>> I'm Jesse Michael. This is Nikki. Is that close? >> Close enough. >> Right right. We
basically would like to come here and talk to you guys about some USB security issues and
we've run into. And basically what we do is we do product security and we keep running
into security issues related to USB, but we kind of like to inspire people and describe how
to get started looking at USB. We're coming and going to teach you guys some stuff. We had like
a half an hour. So we're going to run through a little bit of this. If you have any questions,
look for the guy with the blue mohawk. We'll be walking the floor. Just come find us. Going
to this slide is slow. So basically, we wanted to come in and talk to you guys about USB
security and explain just how easy it is. Because it seems to be some misconceptions about how
do even get started and what to look for. And why you even should. Like a lot of people
think of USB as some academic thing or there actually is some interesting USB security
research here. I'm happy about that because more people are looking at it. We wanted to
basically come in and let you guys understand, it's actually a lot easier to get started with
USB and why you should look at this. So like USB is everything. So basically any device you have
or any modern system is going to have a USB device, you plug USB devices in all the time and
don't necessarily think about it. And it's integrated in modern platforms in interesting
ways that can have some security ramifications people don't think about. And we wanted to
highlight some of that and let you guys get started, essentially. So we didn't really
want to focus on the basics of USB other than pointing out it's been around since 1994. Started
out with the 1.1 speck. It was officially released in 1994. Over the years, we've gone up
from 1.5 to 10 giga-bit per second in 2013 with the 3.1 speck. There's a variety of
different devices like key boards, mouse, mouse storage device, video, we were possibly
going to be using a USB VGA adapter because my keyboard ‑‑ my laptop over here wasn't
working correctly. But it's used all over. And people think about it a little bit. But we just
wanted to bring some attention to some particular uses in cases that ‑‑ some people don't
necessarily think about that are kind of important. So there's basically like a ‑‑ like kind of
rush through the basics ‑‑ there's basically the four main pins. The B CC, and the data
plus minus differential pair in round. And then the mini and micro pin connecter has a on the
go ID pin just to be able to detect if it's a host or a device. And then the 3.0 and 3.1
added the superspeed differential receive and transmit pairs. So that's
basically the really, really really high level view. So if you look at the actual protocol
and specification, it's around 600 pages long and pretty detailed. So it's, it's good to
look through if you have a lot of time and want to get into some of the really low level
details. But. >> A lot of time or a lot of Coffee. >> Yeah, but these bottom layers, the
physical link and protocol area, those are primarily handled in hardware. All the major devices
is done in hardware. It's possible to find vulnerabilities in these. But it's kind of hard
and possibly require expensive equipment. So we basically were trying to focus on places to get
started. We're looking at the function and device layer and giving you guys some bigger
pictures of how USB is implemented into the modern platforms today. There's also
this idea ‑‑ so like, the idea that USB is involved, there's the question of do I need
physical access to plug something directly into the system. Bad USB talk over at
BlackHat with Carsonole and Jacob. It was a good talk this year basically describing how to
subvert some really commonly used devices and it has people talking about filling USB ports
with superglue in order to prevent this cycle of attacks. But you know, modern platform
basically, any laptop you have is going to have internal USB devices. So the HP I was looking
at earlier has three different USB devices internally, and all three of those have upgradeable
firmware. The ability sensor is a finger print sensor, and it has actually an AES block. And
that one actually does secure firmware update in a smart way. The broad come and the web cam
does also have updatable firmware components. So if you have firmware like completely
arbitrarily controllable device in your platform already, it could actually do some pretty
interesting things. And it's something that's not observable by the host. So the host doesn't
have any ability to look inside of this. Because it has its own nonvolatile storage. So you if
you do a firmware update of this device in your system, there's, there isn't a really good way
for the host to actually determine or like your malware software to determine if this
actually has been updated. So it's ‑‑ some devices have hardware that can even force an
update. But some devices, the update software is in its controllable by the firmware. So
once you've updated the software in this device, the device is actually controlling whether you
can do another update afterwards. So if you do the update at once, if it's not
running on your system, it's questionable whether you even have the ability to claim it
successfully and ‑‑ so another thing is that like, with this particular device, this is a
sync cable for an older phone. And you know ‑‑ so even devices that you might think are fairly
simple in how some interesting ramifications. This is just a phone sync cable. And it has a
complete USB to U ark bridge and has a complete 8051 core or 8052 core. It has its own boot ROM.
And ram and S ram. And loads firmware off an external ISD chip. So it actually has this
complete ‑‑ it could be arbitrarily controllable. You could rewrite the vendor ID and
VID and PID so it shows up as a completely separate device. You can change the USB device
descriptors. This is all something controllable over USB. You can basically just send a ‑‑
let's See. So this device actually has a number of vendors of USB request. And some of them
are ‑‑ you can tell it to reboot. You can tell it to force execute the firmware that you
have provided. >> We're going to see a demo later on. >> Yeah. So basically, you can tell it,
usually it'll check the IDC. It'll check the signature. And the signature is basically four
bites of program at all. It doesn't do any kind of integrity or verification of what's in the
ISC chip inside of here. And then it just down loads whatever firmware from the host. Other
side, you can send a request and get it directly to whatever you want to send to the device. So
you can basically, after the system is booted up. We can send an arbitrarily firmware package
through the device and execute whatever you want. Have it reconfigure itself as an
interface of a small storage or a whole variety of different options. And this is just
directly describing the data sheet. If you find this particular controller ‑‑ it even
describes, here's how it's been ‑‑ how to send firmware updates through this device. And
in the data shade, it specifically says these requests are primarily for internal
testing only, these functions should not be used in normal operation. But yeah, you can
find really interesting things if you search for these types of things in data sheets if you're
writing malware, this is one of the things you want to find. You can take advantage of these
debug hooks. This is designed for updatability and test functionality. But there isn't
anything that stops it from being used after it's provisioned and deployed in the
field. So you can take advantage of some of these debug hooks and upgradability hooks to do some
pretty interesting things. And this particular USB controller is used in a whole wide range of
different types of devices from this little USB sync cable up to multi-thousand dollars net work
infrastructure devices. So you can find it in some pretty interesting places. And this
type of capability actually exists pretty commonly. Like I was mentioning, devices that
happen to be already in your laptop, you possibly have something that is arbitrarily
controllable and can be used already in the laptop you have currently, and there isn't
really a good way to determine if it's been modified or to really verify the integrity of
this particular device that's already in your laptop. So some other things in this USB ‑‑ in
the specification is it's specifically describes how to read and write to this
nonvolatile storage that it loads it firmware from. Some devices end up where you can do
an update and send a malicious packet of halo to it. But it's gone once you reboot. But, this
you can be completely persistent. You can send it a malicious update and then they
reboot, they shut down the system, it's still running. So when the system comes back up,
this thing can potentially enumerate as any type of USB device including a hidden device
and send malicious scripts, send like ‑‑ it could also ‑‑ Like if it's attached when the system is
booting up, it can do ‑‑ it can send keystrokes when your system is booting even instead of ‑‑ if
you have some knot lets on the system. Actually I should probably talk about that in a
second. So there actually is a device firmware update specification. And this, the
original version is from the late 1999. And it talks about how to create devices with
upgradeable firmware. And they go in this all kinds of detail about what to do. But they don't
actually mention security at all. There's no mention of how to actually protect the firmware
in all of these devices. They do describe having a simple check sum because not possibly useful
for integrity. But if you have somebody who's creating a malicious payload, that's
completely by passable. And it was updated ‑‑ the first version came out in 1999, they came out
with an updated version in 2004, but they don't talk about security at all. It's just
updating the firmware. But there isn't anything talking about how to do that securely. And we've
run into a bunch of cases where a lot of different vendors do use the DFU, device firmware
upgrade spec. But they, they will follow this and they also will ‑‑ because many devices are
relatively low power, they aren't going to go through the whole case of having something
that uses full length RSA's signatures or any kind of public key signature application before
it runs and updates. So they'll do the integrity check and that's it. That's incredibly
easy to spoof. There are some devices that they do care about security more so they will do
this complete security check in like do signature verification. But it's much more of an on the
fly. It's custom, there isn't any approved way to do this. They're rolling their own
firmware update. So sometimes they get it right and sometimes they don't. But the vast
majority of the devices, they just don't even bother to have any kind of security. It's
fairly trivial to update these devices and just get firmware, get your own firmware running on
the device. And have arbitrary code execution running within the USB device. If you have
that, you can do some pretty interesting things. We'd like to talk about tax purposes. Like a
lot of people will think about the host and then a device and a USB cable in the middle. And you
can just disconnect that. But there's actually a lot more going on. So there's an
application. There's a variety of applications. You might have virtualization going on or two
to virtual guests. And even within a, also there's a couple different privilege level just
within the OS itself and your host. Considering the bios, SMM. There's the CPU. We've had some
interesting capabilities. And within the device itself, there's the firmware and in some
devices that can be as complex as running a complete LINUX distribution inside the device.
So there's devices that have really, really simple just little hard coded if you
remember ware. Others are running a complete OS. And it depends on what the clients do.
But, if you have the complete ‑‑ the complete complexity of an operating system running in your
device, there's much more likely to be other security vulnerabilities from that. And
it's, it's ‑‑ and also, especially with people trying to get devices out and into the the
field, time to market requirements and trying to get devices out into people's hands,
they aren't necessarily going to spend as much time validating things and making sure that its
as secure as possible; they want to going to it out and make the sale and get it out there. So
there's a variety of different interesting things going inside both your host and your PC- The
host and the device. And it's likely happening inside your laptop. So instead of just
thinking of a device that you need to physically disconnect and you don't even ‑‑ if you
want to be careful, like protect yourself and like ‑‑ I don't know that I trust getting USB
from this guy. But if I unwrap it for myself and I only use it myself, it's hopefully going to
be okay. But there's ‑‑ the devices that are already in your laptop that could be
compromised. We've had issues where devices have come from factory with firmware with
malicious or compromised firmware and devices on the devices. But if you have
something that's already in the system, there's some interesting capabilities then that malware
can take advantage of. And so, the devices in your system, some of them also have radio
interface. Like the description of the ‑‑ the device manager that I showed you earlier. One
of the devices I had was a blue tooth interface. So this is talking to outside, it also has
attack surface in bluetooth field. So if there's a blue tooth also like 3G modems, a
variety of devices have external interfaces. So it's not a situation where malware can
reprogram this. But if there's vulnerability within the radio firmware, you can take advantage
for that, that attack surface to get as a quick hold into the system. So if you ‑‑ there's a
variety of different ways you could arbitrary codex execution within the device. There's
malware running within the system already. Maybe in a virtualized guest. Again, in the
malware and virtual box and other virtualization system, you can pass through a USB device to
the guest and the guest have direct access through the USB device. But if you have malware
running within that virtualized guest. It could do a firmware update to this USB device also.
Which could cause some interesting problems. So if you're getting arbitrary codex
within the USB device, you can then use that to attack other components within the host. So
if you have one virtualized guest that reprograms USB device, you can potentially use
that to escape confinement or inject key strokes to bio system booting up. And there's a
variety of different ways you can attack this. So the controller we were talking about
earlier and showed the data sheet for, we could arbitrarily control the VID and PID of that
device. We can change the device descriptors. So what specific device classes show up as. From
the device side, force ‑‑ for disconnect and reconnect, you can reconfigure the device,
disconnect, and that will be reenummerated in the host. But when that's been passed down as
a virtualized guest, it basically shows up as a physical disconnect, which causes the
host to reenumerate the device because it's a different device, the virtualization software
generally uses the VID, PID as this is what ‑‑ this is device is has been passed on to the
host. When it shows up as a disconnect and reconnect, it actually can escape confinement
in that way. So you can inject key strokes to the host instead of the guest. Which is pretty
interesting. >> Or another example, if you have a USB to LAN adapter ‑‑ ‑‑ same
companies, USB LAN adjuster type of product, most likely the two chips will have the same
functionality. The VIM will get connected to the host ‑‑ ‑‑ you will have an entire network
attack surface connected to the host. >> And yeah, this type of attack can happen whether it's a
physical device you've added or if there's a device, a USB device already in your system.
My phone here has the USB modem is via the cellular modem I get access to, the cellular net work
that's a USB connection also. So what are the chances that the base ban firmer has no
vulnerabilities? >> Why haven't you tested that? >> I've played with it a little bit. Not a lot.
>> Still working. >> Yeah. So basically if there's a vulnerability in the base ware
firmware or the phone or something like that, you're basically getting arbitrary
access control within this USB device and then you have to basically bridge the gap across
the USB interface to actually get access to the host. So there's actually a pretty
interesting project called Katalia I think that has a variety of different really
interesting payloads for human interface devices to present to a host over USB. You basically
go to this, I think it's a release script and you can say I want to generate this payload to
like get credentials from a window's device. And it can do some really interesting things
and you basically generate this payload and create a sketch, but it's really easy to take that
payload and use it for other purposes you're not even using something. It was designed to be
used with TNC's and that type of device. But it is, I think it has 30 or so different payloads
that are pretty useful other than just like directed browsing and download and execute. And
getting malware running on the device. But it can do basically like adding a user with admin
permissions. The use of the login has admin permissions already. So like that type of ‑‑
it uses a power shelf for sending for payloads for windows. So it's a pretty
flexible frame work. It's designed for penetration testing. But it's basically a
good way to understand what you can actually do if you have a USB device you control and you
can arbitrarily program. So I was intending to add a slide for that, but didn't quite get that.
I believe it was Katalia. It's on gethub. >> We have a couple references for you guys later.
>> Another thing that a lot of people don't realize about is this debug capability within
USB. And that actually allows you to get low level D bug access over USB. And it's been
added to a window's logo certification, so any device that runs windows, it's going to
support this debug capability. And you can basically get in and internal debugging and stuff
over USB. And some other vendors are doing some more interesting things based on using low level
debug protocol. But with the ESAI version, it was around, but required special hardware. So it
wasn't used as much other than people like writing OS's. But the XHCI version that everybody
has now for the last year, couple years, is basically we'll go through standard USB hubs. It
doesn't use any kind of, any special hardware. So it's actually pretty easy to take
advantage of and play around with. And there's also this thing called media agnostic USB
that has just recently come out. The 1.0 speck that was just released in February of this
year, and they basically are taking the entire USB stack and swapping out the low level
physical link areas. So you can basically have the full USB protocol and stack running on
top of a wireless link. So they basically are designing this so you can have the complete
complexity of USB over wifi or why gig or some other protocol. The initial version of the speck
is specifically talking about wifi and why gig and they're making it flexible enough so you
can have other transport mechanisms. So it ends up looking kind of like this where
you've got the top parts are the protocol agnostic level and then everything else is being
transferred over USB or over wifi or some kind of wireless radio communication. And there's
some interesting things because it can actually ‑‑ instead of pairing and having the
credentials, it could do auto discovery, and that's something we really want to take a look A.
We haven't seen the hardware for this yet. But this is going to be really interesting and we
wanted to give you guy a heads up about this particular technology. Because this is on
the way. And I think it'll be pretty cool. So we wanted to talk about some tools basically
to let you guys know what's out there. And available to get starts with that. So the total
phase will equal 5,000, we've got one of these here. It's it's a nice device. It's kind of
expensive. But it does support USB three superspeed. So you can do protocol analysis and
understand what's actually going on even with high speed devices. But it's ‑‑ it is pretty
expensive. And it could only be used for observation not injection. So it has some
limitation. There's also, if you don't care about the 3.0 superspeed, there's the Beagle
480. Which is less expensive. We've got one over here for demos. It's a lot less
expensive, but it only supports 3.0. And like the 5,000, it can only be used for observation.
This is even less expensive than the Beagle 480. But they brake it up into some of the software
is sold separately. It depends on what you're doing, but that can be useful also. Most of you
probably heard of the face answer that Travis Goodfet put together. It's really nice. A
friend of mine sauttered this together. He didn't have the right resisters for a couple of
these, so he ended up with the three hole parts instead of the surface mount parts. This is
really nice because you can basically do ‑‑ you can emulate any kind of USB device and
basically write a python script in order to do it. But because it has a complete round trip
through the device to your host running python script, it could be really slow. And we ran into
a bunch of issues where it was way too slow for what we were using it for and we had to come
up with an alternate solution. You want to describe that? >> No no no no no I don't want to. We
don't have time anyway. >> Okay. So there's also the dice show project that Michael and
Dominick, Marshal, Jared, Mike and Ben are putting together. This is intended to do fall USB
three injection high speed protocol analysis and man in the middle. But they, we were hoping
to be able to demo here on stage. But it's not quite ready yet. But if you guys are
interested, just pay attention to it. It's ‑‑ it should be out very soon. But I totally want
one of these. And I think these will be really useful. There's also the USB proxy that Dominick
is putting together. It's basically taking a beagle blue in black and he's created
this ‑‑ yeah. So this is a cheep little device. But it has a USB hoax and device for it. So you
can, you have a tool that he can run on there and he is, his release image is basically a WM
insulation. And you could do complete man in the middle of USB two devices. And he's giving
a talk in the hardware hacking allegedly and demoing this also. So he's ‑‑ it's just one guy so
far. Dominick. But he's taking contributions. They could do some pretty awesome stuff. He
has a demo of being able to do like this on the fly write protection of USB devices or
like changing requests on the fly. So he has like a keyboard that's doing rock 13 while you
type. Just as a simple download. But you could do arbitrary modifications of the content on
the bite. So this is a great toy. And his software on that is pretty cool. So if you're
looking for just software, there's lib USB. And that's a good way to get, to start using
the devices even if you don't have any hardware. So you could install LibUSB. And install the
device driver so you can talk to the specific USB device. And this is another way ‑‑ if you're
talking to something that's physically saudered down to your mother board, you're not going
to be able to stick a beagle in the middle. But you could use libUSB to request firmware,
updates explore that space. Another thing we're doing Mickey create add peach publishers are
these are all on the DEF CON CD. But it's hooking up the peach, this awesome fuzzer that we love
a lot. And it's hooking to LibUSB we can do a variety of different fuzzing, different
fuzzing. >> Which is going to show in a minute in the demo. >> Data publisher, configuration
publisher, those are all on the CD. It's a visual studio solution. There is also this
Phison PS2303 framework which is, I believe the device in it is the chip that Carson Knoll
and Jacob Loul were talking about with BlackHat. This frame work is also on bucket. It's
been around for a while. But, it basically, it has a similar capabilities as the controls we
talked about. It has an 8051 compatible core. It has its own ram. It could run firmware off
of the NAN. And they're basically creating this project to use these flash drives as a
USB three development and penetration testing platform. So, this is another great thing
for you guys to check out. So now we move onto the demo. >> Can everyone see a visual
studio window? >> Audience response. >> Really? >> You need to duplicate it. >> I'm
duplicating it. I'll do it again. How about now? >> Yup. >> Awesome. This here is a USB
to LAN adapter. For my next trick, I'm going to plug this in, if I succeed. And I'm going
to show you this little piece of code that gets the VID,PID connected to the device and
reads the VID,PID. Which are stored on an E prom on the PCB. There is a data sheet I want to
show you guys that is publicly available for this device. It has an USB interface and talks
to the directly to the E Prom. One of the beautiful things about this, you look in the data
sheet, you find USB vendor data. Which will give you the exact bites you need to send and
receive in order to read, write, write enable, disable in case you need to write enable, and a
whole bunch of other stuff. I'm going to run through this. Now I'm going to change the VID,PID.
I can tell you where to change it to. For this demo I'm using libUSB.net. And libUSB. So if
you see under libUSB I have the net work device in here. The VID 170 and the PID 7203. So far so
good. Coming back to my tool, write enable, changing the VID, changing the PID and to double
check, I'm reading it back from the E Prom. Now the device is still connected. The device is
still powered on. There is a way to reader specific chip to trigger a hardware. Preset on
the pin. I haven't found that yet. Specks said it still needs to do something, it doesn't
really do it. So, in order to simulate a reset, I will plug it out and back in again. Microsoft
And now we have a Microsoft keyboard. (Applause.) Now for the fun stuff. I hope you all
have the DEF CON CD. No? Okay. Cool. So in the CD, you'll find this USB solution that has
the ‑‑ all you need to do ‑‑ all you ever need to fuzz USB basically with peach. If you
don't open with peach fuzzing frame ware, I recommend you Google that. It's an awesome
framework by Déjà Vu. And in the solution ‑‑ this would be nice. There are pit files. They're the
descriptors, the descripting files that you'll get to peach in order the fuzz things. In my
first demo, I'm going to use the data publisher for android ADB. I'm using a prepaid android
phone. Again, to do this, you need to replace the driver of the libUSB requires you to
replace the driver. We give you ring free access to the ring zero driver to talk to any
device you want. If I look at the android ADB pit file, all I'm sending to the device is
CNXN and host. Two first values you need to send to an ADB indicating for the new android,
you need to secure authentication and all that. So to keep it simple, these are the
values that this examples sends. And if it works, we should get a reply from the phone. I'm going
to run peach. I'm going to do a dash one because I want to run an iteration. In the description
it says if you're missing it dash font performs a single iteration. Which is going to be
run without fuzzing. Whatever value its set to it'll run for this example ‑‑ ‑‑ dash dash
debug so I can see the debug outputs from the publishers I've written from this. So you can
run this ‑‑ ‑‑ and you can see if you can get a response from that. Here's the example. Sorry.
Hopefully this works. Here we go. So we sent CNXN host. And we got that, CNXN device. Show you
I'm not lying. I have a sniffer here. And total phase 480 that we talked about. And I'm going
to run now on the line. And I'm going to run this thing again and turn on the sniffer and
you'll be able to see we're sending CNXN host. And we're getting back from the device
CNXN. You know Peach, you can take it from here, if you don't, pick it up. It's really nice.
Are we on time? Ooh four minutes. That was android. Now, the same thing for iPhone. A
little bit of different technique. ADB is based on data. Data transfers. The iPhone is
more of a controlled transfer. I need to put the iPhone in recovery mode. One second. Yeah,
if you have any questions, this would be the time. >> Where do babies come from? (Laughter)
>> I don't know. >> Why do you put the iPhone in recovery mode? >> Hum? >> Why do you put the
iPhone in recovery mode? >> Umm, this is the simplest example. It's the coolest one. >> Are you
aware of any software phase, sniffers for Windows? >> There are software solutions for
Sniffing on windows. >> Anything that's free? >> There are some that are free. But there are
some also that they look like they're malware. (Laughing) . >> Is there any sample security…
secure software for downloading a platform… (inaudible) >> Well, like a, how to do it correctly?
>> Like someone already wrote it. This is the library you should use. >> I don't know if
there's a good like ‑‑ here's a good place to go and use this for your USB device. The other
issue is just because these are ‑‑ they're often low cost devices. They aren't very high
powered. Like an 8051, if you're doing a full RSA 2048 algorithm in that it might take a while to
boot up and enumerate. So with the USB speck, it's supposed to be able to boot up as soon as
you plug it in, I think it has a hundred million seconds before it can ‑‑ before it needs to be
responding to requests on the USB bus. But if you have something that's really ‑‑ like
a low powered device, it might not have just the computational power in order to do like a full
signature check every time it boots up. So the ‑‑ I think-- I got 30 seconds. Keep going.
>> IS your demo ready? >> Yeah. Real quick, iPhone Demo. All these files are on the CD. What
I'm going to send to the recovery iPhone is this. Get environment round disc size.
Should this work, it should return 40 K in head. And I have the Sniffer running. There you
go. You're receiving in a buffer 40 K and a hex. 400 K, one million. I don't know. But this
is one of the commands being sent to the iPhone in recovery mode after a new image is being
uploaded to the ‑‑ before firmware images uploaded to the phone. It's one of the commands
that you get. So from the demo, you could do this with iPhone. Control transfers or any other
thing that the ‑‑ ten seconds, the other example on the CD is for this USB land dongL, you
just change the VID,PID to whatever matches your hardware. And use control transfers
according to the speck you have and you can do it yourself. And that is it. (Applause.) Thank
you "This text is being provided in a rough draft format. Communication Access Realtime
Translation (CART) is provided in order to facilitate communication accessibility and
may not be a totally verbatim record of the proceedings."