Evilmaid Chkdsk

[kickarse]

Pretty neat concept and code (link and desc below)

https://github.com/AlexWebr/evilmaid_chkdsk

Evil Maid CHKDSK

This is s simple 512-byte MBR program that pretends to be Windows CHKDSK. It asks the user for a password, writes that password back to the media it booted from, renders that media unbootable, and reboots.

Terminal capture of using it with QEMU: http://ascii.io/a/1201

Video demonstration on a Windows laptop:

[digip]

I don't know how "neat" it is as much as it is one hell of a POC code. It demonstrates the power of ASM and ones knowledge of a boot loader, but other than that, its pure evil as the name implies.

One thing I see as a flaw though, is that chkdsk is an automated process, and doesn't prompt for a password. Ever. Once you set it to run on reboot, it will do it automatically, so thats a red flag right there. Granted most people wouldn't take notice if they've never run one before, but if I saw that, I would immediately shut down my machine and investigate whats happening, because it would appear to be a virus or rootkit or such if prompted for my password before getting to the boot screen.

For those of us who fix computers on a regular basis, this would be a huge red flag.

He would have been better off to make it like Konboot, and instead of destructive, just bypass the kernel loader and then keylog the legit login process, similar to Konboot does with its own, and the end user would never be the wiser. Not to mention, this is more destructive than it is useful. How does the "attacker" plan to retrieve this once hes loaded it on a system that then supposedly prompts to format the HDD after booting? The install and extract commands assume the attacker has physical access. If that were the case, it would have been easier to boot linux(which you would be doing anyway to run the dd command) and just pull the SAM file for offline cracking, while the end user would be none the wiser. Not to mention, if you HAVE physical access, just copy the users profile and ntuser.dat file too, so you can harvest their registry for more data and passwords, serial numbers, etc.

Tools like this aren't even in the realm of useful other than maybe knowing how a boot loader works or understanding some ASM code with respect to said boot loader, but other than that, its pretty much destructive code, and I guess more or less done, only because, well, it can be done, or POC. People with skill like this should put it to better use, like protecting systems instead of fucking with someones computer. If you did this to my machine, and I found out who you were, or knew you, I'd put your nuts in a vice a tighten it till they pop.

[kickarse]

I'm happy your cynicism hasn't changed at all Digip ;) lol... you picked that one right apart huh?

It's just a proof of concept idea from what I gander. That's really all it's useful for. It might work on someone who doesn't know jack about PC's (most home users); I mean they end up "scanning" their PC for viruses with software they never paid for or installed. And yes, Konboot would be better.

As for your other "questions" you might want to ask him what he planned on doing with it. I'm just a messenger.

Edited September 24, 2012 by kickarse

[bobbyb1980]

Konboot looks like it manipulates the SAM and does the sticky keys trick (I wouldn't pay 20 bucks for that as konboot asks) via offline attacks on the filesystem, whereas this rewrites the MBR. You can change some of that code to make it say "enter CMOS password" instead of Windows password.

How exactly are you getting that on the MBR in Windows 7?

[digip]

Konboot looks like it manipulates the SAM and does the sticky keys trick (I wouldn't pay 20 bucks for that as konboot asks) via offline attacks on the filesystem, whereas this rewrites the MBR. You can change some of that code to make it say "enter CMOS password" instead of Windows password.

How exactly are you getting that on the MBR in Windows 7?

From the link, it looks like a format of the boot record using the linux dd command to overwrite ti with the asm code. Kondboot I thought loaded its own kernel ahead of the windows kernel in order to bypass authentication.

[bobbyb1980]

From the link, it looks like a format of the boot record using the linux dd command to overwrite ti with the asm code. Kondboot I thought loaded its own kernel ahead of the windows kernel in order to bypass authentication.

Konboot might load a kernel, but it's using the sticky keys so offline attacks are happening somewhere in the process. One way I can think of to do what it does is to just delete the SAM from the offline disk, save it to the USB, then after bootup replace it again once you get system, then the next reboot the same password is required to logon.

In the Windows video it wasn't shown how to rewrite the MBR. I'm not familiar with QEMU very much, don't know whether it's an OS emulator or Cygwin type deal, but either way the video didn't show how to rewrite the win7 MBR. He just ran dd against some fake output.

[digip]

QEMU is a hyper visor, similar to VMware and VBox, and can be used to create virtual machines and migrate virtual disks to other VM's.It lets you run things like ARM programs on an x86 from what I recall, since it can emulate native machine code from different architectures. Its where you get KVM, or kernel based virtual machines from.

I've used it once or twice to make VMware virtual machine configuration files a few years ago when all I had was the free VMware Player, so you could at the time use VMware Player to install say an XP VM from a copied ISO off the HDD, back when they didn't natively support booting an ISO, QEMU would allow you to do it and make a VMware Virtual Machine, but now VMware supports that pretty much in all versions and can be tricked to boot and install with just a manual text edit of a config file and pointing VMware player to the ISO file on your HDD instead of having to use QEMU to build the virtual appliance to load ISO files and virtual disks.

[bobbyb1980]

Yeah, well I'd really like to see how he's rewriting the MBR on Win7 as this video is pretty useless without that info. To my understanding the MBR on Win7 is spread out over a few .dll's. I'd imagine you'd have to disassemble the .dll's, and reassemble them with the altered MBR. Two issues with that though, one I think ASLR might stop this from being replicated since it would change the address in memory, and two the new MBR would have to have exactly the same amount of bytes as the old one or it could cause the .dll's to crash. This will be my next project.

[digip]

The MBR, is the first records on the disk, has nothing to do with DLL files. Windows 7 uses a newer bootloader, vs the older ntloader in XP, but the MBR, is a physical disk area that loads and calls the boot loader from windows, and instructs the HDD how to load the operating system on the active partitions.

You can use a windows 7 install disk to repair the MBR, and run the bootrec program to fix it. In XP, we used to run fixmbr to fix it, but in 7, its a different tool and a different subset of files that load the OS in Vista and 7, since it also creates a bunch of other stuff to load windows 7 its a different program and setup. See here: http://support.microsoft.com/kb/927392

if you set your windows system to show all hidden AND system files and navigate to your C drive or first partition the system boots from you will see the bootrec files. They are "bootmgr" and "BOOTSECT.BAK" as well as a hyberfile(only needed if you use sleep or hybernation modes under your power settings) and in some cases a pagesys file(which is your swap file on systems with self managed virtual memory).

[bobbyb1980]

The MBR, is the first records on the disk, has nothing to do with DLL files. Windows 7 uses a newer bootloader, vs the older ntloader in XP, but the MBR, is a physical disk area that loads and calls the boot loader from windows, and instructs the HDD how to load the operating system on the active partitions.

I could be wrong, but to my understanding the Win7 MBR is located in vdsutil.dll (http://thestarman.na...m/mbr/W7MBR.htm). Specifically in the first 512 bytes of the file.

I appreciate your links, but I'm not interested in fixing XP boot records or MS links for Windos recovery tools. This thread is about rewriting MBR's to execute opcodes, so let's keep the topic about that.

EDIT:

For our Windows 7 install, all the bytes of Win7's MBR code were also contained inside the following files (listed by location, alphabetically; with offset to first byte of the code). In each case, there will be a full 512 bytes that comprise the MBR code (the location for the NT Disk Signature and the 64-byte Partition Table are all zero-filled, the last two bytes being 55h followed by AAh):

1. C:\Windows\System32\RelPost.exe [Offset: 12CD0h]

("Windows Diagnosis and Recovery"; File version: "6.1.7600.16385 (win7_rtm.090713-1255)"; 182,784 bytes; Modification Date: "07/14/2009 1:14 AM"). There's also a second copy here: C:\Windows\winsxs\x86_microsoft-windows-reliability-postboot_31bf3856ad364e35_6.1.7600.16385_none_4d97265566a66f7e\RelPost.exe.

2. C:\Windows\System32\vdsutil.dll [Offset: 22CA8h]

("Virtual Disk Service Utility Library"; File version: "6.1.7600.16385 (win7_rtm.090713-1255)"; 151,040 bytes; Modification Date: "07/14/2009 1:16 AM"). There's also a second copy here: C:\Windows\winsxs\Backup\x86_microsoft-windows-virtualdiskservice_

31bf3856ad364e35_6.1.7600.16385_none_6ac128c35c0231aa_vdsutil.dll_f2ef43cf.

3. C:\Windows\System32\vssapi.dll [Offset: E20D0h]

("Volume Shadow Copy Requestor/Writer Services API DLL"; File version: "6.1.7600.16385 (win7_rtm.090713-1255)"; 1,123,328 bytes; Modification Date: "07/14/2009 1:16 AM").

There's also a second copy here: C:\Windows\winsxs\Backup\x86_microsoft-windows-vssapi_31bf3856ad364e35_6.1.7600.16385_none_d4bd3473e31540bf_vssapi.dll_51f72c64.

4. C:\Windows\System32\VSSVC.exe [Offset: E1BA8h]

("Volume Shadow Copy Service"; File version: "6.1.7600.16385 (win7_rtm.090713-1255)"; 1,025,536 bytes; Modification Date: "07/14/2009 1:15 AM").

There's also a second copy here: C:\Windows\winsxs\x86_microsoft-windows-vssservice_31bf3856ad364e35_6.1.7600.16385_none_5aa3249a792b0938\VSSVC.exe

5. C:\Windows\System32\oobe\winsetup.dll [Offset: 184220h]

("Windows System Setup"; File version: "6.1.7600.16385 (win7_rtm.090713-1255)"; 1,794,048 bytes; Modification Date: "07/14/2009 1:16 AM").

There's also a second copy here: C:\Windows\winsxs\x86_microsoft-windows-setup-component_31bf3856ad364e35_6.1.7600.16385_none_3202d4720e95de08\winsetup.dll.

Edited September 26, 2012 by bobbyb1980

[Jason Cooper]

I could be wrong, but to my understanding the Win7 MBR is located in vdsutil.dll (http://thestarman.na...m/mbr/W7MBR.htm). Specifically in the first 512 bytes of the file.

Sorry but Digip is correct, the MBR is the first 512 bytes on the boot device (be it a hard disk, USB, or even floppy disk). There are copies of templates located in a number of files around the system but they aren't the master boot record. For a start they almost always have the partition table missing as when repairing a MBR you want to use the current partition table for the device.

As to how you go about writing opcodes to the MBR, when I have done it in the past I have tended to use dd from linux. To generate the binary file to be written I would use FASM as it has an option to output a nice binary image. This image can then be written to the device's MBR. As Digip has already mentioned a lot of OS's these days use the MBR to chain load another binary that does the boot loading.

[digip]

I could be wrong, but to my understanding the Win7 MBR is located in vdsutil.dll (http://thestarman.na...m/mbr/W7MBR.htm). Specifically in the first 512 bytes of the file (I would give offsets to further support my point, but as I mentioned before I think ASLR is going to make this different between every machine).

I appreciate your links, but I'm not interested in fixing XP boot records or MS links for Windos recovery tools. This thread is about rewriting MBR's to execute opcodes, so let's keep the topic about that.

The fixmbr is XP specific, the Bootrec is Vista and 7 specific, for fixing both the mbr AND the boot loader files(which are two processes both needed to boot Vista and 7). And it was completely on topic. The DLL files the site you linked to are specific to the OS and its boot process in loading Windows itself, but not anything to do with the MBR itself, which if you read the link you posted, explains where Microsoft puts it for Vista and 7, at 2048 bytes into the drive. The attack above, assuming it works, writes its own mbr BEFORE this into the first 512 bytes of the disk, thus "pre-booting" and overriding windows ability to boot and loading his own code to trick end users into typing their password, and then storing it in the remainder of the 512 bytes area somewhere.

The command here:

dd if=/dev/<device> count=1 bs=512 > dump.hex ; xxd dump.hex
[/CODE]

Shows hes reading the first 512 bytes of the drive which is where hes running and storing his asm and assumed password stored code. In theory, windows should still be intact since it doesn't write its mbr until the first 2048th byte on the disk, its just not able to run(unless his code afterwards causes the windows bootmgr to be skipped which might be why its prompting a format of the disk, since its not seeing windows own boot process). All of that DLL stuff, is the things used by Windows to actually load windows and would be the same files chainloaded or used by say Grub after passing off the boot process to windows if you dual booted windows and 7 at the same time. In xp, it handed it off to ntldr, in Vista and 7, it hands it off to bootmgr and then windows takes over from there and calls all the other dll's and exe's to load the OS.

[bobbyb1980]

Got it guys, thanks.

Edited September 26, 2012 by bobbyb1980

[bobbyb1980]

OK. The partition table.

[digip]

OK. The partition table.

Not trying to be a dick about this or anything either, but the fixing of an MBR is kind of on topic too, since its about attacking the MBR, would be nice for people to know how to defend or even check it for attacks and such. Also, just some info on MBR in general - http://en.wikipedia....ter_boot_record

I'm curious how this works with UEFI enabled systems though, if it would cause some other type of havoc with the disk and booting, and if the attack would even work on UEFI enabled motherboards vs stanadrd BIOS. Be interesting to see someone do this to a Windows 8 VM and see what happens.

For disks that present a sector size other than 512-bytes, there are limitations as well. A sector size of 4,096 results in an eight-fold increase in the size of a partition that can be defined using MBR, up to 16 TiB−4,096 bytes.[citation needed] Versions of Windows more recent than Windows XP support the larger sector sizes as well as Mac OS X, and the Linux kernel has supported larger sector sizes since 2.6.31[17] or 2.6.32,[18] but issues with boot loaders, partitioning tools and computer BIOS implementations present certain limitations.[19]

I think thats why windows 8 went to UEFI for larger disk storage and capabilities for newr HDD's that implement the different byte array sizes for storage and what they call "advanced format" like some of the Western Digital HDD's that won't work with specific motherboards and operating systems due to lack of proper support. Edited September 26, 2012 by digip

[bobbyb1980]

I was thinking (hoping is a better word) that I could just do a binary paste and execute some shell code in one of the .dll's that I thought was the MBR and viola, covert code execution. I now see that's not the case and nothing about this "attack" is covert.

[digip]

If you have physical access though, you could pretty much do anything you want with the system, including replacing core DLL files with your own rouge ones that have extra or injected code. Unless they run SFC or have a virus scanner that matches something heuristically, it shouldn't get picked up either. Especially if its done while booted off live media and setup to run as a service after it executes at next boot. Just depends on what files get checked and if they have a match for the rouge code.