Slashdot Mirror
Rootkit In a Network Card Demonstrated
KindMind notes coverage in The Register on a researcher who has developed a firmware-based rootkit that resides in a network card. Here is the developer's blog entry. "Guillaume Delugré, a reverse engineer at French security firm Sogeti ESEC, was able to develop proof-of-concept code after studying the firmware from Broadcom Ethernet NetExtreme PCI Ethernet cards... Using the knowledge gained from this process, Delugré was able to develop custom firmware code and flash the device so that his proof-of-concept code ran on the CPU of the network card."
At least it would have been a first post had the rootkit in my network card not delayed my packets.
We always knew Comcast was corrupt, here's the proof: http://tech.slashdot.org/comments.pl?sid=1909890&cid=34545432
An attacker would then be able to communicate remotely with the rootkit in the network card and get access to the underlying operating system thanks to DMA."
Not if the CPU had IOMMU hardware that was configured to only allow the network card to write to the proper memory area.
However, this still would not protect against the network card forging data, manipulating packets before passing them to the OS, for example manipulating packets to be malformed so to exploit an OS security vulnerability, emitting packets the OS did not generate (such as ICMP pings, or other packets for a hardware-based DDoS emitted without assistance from host OS.. or connecting to a P2P network of compromised NICs to form a spam-sending botnet, without host involvement.
The possibility also exists of capturing packets crossing the NIC and forwarding samples to an outside address, or manipulating aspects of packets to create an "open proxy" the host does not know about, enabling IP spoofing, cache poisoning, or opening other vulnerabilities that don't require manipulation of the host itself.
I'm sure people are familar with LoJack for Laptops, where either due to a hook in BIOS (Dells and HPs have an option that will reinstall the LoJack software even if the BIOS is reflashed and all disks are zapped) or other means it gets loaded.
I can see this happening with malware, especially on a NIC with DMA access. Even if a machine is completely DBAN-ed, the botnet client will silently reinstall itself. As more devices (keyboards and such) have ROMs that can be flashed, we will see more and more devices have this avenue for compromise.
How to fix? The obvious fix would be signing the flash BIOS, but this completely locks out homebrewers wanting to do something different. Another fix would be having the flash process be offline, such as only though a USB port with a usb flash drive. However, NICs won't have USB ports present. Still another possible avenue would be a slot for a MicroSD card, but that adds complexity to the device. So, this isn't something easy to deal with. The only thing that might come close would be a DIP switch toggle to allow for unsigned images to be flashed (which is shipped off), and all updates signed.
But still completely and utterly fascinating and relevant, especially since no one seemed to pay to much attention back at CANSECWEST (yet another computer security/tool/hacker/exploit research convention) this year in March when the same group shared their research and did a live demonstration of getting root (or system level, I forget if they hacked a windows or linux box) over the network by taking over the NIC, and not doing anything at all through the host OS.
See their writeup here www.ssi.gouv.fr/IMG/pdf/csw-trustnetworkcard.pdf or go to their company's website http://www.ssi.gouv.fr/site_article185.html
By doing what they do now, pull one out of every X and take a look at it.
You're assuming the NIC manufacturer is conducting audits in the first place. If they are, there's probably single person who maintains a list of good hash values for the firmware. Bribe that person and the audits won't matter.
The easier solution is to simply buy the cards from the OEM, flash them with a malicious firmware, then resell those cards at discount prices. Are NIC manufacturers purchasing off-the-shelf goods and conducting audits on those? Probably not.
And even then, you could always create a worm that detects your NIC and flashes the firmware then removes itself. You've been rooted and there's no trace at the OS level of it and even if the NIC manufacturer is auditing their products off-the-shelf they're not auditing the one in your computer.
That's pretty frightening. I would think this would be a pain in the ass to discover, and you'd end up replacing motherboards on servers/workstations trying to figure out why they kept crashing. I mean, who would flash their network card as a troubleshooting step?
I see you've never contacted Dell technical support.
Firmware based rootkits aren't anything new, there has been lots of them already before. Like for example, last year there was several demonstrations of someone writing firmware rootkit for certain Apple-branded keyboards; there simply was enough space in the ROM for a complete keylogger and a bit of heuristics there and several kilobytes of space where to store the log. And network card base rootkits? I remember having read about them and seeing a demonstration already 5-6 years ago.
The thing is, as long as the user has actual physical access to the computer in question he or she can do lots of different kinds of small modifications, and for example the keyboard rootkit is easiest to do, doesn't require admin rights, and is undetectable unless you verify the actual firmware.
"However, the attack presented only applies to a specific network card model (Broadcom NetXtreme) whenever a remote administration functionality (called ASF for Alert Standard Format 2.0) is turned on (it is off by default) and configured. According to vendors, this functionality is far from being widely used. As a consequence, this vulnerability is really likely to have a very limited impact in practice."
Doesnt seem like theres much to worry about.
If it ain't broke, don't fix it.
I suspect that they are (reasonably) well aware that somebody, presumably an embedded system/driver dev had to produce the blobs and loaders and other structures they are monkeying with in the first place. However, from their perspective as security guys, the point isn't "Wow, nobody has ever written an embedded device firmware, burned it to a device, and done some stuff with it" it is "Hey, it is possible for a third party of some(but by no means unique) skill and experience to, wholly without the cooperation of the manufacturer, work out everything that is necessary to get an ill documented or undocumented piece of hardware up and running with a new firmware that is both compatible with the original driver and capable of non-malicious operation and also capable of additional malicious functions".
Anybody who gives the matter a moment's thought, even pure amateurs, must conclude by simple logic that somebody can do it; what the security people are pointing out is that not only can somebody do it, potentially hostile third parties with reasonably available skills and no manufacturer support or collaboration can do it....
say you're a front for the chinese military making these things. you install the rootkit. broadcom or whoever will do an audit of retail boxes to make sure the cards are being produced to spec. how do you hide what you did?
One way is to operate completely within spec. The 'retail box audit' normally includes hardware components, not the actual firmware, so an audit is not likely to detect. It is not like they're going to audit NICs with a $100,000 logic analyzer, and spend thousands of skilled man hours verifying every bit on the programmable chip service matches their master. Hacked firmware can be designed to lie about its own contents when inquired, and these things can be designed to lie dormat for months on average.
The hacked firmware might open a backdoor only periodically, not every time. Each box will probably be audited once, not 50 times. When an end user gets the thing, they will eventually trigger the malicious code, because they'll use their machine for a long time.
Isolating the NIC as a cause would be extremely difficult, if the malicious code is sensitive to network activity, and specific kinds of network activity, for example keywords.
Perhaps the hack is configured only to activate if the computer sends something to an IP address in certain ranges, or containing a certain keyword. There are innumerable criteria that auditing won't detect
When did 'reverse engineer' become something you are and not something you do?
I recall this article that hypothetically starts by using the BIOS extension ROM function to hook into GRUB and modify it, then the modified GRUB loads and patches the kernel to host a rootkit, then runs that.
So instead of a smart peripheral with onboard processor and firmware, the dumb ones are affected as well (which only requires the BIOS extension ROM interface).
Even though BIOS is on its way out (we can't MBR-boot >2TiB drives anymore, so we have to use GPT) and EFI is on its way in, we're still stuck because EFI has similar features. Apple's video cards for Mac Pros have both BIOS extension ROMs and EFI ROMs.
Modded funny but should be informative.
No seriously - Dell Technical support will walk you through the most bizarre troubleshooting tips - and on the odd time it works.
One time we had a desktop that was bluescreening right after post - and would bluescreen if we tried to re-install Windows. It would bluescreen if we tried to get into the windows repair console.
After calling Dell, they simply made me go into the Bios, switch it off AHCI to Serial ATA, reboot, go back into the bios, switch it back to AHCI, reboot, and it worked perfectly again, no reinstall needed, no chkdsk even.
I remember he explained it very very quickly using a lot of hard drive jargon that I'm not familiar with - and I was so flabbergasted that it just went completely over my head anyways.
Windows 7 will require the last know controller mode in BIOS that it was installed under. For example, if you switch it to AHCI or SATA from whatever mode it was installed under will cause a BSOD. That's because the service isn't flagged to be started.
You can change this post install via registry setting. Here's the KB on how to do that. http://support.microsoft.com/kb/922976
FYI I ran into this before when a Dell tech replaced the motherboard for a laptop. He had no idea what was going on and left the building saying it was a "software" error and to call back. Well, he was right. Be he should have documented the BIOS settings and re-applied them to the replacement board, or at least contacted internal support for further help on behalf of the client.
Life is not for the lazy.