Tag Archives: windows 10

Windows 10 Authentication: The End of Pass the Hash?

Windows 10 Authentication: The End of Pass the Hash?

Over the last year, Microsoft had been dropping lots of hints it would be reworking its authentication system in Windows 10. Multi-factors, support of FIDO, and the use of virtualization technology to secure credentials were all slated to be in its latest and greatest OS. With the general release of Windows 10 late last month, we now get to see what’s in the sausage.

Hardened Authentication

For starters, you should read the July 28 announcement on their blog. In the very first bullet point, they announce Windows Hello, which is Microsoft’s take on password-free authentication, using either facial, thumbprint, or iris recognition for validation. Hello will support the FIDO open-standard as well.

Also in that first bullet point is a reference to something called Credential Guard. It’s described as a way to “protect corporate identities by containing them in the hardware-based secure execution environment.”

Ok, Credential Guard must be using the virtualization technology they had been yakking about for the last few months— for example, see this presentation by Microsoft’s Nathan Ide at this year’s RSA conference.

To find out more, I searched the TechNet portion of the Microsoft website and came across this overview article on Credential Guard. As I read more, it was beginning to look like this was the long awaited PtH messiah.

For those who’ve been following along with us, Pass the Hash (and Pass the Ticket for Kerberos) is a way for hackers to directly exploit user credentials that are kept in memory. The hash of the password — remember hashing? — is at the core of Windows NTLM challenge and response authentication protocol.

If you have the hash, it’s the same as having the password: you just pass or feed it into the NLTM protocol to gain entry. Once inside a system, hackers love PtH because they don’t have to crack hashes to take over a user’s identity.

Great news, for hackers. So how do they get the hash?

The answer: Windows keeps hashes in LSASS memory, making it available for Single Sign On or SSO. In an SSO environment, the computing world most of us live in, you enter passwords once when logging in to your corporate laptop. When you need to access other services, Windows just dips into LSASS to pull out the credential — the hashed password — so you don’t have to re-enter it.

It’s a user convenience that we all take for granted, but it has the side effect of giving hackers a huge opening to exploit.

Pen test tools like Mimikatz, for example, access LSASS memory, thereby allowing cyber thieves to pull out credentials (preferably of users with elevated privileges) and take on multiple identities as they traverse the target system.

Bottom Line: Hashes Will Be Really Hard to Get

Mr. Softee has known about PtH for many, many years. To its credit, it sort of recognized the problem and has given very good advice on how to reduce the risks of credential stealing — see this paper.

cred-guard-security

Source: Microsoft

And that’s where Credential Guard finally comes in. In Windows 10, the designers reworked the LSASS process so that it lives in its own virtualized container. Yeah, it’s using similar ideas and techniques to those found in virtual machines that enable a host operating system to run various guest operating systems.

These guest operating systems are sort of like their own min-universes, separate from each other, except through some well-defined worm holes — I’ll get to that in a second.

So what’s going on in Credential Guard?

Last month at Black Hat, Microsoft heavy weights, Seth Moore and Baris Saydag, gave a presentation, Defeating Pass-the-Hash, that explained the implementation details.

It gets gnarly, but the LSASS address space is now really, really separated from other user processes so that apps like Mimikatz can’t peek into it. You’ll have to read the paper to understand the fine points — note the use of the words hypervisor and ring levels.

But here’s the speedy executive overview based on my current understanding. The developers left the LSASS programming logic intact to continue supporting credential processing as before. The memory space, though, is walled off from other apps with Credential Guard acting as the gateway.

Neat Wormhole Technology

System and other apps, of course, still need to verify the credentials of users, but now they do so through a well-protected and authenticated connection to Credential Guard. So you can think of Credential Guard as the guardian of the wormhole between its special memory space and everything on the other side.

I know this post is starting to sound like Interstellar. Nevertheless, the technology is quite interesting and really does seem to finally close off PtH.

I’d like to think that Pass the Hash will eventually become a problem of the past as companies migrate to the Windows 10 Enterprise Edition — the only version that Credential Guard runs on.

Of course, you shouldn’t discount hackers’ power to find weaknesses and zero-day exploits.

So the wiser security view to take is that the cost to play Pass the Hash has gone up immensely. It may still be possible in the future, but it will require a far more sophisticated effort than is currently the case.

Windows 10’s Security Reboot, Part III: FIDO and Beyond

FIDO’s Universal Two Factor (U2F) is intended to make it easy for companies to add a strong second factor to their existing crypto infrastructure. Most of us are probably not ready to leap ahead to the password-less Universal Authentication Factor (UAF), which I touched on in the previous post in this series. So U2F is a comfortable half-way point that still leverages FIDO’s strong crypto technology but allows employees to continue with their more familiar password entry habits.

U2F is an ambitious initiative to raise the overall authentication bar for everyone. Rather than just another proprietary approach, U2F is instead an open-standard with its own ecosystem supported by browser vendors and device makers.

It has a major advantage over current schemes in that it addresses a serious flaw with current implementations of two-factor authentication (TFA).

What’s the issue with vanilla TFA?

It’s actually vulnerable to straightforward man-in-the middle attacks. Typically an attack would be initiated through a phish mail.

Phishing for Factors

Let’s quickly review TFA. In addition to asking for the password–what the user knows–it also requires something they have: say, a cell phone. For example, when logging into a TFA-based web site, the user is asked to enter an additional one-time password (OTP) that’s then sent as an SMS. The OTP is often a short numeric string with a limited lifetime.

A clever hacker simply has to set up a fake web site that looks like the target—for argument’s sake, an overnight delivery service. A phish mail could be sent to employees in a large company asking them to, say, verify a delivered package by clicking on a link to the phantom site.

In standard man-in-the-middle fashion, the hackers now simply forward the password to the real site, triggering the OTP. When the user enters the OTP, it too is forwarded to the real site, giving complete access to the hacker.

Mission accomplished.

U2F Makes it Hard

U2F does it differently. It takes full advantage of the public key crypto that I talked about last time. Like UAF, it uses the public-private key pairs, which are initially registered for the device on which the second factor is based.

Bottom line: U2F provides a convenient way for companies to boost identity verification without having to add fancy biometric techniques.

Vendors have already introduced FIDO compliant dongles—essentially a USB drive on which has the private key is stored. Just around the corner, smart phone vendors will soon be able to support the FIDO standard through Near Field Communications (NFC) technologies.

Here’s how it all works.fido auth u2f

When users log on to a U2F-supported website or corporate portal, in addition to entering their password they’ll be asked to insert their FIDO dongle into their laptop or device. When smart phones start supporting FIDO, users will place or swipe their iPhone and Androids near the laptop’s NFC reader.

Anyway, the dongle is then asked to sign a random string that’s concatenated—and this is crucial—with the URL of the web site asking for the information (see the diagram).

When this signed credential is sent back to the website, it is decrypted. If the random string matches, then the user has proven himself. And if the decrypted URL matches what the user was expecting—i.e., the address of the website verifying the second factor—then the website is authenticated as well.

Not Perfect, But …

Sure, U2F requires support from Chrome, Firefox, and other vendors to pass URLs to the dongle. And no, it’s not a foolproof solution, but you can see how it eliminates man-in-the-middle attacks.

If a fake site passes the credential to the authenticating server of the real site, it would be rejected! The fake site’s phishy URL (www.fed3x.com), when decrypted, couldn’t possibly match the URL of the real site (www.fedex.com).

This is a very good solution!

While there are some potential weak points, U2F should close the door to low-skilled hacks and could eliminate many, many breaches.

No doubt hackers are working on malware that can get around U2F’s strong security—possibly some clever keylogger that embeds itself on the user’s device. It also wouldn’t surprise me if some presentations at this year’s Black Hat conference start suggesting possible hacks. We’ll see.

Nothing in Windows 10 Is Nailed Down

While I was hoping to end this post with a discussion of another intriguing Windows 10 security improvement, a more serious effort at addressing data loss prevention (DLP), I’ll have to punt. There’s even less information available on this than on the authentication improvements I’ve been discussing.

Of course, none of us know how any of this will be implemented because Windows 10 is about a year away from a general release and features are, as Microsoft has noted, “subject to change.”

While I am cautiously optimistic that some of the worst abuses of Windows authentication hacking will soon end, the realist in me says new hacks are in the works.

Windows 10’s Security Reboot, Part II: More on Authentication

Windows 10’s Security Reboot, Part II: More on Authentication

A good part of Windows 10’s security improvements center on basic changes to the way users and software prove their identities. No, that wasn’t a mistake in the last sentence. Software, like, people, also can have an identity and be required to show they’re the apps they say they are.

The underlying technology is well established — it’s the same public key infrastructure (PKI) and certificates that are used all over the Internet.

We’ve all indirectly run into certificates when surfing to a site requiring https, the secure version of the underlying web protocol. Who hasn’t seen the pop-up asking whether you want to accept a site certificate?

Certificates and Identity

What’s a web certificate? It’s a really bunch of text attesting that you’ve landed on the right URL. The text and associated fields have been digitally signed by a trusted certificate authority (CA) using the private key of a public-private key pairing.credential

(Here’s a great overview of how public-private keys work to implement a signature. In brief: unlike symmetric encryption, the keys are different and each can decrypt what the other key encrypts. To create a signature, you encrypt known text with the private key and then the receiver decrypts with a public key that everyone has access to.)

If you’re dying of curiosity, you can view a certificate for yourself by clicking on the lock icon that appears in the address bar.

Why can’t we have the same proof of identify for native apps as we do for webified ones?

Trusted Software

No reason at all! Mobile device makers have been using a similar signing feature for years. For example, I can’t just load any app onto my iPhone or iPad: it’s only those apps that come from the online Apple store and have been digitally authenticated. Microsoft does the same thing with its online app marketplace.

In general, using a signing process has helped greatly reduce, but not completely eliminate, mobile malware. Yes, some evil does slip past the online store guardians, but their track record has, overall, been very good.

Taking a cue from mobile software, Microsoft is introducing a trusted app environment in Windows 10, with the power to lock down and force devices and servers to use 100% authenticated software.

This makes great sense (and has been a long time coming), but it will be something of a culture shock for admins and users who are in the habit of downloading what they want. However, this anything-goes policy came with a heavy price:  hackers never really had to worry that their APTs wouldn’t load when users opened files attached to phish mails.

In theory, signed apps would have stopped all the evil malware software behind the recent breaches in the big box stores, banks, and healthcare organizations.

More PKI Integration: User Credentials and FIDO

Yes, Microsoft will allow you to self-sign internal apps so companies can continue using existing software. And sure, hackers will always find ways to subvert this — they’ve been able to infiltrate some of the certificate authorities to create forgeries — but this is a large improvement over the current ad hoc approach to app security.

Microsoft is taking a similar approach to user credentials. We know from Jim Alkove’s post that Windows 10 will start the break from pure password-based authentication.

Just like with apps, users will also have a digital credential based on private-public keys. Organizations can use the PKI from a favorite vendor or choose Microsoft’s — it won’t matter.

Here’s the huge payoff: users won’t have to enter a password!

Microsoft is part of the Fast Identity Online (FIDO) Alliance and is incorporating their open-standard password-less authentication protocol in Windows 10.

In brief, users first establish public-private keys for each smartphone, tablet, and laptop, registering the public keys with Active Directory. When they access a device, they’ll first interact with an authenticator—say a fingerprint or voice recognition analyzer. If they succeed, they’ll use a simple 4-digit pin or some other mechanism as a second factor.

Ultimately, the device is asked for a signed credential to prove ownership of the private key.

FIDO is actually more complicated than what I just described. So I’ll continue talking about it in the next post, and also discuss other planned improvements to data security in Windows 10.

Image credit: Fido Aliance

Windows 10’s Security Reboot, Part I: Authentication

Windows 10’s Security Reboot, Part I: Authentication

There’s incredible excitement about the Windows 10 release. If you completely quantum leap over Windows 9, you’d expect big things. In December, I was talking with NYU-Poly’s Professor Justin Cappos. He’s a security expert and had nothing but high praise for Microsoft’s security group. But he added their cutting-edge research doesn’t necessarily make it into their products.

With Windows 10 officially launched in January, it looks like the security researchers have finally gotten their way.

The End of Pass the Ticket and Pass the Hash?

While Cortana and HoloLens may have stolen the show at the launch event, the other exciting news–at least for us security geeks –is that Microsoft is planning a complete revamp of its rusting security infrastructure.

Jim Alkove, the Windows 10 product manager, gave us all a heads-up about what to expect in a post  he published back in October. That was also about the time that Microsoft released the Windows 10 Technical Preview, which you’re free to download and try out on a spare PC or in a virtual machine (VM).

In my next few posts, I’ll take up some of the major changes in authentication and data security that are currently slated. The caveat is that none of this is completely finalized. The official release of Windows 10 is year away.

In any case, Alkove says that Windows 10 “aims to eliminate” — long pause — Pass the Hash and Pass the Ticket.

Loyal Metadata Era readers know that we’ve dived somewhat deep into the PtH and PtT waters.  And we’ve also written an ebook covering these two hash stealing approaches as well as other attacks used against Microsoft’s NTLM authentication protocol.

For those just tuning in, the key point is that both Windows and Linux never store plain-text passwords. That’s just Security 101. Instead they perform a one-way encryption of the password, known as a hash, and keep that instead. By all means, read Rob’s hashing post.

Unfortunately, in Windows, the password hash is equivalent to the password in terms of the power it gives you—the fancy crypto-speak for this is plain-text equivalent. In other words, hackers who are able to get inside a Windows system—and that’s easily accomplished through phishing—just need to collect password hashes to masquerade as other users.

Where do they find these hashes? Windows keeps them around in the Local Security Authority Subsystem Service (LSASS). Essentially, they’re stored in memory on a user’s laptop or desktop device.

Containers Are the Answer

Having these powerful password hashes on users’ machines instead of storing them in a safe central location is a feature (not a bug) of Single Sign On (SS0). With SSO enabled in most organizations, Windows can reuse the password hash in LSASS—remember, it’s equivalent to the password—without inconveniencing the user.

Hackers have been very effective at exploiting this feature of SSO. Using malware such as mimikatz, they’re able to easily scoop up the hashes from memory, effectively stealing user credentials without having to know the password itself.

With Window 10, though, Microsoft hopes to stomp out these tools by placing the hashes in a walled off part of memory–technically they’ll put the LSASS in its own VM.

Microsoft, of course, has developed a VM technology, known as Hyper V, and in this latest Windows version, it looks like they plan to take more advantage of it.

It’s way too early to say whether this approach will succeed in blocking Pass the Hash and Pass the Ticket—the devil is always in the implementation details.

We’ll continue with our overview of Windows 10 security in our next post, where we will take up other authentication changes. This includes multi-factor authentication, tighter integration with enterprise PKI, and we’ll learn about FIDO and security ecosystems.