How to detect the Heartbleed Vulnerability using RSA Security Analytics

[RSAAdmin]

What is Heartbleed?

The Heartbleed OpenSSL vulnerability is a serious weakness in specific implementations of the OpenSSL software on servers, Virtual Private Networks and other applications.  For full details on this vulnerability, please visit http://heartbleed.com

How can RSA find instances of Heartbleed?

RSA Security Analytics gives users the ability to identify servers vulnerable to the Heartbleed exploit, as well as detect attempts to exploit the service. This is a perfect example of the type of incident investigation and forensics that can be achieved utilizing full packet capture and RSA Security Analytics.

What rules and/or parsers have been created to help find Heartbleed?

Parsers that have been created to address Heartbleed are now available in RSA Live.  These are available for all RSA Live subscription tiers.  The specific parsers are “TLS” and “TLS_lua”. Users subscribed to either of these parsers will be automatically updated. For users that are not currently subscribing to either piece of content, they should disable the default TLS parser and subscribe to one of the two TLS parsers available on RSA Live. For customers running RSA NetWitness / RSA Security Analytics version 10.2 and below, use the Flex parser “TLS”. For those running versions 10.2 and above, use the LUA parser “TLS-lua”.

To detect vulnerable  servers, look for instances of “openssl vulnerable to heartbleed” under the risk.informational meta-key. For detecting exploit attempts, look for “heartbleed data leak” under risk.warning meta-key.

Once detected how can Heartbleed be remediated?

To fully remediate this vulnerability, upgrade weak systems to the latest fixed version of OpenSSL and revoke old keys. Renew your SSL certificate, and if applicable, change passwords for sensitive accounts.

[RSAAdmin]

Whats the app rule that we can use to look for the previous data. We want to go back see if there was any hit for this vulnerability.. Thanks in advance...

[RSAAdmin]

Exploit attempts (failed or otherwise) won't be detectable using an app rule alone.

The app rule mentioned by Fielder will detect vulnerable OpenSSL versions based on "server" meta.

Note that for non-previous data, the TLS-flex and TLS_lua parser updates include the functionality of that app rule.

[huanzhou1]

https://knowledge.rsasecurity.com/scolcms/set.aspx?id=10187

How to detect the Heartbleed Vulnerability using RSA Security Analytics

[Anonymous]

Will the parser capture the full packets if we have a network rule to truncate ssl?

[huanzhou1]

The parser doesn't use the payload, if you want to capture  the full packets then please disable truncate ssl rule.

- Parses SSL/TLS certificates. Specifically, it looks for the first certificate in a chain and extracts the Issuer Organizational Name (meta ssl.ca), Subject Organizational Name (meta ssl.subject), and Subject Common Name (meta alias.host).

[RSAAdmin]

If the session is being truncated by a network rule, then the payload is filtered before it is seen by the parsers at all.

[huanzhou1]

The network rules can retain the Application Meta correct, i tested the SSL details which are retained when the rule is active.

[Anonymous]

patriot3w wrote:

Parses SSL/TLS certificates. Specifically, it looks for the first certificate in a chain and extracts the Issuer Organizational Name (meta ssl.ca), Subject Organizational Name (meta ssl.subject), and Subject Common Name (meta alias.host).

So it's looking at the certificate and org name. How does that have anything to do with heartbleed?

What I'd want a heartbleed data loss indicator is a response to a heartbeat request with too much data.

A malicious heartbleed request would ask for extensions.

[RSAAdmin]

The primary functionality of the TLS-flex and TLS_lua parsers is to identify TLS/SSL sessions and extract certificate meta from them.

Heartbleed detection was added to them as secondary functionality.  But Heartbleed detection does not use any certificate information.

As for network rules - I think if you are truncating you may be okay, but not if you are filtering (but that is getting into an area where I don't have as much expertise... ) As long as the session is available to the parsing engine, then meta will be registered.

[RSAAdmin]

Parsers get processed before App rules. So if the TLS parser is enabled, you could leverage an App Rule to alert on heartbleed findings (and selecting STOP RULE PROCESSING and KEEP in the rule configuration) and put this App Rule above your App Rule that truncates SSL (service = 22, 443).