Attacking Windows Authentication and BitLocker Full Disk Encryption

Attacking Windows Authentication and
BitLocker Full Disk Encryption
Bsides Seattle 2015...ish
Ian Haken, 20160220

Ian Haken Attacking Windows Authentication and BitLocker Full Disk Encryption 2
Who Am I?
●
A security researcher at Synopsys, working on
application security tools and Coverity’s static
analysis products.
●
Prior to Synopsys, I received my Ph.D. in
mathematics from UC Berkeley.
●
Also have over 9 years of professional software
development experience.
●
Twitter: @ianhaken
●
Email: ian.haken@synopsys.com

What Am I Talking About Today?
●
How Windows BitLocker and domain authentication work,
and how they can be attacked
●
This talk expands on a talk I gave on Nov. 23, 2015 at
BlackHat EU in which I unveiled a technique for defeating
domain authentication and thereby bypassing BitLocker.
– The vulnerability is noted in MS15122 and was patched on Nov. 20,
2015.
●
Today I will be expanding this discussion with new research
and new ways an attacker may use these vulnerabilities.
– Automating the exploit for opportunistic attacks
– New research by Nabeel Ahmed and Tom Gilis (Dimension Data,
Belgium)
– How you can cover you tracks when exploiting this vulnerability
– Other attacks that can be performed using this exploit

Full Disk Encryption
●
A scheme for protecting data at rest. Encrypts
an entire disk or volume.
●
Encrypts everything, often including the OS.
●
Mitigates the impact of a threat with physical
access; generally does not provide protection
against remote adversaries.
●
This talk is about attacking FDE, assuming
physical access.

Microsoft BitLocker
●
BitLocker is Microsoft's proprietary fulldisk
encryption feature.
●
Built into all professional/enterprise versions of
Windows since Vista.
●
Uses the system's Trusted Platform Module
(TPM) to store the master encryption key.

What is a TPM?
●
A TPM is a hardware module responsible for
performing cryptographic operations,
performing attestation, and storing secrets.
●
It has fairly general APIs, so how it is used is
mostly up to applications.
●
Example applications include remote
attestation, and storing encryption keys.

Storing Secrets on a TPM
●
A TPM contains several Platform Configuration
Registers (PCRs).
●
Starting with the BIOS (which is assumed to be
trusted), the next part of the boot process (e.g.
the MBR) is hashed and this value is stored in
the a PCR.
●
Each stage of the boot process is responsible for
hashing the next and storing it in a PCR.

●
A boot, the TPM has a zero in all PCR registers.
●
Whenever the TPM is told to update a register r
with a value v, it always sets: r = HASH(r | v)
●
So PCR values can never get set directly, only
appended to. Arbitrary PCR values cannot be
spoofed.
●
This means a set of values in the PCRs can only
be replicated by having that same boot chain.

●
When the TPM stores a secret key, that key can
be sealed. When a key is sealed, the TPM
references the current value of the PCRs.
●
An API call to unseal that key will fail unless the
current PCR values match the original values
from when the key was sealed.
●
So effectively, only the original boot process will
be able to retrieve that secret key.

Transparent BitLocker
●
BitLocker, in addition to the TPM, can
optionally require a PIN or a key saved on a USB
drive (called preboot authentication).
●
However, its recommended configuration works
transparently. It seals the secret key in the TPM
and only BitLocker can retrieve it.
●
Your computer boots up to a login screen as
usual, with no indication that FDE is enabled.

BIOS/EFIBIOS/EFI
MBR and
bootloader
MBR and
bootloader
Operating System
(Encrypted)
Operating System
(Encrypted)
TPM RAM
Boot Chain of Trust
The boot chain of trust means each component
measures the next, puts the value in the TPM
PCRs, and only then passes on control to the next
component.

Attacks on the TPM
BIOS/EFIBIOS/EFI
MBR and
bootloader
MBR and
bootloader
Operating System
(Encrypted)
Operating System
(Encrypted)
TPM RAM
●
In 2007, Dartmouth researchers were able to
reset the PCR values on a TPM 1.1 chip by using
a wire to ground a particular bus line.
– http://www.cs.dartmouth.edu/~pkilab/sparks/
– http://rdist.root.org/2007/07/16/tpmhardware
attacks/
●
Addressed in version 1.2 of the TPM
specifications (minimum spec required by
BitLocker)

BIOS/EFIBIOS/EFI
MBR and
bootloader
MBR and
bootloader
Operating System
(Encrypted)
Operating System
(Encrypted)
TPM RAM
Attacks on the RAM
●
Cold boot attacks are a known class of attack
where sensitive data can be extracted from the
RAM by hardrebooting into an attacker
controlled OS, or even physically removing the
RAM module and placing it in an attacker
controlled system.
– https://citp.princeton.edu/research/memory/
●
The “TCG Platform Reset Attack Mitigation
Specification” requires the BIOS to overwrite
memory during POST if the operating system
was not shut down cleanly.

Attacks on BIOS/EFI
BIOS/EFIBIOS/EFI
MBR and
bootloader
MBR and
bootloader
Operating System
(Encrypted)
Operating System
(Encrypted)
TPM RAM
●
If the mainboard does not use signed BIOS/EFI
updates, an attacker can load a custom image
which doesn't load the MBR into the PCR.
– Yuriy Bulygin had a proof of concept which defeated
BitLocker specifically at CanSecWest 2013
– https://cansecwest.com/slides/2013/Evil%20Maid
%20Just%20Got%20Angrier.pdf
●
Even if proper signing is in effect, other bugs in
BIOS may still allow an attacker to flash a
malicious and defeat BitLocker in the same way.
– http://www.legbacore.com/News_files/HowManyMillio
nBIOSesWouldYouLikeToInfect_Whitepaper_v1.pdf

Attacks on the MBR/Bootloader
BIOS/EFIBIOS/EFI
MBR and
bootloader
MBR and
bootloader
Operating System
(Encrypted)
Operating System
(Encrypted)
TPM RAM
●
The MBR and NTFS boot sector are very small
and simple. Much easier to verify that there are
no defects here.
●
The initial program loader (IPL) gets more
complex and the Windows Boot Manager
(BOOTMAN) even more so; NTFS drivers, XML
parsers, oh my!
– If there's a memory corruption bug in here, it could
defeat the entire chain of trust...
– But I'm not aware of any defects in this code.

Attacks on the Operating System
Without preboot authentication, the system will
boot up to the fullblown OS. This is much larger
attack surface than any of the early/preboot
components.
BIOS/EFIBIOS/EFI
MBR and
bootloader
MBR and
bootloader
Operating System
(Encrypted)
Operating System
(Encrypted)
TPM RAM

Booting Up With BitLocker

Local Windows Authentication
●
The Local Security Authority (LSA) manages
authentication, usually using a Security
Subsystem Provider (SSP).
●
For a clientdomain authentication, the Kerberos
SSP exchanges messages with the Domain
Controller (DC).
●
When attacking FDE, we have physical access.
So we control the network and can run a
“mock” DC.

Windows Domain Authentication
●
Requests a session ticket (TGT) from the DC.
– The TGT includes a secret key S, encrypted by the
DC with the saved user password. Login screen
decrypts S using the typed password.
1) TGT_REQ
2) TGT_REP: TGT, {S}PW
3) Decrypt S using typed password

Windows Domain Authentication
●
TGT and S are used to request a service ticket T
from the DC for the target service (in this case,
the local workstation).
– The local workstation verifies T, thus verifying the
user has authorization to log in to that workstation.
4) AS_REQ: TGT, {MsgSig}S
5) AS_REP: T
6) Locally verify T

Machine Passwords
●
When a workstation first joins a domain...
– A secret key is generated, called the machine
password.
– This password is sent to the DC, so they have a
shared secret for future communication.
●
To grant access to the workstation, the login
process must present a valid service ticket T.
– A valid ticket is generated using the machine
password.
– Which we don't have...

If the DC uses the wrong machine password

The Local Credentials Cache
●
A user can login when the DC isn’t available
– Like when you’re using your laptop at a conference
during someone’s talk…
●
The cache is usually updated whenever the
workstation sees the credentials are changed.
– So it's updated when you successfully login and
were authenticating against the DC.
– Also updated when you change your domain
password...
●
Which is its own part of the Kerberos protocol

Password Change Protocol
●
Request a session ticket T using old password
– Basically the same as getting the TGT before.
1) AS_REQ
2) AS_REP: T, {S}PW
3) Decrypt S using typed password

Password Change Protocol
●
Use the session ticket T and secret S to send the
new password to the DC
– DC will reply with a status message, e.g. “Password
change successful” or “Password is too short.”
4) KPASSWD: T, {NewPW}S
5) KPASSWD: {Status}S
6) Verify change was successful and
update the local cache with the new
password.

Change the Password on the Login Screen...

Password Reset

Poisoned Credentials Cache

What Now?
●
Recover the BitLocker key
– As long as the domain account is a local admin
– Save a recovery key to your USB drive, or disable
BitLocker entirely.
– Although at this point you already have access to all
the local user files, so it's pretty moot.
●
Just dig through personal data
– Saved passwords, Outlook emails, source code…
●
Drop in a remote access toolkit, or whatever
other malware you like.

Demo

System Configurations Effected
●
Applies to any computer with:
– BitLocker without preboot authentication
– Attached to a domain
– With a least one person having logged in with a
domain account.
●
Tested on Windows Vista, Windows 7, and
Windows 8.1, Windows 10.
– (Also Windows XP and Windows 2000)
●
Patched by KB3101246 released Nov 10, 2015

How Else Does This Attack Apply?
●
This isn't really BitLocker specific. More
generally, this is an authentication bypass for
domain accounts.
●
If someone is logged in, locks their screen, and
steps away, you could use this to unlock the PC.
– Someone on their laptop at a coffee shop.
– A computer in an office.
– Stepping out to the bathroom while at a
conference...

Automating the Attack
●
Between DNS requests, NetBIOS
announcements, and Kerberos requests,
everything you need to know (domain name,
username, Kerberos realm) is announced on the
network by the victim.
●
This means the attack can be completely
automated.
●
This also means that a packaged exploit can be
used for opportunistic exploitation.
– So you can quickly drop a remote access toolkit on
any unattended machine you happen to walk by.

How is the DC Discovered?
Workstation
Where's the LDAP Server?
DNSOh yes, that's me.
Get domain info (also, hostname the DC?)
LDAPThe DC? Yea, that's my hostname.
What's the IP the DC? Also, here's a NetLogon
NetBIOSThe DC? Still me. Also, use Kerberos plx.
TGT_REQ
KDCPassword is Expired
...

Let's Start Scripting
We need to make servers for DNS, NetBIOS, LDAP, Kerberos...

GitHub is your friend
1) Network IO: twisted
https://github.com/twisted/twisted
2) DNS: dnslib
https://github.com/paulchakravarti/dnslib
3) NetBIOS name service et al: Responder
https://github.com/SpiderLabs/Responder
4) Netlogon: python Samba bindings
https://github.com/sambateam/samba/tree/master/python
5) LDAP Queries: ldaptor
https://github.com/twisted/ldaptor
6) Kerberos Requests: pykek
https://github.com/bidord/pykek

Presenting BlueBox
A handheld lockscreen bypasser

How It Works
1) Find an unattended computer.
2) Plug in bluebox to the ethernet port.
3) Log in with the password “a”. When prompted, set
a new password (like “b”).
4) Remove bluebox, login with the new password.
5) Install a RAT or other malware.
6) Leave quietly; later on access the RAT and retrieve
data.
PWR
OK
LKN
FDX
10M
RaspberryPi

Time for a Speed Run

New Research

The MS Patch (KB3101246)
●
The Kerberos password change protocol is
unchanged.
– This protocol was first implemented in Windows
2000, standardized in RFC 3244 published in 2002.
Changing the protocol would be an interoperability
nightmare.
●
After setting a new password the password, the
cache is not updated immediately; the SSP
requests a machine service ticket and only upon
receiving it updates the credentials cache.
– Remember that generating a valid machine service
ticket was something only the real DC could do.

New Research by Ahmed & Gilis
●
After my initial presentation, Nabeel Ahmed and
Tom Gilis performed followup research. Publicly
disclosed on Feb. 10, 2016.
– https://blog.ahmednabeel.com/fromzerotosystemon
fulldiskencryptedwindowssystem/
●
They discovered that by adding the victim machine's
ServicePrincipalName (SPN) to the active
directory, the original attack still works!
●
After some experimentation, I deduced that adding
the SPN allows the rogue DC to send an invalid
machine service ticket T, but it apparently isn't
validated until after the cache is updated.

Remember to Trust and Verify
“I asked if him for identification.”
“Since he had an ID, I let him in.”

The New Attack
$> samba-tool domain provision
$> NOW=`date`
$> date -s “2001-01-01 00:00:00”
$> smbpasswd -a ihaken
$> date -s “$NOW”
$> smbpasswd -a -m WIN10
This was fixed in KB3134228, released on
Feb. 9, 2016.
(And in case you're wondering, bluebox uses this
new version, so it works on anything preFeb9)

Recovering Users'
Passwords

Recovering users' passwords
●
Ahmed and Gilis also described how to use this
attack to recover a user's original password,
assuming they are already logged in when the
machine is compromised (e.g. if the machine is
suspended at the time).
●
While logged in, the LSA keeps the user's
password in (protected) memory for SSO
purposes. So dumping physical memory will
expose the password.
HIBERFIL.SYS

Recovering users' passwords
1) Unplug the laptop, wait for the battery to drain
enough for the laptop to automatically
hibernate.
2) Plug it back in, perform the login bypass attack,
copy the HIBERFIL.SYS file from the system.
3) Use WinDbg and mimikatz to extract passwords
from the dump.
– http://woshub.com/howtoextractwindowsuser
passwordsfromhiberfilsys/

What if the user isn't local admin?
●
Simultaneously, Ahmed and Gilis discovered a
vulnerability that allows for SYSTEM level
privilege escalation

The Credentials Cache

Evidence Left Behind
●
The credentials cache is part of the LSA and is usable by
the SSP modules.
●
The size of the cache is controlled by a registry key, and
defaults to 10 or 25 slots (depending on the OS version)
– HKEY_LOCAL_MACHINESOFTWAREMicrosoft
Windows NTCusrrentVersionWinlogon
●
Stored in the SECURITY registry file, specifically in
HKLMSECURITYCache
●
Stores public data (e.g. username) and doublehashed
(MD4) or PBKDF2stretched versions of the user
password; not directly usable in any sort of passthehash
context.

●
Each username will only use a single cache slot;
when the cache is updated, it overwrites the
data in that user's slot.
●
This means the user's prior cached password is
lost when we poison the cache; their real
password will no longer work.
– At least until they authenticate against a DC instead
of using the cache.
– Similar to how our mock DC removed all trace of the
true password, the cached credentials from the true
DC will remove all trace of the bogus password.

Restoring the Old Cache
●
Use the HIBERFIL.SYS attack to recover original
password
– Then put the properly hashed version back in the cache.
●
Now that you're in the system, monkeypatch the LSA
service to accept any password
– https://github.com/carmaa/inception
– Though to do it without restarting, you'd need SYSTEM
level access
●
Backup the (encrypted) credentials cache before
running this attack
– After the attack, extract the BitLocker key and read the
original value

Restoring the Old Cache
●
https://github.com/Aorimn/dislocker
●
https://github.com/libguestfs/hivex
$> dislocker-fuse -p$BL_KEY -V bckup.img /mnt_old
$> dislocker-fuse -p$BL_KEY -V /dev/sda2 /mnt_new
$> hivexregedit --export
/mnt_old/Windows/System32/config/SECURITY
Cache > /tmp/old_cache.txt
$> hivexregedit --merge
/mnt_new/Windows/System32/config/SECURITY
/tmp/old_cache.txt

Another Style of
Attack

Abusing Physical Access
●
Given an attack with physical access (e.g.
intruder in a datacenter or an office), what
options are available?
– By turning off the machine and taking out the drive
(or restarting the machine into an attacker
controlled OS), data can be read and malware can
be installed.
– But if you are in a position to notice your server
going offline, this would set off some alarms...
●
The goal: how to abuse physical access to a
target without causing any downtime?

The Zero Downtime Attack
●
With this exploit an attacker could insert the rogue DC while the machine is still
online...
●
Traffic is uninterrupted, but Kerberos traffic is manipulated to bypass the login
screen.
– So you can access data, leave a RAT
●
Put the real DC back
●
Other than a few dropped packets, there is no disruption in service.
– No physical evidence of the attack
– Login event can be removed by the malware
– Connectivity to the true DC is restored, so the real password will still work
Internet / Corporate Network
PWR
OK
LKN
FDX
10M
RaspberryPi
DC

Demo: The Zero
Downtime Attack

Some Final Thoughts
●
How should you be mitigating these issues?
– Make sure you're uptodate on Windows security patches.
– Where possible, use preboot authentication with BitLocker.
– For online servers, disable credentials caching entirely
where possible.
●
Don't take physical security for granted
– Consider physical security where building your threat model
●
Get these tools, play with them, send pull requests!
– https://github.com/JackOfMostTrades/bluebox
●
Twitter: @ianhaken, Email: ian.haken@synopsys.com

Attacking Windows Authentication and BitLocker Full Disk Encryption

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (15)

Similar to Attacking Windows Authentication and BitLocker Full Disk Encryption

Similar to Attacking Windows Authentication and BitLocker Full Disk Encryption (20)

Recently uploaded

Recently uploaded (20)

Attacking Windows Authentication and BitLocker Full Disk Encryption