 You guys having a good day? Hopefully you're in the right place. One of the things that I do for a living, I teach at a university. And whenever you go to school, the first day of school, the biggest question everyone's mind is, did I go to the right classroom? Thankfully we have nice big projectors. If you're not here to learn about end point security and USB impersonation, go somewhere else. Unless you're probably all really just here anyway because the other tracks you really wanted to go to were full. That's okay. I can live with that. All right. So let's get started. Just a little bit of a road map. Why this talk? Who is this handsome guy up here? A little bit of brief history of USB. How does USB work? We'll talk about descriptors and end points in USB. Then we'll delve into mass storage devices. How do they work? And then we'll talk about the good stuff. How do you bypass end point security anyway? Talk about some micro controllers, devices that you can build for 20 bucks or less as advertised. And a little bit about some future directions that you might do. All right. So why this talk anyway? Well there are some organizations that are starting to use end point security programs in order to restrict portable media. They're tired of everybody just bringing in their stuff and sucking things off of their networks. In the movies what happens, right? Someone is stolen all the secrets onto a flash drive. And surprisingly nobody notices until after they've left the building. Do you ever notice that? There's an alarm. Oh wait, they just left. Darn it. All right. So a lot of software out there exists that's starting to come into the market that does the equivalent of Mac filtering but for USB. And if you know anything about Wi-Fi, you know Mac filtering doesn't work. So basically what do they do? They have device, they have software, it says are you on my good list? Are you on my white list? Your vendor ID and product ID? And if you're not, well guess what? I'll show you how you can build something for cheap that makes your device look like it's on that list. And why would you want to do that? Two reasons. You want to inject something and you want to extract something. So who is this handsome guy? I teach security at a small private university in Iowa. I like to hack hardware. I've been known to fly and build airplanes and do other fun stuff. And the last couple years I've been known to play with USB devices. So USB something's been around for quite a while. 96 they released the first spec and then they quickly updated it a couple years later. Back in the olden days they had 1.5 and 12 megabit speeds. 1.5 was called low speed and then 12 was called full speed. And then in 2000 they came out with a new spec and they added high speed, 480 megabits per second. Then they kind of took a break for a bit and they came out with USB 3. We're starting to see some USB 3 devices now that are really getting out there and they claim speeds of up to 5 gigabits per second. It's kind of like my cable modem internet. Yeah. Up to 15 megabits per second. Why is it I always get 3? So how does this stuff work anyway? Well it's made to be very simple. Simple from a user standpoint. So they have some nice idiot proof hardware. It's a pretty simple 4 wire protocol. And it's set up so that you cannot screw it up unless you try. So you know if you're used to going old school serial you know that you can very easily hook something up wrong and you're like oh that's the wrong kind of RS232 cable or oh it's got the 25 pin I needed the 9 and oh it's not a no modem cable and they got rid of all of that hassle. Also made it hot pluggable and they used differential voltages which is good for noise and things like that on your lines. And you can have some fairly long USB cables as much as 16 feet. There's some software involved. There's automatic configuration. There's no jumpers or anything like that that you need to use. There's a process called enumeration where it basically goes to the device and says tell me about yourself. And within the standard we have some standard classes for our devices. So we have human interface devices, printers, audio devices and then for today we want to talk about mass storage devices. So how does this work? Well it's a 12 step process. Now of course I have some friends in the media and they tell me that all hackers are intimately familiar with 12 step programs. All right. So you know what happens? You connect device and the hub detects it and the host which is usually a PC says hey it's informed there's new device and then it starts talking to it. It says what are your speeds, what are your capabilities, then it resets it, gives it an address, et cetera, et cetera, et cetera. So it all comes down to descriptors and end points. So an endpoint is really a virtual wire or a pipe if you will. It's a unidirectional virtual pipe. And by the way the end points have a direction and the direction is measured relative to the host. So sometimes things might seem a little backwards when you're dealing with USB you might think but wait I'm sending stuff out. No you're sending it stuff in to the host. Fortunately a lot of the things like pac-ment, fragmentation, handshaking and all that is done in hardware. You can get specialized controller chips to do this. And the address for each end point has a meaning. The high bit tells you whether it's in or out. And there are various types of end points. Control end points are something that every device has to have. You can have bulk end points which we'll talk about a bit today. Interrupt end points and also isochronous end points. So control end points. Most devices use this to communicate with the host. And every device has to have at least one. We call it end point zero not end point one because we don't program it basic. And the devices must respond to standard requests. So these standard requests are things like get, set your address, give me descriptors, change your power settings and what's your status anyway? Some of you may have gotten status input from your badges. How many of you have hooked those up to USB yet? Really? That's all? Okay. Just a little hint. They'll talk to you and tell you status. All right. So the devices can also respond to specific class requests for the class of device and optionally vendor request. So you could in theory have a very special driver for your kind of mass storage device. In practicality, nobody does that because nobody wants to rewrite the drivers. All right. Control end points. You got three stages in the control end point transfer. You have a setup stage. Hey, let's talk. Maybe a data stage depending on the kind of communication. And then a status. All right. So the status stage, you just send a zero-length packet back that says ACK. Yeah. We're all good. Interrupt isosynchronous. Don't really want to talk about them but just so you know what they are. Interrupts for infrequent communications, things like miles, keyboard, stuff like that. Isosynchronous is good for streaming media, et cetera. All right. Bulk end points. The good stuff. Bulk end points are used for mass storage devices. They don't have any guarantees on latency but if their bus is idle, which it usually is, you have some pretty good performance. It, however, if there are other kinds of transports on your bus, it gets superseded by anything else. If you're doing full speed communications, that whopping 12 megabits per second, you're allowed eight 64-byte packets and keep that number in mind for later. It'll be relevant. If you're doing high-speed transfers, you can use 512-byte packets. And this is used pretty extensively in flash drives, also external hard drives, so the transactions consist of a token packet and then some data, possibly, and then you send an act at the end. So what's a descriptor? Well, the descriptor. Describes things. They all have a standard format. The first byte says this is how big this descriptor is. In other words, hardware on the other side. This is when you should stop reading information. This is when we're done. The second byte is what kind of descriptor was this thing anyway? And the rest of it is the actual descriptor. Some common types of descriptors. A device descriptor is what's gotten first and it tells you basic stuff like, hey, how can I talk to this device? What sort of power requirements does it need? Configurations. Sorry, configuration tells you how much power. How many interfaces does it have? How do I talk to it, et cetera, et cetera. Interface then goes on to further describe the device and then we have endpoint descriptors which tell us about each of the end points and then string descriptors which just give us strings in Unicode. So device descriptor, what does it send you? First thing it's going to send you is the length. Then the descriptor type. In this case, it's descriptor type 1. USB and BCD. It's going to send 2, 0, 0 and hex. And then it's going to send you a couple of important pieces of information. Namely the class, subclass and protocol. Now, in the USB spec, you can send zeros which mean, oh, well, I'm not going to tell you yet. I will tell you in a ladder lower down descriptor. So I'm not going to tell you in the device descriptor. Maybe I'll tell you in the configuration descriptor or the interface descriptor. And, you know, other things like packet sizes. And then we have a manufacturer ID and a product ID. And in some cases, a serial number that has to be filled out. So this configuration descriptor is gotten next. And again, it starts with the length and then at the type, it's type 2. They're real creative, right? 1, 2, et cetera. And it gives you some information. The last bit that it gives you is the maximum power, right? Now, if you're going to make a little device, say something kind of like this, a little preview, that is going to fake another device, obviously I have some electronics that are going to require a little bit of power of their own in addition to whatever my thumb drive takes. Some people might be tempted to just crank up that power. Don't do that. The problem with that is if you crank up the power and your port cannot provide that much power, it won't enumerate your device. So usually 100 milliamps is pretty safe. And it's probably enough anyway. So don't get lazy and get all gung-ho and like, yeah, I think I need a lot of power, you know, five watts of power here. Don't do that, all right? Just a little tip. All right, then we get an interface descriptor. And again, in the interface descriptor, we can have the class, subclass and protocol. If we had zeros in the earlier descriptors, then we eventually do have to say, this is what kind of device this is. And then we have to describe our end points. Well, in the case of a mass storage device, as I'll say in a little bit, you're going to have at least three end points. The control endpoint, bulk and bulk out. And each of those end points has an address. And remember that the high order bit tells you the direction. And then it has an attribute bit field as well. And the attribute bit field will tell you things like, is this a bulk endpoint? Another thing you should keep in mind, you know, all this stuff you can get, usb.org, et cetera. A lot of these bits are reserved. If they're not zero, things tend to crash on you. All right, so just zero out stuff if it's not specified. All right, and then we have string descriptors. String descriptors give you unicode text. Again, the first thing it's going to give you is the length. Then it's going to give you the type. It's type 3. It's a string descriptor. And then it's going to give you a unicode string. Which, for most of us here, is pretty much ASCII text where every other character, every other byte is just zero. There is a special case. And the special case is string descriptor zero. String descriptor zero says, what languages do you speak, please? And here is proof that the USA has fixed and improved the English language that we got from the bridge. Because even devices you get from the UK report speaking US English. Which is by the way, hex code 409. Is that formula 409? Cleaning up the language? I don't know. All right. So now that we've learned a little bit about general devices and such, without further delay, let's talk a little bit about bulk only mass storage devices. How does this stuff work? So we're talking about flash drives primarily. What kind of hardware do they have? Software, file systems? How do you talk to them? Things like that. Here is a picture I shamelessly pulled off of Wikipedia of a flash drive. So you can see the different components. You know, you see things such as a big NAND flash chip, a little controller chip, et cetera. By the way, the little silver can, you probably know this from looking at your badges for the conference here is a crystal oscillator. But some of the newer drives, by the way, I've taken apart a few of these. And some of the new ones, they come in this big case. You have this big case and you're looking at it and you're thinking, okay, it probably looks like this inside. I mean, after all, Phil got this picture off of Wikipedia and it's never wrong. So sometimes you'll actually pull one of these apart and you'll find out that it's a big empty case. And they have one integrated circuit. It's really integrated. It's the little spacer in the USB connector. It's literally a chip that's got the four leads built on to it. And you're like, really? I had this thing that was, you know, a couple inches long. There was absolutely nothing inside of it. It even had a little sliding case and everything. But just FYI. So typically these thumb drives use NAND flash storage. You get about 10,000 right cycles on these. If you're writing to them in particular, you don't only get anywhere close to that 480 megabits per second, by the way. Again, it's like the cable modem. Up to this, but not even close. You can only write to it in blocks. Typical block sizes are 512 bytes. You can have other larger block sizes. Although honestly, I have a whole stack of these sitting on my desk at home. And I haven't seen a single one of them with these large blocks. Maybe I just don't buy the right drives. But I guess I like the cheap ones. Maybe that's what it is. And you can have some forensic fund with those as well. So how does this work? These flash drives present themselves as a SCSI device. So they really look like a SCSI hard drive to your computer. And you have typically 512 bytes sectors. And they use the SCSI control set. Most of these devices are pre-formatted as one partition. We don't call them partitions for flash drives. We call them logical units. We call them LUNs, logical unit numbers. By the way, here's a little tip. I have found that some versions of Windows do not see other than the first logical unit. So if you want to hide something on a thumb drive, put it on other than the first partition. And don't use a Windows compatible file system. That would be another good way. Sometimes the reported sizes don't match the actual sizes. You can use that to hide some information. A few years ago there was a big batch of cheap Chinese thumb drives that kind of went out in the market. I see some head shaking. Did you buy one of those? No, okay. And what they did is they over advertised. They said, hey, this is a four gig drive and it was really only two. And they figured by the time you filled it up, passed the two, then it would just start generating errors. And they'd be like, well, I'm long gone by then. It's like buying something in the flea market. Sorry, it wasn't a real Rolex. Other things to keep in mind, typically each 512 byte block needs 16 bytes for error correction. So you might wonder why is the size not exactly what it's reported to be. Software usually implemented in a controller chip. Has to detect communications, respond to requests, check for errors, manage power, things like that. What kind of file systems can you put on these things? Well, it's a block device. Whatever you want. Most of the time they come pre-formatted as fat or fat 32. For external hard drives I've seen those pre-formatted as NTFS. Or for a thumb drive, if you want to, you can put the true flash file system, the extreme flash file system, the journaling flash file system, or my personal favorite, yet another flash file system. It's kind of like YAML. Again, if you want to maybe potentially hide some information from Windows users, a higher order run with a non-Windows, i.e. Linux only file system can work really well. So how do you talk to this flash drive anyway? You have this bulk only mass storage protocol. Sometimes it's called BBB because it's all bulk. And unlike many devices, instead of using the control endpoints, you use the bulk endpoints. And there are three phases. There's a command block wrapper phase, where you send a command block in a wrapper, data transport, depending on the command, and then a command status wrapper where you say, hey, did this succeed or not? All right, so most of these drives use a reduced SCSI instruction set. And, you know, if you have to send or receive data, you use a bulk endpoint for that. So what does this look like? Here's a little C structure for a command block wrapper. It starts with a signature. The signature is really creative. Incidentally, kind of a funny story. I was reading a book on USB stuff a couple years ago, and they just had an hex. Here is this code. And I'm looking at it, and they actually had it reversed. And I'm like, wow. That's just kind of obscure. Well, if you look at it, it types USB-C or USB command. It's not so obscure. And then there's a tag that associates, you know, the packet. It's like a sequence number for TCP IP. And, you know, how long is it going to be? And some flags, et cetera. And then, finally, a command block wrapper. You have 16 bytes in this wrapper, and real commands are going to use 6 to 16 of those. So for example, if I wanted to format a unit, I'm going to have a command block. It looks kind of like this. The first byte is always going to be a command code. Again, what am I supposed to do? I have to know what the command is to know how much more I should really be looking at anyway. What's the logical unit number, et cetera, et cetera. Another example, if I want to do a read, there are different formats for read and write. This one is called read 10, and it's based on how long the command block is. All right. So what are some common SCSI commands? Format units is a good one, because you can, in one atomic operation, just format the unit and erase it. Inquiry, how's it going? Mode select, mode sense, read format capacity, read capacity, all those other things. Command status wrapper comes at the end. So you send a command block, something happens, maybe some data is transferred, and at the end you send a command status wrapper, and it looks kind of like this. And again, real creative, USB-S for status. By the way, if you're cheap and you want to view all this lovely USB traffic and you have a Linux machine, if you don't know this, you can use USB mod. So if you just do a mod probe USB mod and you fire up Wireshark, guess what, all of a sudden you have a bunch of USB buses available for you to trace this stuff on. Comes in handy. Of course, hardware, USB tracer would be nicer, but they're a little bit more expensive than free. So enough of this background stuff. Let's talk about the good stuff. How do I bypass this security anyway? So essentially what we're doing is impersonation or social engineering USB style, if you will. So if we know what an authorized vid pit is, we can use that fact to mount the device and then inject some code, get some stuff off of our device. Also, the device that I designed optionally allows you to do some right blocking. So we'll use some microcontrollers because they're fun and they're cheap. So, you know, when you're going to use a microcontroller, you can look at the different possibilities and say which one should I use. Well, AVR is pretty popular. It's using the Arduino family. A lot of code out there. Unfortunately, it doesn't do USB very well. Even the U-series chips that, yeah, you don't need the FTDI chip anymore, but they don't do mass storage. They will do HID stuff but they don't do the mass storage stuff. Same thing is true with the PIC family. A lot of people like them. I like them. They're fine, but just not good for this purpose. So the winner is neither of those. Couple years ago FTDI, you know, the people that make those little USB interface chips came up with a microcontroller of their own. Maybe they got tired of just making the interface chips. It's a little faster, 48 megahertz. And unlike the Arduinos, it has sort of a proper real-time operating system. It's got threads and semaphores and cool stuff like that. And more importantly, USB classes. So how does this work? These Finkelham 2 chips allow for two full-speed USB 2.0 interfaces which can be host or slave interfaces. The chip also has a whopping 256K of flash memory which, if you don't do microcontrollers, doesn't sound like a lot. And if you do, it does. 16K RAM and normal microcontroller kind of stuff. They have several development modules available which is a good thing because they only provide their chips in surface mount technology. So it can be a real pain in the butt for prototyping, things like that. They also have their yet another Arduino clone, they call the Vinko. It's got the Arduino format sort of with an extra row of pins that you can use. So they come in these surface mount packages. You know, here's a basic diagram of the block diagram of the chip which I'm sure you guys can't read anyway. It's in the slides. It does have a fairly decent IDE. It's not eclipse or anything like that but it gets the job done. It has some debugging facilities and such. So it does work. And in there they do have this nice ability where you can pull up the chip that you're going to target and you can point and click and say this pin is going to do this and this pin is going to do that. And again, one other difference between the AVR series and these FTDI chips is that in the AVRs when you go from one size chip to the next it changes the amount of RAM and flash where here it's consistent. So the only thing it changes if I go from a 32 pin to a 64 pin is the amount of IO pins I have available to me. So that can be nice and useful. You can develop something and then you can scale it up and down as required. All right. Okay. So what's the small package look like? You know, if I just want something tiny I can get something. I'm sure you guys can't see this so well but looks about like this. All right. So it's a little 32 pin development board. And I only have four pins to solder. I can sacrifice an old USB printer cable, solder it on there. And the disclaimer, only four pins to solder. If you're not fond of things like LCD displays and blinking lights and stuff like that. Okay. But so if you want to add that stuff then, okay, maybe you do have to solder a little bit more. If you're really not into soldering you could use one of those Arduino clones like this Vinko board shown here. Now you don't have to solder on a cable because it's got a hose and slave port built into it. Again, same disclaimer. All right. So how does this microcontroller based impersonator work anyway? What it does is it allows you to insert your flash drive and then enumerates it. And then when the PC, when you plug this device in the PC it says, oh, I see there's any device. Let me enumerate it. And it tries to get an authorized vid-pid combination. If it's not successful, it tries the next one. So there are two basic modes of operation in the device. You can either say, oh, I know what the vid-pid is. And I'll just set it. Or you can try automatic mode. So in automatic mode I have 500 of the most common vid-pid combinations and it will just scan through those. So high level design. It's a multi-threaded app. You know, it's got apps to say, hey, let's talk to this thumb drive, another thread that talks to your computer, some management threads and things like that. Also there's a timer thread. And what the timer thread does is if you're in the automatic mode, whenever the PC asks for a device descriptor, it says, oh, someone's trying to talk to me. And it starts a timer. If they stop talking to you after a second and they don't ask for additional descriptors, it says, oh, someone's blocking me. I'll go to the next one. And that's how that works. And there's also a thread for reading the buttons that come in. So main thread sits around, waits for packets to come in. If it's a whitelisted command, it forwards it on. It forwards on things like command block wrappers, performs the data transport phase, does a little man-in-the-middle action, and does the CSW passing. All right. If you're right blocking, if there are non-whitelisted commands, it just says, hey, yeah, I got your command. And then it does any sort of data transport phase. And then it says, you're good. It worked. All right. And now, initially, in an early design of this, I actually returned a unsupported command status if you try to do things like format my drive or write to it. And what I found is that strangely enough, Windows does not handle it correctly. So you tell Windows, unsupported command, what do you think Windows does? Tries again. And again. And again. And it never gives up. It's really obnoxious. All right. So the main loop just sits around waiting for stuff. And then I have a bunch of handlers. So this is just a quick example for the inquiry command. It gets a command block wrapper, allocates a little space, forwards it to the device, gets a response, sends it back, and waits for a command status wrapper, sends it back. You know, it's not rocket science here. Timer thread, as I said, will get started and it will wait for a additional queries for descriptors. And it will get reset if the device actually got fully enumerated. By the way, I don't currently have this set up this way, but you could start to brute force the vidPID if you got to the end of the list. And hey, source code is available if you want to do it. Other complications, Windows and Linux do treat these devices a little bit differently. One thing I found is that Linux sucks in a whole lot of information at the start, whereas Windows sucks in a lot less. It's one of the few cases where Windows sucks less. So what did I do for my testing? Primarily I used Udev rules. If you're not familiar with Udev rules on Linux, they're a really powerful tool and they're a little bit addictive, they're kind of fun to play with. So what I did was set up some Udev rules to say here's my white list of mass storage devices. And if it's not on the list, you can't mount it. My open source solution is a better value. It's equally ineffective, but at a better price. So why waste thousands of dollars when you can be just as insecure for free? All right. Enough. It's demo time. Some of the gamers might get the reference there. Evan, that was just for you. So here's one version of the device. I realize you can't see it so well. I hold it up here. But this is the slightly bigger device. As far as the board on the right is just a programming board. And then I have an LCD display. And I have the actual development board. In this case, there's a thumb drive plugged into it. The pot you see there is just for adjusting the LCD. And then I have a red light and a green light for the right blocking status. So it comes on initially right blocking so the green light should be on. The leftmost button can be used to toggle that status. And then the other buttons are used in order to set the bid and the bid. So by the way, is Java? Java, are you here somewhere? This video is dedicated to Java. Malik. Java made a comment recently how there seem to be a lot of videos out there on the internet for hacking and security that are nothing but people typing and clicking with music. So I dedicate this actual silent video with no music to Java if it plays. If it doesn't play, I dedicate it to Microsoft. It worked great in the speaker room earlier. Wait, it was already there. Please stand by. If it helps you, you can imagine old-time music. We got lucky today, facts are easy. Of course, if they didn't have USB W, you can look in the registry. To make the demo quicker, I didn't. So here you see the welcome screen and then it gives you an opportunity to set it or it goes into automatic. And notice that the green light's on. And I did time warp, by the way. It didn't instantly mount my drive. I should just insert Monty Python music here. Uh-oh. I got lucky this guy had a payroll file on his desktop. All right, just a little food for thought. How could we go, where could we go from here? Well, we could possibly speed it up again if you look in the registry and try to find an authorized vid-pid that's previously loaded. By the way, if you're not familiar with USB dev view, it's a nice little tool. It tells you all kinds of useful information on previously attached USB devices, not just mass storage. Um, we could use the larger device here, uh, to divine the vid-pid and then possibly pre-program a bunch of smaller devices if we're going to, like, in mass go and attempt to do something, maybe say an organization, we knew what was authorized. Uh, like everything else, you can thwart this device. It does only operate at full speed. If you were to detect that, um, you could possibly say, oh, I know that somebody's doing something bad. And you could use proprietary drivers, but you don't really see a lot of that out there. Um, it's kind of, even if you did, that's security through obscurity, which we all know is most security at all. Um, uh, one other thing, uh, remember, who remembers what's the maximum packet size for a full speed USB endpoint? 64 bytes. What is the default block size 512? So what happens is it has to fragment and unfragment all those blocks. So that does give you a little bit of a performance penalty, unfortunately, but, um, I don't know how you could do anything better other than find something that supports full speed. Right, just a couple of references. These are in, uh, the conference DVD. Uh, you can go to my GitHub, uh, in a couple of days since I kind of forgot to update it before I came out here. Or you can feel free to email me. I'm also available on Twitter, just at P poll straw. I know it's not real creative, but people can find me. So thanks guys.