1 00:00:00,000 --> 00:00:01,459 ANDY DAVIS: Hi. 2 00:00:01,751 --> 00:00:03,834 Thanks for sticking around for my talk. 3 00:00:03,834 --> 00:00:07,751 I know a lot of people have headed off already but, yeah, thanks a lot. 4 00:00:07,751 --> 00:00:10,000 So I'm going to talk a little bit about USB. 5 00:00:10,000 --> 00:00:12,042 I have only got 20 minutes and I have got plenty of slides 6 00:00:12,042 --> 00:00:14,501 to get through so I'm going to whiz through them 7 00:00:14,501 --> 00:00:16,417 at reasonable pace. 8 00:00:17,876 --> 00:00:19,167 Okay. 9 00:00:19,167 --> 00:00:22,542 So the general thrust of what I'm going to be talking 10 00:00:22,542 --> 00:00:27,417 about is let's say you've got a device that you want to assess 11 00:00:27,417 --> 00:00:32,918 the security of via USB, so you want to identify any vulnerabilities 12 00:00:32,918 --> 00:00:37,626 in the drivers, the USB drivers, at all the different levels 13 00:00:37,626 --> 00:00:39,999 in the USB stack. 14 00:00:40,959 --> 00:00:45,999 But you want to find out as much as possible about that driver stack 15 00:00:45,999 --> 00:00:50,125 and the drivers that are installed prior to doing any kind 16 00:00:50,125 --> 00:00:54,959 of active fuzzing because as we will get into a bit later, it's 17 00:00:54,959 --> 00:01:00,292 a lot slower process fuzzing USB rather than fuzzing the network services, 18 00:01:00,292 --> 00:01:02,792 that kind of thing. 19 00:01:02,999 --> 00:01:06,292 So the more information you can gather prior to starting fuzzing, 20 00:01:06,292 --> 00:01:09,250 the more effective the process becomes. 21 00:01:10,083 --> 00:01:12,999 The other kind of thrust behind the research 22 00:01:12,999 --> 00:01:16,250 is around embedded devices and certainly more and more 23 00:01:16,250 --> 00:01:20,834 within our company we are getting asked to test black boxes that may be 24 00:01:20,834 --> 00:01:24,209 part of automotive solutions, SCADA, that kind of thing, 25 00:01:24,209 --> 00:01:27,292 where you are just given a black box with a bunch 26 00:01:27,292 --> 00:01:31,792 of interfaces in it and no more information than that. 27 00:01:31,792 --> 00:01:34,876 And using these kind of techniques, you can identify 28 00:01:34,876 --> 00:01:39,999 the operating system that's on board and any applications that are 29 00:01:39,999 --> 00:01:42,167 on board as well. 30 00:01:42,459 --> 00:01:44,667 So kind of fingerprinting techniques. 31 00:01:44,834 --> 00:01:49,999 And to wrap up, I will show a demo which will demonstrate some 32 00:01:49,999 --> 00:01:52,542 of the techniques. 33 00:01:56,459 --> 00:01:57,834 Okay. 34 00:01:57,834 --> 00:01:59,999 So information gathering, why do we care? 35 00:01:59,999 --> 00:02:03,375 If you can connect to a device, surely you already know the platform. 36 00:02:03,375 --> 00:02:05,334 Well, as I said, with the whole embedded system, 37 00:02:05,334 --> 00:02:08,083 that's not necessarily the case. 38 00:02:09,999 --> 00:02:12,334 And as I also mentioned, you really want to gain 39 00:02:12,334 --> 00:02:14,999 as much information about the drivers that are installed 40 00:02:14,999 --> 00:02:17,209 before you start fuzzing. 41 00:02:17,709 --> 00:02:20,999 So a little bit of background on USB, what we're talking 42 00:02:20,999 --> 00:02:23,751 about is the enumeration phase. 43 00:02:25,792 --> 00:02:28,999 The host knows nothing about it. 44 00:02:29,083 --> 00:02:33,167 It goes through this phase of asking the device questions and gaining 45 00:02:33,167 --> 00:02:36,417 an idea of what its capabilities are. 46 00:02:36,417 --> 00:02:39,459 Now, if we are trying to gain information about the host, 47 00:02:39,459 --> 00:02:41,125 we've got a bit of a problem here 48 00:02:41,125 --> 00:02:45,292 because the way USB works, it is a master/slave type setup. 49 00:02:45,876 --> 00:02:49,999 As the device, you are the slave, so you can't ask the questions. 50 00:02:49,999 --> 00:02:51,125 You can only answer them. 51 00:02:51,209 --> 00:02:55,083 So you have got to kind of answer the questions in ways that 52 00:02:55,083 --> 00:02:59,999 will prompt questions from the host to try and deduce what information you 53 00:02:59,999 --> 00:03:03,626 want about the configuration of that host. 54 00:03:04,999 --> 00:03:08,375 It is a pretty complex process and there is lots 55 00:03:08,375 --> 00:03:12,292 of different implementations this information exchange 56 00:03:12,292 --> 00:03:16,417 on different implementations of USB hosts and, therefore, 57 00:03:16,417 --> 00:03:22,125 we can take advantage of that to try to work out what the host is. 58 00:03:22,999 --> 00:03:25,751 So here's a particular enumeration phase, 59 00:03:25,751 --> 00:03:30,375 the arrows there indicating the direction of the traffic. 60 00:03:30,375 --> 00:03:32,834 So there is a bunch of different descriptors. 61 00:03:32,834 --> 00:03:35,999 The descriptors just contain information about configuration, 62 00:03:35,999 --> 00:03:39,334 the data structures essentially. 63 00:03:39,584 --> 00:03:42,501 So you get a device descriptor. 64 00:03:42,792 --> 00:03:44,667 The host sets an address. 65 00:03:44,667 --> 00:03:45,876 It then requests a device descriptor again, 66 00:03:45,876 --> 00:03:48,417 configuration descriptor, string descriptor, a bunch 67 00:03:48,417 --> 00:03:50,999 of configuration descriptors. 68 00:03:50,999 --> 00:03:52,959 The host then sets the configuration and then you can 69 00:03:52,959 --> 00:03:54,999 start using the device. 70 00:03:56,083 --> 00:03:57,999 But hang on. 71 00:03:57,999 --> 00:04:00,999 Why was that device descriptor initially requested twice? 72 00:04:00,999 --> 00:04:06,584 Well, when it first connects, there is no address set for the device. 73 00:04:06,584 --> 00:04:07,999 So it needs to know some information about it 74 00:04:07,999 --> 00:04:10,209 with the first request. 75 00:04:10,209 --> 00:04:11,709 It sets an address. 76 00:04:11,709 --> 00:04:14,709 Then resets the device and goes through the process again. 77 00:04:14,709 --> 00:04:18,584 There's also a multiple requests for some of the other descriptors 78 00:04:18,584 --> 00:04:22,459 from different layers within the USB stack. 79 00:04:22,459 --> 00:04:26,584 So as the information gets processed by different parts of the USB stack, 80 00:04:26,584 --> 00:04:30,999 some of that information needs to be requested again. 81 00:04:31,125 --> 00:04:34,834 You can also get class specific descriptors. 82 00:04:34,834 --> 00:04:38,167 For example, hub descriptors, hid descriptors, "hid" being mice, 83 00:04:38,167 --> 00:04:41,375 keyboards, human interface stuff. 84 00:04:42,792 --> 00:04:46,999 So a bunch of different USB stack implementations. 85 00:04:47,125 --> 00:04:48,999 I will whiz through these slides because as I said, 86 00:04:48,999 --> 00:04:50,999 I only have 20 minutes. 87 00:04:51,375 --> 00:04:52,999 Typical components. 88 00:04:53,375 --> 00:04:57,459 You've got host controller hardware at the lowest level. 89 00:04:57,459 --> 00:05:01,999 This is implementing things like timing, electrical signals, all that kind 90 00:05:01,999 --> 00:05:06,334 of stuff that needs to be implemented in hardware. 91 00:05:06,459 --> 00:05:10,459 You have host controller driver which provides an abstraction layer 92 00:05:10,459 --> 00:05:14,125 to the hardware for the USB core drivers. 93 00:05:14,459 --> 00:05:17,999 And it is those core drivers that perform the actual enumeration. 94 00:05:18,417 --> 00:05:20,626 You then have the class drivers which are mass 95 00:05:20,626 --> 00:05:23,083 storage drivers, printer drivers, that kind 96 00:05:23,083 --> 00:05:26,292 of thing and then application software. 97 00:05:26,292 --> 00:05:28,999 So, you know, you plug in an USB camera and it pops 98 00:05:28,999 --> 00:05:33,459 up some photo editing software to display your photos. 99 00:05:33,459 --> 00:05:37,083 That's what I'm talking about, application software, stuff like that. 100 00:05:37,083 --> 00:05:40,999 A bunch of different implementations which I will whiz through. 101 00:05:40,999 --> 00:05:41,999 Okay. 102 00:05:41,999 --> 00:05:43,542 Interacting with USB, how are we actually going 103 00:05:43,542 --> 00:05:48,375 to communicate with USB to try and gain the information that we want? 104 00:05:48,792 --> 00:05:52,375 We need to be able to capture and replay all the USB traffic. 105 00:05:52,751 --> 00:05:56,501 We need to have complete control of the generated traffic that we want 106 00:05:56,501 --> 00:05:57,999 to create. 107 00:05:57,999 --> 00:06:00,834 We don't want to be banged by any of the spec, so, for example, 108 00:06:00,834 --> 00:06:03,792 if you were going to purely use some test equipment 109 00:06:03,792 --> 00:06:06,999 to do this, a lot of the test equipment will be written 110 00:06:06,999 --> 00:06:09,167 to just use or comply with the USB spec 111 00:06:09,167 --> 00:06:13,667 because people generally want to use it to test their kit. 112 00:06:13,667 --> 00:06:17,667 Or as we want to use it to generate unusual traffic. 113 00:06:19,417 --> 00:06:25,542 Each of the different USB classes has got its own detailed spec document 114 00:06:25,542 --> 00:06:31,209 to explain how that class specific data transfer occurs. 115 00:06:31,209 --> 00:06:33,999 We don't want to have to go to the spec every time we do 116 00:06:33,999 --> 00:06:35,876 packet capture. 117 00:06:35,876 --> 00:06:38,250 So if we've got a class decoder for each of the USB classes, 118 00:06:38,250 --> 00:06:40,501 that's really useful. 119 00:06:40,918 --> 00:06:43,209 We want to be able to support different speeds. 120 00:06:43,209 --> 00:06:44,999 USB 3.0 speed will be fantastic. 121 00:06:44,999 --> 00:06:45,999 Hey, guys. 122 00:06:45,999 --> 00:06:46,999 Hey. 123 00:06:46,999 --> 00:06:55,083 (applause) What do we call this? 124 00:06:55,999 --> 00:06:57,626 Shot the n00b. 125 00:06:57,626 --> 00:07:00,334 What do we need on stage? 126 00:07:00,667 --> 00:07:02,459 Right there, right there. 127 00:07:05,792 --> 00:07:08,209 So first time at DEF CON? 128 00:07:08,709 --> 00:07:10,999 This is your first time at DEF CON? 129 00:07:10,999 --> 00:07:11,999 Yeah. 130 00:07:11,999 --> 00:07:13,999 He is going to say yes anyway, right? 131 00:07:13,999 --> 00:07:14,999 Wait, wait, wait. 132 00:07:14,999 --> 00:07:15,999 Test. 133 00:07:15,999 --> 00:07:17,834 What is the Dark Tangent's real name? 134 00:07:17,834 --> 00:07:18,999 (speaker off microphone.) We do not use real 135 00:07:18,999 --> 00:07:20,709 name at DEF CON. 136 00:07:20,709 --> 00:07:22,459 Off the stage. 137 00:07:22,459 --> 00:07:23,459 No. 138 00:07:23,459 --> 00:07:24,999 I feel bad now. 139 00:07:25,626 --> 00:07:28,334 But don't ever say that again. 140 00:07:28,584 --> 00:07:31,626 Do we have them poured yet? 141 00:07:31,626 --> 00:07:41,459 We are fast, it is a fast talk. 142 00:07:41,459 --> 00:07:42,709 This is our final one. 143 00:07:42,709 --> 00:07:43,999 I'm going to miss this. 144 00:07:43,999 --> 00:07:47,083 This is the last one, so drink if you got them. 145 00:07:47,083 --> 00:07:54,999 To you guys. 146 00:07:54,999 --> 00:07:57,999 (applause) This is the gold plated solution right here. 147 00:07:57,999 --> 00:07:59,125 Gold plated solution. 148 00:07:59,501 --> 00:08:00,501 I don't get it. 149 00:08:00,501 --> 00:08:01,999 What does that even mean? 150 00:08:03,626 --> 00:08:08,792 Can anybody in the audience tell us what's going 151 00:08:08,792 --> 00:08:11,167 on in the talk? 152 00:08:11,167 --> 00:08:12,959 Is this about monster cables? 153 00:08:12,959 --> 00:08:14,999 You have your work cut out for you. 154 00:08:14,999 --> 00:08:16,626 I just noticed speakers have been putting their phones 155 00:08:16,626 --> 00:08:18,542 up and counting down. 156 00:08:18,542 --> 00:08:19,999 You're screwed, my friend. 157 00:08:19,999 --> 00:08:23,209 ANDY DAVIS: We try to be diligent. 158 00:08:24,999 --> 00:08:26,292 Okay. 159 00:08:26,292 --> 00:08:28,083 I tried to be diligent and I failed. 160 00:08:28,959 --> 00:08:30,584 Thanks, guys. 161 00:08:30,584 --> 00:08:32,959 You're welcome. 162 00:08:32,959 --> 00:08:34,459 ANDY DAVIS: Okay. 163 00:08:34,459 --> 00:08:37,834 So, yeah, if you have got plenty of cash and you want 164 00:08:37,834 --> 00:08:41,292 to spend $20,000 on an USB testing solution, 165 00:08:41,292 --> 00:08:44,999 then go ahead and buy the elitest. 166 00:08:45,083 --> 00:08:46,584 I couldn't afford that. 167 00:08:46,626 --> 00:08:50,459 It is pretty useful having some kind of test solution 168 00:08:50,459 --> 00:08:54,834 for the class decoders like I mentioned. 169 00:08:54,834 --> 00:08:56,959 I have got one of those packet masters. 170 00:08:57,751 --> 00:09:02,125 The much cheaper approach which you can get away with for kind of 95% 171 00:09:02,125 --> 00:09:05,125 of the stuff I'm going to talk about is to use 172 00:09:05,125 --> 00:09:07,876 a Face Dancer sub board. 173 00:09:07,876 --> 00:09:12,083 This is a fantastic solution developed by Travis Goodspeed. 174 00:09:12,083 --> 00:09:13,083 It is awesome. 175 00:09:13,083 --> 00:09:16,626 If you haven't played with one, get a hold of it and have a play with it. 176 00:09:16,626 --> 00:09:17,876 It is fantastic. 177 00:09:19,209 --> 00:09:22,501 The solution to do everything I'm talking 178 00:09:22,501 --> 00:09:25,083 about is to use both. 179 00:09:25,584 --> 00:09:27,792 Basically you're generating the traffic using 180 00:09:27,792 --> 00:09:31,459 the Face Dancer sub board because you have actually full control 181 00:09:31,459 --> 00:09:34,751 over the device that you're emulating. 182 00:09:34,792 --> 00:09:36,999 So I can send any packets you like. 183 00:09:37,209 --> 00:09:40,292 And you can use the Packet Master or any of the other appliance 184 00:09:40,292 --> 00:09:42,834 to capture the traffic coming back and deal 185 00:09:42,834 --> 00:09:45,542 with the class decodes for you. 186 00:09:45,542 --> 00:09:48,667 Also, the Packet Master has microsecond 187 00:09:48,667 --> 00:09:55,125 timing which can potentially be useful as we'll talk about in a minute. 188 00:09:55,292 --> 00:09:56,292 Okay. 189 00:09:56,292 --> 00:09:58,292 So there is a bunch of targets here. 190 00:09:58,542 --> 00:10:01,083 There is no reason other than the fact that these were 191 00:10:01,083 --> 00:10:04,375 the devices I had lying around at home. 192 00:10:04,876 --> 00:10:06,999 I wanted to find out if you could use some 193 00:10:06,999 --> 00:10:09,584 of these techniques to differentiate between a bunch 194 00:10:09,584 --> 00:10:12,042 of different operating systems. 195 00:10:12,042 --> 00:10:13,667 These are ones that I had free. 196 00:10:16,167 --> 00:10:19,167 So we want to be able to identify what 197 00:10:19,167 --> 00:10:24,000 the different class types are that are supported. 198 00:10:24,000 --> 00:10:27,125 So kind of standard USB drivers. 199 00:10:27,292 --> 00:10:31,209 Most OSs come with a drive for head. 200 00:10:31,209 --> 00:10:33,250 So keyboard, you can plug a keyboard in. 201 00:10:33,250 --> 00:10:34,709 Also a mass storage device. 202 00:10:34,999 --> 00:10:40,417 We also want to enumerate all these specifically installed drivers. 203 00:10:40,999 --> 00:10:45,375 And if there are any other devices that are already connected, going back 204 00:10:45,375 --> 00:10:48,667 to the embedded system type situation, you might have 205 00:10:48,667 --> 00:10:51,751 a black box that has a HTPA modem inside connected 206 00:10:51,751 --> 00:10:53,876 by USB internally. 207 00:10:53,876 --> 00:10:59,209 So if you can connect those devices, that's pretty cool. 208 00:10:59,209 --> 00:11:01,501 Where is the information stored? 209 00:11:01,667 --> 00:11:04,751 Well, information of the classes is stored within some 210 00:11:04,751 --> 00:11:08,125 of these descriptors I mentioned, within the device descriptor 211 00:11:08,125 --> 00:11:11,292 and also within interface descriptors. 212 00:11:11,292 --> 00:11:12,626 It is normally in interface descriptors 213 00:11:12,626 --> 00:11:15,083 because devices with multiple interfaces might have 214 00:11:15,083 --> 00:11:17,834 different classes of interface. 215 00:11:19,459 --> 00:11:28,584 And the information that relates the device driver to specific devices 216 00:11:28,584 --> 00:11:31,999 is the vendor I.D. 217 00:11:31,999 --> 00:11:32,999 and the product I.D. 218 00:11:32,999 --> 00:11:36,334 that's stored within the device descriptor. 219 00:11:36,626 --> 00:11:39,083 So it's kind of like a lookup table. 220 00:11:39,083 --> 00:11:41,709 So after it's gone through the enumeration process, 221 00:11:41,709 --> 00:11:45,959 it can go off and say am I aware of this device? 222 00:11:45,959 --> 00:11:47,584 Look it up with a vendor I.D. 223 00:11:47,584 --> 00:11:48,584 and product I.D. 224 00:11:48,999 --> 00:11:50,792 Using the Face Dancer, you can go 225 00:11:50,792 --> 00:11:54,792 through a brute force approach to try and identify those. 226 00:11:55,375 --> 00:11:59,626 You don't need to go through the entire bit space of each 227 00:11:59,626 --> 00:12:03,167 of those 16 bit values because everyone who wants 228 00:12:03,167 --> 00:12:05,792 to use a vendor I.D. 229 00:12:05,792 --> 00:12:06,792 or product I.D. 230 00:12:06,792 --> 00:12:10,542 has to register those with the USB implementation bleh 231 00:12:10,542 --> 00:12:14,667 alcohol, the USB Implementors Forum. 232 00:12:14,792 --> 00:12:19,083 So you can download that list and the e map tool uses that list. 233 00:12:20,751 --> 00:12:26,709 To identify what drivers are installed, it's just a case of emulating each 234 00:12:26,709 --> 00:12:31,667 of the device types when you connect to the host. 235 00:12:31,667 --> 00:12:34,999 So you're virtually connecting to the host using the Face Dancer. 236 00:12:34,999 --> 00:12:38,667 You bring it up and say today I'm a printer. 237 00:12:38,667 --> 00:12:43,334 Next time I'm an USB camera, that kind of thing. 238 00:12:43,999 --> 00:12:46,459 The host will respond. 239 00:12:46,459 --> 00:12:49,709 And if it goes all the way through to the set configuration 240 00:12:49,709 --> 00:12:53,999 command there and stops, there's no driver installed. 241 00:12:53,999 --> 00:12:56,999 If it continues and starts talking, the protocol associated with that class, 242 00:12:56,999 --> 00:12:59,209 you know it is installed. 243 00:12:59,209 --> 00:13:02,417 Simple as that. 244 00:13:02,417 --> 00:13:04,999 I talked about trying to identify the connected devices purely 245 00:13:04,999 --> 00:13:07,209 by sniffing the USB bus. 246 00:13:07,209 --> 00:13:11,334 If you look for traffic on other addresses, you 247 00:13:11,334 --> 00:13:16,834 will see those are other devices connected. 248 00:13:16,834 --> 00:13:20,417 The way the structure of the USB works, as long as you are 249 00:13:20,417 --> 00:13:25,751 on the same tier of the kind of starred tier arrangement of hubs, 250 00:13:25,751 --> 00:13:30,959 you will see all traffic associated with other devices connected 251 00:13:30,959 --> 00:13:32,999 into that hub. 252 00:13:33,417 --> 00:13:37,083 Potentially I've been thinking about a scenario whereby you could 253 00:13:37,083 --> 00:13:39,501 control other devices. 254 00:13:39,999 --> 00:13:46,083 So the Face Dancer allows you to be a host as well as a device. 255 00:13:46,501 --> 00:13:49,083 So if you've identified there's a device 256 00:13:49,083 --> 00:13:54,999 on address 4 and you start sending get device descriptor requests to that, 257 00:13:54,999 --> 00:13:59,250 will it start revealing information to you? 258 00:13:59,250 --> 00:14:00,751 I think it probably will. 259 00:14:00,751 --> 00:14:02,375 It's currently untested and it is something that's part 260 00:14:02,375 --> 00:14:04,751 of my future research plans. 261 00:14:04,999 --> 00:14:07,250 So a bunch of fingerprinting techniques, seriously, 262 00:14:07,250 --> 00:14:10,959 we are running out of time so I will whiz through this. 263 00:14:11,417 --> 00:14:15,334 OS identification, here we've got Linux based TV set top 264 00:14:15,334 --> 00:14:18,999 box, Windows 8 and the same mass storage device was 265 00:14:18,999 --> 00:14:21,125 plugged into each. 266 00:14:21,125 --> 00:14:22,999 All the traffic was captured. 267 00:14:22,999 --> 00:14:24,584 You can quite clearly see that the types 268 00:14:24,584 --> 00:14:27,334 of class commands that are used and the order 269 00:14:27,334 --> 00:14:32,792 in which they're requested are completely different for those two OSs. 270 00:14:33,709 --> 00:14:37,334 And it's worth pointing out that every time you plug 271 00:14:37,334 --> 00:14:43,083 into these specific OSs that's the pattern of requests and replies. 272 00:14:43,083 --> 00:14:45,334 So, yeah, you can see quite clearly fingerprint 273 00:14:45,334 --> 00:14:46,999 them there. 274 00:14:47,209 --> 00:14:48,751 Application identification, so I talked 275 00:14:48,751 --> 00:14:52,209 about the different applications that automatically spawn when you plug 276 00:14:52,209 --> 00:14:54,083 in an USB device. 277 00:14:54,083 --> 00:14:56,999 Here we are talking about an USB camera that's plugged in. 278 00:14:57,125 --> 00:15:00,167 On Linux, you have got all these different requests 279 00:15:00,167 --> 00:15:03,667 and replies within this is in class specific data 280 00:15:03,667 --> 00:15:07,083 after the enumeration has occurred. 281 00:15:07,250 --> 00:15:09,083 Whereas, on Windows 8 you have got completely 282 00:15:09,083 --> 00:15:10,999 different commands. 283 00:15:10,999 --> 00:15:15,417 And what Windows 8 actually tries to do is modify the property of one 284 00:15:15,417 --> 00:15:19,751 of those images and within that device property request, 285 00:15:19,751 --> 00:15:24,292 there is a whole bunch of text with very specific information 286 00:15:24,292 --> 00:15:27,834 about the version of OS, IE, Windows 6.2.9200 287 00:15:27,834 --> 00:15:31,999 is basically latest version of Windows 8. 288 00:15:34,542 --> 00:15:39,375 So there are a bunch of other patterns that I identified based 289 00:15:39,375 --> 00:15:43,584 on different requests, different numbers of requests, 290 00:15:43,584 --> 00:15:48,918 specific requests for certain OSs, that kind of stuff. 291 00:15:48,918 --> 00:15:53,999 So quite easy to identify OS versions sorry, OS types. 292 00:15:54,667 --> 00:15:56,459 Timing information. 293 00:15:56,459 --> 00:15:58,125 I talked about this microsecond timing capability 294 00:15:58,125 --> 00:16:00,959 with the Packet Master device. 295 00:16:01,083 --> 00:16:07,501 So I've got five different captures here of the same enumeration phase 296 00:16:07,501 --> 00:16:10,292 for the same device. 297 00:16:10,584 --> 00:16:13,918 And if you look at the amount of time it takes 298 00:16:13,918 --> 00:16:18,667 to perform each enumeration, the times are wildly different when you 299 00:16:18,667 --> 00:16:21,667 are talking in microseconds. 300 00:16:21,667 --> 00:16:26,167 So there's massive difference across the entire enumeration. 301 00:16:26,167 --> 00:16:29,667 However, I noticed that if you choose specific the time 302 00:16:29,667 --> 00:16:33,709 between specific requests, so, for example, in this case, 303 00:16:33,709 --> 00:16:37,999 between string descriptor, the request for string descriptor 0 304 00:16:37,999 --> 00:16:44,292 and 2, there's actually very little difference in the timing between those. 305 00:16:44,334 --> 00:16:47,999 And this kind of implies if you already know the OS, there's 306 00:16:47,999 --> 00:16:50,626 the potential for discovering some speed 307 00:16:50,626 --> 00:16:52,834 information here. 308 00:16:52,834 --> 00:16:54,626 Again, this is work in progress. 309 00:16:54,667 --> 00:16:56,417 And I hope to talk a bit more about that 310 00:16:56,417 --> 00:17:00,083 in the future once I have done further research. 311 00:17:00,999 --> 00:17:05,292 Some OSs have got their own specific descriptors you see. 312 00:17:05,292 --> 00:17:08,083 So if you see Microsoft OS descriptors, you obviously know it 313 00:17:08,083 --> 00:17:10,584 is a Microsoft based OS. 314 00:17:11,375 --> 00:17:13,626 Responses to invalid data. 315 00:17:13,626 --> 00:17:16,209 There is a whole bunch of different invalid data that you can 316 00:17:16,209 --> 00:17:19,999 send within these descriptors that are the responses to the requests 317 00:17:19,999 --> 00:17:24,959 during both enumeration and also in the class specific communication. 318 00:17:25,626 --> 00:17:27,667 So things like minimum/maximum values, 319 00:17:27,667 --> 00:17:31,999 logically incorrect values, missing data, you know, short strings, long strings, 320 00:17:31,999 --> 00:17:34,167 all that kind of stuff. 321 00:17:34,584 --> 00:17:40,083 So there are some situations that I identified whereby you get unusual 322 00:17:40,083 --> 00:17:44,667 behavior that can be used for fingerprinting. 323 00:17:44,876 --> 00:17:48,083 But it's more useful as part of test cases for fuzzing 324 00:17:48,083 --> 00:17:50,250 to identify bugs. 325 00:17:50,334 --> 00:17:55,999 So, for example, Windows, all versions I say all versions 326 00:17:55,999 --> 00:17:59,501 from XP up to current day. 327 00:17:59,959 --> 00:18:05,459 If you send a specific logically incorrect head report descriptor, this happens. 328 00:18:07,751 --> 00:18:13,999 So not too great for any kind of enumeration perspective. 329 00:18:13,999 --> 00:18:14,999 But it's a bug. 330 00:18:14,999 --> 00:18:18,083 And when I show you e map in a few minutes' time, one 331 00:18:18,083 --> 00:18:22,501 of the test cases within e map will trigger this. 332 00:18:22,501 --> 00:18:23,667 So when I release it all, you will be able to play with this 333 00:18:23,667 --> 00:18:25,751 and find out what this bug is. 334 00:18:28,999 --> 00:18:31,999 Also, the order of the descriptor requests can be used 335 00:18:31,999 --> 00:18:34,209 for identification, too. 336 00:18:34,709 --> 00:18:37,250 So let's do a demo of e map and hopefully 337 00:18:37,250 --> 00:18:40,792 the demo gods are going to be with us. 338 00:18:42,459 --> 00:18:43,834 Right. 339 00:18:43,834 --> 00:18:47,209 So what I've got here is my laptop is connected via 340 00:18:47,209 --> 00:18:51,876 a Face Dancer board here which is down here connected 341 00:18:51,876 --> 00:18:55,667 to a laptop that's running Linux. 342 00:18:55,999 --> 00:19:01,501 So if I run e map there is a whole bunch of commands 343 00:19:01,501 --> 00:19:06,334 and things you can do with e map. 344 00:19:06,334 --> 00:19:08,999 I will show you a few examples of the things you can do. 345 00:19:09,292 --> 00:19:13,999 First of all, let's list the different USB device classes that 346 00:19:13,999 --> 00:19:16,459 e map is aware of. 347 00:19:16,999 --> 00:19:20,083 And most of these we can emulate. 348 00:19:20,209 --> 00:19:23,751 First of all, we want to say let's pick one of those and say 349 00:19:23,751 --> 00:19:25,626 is it supported. 350 00:19:26,876 --> 00:19:29,999 So does it support the audio class? 351 00:19:32,709 --> 00:19:38,999 So what it's doing is it is going through and it's systematically virtually 352 00:19:38,999 --> 00:19:43,667 plugging itself in and saying I'm audio class sub class 353 00:19:43,667 --> 00:19:47,999 undefined protocol, protocol undefined. 354 00:19:48,125 --> 00:19:50,501 No, not supported. 355 00:19:50,501 --> 00:19:51,501 Next one. 356 00:19:51,501 --> 00:19:52,501 Right. 357 00:19:52,501 --> 00:19:56,083 Now I'm another audio device, audio control, da, ta, da, ta, da. 358 00:19:56,083 --> 00:20:01,542 It is going through each one and none of these are supported so far. 359 00:20:02,334 --> 00:20:03,667 Okay. 360 00:20:03,667 --> 00:20:05,375 So it doesn't seem to support any audio devices, 361 00:20:05,375 --> 00:20:07,250 this Linux box. 362 00:20:07,250 --> 00:20:13,999 So if we try go back to let's try an image class device. 363 00:20:13,999 --> 00:20:15,042 That's type 3. 364 00:20:19,918 --> 00:20:21,459 So we go. 365 00:20:21,459 --> 00:20:22,501 That's supported. 366 00:20:22,501 --> 00:20:25,999 So it said now my camera, this is the particular class, sub class 367 00:20:25,999 --> 00:20:30,125 and protocol that I'm using and it's come back and started talking 368 00:20:30,125 --> 00:20:32,542 image class language. 369 00:20:32,542 --> 00:20:33,542 And, therefore, we know that that's supported 370 00:20:33,542 --> 00:20:35,626 and we can fuzz it later on. 371 00:20:36,501 --> 00:20:43,000 Also, within the talk, I mentioned the vendor I.D. 372 00:20:43,000 --> 00:20:44,000 and product I.D. 373 00:20:44,000 --> 00:20:46,334 that's associated with specific drivers that have 374 00:20:46,334 --> 00:20:48,250 been installed. 375 00:20:48,250 --> 00:20:50,918 If you know a VID, a PID and what it equates to, 376 00:20:50,918 --> 00:20:54,999 it maintains a database of all that information. 377 00:20:54,999 --> 00:21:03,125 So as a quick example, it has looked up that VID and PID. 378 00:21:09,292 --> 00:21:13,459 The various operating system identification techniques I talked about, 379 00:21:13,459 --> 00:21:16,250 it goes through and uses those. 380 00:21:16,334 --> 00:21:21,959 So if I do capital O, it will go off and try some of those. 381 00:21:21,959 --> 00:21:24,999 It systematically is plugging in and enumerating, looking 382 00:21:24,999 --> 00:21:28,918 at the order of the packets going back. 383 00:21:30,834 --> 00:21:31,999 Okay. 384 00:21:31,999 --> 00:21:32,999 Cool. 385 00:21:32,999 --> 00:21:33,999 That's right. 386 00:21:33,999 --> 00:21:34,999 Good. 387 00:21:34,999 --> 00:21:38,209 Let's say you just want to be a specific device, you want 388 00:21:38,209 --> 00:21:41,876 to emulate a device of a certain class. 389 00:21:42,250 --> 00:21:45,250 I'm thinking of a scenario let's say you're doing 390 00:21:45,250 --> 00:21:49,667 a job where you know that you've got an USB based end point protection 391 00:21:49,667 --> 00:21:53,999 system in play and you know that USB mass storage devices are allowed 392 00:21:53,999 --> 00:21:56,876 but only from a certain vendor. 393 00:21:56,999 --> 00:22:00,792 So you can say I'd like to be a mass storage class device 394 00:22:00,792 --> 00:22:03,292 with this vendor I.D. 395 00:22:03,292 --> 00:22:04,292 and product I.D. 396 00:22:04,292 --> 00:22:07,125 and it will pop that right up and you can start using that. 397 00:22:07,292 --> 00:22:09,626 Also, image class, let's do an image class example 398 00:22:09,626 --> 00:22:13,417 because it doesn't come by default with Face Dancer. 399 00:22:15,918 --> 00:22:16,999 Okay. 400 00:22:25,792 --> 00:22:30,999 So that's now connected and said, hey, I'm a camera and that's 401 00:22:30,999 --> 00:22:34,584 all the interactions of the OS. 402 00:22:34,584 --> 00:22:35,918 And, yeah. 403 00:22:35,918 --> 00:22:37,417 There you go. 404 00:22:38,083 --> 00:22:42,876 So on to the fuzzing side of things, there's a whole bunch 405 00:22:42,876 --> 00:22:46,250 of test cases I've implemented. 406 00:22:46,250 --> 00:22:50,751 So generic test cases can be used to fuzz any USB device and then based 407 00:22:50,751 --> 00:22:54,083 on the spec for each of the USB device classes, 408 00:22:54,083 --> 00:22:57,501 I've gone through and developed fuzz test cases 409 00:22:57,501 --> 00:23:00,626 for a bunch of those as well. 410 00:23:01,375 --> 00:23:03,667 So you can see all the layers in there. 411 00:23:06,334 --> 00:23:13,250 Let's do a quick fuzz attempt. 412 00:23:13,250 --> 00:23:16,125 We know it supports the image class. 413 00:23:16,334 --> 00:23:21,083 So if we say fuzz the image class, so it takes each one of those and it 414 00:23:21,083 --> 00:23:25,459 is basically, you know, going through and saying, yep, I'm 415 00:23:25,459 --> 00:23:30,167 an image class device with this particular test case that we are 416 00:23:30,167 --> 00:23:32,501 starting to fuzz. 417 00:23:32,709 --> 00:23:35,292 You can't see what's going on on my laptop but it is checking 418 00:23:35,292 --> 00:23:37,292 up loads of errors. 419 00:23:37,292 --> 00:23:41,709 In a minute, it will actually check up a really serious error. 420 00:23:42,292 --> 00:23:44,083 You won't be able to see it from there anyway, so you have 421 00:23:44,083 --> 00:23:45,501 to trust me. 422 00:23:45,876 --> 00:23:48,876 It is a great way of identifying bugs. 423 00:23:48,876 --> 00:23:53,209 And just through testing of e map, I have identified a whole bunch 424 00:23:53,209 --> 00:23:56,083 of bugs in different OSs. 425 00:23:56,250 --> 00:24:00,209 It is not quite ready for primetime yet. 426 00:24:00,209 --> 00:24:03,167 It needs a little bit of tweaking and it needs me to implement 427 00:24:03,167 --> 00:24:05,459 the remainder of the device classes 428 00:24:05,459 --> 00:24:07,999 before I make it public. 429 00:24:07,999 --> 00:24:12,501 But once I do, it will go live on our GitHub so you can download it. 430 00:24:12,751 --> 00:24:21,542 So if I just stop that and go back to my wrapup. 431 00:24:21,542 --> 00:24:24,999 So overview, you can enumerate supported device 432 00:24:24,999 --> 00:24:30,542 classes, operating system information can be enumerated. 433 00:24:30,542 --> 00:24:32,751 So if you want to emulate any of the device classes 434 00:24:32,751 --> 00:24:35,626 and you know a specific vendor I.D. 435 00:24:35,626 --> 00:24:37,209 and product I.D., you can do that. 436 00:24:37,542 --> 00:24:40,501 You can then fuzz any USB host implementation 437 00:24:40,501 --> 00:24:43,375 to identify bugs within that. 438 00:24:43,626 --> 00:24:48,250 And as you can see, with the classes, sub classes and protocols, this 439 00:24:48,250 --> 00:24:51,292 is an enormous attack surface. 440 00:24:51,292 --> 00:24:52,999 Lots and lots of this stuff is implemented 441 00:24:52,999 --> 00:24:56,250 in OSs and people just don't know it's there. 442 00:24:56,250 --> 00:24:57,334 It's just not used. 443 00:24:57,417 --> 00:24:59,292 But it is there as part of the attack surface 444 00:24:59,292 --> 00:25:01,167 and it can be fuzzed. 445 00:25:01,542 --> 00:25:04,542 I mentioned end point protection systems. 446 00:25:04,542 --> 00:25:08,209 You can assess the configuration of them if they are USB based. 447 00:25:08,792 --> 00:25:11,459 Potentially circumvent them if you know specific devices you want 448 00:25:11,459 --> 00:25:12,999 to emulate. 449 00:25:12,999 --> 00:25:16,459 And, yeah, as I said, completely comprehensively test USB 450 00:25:16,459 --> 00:25:19,501 host test implementations. 451 00:25:20,751 --> 00:25:23,083 Wow, that's the quickest I have ever done that. 452 00:25:23,083 --> 00:25:24,918 (applause) Thank you very much. 453 00:25:24,918 --> 00:25:25,918 That was great. 454 00:25:25,918 --> 00:25:26,918 Okay. 455 00:25:26,918 --> 00:25:26,918 There's a big crowd in here and there are people coming 456 00:25:26,918 --> 00:25:27,999 in and I don't know why! 457 00:25:27,999 --> 00:25:28,999 Why are you coming in? 458 00:25:28,999 --> 00:25:31,459 (speaker off microphone.) You're wrong. 459 00:25:31,459 --> 00:25:31,459 You could stay but you wouldn't be staying 460 00:25:31,459 --> 00:25:31,459 for a damn thing because why would you ever believe 461 00:25:31,459 --> 00:25:33,083 anything that you read at DEF CON? 462 00:25:33,083 --> 00:25:34,125 The program is wrong. 463 00:25:34,125 --> 00:25:36,709 It's time to go get in the queue for tracks 2 and 3. 464 00:25:36,709 --> 00:25:37,999 Good luck out there, folks! 465 00:25:37,999 --> 00:25:39,792 Thanks for coming to Party Track. 466 00:25:39,792 --> 00:25:40,999 I will see you next year.