Pay Attention to this Samba Vulnerability

We have a feeling that this recent Samba vulnerability should be at the top of your mind. We are seeing a lot of attention to this across a variety of platforms and we wanted to make sure you saw it. It should be patched as soon as possible, especially on highly sensitive data stores and critical systems.

Let us know if you have any questions.

Keep Your Hands Off My SSL Traffic

Hey, you, get off my digital lawn and put down my binary flamingos!!!!! 

If you have been living under an online rock these last couple of weeks, then you might have missed all of the news and hype about the threats to your SSL traffic. It seems that some folks, like Lenovo and Comodo, for example, have been caught with their hands in your cookie jar. (or at least your certificate jar, but cookie jars seem like more of a thing…) 

First, we had Superfish, then PrivDog. Now researchers are saying that more and more examples of that same code being used are starting to emerge across a plethora of products and software tools.

That’s a LOT of people, organizations and applications playing with my (and your) SSL traffic. What is an aging infosec curmudgeon to do except take to the Twitters to complain? 🙂

There’s a lot of advice out there, and if you are one of the folks impacted by Superfish and/or PrivDog directly, it is likely a good time to go fix that stuff. It also might be worth keeping an eye on for a while and cleaning up any of the other applications that are starting to be outed for the same bad behaviors.

In the meantime, if you are a privacy or compliance person for a living, feel free to drop us a line on Twitter (@lbhuston, @microsolved) and let us know what your organization is doing about these issues. How is the idea of prevalent man-in-the-middle attacks against your compliance-focused data and applications sitting with your security team? You got this, right? 🙂

As always, thanks for reading, and we look forward to hearing more about your thoughts on the impacts of SSL tampering on Twitter! 

3 Things I Learned While Responding to Security Incidents

Unfortunately, if you work in IT long enough, you’re likely to encounter a security incident. Having experienced these incidents as a Systems Administrator and as a consultant, I felt that it would benefit others if I shared 3 things that I learned while responding to security issues.

  1. Stay calm – If you’ve noticed malicious activity on your network, your first reaction might be to panic. While time is of the essence, you don’t want stress to negatively impact your decision making. If you need to, give yourself a minute to collect your thoughts prior to proceeding with resolving the issue. Once you’re ready to start working on the problem, begin by attempting to gain an understanding of the type and severity of the attack. This information will go a long way towards mitigating the issue.
  2. Don’t be shortsighted – Whether you’re dealing with a targeted attack or a random malware infection, it’s important to consider the long term effects of your decisions. It is likely that you will receive pressure from various business units to bring systems back online as soon as possible. While it’s important that staff regains access to their applications, it could lead to larger problems down the line if that access is restored prematurely. For example, removing network connectivity or isolating affected systems is obviously going to upset some staff members due to the loss of productivity. However, it’s possible that the malware or attacks could become more widespread if the affected systems are not properly isolated.
  3. Hindsight is 20/20 – I’ve seen individuals waste time during incidents pointing fingers at other team members. I’ve also witnessed individuals procrastinate resolving the issue while they agonize over ways they could have prevented the incident from occurring. After the issue has been resolved, it’s important to have a post mortem meeting to take the proper steps to make sure that history does not repeat itself. However, those conversations can wait until the incident has been fully resolved.

I sincerely hope you don’t have to deal with any security incidents.  However, if you need help resolving an issue involving a malware outbreak or targeted attack, do not hesitate to contact us for assistance.

Telnet!? Really!?

I was recently analyzing data from the HITME project that was collected during the month of January. I noticed a significant spike in the observed attacks against Telnet. I was surprised to see that Telnet was being targeted at such a high rate. After all, there can’t be that many devices left with Telnet exposed to the internet, right?

Wrong. Very wrong. I discovered that there are still MILLIONS of devices with Telnet ports exposed to the internet. Due to Telnet’s lack of security, be sure to use SSH as opposed to Telnet whenever possible. If you absolutely must control a device via Telnet, at least place it behind a firewall. If you need to access the device remotely, leverage the use of a VPN. Finally, be sure to restrict access to the device to the smallest possible IP range.

The map below shows the geographical locations and number of attacks against Telnet that we observed last month. If you need any help isolating Telnet exposures, feel free to contact us by emailing info <at> microsolved.com.

Screen Shot 2015-02-10 at 11.28.10 AM

 

Podcast Episode 1 is Now Available

This episode is about 45 minutes in length and features an interview with Dave Rose (@drose0120) and Helen Patton (@OSUCISOHelen) about ethics in security, women in STEM roles and career advice for young folks considering Infosec as a career. Have feedback, let me know via Twitter (@lbhuston).

 
As always, thanks for listening and reading stateofsecurity.com!
 
Listen here: 
 
PS – We decided to restart the episode numbers, move to pod bean.com as a hosting company and make the podcast available through iTunes. We felt all of those changes, plus the informal date-based episode titles we were using before made the change a good idea.

Social Media Targeting: A Cautionary Tale

I was recently doing some deep penetration testing against an organization in a red-team, zero knowledge type exercise. The targets were aware of the test at only the highest levels of management, who had retained myself and my team for the engagement. The mission was simple, obtain either a file that listed more than 100 of their key suppliers, or obtain credentials and successfully logon to their internal supply system from an account that could obtain such a file.

Once we laid some basic groundwork, it was clear that we needed to find the key people who would have access to such data. Given the size of this multi-national company and the thousands of employees they had across continents, we faced two choices – either penetrate the network environment and work our way through it to find and obtain the victory data and/or find a specific person or set of persons who were likely to have the data themselves or have credentials and hack them get a shortcut to victory.
 
We quickly decided to try the shortcut for a week or less, preserving time for a hack the network approach should we need it as a backup. We had approximately 6 weeks to accomplish the goal. It turned out, it took less than 6 hours…
 
We turned our TigerTrax intelligence & analytics platform to the task of identifying the likely targets for the shortcut attack. In less than 30 minutes, our intelligence team had identified three likely targets who we could direcly link to the internal systems in question, or the business processes associated with the victory condition. Of these three people, one of them was an extensive participant in their local dance club scene. Their social media profile was loaded with pictures of them dancing at various locales and reviewing local dance clubs and DJs. 
 
A plan was quickly developed to use the dance club angle as an approach for the attack, and a quick malware serving web site was mocked up to look like an new night club in the target’s city. The team them posted a few other sites pointing to a new club opening and opened a social media account for the supposed club’s new name. The next day, the penetration team tested the exploits and malware against the likely OS installs of the victim (obtained from some of their social media data that was shared publicly). Once the team was sure the exploits and malware were likely to function properly, the club’s social media account sent a tweet to the account of the target and several other people linked to the club scene, inviting them to a private “soft opening” of the club — starring the favorite DJ of the target (obtained from his twitter data). Each person was sent a unique link, and only the target’s link contained the exploit and malware. Once the hook was delivered, the team sat back and waited a bit. They continued to tweet and interact with people using the club’s account throughout the rest of the day. Within hours, the target followed the club’s account and visited the exploit site. The exploit worked, and our remote access trojan (RAT) was installed and connected back to us.
 
It took the team about an hour to hoover through the laptop of the target and find the file we needed. About the same time, an automated search mechanism of the RAT returned a file called passwords.xls with a list of passwords and login information, including the victory system in question. The team grabbed the victory files, screen shotted all of our metrics and data dashboards and cleaned up after themselves. The target was none the wiser.
 
When we walked the client through this pen-test and explained how we performed our attack, what controls they lacked and how to improve their defenses, the criticality of social media profiling to attackers became crystal clear. The client asked for examples of real world attackers using such methods, and the team quickly pulled more than a dozen public breach profiles from the last few years from our threat intelligence data.
 
The bottom line is this – this is a COMMON and EFFECTIVE approach. It is trivial for attackers to accomplish these goals, given the time and will to profile your employees. The bad guys ARE doing it. The bigger question is – ARE YOU?
 
To learn more about our penetration testing, social engineering and other security testing services, please call your account executive to book a free education session or send us an email to info@microsolved.com. As always, thanks for reading and until next time, stay safe out there!

RansomWeb Attacks Observed in HITME

Unfortunately, the destructive nature of Ransomware has taken a new turn for the worse.  A new technique called RansomWeb is affecting production web-based applications.  I recently analyzed data from the HITME project and observed several RansomWeb attacks against PHP applications.  I can only assume the frequency of these attacks will increase throughout the year.  As a former Systems Administrator, I can definitively say that it would be a nightmare to bring an application back online that was affected by this variant of Ransomware.  Due to RansomWeb’s destructive nature, it is important to ensure that your organization is actively working to prevent RansomWeb from destroying any critical systems.

The attackers begin the RansomWeb process by exploiting a vulnerability within a web server or web-based application.  Once the server or application have been exploited, the attackers slowly begin encrypting key databases and files.  Once the encryption is complete, the hackers shut down the website/application and begin to demand ransom in exchange for the decryption of the corporation’s files.  Unfortunately, the attackers have even perfected using this process to encrypt system-level backups.

To prevent RansomWeb from affecting your organization, please be sure to complete the following steps on a regular basis:

  • Perform regular vulnerability assessments and penetration testing against your critical applications and servers.
  • Audit your application and system logs for any irregular entries.
  • Verify that you are performing regular application and system backups.
  • Be sure to test the backup/ restore process for your applications and systems on a regular basis.  After all, your backup/ DR process is only as effective as your last successful restore.

If you would like to discuss how we can help you prevent RansomWeb from affecting your production applications, do not hesitate to contact us by emailing info <at> microsolved.com

The Need for an Incident Recovery Policy (IRP)

Organizations have been preparing for information security issues for a number of years now and many, if not most, have embraced the need for an incident response policy and process. However, given the recent spate of breaches and compromises that we have analyzed and been involved in over the last year, we have seen an emerging need for organizations to now embrace a new kind of policy – a security incident RECOVERY policy.
 
This policy should extend from the incident response policy and create a decision framework, methodology and taxonomy for managing the aftermath of a security incident. Once the proverbial “fire has been put out”, how do we clean up the mess, recreate the records we lost, return to business as usual and analyze the impacts all of this had on our operations and long term bottom line? As a part of this process, we need to identify what was stolen, who the likely benefactors are, what conversion events have taken place or may occur in the future, how the losses impact our R&D, operational state, market position, etc. We also need to establish a good working model for communicating the fallout, identified issues, mitigations, insurance claims, discoveries and lessons learned to stakeholders, management, customers, business partners and shareholders – in addition to the insurance companies, regulators and law enforcement.
 
As you can imagine, this can be a very resource intensive process and since post-incident pressues are likely to remain high, stress levels can be approaching critical mass and politics can be rampant, having a decision framework and pre-developed methodology to work from can be a life saver. We suggest following the same policy development process, update timeframes and review/practice schedules as you do for your incident response policy.
 
If your organization would like assistance developing such a policy, or would like to work through a training exercise/practice session with an experienced team, please feel free to work with your account executive to schedule such an engagement. We also have policy templates, work sheets and other materials available to help with best practice-based approaches and policy creation/reviews.