Sunday, April 5, 2015

No, Microsoft Hasn't "Fixed" Silver Tickets

Contrary to what many folks might think, I don't wait around on the Internet for somebody to be wrong to blog about it.  However, when somebody misrepresents research that myself and others have worked on, there's something to talk about.  Especially if this "advice" leads to sweeping incorrect statements that could lead C-level folks to think that an entire class of problems has been fixed when they haven't.  This is a problem :/

The post is here:

It's also a bit old, from December of last year, but @Gentilkiwi (Ben / Author of Mimikatz) recently pointed it out.

And it makes enough mistakes and confuses enough concepts that I felt it necessary to make sure at least one source on the web corrects the misconceptions....

What He Got Right

The author did a decent job in previous blog entries (at least from a skim) of explaining the Kerberos process and has a decent grasp on Golden Ticket Attacks.  I'll also forgive him for not updating the post or referencing in a new post Microsoft's official KRBTGT changing script found here: (blog)

Where Things Go South

So things start getting a little misunderstood talking about Service Tickets.  There's a couple points I would like to make.  Generally speaking : 

1) Service tickets destined for something the target computer deals with (file shares, rpc calls, etc) use the target computer's AD account to sign the service ticket.  The computer account is (by default) changed every 30 days or so and has a long random unicode password.  You in all likelihood will never be able to guess this password.  However, with local admin on the box or physical access, they are trivial to recover.

2) Service tickets destined for a service running as a different account (SQL server, Exchange Server, etc) will use the service account password for that particular service as the signing key for Kerberos requests.  There is a chance you can guess these passwords, since they are service accounts.  Tim Medin's research focuses on getting something to crack offline by creating a fake SPN (service principal name) and requesting service ticket(s) ( / )

Silver tickets allow an attacker to generate arbitrary service tickets when the attacker has the service account hash / password.  PAC validation is disabled by default for accounts running as services.  For more details, refer to one of my previous posts which quotes the official MS specs :

No, MS14-068 Did NOT Fix Silver Tickets

Joe Bialek from Microsoft did a great job of talking about the vulnerability fixed by MS14-068 here:

The short version is that prior to this patch there was an edge case in the Kerberos spec that could allow an attacker with a user account password/hash to modify the PAC and then the KDC would validate it as legit. The end result was an elevated TGT account.  This is completely unrelated to silver tickets.  This was an exploit against Kerberos.

Silver tickets will continue to work with the MS14-048 patch installed.

A Note to the Author

Mr. Green, feel free to reach out to me, @gentilkiwi, or @josephbialek if you need any more clarification.

Saturday, February 14, 2015

Microsoft Finally Releases Guidance and a Script to Change the KRBTGT Account

So Microsoft recently released a zipfile which contains both a document and a powershell script that can be used to change the KRBTGT in a domain.  Before doing anything, RTFM that comes with it and obviously run it in a test environment and make sure that it doesn't eat kittens in your environment...

The basic functionality of the powershell script is that it changes the KRBTGT and it will force replication to update the KRBTGT account and validate that it has replicated.

I haven't (and likely won't ) spend a lot of time on the script itself.  However, one of the things that came up on Twitter from @scriptjunkie1 was that the password being set wasn't using a decent random source, so the password wouldn't be as random as it could be.

However, based on conversations I've had with folks at Microsoft, this password doesn't matter.  This is of course undocumented and honestly, this could potentially lead to problems with clever administrators, however I will get to this a little later...

So, in this case I set up a throwaway Windows 2008 R2 domain controller.  I used Mimikatz to dump the KRBTGT hash.

So, by default, the KRBTGT account has a random 32 byte unicode password assigned to it that is completely unprintable, so it's easiest to just see the hash...

I am using this 8 character complex, yet terrible, password.  If an actual account was set to this, the NT hash would look like the above screen.

Using the 'net user' command, we can set the password for the KRBTGT account, but as you can see above, the hash from setting the password to '1qaz@WSX' is not the same hash from above.  Ok, what happens if we do it again? 

So, the hash changes again.  Even though we set it to the same password, it changes again to a random password / hash.

One thing to note, even though the password is completely ignored, it needs to clear whatever the password policy is in play on the domain.

So, why is this behavior a bad thing?  Well Microsoft's unofficial stance is that they want people to use strong passwords (even though it's completely ignored).  However, a clever administrator would INCORRECTLY believe that they could type in the same password on each DC and shortcut the replication process.

So would this completely brick your environment if you did this? Honestly I don't know.  Late last year @mubix talked about an environment where the KRBTGT was changed on a semi-constant manner and it didn't break the environment.  So (offline) myself and a few others fiddled with it a bit and it looks like that could work, but only because when the tickets are invalidated the credentials that are cached in memory are immediately resubmitted and new tickets are issued.

So what happens if you fsck up the KRBTGT across multiple domain controllers?  Honestly I don't know and don't really have a good way to easily test this. Do you really want to find out in your environment?

Correction 1:

Benjamin Delpy (@gentilkiwi) says that the KRBTGT password is a 32-byte random password (which would actually be 16 unicode chars).  Since he's poked around in memory on DC's far more than I have, I'm going with his answer :-)  Corrected in the post

Saturday, September 27, 2014

PAC Validation, The 20 Minute Rule and Exceptions (BHUSA 2014 part deux)

First off, I apologize for not being quicker about getting this post out.  However, Wasteland 2 came out recently, and I have been playing far too much of it for my own good ;-)

Anyways onto the topic at hand: PAC validation and the various excuses not to check it

What is PAC Validation and Why Do I Care?

 The PAC (Privilaged Attribute Certificate) is a structure contained in a Kerberos ticket that contains a list of privileges that the ticket is representing, along with some other stuff.  If we can forge the PAC we can do things to break the privilege model of Kerberos  in some very interesting ways ;-)

"PAC validation" is pretty much what it sounds like, the service receiving the ticket double checks the information contained in the PAC as being valid before either issuing service tickets (in the event of a Ticket Granting Ticket / TGT) or running the command/request/whatever (in the event of a service ticket being used).

The 20 Minute Rule 

What we're calling "The 20 Minute Rule" is taken straight out of the Microsoft's MS-KILE specification, specifically section 5.1.3 which states:

"Kerberos V5 does not provide account revocation checking for TGS requests, which allows TGT renewals and service tickets to be issued as long as the TGT is valid even if the account has been revoked. KILE provides a check account policy (section that limits the exposure to a shorter time. KILE KDCs in the account domain are required to check accounts when the TGT is older than 20 minutes. This limits the period that a client can get a ticket with a revoked account while limiting the performance cost for AD queries."

So to translate, in the event that the TGT is more than 20 minutes old, the PAC contents are validated to ensure that the account is still valid.  However to flip this around, this means that there's a 20 minute window where the contents ARE NOT validated.  This is one of the primary things we brought up in our Black Hat talk.  As long as you have the KRBTGT hash you can put whatever information you want into the PAC inside the TGT, and service tickets will be issued, as long as the age of the TGT is less that 20 minutes old.  This includes bogus account / SID information, such as a non-existent user being a member of the domain admins group.  Because the information isn't validated during this first 20 minute window, service tickets will be generated that are good for several hours by default.  Additionally, since we can create our own TGTs, the 20 minute rule is never really a problem since we can simply create a new TGT every 20 minutes to get around this limitation.

Other PAC Validation Issues

So obviously, this can lead to some problems, but are there any other examples lurking out there?  I'm glad you asked!

Recently @gentilkiwi and I have been investigating another issue related to a failure of PAC validation that Ben has dubbed a 'Silver Ticket'.   Here's the section of relevant protocol specification from the holy Microsoft MS-APDS scripture Appendix A, Section 1.6.2:

  • Windows 2000 Server and Windows XP do not validate the PAC when the application server is running under the local system context or has SeTcbPrivilege, as specified in [MS-LSAD] section Otherwise, Windows 2000 Server and Windows XP use Kerberos PAC validation.
  • Windows Server 2003 does not validate the PAC when the application server is running under the local system context, the network service context, or has SeTcbPrivilege. Otherwise, Windows Server 2003 uses Kerberos PAC validation.
  • Windows Server 2003 with SP1 does not validate the PAC when the application server is under the local system context, the network service context, the local service context, or has SeTcbPrivilege privilege. Otherwise, Windows Server 2003 with SP1 and future service packs use Kerberos PAC validation.
  • Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 do not validate the PAC by default for services. Windows still validates the PAC for processes that are not running as services. PAC validation can be enabled when the application server is not running in the context of local system, network service, or local service; or it does not have SeTcbPrivilege, as specified in [MS-LSAD] section

So, in general older versions of Windows don't validate the PAC when the process is running as SYSTEM or has the "SeTcbPrivilege" (Act as part of the operating system) privilege set.  Newer versions (Vista+) don't check the PAC for services. 

So, how is this useful?  Well, pretty much anything that you could want to do to a computer remotely is a service, such as access a file share, schedule a task, execute code, etc...

So, for Kerberos, services by default don't validate PAC settings... What could possibly go wrong here?  But wait! There's more!

Service Tickets and Kerberos 

The obvious question now arises, what do we need to issue a service ticket for a particular service?  How can we take advantage of this?

Service tickets SHOULD be issued by a TGS after getting a TGT and should be between 2 Kerberos principals.  So for example, if Bob wants to access a file share (CIFS) on ServerA, Bob would ask the TGS to give him a ticket for user CIFS@ServerA.  The TGS would then give Bob a ticket that he could present to ServerA that would give him access to the CIFS service.

With TGTs, the piece destined for the TGS would need to be signed by the KRBTGT account, the central account for trust to validate that the ticket is legit.  However, for service tickets, the target account is on the computer itself.  What is the long term secret key?  

In short, it depends.  For all services that run as System on the computer, it will be the computer account from AD.   If the service is operating as a particular user (typically like Sharepoint, Exchange,  MSSQL, etc...) it will be that account. 

Recovering the computer account is relatively trivial with physical access (think boot disk, grab the registry, decode at whim) and if you can run as admin, it's trivial as well...  If you can guess the service account password for a service that runs as a different user, that will work too...

Now, all you have to do is use Mimikatz to generate a Silver Ticket for the service and away you go...  an example that Ben posted to twitter can be seen here:

Since service tickets are identical in format to TGTs albeit with a different service name, all you need to do is specify a different service name and use the RC4 (NTLM hash) of the account password (either the computer account for default services or the actual account) and you can now issue service tickets for the requested service.  Note:  You can also use the AES keys if you happen to have them instead of the NTLM key and it will still work ;-)

It is worth noting, that services like MSSQL, Sharepoint, etc will only allow you to play with those services.  The computer account will allow access to CIFS, service creation, and a whole host of other activities on the targeted computer.  You can leverage the computer account into a shell with PSEXEC and you will be running as system on that particular computer.  Lateral movement is then a matter of doing whatever you need to do from there :-)

My next post I will perform some demos with screenshots, etc...  Stay tuned!

Thursday, August 21, 2014

Mimikatz and Golden Tickets... What's the BFD? BlackHat USA 2014 Redux part 1

So a couple weeks ago Benjamin Delpy (@gentilkiwi on twitter / author of Mimikatz ) and myself presented at Blackhat USA and, in a somewhat impromptu manner, the Wall of Sheep at DefCon as well...

The updated slides (from the WoS talk) can be found here:

Quick Oversimplified Kerberos Refresher

IF you read all the links on Kerberos there's talks about TGTs, service tickets, principals, etc... I want to present just a simple way to quickly visualize what's going on with Kerberos.

Imagine yourself as a kid.  Mom needs to pick up a gallon of milk and the dry cleaning but needs to wait in the car for whatever reason. Fortunately, the cleaners and 7-11 are right next door to each other.  She hands you her credit card and tells you to go get the milk and then the dry cleaning and get back to the car.

You walk into the 7-11, grab the milk, hand the credit card to the cashier and he lets you leave with the milk.  You then walk into the dry cleaners, tell them you're there for the pickup, hand them the credit card and you walk out with some shirts as well. 

In this highly oversimplified example, the credit card is how you gain access to the services of the convenience store (the milk) and the dry cleaners.  You don't understand how the card works, only that you show it to the cashiers and they allow you to leave with the items.

TGT (Ticket Granting Tickets) operate in much the same way.  When a kerberos principal (somebody who wants to access a service protected by kerberos) authenticates to the KDC, they provide their username and password and get a TGT in return.  This TGT operates in much the same way the credit card does.  Whenever the principal wants to access a service, they submit their request along with the TGT and based on the privileges contained in the TGT, the request will either be granted or denied.

The nice thing about this TGT is that it is valid for a period of time.  This means that the user doesn't have to get prompted for their password for a period of time.  The TGT can simply be passed on and reused until the ticket expires.

Why Does the Domain Trust the TGT?

So what grants the TGT its mystical powers?  It's because part of it is encrypted using the NT  hash of the KRBTGT account and the other part is encrypted by the NTLM hash of the principal requesting it.  

This means that in order for it to be legit, 2 different principals have to agree that it's legit.  In essence, each side of the conversation has some assurance that the other side is who they claim to be since "in theory" the only way the TGT could be valid is that both sides can read their part.

This is where Mimikatz comes into play.

So How Old is the KRBTGT on Your Network?

If we have a complete hashdump of the domain, then we have the password hash for the KRBTGT account.  Additionally, this account seemingly never changes its password.  The only instances where folks have reported that it changes is when the domain functional level changes during an upgrade, a point I will touch on in a sec.

So,  for example, this is from my demo domain from 2012 that is still up and running that I use to test PTH tools against:

Note that the password for the KRBTGT hasn't changed since March of 2012.  This is about the time I set the domain up to begin with.

So that means that regardless of the password policy in place on the network, this account has NOT changed its password in over 2 years.  Just in case you're wondering what your network looks like, try running "net user krbtgt /domain" from a command prompt on your local network.

So, when does this hash / password change?  There is only one circumstance where this password automatically changes.  The password for the KRBTGT account only changes when the domain functional level is upgraded from a NT5 version (2000/2003) to a NT6 version (2008/2012).  If you move from 2008 -> 2012R2 domain functional level, this hash won't change.

This hash can also be manually changed in a working AD, but this will cause all sorts of "Bad Things(tm)" to happen to your network, namely all Kerberos tickets will simultaneously die and in all likelihood demons will be summoned and a lot of puppies and kittens will be killed.  Not to mention Sysads.

Seriously though, this process is as of right now unsupported by Microsoft and there has not been any official documentation regarding how this should take place and what the effects will be.  This will be forthcoming in the "Not Too Distant Future(tm)" as well, so keep an eye out for that.

So, the net result is that your KRBTGT account is only as old as your transition from a NT5 domain funtional level to NT6.  If that happened back in 2008, then you hash is at least 6 years old.  If you are still on a 2003 domain, then it is even older.

Assume that "N" is the amount of time since the KRBTGT account has changed.  Ultimately, if you have a password hash dump somewhere on your network from something less than N years ago, then the KRBTGT account could have been compromised. (Of course, said password dump could also be on pastebin too and archived by Google...) If you have a poorly configured backup of a domain controller on your network from less than N years ago, the KRBTGT account could have been compromised.  If there's an old domain controller that has been decommissioned but is still in your virtual machine library, ditto.  If there was a poorly redacted  pentest report showing the first few lines of a hashdump, ditto... and the list goes on....

So, what's the BFD with this account?

The bottom line is this : If somebody has compromised the KRBTGT account and they have the domain SID (Security Identifier) for your domain, they can generate a ticket that can impersonate any user and put them into any group.  The users do not need to be enabled or even exist in the domain and they can still be put into the highly privileged groups in the domain, such as the domain or enterprise admins.

So, this is definitely a Big Fscking Deal.

Well touch more on this in the next post.

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: