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

Will Metcalf william.metcalf at ...11827...
Tue Aug 10 18:17:38 EDT 2010


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.



On Tue, Aug 10, 2010 at 4: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 (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:
> 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;)
> 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:
> /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

More information about the Snort-users mailing list