From: Eoin Miller (eoin.millertrojanedbinaries.com)
Date: Tue Aug 10 2010 - 16:24:49 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  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-userslists.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

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]