Slashdot Mirror
Remote Malware Injection Via Flaw In Network Card
kfz-versicherung writes "During the CanSecWest international conference in Vancouver, members of ANSSI described how an attacker could be able to exploit a flaw to run arbitrary code inside some network controllers (full presentation; PDF). The attack uses routable packets delivered to the victim's NIC. Consequently, multiple attacks can be conducted including man-in-the-middle attacks on network connections, access to cryptographic keys on the host platform, or malware injection on the victim's computer host platform."
If you dig into TFA, you'll find this:
"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."
A lot of IPMI and ASF code is an open door into at least some portion of the overall system. As NICs become more and more "intelligent," there's going to be more opportunities to exploit the NIC architecture and any subtle flaws because of the communication path into the system itself. Couple that with a rush to get stuff out the door faster and cheaper...and more of these issues will crop up.
"It is a miracle that curiosity survives formal education." -Albert Einstein
It seems that the presentation focuses heavily on the NetXtreme framework, which is specific to Broadcom. Doesn't Intel, the other major NIC vendor/manufacturer, use their own proprietary security and administrative protocols on their devices?
I wonder how secure Realtek's stuff is; their drivers/software leave me to think that their hardware code is ripe for discovery...
As devices become more and more complex, device functions that were once embedded within a chip are now being implemented by embedded computer systems which are tiny processors, ROM and RAM. And these devices interface with our computers through Direct Memory Access in some form or another and they get access to our computer's memory. If you think it is getting harder to find a virus in a running Windows installation, try finding one in your network cards or other devices.
While the "article" (it's a frikken PDF) says that this has been tested by invading a network card through a normally disabled management interface, what about other means of infection?
What I am saying is this: Once malware gets into the computer, all other devices are increasingly at risk of being a target for being compromised to enable secondary infections even after the hard drive is wiped out... even after the hard drive is replaced. Get some malware stuck inside your system board's controllers and you are either trying to figure out how to reflash every chip on that board, or you're buying a new board.
Since none of our clients use ASF, I have manually disabled it on every build I've done. Contrary to the article, many have it enabled by default. Why did I bother? I am a minimalist. I figured having an unused feature enabled could only potentially introduce problems.
Dude, I think you forgot to change your decoder ring from "I'm high" to "Slashdot". Please check the setting s and try posting again.
Love that comment! Too bad it was done anonymously, you deserve credit for the genius of its simplicity and clarity. "device vulnerabilities" have been around a long time. I used to make people on IRC lose their connections by sending specially crafted PING packets which would contain "+++ATH0" resulting in an immediate disconnection. I had one poor schmuck who patched and recompiled his Linux kernel like 6 or 7 times as he thought I was hacking his "computer" rather than exploiting his modem. His logs showed an ICMP coming from me followed by an interruption of his network link. He could have done one of two things: disable ping responses or changed a setting in his modem. It was hilariously funny watching the guy struggle though. Finally, I told him what I was doing..."Denwaugh"? Are you out there? Muhahaha! That comment brings back some memories...
The real point here is that devices are more than bits of hardware -- they are little computers themselves with their own vulnerabilities. Our trust of devices is a problem that is rarely considered.
The important part about this is not that the attack is very specific (only Broadcom running ASF) but that attacks through a NIC are possible at all. This could be the beginning of more serious and widespread attacks as network components become exploitable through their increasing technology. There's a relationship between amount of code a device runs and the amount of bugs present in that code, and bugs can often be exploited for bad purposes.
He could have done one of two things: disable ping responses or changed a setting in his modem.
Disabling ping is merely a poor workaround. You can exploit it in at least one other way, CTCP also has a ping response. If the victim is running an SMTP server that you can connect to you can get the SMTP server to repeat +++ATH0 via several different tricks. I'm sure there's other services that behave in a similar manner. The only REAL fix is to disable the sequence in the modem.
AccountKiller
I recently heard that the simulated network card in virtualization systems can be a point of attack. So, this may be a more general issue than a specific card.
The only REAL fix is to disable the sequence in the modem.
Or to buy a modem from a manufacturer that implemented it properly. The escape sequence is not just "+++" - there has to be an interval before and after those characters in which no other bytes are sent to the modem. This can only happen if you're typing directly from a terminal, since there are always extra headers present if you're sending TCP/IP traffic.
If your modem was vulnerable to this then the manufacturer was either incompetent or intentionally screwing it up to avoid paying patent royalties.
IPMI remote management security is worrisome.
There are Linux utilities for IPMI. It's definitely worthwhile running "ipmiutil discover" on any LAN you control, to find out if anything out there speaks IPMI. It's also worthwhile monitoring your data center's networks for anything happening on UDP ports 663 and 664. If you're not using IPMI, make sure no one else is.
A big problem with IPMI is that the shipped hardware defaults really matter. If someone ships you a NIC card with IPMI enabled and the password known, you are 0wned at a very low level. IPMI boards offer various levels of authentication, some of which offer good cryptographic security. But one of the options is "no authentication".
A deeper problem is the possibility that NIC chips might have a default backdoor password built in. Many NIC chips now are designed in China.
Understand how much you can do via IPMI. You can turn the machine on and off remotely. You can force a reboot. You can change the boot settings. You can change the MAC address. You can override the front panel power and reset switches.(!) You can lock out the keyboard, blank the screen, set up a connection which the computer sees as a hard-wired keyboard, and boot from the LAN. The operating system isn't involved in any of this; it's taking place at a level below that of the main CPU.
Dell's guidance on IPMI is terrifying. See Figure 3, where IPMI over LAN is being enabled with username "root", no password. This sort of thing is common. The default password on Dell PowerEdge servers is "calvin", on Sun Fire servers its "changeme", in both cases the user is "root"."
If you try to do it right, turning on all the crypto and using unique random keys for each chassis, someone has to manually type in the encryption key in hex on each new server. Then you need a remote management program which securely holds all the keys. How many shops really do that?