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

Will Metcalf william.metcalf at ...11827...
Wed Aug 11 13:41:55 EDT 2010


Matt,

A bit more info....  have the pcap if you want/need it.

POST /index.php/component/search/index.php HTTP/1.1
Host: www.openinfosecfoundation.org
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8)
Gecko/20100214 Ubuntu/9.10 (karmic) Firefox/3.5.8
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.openinfosecfoundation.org/index.php/component/search/AllWorkAndNoPlayMake?ordering=&searchphrase=all
Cookie: e6504ae48c99f09df7f58996aacbb6b0=120e494ce857d6ceeef89f9678d4d703
Content-Type: application/x-www-form-urlencoded
Content-Length: 54

searchword=1234567891011&task=search&option=com_search

-----------------------------------------------------------------------------------------------------------------
#fails http_client body with within/distance on previous
http_client_body match..
alert tcp any any -> any any (msg:"searchword= with ucontent +
http_client_body + searchword="; content:"search"; depth:6;
http_client_body; nocase; content:"word="; distance:0; within:5;
http_client_body; classtype:bad-unknown; sid:59; rev:1;)

#works no http_client body on relative match
alert tcp any any -> any any (msg:"searchword= with ucontent +
http_client_body + searchword="; content:"search"; depth:6;
http_client_body; nocase; content:"word="; distance:0; within:5;
classtype:bad-unknown; sid:60; rev:1;)

#works distance is treated as offset
alert tcp any any -> any any (msg:"searchword= with ucontent +
http_client_body + searchword="; content:"search"; depth:6;
http_client_body; nocase; content:"word="; distance:6; within:5;
http_client_body; classtype:bad-unknown; sid:61; rev:1;)


/opt/snort2861/bin/snort -c /opt/snort2861/etc/snort.conf -r
/home/coz/rules4/oisfsearchnums.pcap -l ./ -k none -A console -q
03/07-22:19:54.242506  [**] [1:60:1] searchword= with ucontent +
http_client_body + searchword= [**] [Classification: Potentially Bad
Traffic] [Priority: 2] {TCP} 192.168.100.17:38111 -> 96.43.130.5:80
03/07-22:19:54.242506  [**] [1:61:1] searchword= with ucontent +
http_client_body + searchword= [**] [Classification: Potentially Bad
Traffic] [Priority: 2] {TCP} 192.168.100.17:38111 -> 96.43.130.5:80
Rule Profile Statistics (worst 20 rules)
==========================================================
   Num      SID GID Rev     Checks   Matches    Alerts
Microsecs  Avg/Check  Avg/Match Avg/Nonmatch
   ===      === === ===     ======   =======    ======
=========  =========  ========= ============
     1       60   1   1          2         2         1
  6        3.1        3.1          0.0
     2       61   1   1          2         2         1
  2        1.2        1.2          0.0
     3       59   1   1          2         0         0
  2        1.2        0.0          0.2

On Wed, Aug 11, 2010 at 11:33 AM, Will Metcalf
<william.metcalf at ...11827...> wrote:
>> Change test case to something actually in http_client_body buffer and bound it.
>> This alerts as expected.
>> 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:"45"; distance:0; http_client_body;
>> classtype:bad-unknown; sid:5600100; rev:2;)
>
> I just tested on 2.8.6.1 and it appears as if the behavior is the same
> as 2.8.5.3.  I think the only reason why you get a match here is
> because distance is treated like offset so you are really searching
> for "45" from the start of the normalized buffer not from the last
> match. I bet if you change content:"45"; distance:0; http_client_body;
> to content:"product"; distance:0; http_client_body; the sig will still
> fire...
>
> Regards,
>
> Will
>
> On Wed, Aug 11, 2010 at 10:42 AM, Matt Watchinski
> <mwatchinski at ...1935...> wrote:
>> Initial thought after basic testing on 2.8.6.1. Distance greater than
>> http_client_body actual size isn't being bounded correctly.
>>
>> IE max distance is 25
>>
>> This alerts as shown below.
>> 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;)
>>
>> Change distance to max real distance of 25:
>> This doesn't alert in my testing
>> 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:25; http_client_body;
>> classtype:bad-unknown; sid:5600100; rev:2;)
>>
>> Change distance to 0
>> This doesn't alert either.
>> 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:0; http_client_body;
>> classtype:bad-unknown; sid:5600100; rev:2;)
>>
>> Change test case to something actually in http_client_body buffer and bound it.
>> This alerts as expected.
>> 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:"45"; distance:0; http_client_body;
>> classtype:bad-unknown; sid:5600100; rev:2;)
>>
>> I've opened a bug here in the tracker for this, when the snort dev's
>> add the complete answer I'll forward it out.
>>
>> Cheers,
>> -matt
>>
>> On Tue, Aug 10, 2010 at 5: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 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 at 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
>>>
>>
>>
>>
>> --
>> Matthew Watchinski
>> Sr. Director Vulnerability Research Team (VRT)
>> Sourcefire, Inc.
>> Office: 410-423-1928
>> http://vrt-sourcefire.blogspot.com && http://www.snort.org/vrt/
>>
>




More information about the Snort-users mailing list