On Fri, 2005-12-30 at 15:40 -0500, Paul Laudanski wrote: > alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"BLEEDING-EDGE EXPLOIT > WMF Escape Record Exploit"; flow:established,from_server; content:"01 00 > 09 00 00 03"; depth:500; content:"00 00"; distance:10; within:12; > content:"26 06 09 00"; within:5000; classtype:attempted-user; > reference:url,www.frsirt.com/english/advisories/2005/3086; sid:2002733; > rev:1;) This signature is outdated and can be evaded easily. Get the latest version from http://www.bleedingsnort.com/cgi-bin/viewcvs.cgi/sigs/CURRENT_EVENTS/CURRENT_WMF_Exploit?only_with_tag=HEAD&view=markup Also, make sure you read the important note on this sig (before you wonder why it doesn't alert) as outlined in the bleeding-sigs mail list. In case you missed that post, here again. ---8<--- Greetings, below is a revised version of the Snort signatures for the WMF issue: Web Only: alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"EXPLOIT WMF Escape Record Exploit - Web Only"; flow:established,from_server; content:"HTTP"; depth:4; nocase; content:"|00 09 00 00 03|"; within:500; content:"|00 00|"; distance:10; within:12; pcre:"/\x26[\x00-\xff]\x09 \x00/"; classtype:attempted-user; reference:url,www.frsirt.com/english/advisories/2005/3086; sid:2002741; rev:2;) All Ports: alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"EXPLOIT WMF Escape Record Exploit"; flow:established,from_server; content:"|00 09 00 00 03|"; depth:800; content:"|00 00|"; distance:10; within:12; pcre:"/\x26[\x00-\xff]\x09\x00/"; classtype:attempted-user; reference:url,www.frsirt.com/english/advisories/2005/3086; sid:2002733; rev:3;) Credits to Blake Harstein and Brandon Franklin for their cooperation with us on further refinement and on-going improvement of the BleedingSnort rules. There is one important note in regards to ALL published signatures including this one. All these signatures will fail to detect the exploits when the http_inspect preprocessor is enabled with default settings. My default, the flow_depth of the preprocessor is 300 which is too short to cover the whole exploit. Should the exploit be transmitted on port 80 and http_inspect is enabled, no alert will occur. Note that it will still alert on any ports (using the all port sig below) that are not configured in http_inspect (ie FTP). One solution is to add the statement "flow_depth 0" to the http_inspect preprocessor. This will tell the preprocessor not to truncate the reassembled pseudo-packet, but it will have an adverse impact on performance. On busy networks, this will lead to 100% CPU utilization of the Snort process and major packet drops. So we're between a rock, a solid surface, and a hard place. The exploits are web based, yet the signature will fail with http_inspect enabled. With it disabled, Snort will miss all rules containing uricontent and pcre/U statements. With it enabled, and flow_depth set to 0, Snort will alert on the exploit, but also process all uricontent rules in such a fashion that its CPU utilization is skyrocketing. The only viable solution at this point is to run two instances of Snort. One with your normal set of rules and http_inspect enabled with either the default or "sane" values for flow_depth. The second instance should run with http_inspect disabled or flow_depth set to 0, and process only rules that have to cover a larger than 300 byte area for content matches on ports configured in http_inspect. This two-pronged approach assures that Snorts performance is kept at normal levels, preventing packet loss. Have a good weekend and a great New Year! Frank -- It is said that the Internet is a public utility. As such, it is best compared to a sewer. A big, fat pipe with a bunch of crap sloshing against your ports.
Attachment:
signature.asc
Description: This is a digitally signed message part