This article helps you to understand the nature and impact of serious vulnerabilities, which exist even in the most advanced security tools and products.
In the first part of the article we discussed the issues related to vulnerabilities in the security software itself. In this second part, we would discuss some real life attacks and understand the nature of security vulnerabilities in security products.
New BIOS Attack
In computing, the BIOS is an acronym that stands either for the Basic Input/Output System or for Built In Operating System. BIOS refer, in part, to the firmware code (a type of boot loader) run by a PC when first powered on. The primary function of the BIOS is to identify and initialize system component hardware (such as the video display card, hard disk, and floppy disk) and some other hardware devices. This is to prepare the machine into a known low capability state, so other software programs stored on various media can be loaded, executed, and given control of the PC. This process is known as booting, or booting up, which is short for bootstrapping.
A BIOS program can also provide certain security mechanisms like boot password protection, which if configured, force the user to enter the correct password in order to continue the system booting and loading of Operating System. Examples of BIOS programs include Hewlett-Packard 68DTT Ver. F.0D BIOS, Intel Corp PE94510M.86A.0050.2007.0710.1559 (07/10/2007) BIOS etc.
| “A BIOS program can provide certain security mechanisms like boot password protection which if configured forces the user to enter the correct password in order to continue the system booting and loading of Operating System” |
How pre-boot authentication is done?
A pre-boot authentication software can be implemented in the BIOS itself (e.g.: a user BIOS pass-word) or most probably, for obvious portability reasons, in the boot-loader (lilo/grub, Vista's Bitlocker, or virtually any other pre-boot authentication software with or without full disk encryption capabilities). Since, there is no kernel in memory when this authentication software is run in RAM, the only API available to the programmer of a pre-boot authentication software is the BIOS API. This software might or might not add some kind of encryption to the disks, but it will surely need to ask the user for a password at a given moment.
| “The vulnerability lies due to the fact that the data read from user is copied in an unencrypted fashion at a static location in memory and is never removed even after use by the authentication program.” |
The BIOS API offers interruption 0x16 to retrieve keystrokes from the keyboard. In particular, functions ah=0x01 checks (and reads) if a key has been pressed and function ah=0x00 reads this keystroke, returning the ASCII code of the keystroke in the AL register and its scan code (read by Int 0x09 - i.e.: IRQ1 - from the keyboard and placed into the buffer. This mechanism allows the use of extended keystrokes, e.g.: Alt+Shift+Keystroke) in the AH register. At boot time, a critical structure, the BIOS Data Area is created at location 0x0040:0x0000 in RAM. The keyboard contains an embedded 8042 microcontroller to continuously scan for keystrokes pressed or released, in real time, independently of the workload of the main CPU. Every time a keystroke is pressed or released, this microcontroller sends a scancode to a second microcontroller (PIC 8259) present in the motherboard. This microcontroller unifies the two keystrokes sent when pressing and releasing a key and sends a unique scan code to the keyboard interrupt service routine (i.e.: the ISR of interruption 0x09, or physical (IRQ 0x01). The keyboard ISR updates a critical structure created at boot time at location 0x40:0x00 : BIOS Data Area accordingly.
Pre-Boot authentication software including the BIOS password authentication routines use interruptions as described above for reading password from the user during boot time before the operating system is initialized. The vulnerability lies due to the fact that the data read from user is copied at a static location in memory and is never removed even after use by the authentication program.
| This vulnerability will allow an attacker to steal the boot password stored in the BIOS by running a local exploit on the host. |
How has this vulnerability been discovered?
Windows (from Windows 95 to Vista) is running, like every modern OS, under Protected Mode to enable paging, segmentation, and multitasking. It is therefore impossible to access physical addresses directly; if we want to get access to a memory location, we will have to use virtual addressing and only the Memory Management Unit will be able to translate it into a physical address which we will not even know. To circumvent protections of Protected Mode and segmentation, a strategy could be to switch the OS back to Real Mode. This would require modifying the value of control register cr0, hence requiring 0 privileges. It could be implemented as a kernel driver, but would be highly non portable across versions of the Windows kernel, plus it would require special privileges. Another strategy, to disable segmentation and access the full physical memory in read or even write mode would be to switch to System Management Mode to run our shell code in 16 bits mode. Such an attack has been proved to be practical, assuming the attacker has root privileges, under OpenBSD.
But actually, all we need is a small shell allowing us to access the first few kilobytes of physical memory in read mode and optionally to do a few raw calls to BIOS interruptions to display the content of the BIOS keyboard buffer. Fortunately, the MS-DOS compatibility mode of Microsoft Windows provides just that : it takes advantage of Intel CPU's V86 Mode, to allow 16 bits programs execution under ring 3. Some privileged operations like raw access to disks via Interruptions 0x13 will be disabled, but we have access to Int 0x10 and even MS-DOS's Int 0x21 without restrictions. And since this mode uses Real Addressing and allows access to the first 1 MB of physical memory in read mode, we can run our previous 16b BIOS shellcode (Shellcode.S) without any modification. It is really just a matter of compiling the code and placing it in a file with an extension .COM, after verifying that it is 4b aligned, and run our binary.
“Interestingly, the vulnerability existed in numerous BIOS for last 20 years. So you may have been vulnerable from the very day you bought your computer.
iViZ published this vulnerability in Defcon 2008 at Las Vegas. ” |
How can you be safe?
The root cause of this kind of vulnerability lies in lack of sanitization of the memory area in which the password is stored in memory even after the authentication routines have finished its operation. The fix for this vulnerability is to be implemented in appropriate software that uses pre-boot authentication, that it must sanitize or nullify the password from memory after use.
Since, this issue primarily affects BIOS software; it is possible that this vulnerability will remain in various systems using the affected version of BIOS software for a long time due to the fact that BIOS updates are not very often. The users should use the latest versions of BIOS and the pre-boot authentication software where the issue has been fixed or use the latest patches/upgrades.
Encrypting your hard disk is no longer safe…
We use disk encryption software to secure our data. But is it really secure? iViZ Vulnerability Research team discovered a new class of vulnerability which bypassed the security of particular versions of Microsoft Bitlocker, McAfee Safeboot and several others.
iViZ discovered and showed to the world how hard disk encryption can be rendered practically useless. Hard Disk encryption tools including the BIOS password authentication routines use interruptions for reading password from the user during boot time before the operating system is initialized. The vulnerability lies due to the fact that the data read from user is copied at a static location in memory and is never removed even after use by the authentication program.
| iViZ discovered that it is possible to steal the password of the disk encryption tools by running an exploit locally. Once an attacker gets the password, the encryption is rendered useless. |
Breaking Microsoft Bitlocker/Vista (SP0)
Microsoft Bitlocker is the disk encryption feature introduced in Microsoft Vista. It has the capability to authenticate users in several ways, including with a password (PIN), when configured to work with the TPM chip. The password checking routine of Microsoft Bitlocker fails to sanitize the BIOS keyboard buffer after reading passwords, resulting in plain text password leakage to unprivileged local users.
Bitlocker's pre-boot authentication routines use the BIOS API to read user input via the keyboard. The BIOS internally copies the keystrokes in a RAM structure called the BIOS Keyboard buffer inside the BIOS Data Area. This buffer is not flushed after use, resulting in potential plain text password leakage once the OS is fully booted, assuming the attacker can read the password at physical memory location 0x40:0x1e. Microsoft Bitlocker/Vista (SP0) is vulnerable to this attack whereas Microsoft Bitlocker/ Vista (SP1) is not.
Breaking McAfee Safeboot V4, Build 4750 and below
The password checking routine of SafeBoot Device Encryption fails to sanitize the BIOS keyboard buffer after reading passwords, resulting in plain text password leakage to unprivileged local users.
SafeBoot's pre-boot authentication routines use the BIOS API to read user input via the keyboard. The BIOS internally copy the keystrokes in a RAM structure called the BIOS Keyboard buffer inside the BIOS Data Area. This buffer is not flushed after use, resulting in potential plain text password leakage once the OS is fully booted, assuming the attacker can read the password at physical memory location 0x40:0x1e.
However, builds 4760 and above are not vulnerable to this attack. Customers should upgrade to the current version of SafeBoot Device Encryption v4, or migrate to the current McAfee Endpoint Encryption for PC v5 platform.
| Readers should note that the vulnerabilities were discovered in specific versions of the Bios or Disk Encryption products are and has currently been fixed by the vendors. iViZ team works in coordination with vendors and releases the vulnerabilities once the patches are released. |
Conclusion
For the security product vendors, it is very critical to adopt secure design and coding principles, conduct regular penetration testing, conduct code review and also educate the customers regarding patching the security tools. It is critical to create security assurance programs and customer education program. The vendors need to make their customers understand that security products is yet another software/hardware and no software/hardware can be free of bugs/vulnerabilities and it is important for them to know how to deal with it. For enterprises and common users it is very critical to understand that security tools can also have vulnerabilities and hence it is critical to use it judiciously. We need to patch the security tools too, create layered defense, use multiple tools and create adequate failover mechanisms.
The next part of the series will be devoted on the details of the measures that users and product developers should take to stay secure.
—By: Bikash Barai
CEO, Co-Founder,
iViZ - On Demand Penetration Testing
Additional Credits: Rudra Kamal Sinha Roy, Jitendra Singh Chauhan, Abhisek Datta, Jonathan Brossard and the iViZ Vulnerability Research team |
