| UPDATE - March 21, 2017 |
|---|
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:
ioc=”apache struts exploit attempt” analysis.service=”content-disposition filename contains null character”
Thanks! |
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:
I've attached a sample PCAP of the POST if you need to replay. Another, showing an HTTP GET was found on the SANS Internet Storm Center site here: Critical Apache Struts 2 Vulnerability (Patch Now!) - SANS Internet Storm Center
Happy Hunting,
Chris
2 Comments
