Hi. Thanks for sticking around for my talk. I know a lot of people have headed off already,
but, yeah, thanks a lot. So I'm going to talk a bit about USB. I've only got 20 minutes
and I've got plenty of slides to get through, so I'm going to whiz through them at a reasonable
pace. Okay. So the general thrust of what I'm going to be talking about is let's say
you've got a device that you want to assess the security of via USB. So you want to identify
any vulnerabilities in the drivers, the USB drivers at all the different levels in the
USB stack. But you want to find out as much as possible about that driver stack and the
drivers that are installed prior to doing any kind of active fuzzing. Because as we'll
get into a bit later, it's...
A lot of a slower process, fuzzing USB rather than fuzzing kind of network services, that
kind of thing. So the more information you can gather prior to starting fuzzing, the
more effective the process becomes. The other kind of thrust behind the research is around
embedded devices and, you know, more and more certainly within our company, we're getting
asked to test black boxes that may be part of automotive solutions, SCADA.
We're just given a black box with a bunch of interfaces in it. And no more information
than that. So using these kind of techniques, you can identify the operating system that's
on board and any applications that are on board as well. So kind of fingerprinting techniques.
And to wrap up, I'll show a demo of a tool that I've written called UMAP, which will
demonstrate some of the techniques.
Okay. So information gathering, why do we care? If you connect to a device, surely you
already know the platform. Well, as I said, with the whole embedded system, that's not
necessarily the case. And as I also mentioned, you really want to gain as much information
about the drivers that are installed before you start fuzzing. So a little bit of background
on USB. What we're talking about is the enumeration phase. So for those of you who don't know,
you plug in your USB device. The host initially knows absolutely nothing about it. So it
goes through this phase of asking the device lots of questions, gaining an idea of what
its capabilities are. Now, if we're trying to gain information about the host, we've
got a bit of a problem here because the way that USB works, it's a master slave-type set-up.
And as a device, you're the slave. So you can't ask the questions. You can only answer
them. So you've got to kind of answer the questions
in ways that will make them feel like it's going to be a slave. And you want to do some
that will prompt questions from the host to try and deduce what information you want about
the configuration of that host. And it's a pretty complex process and there's lots of
different implementations of this information exchange on different implementations of USB
hosts and therefore we can take advantage of that to try and work out what the host
is. So here's a typical enumeration phase. The
arrows there indicating the direction of the traffic. So there's a bunch of different descriptors.
The descriptors just contain information about configuration. They're data structures essentially.
So you get a device descriptor. The host sets an address. It then requests the device descriptor
again, configuration descriptor, string descriptor, bunch of configuration descriptors. The host
then sets the configuration and you can then start using the device. But hang on. Why was
that device descriptor initially requested twice? Well, when it first connects, there's
no address set for the device. So it needs to know some information about it with the
first request. It sets an address, then resets the device and goes through the process again.
There's also multiple requests for some of those other descriptors from different layers
within the USB. So it's a pretty complex process. So it's a pretty complex process. So it's a pretty complex process. So it's a pretty complex process. So it's a pretty complex process.
So it's a pretty complex process. So it's a pretty complex process. So it's a pretty complex
process. So as the information gets processed by different parts of the USB stack, some
of that information needs to be requested again. You can also get class-specific descriptors.
So for example, hub descriptors, HID descriptors, HID being mice, keyboards, human interface
stuff. So a bunch of different USB stack implementations. I'm going to whiz through these slides because, as I said, I'm running up 20 minutes.
Typical components. You've got host controller hardware at the lowest level. This is implementing
things like timing, electrical signals, all that kind of stuff that needs to be implemented
in hardware. You've then got host controller driver, which provides this abstraction layer
to that hardware for the USB core drivers. And it's those core drivers that perform the
actual enumeration. You then have the class drivers, which are things like, you know,
mass storage device drivers, printer drivers, that kind of thing. And then application software.
So, you know, you plug in a USB camera and it pops up some photo editing software to
display your photos. That's what I'm talking about with application software there.
Bunch of different implementations, which I will whiz through. Okay. Interacting with
USB. How are we actually going to communicate with USB to try and get in the information
that we want? We need to be able to capture and read the
data. We need to be able to replay all the USB traffic. We need to have complete control
of the generated traffic that we want to create. We don't want to be bound by any of
the spec. So, for example, if you were going to purely use some test equipment to do this,
a lot of the test equipment will be written to just use or comply with the USB spec because
people generally want to use it to test their kit. Whereas we want to use it to generate
unusual traffic. Each of us has a different way of doing this. We want to be able to
do this. Each of the different USB classes has got its own detailed spec document to
explain how that class specific data transfer occurs. We don't want to have to go to the
spec every time we do a packet capture. So if we've got a class decoder for each of
the USB classes, that's really useful. We want to be able to support different speeds.
USB 3.0 super speed will be fantastic. Hey, guys.
Hey.
What do we call this? Shot the noob. What do we need on stage?
Right there. Right there. So first time at DEF CON? Is this your first time at DEF CON?
He's going to say yes anyway, right? Wait a second. Wait, wait, wait. Test.
What is the dark tangent's real name? We do not use real names at DEF CON.
Off the stage, Dex. All right. No, no, no. I feel bad now.
You can come back. But don't ever say that again.
Do we have them poured yet? Yes. We're fast. It's fast talk.
I'm going to miss this. This is the last one. So drink if you've got them.
To you guys.
This is the gold-plated solution right here.
Gold-plated solution. I don't get it.
What does that even mean?
Can anybody in the audience tell us what's going on in this talk?
Is this about monster cables?
You have your work cut out for you. Look, you know, I just noticed speakers have been
putting their phones up and counting down. You're screwed, my friend.
We try to be diligent.
Okay. I tried to be diligent and I failed. Thanks, guys.
You're welcome.
Okay. So, yeah, if you've got plenty of cash and you want to spend $20,000 on a USB
testing solution, then go ahead and buy the Alesis. I couldn't afford that. It's pretty
useful having some kind of test solution for the class decoders, like I mentioned.
So I've got one of those packet masters.
The much cheaper approach, which you can get away with for kind of 95% of the stuff I'm
going to talk about, is to use a face sensor board. This is a fantastic solution developed
by Travis Goodspeed. It is awesome. If you haven't played with it, get hold of one and
have a go. They're great. Absolutely fantastic.
The ultimate solution in order to do everything that I'm talking about is to use both. So
basically you're generating the traffic using the face sensor board because you've got absolute
full control over the device that you're emulating. So you can send any packets you
like. And you can use the packet master or any other appliance to capture the traffic
coming back and do all the class decodes for you.
Also, the packet master has microsecond timing, which can potentially be useful, as we'll
talk about in a minute.
Okay. So there's a bunch of targets here. There's no reason other than the fact that
these were the devices I had lying around at home. So I wanted to find out if you could
use some of these techniques to differentiate between a bunch of different operating systems.
So these are ones that I have free.
So we want to be able to identify what the different class types are that are supported.
So kind of standard USB drivers. Most OSs come with a driver for HID, so keyboard.
You can plug your keyboard in. Also, mass storage device. We also want to enumerate
all these specifically installed drivers. And if there are any other devices that are
already connected.
Going back to the embedded system type situation, you may well have a black box that might have
a HSPA modem inside that's connected via USB internally. So if you can identify any of
those devices, that would be pretty cool.
So where is the information stored? Well, information about classes is stored within
some of these descriptors I mentioned, within the device descriptor, and also within interface
descriptors.
It's normally in interface descriptors because devices with multiple interfaces might have
different classes of interface.
And the information that relates the device driver to specific devices is the vendor ID
and the product ID that's stored within the device descriptor.
So it's kind of like a lookup table.
So after it's gone through the enumeration process, it can go off and say, you know,
am I aware of this device? Look it up with the vendor ID and product ID.
Using the face dancer, you can go through kind of a brute force approach to try and
identify those.
You don't need to go through the entire bit space of, you know, each of those 16-bit
values because everyone who wants to use a vendor ID or a product ID has to register
those with the HID.
So you can download that list and the UMAP tool uses that list.
So to identify what drivers are installed, it's just a case of emulating each of the
device types when you connect to the host.
So you're virtually connecting to the host using the face dancer.
So you basically bring it up and say, today I'm a printer.
Next time, I'm a USB camera, that kind of thing.
And the host will respond.
And if it goes all the way through to the set configuration command there and stops,
there's no driver installed.
If it continues and starts talking the protocol associated with that class, you know that
it's installed.
Simple as that.
I talked about trying to identify the connected devices purely by sniffing the USB bus.
If you look for the USB bus, you can see that it's connected to the USB bus.
If you run traffic on other addresses, you'll be able to see that those are other devices
that are connected.
The way that the structure of USB works, as long as you're on the same tier of the kind
of starred tier arrangement of hubs, you'll see all traffic associated with other devices
connected into that hub.
Potentially, I've been thinking about a scenario whereby you could control other devices.
So the face dancer allows you to be a host as well as a device.
So if you've identified that there's a device on address 4 and you start sending get device
descriptor requests to that, will it start revealing information to you?
I think it probably will.
It's currently untested and it's something that's part of my future research plans.
So a bunch of fingerprinting techniques.
I'm seriously running out of time, so we're going to whiz through this.
So OS identification.
Here we've got Linux based TV set-top box and Windows 8.
And the same mass storage device was plugged into each and all the traffic was captured.
You can quite clearly see that the types of class commands that are used and the order
in which they're requested are completely different for those two OSs.
And it's worth pointing out that everything is different.
Every time you plug into these specific OSs, that's the pattern of requests and replies.
So you can see that you can quite clearly fingerprint them there.
Application identification.
So I talked about the different applications that automatically spawn when you plug in
a USB device.
So here we're talking about a USB camera that's plugged in.
On Linux, you've got all these different requests and replies.
This is in class specific data after the enumeration has occurred.
Whereas on Windows 8, you've got completely different commands.
And what Windows 8 actually tries to do is modify the property of one of those images.
And within that device property request, there's a whole bunch of text with very specific information
about the version of OS, i.e., you know, Windows 6.2.9200 is basically the latest
version of Windows 8.
So there are a bunch of other patterns.
There are a bunch of other patterns.
That I identified based on different requests, different numbers of requests, specific requests
for certain OSs, that kind of stuff.
So quite easy to identify OS versions ‑‑ sorry, OS types.
Timing information.
I talked about this microsecond timing capability with the packet master device.
So I've got five different captures here of the same enumeration.
So I've got the enumeration phase for the same device.
And if you look at the amount of time it takes to perform each enumeration, you know, the
times are wildly different, you know, when you're talking in microseconds.
So there's massive difference across the entire enumeration.
However, I noticed that if you choose specific ‑‑ the time between specific requests, so,
for example, in this case, between string descriptor ‑‑ the requests for string
descriptor 0 and 2, there's actually very little difference in the timing between those.
And this kind of implies that if you already know the OS, there's the potential for discovering
some speed information here.
Again, this is work in progress.
And I hope to talk a bit more about that in the future once I've done further research.
Some OSs have got their own specific descriptors that you see.
So if you see Microsoft OS 2.0.
Descriptors, you obviously know that it's a Microsoft‑based OS.
Responses to invalid data.
There's a whole bunch of different invalid data that you can send within these descriptors
that are the responses to the requests during both enumeration and also in the class‑specific
communication.
So things like minimum, maximum values, logically incorrect values, missing data, you know,
if there's strings, long strings, format strings, all that kind of stuff.
So there are a number of different ways to do this.
There are some situations that I identified whereby you get unusual behavior that can
be used for fingerprinting.
But it's more useful as part of test cases for fuzzing to identify bugs.
So for example, Windows all versions ‑‑ I say all versions ‑‑ from XP up to current
day, absolutely everything, if you send a specific logically incorrect HID report descriptor,
this happens.
This happens.
So not too great from a kind of enumeration perspective, but it's a bug.
And when I show you UMAP in a few minutes' time, one of the test cases within UMAP will
trigger this.
So when I release the tool, you'll be able to play with this and find out what this bug
is.
Also the order of the descriptor requests can be used for identification, too.
So let's do a demo of EMAP.
And hopefully the demo gods are going to be with us.
Right.
So what I've got here is my laptop is connected via a face dancer board here, just down here,
connected to a laptop that's running Linux.
So if I run UMAP ‑‑ so there's a whole bunch of commands and things that you can
do with UMAP.
So I'll show you a few examples.
First of all, let's list the different USB device classes that UMAP is aware of.
And most of these we can emulate.
And first of all, we want to say ‑‑ let's pick one of those and say, is it supported?
So if we do, does it support the audio class?
So what it's doing is it's going through.
And it's systematically running.
It's virtually plugging itself in and saying, I'm audio class, subclass, undefined, protocol,
protocol undefined.
Oh, no, not supported.
Next one.
Right.
Now I'm another audio device, type audio control, da, da, da, da, da.
So it's going through each one.
And none of these are supported so far.
Okay.
So it doesn't seem to support any audio devices, this Linux box.
So if we try ‑‑ go back to ‑‑ let's try an image class device that's type 3.
So there we go.
That's supported.
So it said, now I'm a camera.
This is the particular class, subclass, and protocol that I'm using.
And it's come back and started talking image class language.
And, therefore, we know that that's supported and we can fuzz it later on.
All right.
All right.
So also within the tool, I mentioned the vendor ID and product ID that's associated
with specific drivers that have been installed.
If you know a vid and a PID and you want to know what that actually equates to, it
maintains a database of all that information.
So as a quick example ‑‑ okay.
So it's looked at that vid and PID, vendor DragonWise Inc., PID game pad.
The various operating system identification techniques I talked about, it goes through
and uses those.
So if I do capital O, it will go off and try some of those systematically plugging
in and enumerating, looking at the order of the packets going back.
And it said it's Linux.
Okay.
Cool.
That's right.
Good.
Let's say you just want to be a specific device, so you want to emulate a device of
a certain class.
I'm thinking of a scenario, let's say you're doing a job where you know that you've got
a USB‑based endpoint protection system in play, and you know that USB mass storage
devices are allowed, but only from a certain vendor.
So you can say I'd like to be a mass storage class device with this vendor ID.
And it will just pop that up and you can start using that.
Also image class, let's do an image class example, because that doesn't come by default
with Face Dancer.
It's something I've implemented.
So I want to be a camera.
You can put in any old vendor ID, product ID, and rev.
Okay.
So that's now connected and said, hey, I'm a camera.
And that's all the interactions with the OS.
And yeah, there you go.
So on to the fuzzing side of things, there's a whole bunch of test cases I've implemented.
So generic test cases that can be used to fuzz any USB device.
And then based on the spec for each of the USB device classes, I've gone through and
developed fuzz test cases.
So you can see a whole load of those in there.
So let's do a quick fuzz attempt.
So we know that it supports the image class.
So if we say fuzz the image class.
So it takes each one of those and it's basically, you know, going through and saying, yep, I'm
an image class device with this particular test case that we're starting to fuzz.
You can't see what's going on on the laptop, but it's checking up loads of errors.
In a minute it will actually check up a really serious error.
But you won't be able to see it from there anyway, so you have to trust me.
So it's a great way of identifying bugs.
And just through the testing of UMAP, I've identified a whole bunch of bugs in different
OSs.
It's not quite ready for prime time yet.
It needs a little bit of tweaking and it needs me to implement the remainder of the device
classes before I make it public.
But once I do, it will go live on our GitHub so you can download it.
So if I just stop that and go back to my wrap up.
So overview.
You can enumerate.
It supports a device class.
Operating system information can be enumerated.
So if you want to emulate any of the device classes and you know a specific vendor ID
and product ID, you can do that.
You can then fuzz any USB host implementation to identify bugs within that.
And as you can see with the classes, subclasses and protocols, this is an enormous attack
surface.
Lots and lots of this stuff is implemented in OSs.
And people just don't know it's there.
It's just not used.
But it is there as part of the attack surface and it can be fuzzed.
I mentioned endpoint protection systems.
You can assess the configuration of them if they're USB based.
Potentially circumvent them if you know specific devices that you want to emulate.
And yeah, as I said, completely comprehensively test USB host implementations.
Wow.
That's the quickest I've ever done that.
Thank you.
Thank you.
I appreciate it.