Re: openbsd and badusb
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: SCSI4 0/direct removable serial.0951168cAC90909F sd4: 15008MB, 512 bytes/sector, 30736384 sectors , 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: SCSI4 0/direct removable , 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
Re: openbsd and badusb
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. >>> 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. >>> 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). >>> 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 :) >>> 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
Re: [Bulk] Re: openbsd and badusb
On 04-08-2014 11:11, Kevin Chadwick wrote: > previously on this list Giancarlo Razzolini contributed: > >> 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]
Re: [Bulk] Re: openbsd and badusb
previously on this list Giancarlo Razzolini contributed: > 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 ___
Re: openbsd and badusb
On 02-08-2014 04:20, Dmitry Orlov wrote: > 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]
Re: openbsd and badusb
> #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.
Re: openbsd and badusb
OpenBSD deny such devices. Don't worry :) And, infection does not penetrate NON-Windows systems. Wait blackhat and read reports. On 02.08.2014 03:27, patrick keshishian wrote: On 8/1/14, Gustav Fransson Nyvell wrote: On 08/01/14 23:01, Ted Unangst wrote: 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...
Re: openbsd and badusb
On 8/1/14, Gustav Fransson Nyvell wrote: > On 08/01/14 23:01, Ted Unangst wrote: >> 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...
Re: openbsd and badusb
#badbios redux? I seem to recall it was suspected that badbios started with an infected USB stick. On 8/1/14, Ted Unangst wrote: > 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.
Re: openbsd and badusb
On 08/01/14 23:01, Ted Unangst wrote: 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.
openbsd and badusb
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.
