This IS the UNC Path You're Looking For
In the previous post we learned a few of the reasons why SMB is so damn popular with attackers; mainly that it's ubiquitous and bakes in remote code execution. We also found that with the right conditions, we could bypass Kerberos and MitM an SMB session to gain authenticated code execution on a target system. Let's dig a little more into the authenticated code execution.
Conditions are Perfect
There are three conditions that must be satisfied before we can MitM SMB:
- We must be able to force a client to initiate an SMB session to our attacking machine.
- Sweet, juicy, trusting NTLM authentication.
- Convenience features.
The first requirement begs for an evil UNC path. Something that redirects the user to \\SERVER\evilshare would be ideal.
The second requirement can be met if we force the client to authenticate either to a non-domain-joined target or via IP.
The third requirement is where the magic happens. By default, when you try to access a file share, your workstation will try to authenticate on your behalf to save you from typing in your credentials every time you have a network resource. This is great since it saves you from all sorts of typing, but is exactly the kind of convenience feature that will ruin your day if you get tricked into authenticating to places you shouldn't be.
Now it's coming together. A UNC path tells a client where to go. Since we're not part of the domain (or if we are, we'll specify an IP), the client will use NTLM. Finally, it's going to automatically authenticate to wherever the UNC path tells it to. Bingo!
But wait! I thought we had challenge/response? How are we running into problems if our hashes never even leave our machine?
Challenges of Challenge/Response
A normal, non-evil challenge/response session looks like this:
No hashes sent, but by default the server is not authenticated. And that is where things fall apart.
Consider this:
In this scenario, the attacker inserts themselves in the middle of this process and just relays the challenge/response messages between the server and the client.
To the client, the attacker appears to be the server, and to the server, the attacker appears to be the client. Since neither side authenticates the other beyond the server validating the correct client response, the attack works.
Once the proces is complete, the attacker drops the client connection and uses the named pipe created to the server to execute code.
But how do we get the client to authenticate?
A... Shortcut?
Watching this attack play out for the first time was a jaw-dropping experience. It was hard to believe that just by opening a folder, my workstation would be authenticating on my behalf to pretty much anywhere. If you have a popular share in your environment that both users and administrators can write to, this becomes especially damaging. User uploads an evil shortcut, administrator views it, whammo. Code execution pretty much anywhere the administrator can normally execute code.
The Attack
This attack depends on a well-placed shortcut. A shortcut is just a file that points to another file and they're all over the damn place. Most of the things you see on your Start Menu are shortcuts. You can tell it's a shortcut by either the distinctive shortcut arrow, or the file extension of .lnk.
When creating or editing shortcuts using the approved GUI method, we've got a few basic parameters available to us--target location, name, description, start in, icon, etc. But if you get nerdy with it, you can bypass the sanity checks for all of these parameters, which lets us specify, say, a UNC path to an icon that doesn't exist. And as you'll recall, a UNC path is exactly what we need to kick things off.
The location we're interested in is the IconLocation parameter. Once your evil UNC path is loaded in there, a user just has to open the folder, at which point explorer.exe will retrieve all the icons for the files contained within. When it hits the evil UNC path, you get an SMB session to the machine of your choosing with whatever privileges the client has on that system.
Here's the output of Responder catching this attack:
|
|
There are a few ways of creating these evil LNK files. The first is Metasploit's post/windows/escalate/droplnk module, which will use a Meterpreter session to drop this shortcut on the target's filesystem.
If you're planning on dropping the shortcut anywhere but the system you've got a shell on, say, a heavily-trafficked file share, the Metasploit module may be a bit clunky to use since you have to then copy it from the target system to somewhere else.
To get around that, I wrote a little PowerShell script that doesn't require a Meterpreter session anywhere and will just dump the LNK file with the parameters of your choosing to the location of your choice.
We're going to talk a bit more about the receiving end of the UNC path in future posts, but first we're going to cover one more attack primitive for this type of attack.
The Elephant in the Room
So this is pretty sweet and all, but it does have pre-requisites. First, you will likely need a valid user account to pull it off. It also requires some user interaction. First an attacker has to make a shortcut, and then someone has to open the damn folder. That's a lot of work and a lot of what-ifs. What if we could somehow just... have it happen?
Next week: it's a feature, not a bug.
ELI5
UNC paths appear all over the place and pretty much all of them can be co-opted to perform the above attack. All that's required is a UNC path pointing to an attacker's machine and a client somehow browsing to that share. Check the resources for additional places to stick your evil UNC paths.