 Hello, first of all say to everyone good afternoon, and thank you for being here. I'm quite impressed for All the people that is here on the last day the last talk before the last one Keep touching the wall, and I hope you guys are still here after the second slide hopefully so My name is Rafa and I work as a security consultant and security researcher for MWR info security in the UK That is my email address in case you want to send me an email after the talk I doubt it, but This is our labs website where the guys and me included, you know put our research But enough of me Let's see what this talk is gonna cover We're gonna be seeing different type of USB attacks And we're gonna understand the impact of this if they were to be exploited We are gonna we are gonna be Looking at different approaches for security assessment assessing USB drivers and how to identify bugs We also give details how we can actually implement these bugs in a USB hardware device itself So the talk will break down in the following parts First we explain different type of USB attacks, and we'll see how USB has impacted our society We'll look at different Fasting approaches for passing USB device drivers We'll see how these crashes can actually be debug and analyze and we'll see how can we actually get that bug and that Exploit and implemented in a hardware device itself And we have also some a few demos here and there to actually Supplement all this information so Once upon a time The serial port used to be our base frame for connecting a hardware devices to our computer It also was our worst enemy when it came to finding Drivers for unsupported devices, and we all have filled up pain But the era of serial port is unfortunately far gone And now we have the USB the plug-and-play technology and the mini USB device paint drives and it's actually a Bit of a pain in the ass to actually find a Computer with inbuilt serial port and for those that do hardware debugging is a bit frustrating There's some danger with USB And we have seen that Companies has well lately has been some a concerns about USB a port itself and we have seen this mainly at corporate level We don't have to actually go very far to actually Identify remember the famous a configure which actually is exploited the out of run functionality and display Spread as a warm by passing by using the USB devices Pass from hand to hand to exploit this vulnerability And we have also I found There is as in any software USB Driver has also got vulnerabilities Which can be triggered and exploited from development mistakes, but we don't have to get too technical when it comes to Exploiting USB attacks An individual come come to your company or to your organization Pretending to be the cleaner after working hours and actually plus plug a USB keyboard And after a period of time actually obtained a lot of information And we all have seen in the news When a business manual politician has actually lost a pen drive We are containing a lot of sensitive information and actually a Compromising this data But we have seen some concerns Organization has started to actually think about that USB is not actually that secure Major operating system has started to disable the out of run functionality At Corporate level they are starting to use and USB encrypted pen drive in case this gets lost And even we have seen in security policies that now a computer standard bill have a Policy where they disable the the USB port itself And there is also even software out there that actually allow you to set different USB devices come that can be used in a In a computer depending on the serial number but There is still dangerous there because a thing of the day is up to the user To plug that USB device into the into the computer and that involves security Education and security awareness that is something very difficult to combat with But how did I get involved in this research how did I start looking into USB devices? Well, it all came through one of our clients They have this They have this a half piece of hardware that does a staff And they wanted this to be tested before the new release was actually out So we tested it we the project took time in a period of two weeks And we had to test the project involved a little bit of everything from protocol fasting a revered Engineering and functionality hacking it was a really great piece of work basically was Hack the hardware in a period of two weeks as you could And of course included the new feature that was implementing in this new release, which was the the USB port So we start looking at the USB port We took different approaches black box black box white box testing which was a little bit boring And it required a little bit of source code review as we all know Black box testing which was the fun part because you don't actually see what you're Sending what you see what you're sending, but you don't see exactly what's going on And we face the challenge of passing USB device drivers And of course the bit based testing which really helped when it came to Doing this project So before we go any further let's have a little bit of technical background about the the USB communication between the host device and The host computer and the USB device The numeration is the face of communication between The host PC and the USB device and is where the PC actually Lends information about the device itself about its identity And the descriptors are data structures that the USB device Send to the host in the numeration phase and provide information about the configuration of the device The manufacturer type and its properties As I say the numeration is the device identification and it happened as soon as you plug the USB device in your computer It's automatic and in some operating systems is visible to us such as Windows where a pop-up Windows Where Windows appear? Telling you that a new USB device has been identified and it's in this phase where descriptors are sent containing general information about the configuration of the device We have different type of descriptors and here we have some important ones We have the device descriptor which Describes general information about the device and provide information such as the vendor ID and the product ID and the serial number It's in the Product ID and the vendor ID that we are going to be particularly interested because these are used to identify which device driver is going to be used Then we have the configuration descriptor which as it names dictates provide configuration information about the device Mainly relating to power management Then we have the interface descriptor which provides Information about an interface within a configuration We have the endpoint descriptor that provides information about the the The bandwidth that will be used in the USB port in USB bus and we have the string descriptor which is Additional information that the device the USB device provide to the host in the numeration process and this is human Readable data and providing information such as the manufacturer name the product name and the serial number Here we can see how a device descriptor looks like and we can see The vendor ID and the product ID being those what are going to be used to identify the the USB device that The driver that will be used in the communication And here we have a string the string descriptor We have the as we can see it's human readable data and we have the manufacturer name and the product name so Everyone touching the wall Yeah so we start looking as We were at the same time we were reviewing Source you a Linux USB a driver source code. We were discussing how we were going to be performing USB drivers fastened We came with three different approaches with which were the approach that fit it more to us in the time frame that we have in the project tie that we were performing and And I want to stop at this moment and say that I'm not selling here a Fasting framework tool or over fasting technique. This is what it worked for us and I hope it gives you some ideas We took three different approaches a virtualized approach using QM A network approach using USB over IP and a hardware approach Consisting actually implementing a hardware that will send more for data to the target system So QM QM is an open-source and machine emulator machine emulator a virtualizer And it's quite cool because it allows us to emulate us be Devices from the host computer to the gas operating system as if this was actually physically plugged into the into the device Into the into the target system The idea of this Fasting approach was to actually have a environment with our host system and a virtual machine With the same a I forgot to say that actually We perform a source code review because the operating system that was being used in in the hardware that we were testing Was Linux? As we all know secure operating system So we what we did in the in the in the virtual machine we installed Linux the set version that was using in the hardware device that we were testing with the idea of Emulating multiple USB devices from the host computer to the head guest virtual machine sending malformed data to the guest virtual machine For this what we did was to recompile QM with multiple fasting cases being each fasting case USB device to be emulated into the virtual machine The advantages of this approach is that it gave us a very quick start up to start fasting USB device device drivers It required very low Very little resources when it came into software and hardware first of all because QM is is Open source and you have in a virtual machine And it just required a little bit of programming here and there to actually make this work the main disadvantages is that we were With lack from a proper fasting engine engine and what I mean with a fasting engine is actually something that It's gonna be creating fasting cases for our fasting and we were relying in In a text files with containing malformed data and every time that we wanted to create a bunch of Fasting cases we had to recompile QM with with all out with all our fasting cases so We took a second second approach USB over IP with the with the aim of overcoming some of the problems that we found in the previous approach The idea of this is actually to get USB packets and sending over the network to the target system for that we look at I Is a Linux module called call USB IP which actually allows you to legitimate a share USB devices over the network So we we look at this this module and we got a couple of wires are captures We see what was what was being sent as it is also open source open source We look at the source code to actually create a little tool that will allow us to send To replicate USB IP packets So our environment to look something like this we have the attacker system With these tools that we created to replicate the USB IP packets We implemented already assisting network fasting engine Which will be creating our fasting cases The attacker would send the USB packets over IP at the target system. We will have the USB over IP USB IP module installed that will be in charge of Taking the USB packet that we are sending with the malformed data Removing the IP header from the packet and sending the USB packet directly to the to the drivers The advantages of this is that we had a fasting engine We use a already network-resistant fasting engine and it could create the different fasting cases The disadvantages is that we're relying in a piece of software and in this case being USB IP meaning that any problem in this Software would actually affect the reliability of our software of our faster. Sorry the third approach Our faster and the idea of this approach was actually to create a hardware device That could actually and be plugged directly into the target system and send malformed data This we didn't get to implement this approach because it's a quite a long-term project I would say And it requires more than two weeks that we had for the testing But the idea is that we thought about it and where to approaches The first approach would be to actually have the USB hardware that would create the fasting cases impersonating USB specific USB devices or multiple USB devices being plugged into the into the target system and actually send them malformed data The second approach that we thought with the hardware fasting it would be an among-in-the-middle approach where we would actually have the hardware device Performing among in the middle. So we will be plugging a USB device To this hardware this hardware will take the USB packet in the fly modify put the malformed data and send that directly to the to the hardware device As I say, it's a longer term longer term project And I know there is already people out there Trying or performing this type of hardware faster so We were reviewing This is the driver source code and Well, we were checking we left the fasting the faster running And we were every now and then as you know when you perform any fasting every now and then you go I checked the fast if if it has crushed if it has it identify something and at the same time we were also a performing some a USB a source code review and just suddenly while we were reviewing one of the Drivers USB driver source code. We found a development mistake a Vulnerability in one of the Linux USB device driver that we were looking at It's a pretty picture You guys keep touching the wall. Yeah, three seconds three seconds Three Spanish seconds and we found the bag Okay We found about in one of the Linux USB driver but a device drivers The bad news For some political issues, I can't actually disclose as much as I would like In this slide, I would have had actually the Vulnerability that I found actually the device itself and I cannot put the picture. So I say I'm gonna put a pretty picture All these Political issues happened. No very long ago Actually a couple of days ago. So I have tried and I have I would like to say here today that I'm hand-over But I'm not because I've been working on these to actually show you as much as I can and So I had to modify a series of things to actually show you, you know, what is really going on without actually You know what I mean? So The vulnerable device as I did this in Vegas is Vegas girl. I don't know why And it's a buffer overflow vulnerability That is happening in Tom dick and Harry function. I know why is that name? I'm not gonna say Tom dick and Harry function a function is in charge always responsible for handling the Usp is a String descriptor and if we go back to the technical background slides the The string descriptor is is that? A data structure that send human readable data the manufacturer name We saw that before the manufacturer name the product name and the serial name and it's actually data That we control because it sent from the USB device to the host computer Which means that we can't actually? cause this We can actually trigger this buffer overflow so USB string function is actually Well, it's not similar, but we can think of as a main copy was entering string copy because we are actually copying from a to be Into a buffer and we are at the buffer that we are overflowing Overflowing is used by an element of one of the USB devices structure So what we what is actually happening? We are just copying too much data that buffer and allowing us to actually overwrite other elements of the data structure and we'll see later what Actually can can happen with this and what we're going to do to demonstrate the the The the vulnerability we are going to do a kernel crash demo So for the kernel crash demo as the QM fasting that we had before what we are going to what we are going to have is QM running on a virtual machine With Linux and with the vulnerable USB device Driver and what we are going to be doing is emulating our malicious Vegas malicious Vegas girl that sounds big I'm malicious Vegas girl device so we start QM This is started and we can see here the vendor ID and the product ID Being those what it's actually going to identify The device driver that's going to be used Of course, it's not zero zero zero zero and we are going to be looking the data in this case is that it's going to be overflowing The buffer for the limit element of destruction So we go to QM and we go to QM and I've been console and we are going to emulate the USB device And we get the kernel crash without Actually showing the IP because it will be showing too much so For crash analysis and there are many tools out there for kennel. I'm gonna hold on There are many tools out there for analyzing Kennel crash a majority of them based in GDP I'm quite a big fan of what did really work for me in this project was KGTV because it actually allows you to set breakpoints In the kernel in live execution So the environment I have set up is KGTV in the in the debugger system the target system running the Linux the Linux with the vulnerable USB device driver Connected with a serial connection And the malicious USB device a plug into the into the target system The target system having the running the Linux driver that would be Would be debug so what I did? I implemented I implemented this exploit in a hardware device and I use a peak a team family microcontroller Which is relatively easy to program and you go a lot of guides out there to actually do this And I performed the malicious Perform I implemented the malicious Vegas girl device I fastened the mic on to control it with a with a share code in order to exploit the device driver The device driver my little baby Looks something like this Which I will show here, which is a pk team effort in k5 50 so Let's do a little bit of crash and Ali demo of the crash analysis and exploit demo that I implemented With this device with the idea of what we're gonna be seeing is we're gonna be a Seeing the environment where I flashed the where I program the in Vegas car malicious device will be flashing the The microcontroller with our shell code and then will be Plugging this in the in the target system I'm actually going through to actually see what is going on with this exploit I just showed the end of the demo very good. So This is my environment for For programming the USB device using MP labs Just really quite cool software I'm not very good doing demos But that is going to be the a set of ace that will be The code that we're gonna be executing in this demo and this year's Are the different Elements of the data structure that we are going to be overwriting There is a static address and a pop return and we'll explain I'm not gonna get into details now about this but we'll explain this a little bit later So we compile our Our source code. Hopefully It would be good to have an error in a demo And we're gonna be flashing Our microcontroller the main reason for showing this in a demo is that this environment involves three laptops and and the microcontroller itself Plugging this around it could be a little bit of a for trouble. I Have problems with only one laptop Imagine with three So we flashed the the microcontroller and what we do this is gonna be our Devagger system, which is actually plugged with a serial port to the target system with them Vegas girl devices actually running What we are doing is just starting a gdb to connect to the to the remote system Be a serial port we connect to the target system And we send a breakpoint in Tom dick and Harry function that if if we remember is the function where they Where the enumeration process takes place and the string descriptor is actually a Pass from the device to the host computer so we continue we hit a function and We set a breakpoint in USB string Which is going to be doing the copying into the into the buffer We continue and there is our buffer and we are going to see the status of our buffer at that stage And as we can see at the moment the buffer is empty So we continue we hit the USB string function again, and we look at the status of our buffer And now we see that our buffer is legitimately filled with our set of face we continue and this where the with overflow actually the buffer and we Set we actually overwrite the elements of the data structure being the static address and the Pop return now the idea was the other static address and the pop return is to actually Get the Get the pop return just exactly after the seclusion of the stock and we'll see that later so we Have said we have seen we have said a breakpoint Where we are going to be writing the popular term and we see that we have control of ecx and ebx ecx being the popular term and ebx being a static address and we'll see what this Stacked the static address actually do We set up a point in 853 And we look at the status of the the instruction at the address So what we want to do is to actually with this move from ecx to ebx Plus three three C what we'll do it will get The pop return Into ebx plus it which will be the next instruction to be executed Which will be here which we where we where it is where we want to write our popular term so We step in And we look at the status so we've done already the move of data And we have our popular tone just right after The instruction that we previously executed you could for reliable purposes. You could actually put the pop return I need to be further down Okay, sorry So we step in and we get into pop ex what pop ex is gonna be popping ex I'm bringing execution to the next traction, which is gonna be I pointer with our shell code Close to where our shape of this and we return I will be executing address and we get a segmentation fault If we do backtrace we can see the execution path So we have the demo It's getting closer to the end the recommendations Disable not require USB drivers when you can actually try to Assess this the the USB Device driver that you need and actually just use the ones that you need in that way You actually will will close down a little bit the the The attack vectors and security test the USB drivers when possible And if you you have access to the source code do a source code review Oh, it's not you can also do black box testing And also in organization or company always assess the use of USB a risk Implement security policies when required Yeah assess the risk a Little bit of reference here more reference here and questions any questions Thank you