The Data Protection API (DPAPI) provided by Windows is a way of protecting secrets used by a lot of popular software solutions, most famously by Google Chrome when storing passwords and cookies. A lot has been said over the years about the security of this API, but new versions of Windows 10 added a new convenience feature called TBAL that further undermines this protection. Basically, when you have access to the disk of of a computer that is not joined to a domain and has been shut down properly, you have everything you need to decrypt all DPAPI secrets of the last logged-in user. With earlier versions of Windows 10, the data necessary to decrypt DPAPI secrets was (almost?) never stored on the disk, most certainly not on every shutdown.

I work as an ethical hacker at DCIT, a Czech company that focuses on corporate security. This research was conducted during work hours, with tremendous support from both colleagues and superiors.

Disclaimer: Most of the information found in this article was discovered through reverse engineering, either by us or by other people. Reverse engineering is a lot of guesswork and assumptions. Even though we provide all information in good faith, the information is provided “as is” without warranty of any kind, either expressed or implied, including limitation warranties of merchantability, fitness for a particular purpose, and noninfringement. 

DPAPI 101

The DPAPI is the simplest API you can imagine: it’s basically just a pair of functions, CryptProtectData and CryptUnprotectData. That’s probably why it’s so popular with developers – if you are fine with it being a black box, it’s very simple to use. Just take a buffer, send it to DPAPI, and it returns a blob. You store that, and you’re done. No key management; no choosing the correct cryptographic algorithms for the job; it just works.

For this article, we will investigate only the top layer of DPAPI – if you’re interested in more details, we strongly recommend the DPAPI and DPAPI-NG: Decrypting All Users’ Secrets and PFX Passwords talk from Insomni’hack 2018 by Paula Januszkewicz.

DPAPI uses a Master key, and as the name suggests, this key is basically all you need to decrypt all other secrets. Obviously, this secret key can’t just be stored on the disk in its raw form for anybody to grab, so it is encrypted with a hash of the user’s password.

If you know anything about Windows security, you have probably heard of the NTLM hash, which is an MD4 hash of the password. This hash is used for almost everything in Windows, including authentication. When you are logging in, Windows calculates the NTLM hash of the password you typed in and compares it with the NTLM hash that’s stored in something called the SAM file. So, for obvious reasons, the NTLM hash has to be stored on the disk, otherwise Windows wouldn’t have a reference to compare it with. This is important, as if you only used the NTLM hash to encrypt the master key, simply grabbing it from the SAM file residing on the hard disk would be enough to decrypt every single secret that is protected by DPAPI.

According to Passcape Software’s research paper, “DPAPI Secrets. Security analysis and data recovery in DPAPI”, the first implementation of DPAPI actually used NTLM hashes, and it was such a major issue that Microsoft quickly changed it:

The decryption of Master Key in the first implementation of DPAPI required the NTLM hash of user’s password. That was a major: No, that was the greatest blunder of DPAPI developers, which negated the security of the system. All because it technically allowed a potential malefactor to decrypt the Master Key and, consequently, any DPAPI blob by getting the NTLM hash directly from the SAM file; the actual password was not even necessary! In the second, current version of DPAPI, that error was fixed; now Master Key is encrypted using the SHA1 hash.

So, in all implementations of DPAPI from XP onward, the Master key is encrypted using SHA‑1(UTF16LE(user_password)). This is actually a pretty clever solution to the problem: use a different hash of the same password (domain-joined users actually still use the NTLM hash, but that’s out of scope for this article). As long as the hashing algorithms used are good enough and the SHA‑1 hash never gets stored on the disk, the easiest way of getting the SHA‑1 hash is through bruteforcing the original password corresponding to the NTLM hash that’s stored there. This leads to a situation where (when the computer is off) your secrets are as secure as your password is strong.

This is actually a good solution to a few different attack vectors. If you have write access to a disk, it’s easy to modify the SAM file and effectively reset the user’s password and then log in. Windows calculates the NTLM hash of the password you typed in, compares it with your modified SAM file, and as it checks out, you get logged in. However when it calculates the SHA‑1 hash of your new password and tries to decrypt your master key with that, it obviously fails, as you have changed the password (when you change the password in a regular way, some data has to be decrypted and reencrypted to keep your access to it).

ARSO and TBAL

Windows 8.1 quietly introduced a new feature called Automatic Restart Sign-On (ARSO). There’s not a lot of documentation available about it, only this Microsoft docs page. Although we strongly recommend reading the linked document, it basically boils down to this:

After a Windows Update induced reboot, the last interactive user is automatically signed on and the session is locked so the user’s lock screen apps can run.

This means that user credentials have to be stored on the disk to be preserved during the reboot. And to fully restore the user session, not only the NTLM hash, but also the SHA‑1 hash have to be preserved. However, this feature was implemented very cautiously: one of the requirements listed in the documentation is Can only be enabled if BitLocker is enabled. Therefore, when this feature was introduced, your SHA‑1 hash could get stored on the disk, but only on a Windows Update initiated restart if BitLocker is enabled. As long as your BitLocker setup was secure, your hash was technically secure.

But with Windows 10, Microsoft was silently pushing this feature forward with each update, removing more and more restrictions in the name of convenient lock screen apps including Cortana. This feature was also renamed TBAL, the explanation of which is nowhere to be found (we guess AL stands for AutoLogon; no idea about the TB). We weren’t able to find any comments on the security aspects of ARSO, and for TBAL, the internet doesn’t seem to have any information whatsoever.

How does it work? When somebody asks lsasrv for the so-called TBAL provisioning, lsasrv checks whether the account is an offline one or an MS account, and then, based on that, asks either the msv1_0 or the cloudAP security provider to store everything it needs to restore the user session to the disk. After that, it sets up the autologon mechanism that’s been in Windows since at least NT4, with the hardcoded password of _TBAL_{68EDDCF5-0AEB-4C28-A770-AF5302ECA3C9}.

After booting, the autologon mechanism kicks in, and tries to login to your user account with the TBAL password. The security package sees this special password, so it deserializes the stored credentials, and pretends that this password actually has worked, and then your session gets locked as if you  had immediately pressed Win+L (this is actually a simplification, there are a lot of complex hacks that make this possible, but we describe the observable behavior). The stored credentials then get removed from the registry. However, the credentials of the last logged-in user before reboot stay loaded in memory even when a different user logs in after reboot. Any (admin) user can dump them using ordinary methods like mimikatz.

Where do the security packages store their serialized credentials? In the registry, specifically in a storage commonly called LSA secrets, which is encrypted using the BOOT key (in a very obscure way). There are tools readily available for decryption of these secrets, as will be shown in the PoC. Specifically, we’ll focus on msv1_0’s secret, which is called M$_MSV1_0_TBAL_PRIMARY_{22BE8E5B-58B3-4A87-BA71-41B0ECF3A9EA}. This LSA secret contains the NTLM and more importantly the SHA‑1 hash of your password, a.k.a the secret necessary for decrypting DPAPI’s Master key. The structure of the said secret is the following:

From some basic reverse-engineering we’ve done on the various Windows 10 versions, we believe this is how the scope of TBAL was slowly expanded:

• 1507: TBAL provisioning on every reboot, but available only for MS accounts and enabled only when OSVolumeProtected (probably BitLocker)
• 1607: TBAL added for non-MS accounts
• 1709: TBAL doesn’t require BitLocker anymore

Proof of concept attack

First, we start by installing a clean Windows 10 1803 VM, setting it up with a local account and opting-out of all the voluntary telemetry. After that, we just install Chrome, store a password in it, and shut down the computer. After that, all steps are taken strictly against the VM’s disk. We simply mounted it to the host machine using VMware, but if it were a real computer, imagine physically connecting the HDD to your machine.

Then, we used creddump7 to dump the LSA secrets from the disk. As you can see, TBAL was provisioned, so the Default password is set to the TBAL magic string. As this is a local account, we can see the serialized credentials and grab the SHA‑1 hash from it.

Afterwards, we switch to mimikatz. First, we show you that without decrypting the masterkey, we can only read out the stored username and not the password. After that, we use the dpapi::masterkey command to actually decrypt the masterkey from the VM’s disk using the SHA‑1 we retrieved in the previous step. As mimikatz automatically caches all masterkeys it has decrypted, just running the same dpapi::chrome command again reveals the password in plain sight.

Mitigations & remaining questions

This threat is easily mitigated by disabling ARSO and TBAL with a group policy or a registry setting (reportedly, the ARSO policies mentioned in the Microsoft docs page also work for TBAL). If you don’t want to lose the convenience these features provide, full disk BitLocker should probably protect you as well.

There are still some questions we don’t have answers to and would love to continue looking into them more:

• What data is serialized for Microsoft accounts?
• How does TBAL work in a multi-user scenario?
• Is TBAL completely disabled in domains?
• Can’t the fact that security packages accept the fake password be somehow abused? If we managed to login with it interactively without getting the session locked, that would be very serious.

Conclusion

In this article, we have demonstrated that in some scenarios, the default Windows configuration leads to the SHA‑1 hash of the user’s password being stored to the disk in a way that is retrievable without any further knowledge about the password. We argue that this is an issue for DPAPI, because if the secret necessary for decrypting the master key was to be stored on the disk by design, Microsoft could have kept on using the NTLM hash it uses in domain settings (and supposedly used in the first implementation of DPAPI). We then demonstrated how this attack can be executed using readily available tools.

Feel free to comment or @me on twitter!

DISCLAIMER: Everything you read in this article is what I personally believe is happening. Since reverse-engineering is basically guesswork at some points, I can be wrong about pretty much everything. If you do find some mistakes, please, tell me in the comments.

So let’s dive into it!

FrisbiiU.rpx

This is the least interesting part of the whole Wii VC. It just displays the fancy banner on boot and takes care of showing the manual. Note that this binary doesn’t even do the “This game supports the GamePad” prompt – the Wii U menu does that (based on the meta.xml), and just calls CMPTAcctSetDrcCtrlEnabled with the result, but more on that in nn_cmpt.rpl section. For all the rest, it calls the included nn_hai_user.rpl library.

nn_hai_user.rpl

Now first, let me make something clear. Hai is the most used codename around all the Wii Virtual Console stuff. Actually, it is used in so many places, that I will be differentiating between the various parts it consists of.

This library loads all the /vol/content/hif_XXXXXX.nfs files, merging them one after another. It also does some basic checks on them (like correct length and padding), and asks the MCP to store them to a Hai Companion File, which MCP stores at /vol/compat_slc/shared2/sys/hai/imginf.bin. So, after this library is done with its job, the imginf.bin should be the nfs files merged (needs confirmation). It then calls the first system library nn_hai.rpl.

nn_hai.rpl

This library also doesn’t do a hell lot work – basically it just makes sure your Wii VC games will be in the daily log. For the rest, it calls nn_cmpt.rpl, another system library.

nn_cmpt.rpl

This is the most important library of them all. It has all the exports that allow you to launch vWii mode. What’s interesting is that there are two ways of launching it – through ‘old’ calls and through ‘Ex’ calls. They are similiar in some ways, but different in others (needs more research, sorry). This one prepares a complete configuration file for the MCP – what video output should the vWii use, what it should it load when it starts (Menu/DataManagement/a custom title/a dol file?), what will its nickname and internet settings be etc. This is the library that is also called when you just launch Wii Menu from the Wii U Menu, while everything we had so far was Hai-specific.

Now let’s transfer from the PPC to ARM, and let’s go to MCP.

MCP

The MCP (a kernel module, /dev/mcp) takes care of all the steps remaining before the Wii U can be rebooted and become a Wii. It supports three different types of launching (defined at 0x050623C0), and loads files according to that:

• ‘Regular’ launch: Loads just OSv0’s c2w.img and font.bin
• ‘Dol’ launch: Loads OSv0’s c2w.img and font.bin and then a mystical fw.img, boot.bin and App.dol. This doesn’t seem used anywhere, and I haven’t played with it.
• ‘Hai’ launch: Loads OSv1‘s c2w.img and boot.bin, OSv0’s font.bin, and /vol/system_ram/es/fw.img.

Also, if it is in hai mode, it prepares so called “Hai params”, and stores them at 0x402000. These Hai params also contain a setting if the GamePad should be used. They also contain the key read from htk.bin and some other stuff. After everything is set in its proper place, it reboots the Wii U.

OSv1

Now I’ve seen a lot of confusion about this (and also OSv0). This is just a bootloader. It doesn’t do any gamepad magic. There’s no “running games using OSv1”. OSv0 and OSv1 both just set up some hardware, move stuff a bit around in the memory, and then jump to code that was prepared by the MCP. What’s the difference between OSv0 and OSv1? The OSv1 checks 0x402000. If it finds the letters “Hai” there, it recognises the Hai params, and copies them to 0xFFFFF000, where the Hai IOS can later see it. It also sets up some hardware a bit differently (MCP_HWSetCompatMode).

Hai IOS (a.k.a. the fw.img)

Now this is the most integral part of everything. It is a full-blown IOS, just written for the Wii VC specifically. There are several versions included in various Wii VC releases (I know about three), but they are all universal. As in, there are just updates of the same thing. It consists of several modules, but there are two main interesting ones: OHCI1 and DI2SD.

OHCI1 emulates the WiiMote when gamepad controls are enabled. It reads data coming from the GamePad (over a special I2C bus), and converts them to simulated bluetooth messages. This code can be easily modified to emulate things different than the Classic Controller (Proof of Concept).

DI2SD is what it says: it emulates the disc interface. Even though it has “2SD” in its name, it seems it can load data from pretty much everywhere. This is where the EGGS header is parsed. This is where decryption takes place.

I hope this article helps to clear up some of the confusion around Hai!

Interesting exports

When comparing DLL Exports of 10240 and 10514, I noticed three new interesting exports. To be precise, they were CreateEnclave, InitializeEnclave and LoadEnclaveData from the kernel itself (kernel32.dll). These are definitely new, as neither 10240 for Desktops and for Mobiles had it, but both 10512 and 10514 already do. So what are these enclaves exactly?

A bit of disassembling

After installing the Windows SDK, doing live kernel debugging, kernel debugging over serial, kernel debugging over network, trying to dump memory, actually dumping memory, and then finding out there is a simple app that does dump the SSDT automagically (interestingly called NoVirusThanks SSDT View) and unlike my previous attempts actually works, I finally figured out where these exports (after a syscall) lead to. And what a surprise.

While the x64 Server binary had a lot of pretty complex assembly going on, the ARM version was way simpler.

ARM CreateEnclave

PUSH.W {R11,LR}
MOV R11, SP
LDR R0, =0xC00000F4 ;STATUS_INVALID_PARAMETER_6
POP.W {R11,PC}

ARM InitializeEnclave & LoadEnclaveData

PUSH.W {R11,LR}
MOV R11, SP
LDR R0, =0xC0000018 ;STATUS_CONFLICTING_ADDRESSES
POP.W {R11,PC}

As you can see (even if this is your first time when it comes to ARM assembly), the implementations are very dumb ones – they just return an arbitrary error code immediately, without doing anything serious. The x86_64 variants are however much more complex and actually implement stuff, so I won’t be going into further detail here.

Intel inside

So now we know that the enclaves are somewhat x86_64 specific, giving us a better idea what to google alphabet for. Soon, you’ll get to Intel® Software Guard Extensions (Intel® SGX). This set of new instructions enable the kernel to create an ‘enclave’. What is it good for?

If you don’t have a good understanding of what is kernel space and user space, I advice you to watch a great video on User Mode Isolation on Channel9 and then come back.

Until now, kernel mode was the “good guy”, while user mode was all these buggy, insecure apps. That’s why most of the focus was on isolating applications running in the user mode from one another, so your music player can’t touch memory of your browser with internet banking open.

As you can see, every App has its own box and can’t access any other box. (It can, but it requires more effort and an approval of the kernel). However, what exactly is in this green “trusted code”? Turns out, it’s not just the operating system, it’s also drivers.

Problem is, these drivers are potentionally dangerous. Not only the unsigned ones (we all clicked “Install and continue”, didn’t we?), but also the tested and WHQL certified ones can have bugs and security holes. However, that dashed line between user mode and kernel mode provides no security whatsoever. If my sound driver wanted to touch the memory of any of my running applications, it could. And that’s where enclaves come to play.

Think of enclaves as a small witness protection program. You lock the witness up, but mainly because you want to protect it from evil doings of somebody else. Here, the witness is your application and the evil is kernel mode code.

How does it work in practice? When you run an application, the kernel mode creates an enclave, fills it with the application code, locks it and tells the processor to run it. From the point it is locked, kernel mode can’t read or modify the application’s memory at all – it’s protected by hardware.

Conclusion

Yes, I know, it’s not much, but we are in the early days of Threshold2. I’ll make sure to update you once there’s a working example of working with enclaves, as at the current stage, no part of Windows is using it. Also, make sure to stay tuned, since we will make sure to take a deeper look at any future Windows 10 build that gets released!

Read more

Intel® SGX for Dummies (Part2) (Part3)
Secure execution of unmodified applications on an untrusted host (Microsoft Research)