Energizer battery charger contains backdoor(blogs.zdnet.com)
blogs.zdnet.com
Energizer battery charger contains backdoor
http://blogs.zdnet.com/security/?p=5602&tag=wrapper;col1
65 comments
And, in my personal experience, in every case (excepting video cards) where I've had a choice between native OS support and a vendor provided driver, the vendor software is far worse - buggy, ugly, obtrusive, and usually stuffed with multiple "value-added" programs I don't want.
I've had that experience with video cards too, on Linux with an ATI FireGL v5200:
Built-in (open-source) driver: not great performance, but usable.
ATI driver: suspend/resume broken, frequent lockups requiring anything from connecting via SSH from another machine and killing the process to a hard reboot, and finally discontinuation of driver support about a year after the card was off the market (just in time for a version of X requiring new drivers).
I have a new laptop equipped with a FireGL v5700. Last I checked, the open-source drivers didn't provide 3D acceleration, so I suppose ATI's driver is better despite still having the above-mentioned issues.
Built-in (open-source) driver: not great performance, but usable.
ATI driver: suspend/resume broken, frequent lockups requiring anything from connecting via SSH from another machine and killing the process to a hard reboot, and finally discontinuation of driver support about a year after the card was off the market (just in time for a version of X requiring new drivers).
I have a new laptop equipped with a FireGL v5700. Last I checked, the open-source drivers didn't provide 3D acceleration, so I suppose ATI's driver is better despite still having the above-mentioned issues.
I think that Windows doesn't turn on power for a USB device until a driver recognizes it and OKs full power; I've run into this with other battery chargers in the past, and with other combinations of devices. Even though I have 6 different devices with USB in my living room, I can only charge my iPhone from one of them.
EDIT: This is opposed to Linux and Mac OS, which seem to be happy to provide plenty of power as soon as the device handshakes - I regularly charge my iPhone off of my ReadyNAS without any problems.
EDIT: This is opposed to Linux and Mac OS, which seem to be happy to provide plenty of power as soon as the device handshakes - I regularly charge my iPhone off of my ReadyNAS without any problems.
That's a good point, however, might be solved by making the charger introduce itself as one of the well-known USB device classes.
In this case, the software appears to be an on-screen battery charge monitor that users could download from a website. It was not included with the device or required for operation.
I really wonder how the backdoor got there in the first place.
The only machine in the factory in the cheap third world country with a CD burner was also the only one connected to the internet - so was the one that the techies browsed porn on and so was infected with everything.
ps. if you think this is unlikely - take a look at the crap on your CEO/CFO/salesman's laptops sometime.
ps. if you think this is unlikely - take a look at the crap on your CEO/CFO/salesman's laptops sometime.
Unlikely given the Symantec analysis. The DLL which listens on 7777 had a specific reference to the Energizer USB device. So, if it was a 3rd party attack, it would have to be an extremely targeted one.
Remember that article we had here on HN a few weeks back about Chinese spies infiltrating companies to get company information? It is improbable, but a similar thing could have easily been done with this. All they would have to do is get their own code substituted into the production process and they get an instant backdoor into many, many computers.
A more likely scenario, though, is that a tech savvy and angry employee wanted to get back at the company that was about to fire him. Imagine if a DDOS was launched against Energizer using code distributed by one of their own products. Ultimate irony!
I'm not saying either of these theories are legitimate, or even probable, but who knows?
A more likely scenario, though, is that a tech savvy and angry employee wanted to get back at the company that was about to fire him. Imagine if a DDOS was launched against Energizer using code distributed by one of their own products. Ultimate irony!
I'm not saying either of these theories are legitimate, or even probable, but who knows?
I bought a cheap router about 8 years ago that sent all of my DNS requests through some IP address in China.
Which raises an interesting question. How many people here monitor the link between their router and their cable modem? I certainly don't.
I use DD-WRT, so anything malicious from the router provider would have to be in hardware.
Good thing hardware doesn't rely on running complicated firmware... :)
DD-WRT is the firmware for the most part although I'd bet there's some embedded code running below this Linux-based OS. Is there enough wiggle room "down there" to, say, surreptitiously forward inbound traffic between network segments and back (like a mini NAT)? I have no idea. Does anyone here know anything about the WRT54GL board?
The DD-WRT is just general purpose computer operating system that happens to be configured as a router which Linksys calls firmware to discourage you from tinkering with it. The ethernet and wireless devices, though, have more code, several thousands lines of it, running on slower, low power (but still complex) processors.
[deleted]
How does code like that get in a system from a major corporation?
Is this an outsourcing/supplier issue, or something related to Energizer's own staff?
Is this an outsourcing/supplier issue, or something related to Energizer's own staff?
Wild guess: the software was outsourced to a software house, probably in one of the more "disreputable" countries.
It's a common method of doing it.
It's a common method of doing it.
There's a strong relationship between the quality of software packaged with a product and the relative importance of software to the maker's product line as a whole. This Energizer example is an extreme point on the graph.
My guess is that whoever made the installer had his computer infected. Not all companies have strict rules about what can be on the computer (or developers choose to not follow them and find ways around their enforcements) and this can be one of the downsides. I can't guess whether they virus-scanned the installation or not because it's quite possible that the trojan was new and not being picked up by scanner when they released the charger.
Ok, I found this analysis by Symantec which makes the whole thing less naive than I originally thought:
http://www.symantec.com/connect/fr/blogs/trojan-found-usb-ba...
They indicate a Liu Hong seems to have authored the install package. No indication if he was a Energizer employee or not.
The tale of how this backdoor got into a battery charging product is going to be interesting to hear.
This is a fairly important issue seeing as everyone is pushing towards USB-only charging. There are even USB charging ports on airplanes now.
Plugging in your device, with the intent of charging, shouldn't implicitly grant the host the right to install software or access files on the guest.
The USB protocol doesn't seem properly designed for this use case: I should be able to plug in to charge without having to worry about security holes.
Plugging in your device, with the intent of charging, shouldn't implicitly grant the host the right to install software or access files on the guest.
The USB protocol doesn't seem properly designed for this use case: I should be able to plug in to charge without having to worry about security holes.
This isn't an issue with the USB protocol. The software has to be installed manually, and should not even have been included (why do you need special software to charge batteries?)
It's the same with printers. They always want you to install some stupid software that "manages" printing for you. Um no, I just want the printer driver thanks.
There is still a remaining issue with plugging in devices, especially cameras and phones, where the charger has the opportunity to inappropriately, given the context, access the filesystem: software can maliciously be installed a result.
When wanting to charge a camera on an airplane, for instance, the user shouldn't be left to guess if his photos are going to be copied off the device.
When wanting to charge a camera on an airplane, for instance, the user shouldn't be left to guess if his photos are going to be copied off the device.
You can easily solve this problem by getting a usb cable without data wires. A few things I have came with these included with the charger. It pissed me off at first because they look like regular usb cables and I tried to hook up a disk drive. I marked them with a big X but soon realized how handy they could be when I wanted to charge a media player from a laptop I knew had some issues.
I've done surgery with a razor and some good shrink tube twice now to make more of these little gems.
Smarter devices like my Palm Pre actually ask if you want to let the host connect to them or just take power.
I've done surgery with a razor and some good shrink tube twice now to make more of these little gems.
Smarter devices like my Palm Pre actually ask if you want to let the host connect to them or just take power.
If I understand the USB spec right, getting more than 100mA of power requires a negotiation with the host, thus data wires. There might be a market for a USB data blocker, a device that negotiates the 500mA output with the host and with the guest but does not pass through any data.
You are right. That's what the spec says. In reality, I've never found a single hub or host that actually does this. They mostly just dump somewhere between 300ma and 700ma right on the wire. The really advanced ones don't crash the all the ports on the whole machine if you short or overdraw a port. Actually, I think my macbook may get it right (i don't plug homemade usb junk into my macbook), but my toshiba I know for certain does not.
You've got a great idea though. A simple micro like a PIC or an arduino (atmel) could do this and get all kinds of neat data on the power flow as well.
You've got a great idea though. A simple micro like a PIC or an arduino (atmel) could do this and get all kinds of neat data on the power flow as well.
USB Specs are available here:
http://www.usb.org/developers/docs/
USB 2.0 in particular (10.9 MB zip file): http://www.usb.org/developers/docs/usb_20_122909-2.zip
USB 2.0 in particular (10.9 MB zip file): http://www.usb.org/developers/docs/usb_20_122909-2.zip
USB data blocker - totally awesome idea. It could double as a protocol sniffer if it had a buffer.
See, a blocker and a sniffer would have almost entirely opposite functions. Both are cool devices that could be built from essentially the same hardware, so you do have a point there, but I wouldn't combine the two. Too easy to end up doing the wrong thing and compromising your data.
this is a great idea. market it to paranoid corporate IT for blackberries with sensitive materials.
No idea if no-data-wire USB cables are actually sold or do you have to roll your own?
Mind you, I find the point that there should be software for managing a battery recharger incredible.
Mind you, I find the point that there should be software for managing a battery recharger incredible.
When I plug my camera in to charge, it asks if I want it to go into disk mode. I can say no.
If your OS allows that, you need a better OS. Seriously, that's practically like having an OS that lets anyone on your LAN just SSH into your machine as root without a password just because they happen to be on the same subnet.
man dma
$ man dma
No manual entry for dmahttp://en.wikipedia.org/wiki/Direct_memory_access
And the description of how to exploit it
http://www.schneier.com/blog/archives/2006/06/hacking_comput...
The FireWire version http://www.storm.net.nz/static/files/ab_firewire_rux2k6-fina...
And the description of how to exploit it
http://www.schneier.com/blog/archives/2006/06/hacking_comput...
The FireWire version http://www.storm.net.nz/static/files/ab_firewire_rux2k6-fina...
get a better manual
I don't understand why you would plug a battery charger into a USB port? How many people don't have an extra power plug, but do have a laptop that they are going to let run for hours to charge their AA batteries.
If you are on the move it can be quite handy. Instead of dragging N wall warts with you (esp. if you're traveling internationally, as the cheap ones often are 110V only), you just use your laptop as a universal power adapter.
But that's one thing. To get power out of a usb port, you don't need to install any software. And that's what blows my mind, why would you even want to install some software to run a battery charger??
But that's one thing. To get power out of a usb port, you don't need to install any software. And that's what blows my mind, why would you even want to install some software to run a battery charger??
To get power out of a usb port, you don't need to install
any software. And that's what blows my mind, why would
you even want to install some software to run a battery
charger??
However, there are two reasons that you shouldn't do that, and why you need your device to actually enumerate itself on the users system.
The important reason, is to insure that the 500mA you think you have coming to you, is actually delivered. Technically, a motherboard can choose to assume you are broken, and disable the USB port, if you draw more than 100mA and haven't identified yourself as a high current device. Almost nobody actually does this, but the risk is there.
The 2nd reason is so you can place the little USB-IF logo on your product, reassuring people that your product complies with the USB specs. This logo, in the early days of USB, was very important. It's less so now. If you want it, you need to enumerate within $time (I forget the number of milliseconds) after you begin drawing power. If you don't, USB-IF doesn't like you and you can't put the logo on your product.
Both items 1 and 2 could be accomplished using just the USB controller in the USB device, with no driver needed ... But only if the USB controller lied about who it was. It would have to say, "I'm a hard disk", or "I'm a speaker". As soon as you lie, you're also not USB-IF compliant. Plus, it will look pretty unprofessional to have your battery charger show up on the hardware manifest as a hard drive. It would have been better to not enumerate at all, then to do that.
So, you need to supply a driver, if you're doing something that every OS doesn't have drivers for already, even if technically, it's not required.
So, really, this was Bill Gates fault. I knew we could lay this one on him if we dug deep enough. Windows should ship with OS drivers for USB battery chargers. Curse you Bill Gates, curse you.
Can't these these issues be solved by registering to the USB controller as "battery charger" and ignoringing the OS?
The USB spec doesn't include a class for battery charger.
Some mobile phones will not charge their batteries from the USB port of you don't have special software installed on the PC to activate that function.
The motivation is that you might not want to charge from USB all the time, especially if your notebook is currently running on batteries, too.
Of course it's much more practical to have a corresponding switch on the plugged in device, instead of having it in the PCs driver.
The motivation is that you might not want to charge from USB all the time, especially if your notebook is currently running on batteries, too.
Of course it's much more practical to have a corresponding switch on the plugged in device, instead of having it in the PCs driver.
Or, just unplug the charger.
The software apparently lets your computer tell you how much charge the batteries have.
Another issue is that USB ports have a pretty small power limit - 2.5 Watts, so using it as a charger is going to take significantly longer than what you plug into the wall...
The design of the trojan is odd. According to the Symantec analysis, it did a bunch of xor's on request/replies as a sort of obfuscation. Given the available commands all had GUID "magic numbers", only someone who had analyzed the source code could exploit the backdoor. If one did that, he surely would have observed the xor-ing and could easily add it into his trojan client. If the author wanted to be sure that his botnet was not hijacked, he should have made the trojan check signatures of instructions to verify origin.
Perhaps the xors were there to obfuscate the data on the wire so the nefariousness of the open port would not be so obvious to net admins? However, given that most companies would not forward 7777 traffic through their firewalls, this trojan was probably targeted toward home users without firewalls. Or, maybe it was designed as an exploit to be used after another means was used to get inside a corporate firewall?
Also, given that probably only a few computers out of a million had this trojan installed with 7777 available on the public 'net, how much effort would be required to portscan machines just to identify botnet members? And, was this even a true botnet? The built-in commands seemed to be designed around data harvesting (for identity theft?).
This whole design is very strange to me.
Perhaps the xors were there to obfuscate the data on the wire so the nefariousness of the open port would not be so obvious to net admins? However, given that most companies would not forward 7777 traffic through their firewalls, this trojan was probably targeted toward home users without firewalls. Or, maybe it was designed as an exploit to be used after another means was used to get inside a corporate firewall?
Also, given that probably only a few computers out of a million had this trojan installed with 7777 available on the public 'net, how much effort would be required to portscan machines just to identify botnet members? And, was this even a true botnet? The built-in commands seemed to be designed around data harvesting (for identity theft?).
This whole design is very strange to me.
Wow. Any ideas on how this got there? I just don't see the motivation there. Rogue addon at the factory? I don't see what use a battery manufacturer would have from a remote backdoor. I thought USB battery chargers were "dumb" devices.
>> "I thought USB battery chargers were "dumb" devices."
They are, but they offer "software" for stupid people who like installing crap. (I actually own this battery charger, it's pretty neat).
They are, but they offer "software" for stupid people who like installing crap. (I actually own this battery charger, it's pretty neat).
Oh, by "dumb" I meant that they do not actually exchange data with the host, just their device descriptor. Having read the Symantec link elsewhere in the comments, I see this is indeed the case. So you actually have to download the software yourself?
Yeah, you download the software yourself from the internet.
That said, it appears that the charger does communicate with the software on the host computer to tell it how well charged the batteries are.
That said, it appears that the charger does communicate with the software on the host computer to tell it how well charged the batteries are.
Did you install the software? If it's neat does the software have any point to it?
No I didn't install it. The charger has a light to say if the batteries are charged. I don't want some crappy poorly written big flashy dial popping up on my computer to say my batteries are 75% done.
So I don't know, it probably just displays a dial, some adverts for batteries, etc
So I don't know, it probably just displays a dial, some adverts for batteries, etc
The only machine in the factory in the cheap third world country with a CD burner was also the only one connected to the internet - so was the one that the techies browsed porn on and so was infected with everything.
ps. if you think this is unlikely - take a look at the crap on your CEO/CFO/salesman's laptops sometime.
ps. if you think this is unlikely - take a look at the crap on your CEO/CFO/salesman's laptops sometime.
We were interested in finding out how long this file had been available to the public. The compile time for the file is May 10, 2007
That's a looong time before anybody found out
That's a looong time before anybody found out
Symantec did an analysis on the Trojan: http://www.symantec.com/connect/fr/blogs/trojan-found-usb-ba...
I'm still wondering how many commodity devices come with a "driver CD". In the last 5-10 years I never needed any of them, as the devices were already fully supported on my Debian system. And I'm sure that is the case for MacOS and Windows, too.
The only interesting part of such a CD is the online manual, which is hopefully available as PDF and doesn't require any special software to read it.