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

Matt Watchinski mwatchinski at ...1935...
Wed Aug 11 11:42:59 EDT 2010


Initial thought after basic testing on 2.8.6.1. Distance greater than
http_client_body actual size isn't being bounded correctly.

IE max distance is 25

This alerts as shown below.
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"DRIVEBY SEO
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;)

Change distance to max real distance of 25:
This doesn't alert in my testing
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"DRIVEBY SEO
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:25; http_client_body;
classtype:bad-unknown; sid:5600100; rev:2;)

Change distance to 0
This doesn't alert either.
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"DRIVEBY SEO
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:0; http_client_body;
classtype:bad-unknown; sid:5600100; rev:2;)

Change test case to something actually in http_client_body buffer and bound it.
This alerts as expected.
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"DRIVEBY SEO
Exploit Kit - request for Java exploit"; flow:established,to_server;
content:"POST"; http_method; content:"id="; http_client_body;
content:"45"; distance:0; http_client_body;
classtype:bad-unknown; sid:5600100; rev:2;)

I've opened a bug here in the tracker for this, when the snort dev's
add the complete answer I'll forward it out.

Cheers,
-matt

On Tue, Aug 10, 2010 at 5:24 PM, Eoin Miller
<eoin.miller at ...14586...> wrote:
>  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 2.8.5.3 (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
> 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:
>
> alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"DRIVEBY SEO
> 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;)
> alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"EID DRIVEBY
> 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:
>
> POST
> /earth-expandable-substrate-pack-p-1903.html?action=add_product&currency=USD&osCsid=uhlf66l9csn4gkpvj9kq016ht2
> HTTP/1.1
> 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, */*
> Referer:
> http://www.mopsdirect.us/earth-expandable-substrate-pack-p-1903.html?currency=USD
>
> 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
>
> products_id=1903&x=45&y=13
>
>
> 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
>
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users
>



-- 
Matthew Watchinski
Sr. Director Vulnerability Research Team (VRT)
Sourcefire, Inc.
Office: 410-423-1928
http://vrt-sourcefire.blogspot.com && http://www.snort.org/vrt/




More information about the Snort-users mailing list