Discussion:
openbsd and badusb
Ted Unangst
2014-08-01 21:01:11 UTC
Permalink
You may have heard about the "badusb" talk coming at blackhat. In
theory, we should wait to watch the talk and see what it's actually
about, but since some people can't wait that long, here's a few
thoughts. (I'm a little surprised nobody has asked here already. I have
some time free, thought I'd beat the rush. :))

The claims on the main page, https://srlabs.de/badusb/, are fairly
reasonable if a little vague. Other claims I'm reading elsewhere
appear a little overhyped. In order of increasing danger...

0. The final claim is that once infected, you'll always be infected
because disinfection is nigh impossible. Meh. The same could be said
of the firefox exploit of the week. It too can reprogram your bios or
persist itself in any number of ways.

1. They're exploiting all manner of Windows specific autorun
functionality to install or configure drivers. By default, OpenBSD
will do just about nothing when a USB device is plugged in, so this is
not a serious concern.

2. They have created a rogue keyboard device which will type naughty
commands. In theory, the same keyboard could type "rm -rf ~" into an
xterm. This is a tiny bit more challenging since it probably depends
on your desktop environment and window manager, but presumably your
attacker will know all that. So yeah, vulnerable. But at the same
time, I could also train a monkey to type that command and strap it to
your normal not backdoored keyboard. Beware the badmonkey attack, too.

3. A storage device may lie about the contents of a file. Sometimes it
will say one thing (so it looks safe on this computer), sometimes it
will say another (so it installs a backdoor on that computer). Don't
install OpenBSD from media you don't control. Technically, signing the
sets won't help since the backdoor installer might have a bogus key on
it (or a bogus installer that doesn't check). You can always pxeboot
and hope that the firmware in your ethernet card is more trustworthy.

They don't appear to mention two other avenues of exploitation,
which may be more practical. I refer specifically to OpenBSD,
though there's no such limitation. First, the USB stack has a number
of known races and other bugs, especially around attach/detach and
error handling. If a rogue device attached and detached itself several
times, it could likely corrupt the kernel heap. Game over.

Second, any USB disk, even one with a normal firmware, can have an evil
filesystem image on it. By this, I mean the metadata that the kernel
reads is corrupt, not that it has naughty files. There have been crash
reports when mounting corrupted (and even not corrupted) (e.g.)
MSDOSFS disks. The kernel is a little too trusting that a filesystem
is what it claims to be. There are probably exploitable vulns here,
too.

All that to basically say "don't panic" (that's the kernel's job).
Fixing filesystem bugs is something we'll do, of course, but it's not
a priority for me to sit down and start fuzzing Right Now. Same for
miscellaneous bugs in the USB stack.
Gustav Fransson Nyvell
2014-08-01 22:20:06 UTC
Permalink
Post by Ted Unangst
You may have heard about the "badusb" talk coming at blackhat. In
theory, we should wait to watch the talk and see what it's actually
about, but since some people can't wait that long, here's a few
thoughts. (I'm a little surprised nobody has asked here already. I have
some time free, thought I'd beat the rush. :))
The claims on the main page, https://srlabs.de/badusb/, are fairly
reasonable if a little vague. Other claims I'm reading elsewhere
appear a little overhyped. In order of increasing danger...
0. The final claim is that once infected, you'll always be infected
because disinfection is nigh impossible. Meh. The same could be said
of the firefox exploit of the week. It too can reprogram your bios or
persist itself in any number of ways.
1. They're exploiting all manner of Windows specific autorun
functionality to install or configure drivers. By default, OpenBSD
will do just about nothing when a USB device is plugged in, so this is
not a serious concern.
2. They have created a rogue keyboard device which will type naughty
commands. In theory, the same keyboard could type "rm -rf ~" into an
xterm. This is a tiny bit more challenging since it probably depends
on your desktop environment and window manager, but presumably your
attacker will know all that. So yeah, vulnerable. But at the same
time, I could also train a monkey to type that command and strap it to
your normal not backdoored keyboard. Beware the badmonkey attack, too.
3. A storage device may lie about the contents of a file. Sometimes it
will say one thing (so it looks safe on this computer), sometimes it
will say another (so it installs a backdoor on that computer). Don't
install OpenBSD from media you don't control. Technically, signing the
sets won't help since the backdoor installer might have a bogus key on
it (or a bogus installer that doesn't check). You can always pxeboot
and hope that the firmware in your ethernet card is more trustworthy.
They don't appear to mention two other avenues of exploitation,
which may be more practical. I refer specifically to OpenBSD,
though there's no such limitation. First, the USB stack has a number
of known races and other bugs, especially around attach/detach and
error handling. If a rogue device attached and detached itself several
times, it could likely corrupt the kernel heap. Game over.
Second, any USB disk, even one with a normal firmware, can have an evil
filesystem image on it. By this, I mean the metadata that the kernel
reads is corrupt, not that it has naughty files. There have been crash
reports when mounting corrupted (and even not corrupted) (e.g.)
MSDOSFS disks. The kernel is a little too trusting that a filesystem
is what it claims to be. There are probably exploitable vulns here,
too.
All that to basically say "don't panic" (that's the kernel's job).
Fixing filesystem bugs is something we'll do, of course, but it's not
a priority for me to sit down and start fuzzing Right Now. Same for
miscellaneous bugs in the USB stack.
This wouldn't be such a big problem if hardware manufacturers weren't so
mysterious about their firmware and ways to install such firmware. I
mean from the owner/operator/maintenance perspective. Maybe the EU
should force them to help us...
--
This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
patrick keshishian
2014-08-01 22:27:23 UTC
Permalink
Post by Gustav Fransson Nyvell
Post by Ted Unangst
You may have heard about the "badusb" talk coming at blackhat. In
theory, we should wait to watch the talk and see what it's actually
about, but since some people can't wait that long, here's a few
thoughts. (I'm a little surprised nobody has asked here already. I have
some time free, thought I'd beat the rush. :))
The claims on the main page, https://srlabs.de/badusb/, are fairly
reasonable if a little vague. Other claims I'm reading elsewhere
appear a little overhyped. In order of increasing danger...
0. The final claim is that once infected, you'll always be infected
because disinfection is nigh impossible. Meh. The same could be said
of the firefox exploit of the week. It too can reprogram your bios or
persist itself in any number of ways.
1. They're exploiting all manner of Windows specific autorun
functionality to install or configure drivers. By default, OpenBSD
will do just about nothing when a USB device is plugged in, so this is
not a serious concern.
2. They have created a rogue keyboard device which will type naughty
commands. In theory, the same keyboard could type "rm -rf ~" into an
xterm. This is a tiny bit more challenging since it probably depends
on your desktop environment and window manager, but presumably your
attacker will know all that. So yeah, vulnerable. But at the same
time, I could also train a monkey to type that command and strap it to
your normal not backdoored keyboard. Beware the badmonkey attack, too.
3. A storage device may lie about the contents of a file. Sometimes it
will say one thing (so it looks safe on this computer), sometimes it
will say another (so it installs a backdoor on that computer). Don't
install OpenBSD from media you don't control. Technically, signing the
sets won't help since the backdoor installer might have a bogus key on
it (or a bogus installer that doesn't check). You can always pxeboot
and hope that the firmware in your ethernet card is more trustworthy.
They don't appear to mention two other avenues of exploitation,
which may be more practical. I refer specifically to OpenBSD,
though there's no such limitation. First, the USB stack has a number
of known races and other bugs, especially around attach/detach and
error handling. If a rogue device attached and detached itself several
times, it could likely corrupt the kernel heap. Game over.
Second, any USB disk, even one with a normal firmware, can have an evil
filesystem image on it. By this, I mean the metadata that the kernel
reads is corrupt, not that it has naughty files. There have been crash
reports when mounting corrupted (and even not corrupted) (e.g.)
MSDOSFS disks. The kernel is a little too trusting that a filesystem
is what it claims to be. There are probably exploitable vulns here,
too.
All that to basically say "don't panic" (that's the kernel's job).
Fixing filesystem bugs is something we'll do, of course, but it's not
a priority for me to sit down and start fuzzing Right Now. Same for
miscellaneous bugs in the USB stack.
This wouldn't be such a big problem if hardware manufacturers weren't so
mysterious about their firmware and ways to install such firmware. I
mean from the owner/operator/maintenance perspective. Maybe the EU
should force them to help us...
oh the irony...
Dmitry Orlov
2014-08-02 07:20:11 UTC
Permalink
OpenBSD deny such devices.
Don't worry :) And, infection does not penetrate NON-Windows systems.
Wait blackhat and read reports.
Post by patrick keshishian
Post by Gustav Fransson Nyvell
Post by Ted Unangst
You may have heard about the "badusb" talk coming at blackhat. In
theory, we should wait to watch the talk and see what it's actually
about, but since some people can't wait that long, here's a few
thoughts. (I'm a little surprised nobody has asked here already. I have
some time free, thought I'd beat the rush. :))
The claims on the main page, https://srlabs.de/badusb/, are fairly
reasonable if a little vague. Other claims I'm reading elsewhere
appear a little overhyped. In order of increasing danger...
0. The final claim is that once infected, you'll always be infected
because disinfection is nigh impossible. Meh. The same could be said
of the firefox exploit of the week. It too can reprogram your bios or
persist itself in any number of ways.
1. They're exploiting all manner of Windows specific autorun
functionality to install or configure drivers. By default, OpenBSD
will do just about nothing when a USB device is plugged in, so this is
not a serious concern.
2. They have created a rogue keyboard device which will type naughty
commands. In theory, the same keyboard could type "rm -rf ~" into an
xterm. This is a tiny bit more challenging since it probably depends
on your desktop environment and window manager, but presumably your
attacker will know all that. So yeah, vulnerable. But at the same
time, I could also train a monkey to type that command and strap it to
your normal not backdoored keyboard. Beware the badmonkey attack, too.
3. A storage device may lie about the contents of a file. Sometimes it
will say one thing (so it looks safe on this computer), sometimes it
will say another (so it installs a backdoor on that computer). Don't
install OpenBSD from media you don't control. Technically, signing the
sets won't help since the backdoor installer might have a bogus key on
it (or a bogus installer that doesn't check). You can always pxeboot
and hope that the firmware in your ethernet card is more trustworthy.
They don't appear to mention two other avenues of exploitation,
which may be more practical. I refer specifically to OpenBSD,
though there's no such limitation. First, the USB stack has a number
of known races and other bugs, especially around attach/detach and
error handling. If a rogue device attached and detached itself several
times, it could likely corrupt the kernel heap. Game over.
Second, any USB disk, even one with a normal firmware, can have an evil
filesystem image on it. By this, I mean the metadata that the kernel
reads is corrupt, not that it has naughty files. There have been crash
reports when mounting corrupted (and even not corrupted) (e.g.)
MSDOSFS disks. The kernel is a little too trusting that a filesystem
is what it claims to be. There are probably exploitable vulns here,
too.
All that to basically say "don't panic" (that's the kernel's job).
Fixing filesystem bugs is something we'll do, of course, but it's not
a priority for me to sit down and start fuzzing Right Now. Same for
miscellaneous bugs in the USB stack.
This wouldn't be such a big problem if hardware manufacturers weren't so
mysterious about their firmware and ways to install such firmware. I
mean from the owner/operator/maintenance perspective. Maybe the EU
should force them to help us...
oh the irony...
Giancarlo Razzolini
2014-08-04 10:54:33 UTC
Permalink
Post by Dmitry Orlov
infection does not penetrate NON-Windows systems.
Yes, because windows automatically runs anything you throw at it.
autorun is an abomination, but it can be disabled. That is not to say
that some badusb device couldn't lie to OpenBSD, or any other *nix for
that matter, and use of those devices could be harmful if the attack is
targeted. I don't see anything new about this attack. The theory behind
it was invented with USB itself. Just read the USB spec. It's completely
based on trust. And there is little the OS can do to check if a what a
USB device claimed to be, is what it actually is.

Cheers,

--
Giancarlo Razzolini
GPG: 4096R/77B981BC

[demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Kevin Chadwick
2014-08-04 14:11:18 UTC
Permalink
Post by Giancarlo Razzolini
I don't see anything new about this attack. The theory behind
it was invented with USB itself.
I haven't looked into it but thought it might have something to do with
"On the Go" but I guess not then.
--
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
_______________________________________________________________________
Giancarlo Razzolini
2014-08-04 16:17:39 UTC
Permalink
Post by Kevin Chadwick
Post by Giancarlo Razzolini
I don't see anything new about this attack. The theory behind
it was invented with USB itself.
I haven't looked into it but thought it might have something to do with
"On the Go" but I guess not then.
A simple search of "usb flash drive atack" will yield a lot of results,
some many years old. Many exploiting windows autorun feature. You can
even reprogram your flash drive with another's firmware. There are even
some russian websites on the matter with lots of firmwares and tools to
modify your device:

http://www.usbdev.ru
http://flashboot.ru/

Perhaps the only thing "new" about this badusd is the rogue keyboard
emulation. I might be wrong. But it's nothing like they only now
discovered an usb protocol vulnerability. Let's just wait their blackhat
presentation, when they will allegedly release the poc's.

Cheers,

--
Giancarlo Razzolini
GPG: 4096R/77B981BC

[demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Franchini Fabien
2014-08-05 12:50:25 UTC
Permalink
Hello !

I'm not sure that this exploit affect only Windows system.
Autorun != USB stick firmware. Autorun is a part of the
Windows system wich configure the device when it's mounted.
(See : https://en.wikipedia.org/wiki/AutoRun for more information about)

The USB stick firmware is like the BIOS... Without it your stick can't
run. All hardwares provide an embedded firmware.

The 'BadUSB' exploit this firmware and there's multiple possibility
to do malicious things.
Post by Ted Unangst
0. The final claim is that once infected, you'll always be infected
because disinfection is nigh impossible.
I'm very sceptic if you can infect that firmware it's possible to disinfect it.
But yes it must be very difficult to detect that.
Post by Ted Unangst
Meh. The same could be said
of the firefox exploit of the week. It too can reprogram your bios or
persist itself in any number of ways.
Yes of course, but that technique is a new vector of infection very powerfull.
With that you're able enter in closed network. (If the exchange USB stick of course).
Post by Ted Unangst
1. They're exploiting all manner of Windows specific autorun
functionality to install or configure drivers. By default, OpenBSD
will do just about nothing when a USB device is plugged in, so this is
not a serious concern.
It's not an AutoRun exploit :)
Post by Ted Unangst
2. They have created a rogue keyboard device which will type naughty
commands. In theory, the same keyboard could type "rm -rf ~" into an
xterm.
Here's the interesting part. I think with that technique you can spoof a
keyboard. Even in OpenBSD, when you plug a keyboard or a mouse OBSD
detect it and you can use it directly. The infected USB can tell to the system :
"I'm not an USB stick but a keyboard". With that fact I'm sure there are a lot
of malicious possibilities.


Cheers !

Fabien Franchini
patrick keshishian
2014-08-01 22:25:43 UTC
Permalink
#badbios redux?
I seem to recall it was suspected that badbios started
with an infected USB stick.
Post by Ted Unangst
You may have heard about the "badusb" talk coming at blackhat. In
theory, we should wait to watch the talk and see what it's actually
about, but since some people can't wait that long, here's a few
thoughts. (I'm a little surprised nobody has asked here already. I have
some time free, thought I'd beat the rush. :))
The claims on the main page, https://srlabs.de/badusb/, are fairly
reasonable if a little vague. Other claims I'm reading elsewhere
appear a little overhyped. In order of increasing danger...
0. The final claim is that once infected, you'll always be infected
because disinfection is nigh impossible. Meh. The same could be said
of the firefox exploit of the week. It too can reprogram your bios or
persist itself in any number of ways.
1. They're exploiting all manner of Windows specific autorun
functionality to install or configure drivers. By default, OpenBSD
will do just about nothing when a USB device is plugged in, so this is
not a serious concern.
2. They have created a rogue keyboard device which will type naughty
commands. In theory, the same keyboard could type "rm -rf ~" into an
xterm. This is a tiny bit more challenging since it probably depends
on your desktop environment and window manager, but presumably your
attacker will know all that. So yeah, vulnerable. But at the same
time, I could also train a monkey to type that command and strap it to
your normal not backdoored keyboard. Beware the badmonkey attack, too.
3. A storage device may lie about the contents of a file. Sometimes it
will say one thing (so it looks safe on this computer), sometimes it
will say another (so it installs a backdoor on that computer). Don't
install OpenBSD from media you don't control. Technically, signing the
sets won't help since the backdoor installer might have a bogus key on
it (or a bogus installer that doesn't check). You can always pxeboot
and hope that the firmware in your ethernet card is more trustworthy.
They don't appear to mention two other avenues of exploitation,
which may be more practical. I refer specifically to OpenBSD,
though there's no such limitation. First, the USB stack has a number
of known races and other bugs, especially around attach/detach and
error handling. If a rogue device attached and detached itself several
times, it could likely corrupt the kernel heap. Game over.
Second, any USB disk, even one with a normal firmware, can have an evil
filesystem image on it. By this, I mean the metadata that the kernel
reads is corrupt, not that it has naughty files. There have been crash
reports when mounting corrupted (and even not corrupted) (e.g.)
MSDOSFS disks. The kernel is a little too trusting that a filesystem
is what it claims to be. There are probably exploitable vulns here,
too.
All that to basically say "don't panic" (that's the kernel's job).
Fixing filesystem bugs is something we'll do, of course, but it's not
a priority for me to sit down and start fuzzing Right Now. Same for
miscellaneous bugs in the USB stack.
Theo de Raadt
2014-08-02 23:14:22 UTC
Permalink
Post by patrick keshishian
#badbios redux?
I seem to recall it was suspected that badbios started
with an infected USB stick.
I recall differently: badbios required a yellow reporter.
David Vasek
2014-08-09 10:59:56 UTC
Permalink
Hello,

I have already met something of that kind. Not exactly, but very close. A
USB flash drive that changes its vendor and model on the fly. Both strings
and IDs changed. Light intensity of the blinking LED also changed at the
same time. Just plug and unplug. I think that in a similar way as some
fish can change their sex, some USB devices can change their manufacturer
during their life.

Originally it was:

umass1 at uhub0 port 4 configuration 1 interface 0 "Kingston DT Elite 3.0" rev 2.10/1.00 addr 3
umass1: using SCSI over Bulk-Only
scsibus4 at umass1: 2 targets, initiator 0
sd4 at scsibus4 targ 1 lun 0: <Kingston, DT Elite 3.0, 1.01> SCSI4 0/direct removable serial.0951168cAC909000009F
sd4: 15008MB, 512 bytes/sector, 30736384 sectors

<unplug>, <plug in again two minutes later>

umass1 at uhub0 port 4 configuration 1 interface 0 "SKYMEDI USB Drive" rev 2.10/1.00 addr 2
umass1: using SCSI over Bulk-Only
scsibus4 at umass1: 2 targets, initiator 0
sd4 at scsibus4 targ 1 lun 0: <SKYMEDI, USB Drive, 1.00> SCSI4 0/direct removable

<unplug again>, <plug in once more>

umass1 at uhub0 port 4 configuration 1 interface 0 " " rev 2.10/1.00 addr 3
umass1: using SCSI over Bulk-Only
scsibus4 at umass1: 2 targets, initiator 0
sd4 at scsibus4 targ 1 lun 0: <, , 1.00> SCSI4 0/direct removable
sd4: 15008MB, 512 bytes/sector, 30736384 sectors

It stays with that blank vendor so far, only ocassionaly it reports itself
as SKYMEDI. I never saw Kingston again. The stored data remained
untouched, at least I didn't encounter any problem.

I think it is more likely a buggy firmware from Kingston (or from Skymedi,
who apparently is the real OEM manufacturer of the controller) rather than
a failing hardware.

Regards,
David

Loading...