Who am I ?
Scope of this presentation
We present a new class of vulnerabilities,
Affecting multiple
Exploitable without physical access.
Limitations : we will focus on password based authentication solely.
Contents
(Technically) defining
Password leakage under Windows
Password leakage under *nix
Rebooting in spite of a
Examples of vulnerable software
Mitigating those vulnerabilities
I - (Technically) defining
authentication
Boot sequence overview
Taxonomy of
BIOS API for user inputs
BIOS internals for keyboard management
BIOS keyboard buffer Remanence...
Verifying this bug exists “in real life”
Password chaining
Bios Passwords
Bootloader Passwords (Vista's Bitlocker, Grub or Lilo, and most others
Early kernel stage passwords – typically before decompression (eg: suspend2 hibernation patch for GNU/Linux)
Interruption 0x16 invoked via functions :
ah=0x00 , “Get keystroke” : returns the keystroke scancode in AH and its ASCII code in AL.
ah=0x01 , “Check for keystroke” : idem, but the Zero Flag is set if no keystroke is available in the Bios keyboard buffer.
eg : lilo password reading routine :
Remanance... (1/3)
Filling the BIOS keyboard buffer (with the keyboard) :
Remanence... (2/3)
Reading the BIOS keyboard buffer (using int 0x16, ah=0x00 or 0x01) :
Remanence... (3/3)
Who is supposed to clear the keyboard buffer ?
life” (1/2) :
We want to check the authentication routines in the BIOS themselves (aka: BIOS Passwords)
We will write a small
life” (2/2) :
Results :
Most BIOS Passwords are vulnerable (more on this later).
... if the BIOS Programmers themselves do not clear the BIOS keyboard buffer... just imagine third party programmers...
Let's now imagine we have two authentication devices in a raw (asking for pass1 and pass2 respectively)....
What happens in the BIOS keyboard buffer ?
The passwords are concatenated ! So we can retrieve both ;)
[p][a][s][s][1][Enter][p][a][s][s][2][Enter]
SCOPE :
In the following two sections, we
assume the OS has fully booted and the attacker is given a local shell, but no physical access.
II- Password leakage under Windows
The Challenge
Possible attack scenarii
Reading the password from a guest account
How to read the password at 0x40:0x1e ?
(once in protected mode...)
Get back to
Switch to SMM
Get it from kernel land
All those scenari require very high privileges :(
guest account :
The
built on top of x86 Vmode to emulate 16b execution
Windows “feature” : maps physical memory ranges
(http://readlist.com/lists/securityfocus.com/bugtr
aq/1/9422.html)
III– Password leakage under *nix
Challenge
Getting the password from user land
Getting the password from kernel land
Conclusion
Unfortunatly, no goodie like the RAM leakage under Windows... We will try to retrieve the password from a privileged (typically root) account...
user land (1/4):
We know the address of the BIOS keyboard buffer in Physical Memory.
under most flavors of Unix, /dev/mem contains a mapping of the Physical memory...
user land (2/4):
/dev/kmem contains a mapping of kernel memory :
/dev/kcore contains the same information in the form of a core file :
user land (3/4):
We have coded a simple tool that will work under virtually any x86 based *nix (tested under OpenSolaris, FreeBSD, OpenBSD and GNU/Linux) to read the possible passwords from /dev/mem, but also /dev/kmem, /dev/kcore etc if available...
user land (4/4):
kernel land (1/3):
The BIOS Data Area is copied to a “safe” zone during kernel early booting (the infamous “Zero Page”, cf: Setup.S in the Linux kernel).
If you assume a 3Gb/1Gb kernel split, the address of the BIOS Keyboard buffer is : 0xC000041e
kernel land (2/3):
Verifying that the password is located at 0xC000041e (using remote kernel debugging...)
kernel land (3/3):
We have coded a simple LKM to automate the work and display the possible passwords in a new entry under the /proc
This bug has been there since the very beginning of BIOS passwords (25+ years).
Retrieving the password is as simple as reading a file at a given location... Open your eyes ;)
IV – Rebooting in spite of a
authentication password
In some cases, it is handy for an attacker to reboot the computer (to boot a weaker kernel for instance). But if a
In the next section, we assume the attacker can write to the MBR (ie: typically root access) and is willing to reboot the computer.
IV – Rebooting in spite of a
authentication password
Agenda :
The password is not used to decrypt anything
The password is used to decipher part of the disk or the whole disk.
authentication password without
disk encryption (1/2):
Since the password checking routine doesn't perform any useful task (from an attacker point of view), he can simply patch it.
See phrack article “Hacking deeper in the system” by Scythale for a deeper analysis of Grub hacking).
authentication password without
disk encryption (2/2):
used for disk decryption :
The BIOS keyboard buffer “feature” reloaded
Attack scenario
Methodology to install the rogue bootloader
“Invisible Man” roadmap
“feature” reloaded :
The Problem :
What happens if the BIOS keyboard buffer is not initialized ?
If the attacker can somehow enter the password before the genuine bootloader prompts for a password, the authentication routine will decrypt the disk nicely ;)
I/O Port |
|
|
|
|
|
|
|
|
|
|
I/O Port |
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
0x64 |
|
|||||
0x60 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
rogue bootloader :
V – Examples of vulnerable
softwares...
BIOS passwords :
Award BIOS Modular 4.50pg
Insyde BIOS V190
Intel Corp PE94510M.86A.0050.2007.0710.1559
IBM Lenovo 7CETB5WW v2.05 (10/13/2006)
Full disk encryption with
Bitlocker with TPM chip under Microsoft Vista Ultimate Edition SP0.
Truecrypt 5.0 for Windows (open source)
DiskCryptor 0.2.6 for Windows (open source)
Secu Star DriveCrypt Plus Pack v3.9
Boot loader passwords :
grub (GNU GRUB 0.97) (latest CVS)
lilo version 22.6.1 (current under Mandriva 2006)
(1/2):
BIOS Passwords :
Pheonix BIOS Version F.0B, 7/3/2006
Phoenix Technologies LTD R0220Q0
(2/2):
Full disk encryption with
SafeGuard 4.40 for Windows
PGP Desktop Professional 9.8 for Windows (Trial Version)
VI) Mitigating those vulnerabilities :
Write correct software : sanitize the BIOS keyboard buffer (and more generally any password buffer) before and after use...
We keep a list of patches on our website : http://
For GNU/Linux users, the latest version of Grsecurity (http://www.openwall.net) sanitizes the BDA at boot time (thanks to Brad for this).
Greetings :
My uber elite reviewers (you know who you are) : many thanks guys :)
The iViZ Technical Team for your support and the time spent on testing software.
irc.pulltheplug.org and irc.blacksecurity.org...
All of you for coming to this presentation.
The Defcon Staff for the awesome event and parties...
