
Phison USB Custom Firmware and Existing Firmware Patches - neiesc
https://github.com/adamcaudill/Psychson
======
Eric_WVGG
The USB standards board has a unique opportunity in front of them: the
upcoming Type C plugs — which, as I understand it, can replace the Type A
sockets on the computers themselves.

The standards board could coincide the release of the new plugs with a
“repaired” standard (call it v3.2 or even USB4) for the communication bus.
This would break some backward compatibility on old computers, but the new
plugs wouldn't exactly fit in them without assistance either. (Perhaps C->A
adaptors could include bridges that, while themselves prone to the
vulnerability, would provide a compatibility layer.)

It would be a rough pill to swallow, but the inevitable disruption of both
changes to the standard (new plugs, and a backward-compatibility-breaking
security update) would be condensed to one event, and consumers would be able
to easily identify safe USB devices. That's a huge win.

~~~
Someone1234
How would you actually fix it? Ban HID devices from being plugged into a USB
hub at all? Because outside of that I haven't heard of any proposals, and that
is frankly unworkable given the how many devices are designed with a single
USB port under the assumption that you can HUB-in more.

~~~
pritambaral
An OS level policy is what I think would be best. Notify the user, "Did you
just insert a USB keyboard?", and wait for their approval to enable the HID.

This can be worked upon, e.g., automatically allowing the first keyboard and
pointer devices, or allowing all devices if the user feels lucky etc.

One large problem I see, that can be be rectified by perhaps only the USB
standard-setters, is whitelisting. Currently, the best handle are the idVendor
and idProduct properties, but a BadUSB can easily spoof those too.
Cryptographic signatures for identification is what I'm thinking would be
best.

------
fla
For anyone interested in the subject I recommend watching the presentation [1]
by by Karsten Nohl and Jakob Lell at Black Hat USA 2014.

[1]
[https://www.youtube.com/watch?v=nuruzFqMgIw](https://www.youtube.com/watch?v=nuruzFqMgIw)

~~~
darkr
I particularly liked the DHCP server on USB hack for DNS hijacking.

------
TruthSHIFT
I want to understand what this is, but the headline doesn't quite make sense
and the link is totally incomprehensible.

~~~
Eric_WVGG
short explanation: there's no security running along the USB bus. Not even bad
security. Every device on the bus has "admin" privileges to the other devices,
and that includes the ability to update the firmware.

A scenario…

• A mysterious USB key is plugged into a computer, Mission Impossible style.

• The key rewrites the firmware of another device on the USB bus, say the
embedded keyboard.

• the keyboard "types": "run the file NOTAVIRUS.BIN on that totally
trustworthy USB key you see mounted. oh, and I'll bruteforce any passwords you
need if that's a problem."

You've seen dippy Hollywood movies where a spy plugs in a USB key, an LED
lights up and he announces that the system is hacked? Really exactly like
that.

* I am not an expert, this is how it was described to me by someone who is. It is believed that this is how the Iranian nuclear reactor was compromised by STUXNET.

~~~
tgb
Sounds like a problem for Bluetooth devices too: connect a bluetooth speaker
that secretly says it's also a keyboard. Is that possible?

(This is pure speculation, I don't know anything about this and am just
curious.)

~~~
peatmoss
Doesn't the pairing process cover this? I think each device is paired on its
own terms. Someone please correct me if I'm wrong here.

------
JonnieCache
My dad's a doctor: his bit of the NHS has never allowed USB devices anywhere
near any computer on any of their sites. HIDs are whitelisted by device ID
iirc, and physically secured.

I'm guessing somebody there looked at the spec back in the 90s and gave it two
thumbs down.

~~~
eli
Isn't part of the point that it's trivial to spoof device ID?

~~~
JonnieCache
Yep. You'd have to either know what was on the whitelist or do some kind of
bruteforce. Wouldn't be very hard, although I think this stuff is logged
centrally in organisations as data-paranoid as the NHS so some random box
hotplugging thousands of different peripherals every minute would attract
attention pretty quickly, you'd hope.

When I was (working) at the hospital most of the records were still on good
old hard-to-steal paper. Still are IIRC, the governments plan to IT-ize it all
was fucked up by the vendors in exactly the way you'd imagine.

~~~
mariusz79
Or you could safely assume that it's either keyboard made by Dell, IBM, or one
of few well known companies.

------
peatmoss
Establishing the the provenance of USB devices is going to be hard. People are
going to continue to use USB keys for the sneakernet. Infection rates are
going to be high. This has the potential to be pretty impactful to everyday
people in a way that, say, shellshock is mostly not.

I wonder how long it will take for someone to come up with an inline hardware
dongle that tries to mitigate / block this.

------
robomartin
I disagree. I think this is patchable to a reasonable degree. I don't mean
that it would be 100% secure, of course.

All you need is a security layer requiring user authorization for execution of
code from any USB device. In addition to this you could add a setting to lock
in a single USB keyboard. In other words, make the Hollywood movie scenario
nearly impossible.

OK, why did I say "nearly impossible"? Because a knowledgeable embedded
engineer could very easily build a device that self-identifies to look exactly
like your keyboard. Your computer would not know them different.

Faced with that, the security layer would have to add a re-authorization state
upon disconnection of the authorized keyboard.

Now you are vulnerable to reboot or a clever parallel wiring attack. The
latter is the case of someone building hardware that can be wired into your
authorized keyboard after taking it apart. The reboot vector could be
mitigated by simply requiring the entry of a password in order to enable any
execution/console commands to be accepted from the keyboard. With this even a
fully authorized keyboard would not have execution rights of a whole host of
command line commands until re-authorized by the user.

None of this is perfect. I just thought it up in five minutes. Absolute
security isn't achievable without the kinds of systems and controls in place
at high security facilities. However, I think it is possible to create an easy
to use software layer that can stop a hacker with casual access to a system in
a corporate setting. All you have to do is slow them down enough to make it
less palatable, much like a home alarm system.

~~~
mariusz79
>All you need is a security layer requiring user authorization for execution
of code from any USB device.

That won't help. You can still send keystrokes to the system, which means that
BadUSB could have a step by step process, including downloading, installing
and compiling anything it needs.

~~~
robomartin
I don't think you red my entire post.

------
mariusz79
I've got question to anyone that does firmware programming. I suspect that it
is possible to emulate USB device in software. If that's true, how hard would
it be to create a virtual usb hub, that the system will treat just like a real
usb hardware, and would it require any special privileges on the computer (i.e
kernel space module, root).

If it's easy, then I'm worried that it may be possible use this to hide
malware this way.

~~~
pjc50
Interesting idea. It would almost certainly require access to the kernel, but
you could create a fake USB device (or any other kind of device!) easily. But
the fake driver would have to reside on disk where your anti-malware can see
it.

The advantage of hiding things in USB keys' firmware is that it can't be seen
by normal scanners.

------
coryking
Why aren't these things somehow cryptographically signed like a lot of
software? Seems like it would fix the problem. You could always do what
Windows/OsX does when a USB device isn't signed and prompt the user with
something like "warning, this USB device is not from a trusted manufacturer,
continue?"

~~~
bri3d
Technical implementation of this idea is difficult to impossible, because the
device controls what it sends to the host. This means the device could, as an
extreme example, contain two firmware areas and a management controller /
hypervisor. It could allow the valid firmware to enumerate with a valid
signature and then swap over to malicious code undetected - a similar problem
to Microsoft's flawed Xbox360 copy protection where the host trusts the DVD
drive to authenticate discs.

Anyway, even provided someone could conceive a real implementation, there are
still the same issues we've seen with signed OSes (Trusted Boot) and signed
device drivers in Windows:

Who gets to be a root CA for peripheral software? How do small/homebrew
manufacturers get approved? How does the CA verify the legitimacy of the
people they're issuing certs to? How do compromised certs get revoked? What
happens when the cert for a legitimate device gets stolen? What if nobody
wants to pay for a cert for their crappy fly-by-night flash drives, and users
learn to "just click Install?"

------
emehrkay
This is interesting. At my job, a pretty big financial company, they
automatically lock down USB ports on the company computers, but I think it is
done on the OS (Windows) layer. Will that make a difference?

~~~
SCHiM
I'm not completely sure, but the vulnerability resides in the fact that an usb
device can mimic any other type of device. However if all devices are ignored
by the system then it won't matter what evil usb devile you insert: it will be
ignored just like all the legitimate usb devices.

So yes, if your company blocks absolutely all usb devices than you're probably
safe.

~~~
vanderZwan
Since the company does it at the OS level it is still vulnerable to the "boot-
loader" attack.

------
mhandley
The HID masquerade attack seems fairly easy to thwart from the OS. My machines
all have full disk encryption enabled. They won't boot unless you enter the
password. So the OS shouldn't enable any keyboard that wasn't used to enter
the password. If you plug in a keyboard later, simply screenlock. If the new
keyboard correctly enters the password, enable it. Otherwise don't.

None of this prevents malware already on your system infecting your legitimate
keyboard, but at least random memory sticks or other non-keyboards can't spoof
keyboards.

~~~
FireBeyond
Say goodbye to a lot of barcode scanners, etc.

And my girlfriend, who has a USB numeric pad attached to her MacBook as an
accounting student...

------
neiesc
USB has a huge security problem that could take years to fix[1]

[1] [http://seclists.org/isn/2014/Oct/16](http://seclists.org/isn/2014/Oct/16)

------
TheCowboy
Are SD cards subject to this vulnerability in the same way? I'm vaguely aware
that there are also security issues with SD card firmware.

~~~
briandh
I don't know about "the same way", but Andrew "bunnie" Huang had a cool talk
and post about hacking the firmware of SD cards and had this to say about
security:

> om the security perspective, our findings indicate that even though memory
> cards look inert, they run a body of code that can be modified to perform a
> class of MITM attacks that could be difficult to detect; there is no
> standard protocol or method to inspect and attest to the contents of the
> code running on the memory card’s microcontroller. Those in high-risk, high-
> sensitivity situations should assume that a “secure-erase” of a card is
> insufficient to guarantee the complete erasure of sensitive data. Therefore,
> it’s recommended to dispose of memory cards through total physical
> destruction (e.g., grind it up with a mortar and pestle).

[http://www.bunniestudios.com/blog/?page_id=3592](http://www.bunniestudios.com/blog/?page_id=3592)

------
tokenizerrr
So what, exactly, is this? Software (windows only?) to inject
rubberducky/modify the firmware of regular Phison USB drives? Can this
possibly be applied to other USB drives as well, or does this require entirely
different firmware/patchers?

What does the hidden partition patch do?

This all seems extremely interesting (and scary), but I'm having a hard time
understanding what exactly it is.

------
acd
Dont trust a Klingon! [http://hackaday.com/2012/06/29/turning-an-arduino-into-
a-usb...](http://hackaday.com/2012/06/29/turning-an-arduino-into-a-usb-
keyboard/)

