×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Rootkit In a Network Card Demonstrated

kdawson posted more than 3 years ago | from the burrowing-in-deep dept.

Security 112

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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

112 comments

Dammit (0)

Anonymous Coward | more than 3 years ago | (#34322392)

That's what I've got in my servers. Now if they're ever rooted I'll have to get entirely new network cards when I reformat and reinstall everything else.

First Post (2, Funny)

Wannabe Code Monkey (638617) | more than 3 years ago | (#34322408)

At least it would have been a first post had the rootkit in my network card not delayed my packets.

Re:First Post (1)

minvaren (854254) | more than 3 years ago | (#34323010)

Ah, there's your problem. You needed one of these Killer NICs http://www.bigfootnetworks.com/killer-xeno-pro/ [bigfootnetworks.com] to offset the lag of the rootkit.

Re:First Post (1)

Noughmad (1044096) | more than 3 years ago | (#34323082)

Unfortunately, they seem to be incompatible with my file system. Do you know any other FS that might work with that?

or buy a cheaper intel pro nic card that does the (1)

Joe The Dragon (967727) | more than 3 years ago | (#34323688)

or buy a cheaper intel pro nic card that does the same with out the software bloat.

Need hardware IOMMU (5, Interesting)

mysidia (191772) | more than 3 years ago | (#34322418)

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.

Re:Need hardware IOMMU (2, Interesting)

satuon (1822492) | more than 3 years ago | (#34322616)

Yes, but wouldn't the network card's limited hardware be a problem? I mean if you want to make a spam bot / P2P, etc., the code+data will have to fit in whatever RAM or EEPROM capacity the network card has.

Re:Need hardware IOMMU (4, Insightful)

mysidia (191772) | more than 3 years ago | (#34322910)

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

Re:Need hardware IOMMU (1)

MBCook (132727) | more than 3 years ago | (#34324682)

Quite true. But I would be willing to bet that most NICs don't have a very big program in EEPROM, but have at least 8 to 32 megabits of the stuff. After all, flash prices have dropped a ton and it's probably a better idea when building something to go with the 1.0078 cent flash rom that gives you lots of space you probably don't need than the 1.0072 cent one that gives you a constraint and may be hard to source next year due to it's small size.

I'd be willing to bet that for this reason, most NICs have lots of extra space. Even 256k can hold a LOT of special purpose code.

Re:Need hardware IOMMU (1)

sjames (1099) | more than 3 years ago | (#34324860)

If necessary, the spammers could just have the card do NAT so you get blamed for the spam.

Re:Need hardware IOMMU (1)

mysidia (191772) | more than 3 years ago | (#34325580)

If necessary, the spammers could just have the card do NAT so you get blamed for the spam.

Interestingly.. they wouldn't even have to do that much. Just provide the spammer a 'magic packet' to tell the NIC to start replacing and forwarding either all packets, or packets destined to certain ports to the spammer's destination IP.

Dumb rewriting is fine as long as the spammer gets the packet otherwise unchanged, as the spammer can implement all the 'NAT logic' in their own software.

In fact, since nobody really practices BCP38, the compromised NIC doesn't even need to send the spam packets, the spammer can take care of that by sending the spam packets themselves and applying the compromised host's IP address as the source IP on the packets -- all the spammer needs is the return traffic.

And the only reason the spammer needs the return traffic, is you can't in general use someone else's source IP address to successfully establish TCP connections without it.

Re:Need hardware IOMMU (1)

hAckz0r (989977) | more than 3 years ago | (#34323720)

That is what the Intel VT-d extension is for, and qubes-os.org is building a secure Hypervisor to operate it from a higher privilege than the normal root privilege, so the DMA can not break out via the normal driver level hacks.

Re:Need hardware IOMMU (1)

sjames (1099) | more than 3 years ago | (#34324840)

Or perhaps creatively re-routing packets into a GRE tunnel so they can all be watched remotely.

Re:Need hardware IOMMU (0)

Anonymous Coward | more than 3 years ago | (#34327352)

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."

However, this still would not protect against the network card forging data, manipulating packets before passing them to the OS,

But wouldn't he first have to sneak into your home and flash your NIC firmware, then sneak out again, and start the electronic attack?

scanning you to better enjoy yuor computing life (1)

chronoss2010 (1825454) | more than 3 years ago | (#34327616)

next up that root kit scans , finds hole sends back and then you get properly rooted

how do you hide it? (1)

alen (225700) | more than 3 years ago | (#34322442)

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?

Re:how do you hide it? (1)

Securityemo (1407943) | more than 3 years ago | (#34322514)

They can't possibly audit all the cards.

Re:how do you hide it? (1)

alen (225700) | more than 3 years ago | (#34322636)

but it will be done randomly so to get value from your virus you have to know who to sell the virus cards to. and since the chinese don't control the serial numbers you somehow have to produce and sneak them into the market with the right numbers

Re:how do you hide it? (1)

Monkeedude1212 (1560403) | more than 3 years ago | (#34322532)

How will they successfully audit them?

Re:how do you hide it? (2, Informative)

h4rr4r (612664) | more than 3 years ago | (#34322600)

By doing what they do now, pull one out of every X and take a look at it.

Re:how do you hide it? (1)

alen (225700) | more than 3 years ago | (#34322622)

the companies that make these will have reference boards, software and debugging tools

buy the retail boxes via CDW
install in test server or workstation
run your in house tools to verify that the code on the card is the same as your in house code you developed

and most of these cards are sold via dell and HP which write their own custom firmware as well just like they do for all the other add on boards.

Re:how do you hide it? (1)

mysidia (191772) | more than 3 years ago | (#34323102)

run your in house tools to verify that the code on the card is the same as your in house code you developed

And a properly hacked card outputs to the in-house tool the exact code it's supposed to, because the hack contains a bit of code to remove all the patches and return itself to pristine state, when a debug connection is detected

Re:how do you hide it? (1)

sexconker (1179573) | more than 3 years ago | (#34323178)

run your in house tools to verify that the code on the card is the same as your in house code you developed

And a properly hacked card outputs to the in-house tool the exact code it's supposed to,
because the hack contains a bit of code to remove all the patches and return itself to pristine state, when a debug connection is detected

Any in-house tool worth running will do physical reads and tests, as well.

Re:how do you hide it? (0)

Anonymous Coward | more than 3 years ago | (#34322534)

You put it in an OEM machine or coerce Lenovo or Acer to offer that driver on their updates site.

Re:how do you hide it? (1)

alen (225700) | more than 3 years ago | (#34322580)

but then how do you control who gets the virus laptops? with lenovo and acer they also have huge US workforces that can catch on.

and with all the security appliances that everyone runs these days it's going to be hard to hide the malicious network traffic

Re:how do you hide it? (1)

mysidia (191772) | more than 3 years ago | (#34323518)

and with all the security appliances that everyone runs these days it's going to be hard to hide the malicious network traffic

Security appliances need NICs too

Perhaps version 1 of the 'hack' is to obscure traffic that would be emitted by version 2

Re:how do you hide it? (2, Insightful)

_bug_ (112702) | more than 3 years ago | (#34322612)

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.

Re:how do you hide it? (1)

maxwell demon (590494) | more than 3 years ago | (#34323232)

Another attack level could be if you already rooted an OS, and want to protect your root kit against reinstall. Someone already mentioned PXE boot, as well as option ROM. In short, as soon as the PC gets rebooted (which is required for a wipe/reinstall), you get complete control.

Re:how do you hide it? (5, Insightful)

mysidia (191772) | more than 3 years ago | (#34323046)

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

Re:how do you hide it? (1)

mlts (1038732) | more than 3 years ago | (#34323100)

Don't have to turn it on for all cards, just like one of the prime vectors for malware are ad infected ad rotators where the ads just show to a small percentage -- just one in every several thousand cards with a bongoed ROM can bring in a superb ROI for blackhats.

Scary (1)

Quato (132194) | more than 3 years ago | (#34322464)

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?

Re:Scary (4, Funny)

jimicus (737525) | more than 3 years ago | (#34322614)

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.

Re:Scary (1)

alen (225700) | more than 3 years ago | (#34322682)

or HP for that matter

last week they almost made me upgrade to the latest RAID controller firmware to replace a few drives showing predictive failure. i was one version behind and this new firmware was a week old. but generally if you're a few months behind they will make you upgrade.

and i've seen a lot of mysterious reboots and other problems thought to be MS's fault fixed by HP firmware/driver upgrades

Re:Scary (0)

Anonymous Coward | more than 3 years ago | (#34323174)

HP does that. I got sick of it and went with service express for all our maintenance. fantastic company.

Re:Scary (1)

amorsen (7485) | more than 3 years ago | (#34323378)

HP's firmware writers are really crap. At least they DO fix issues eventually, even if they "only" affect Linux.

The only upside is that all the other vendors seem to be at least as bad, in some cases significantly worse.

Re:Scary (0)

Anonymous Coward | more than 3 years ago | (#34326246)

the latest barrage of hp firmware is kind of important if you give a shit about your data or performance and run a P-series card and in raid 0, 1+0 or 0+1.

see the now numerous critical firmware updates they have posted this quarter.

more reasons to say, fuck off and die HP

Re:Scary (1)

mysidia (191772) | more than 3 years ago | (#34323546)

and i've seen a lot of mysterious reboots and other problems thought to be MS's fault fixed by HP firmware/driver upgrades

The real question is... if you didn't upgrade it, would the problem still have gone away?

How many firmware fixes are genuine hardware issues VS workarounds for buggy Microsoft drivers? :)

Re:Scary (2, Interesting)

Monkeedude1212 (1560403) | more than 3 years ago | (#34323394)

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.

Re:Scary (2, Informative)

DigiShaman (671371) | more than 3 years ago | (#34323638)

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 [microsoft.com]

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.

Re:Scary (0)

Anonymous Coward | more than 3 years ago | (#34323532)

I see you've never contacted Dell technical support.

... Coffee... Nose... Keyboard...

Thanks for the laugh, try not to hit me right after a sip of coffee next time.

Re:Scary (1)

GaryOlson (737642) | more than 3 years ago | (#34325224)

I see you've never contacted Dell technical support.

No, but by calling the Dell number I have contacted a collection of semi-autonomous, partially intelligent voice response systems with limited input parameters and limited output responses.

Do these guys have any driver experience at all? (1)

BadAnalogyGuy (945258) | more than 3 years ago | (#34322468)

I read these security reports and have to wonder how much, if any, driver experience these security specialists have.

When we talk about patents, we like to drone on and on about prior art and how obvious something is to someone skilled in the art. But these security reports about flashing the EEPROM and running code on the NIC CPU and using DMA to corrupt the OS are all things that are done daily by embedded systems and driver developers.

Re:Do these guys have any driver experience at all (1)

Securityemo (1407943) | more than 3 years ago | (#34322544)

Then why hasn't someone gotten to it and embedded a firmware rootkit like this before? "Talk is cheap; show me the code" ...

Re:Do these guys have any driver experience at all (1)

BadAnalogyGuy (945258) | more than 3 years ago | (#34322610)

Mainly because the security experts, for the most part, don't know what they are doing and spend most of their time reinventing bugs that developers have already grappled with and overcome.

It's a lot like how a lot of teachers have a Masters in Education but not in anything specific to the courses they teach. Basically, all they have is a bunch of random ideas without any expertise to show them the right way.

Re:Do these guys have any driver experience at all (1)

Securityemo (1407943) | more than 3 years ago | (#34322800)

That's a flamebait, but unfortunately it's usually true, at least from my limited experience (as a security person you aren't likely to encounter a lot of colleauges unless you work in the business). However, all "real" "security researchers" I've encountered have been programmers as well - and certainly level enough to consult the technical documentation/research backgrounds of whatever they're trying to break. You also have to remember that a lot of stuff is already known since a decade or more, but since new security researchers generally aren't schooled formally...
It's a fragmented mess, or at least it looks like a mess from outside the industry, even with the security conference loop.

Re:Do these guys have any driver experience at all (1)

Gaygirlie (1657131) | more than 3 years ago | (#34322722)

Then why hasn't someone gotten to it and embedded a firmware rootkit like this before?

How do you know someone hasn't done it already? The whole point of rootkits is that they're undetected for as long as possible. And firmware rootkits are most likely employed by people who really know what they're doing and thus it's not likely the rootkits are found.

Re:Do these guys have any driver experience at all (1)

Securityemo (1407943) | more than 3 years ago | (#34322900)

"Talk is cheap; hide it in my car braking system firmware and have it play 'Korobeiniki' as I plunge to my untimely doom."

Re:Do these guys have any driver experience at all (1)

leuk_he (194174) | more than 3 years ago | (#34323422)

Maybe there are, but to see it you need to install a antitivirus product on your firmware.

wait... there are none..

Re:Do these guys have any driver experience at all (4, Insightful)

fuzzyfuzzyfungus (1223518) | more than 3 years ago | (#34322706)

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....

Re:Do these guys have any driver experience at all (1)

BadAnalogyGuy (945258) | more than 3 years ago | (#34322890)

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.

I don't suspect they know this at all.

Re:Do these guys have any driver experience at all (1)

Securityemo (1407943) | more than 3 years ago | (#34323018)

Most of so called "hackers" are incompetent, barely script kiddies. I consider myself quite incompetent, and I find it unbelievable that they can get a job anywhere. They're the security worlds mirror of the people who can't pass the FizzBuzz test. But then there's people who actually have half a brain. Thing is, for these people, shutting the fuck up on a semi-permanent basis might be a good idea. I'm sure you can imagine a few reasons why.

Re:Do these guys have any driver experience at all (1)

jd (1658) | more than 3 years ago | (#34324116)

You're assuming intelligence. An intelligent person would come to the same conclusions as you have. The same caution has come out for the Intel microcode uploader, flash-based BIOSes of all kinds and intelligent devices that can handle uploadable programs. It's not new, it's not even that dramatic, but it is (sooner or later) going to be highly significant. And all those who failed to take any action now will deny that they were ever told it was a possibility, and all those manufacturers who opted for pointless industrial secrets will point fingers at everyone but themselves. Same old, same old.

As for what skill it would take - well, anyone with rudimentary coding skill and a copy of FTP can grab hold of OpenBIOS, Tiara, Flashrom, Coreboot, Linux' flash drivers and any number of firmware uploaders. That gives enough information to cover a great many different cases. Most of the hard work has already been done. There may well be Black Hat tools that already use these mechanisms to embed malware into programmable devices.

It's a FEATURE! (0)

Anonymous Coward | more than 3 years ago | (#34322478)

...that comes pre-installed on Chinese made NICs.

I wonder about the next gen of attacks... (4, Interesting)

mlts (1038732) | more than 3 years ago | (#34322502)

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.

Re:I wonder about the next gen of attacks... (4, Informative)

cachimaster (127194) | more than 3 years ago | (#34322748)

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.

It's not a hook, LoJack comes with every BIOS. That's why it survives reflashing, you don't have the option of a BIOS without it. I co-wrote some article [coresecurity.com] about this not long ago.

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.

None of this would work. Maybe it will make it more difficult, but can't protect you against a logical flaw in the firmware that allows you to execute code. Firmware is like any other software, what happens if you sign code that executes any code? then all code is automatically "signed".

The solution IMHO is complex, expensive and involves signing+software protections in the NIC and in the OS (I.E. iommu, etc.) and WILL fail with a sufficiently resourceful attacker.

BTW, awesome work.

Re:I wonder about the next gen of attacks... (1)

fuzzyfuzzyfungus (1223518) | more than 3 years ago | (#34322824)

One might also go the avenue of adding a system-wide mechanism, designed from the ground up for maximum simplicity(so it doesn't itself need potentially malicious patching), for reading and writing all persistent memory in a system using an external piece of hardware in a special non-operating debug type mode(jtag-esque; but designed for lower complexity and this single purpose).

Some vendors would, no doubt, cry about the security of their precious binary blobs; but the customer, and security must ultimately come first. If there were such a mechanism, for reading back all the various 'hidden' memory spaces within a system, you wouldn't need to choose between the "security and control" of signed-only firmware or the "freedom and potential risk" of allowing unsigned firmware. The vendor could publish their recommended firmware, and its hash, and anybody who wished to verify their system could do so, and anybody who wished to run their own could calculate their own hash and do likewise.

Re:I wonder about the next gen of attacks... (1)

mlts (1038732) | more than 3 years ago | (#34323370)

Perhaps even just having a standard connector and method for accessing the JTAG ports might be the way to go. Plug a connector in, check on a second device if the code stored matches what it should be. If not, copy over a version that does. This could be automated so the NIC maker can make a security tool with a green/yellow/red light about the size of a 1/8 to 1/4" audio jack adapter that plugs into cards, reads a green light if the ROM matches a known good one, red if it doesn't, and yellow to tell the user the device is reflashing the NIC to a known good BIOS load.

Re:I wonder about the next gen of attacks... (1)

fuzzyfuzzyfungus (1223518) | more than 3 years ago | (#34323502)

My concern would be that any verification interface that doesn't have raw, independent, access to the persistent storage(doesn't have to be fast, I2C would cut it for all but the biggest blobs, does have to be independent) could theoretically be subverted by a malicious firmware.

In effect, unless you can take the system offline and scan the raw memory, you are really just asking the (potentially compromised) firmware running on the embedded CPU "Dear sir, are you compromised?" to which the answer will, inevitably be "No, obviously not, here is the checksum of either the firmware that I am, or the firmware I maliciously replaced. Nothing to worry about."

It's analogous to the challenge of A/V software on a potentially rootkitted system. You can ferret out a lot of the sloppier stuff by asking clever questions, which make it very hard for a rootkit to hid all its traces; but you are very much at a disadvantage. If you take the disk offline, though, and just hash all the files, comparing against known good hashes, nothing can hide, no matter how subtle.

Re:I wonder about the next gen of attacks... (1)

mlts (1038732) | more than 3 years ago | (#34323566)

Perhaps a separate, burned ROM (that can't be tampered with) that boots if a button is pressed? This ROM would scan the other BIOS storage and do exactly as you say -- compare everything to known hashes, and if there is an issue, zero out the BIOS and slap a "1.0" image that originally shipped with it, or perhaps have another mechanism for writing a BIOS to the storage. This is similar to booting a Linux machine from a Knoppix CD, running a hash of all files, then permissions and comparing the two to a known good reading.

Re:I wonder about the next gen of attacks... (1)

mysidia (191772) | more than 3 years ago | (#34323696)

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.

How about a special cable?

Have say a USB port with an extra 'notch' at the bottom.

When a special proprietary flash drive is plugged in that has an extra plastic notch attached to the bottom, the 'button' will be pushed and held down while it is plugged in, enabling a "hardware maintenance" signal line.

When the system is rebooted with the 'maintenance' button pushed down, the BIOS boots in maintenance mode, IDE/SATA controllers will be disconnected, USB ports except the maintenance port physical disconnect, the system will zero all RAM and load an image from the flash drive into RAM.

Once the drive is removed, it will jump to code in RAM containing any firmware upgrades. In maintenance mode, flashing is enabled and SATA controllers are disabled. In non-maintenance mode, flashing is disabled and SATA controllers are enabled.

And the manufacturer can sell proprietary flash drives to make up for the extra expense.

Re:I wonder about the next gen of attacks... (1)

Anthony Mouse (1927662) | more than 3 years ago | (#34323698)

How to fix? The obvious fix would be signing the flash BIOS, but this completely locks out homebrewers wanting to do something different.

Why not just have the hardware detect an unsigned BIOS and print a message on every boot that says "Modified firmware detected, press F7 for ten seconds to restore to factory default"? Then you can modify it if you like and you just ignore the message.

Re:I wonder about the next gen of attacks... (1)

DigiShaman (671371) | more than 3 years ago | (#34323878)

Simple, no need to make it complicated.

When a PC or Server is booted for the first time, force the user to create a password to password protect all firmware. The key here is to create a hierarchy of protection starting with the motherboard down to the peripherals installed on it. This could be vendor proprietary and eventually made into an industry standard. Any software that needs to change or update them will require this password in the future.

In the event the password is lost, physical presence of the machine will be required to clear settings. Generally done with a jumper or toggle switch.

Re:I wonder about the next gen of attacks... (1)

jeff4747 (256583) | more than 3 years ago | (#34324944)

Not even close to a solution.

First, passwords are not secure. They were always a kludge that made things 'better', but not secure.

Second, you are creating your password through the potentially infected system.

Third, this password would be stored somewhere in the system, since it would have to be checked. Stored data WILL be read by a malicious user.

Fourth, the password check is performed by software installed on the system that is potentially under attack.

Here's a good rule for security: If it's not blocked by the laws of physics, it will be used to exploit your system.

I came out of the closet: I'm a Dittohead!!!

Oh...that explains it.

Re:I wonder about the next gen of attacks... (1)

DigiShaman (671371) | more than 3 years ago | (#34325068)

BS!

1st: Passwords are an acceptable form of authentication as long as you provide proper complexity requirements (better that way).

2nd: What? You can't trust a brand spanking-new PC/Server to be free from rooted firmware? Why buy from vendor X then? Besides, I said that one would be created from the first time it was booted. That means YOU or someone you trust unboxing it first.

3nd: Passwords, or the information to verify authentication is always stored someplace. Locality isn't all that important. It also provides an option to erase it with physical means. Much in the same way as a router or other networking equipment.

4th: The point of password protection is to prevent the firmware from being overwritten in the first place.

Here's a good rule for security: Don't run or admin servers???

Re:I wonder about the next gen of attacks... (1)

jeff4747 (256583) | more than 3 years ago | (#34326890)

1st: Passwords are an acceptable form of authentication as long as you provide proper complexity requirements (better that way).

Ok, we'll delve back into Security 51 class for you. This is a bit too basic for Security 101.

Security comes from 3 things:

  • Something you know (username, password, etc)
  • Something you have (atm card, RSA keyfob, etc)
  • Something you are (misc biometrics)

You must have at least 2 of those components to have actual security. A password alone is not secure. A username and password is not secure, as they are both things you know. However, waaaaay back in the 1960s when remote login first became common, it was not practical to use one of the other methods. So the accepted hack was the username/password. The fact that it's still used widely doesn't mean it's no longer a hack, nor does it mean it's secure.

2nd: What? You can't trust a brand spanking-new PC/Server to be free from rooted firmware?

Nope.

Why buy from vendor X then?

How do you know you are actually buying from vendor X? Counterfeit parts are not rare and frequently enter 'trusted' supply chains.

Besides, I said that one would be created from the first time it was booted. That means YOU or someone you trust unboxing it first.

First, your vendor is going to boot and do burn-in tests on the system. If they do not, they should not be your vendor. Second, you are entering the password into a system with no security until you've entered the password.

Passwords, or the information to verify authentication is always stored someplace.

Yes, which is one of the reasons they're not secure. One-way hash is a good idea, but you're assuming functional hash software in a system that, again, has no security at the time you create the password. Not to mention there have been published attacks against hashes and hashing algorithms.

Locality isn't all that important

You have to be kidding me. K, I'll store your password on web page. Locality isn't important, right?

It also provides an option to erase it with physical means

How, exactly, does this enhance security? This just makes it so that if I get physical access to the box, I can reset it and enter whatever password I'd like. There's a reason you see this feature only on consumer-grade devices. And there's a reason people who understand security are always nice to the janitors.

The point of password protection is to prevent the firmware from being overwritten in the first place.

Yes, and there are published software-based attacks used to break passwords via flaws in password-checking algorithms. Note the key part there...software. I don't need to replace the firmware to attack your password. These algorithms also get extremely effective when they're on the target machine instead of operating over a network.

You might not understand how to defeat your solution. But there's 7 billion other people on this planet, and many of them are better at this than you are.

Re:I wonder about the next gen of attacks... (1)

DigiShaman (671371) | more than 3 years ago | (#34327906)

IMHO, I think you're over analyzing this way to much. At some point, you have to find your link in a chain of trust. How and where I leave up to you and the company you may or may not represent. At that level, it's really a risk assessment.

As for vendors, I trust Dell, HP, and IBM. At least the major brands would be HIPAA and PCI complaint. Also, some people run entire server farms using thousands of 1U servers from them. Each having a NIC or two.

This just makes it so that if I get physical access to the box, I can reset it and enter whatever password I'd like. There's a reason you see this feature only on consumer-grade devices. And there's a reason people who understand security are always nice to the janitors.

SonicWALL is not a consumer grade device. Yet vendors like them all authenticate locally with a password. And I know for a fact SonicWALL specifically will allow for resetting the password. But you will be forced to wipe out the configuration in the process. You would have to be a damn good social engineer to walk a janitor through reprogramming one over the phone. Hats off to you if you can pull that off. Sheesh.

Re:I wonder about the next gen of attacks... (1)

Gerzel (240421) | more than 3 years ago | (#34324190)

I'd say the simple switch or button located on the device, like you propose, would be the best option. Just add couple steps, "Find paperclip." "Find the little hole you wondered about in the plastic." "Stick paperclip into hole to press tiny button." The device is now flashable for x period and will revert back on its own after x or it is flashed."

Why is that hard?

Old News (2, Informative)

chrisG23 (812077) | more than 3 years ago | (#34322508)

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 [ssi.gouv.fr]

Re:Old News (1)

Securityemo (1407943) | more than 3 years ago | (#34322592)

I think it's utterly fascinating how blind we are about computer security unless we take matters into our own hands and look. It's like being in a series of twisty little passages, all alike. And some people are groping the walls instead of each other.

Re:Old News (1)

chrisG23 (812077) | more than 3 years ago | (#34322594)

I take it back, this is new but related stuff. The old stuff was a hack to gain control of a NIC and then the host computer over the network (only affected 1 model of NIC that they knew of). There new stuff is firmware that would require them to first have root level access on the target system so that they could flash the attached network card. The upside to this is that they could remove all tools on the system itself and traces that they had been there, and be very very stealthy.

Re:Old News (2, Insightful)

fuzzyfuzzyfungus (1223518) | more than 3 years ago | (#34322884)

I imagine that the bigger risk would be contamination of the supply chain. Having a box rooted and NIC flashed(especially if said NIC(s) are embedded on a motherboard and the malicious flash includes a mechanism for silently eating all reflashes while reporting success...) is a downer; but learning that 45% of counterfeit Cisco gear, and 20% of the real used stuff, is also loaded with firmware level malice would be a real downer...

Re:Old News (1)

BronsCon (927697) | more than 3 years ago | (#34322950)

So they use the NIC exploit to gain access to the system, then flash the NIC and remove the tools. Seems pretty related, to me; and I'm certain we'll see it happen in the next year.

or infect NICs in the factory (1)

Chirs (87576) | more than 3 years ago | (#34322996)

If they bribed/coopted someone in the factory they could infect a bunch of NICs before they ever got to the end user, and they'd have backdoors all over.

This is going to get worse when BIOS is gone (0)

Anonymous Coward | more than 3 years ago | (#34322510)

When scripts can move into the mainboard firmware, all hell will break loose. All persistent memory should have write-protect switches.

Re:This is going to get worse when BIOS is gone (1)

fuzzyfuzzyfungus (1223518) | more than 3 years ago | (#34322942)

*Intel spokesweasel, in a plaintive tone*: "We intended EFI to stand for Extensible Firmware Interface; but we didn't mean that extensible. Leave EFI alone!"

Keyboards next (0)

Anonymous Coward | more than 3 years ago | (#34322538)

Bring on the rootkit Mice with the plague virus

Nothing new, though (2, Interesting)

Gaygirlie (1657131) | more than 3 years ago | (#34322664)

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.

Sensationalized (3, Informative)

tom229 (1640685) | more than 3 years ago | (#34322696)

"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.

Re:Sensationalized (0)

HomelessInLaJolla (1026842) | more than 3 years ago | (#34323388)

From phone phreaking to the present day on every piece of hardware ever deployed has been exploited.

People are such trusting little suckers...

He Is A Reverse Engineer (2, Interesting)

mastershake82 (948396) | more than 3 years ago | (#34323198)

When did 'reverse engineer' become something you are and not something you do?

Re:He Is A Reverse Engineer (1)

Securityemo (1407943) | more than 3 years ago | (#34323376)

When did bricklayer become something you are and something you do? Or arson, for that matter? There's a crime defined in the penal code in the country where I live called approximately "general devastation", if you happen to cause earthquakes, landslides, train accidents or large explosions. Why aren't the ones penalized under it refered to as "devastators?" That's a big linguistic miss in my opinion.

Re:He Is A Reverse Engineer (1)

Gaygirlie (1657131) | more than 3 years ago | (#34323506)

When did bricklayer become something you are and something you do?

You don't do "bricklayer", you lay bricks, or perhaps you do a layer of bricks. His point was that you aren't "reverse engineer"; "reverse engineer" is a process someone does, but the person doing it isn't even necessarily an engineer at all.

Re:He Is A Reverse Engineer (1)

Securityemo (1407943) | more than 3 years ago | (#34323634)

My point was that the instincts of human language has no regards for the finer points of naming. If reverse engineering is a major activity in your life, you're going to get the title reverse engineer.

Re:He Is A Reverse Engineer (1)

jgrahn (181062) | more than 3 years ago | (#34324950)

My point was that the instincts of human language has no regards for the finer points of naming. If reverse engineering is a major activity in your life, you're going to get the title reverse engineer.

Doubtful. It sounds kind of ... wrong to me, so I would avoid the term. I might use it now and then in Slashdot summaries etc for humorous effect.

Perhaps the actual title should be "reenigne".

Re:He Is A Reverse Engineer (1)

jd (1658) | more than 3 years ago | (#34324168)

Well, it depends a bit on taste. I imagine some people would do a bricklayer, but so long as they keep that to themselves it doesn't bother me.

Re:He Is A Reverse Engineer (0)

Anonymous Coward | more than 3 years ago | (#34323804)

Around the same time 'engineer' became something you do and not something you are? Or was it the other way around... I cannot remember.

Cheap Chinese Manufacturing! (1)

erroneus (253617) | more than 3 years ago | (#34323228)

If we haven't been concerned over all of the cheap manufacturing going on in China, I would say this clearly illustrates what can really be done in a hard-to-detect way.

I have been repeating how "fear beats facts" lately, but there is one thing that beats fear... that would be greed. Not a lot beats greed and that is what is at the core so much. In this case, greed over the low cost of manufacturing in China to save a few bucks and to boost that bottom line.

BIOS boot process is also vulnerable... (2, Interesting)

tlhIngan (30335) | more than 3 years ago | (#34323304)

I recall this article [ksplice.com] 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.

Re:BIOS boot process is also vulnerable... (0)

Anonymous Coward | more than 3 years ago | (#34324302)

Personally, I'm more worried about this on "appliance" devices such as DSL modems, firewalls, routers, etc. that are on 24/7 and usually don't have much logging or even binary transparency to the user. How likely do you think it would be for someone to discover that the nic in their router had been rootkitted at some point? The worst part is, such an attack could be carried out remotely using default admin passwords and most people probably wouldn't even notice -- even after it had been discovered and publicized.

--And going after a single network interface in a router would be much easier, as you' could target the most popular routers and be guaranteed a large windfall.

Re:BIOS boot process is also vulnerable... (1)

Hatta (162192) | more than 3 years ago | (#34324608)

People running consumer routers are already very vulnerable for the most part. Reflashing the NIC is too much work. What you need to worry about is if you are doing everything else right, running full disk encryption, with encrypted swap, and a nice long passphrase. Let your computer out of sight for a bit and it's been flashed with firmware that will tftp your encryption key to hostile intelligence agencies (foreign or domestic, take your pick). Hell, they could even intercept your equipment before you got it. Looks like it's time to start buying components in person with cash at big box retailers.

Demonstrate This (0)

Anonymous Coward | more than 3 years ago | (#34326956)

http://www.DRIOD.com Demonstrated.........

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...