The BIOS rootkit from hell (attn. Sigma)

[Cyborg Girl]

https://www.security.nl/posting/366329/ ... OS-malware

Courtesy of Google Translate:

A security researcher has discovered several laptops mysterious malware hiding in the BIOS of computers . The BIOS ( Basic Input / Output System) is a set of basic instructions for communication between the operating system and the hardware .It is essential for the operation of the computer , and also the first major software running at the start-up. An attack on the BIOS may have far-reaching consequences and is difficult to detect . Example by a virus on the desktopResearcher Dragos Ruiu , creator of the famous Pwn2Own hacker competitions , reports via Twitter that he has discovered that flashing the BIOS can survive . Persistent BIOS malware In addition, the malware on a BIOS hypervisor , also called a virtual machine monitor ( VMM ) in which a virtual machine is running , and Software Defined Radio ( SDR ) functionality to 'air gaps to bridge .SDR is a radio communication system in which components that are normally part of the hardware (for example, mixers, filters and amplifiers) are carried out by means of software on a computer . A -SDR basic system can consist of a computer with a sound card or other analog-to - digital converter preceded by a form of RF front end.Air gapAn air gap is a computer that is not connected on the internet. Recently left security guru Bruce Schneier even know that he uses an air gap for the documents whistleblower Edward Snowden , he also examines , with a computer that has never been connected on the internet. By means of the SDR attackers would also be able to communicate in this way. With the machineThe malware was discovered by the Copernicus tool that dumps the contents of the BIOS and then to examine them. Dump Ruiu states that Copernicus seen the discovery of the BIOS malware already the main tool of the recent times .laptopsThe researcher reports that the BIOS malware on a Dell Alienware , Thinkpads and Sony laptops is found . Would have become infected MacBooks also possible but has not been confirmed . The malware uses DHCP options for encrypted communication. Using their skill On the basis of the tweets that the investigation into the malware is still in progress . Security.NL Ruiu has asked for more information . As soon as more details are known , we will let you know .

And the twitter feed:

https://twitter.com/dragosr

Watch this space. I am sure there will be more.

[FZR1KG]

Not to sound sceptical, but, SDR requires more than a simple sound card and software.
Sound cards have ADC's that go out to 96KHz which is way too low for useful radio reception or transmission.
Every SDR I know of uses an RF front end stage to drop the radio frequencies down to the level where the ADC's can function.
Separately, ADC's have really bad performance at the uV level so a good high gain preamp is required.
Even though most sound cards do have an amplifier (for the mic) that is in the mV not uV region.

r.e. flashing persistence of BIOS.
This also sounds really suspicious.
Flashing deletes all the data in the EEPROM or Flash device. It is a non reversible process.
The only way to maintain persistence after flashing a device is to put it back.
This means that the bootloader (the device that reads the data and programs the flash device with said data) must have been compromised.
Bootloaders are extremely simple devices. Almost all are ROM, i.e. non reprogramable.
The reason for that is so they can't accidentally get erased, which would totally brick a device rendering it useless.
Even cheap cub $2 cpu's have ROM bootloaders to load the Flash memory.
I have seen flash bootloaders (and disapprove most intensely) but even in these types the bootloader memory allocated and protected and are very small program wise and easy to check if corrupted because they use system calls to program and have inbuilt data integrity checking.
Pretty hard to hide a virus in a bootloader from both an access and memory capacity point of view.
Also, bootloaders are done by factory, the factory that designed the chip itself.

Unless the PC uses its own CPU to program flash (can anyone say dumb assed design that was prone to failure and known to be unreliable decades ago becore the PC was even concieved) I just can't see it happening. Then again, who knows what regurgitated obsolete design topology is used in the never ending quest to make a cheap product, I have seen dumber shit happening...

So yeah, I'll wait for updates but unless someone shows me how they overcame the above issues I will remain very skeptical.

[Cyborg Girl]

Thanks for the info FZ. Ruiu was also looking into the possibility that it was transmitted via power lines, but that sounds even more dubious to me; I don't know how you'd get something like that past a decent transformer.

My thought is that it may be polymorphic code of some sort that was preinstalled on the machines. Polymorphic viruses are an old tactic, and malware (even of the firmware variety) has come preinstalled on commercial hardware before.

Edit: re using the CPU to program the firmware - I'm not sure but I think most PCs do exactly that. On recent BIOS-based machines you can update the firmware from within Windows. Not sure about UEFI machines.

[FZR1KG]

You can transmit data down powerlines but you need the hardware to do it.

Just because you can program firmware via your Windows, doesn't mean the device programming the firmware is CPU driven.
It doesn't negate it but neither does it confirm it.

If it was me designing the system the flash image would be passed onto the bootloader and it does the programming.
For the actual PC CPU to do the manipulation of the data and control lines would be dumb.

Note however that in both cases the flash still gets completely wiped first then the new copy is written thus persistence does not happen unless the new flash code is compromised as well. Though that's technically not persistence, its flashing using compromised code.

Google translate may have a few issues here as well. What we may be reading in English may not be what was written in Dutch.
We need someone who can read Dutch to translate it properly. Now who do we know that's Dutch around here??? LOL

[Sigma_Orionis]

SInce this is deep into the hardware, I'll take Zee's word for it. Sounds about right to me.

r.e. flashing persistence of BIOS.
This also sounds really suspicious.
Flashing deletes all the data in the EEPROM or Flash device. It is a non reversible process.
The only way to maintain persistence after flashing a device is to put it back.
This means that the bootloader (the device that reads the data and programs the flash device with said data) must have been compromised.
Bootloaders are extremely simple devices. Almost all are ROM, i.e. non reprogramable.
The reason for that is so they can't accidentally get erased, which would totally brick a device rendering it useless.
Even cheap cub $2 cpu's have ROM bootloaders to load the Flash memory.
I have seen flash bootloaders (and disapprove most intensely) but even in these types the bootloader memory allocated and protected and are very small program wise and easy to check if corrupted because they use system calls to program and have inbuilt data integrity checking.
Pretty hard to hide a virus in a bootloader from both an access and memory capacity point of view.
Also, bootloaders are done by factory, the factory that designed the chip itself.

Unless the PC uses its own CPU to program flash (can anyone say dumb assed design that was prone to failure and known to be unreliable decades ago becore the PC was even concieved) I just can't see it happening. Then again, who knows what regurgitated obsolete design topology is used in the never ending quest to make a cheap product, I have seen dumber shit happening...

So yeah, I'll wait for updates but unless someone shows me how they overcame the above issues I will remain very skeptical.

Most servers these days have a small auxiliary CPU with its own software where the Hardware monitoring stuff runs (Intel calls it BMC, IBM calls it RSA, And it's part of what the SUN/Oracle ILOM software does in their systems, etc.), so it can reboot the server if it hangs (in these cases) the Server OS has a "watchdog" daemon that regularly talks to the internal monitoring system to let it know it's alive. To flash those things (and the rest of the Server Firmware as well) it's usually done with software that runs on the Server OS. Of course, since I don't know how exactly those things work I presume that they work the way Zee mentions: the Server OS and flash updating software pass the new firmware to the bootloader which actually does the firmware upgrade.

I do know that it can be accessed remotely through a standard called IPMI, which provides support for encrypted communications ( I use it to monitor my server hardware). Lately it has been shown to have several security holes

[FZR1KG]

I'd just like to point out that that while systems have been in place for decades as to reliable ways to bootload flash it doesn't mean everyone will implement them.
The main thing is that bootloaders should be preferably separate CPU based systems or implemented via protected memory schemes in conjunction with a hardware WDT.
The problem with using the PC's CPU is that its not a separate CPU and won't implement a proper WDT circuit that is effective for flash rewrites.
Which is why I doubt any engineer worth their degree would do it that way.

I again do stress however, I have seen dumber things done but with so many PC's the likely hood of it turning to shit would be very high so can't imagine anyone deciding this was a wise idea to do.
A partial (though crappy) solution would be to shutdown all other processes for the duration of the flash rewrite and to execute the write from protected memory, dual flash banks to confirm that the complete flash write was successful then bank switch. That's a lot of messing about to get less than desirable protection.

The standard way of doing things is to use bank switching with a separate CPU doing the flash writes and it halts the main CPU until it is done.
If completed the main CPU is restarted otherwise the original firmware is used and operation continues as though no flash upgrade was done.

If the above was implemented with a separate ROM driven CPU the OP concept won't work.
If it was implemented with the same CPU (the PC's CPU) it would be a simple case of never switching the updated bank thus possibly showing symptoms of persistence after a BISO Flash has been performed because the system would never use the new flash bank.

If its the latter I'd be one really pissed of customer since the correct flash bootloader procedures have been known for decades now along with all the potential pitfalls. I've known about it since the early 80's for example and it was old then. That's well over 30 year old security issues that have been both documented and solved a long time ago.

[Sigma_Orionis]

Meh, Like I mentioned in FWIS 2.0, "Mistakes and Sloppyness in IT are made three times: once in Mainframes, once in Minis and once in Micros". Nowadays it's four times: once in Mainframes, once in Servers, once in PCs and once in Tablets and Smartphones......

[FZR1KG]

Meh, Like I mentioned in FWIS 2.0, "Mistakes and Sloppyness in IT are made three times: once in Mainframes, once in Minis and once in Micros". Nowadays it's four times: once in Mainframes, once in Servers, once in PCs and once in Tablets and Smartphones......

Unfortunately this would fall in the lap of the hardware designers.
If they never provided the bootloader systems with a separate CPU there is no other option other than to use the PC's CPU.
I always expect better from hardware designers.
Not because I think they are better than software programmers.
Its because software can be updated if there is a bug, hardware can't so the hardware requirements place far more emphasis on getting it correct the first time because there aren't second or third chances and as a result the hardware engineer should place far more emphasis analysing everything that may go wrong and implement it at the design stage using well established procedures that are documented and supplied as datasheets and appnotes by the manufacturers of the hardware devices.
Of course, there is also the bean counter aspect to consider. When that hits the designer has to make sacrifices somewhere so no matter what some aspect of the system will end up being compromised. Many times the original designer doesn't even get a say in what stays and what goes. Been there, done that.

[Sigma_Orionis]

Yeah, I know what you mean.

I DEPEND on hardware running correctly, I remind the Boss about that once in a while. If it's a problem at the OS, RDBMS, Network and sometimes the App layer I can usually find a way to fix it. If it's hardware I can't unless I get a spare part.

The day I got this job, and he told me what his expectations where for Data Center Availability, and that we DIDN'T have Hardware Maintenance Contracts, I immediately told him "I will NOT accept ANY responsibility for Hardware Problems."

Case in Point: Last year he dumped the operation of the UPS to me. Poor Man, once I found out that the batteries in the UPS were close to giving up the ghost I pestered him for months about it (and of course he didn't want to buy'em.) the UPS had to go into Alarm mode till he relented. So he finally authorized the procurement of new batteries.

Two months later we had a blackout. The UPS worked but the POWER PLANT DIDN'T. So, the Data Center stayed operational till the Batteries ran out of Juice. When they checked the Power Plant, SURPRISE! it needed maintenance and nobody was paying attention to it.

So guess what? They Ended up dumping the operation of the Power Plant to me.....After I had it fixt (and that required pestering the supplier, the Boss learned his lesson THIS TIME), we had a major nationwide blackout and my DataCenter stayed operational. You should have seen the smug smile on my face that day......

[Cyborg Girl]

Well FZ was right, it doesn't cross air gaps... It apparently infects USB stick firmware and jumps from there to an x86 machine's BIOS, bypassing the OS. Nasty.

Question is, who the hell wrote it? This seems far too involved for your typical criminal enterprise, and the lack of obviously stolen PINs, etc. makes me suspicious.

Edit: more from Ruiu's Facebook account: https://www.facebook.com/dragosr/posts/ ... 5183445588

[Cyborg Girl]

And it hits the news.

Note this:

Ruiu said he arrived at the theory about badBIOS's high-frequency networking capability after observing encrypted data packets being sent to and from an infected laptop that had no obvious network connection with—but was in close proximity to—another badBIOS-infected computer. The packets were transmitted even when the laptop had its Wi-Fi and Bluetooth cards removed. Ruiu also disconnected the machine's power cord so it ran only on battery to rule out the possibility it was receiving signals over the electrical connection. Even then, forensic tools showed the packets continued to flow over the airgapped machine. Then, when Ruiu removed the internal speaker and microphone connected to the airgapped machine, the packets suddenly stopped.

Nice.

[FZR1KG]

Not sure why he is still speculating about the mic/speaker communications.
Get a simple CRO and a cheap mic and you'll see if there are any ultrasonic transmissions.

Seems like a pretty big waste of time to me, the speakers and mic in a laptop aren't really that efficient at above audio frequencies. For transfer to take place, both systems must have previously been infected (by a non airgap system such as USB) and only then they can only communicate if they are in close proximity to each other.

While not impossible to do, its pretty impractical to use this as a form of communications. Its inefficient, unreliable and relatively slow.

A practical use is spying in person. Basically go up to a laptop (it needs speakers and mic and not all desktops do) infect it and get out. Then come back later with a smaller version, say a phone and get some data off the machine while discussing business with your victim.

Unfortunately for them the system is easy to beat. Install a plug into the line out socket or the mic input. Also its easy to detect using a cheap portable CRO.

[Cyborg Girl]

http://www.rootwyrm.com/2013/11/the-bad ... -is-wrong/

Honestly I don't know nearly enough about hardware stuff to say whether this is correct.

BTW, "rootwyrm" also has a post regarding racism in the IT industry, which I think some of you might like...

[Sigma_Orionis]

Dunno if he's right but at least he seems knowledgeable about BIOSses.

This bit is pretty good:

Regardless, you’re still at an extreme level of specificity because you’re literally manipulating pins and wires alongside registers. You can’t just take an AMI ROMBIOS8 from one board and slap it on another. Yes, there’s a common core – that’s why we have AMI, Phoenix Technologies and used to have Award (plus Insyde as used by Sony/HP.) But to actually use that core requires extensive work to support the specific silicon and wiring used by a given motherboard. That information is always trade secret, and heavily protected.

I can testify to that, I took a BIOS ROM from a motherboard and placed it on another motherboard, guess what happened? I fried the MOBO, had to buy a new one. So it makes sense that BIOSses are not all that portable amongst different models of machines.

[FZR1KG]

He is pretty much spot on from my experience with hardware and firmware.
BIOS is firmware for a particular motherboard. Basically it connects the various lines from the hardware via firmware. You can get a lot of different devices (chips) that you use to do the functions required. All of the code would naturally be very different.
What a lot of people fail to understand is that you can use exactly the same hardware (chips) but each designer on the design team would implement it differently. The simple example is I/O mapping would be different. This would break code right there even with everything else being the same.
The biggest problem however is that even with different interface devices you get different modes that they can be run in. Sometimes this is programmable, most often it is a combination of hardware wiring to the device itself which cannot be read from the interface and software configuration. You just have to know what the mode is by looking at the individual schematic of each individual motherboard. Get it wrong at this level and you release the magic smoke that hardware runs on. Once the smoke is released you can't put it back in and the device fails. That's an old hardware joke that its not electrons that run hardware but smoke.

The author claims correctly that the mic is not accessible via BIOS, but I don't think the OP suggested that it was controlling the mic at the BIOS level. Apart from that one little slip there is nothing that he has written that does not make sense.
Like he said, while not impossible it would be limited to one specific machine.

He also made the statement that security guys aren't hardware guys.
The clearest example that I can give is that the security guy in question provided "proof" by removing the speaker/mic and the information exchange stopped.
Any hardware guys first response would be to actually verify the signal via CRO and analyse it. He failed this basic step.

Still very skeptical of this whole thing.
If he was an Australian researcher I could mode easily believe some smart ass on his team wrote a little bit of code and put it on the systems just to have a laugh. Seen plenty of that sort of stuff