Identifying Compromised Accounts

Although the Heartbleed vulnerability allowed for credential theft on an unprecedented scale, account compromises have long been of significant concern to security operations. Even though an organization may not have directly implemented systems vulnerable to Heartbleed, users sharing account names and passwords across applications could easily have had their credentials stolen from a separate, vulnerable site. To detect a malicious actor using stolen credentials to log in to your organization’s network or web applications, LogRhythm includes a set of purpose-built Advanced Intelligence Engine rules.

Because the LogRhythm Labs team is in the process of renaming and reorganizing AIE Rules, the rule id, which will not change, will be included with the current rule name in order to keep this post relevant.

blacklistThe most basic form of catching a malicious login is to blacklist or whitelist certain source locations for remote log ins. Three rules, Susp:Inbound:Connection With Blacklisted Country (464), Susp:Inbound Connection With Non-Whitelisted Country (467), and Ext:Acnt Comp:Remote Auth From Unauthorized Location (6) are very easily to implement, yet are very effective at detecting compromised accounts. Obviously these rules will not trigger when the malicious actor happens to be outside of a blacklisted area or within a whitelist one, but it certainly narrows down possible breach points.

The second group of rules detect authentications for the same account across disparate geographic areas – for example, a user typically shouldn’t be logged in from both Denver and London at the same time. The rules, Ext:Acnt Comp:Concurrent Auth From Multiple Cities (39), Ext:Acnt Comp:Concurrent Auth From Multiple Regions (4), and Ext:Acnt Comp:Concurrent Auth From Multiple Countries (5), will detect malicious actors logging into accounts already in use.

Finally, attackers that have stolen credentials that include the organization’s domain may attempt authentication, even if the user wisely uses a different password. In this case, many authentication failures should be observed. If rules such as Ext:Acnt Atck:Account Scan On Single Host (8) and Ext:Acnt Atck:Brute Force From A Single Origin Host (2) are triggered, the organization can identify users who have a compromised external account. And if the authentications failures are followed with a successful login, rules such as Ext:Acnt Comp:Account Scan On Single Host (7) and Ext:Acnt Comp:Brute Force From A Single Origin Host (1) will identify account compromises.

To reiterate, large account breaches, even if not experienced directly by an organization, can still easily lead to security breaches. Monitoring accounts can allow for much easier mitigation and remediation in the event of an account compromise and should be considered standard practice for even smaller-scaled security operations.

Tags: , , ,

none | ComplianceDigital ForensicsGeneralSecuritySIEM

 
 

The Internets Bleeding Heart

As most everyone in the security industry is well aware, the Heartbleed vulnerability (CVE-2014-0160) is a major issue that has a drastic impact on the Internet as a whole. This specifically affects the heartbeat extension of OpenSSL, which allows for ‘keep-alive’ functionality without performing a renegotiation.

“The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).

The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.”

http://heartbleed.com/

The following versions of OpenSSL are vulnerable:

  • 1.0.1
  • 1.0.1a
  • 1.0.1b
  • 1.0.1c
  • 1.0.1d
  • 1.0.1e
  • 1.0.1f
  • 1.0.2-beta1

Versions 1.0.1g, 1.0.0, and 0.9.8 have been reported to not include this bug. If you are running a vulnerable version of OpenSSL you can remediate the vulnerability by downloading the patch here: https://www.openssl.org/source/.

The severity of this vulnerability is extrapolated only by the sheer number of servers running vulnerable versions of OpenSSL. Many of these servers are hosting ‘trusted’ applications which store very sensitive user data that is now at risk of being exposed.

ShodanHQ - Tweet - Vulnerable Servers

Figure 1: Metrics on known vulnerable servers world wide

Lists are even being compiled of popular vulnerable sites.

Right now, hackers can attack vulnerable servers and read the host’s memory. This vulnerability, when exploited, will inevitably expose sensitive data — including usernames, passwords, server certificates, and much more, depending on the server’s configuration and purpose.

testing PoC

Figure 2: Testing against known vulnerable servers

The folks over at BugCrowd have released an excellent summary of the currently available Exploit PoC code to test this vulnerability, which includes a Metasploit Module that allows for very easy internal testing. For public facing services, the Heartbleed test site is great and can also be run internally, however beware that this does have the potential to leak your target’s memory to the internet, make sure you understand and are okay with this before proceeding. In our testing, the easiest one to demonstrate with is the very simple ssltest.py script, available on Pastebin. Be careful running any of these scripts, as exploit code can very dangerous if you are inexperienced with this sort of thing…

This is a fascinating vulnerability that is full of potential, especially for penetration testers and ‘hackers’ as a wealth of information can be exposed without leaving many traces on the target host. In-fact, the ssl-access logs will show nothing when this vulnerability is triggered. So, for this type of attack we must rely on network flow data and anomaly detection at layer 3.

heartbleed log traces

Figure 3: Log traces from Heartbleed attack

Examining a packet capture of the network traffic this generates, we can see the request…

Figure 4: Heartbleed Request

Figure 4: Heartbleed Request

And response…

Figure 5: Heartbleed Response

Figure 5: Heartbleed Response

In reviewing the SSL request, we can see the encrypted heartbeat, which gives us a content type of Heartbeat (24) and a length of 3. This gives us a unique indicator that can be used to catch this activity as it passes across the network. The only problem being, this would result in many false positives.

Figure 6: SSL Heartbeat Request Details

Figure 6: SSL Heartbeat Request Details

There are a few ways to do this, one of which is to utilize Snort rules and trigger on this activity within a SIEM so that the Security Analysts can detect and respond to this vulnerability from a central interface. Speaking of Snort, they have covered the details of the vulnerability in a recent blog post. This is an excellent summary of why specific versions of OpenSSL are vulnerable to this attack and more importantly how this activity can be detected using an Intrusion Detection System (IDS). With LogRhythm, we can utilize these rules along with the following Advanced Intelligence Engine (AIE) Rule Blocks to alert on this activity within Snort logs.

This is made up of two rule blocks, the first of which consists of four unique Snort Vendor Message ID’s (VMID), which essentially reflect a ‘Heartbleed’ request.

Figure 4: Heartbleed Request AIE Rule Block

Figure 7: Heartbleed Request AIE Rule Block

The second half of this rule, triggers on the response from a vulnerable server. This helps in reducing false positives so that security analysts do not waste time tracking down unsuccessful attacks.

Figure 5: Heartbleed Response AIE Rule Block

Figure 8: Heartbleed Response AIE Rule Block

If you are interested in the details of this rule, Snort has documented each of these relevant VMID’s in their Heartbleed blog post.

If you are not running an IDS, you can also find this activity by looking for continuous HTTPS requests against servers without pulling any subsequent data such as favicons, CSS, JavaScript, etc. If someone is actively reading the memory on your server, multiple requests will be made in quick succession over an extended period of time; however one-off requests will be much more difficult to detect.

The best solution is to apply the OpenSSL patch and test your entire environment using the supplied tools to assure that the vulnerability has been remediated across the board. If you are using something like Puppet, Chef, or Ansible, this entire patching process can be automated rather easily.

heartbleed

Tags: , , , , , , , , , , , , ,

none | Security

 
 

Time has run out for Windows XP users

Today, Microsoft has ended support for its Windows XP operating system, however many organizations have not yet upgraded to a newer version of Windows.  In fact, recent reports suggest that not only are 30 percent of PCs worldwide running XP, but over half of the UK’s councils and 95 percent of the world’s cash machines run on Microsoft’s fated platform.  As such, with support now ended, many are going to find themselves with gaping security holes.  Time has now run out for those businesses to upgrade to a new operating system and it is likely that hackers will already be planning their attacks to exploit these vulnerabilities.  Unless some form of action is taken now, anyone operating XP should be concerned.

While antivirus software and firewalls are the basic line of defense, they won’t be able to stop everything – particularly as they already struggle to keep up with zero-day exploits.  It is therefore imperative that other controls are put in place that can minimize this new weakness.  An effective measure would be to implement protective monitoring tools that provide complete visibility into the network.  Not only can this strategy be implemented with relative speed, but as these solutions alert on any suspicious activity immediately, organizations are in a far better position to react and contain the threat before it causes any lasting damage.

Cyber attacks against businesses are already ten-a-penny, therefore there is really no excuse not to increase defenses when there is a growing security threat – especially as they have been forewarned.  Long-term, the only answer is to upgrade to a new operating system but, in the short-term, businesses can compensate by having the tools in place to know exactly what is happening on the network at all times.   Most organizations have to consider it a case of when they are breached, not if, and running XP without extra protection in place is simply going to make the ‘when’ occur faster.

XP Image

none | Uncategorized

 
 

Security and Your Internet-Connected Car of the Future

As more and more car features such as remote unlocking and starting become available over the internet, the need to properly secure these features increases. As an example Nitesh Dhanjani demonstrated what level of control he was able to gain over a Tesla Model S sedan after a simple brute force attack. Security researchers will begin uncovering these flaws more and more frequently as consumers demand internet-connected features in their cars and the security and auto manufacturing industries will need to respond with more advanced security measures.

http://www.cnbc.com/id/101539060

http://www.engadget.com/2014/04/01/tesla-hacking/

none | GeneralSecurity

 
 

Overcoming Individual Weaknesses in Security Technologies

By Michael Logoyda

Before RSA, Dave Aitel of Immunity Security summarized the weaknesses and benefits (but mostly weaknesses) of several security technologies in the table below (further described here). Presumably, this acted as a warning to readers and RSA attendees to be skeptical that one vendor’s product could be an InfoSec panacea. This certainly must have proved useful during the conference, where several presentations made claims about the ineffectiveness of select security techniques – for example, the many flaws of signature-based or statistical anomaly-based approaches. The solutions, of course, typically involved a specific product or service.

Although some of the weaknesses in the table below may have been slightly exaggerated (discussed here), these issues reflect the current state of InfoSec: compromises across all sectors continue to persist as security professionals face both increasingly skilled adversaries and mounting pressure to stop them. Solutions are hard to come by.

Even under such pressure, it’s important to avoid the temptation of looking for a magic bullet. Within the realm of network defense, there is no quick remedy, nor will there likely ever be – novel  techniques and motivated adversaries will always change the game. The best chance of a successful security operation is to continually adapt to this arms race, bringing together expertise with complimentary devices and techniques that have proven themselves most capable in their respective arenas. This strategy is known as “defense in depth”.

Following this philosophy, an organization can of course use these devices independently and, with sufficient manpower and knowledge, still run a reasonably successful security operations center. But after making large investments into security infrastructure, managing security from dozens of devices can be challenging – centralizing data allows for much clearer insight into the security posture of an organization. More importantly, having this data in a standard format allows for correlation between devices, which compensates for individual weaknesses and augments their strengths, granting security professionals the best chance of catching malicious actors before they’re able to pilfer their organization’s data. Thus, for the best return on investment on all of those fancy security technologies purchased at RSA, consider bringing their disparate security and log data into a SIEM with a real analytics engine – it’s certainly the easiest way to effectively manage a defense in depth InfoSec strategy. But however your organization choses to defend their network, focus on each security tool’s strengths while using an overlapping strategy to eliminate their weak points. The thorough approach will win out in the end.

Table of Security Technologies strengths and weaknesses

LL 14 March

 

none | Uncategorized