[Snort-users] [Emerging-Sigs] Signatures for Clients POSTing to SEO/NEOsploit Exploit Kits - Round 2

Eoin Miller eoin.miller at ...14586...
Tue Aug 10 17:24:49 EDT 2010

  On 8/10/2010 8:49 PM, Will Metcalf wrote:
> ehhh be careful... this only works for http_uri and http_client_body
> all other http_* modifiers using distance/within fails silently....
> always... at least in my testing. Which makes me wonder why snort
> doesn't reject those rules during parsing as they will never match.
> Joel?  Also did you test these because as of (yes I know, I
> know) this would only work if you did....
> content:"id="; http_client_body; content:"%26jp"; distance:32;
> classtype:bad-unknown; sid:5600099; rev:2;)
> leaving off the second http_client_body modifier. Otherwise it appears
> the behavior is to always in this case distance would start from the
> beginning of the normalized buffer i.e. behaves like offset.  The same
> trick works for http_uri but if the uri has to be decoded/normalized
> in anyway it will always fail.
> This is really annoying to me btw.  if you have a normalized buffer
> why as a rule writer you should be able to di something like what Eoin
> is trying to do.  For things where within/distance don't really make
> much of a difference I can understand read uricontent, but for things
> like http headers etc where you fingerprint things like a unique
> user-agent using within/distance and can avoid pcre why not allow this
> instead of assuming that the user "really meant" dept/offset.
> just my 0.02
> Regards,
> Will

Thank you for this information. This literally just bit me in the rear, 
but it appears to have been in a slightly different way? What is really 
weird though is only one of the signatures is triggering and the other 
isn't on the same traffic. In trying to troubleshoot this, I've 
rewritten the sigs to even be specifying in content matches in for the 
%26 expressed in hex as |25 32 36| but that doesn't seem to matter 
either. Check this out:

Exploit Kit - request for Java exploit"; flow:established,to_server; 
content:"POST"; http_method; content:"id="; http_client_body; 
content:"|25 32 36|j"; distance:32; http_client_body; 
classtype:bad-unknown; sid:5600100; rev:2;)
SEO Exploit Kit - request for Java and PDF exploits"; 
flow:established,to_server; content:"POST"; http_method; content:"id="; 
http_client_body; content:"|25 32 36|jp"; distance:32; http_client_body; 
classtype:bad-unknown; sid:5600101; rev:2;)

When compared against the following POST:

Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, 
application/x-ms-application, application/x-ms-xbap, 
application/vnd.ms-xpsdocument, application/xaml+xml, 
application/vnd.ms-excel, application/vnd.ms-powerpoint, 
application/msword, application/x-shockwave-flash, */*

Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; 
Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 
3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2)
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
Host: www.mopsdirect.us
Content-Length: 26
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: osCsid=uhlf66l9csn4gkpvj9kq016ht2


Only the first of those two signatures fires on this. Why? Damned if I 
know. There isn't even 32 bytes of data after the "id=" before you get 
to the end of the http_client_body buffer and the hex string "|25 32 
36|j" doesn't exist anywhere in the entire packet, normalized or 
otherwise (unless I am blind).

-- Eoin

More information about the Snort-users mailing list