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

Will Metcalf william.metcalf at ...11827...
Wed Aug 11 12:33:48 EDT 2010


> 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 just tested on 2.8.6.1 and it appears as if the behavior is the same
as 2.8.5.3.  I think the only reason why you get a match here is
because distance is treated like offset so you are really searching
for "45" from the start of the normalized buffer not from the last
match. I bet if you change content:"45"; distance:0; http_client_body;
to content:"product"; distance:0; http_client_body; the sig will still
fire...

Regards,

Will

On Wed, Aug 11, 2010 at 10:42 AM, Matt Watchinski
<mwatchinski at ...1935...> wrote:
> 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