Snort mailing list archives
Re: [Emerging-Sigs] Signatures for Clients POSTing to SEO/NEOsploit Exploit Kits - Round 2
From: Will Metcalf <william.metcalf () gmail com>
Date: Tue, 10 Aug 2010 17:17:38 -0500
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, WillWill, 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¤cy=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
Current thread:
- Re: [Emerging-Sigs] Signatures for Clients POSTing to SEO/NEOsploit Exploit Kits - Round 2 Will Metcalf (Aug 10)
- Re: [Emerging-Sigs] Signatures for Clients POSTing to SEO/NEOsploit Exploit Kits - Round 2 Will Metcalf (Aug 10)
- Re: [Emerging-Sigs] Signatures for Clients POSTing to SEO/NEOsploit Exploit Kits - Round 2 Eoin Miller (Aug 10)
- Re: [Emerging-Sigs] Signatures for Clients POSTing to SEO/NEOsploit Exploit Kits - Round 2 Will Metcalf (Aug 10)
- Re: [Emerging-Sigs] Signatures for Clients POSTing to SEO/NEOsploit Exploit Kits - Round 2 Matt Watchinski (Aug 11)
- Re: [Emerging-Sigs] Signatures for Clients POSTing to SEO/NEOsploit Exploit Kits - Round 2 Will Metcalf (Aug 11)
- Re: [Emerging-Sigs] Signatures for Clients POSTing to SEO/NEOsploit Exploit Kits - Round 2 Will Metcalf (Aug 11)
- Re: [Emerging-Sigs] Signatures for Clients POSTing to SEO/NEOsploit Exploit Kits - Round 2 Alex Kirk (Aug 11)
- Re: [Emerging-Sigs] Signatures for Clients POSTing to SEO/NEOsploit Exploit Kits - Round 2 Eoin Miller (Aug 11)
- Re: [Emerging-Sigs] Signatures for Clients POSTing to SEO/NEOsploit Exploit Kits - Round 2 Matt Watchinski (Aug 11)