Remote Malware Injection Via Flaw In Network Card 49
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."
For a little piece of mind (Score:5, Informative)
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."
Re:For a little piece of mind (Score:4, Interesting)
Okay but will the UDP packets which cause the problem be well formed enough to be routed into your network from outside? In most cases if you have access to the local network all systems are vulnerable anyway.
Re: (Score:2)
In most cases if you have access to the local network all systems are vulnerable anyway.
True: "if you have physical access then all systems are vulnerable" -- definitely. Just remove the hard drive, plug-in a keyboard sniffer, etc.
Maybe true: "if you can login to the box then all systems are vulnerable" -- yeah, most OSs probably have some local root exploit.
Stretch: "if you have access to the local network all systems are vulnerable" -- most desktop boxes don't even have any server ports open. Hacking them from the LAN is unlikely.
Re: (Score:2)
Yes, they will.
The packets in question cause problems because they cause a buffer overflow in a parameter sent in the data.
The NIC accepts normal UDP packets for port 664 and then analyses the packets to see whether they use a certain protocol. If that's correct, the NIC responds to the packet itself and the OS never sees it.
The tampered packets trigger a buffer overflow by using a usernam
Re:For a little piece of mind (Score:4, Funny)
3. Is there a proof of concept?
Yes. A proof of concept attack has been demoed during the CanSecWest conference. It showed how an attacker can remotely shutdown or wake up his victim’s machine, and fully compromise a COTS operating system machine (Linux for the demo, but all operating systems are vulnerable).
Hey, at least it's Linux compatible!
Re:For a little piece of mind (Score:5, Informative)
However, the attack presented only applies to a specific network card model (Broadcom NetXtreme)
Which happens to be the most popular network interface chipset used by Dell, HP, and many other manufacturers...
Not a big surprise (Score:5, Insightful)
Re: (Score:2)
Intelligent LAN cards are nothing new. Back when 80386 processors were being used in servers, several manufacturers produced NICs with their own processor. The LAN protocol stack would be run partially on the NIC itself to reduce the load on main server. We had a Xenix server at work that used such a NIC.
As a matter-of-fact I've still got a similar designed serial card in my cupboard of spares. This used an 80186 to control 6 serial lines, leaving the main processor free to get on with other things.
Limited to Broadcom only? (Score:3, Interesting)
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...
Re:Limited to Broadcom only? (Score:4, Informative)
Realtek hardware generally does not have the advanced hardware features found in the fancier Intel e1000(e) and Broadcom tg3.
Re: (Score:2)
Realtek's stuff is pretty much little more than reference implementation. They represent the "value end" of the marketplace, which works fine for cheaper Linux-based computers since drivers are ubiquitous for low-end (ahem: value priced) hardware.
Re: (Score:2)
+++ATH0 (Score:1, Informative)
NO CARRIER
Re:+++ATH0 (Score:5, Informative)
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.
Re: (Score:3, Informative)
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.
Re: (Score:3, Interesting)
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.
Re: (Score:2)
Unfortunately, that method was patented (did th patent run out yet?) and famously, modems based on the Rockwell chipset was vulnerable to this problem. I think USRobotics had the patent, I dun't know any more. But I know it was because of a patent on the pause following +++
ATH0
Re: (Score:2)
That method was patented by Hayes. Some modem manufacturers licensed the patent, while others did not. My Rockwell-chipset Supra modems handled +++ properly back in the day, but most of the no-name modems made after the September that never ended [catb.org] lacked this detail.
If I recall, there was also a way to do this using IRC directly, by issuing a command which would cause the remote client to respond (in part) with +++ATH0.
My personal favorite was just pinging folks to death. Their connection would simply deg
Re: (Score:2)
Every communications device/layer out of the USA should be seen as NSA friendly by default.
Re: (Score:2)
Even low end state taskforces can buy in p2p tracking software to find your 'unique' MAC.
Given that the MAC address isn't transmitted outside whatever subnet the device is on, how can "tracking software" (P2P or otherwise) determine your MAC address unless it is either on the same subnet or uses software that's somehow been installed on the target PC?
Re: (Score:2)
http://news.cnet.com/8301-10784_3-9920665-7.html [cnet.com]
This points out a simple problem (Score:5, Insightful)
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.
Re: (Score:2)
While everything you say is true, there is some measure of security in the fact that at the device level, you are working with the equivalent of multiple operating systems.
A virus writer infecting both your primary OS and a device on your system must have intimate knowledge of both the primary OS and the device's firmware. The first is not hard, 95% of people use the same brand with only a handful of widely used platforms. The second though, varies wildly, and it would be extremely unlikely that a virus fo
Re: (Score:2)
Oh let's see if I can outline this:
1. common malware happens
2. common malware gets system level access
3. common malware does an inventory of your system's hardware
4. common malware downloads prepared exploits for any common devices in its library hosted on any of the command/control servers or any servers C&C tells it
5. common malware then injects prepared exploit packages into device controller firmware
You are thinking about individual focused attacks where a person is driving each step of the game. T
Re: (Score:2)
If a particular brand of a common device were ever to absolutely dominate the market I could see it becoming a major concern.
My guess is that about 70% of all laptops and netbooks produced in the last two to three years run one out of maybe five or six different Intel NICs. On desktops targeting the four most widely used Realtek chips should give at least 30% coverage. On servers it boils down to a handful of widely used professional chips.
I do see it being an issue already. Not one of end-of-the-world-like seriousness, but for certain critical applications I would take it into consideration, CYA wise.
Re: (Score:2)
Re: (Score:3, Funny)
Re: (Score:1)
Re: (Score:1)
ASF hero (Score:5, Informative)
Re: (Score:2, Insightful)
an hero (Score:1, Funny)
only unpatched Broadcom NetXtreme w/ circumstances (Score:4, Informative)
Mo bugs mo problems (Score:2, Interesting)
Re: (Score:2)
Actually, this isn't that important. We've known about hardware vulnerabilities for decades. They're more difficult to exploit, typically, but they've been known about for at least 30 years, now. We used to just exploit the processor embedded microcode. Nothing new here, just moving to a different processor on a different PCB (unless it's built on the motherboard)
Non-story (Score:2)
From the article:
"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."
One network card by one manufacturer has a vulnerability when an obscure feature is tu
This may be more general than a specific card (Score:3, Interesting)
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.
Remote management security not good. (Score:3, Informative)
IPMI remote management security is worrisome.
There are Linux utilities for IPMI. [sourceforge.net] 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 [dell.com] 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"." [cuddletech.com]
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?