Tag: MBR
FireEye: BIOS Boots What? Finding Evil in Boot Code at Scale
Malware continues to take advantage of a legacy component of modern systems designed in the 1980s. Despite the cyber threat landscape continuing to evolve at an ever-increasing pace, the exploitation of the classic BIOS boot process is still very much a threat to enterprises around the world. Furthermore, since malware that tampers with the boot process (aka bootkits) execute before the operating system, such compromises often persist even after incident responders think the incident has been remediated. This post details the challenges FireEye faced examining boot records at scale and our solution to find evil boot records in large enterprise networks.[…]
NyanMBR: Nyancat in the MBR
Re: https://firmwaresecurity.com/2017/12/01/nyan-load-and-efi-example/
There’s also a nyan for BIOS, not only the above UEFI one!
NYAN ALL THE MBRs! A 16 bit Nyan cat demo small enough to fit in the master boot record of a disk. BEFORE YOU CONTINUE: USE ON YOUR OWN RISK, PLAYING WITH MBRs IS LIKE PLAYING WITH FIRE. DO NOT BE ON FIRE!
CheckBIOSDisk: Check uefi/legacy bios and gpt/mbr disk type for WinPE
This is a Win32 console application for Windows Preinstall Environment system. The gaol is checking PC uses UEFI BIOS (or with CSM) must ensures the disk type is GPT format, otherwise the legacy BIOS must using MBR format for disk layout. C++ code only does windows executing diskpart and reg commands and checks results to improve function, because requester is lazy and having lack knowledge on his job to design commands flow.
https://github.com/sharowyeh/checkbiosdisk
PS: Another tool by author:
https://github.com/sharowyeh/NvGpuUtility
DiskImageCreator: designed to help people attack the machine with a secure chain-of-trust boot process in UEFI BIOS
[[
UPDATE: adding URL, which I forgot in original post:
https://github.com/tsunghowu/DiskImageCreator
]]
DiskImageCreator : A python utility to process the input raw disk image and sign MBR/partitions with given corresponding keys.
Signing Tool for boot security validation.
This python utility is designed to provide a baseline for people who may be interested in attaching the machine with secure boot process built-in. The secure boot process is a customized chain-of-trust boot flow in UEFI BIOS. It will exam the target disk image(in MBR) and see if it is properly signed by the root key controlled by owner. This utility is to help owner to create a signed image with owner keys.
This tool is designed to help people attack the machine with a secure chain-of-trust boot process in UEFI BIOS.
Microsoft MDT: moving from BIOS to UEFI
If you have a Windows box and are trying to convert MBR/BIOS installs to GPT/UEFI installs on ‘class 2’ systems, you might want to read this:
https://blogs.technet.microsoft.com/mniehaus/2017/04/14/moving-from-bios-to-uefi-with-mdt-8443/
MBR2GPT
“MBR2GPT.EXE converts a disk from Master Boot Record (MBR) to GUID Partition Table (GPT) partition style without modifying or deleting data on the disk. The tool is designed to be run from a Windows Preinstallation Environment (Windows PE) command prompt, but can also be run from the full Windows 10 operating system (OS).[…]”
https://technet.microsoft.com/itpro/windows/deploy/mbr-to-gpt
MBRFilter: MBR security for Windows
Lucian Constantin has an article about a new MBR-based Windows-centric tool created by Cisco’s Talos. From his article on CSO Online:
[…]Cisco’s Talos team has developed an open-source tool that can protect the master boot record of Windows computers from modification by ransomware and other malicious attacks. threat intelligence The tool, called MBRFilter, functions as a signed system driver and puts the disk’s sector 0 into a read-only state. It is available for both 32-bit and 64-bit Windows versions and its source code has been published on GitHub. The master boot record (MBR) consists of executable code that’s stored in the first sector (sector 0) of a hard disk drive and launches the operating system’s boot loader. The MBR also contains information about the disk’s partitions and their file systems. Since the MBR code is executed before the OS itself, it can be abused by malware programs to increase their persistence and gain a head start before antivirus programs. Malware programs that infect the MBR to hide from antivirus programs have historically been known as bootkits — boot-level rootkits. […]
From the project’s readme:
[…]This is a simple disk filter based on Microsoft’s diskperf and classpnp example drivers. The goal of this filter is to prevent writing to Sector 0 on disks. This is useful to prevent malware that overwrites the MBR like Petya. This driver will prevent writes to sector 0 on all drives. This can cause an issue when initializing a new disk in the Disk Management application. Hit ‘Cancel’ when asks you to write to the MBR/GPT and it should work as expected. Alternatively, if OK was clicked, then quitting and restarting the application will allow partitoning/formatting. […]
Showalter analysis of HDRoot MBR bootkit
William Showalter has a blog post on the HDRoot MBR bootkit. Abstract below. See the below web site for an additional PDF, and a Github repo of the samples.
A Universal Windows Bootkit: An analysis of the MBR bootkit referred to as “HDRoot”
In October, 2015 Kaspersky released an analysis of a family of malware they dubbed “HDRoot” on their Securelist blog. It was an installment in their ongoing series on the WINNTI group, known for targeting gaming companies in their APT campaigns. The Securelist blog was dismissive of the HDRoot bootkit and called out a number of mistakes they claimed the authors made, which brought it to be the focus of their ridicule. The bootkit in question uses two stolen signing certificates and is capable of running without problem on any Windows system that was released in the last 16 years, from Windows 2000 to Windows 10. The one limitation is that it will only run as an MBR bootkit and will not work on systems using UEFI. It contains the ability to install any backdoor payload to be launched in the context of a system service when Windows starts up on both 32 and 64-bit systems. It also does a fairly good job of concealing the actual bootkit code, only failing to remove the backdoor after running it at boot. […]
Full post:
http://williamshowalter.com/a-universal-windows-bootkit/
Brian on Secure Boot -vs- Nemesis
Brian Richardson of Intel wrote a new blog on the recent Nemesis malware:
(Nemesis targets BIOS-centric MBR not UEFI-centric GPT partititions.)
http://blogs.intel.com/evangelists/2015/12/08/nemesis-meet-uefi-secure-boot/
Determining Windows partition information
Patrik Suzzi has an article on GPT partitions, and how to determine if you have MBR or GPT:
The article is written for Windows users, and has lots of screenshots, looks to be informative!
http://www.multibooters.com/guides/determine-if-hard-drive-is-mbr-or-gpt.html
verifyBoot: check MBR for changes since last boot
A few years ago, Naja Melan wrote a verifyBoot. Excerpt of readme:
verifyBoot helps you to automate the process of checking if your MBR and a partition have not changed. verifyBoot makes sha256 hashes, first of the entire partition, then of your MBR and every file individually on the partition to help to find out what has changed. Nowadays it has become reasonably trivial to have linux installed on an encrypted partition using dmcrypt or other encryption software. The usual procedure for system start-up implies for the bios to load the MBR of the boot device or the boot sector of a partition which then loads grub. Grub will load the kernel which will then take care of further booting and decryption of the encrypted system partition. The problem with this approach is that everything in the “/boot” partition is not encrypted, facilitating a rootkit attack. An attacker could make the user run a process with the required privileges before or during a moment when the boot-medium gets plugged into the running operating system. This would allow them to place a rootkit, but also to access to the unencrypted data which would probably be what’s at stake here in the first place, so this is not a very interesting scenario when considering the threat of a rootkit. The second option an attacker has when they can’t convince the user to run a rogue process is is to get physical access to the boot-medium. Since “/boot” is not encrypted, they can easily install a rootkit compromising everything on the system as soon as the user provides their pass-phrase. It is possible to considerably raise the bar of such an attack by installing one’s boot partition on a usb-stick that one carries at all time. This makes it hard for an attacker to obtain the unencrypted boot partition to compromise it. What do you do however when you go swimming, or when you get arrested or if you forget your usb stick somewhere. You could no longer be a 100% sure it wasn’t compromised. After you have been separated from your boot medium you should verify that it hasn’t changed. This is where verifyBoot comes in. It helps you to automate that process of verification. Note that you will need a safe system to run the verification test from. This could be a verified live system that you obtain from a trusted source for example. If the boot system has changed you will need to create a new one from a trusted system or use an encrypted backup copy to restore your boot partition before booting from it.
It is tied to MBR, and doesn’t work with GPT. It isn’t perfect, but it helps BIOS/MBR users with some vulnerability detection. It also seems like a feature the kernel should have…
BIOS, MBR, and the 0x87C00 mystery
Binni Shah tweeted about a BIOS blog post by Masahiko Sakamoto:
Excerpt of initial post, with all the questions, and none of the answers:
Why BIOS loads MBR into 0x7C00 in x86? The mysteries arround “0x7C00” in x86 architecture bios bootloader? Do you know “0x7C00”, a magic number, in x86 assembler programming ? “0x7C00” is the memory address which BIOS loads MBR (Master Boot Record, a first sector in hdd/fdd) into. OS or bootloader developer must assume that their assembler codes are loaded and start from 0x7C00. But…1st, you may wonder. “I read all of Intel x86(32bit) programmers manual, but did not found the magic number 0x7C00.” Yes. 0x7C00 is NOT related to x86 CPU. It’s natural that you couldn’t find out it in cpu specifications from intel. Then, you wonder, “Who decided it ?” You may wonder: “0x7C00 is 32KiB – 1024B at decimal number. What’s this number means ?” Anyone decided it. But, why he/she decided such a halfway address? Hum…There’re TWO questions (mysteries) arround the magic number “0x7C00”. Who decided “0x7C00”? What “0x7C00 = 32KiB – 1024B” means? Okay, let’s dive into the secret of BIOS for “IBM PC 5150”, ancestor of modern x86(32bit) PCs, with me…!!
Full post:
Firmware Security 