[Snort-users] [Emerging-Sigs] Signatures for Clients POSTing to SEO/NEOsploit Exploit Kits - Round 2
eoin.miller at ...14586...
Tue Aug 10 17:24:49 EDT 2010
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 18.104.22.168 (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
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:
Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg,
application/msword, application/x-shockwave-flash, */*
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)
Accept-Encoding: gzip, deflate
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).
More information about the Snort-users