BadUSB security flaw (massive undetectible USB reprogramming vulnerability)

  • Thread starter Thread starter bob mullen
  • Start date Start date
B

bob mullen

Massive, undetectable security flaw found in USB
http://www.extremetech.com/computin...-to-get-your-ps2-keyboard-out-of-the-cupboard

"This flaw, dubbed BadUSB by Security Research Labs in Berlin, leverages
the fact that every USB device has a controller chip. Whether it¡¦s your PC,
smartphone, external hard drive, or an audio breakout box, there¡¦s a USB
controller chip in every device that controls the USB connection to other
devices. It turns out, according to SR Labs, that these controllers have
firmware that can be reprogrammed to do a whole host of malicious things ¡X
and, perhaps most importantly, this reprogramming is almost impossible to
detect."
 
bob said:
Massive, undetectable security flaw found in USB
http://www.extremetech.com/computin...-to-get-your-ps2-keyboard-out-of-the-cupboard

"This flaw, dubbed BadUSB by Security Research Labs in Berlin, leverages
the fact that every USB device has a controller chip. Whether it’s your PC,
smartphone, external hard drive, or an audio breakout box, there’s a USB
controller chip in every device that controls the USB connection to other
devices.

Every computer hardware interface has a controller. You thought the
wires and foils handled the logic?
It turns out, according to SR Labs, that these controllers have
firmware that can be reprogrammed to do a whole host of malicious things —
and, perhaps most importantly, this reprogramming is almost impossible to
detect."

Same for the EEPROM holding your BIOS.
 
Massive, undetectable security flaw found in USB
http://www.extremetech.com/computing/187279-undetectable-indefensible- security-flaw-found-in-usb-its-time-to-get-your-ps2-keyboard-out-of-the-
cupboard

"This flaw, dubbed BadUSB by Security Research Labs in Berlin, leverages
the fact that every USB device has a controller chip. Whether it’s your
PC,
smartphone, external hard drive, or an audio breakout box, there’s a USB
controller chip in every device that controls the USB connection to
other devices. It turns out, according to SR Labs, that these
controllers have firmware that can be reprogrammed to do a whole host of
malicious things —
and, perhaps most importantly, this reprogramming is almost impossible
to detect."

I would like to raise two issues, one minor one major.

The minor one was that this was known to anyone who thought to look.
Perhaps we didn't know that you could just feed the device a faulty
firmware, but the idea that you could reprogram USB's was well known.

The major one is the alarm that *someone* may be trying to make matters
worse. The fact the feature-turned-flaw got a name with a non-trivial
capitalization is the first red flag. But the real proof of maliciousness
is in the proposal given by SR Labs about the way to "solve" the problem.

Their suggestion is cryptographic signing of the firmware which can only
possibly make the problem worse. As the things are today, you can compile
your own - known to be secure - firmware and upload it to the USB device,
thus solving the problem. If you don't have the know-how, you can pay a
consultant to do that for you. In other words, this is one of those lucky
few hardware problems that are solvable by the populace at large, with
zero effort (and zero money) required on the part of corporations.

Cryptographically signing the firmware, however, makes it impossible for
the people to solve the problem themselves, leaves the problem wide open
because to USB-peripheral-making corporation is going to spend money
fixing this (see addenum) and exposes everyone to NSA & friends which
will ofcouse have access to the secret keys one way or the other.

Addenum: USB peripherals that are important are cheap. Dime-a-dozen
cheap. That means the only way for a multinational to make a
notable profit is by making many of them. Which means any
problem (like this one) will be overwhelming. Additionally,
the only way to turn a profit when making these things is to
have a razor-thin margin. Which means the company has
insufficient reserves to deal with these problems.
Couple an overwhelming problem with barely any reserves for
solving it and you end up with no solution to speak of.

Addenum 2: the issue is actually detectable (with no extra equipment),
you just need to know what you are doing.
 
["Followup-To:" header set to alt.os.linux.]
Every computer hardware interface has a controller. You thought the
wires and foils handled the logic?

Yes, And?
Same for the EEPROM holding your BIOS.

Yes, but someone can lend you a usb stick to stick into your computer,
subverting it. They cannot stick their eeprom into your machine, nor can
they install junk on your eeprom without you perhaps noticing that they
have your computer.
 
Aleksandar said:
I would like to raise two issues, one minor one major.

The minor one was that this was known to anyone who thought to look.
Perhaps we didn't know that you could just feed the device a faulty
firmware, but the idea that you could reprogram USB's was well known.

The major one is the alarm that *someone* may be trying to make matters
worse. The fact the feature-turned-flaw got a name with a non-trivial
capitalization is the first red flag. But the real proof of maliciousness
is in the proposal given by SR Labs about the way to "solve" the problem.

Their suggestion is cryptographic signing of the firmware which can only
possibly make the problem worse. As the things are today, you can compile
your own - known to be secure - firmware and upload it to the USB device,
thus solving the problem. If you don't have the know-how, you can pay a
consultant to do that for you. In other words, this is one of those lucky
few hardware problems that are solvable by the populace at large, with
zero effort (and zero money) required on the part of corporations.

Cryptographically signing the firmware, however, makes it impossible for
the people to solve the problem themselves, leaves the problem wide open
because to USB-peripheral-making corporation is going to spend money
fixing this (see addenum) and exposes everyone to NSA & friends which
will ofcouse have access to the secret keys one way or the other.

Addenum: USB peripherals that are important are cheap. Dime-a-dozen
cheap. That means the only way for a multinational to make a
notable profit is by making many of them. Which means any
problem (like this one) will be overwhelming. Additionally,
the only way to turn a profit when making these things is to
have a razor-thin margin. Which means the company has
insufficient reserves to deal with these problems.
Couple an overwhelming problem with barely any reserves for
solving it and you end up with no solution to speak of.

Addenum 2: the issue is actually detectable (with no extra equipment),
you just need to know what you are doing.

The quickest solution, is to add a prompt to the "new hardware"
dialog.

"I think you have added a USB Mass Storage device"

"This device appears to be a web cam. It claims a composite
device block at the top level, with one UVC video device and
one audio device underneath that top level."

"Do you want to accept connection via these classes only ? Y/N"

That would not prevent a bugged HID from recording key presses.
So a HID faking a HID, you can't protect against that. But
if a webcam has a "network" or a "HID", the OS could restrict
the classes eventually discovered.

Say I present myself as a webcam, then five minutes later inside
the webcam, I add a third "HID" device under the composite device
at the top level. If the user had been queried about whether
this actually was a webcam, the OS could reject the HID that
pops up out of no-where, five minutes later.

Paul
 
William said:
["Followup-To:" header set to alt.os.linux.]
Every computer hardware interface has a controller. You thought the
wires and foils handled the logic?

Yes, And?
Same for the EEPROM holding your BIOS.

Yes, but someone can lend you a usb stick to stick into your computer,
subverting it. They cannot stick their eeprom into your machine, nor can
they install junk on your eeprom without you perhaps noticing that they
have your computer.

Reprogrammers have to run. That would be for EEPROM writing as well as
USB controller firmware updating. USB drives have been a sore point
regarding security. Smart users disable auto-run on removable media
devices. Thereafter the user would have to be conned into running a
program so it could reprogram the BIOS or the USB firmware, or a NIC
with firmware, or anything else with reprogrammable firmware.
 
Massive, undetectable security flaw found in USB

"This flaw, dubbed BadUSB by Security Research Labs in Berlin, leverages
the fact that every USB device has a controller chip. Whether it¡¦s your PC,
smartphone, external hard drive, or an audio breakout box, there¡¦s a USB
controller chip in every device that controls the USB connection to other
devices. It turns out, according to SR Labs, that these controllers have
firmware that can be reprogrammed to do a whole host of malicious things ¡X
and, perhaps most importantly, this reprogramming is almost impossible to
detect."

There was SD Card flaw which allowed to execute binary in the firmware,
there was a java issue in SIM Cards which allowed you to execute java
binaries. You will see all these kinds of issues, they tend to be
firmware and/or manufacturer specific. Even if there hadn't been any
hardware with software issues, it had been simple enough to make a
custom unit which could be used in a similar fashion.

The impact of the flaw will be small, as to get out the right number of
modified USB/SD/SIM to get any sort of "revenue" is costly and will get
few persons to actually use the hacked item. Compare this to sending out
some fake mail with an attachment to click which will install a small
boot virus which will fool UEFI by providing the microsoft windows keys
and gives the virus full control of the OS as it's run as a virtual
environment (don't worry, this kind of boot viruses are already
developed and most likely out there earning money or stealing
information for one or another organization).
 
William said:
["Followup-To:" header set to alt.os.linux.]
bob mullen wrote:

Massive, undetectable security flaw found in USB
http://www.extremetech.com/computin...-to-get-your-ps2-keyboard-out-of-the-cupboard

"This flaw, dubbed BadUSB by Security Research Labs in Berlin, leverages
the fact that every USB device has a controller chip. Whether it???s your PC,
smartphone, external hard drive, or an audio breakout box, there???s a USB
controller chip in every device that controls the USB connection to other
devices.

Every computer hardware interface has a controller. You thought the
wires and foils handled the logic?

Yes, And?
It turns out, according to SR Labs, that these controllers have
firmware that can be reprogrammed to do a whole host of malicious things ???
and, perhaps most importantly, this reprogramming is almost impossible to
detect."

Same for the EEPROM holding your BIOS.

Yes, but someone can lend you a usb stick to stick into your computer,
subverting it. They cannot stick their eeprom into your machine, nor can
they install junk on your eeprom without you perhaps noticing that they
have your computer.

Reprogrammers have to run. That would be for EEPROM writing as well as
USB controller firmware updating.

The big exposure that I see is some manufacturer of USB-sticks putting
funky code into the controller before it ever goes out the door... as a
"favor" to maybe the NSA, in exchange for some under-the-table funds...
or as an unofficial "contribution" by some employee who has a nefarious
agenda.
USB drives have been a sore point
regarding security.

I see this thread is now crossposted. Certainly there's the MS-Windows
issue of Windows being set up on the assumption that all users are not
only dumb but compliant.
Smart users disable auto-run on removable media
devices.

That should never, ever, be a default setting distributed with the
opsys. The user should *always* have to choose to opt-in to auto-run,
there's nothing dramatically difficult about a first-time prompt to see
what the user wants.
Thereafter the user would have to be conned into running a
program so it could reprogram the BIOS or the USB firmware, or a NIC
with firmware, or anything else with reprogrammable firmware.

It isn't clear to me how the user can know that he is not being conned.
Both Windows (last time I used it) and linux lack any "master console
mode" so the user can tell whether a prompt is legitimately from the
opsys or a spoof-dialog. It could certainly be done via a driver that
gloms the last line of the display device for system status, thus making
that line unavailable to any application.
 
The big exposure that I see is some manufacturer of USB-sticks putting
funky code into the controller before it ever goes out the door... as
a "favor" to maybe the NSA, in exchange for some under-the-table
funds... or as an unofficial "contribution" by some employee who has a
nefarious agenda.

As shown in the documents publicized by Edward Snowden, the NSA does
actively employ non-USA'n companies to intercept all kinds of ITC-
related devices when they ship from their respective manufacturers, put
backdoors in them, and then put them back on their path to the
distributors and retailers.
I see this thread is now crossposted.

It was already crossposted from the beginning, Cranky. There appears to
be a sufficiently high number of people eager for flamewars, as we've
already been seeing on alt.os.linux recently. If it ain't between the
GNU/Linux people and the Mac/iDevices people, then it's between the
GNU/Linux people and the Windows people.

I smell a rat.
Both Windows (last time I used it) and linux lack any "master
console mode" so the user can tell whether a prompt is legitimately
from the opsys or a spoof-dialog.

Experienced GNU/Linux users - we're not talking of the Ubuntu/Mint crowd
here - know that vc/12 shows the output of the syslog daemon, and this
includes kernel messages.

One switches to vc/12 ("virtual console #12") by pressing
(Ctrl+)Alt+F12. It's a read-only console, so one cannot interact with
the operating system from there.

Another option is to check the kernel ring buffer directly via dmesg in
a terminal emulator window.
 
William said:
["Followup-To:" header set to alt.os.linux.]
bob mullen wrote:

Massive, undetectable security flaw found in USB
http://www.extremetech.com/computin...-to-get-your-ps2-keyboard-out-of-the-cupboard

"This flaw, dubbed BadUSB by Security Research Labs in Berlin, leverages
the fact that every USB device has a controller chip. Whether it???s your PC,
smartphone, external hard drive, or an audio breakout box, there???s a USB
controller chip in every device that controls the USB connection to other
devices.

Every computer hardware interface has a controller. You thought the
wires and foils handled the logic?

Yes, And?
It turns out, according to SR Labs, that these controllers have
firmware that can be reprogrammed to do a whole host of malicious things ???
and, perhaps most importantly, this reprogramming is almost impossible to
detect."

Same for the EEPROM holding your BIOS.

Yes, but someone can lend you a usb stick to stick into your computer,
subverting it. They cannot stick their eeprom into your machine, nor can
they install junk on your eeprom without you perhaps noticing that they
have your computer.

Reprogrammers have to run. That would be for EEPROM writing as well as
USB controller firmware updating. USB drives have been a sore point
regarding security. Smart users disable auto-run on removable media
devices. Thereafter the user would have to be conned into running a
program so it could reprogram the BIOS or the USB firmware, or a NIC
with firmware, or anything else with reprogrammable firmware.

No, the usb stick's eeprom has already been reprogrammed with the
malware. You stick it into your computer and that firmware claims it is
both a usbstick and a keyboard say. Your system sets it up (You already
said that you wanted a memory device by plugging it in) and then types
commands into your machine.
Keyboards are pretty automatically recognized. I have never had to say
"Yes, I want that keyboard attached" when a keyboard was plugged into my
computer running Linux.
 
On 08/01/2014 03:41 AM, VanguardLH wrote: ....

That should never, ever, be a default setting distributed with the
opsys. The user should *always* have to choose to opt-in to auto-run,
there's nothing dramatically difficult about a first-time prompt to see
what the user wants.

For a keyboard?
I have neer been asked if I want my keyboard attached.
It isn't clear to me how the user can know that he is not being conned.
Both Windows (last time I used it) and linux lack any "master console
mode" so the user can tell whether a prompt is legitimately from the
opsys or a spoof-dialog. It could certainly be done via a driver that
gloms the last line of the display device for system status, thus making
that line unavailable to any application.

??? It is a keyboard. What harm could there be in a keyboard? :-)
 
[snip]
The quickest solution, is to add a prompt to the "new hardware"
dialog.

"I think you have added a USB Mass Storage device"

"This device appears to be a web cam. It claims a composite
device block at the top level, with one UVC video device and
one audio device underneath that top level."

"Do you want to accept connection via these classes only ? Y/N"

How many users will simply click Yes just as they do with so many
other arcane prompts?

[snip]

Sincerely,

Gene Wirchenko
 
Gene said:
[snip]
The quickest solution, is to add a prompt to the "new hardware"
dialog.

"I think you have added a USB Mass Storage device"

"This device appears to be a web cam. It claims a composite
device block at the top level, with one UVC video device and
one audio device underneath that top level."

"Do you want to accept connection via these classes only ? Y/N"

How many users will simply click Yes just as they do with so many
other arcane prompts?

[snip]

Sincerely,

Gene Wirchenko

The OS side has ultimate control. A bugged device cannot
force an endpoint connection. It is up to the OS to set it
up.

Either the OS or AV code, could hook the routine that
sets up new USB devices. If the characteristics of the
devices were recorded by the manufacturers of them,
an AV code could simply deny the connection entirely,
then present a dialog box indicating what has happened.
The only time the user sees a dialog in this case,
is when the thing they plugged in, doesn't work at all.

Using the user as a filter, avoided the need for a
central registry. But if you wanted to do the
extra work, you could simply lock out devices
that don't match their hardware template (i.e.
Logitech 9000 has composite+video+audio but no HID).

Paul
 
Gene said:
How many users will simply click Yes just as they do with so many
other arcane prompts?

Most. That's their business.

Seems reasonable to me for the OS to accept the first keyboard and mouse
that offer themselves but at least ask permission before accepting any
more of those.
 
For a keyboard?
I have neer been asked if I want my keyboard attached.


??? It is a keyboard. What harm could there be in a keyboard? :-)

A keyboards is *not* a removable-media device.

Optical and hard disk drives, thumb drives, & flash cards are removable
media...
 
A keyboards is *not* a removable-media device.

Optical and hard disk drives, thumb drives, & flash cards are removable
media...

But maybe I'm wrong in thinking the firmware can't execute as a keyboard
unless the drive is configured to autorun.

I'm willing to learn...Or at least have my mind boggled.
 
John said:
A built-in hub might have DMA. I don't see how an endpoint device
could. On the other hand, as it would be idiotic to allow
externally-pluggable devices DMA, I would not be surprised if pc
manufacturers have done so.


USB is not mentioned.

Yes, I'd heard of the Firewire (1394) attack, but never USB.

Even with USB OTP, there would be a negotiation process
before some kind of endpoints were set up. I don't know
any details of OTP, so don't know if there are any
weird exposures there. I would expect a driver to work
the negotiation, rather than logic gates in hardware
to do it.

Paul
 
Back
Top