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

[Will Metcalf <william.metcalf () gmail com>]

Eoin,

To be completely honest other than looking at a modification to the
behavior of byte_test option parsing I haven't looked at the snort
source code in a very long time.  This only the observed behavior of
content/modifier interaction that I have seen.  Hopefully somebody
from SF will respond.

Regards,

Will

On Tue, Aug 10, 2010 at 4:24 PM, Eoin Miller
<eoin.miller () trojanedbinaries com> 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 () 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