Due to continued interest in this event and continued public exploitation, we’ve added detection to the HTTP_lua parser. Customers will get this update automatically via the LIVE update process if they are subscribed to this content. The following meta is created if the parser is triggered:
Since the release of CVE-2017-5638, the RSA Incident Response team has fielded several questions about how to detect this activity. Proof of concept code is already available and being used to identify vulnerable servers. Fortunately, detection with Netwitness Packets it is quite easy.
The packet decoder contains HTTP parsers that will parse out much of the HTTP headers. Since this exploit appears to be using a malformed Content-Type entry, we can detect this by examining meta already coming in.
One thing to note is that this traffic still appears as valid HTTP traffic. It appears like a typical POST and has valid HTTP headers with the exception of the malformed Content-Type.
Another included an HTTP GET.
One way to find this traffic is using existing meta combined to make new meta. We can make an app rule out of this. Lets examine the meta.
We already have service type of 80 (HTTP) and a long content meta. We can pick out interesting pieces from the content meta key such as "_member".
Therefore an application rule might look like:
service=80 && content contains '_member'
If we turn that into a query to double-check our work, we should get the session(s) of interest: