<<< Date Index >>>     <<< Thread Index >>>

Re: WMF Exploit



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