 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 more and more, certainly within our company, we're getting asked to test black boxes that may be part of automotive solutions, skater, that kind of thing. 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, we're 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, when you plug in a USB device, the host initially knows absolutely nothing about it. So it goes through this phase of like asking the device lots of questions and 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 setup. 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 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 the 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, their 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 stack. 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 this has a set of 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 mass storage device drivers, printer drivers, that kind of thing, and then application software. So 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. A 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 the information that we want? We need to be able to capture and 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 are 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 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, USB speed will be fantastic. Hey, guys. Hey! What do we call this? It cruts up on me. 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, wait, wait, test. What is the dark tangent's real name? We do not use real names at DEF CON! Off the stage, Dex. 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. This is our final one, isn't it? I'm going to miss this. This is the last one. So drink if you 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? What's the least in my cables? 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 tried 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 elisis. I couldn't afford that. It's pretty useful having some kind of a 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 it 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 the ones that I have free. So we want to be able to identify what the different different class types are that are supported. So kind of standard USB drivers. Most OSes come with a driver for HID, so Keyboard, you can plug 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 want to 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 of my 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. So, 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 USB implementers, blah, alcohol. The USB implementers forum. 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 host 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 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 four 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 setup box, 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 OSes. And it's worth pointing out that every time you plug into these specific OSes, that's the pattern of requests and replies. So you can see 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 within the, 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 texts 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 that are identified based on different requests, different numbers of requests, specific requests for certain OSes, 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 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 notice 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 OSes have got their own specific descriptors that you see. So if you see Microsoft OS descriptors, you obviously know that it's a Microsoft-based OS. Responses to invalid data. There's a whole bunch of 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, if there's strings, long strings, format strings, all that kind of stuff. So there are some situations that are 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. 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 it all, you'll be able to play with this and find out what this bug is. Also, the order of the descriptor request can be used for identification too. So let's do a demo of UMAP, 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 if I run it as a whole bunch of commands and things that you can do with UMAP, so I'll show you a few examples of things that you can do. 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 virtually plugging itself in and saying, I'm audio class, subclass, undefined, protocol, protocol undefined. No, not supported. Next one. Right. Now I'm another audio device, type audio control, 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 that. Now let's try an image class device that's type three. 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. 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 the database of all that information, so as a quick example, okay, so it's looked at that vid and pid, vendor, DragonWise, pid, gamepad. The various operating system identification techniques I talked about, it goes through and uses those, so if I do caplo, it'll go off and try some of those, so it's systematically plugging in and enumerating, looking at the order of the packets going back, and it said it's the next, 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 they're only from a certain vendor, so you can say I'd like to be a mass storage class device with this vendor ID and product 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 onto 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 for a bunch of those as well. So you can see a whole load of those in there. 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 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 I'll actually check up a really serious error, but you'll 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 U-Map, I've identified a whole bunch of bugs in different OSes. 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 supported device classes. 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 OSes 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 are 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. Well that's the quickest I've ever done that.