Home

Windows Shell LNK exploit over WebDAV

Tue, 2010-07-20 08:54 — Christopher

The Metasploit Framework project released a module yesterday that implemented an attack against the Windows Shell vulnerability when displaying icons for LNK files. The MSF module exploits the vulnerability over WebDAV - currently over HTTP (80/tcp) only. With this module an attacker only needs a victim to click a link to have their system owned.

I have submitted a rule, included below, to Emerging Threats to detect an attempt to access a ".lnk" file from the Windows Shell over WebDAV. In my testing with both Snort and Suricata, the signature reliably detected the MSF exploit.

A future revision of the signature will focus on the exploit in the response body to prevent false positives, but .lnk files over WebDAV (especially to $external_net) should be relatively rare anyway. This signature makes use of HttpInspect in Snort and HTP in Suricata to do most of the heavy lifting.

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET CURRENT_EVENTS Windows Shell LNK GET request via WebDAV possible remote exploit"; flow:established,to_server; content:"GET"; http_method; uricontent:".lnk"; nocase; content:"Microsoft-WebDAV-MiniRedir"; http_header; classtype:bad-unknown; reference:url,www.microsoft.com/technet/security/advisory/2286198.mspx; reference:cve,CVE-2010-2568;sid:2011229; rev:1;)

Comments

Tue, 2010-07-20 12:52 — Anonymous

Thanks

Would it be of benefit to add:

content:".dll"; nocase;

to the rule since the exploit relies on the .lnk to fire off the .dll containing the actual exploit?

Tue, 2010-07-20 18:25 — Christopher

Re: Thanks

You have to keep in mind that Snort processes traffic one packet at a time (really one frame at a time, but we're relying on reassembly for HttpInspect to work anyway). The reference to the .dll that is embedded in the .lnk file is not in the request, but in the response from the server.

I have uploaded a packet capture of the attack here: http://www.cloudshark.org/view?url=http://riosec.com/files/lnk-exploit.cap

The request that my signature is matching on is in frame #28, and the response is in frame #30. Matching across packets in a stream is the job of flowbits. To do this right, we'll need to set a flowbit when we see the WebDAV GET request for the .lnk file from Windows shell, by adding:

flowbits:set,webdav_lnk_req; flowbits:noalert;

to the previous rule. Then the second rule would look like:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET CURRENT_EVENTS Windows Shell LNK GET request via WebDAV possible remote exploit"; flow:established,from_server; flowbits:isset,webdav_lnk_req; file_data; content:".dll"; nocase; classtype:bad-unknown; reference:url,www.microsoft.com/technet/security/advisory/2286198.mspx; reference:cve,CVE-2010-2568;sid:2011230; rev:1;)

This will match the response body from the WebDAV server, but only when the webdav_lnk_req flowbit is set.

I'm not sure about this approach, however, because I'm not convinced that the .lnk actually has to point to a payload in a file that that ends in .dll file - it might be that any file extension would do. It will probably be more effective to match on the actual vulnerability in the .lnk file (the characteristic that makes this file different than a standard .lnk), but I haven't had time to work on that yet. Once I do, I'm planning on posting a revised rule.

Thanks for your comment!

Christopher