BIOS rootkits making a come back?

[Mark]

BIOS rootkits making a come back?


A new BIOS rootkit that goes by the name Mebromi was detected by a Chinese security company while actively targeting users in the wild.

Apparently, the malicious package contains a BIOS rootkit, a MBR rootkit, a kernel mode rootkit, a PE file infector and a Trojan downloader.
With it targeting the BIOS, this makes the infection harder to detect and eradicate, and persist even if the hard drive is wiped or physically replaced.

It works by when it's first downloaded it checks which BIOS is being used, if it's Award BIOS it dumps a copy of the BIOS and then adds an ISA ROM that will rewrite the MBR at each bootup. From there, it infects the winlogon.exe (Windows XP/2003) or winnt.exe process (Windows 2000), which will be used to download a Trojan.

Mebromi is currently targeting Chinese users, which is obvious by the security software it tries to find and block. And even if the victim's computer isn't using Award BIOS, the threat isn't thwarted - it simply omits the first step and goes directly for the MBR.

The reason why Mebromi only targets Award BIOS ROM is because it has been modeled after the IceLord rootkit - a PoC that was made public in 2007 and did the same thing.

[Drumm]

Ring -1... I think we need to re-evaluate our ring system.
Wait until it finds more ways to infiltrate the BIOS ROM.

[Pack3t SynAck3r]

Ring -1... I think we need to re-evaluate our ring system.
Wait until it finds more ways to infiltrate the BIOS ROM.

Ring -1...I think I mentioned that somewhere before, grasshopper always pays attention.

Bios Rootkits have been around for quite awhile. There is a large quantity that is/was targeting dell dimension desktops Pentium 4 based (mainly because the number of machines still connected to the internet is vast.) BIOS is actually being replaced by UEFI on most modern Mobos. This particular trend is curious because of the preloaded drivers for input devices particularly the mouse. I suspect it could open up another can of worms for attack vectors but for the time being all is quiet on the front of security holes in the UEFI systems. The ROM checksum if examined on an infected BIOS will not not match the MD5 checksum that came from the manufacturer and in most scenarios can be dealt with by simply blowing out the firmware version through the built in BIOS utility. There are some boards where you can actually yank the ROM chip and reconfigure(if you have the right equipment) or simply replace it usually for a very small cost. Dealing with an MBR rootkit can require slightly more work, that is if you don't want to hose the OS at least.

MBR rootkits take advantage of the NTFS partitioning system tables(taking into consideration each system is unique as far as number of physical hard drives and number of active partitions on said hard drives. The "easiest" way of clearing out an MBR rootkit is using the simple FIXMBR command in the windows recovery console or you choice of PE environments i.e. BartPE or UBCD4Win. However you must also at this point consider that the malware that was originally able to modify the MBR must also be dealt with less you get your MBR reinfected upon boot.

Generally if I find a computer that has been nailed with an MBR rootkit I will take the machine offline and use sysinternal's autoruns in offline mode to go in and and remove all of the malicious startup entries be it a simple startmenu autorun, or disabling/deleting a malicious service whose only purpose is to reinfect. Running a chkdsk and forcing the reanalysis of "marked" bad sectors will also help remedy the rogue data floating about The biggest pain in the ass when trying to reverse engineer a ring 0 (kernel based) rootkit is that the authors have become very adept at disabling any debugging while the OS is active, making it difficult to track progress of how the r/k might be functioning. The only real way to debug in this case is to load the OS through an emulator and monitor from the outside.

Most of the time it is possible to examine the modified MBR of a rootkit and see where the partitions are trying to preload data from....which is usually a chunk of space of hard drive(mentioned previously) that might intentionally be marked damaged/unmovable so only the low level functioning kernel rootkit is actually able to access and manipulate the data in the previously stated space. If you study the basic makeup of how partition tables are created and how they function aside the MBR it makes life much easier as far as figuring out where the "hidden" data is lying low. A good resource is this website http://www.ntfs.com/partition-table.htm. Dump the MBR into a Hex editor and cross examine what you have with the information given on the aforementioned websites

I have seen one machine that had an infected BIOS and it was extraordinarily unstable. It is difficult to hide yourself when you are constantly causing your machines OS to BSOD because your injected code is causing Windows to act as though it is broken. Most people will probably look at the BSOD caused, determine the the mother board to be faulty and then replace it. The lower on the machine you attempt to manipulate data flow to facilitate your agenda the more likely it is that as the data is passed higher up the OS chain it is going to hit some snags. To this day I have yet to see a rootkit that has played nicely with the host operating system on which it is functioning. A layman will see their computer running slowly, a tweeker (like ourselves collectively) will usually intuitively figure out something else is amiss

I am constantly working on code in C and ASM that is able to rip out MBR rootkits and their hidden data. The constant tweeking and modding that the malware authors are using with their encrypt/decrypt sequences makes it difficult to set a one solution kills all mechanism, but I am able to add in rules as the new infections come out and the contents of such are made public. I have also found a few on my own that I have added in rules for and then posted the infected MBR code (a mere 512 Bytes on XP-like systems) for others to examine for themselves.
The MBR infectors on Vista and Windows 7 machines are a bit more complicated and I can go into them if requested but the most important thing to know about them is that they allow for unsigned drivers to load at boot-time without informing the user/admin of the machine.

I am glad to see you are starting to pay attention to rootkits Mark, they can be the enemy of system admin, or the friend of a security specialist attempting to audit.