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."
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....
the code+data will have to fit in whatever RAM or EEPROM capacity the network card has.
Or a downloader/backdoor will have to fit on the card to allow a remote load of any code that can't be stored on the PROM.
It could be a simple stub, executing exactly instructions carried in magic data packets. Downloaders can pull more code than is stored by using sources found outside the NIC, such as sources on the internet.
the hacked firmware could remove standard features like Wake on Lan, and use that space to implement features the malware author wants, like "Flood on LAN".
Most NICs nowadays support things like PXE boot. Either that part of the option ROM could be completely hijacked, OR in fact the PXE boot function could be used as a way of booting the system to a 'boot sector infection' routine next boot after the NIC is infested.
Think about it... Phase 1, your NIC gets infected, Phase 2, next boot a vulnerability will be opened in your system, thanks to the ability of every PCI card to include an option ROM in the BIOS, or code will run to use blue pill against your OS and introduce malicious code, the hypervisor above your OS downloads code from the attacker.
Depending on the payload downloaded, the malware could be anything from a keylogger to a spam node
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