 Thanks for coming and uh please join me in welcoming Douglas McKee and Mark Borreza. Thank you and welcome. We're really excited to be here. We're glad you could come see our talk today. We're going to be talking about a zero day uh that we discovered. We're going to walk through our vulnerability research process, our exploitation process and post exploitation and hopefully have some really cool demos for you uh at the end. So first off who are the two crazy idiots standing in front of you? Uh my name is Doug McKee. I'm a security researcher for McAfee's Advanced Threat Research Team. I've got a little over eight years of experience in volume research and pen testing. And I'm Mark Borreza. I have a little over eight months of experience in vulnerability research and pen testing. That's great. So first off most importantly what are we here to talk about today? We're going to talk about an ICS system produced by a company called Delta Controls. They refer to it as their IntelliBus Manager. And what this is is it's called a building controller. It's used to manage systems in a commercial building, things like HVAC, lighting, pressure rooms, etc. And important thing to note is that this device uses a networking protocol called BACnet. That's largely how it manages these devices. BACnet stands for Building Automation Control Network. And I also want to highlight that this is not specific to Delta systems. This is an industry wide use protocol. It also has a slight, a little bit of router capability built into it, which I'll touch on here a little bit later. And before I go any further, I often get the question, how do you pick your targets or why did you pick this target? Generally at HCR we try to pick targets that can have a very high impact as if they were compromised. Obviously there's a lot of critical systems that fall into that. And this happened to be one that we were able to obtain. And also something of interest is the fact that it uses the BACnet protocol, therefore it's network accessible. So let me take a moment to explain to you how this works in the real world before we jump into hacking this device. So what you see in front of you is we have a wiring diagram of one of these devices potentially for an HVAC system. So you have the Delta controller, which talks over a CAN bus to something called modules. At the highest level, these modules take inputs and uses it to control outputs. So that each device is programmed differently from the installer. And depending on the state of those inputs, it changes those outputs. So in the wiring diagram in front of you, assuming it's an HVAC system, depending on the temperature, it'll do something like turn on or off a boiler, turn on and off a pump, et cetera, et cetera. And this is just one example. It's used across industries for multiple things, which we'll get back to here momentarily. So understanding this, how do we start looking for bugs or where do we start looking for volume research? Well as I said, one of the most important things for us from attack vector is we like the fact that it's network accessible. So in front of you, you can see an NMAP scan of the fact that it uses the backnet protocol. So now we know what direction we want to attack it from. We're going to do a network attack on this, hopefully. Well, what else do we need? It'd be really useful to have the software. Well, lucky for us, the developers left UART headers on the board, which was completely unauthenticated root access to the system. This made it simple for us to pull off the firmware. So if we look at that firmware for a moment, a couple important things to note is one, there was no ASLR and NX wasn't able. And also, it was quickly able to see that symbols were left into the program. This will become extremely useful and I will reference this multiple times throughout this presentation. So we want to use a network attack vector. So what does that mean? Well, we're going to start with fuzzing, like everybody else. So we decided to use a commercial fuzzer called Defensix. This fuzzer has a built in module for a backnet server. We weren't quite using a backnet server, but because of the router protocol, the routerness of the device, it had a lot of similar attributes. And one of that is the backnet protocol uses broadcast traffic pretty frequently. So we use this fuzzer as a starting point and started to fuzz the device. This is one of those packets that you see on the screen that the fuzzer chose to use as a test case. Couple things I'll highlight real quickly. Besides the fact that it's a broadcast packet, the fuzzer here is sending about 8,000 bytes in what's called the BLVC layer or the backnet layer of the packet. You can even see that Wireshark is telling you that this layer is really only supposed to be a maximum of 1476 bytes. I think it's pretty easy to see here that the fuzzer is trying to look for a buffer overflow attack. So we fire up Defensix, we run this test case, and after a few minutes we see this on the UART screen. Quite simply, what you see is that it's a core dumping and the system is rebooting. Now I'm a little bit of a pessimist when it comes to vulnerability research, so I never actually believe I found something the first time. And so I run the Defensix at least two or three more times. And for your amusement, I took a picture of Mark's face once we were running the fuzzer because this is pretty much what it looked like. And he got excited because we had a reproducible crash. Ironically though, I went back to that packet that I showed you on the previous screen and I sent just that packet to the device. Interestingly enough, the device did not crash. Well, I sent that packet twice and the device still did not crash. Through a lot of trial and error, I actually discovered that it took 97 packets to crash this device. And I'll touch on this here momentarily. But after discovering it took 97 packets, I was able to do it repeatedly. So that meant it was time to investigate further. Well, as you saw the system produce a core dump. So let's take a look at that core dump as a first place to start to try to figure out where to move on. Obviously we have a segfault here that makes a lot of sense, the device crashed. But what can we learn about that looking at the registers? Well, let's start with the R0 register. For those of you that haven't fallen asleep yet, you might notice some similarity in what's in the R0 register to the packet at which Defensix decided to send to the system. There's a lot of 22s or ASCII quotation marks. That's interesting. We know that that's network data. If we keep thinking about network data and we look forward at R3 and R8, R3 has the value 81 in it. For those of you that were smart enough not to read the backnet RFC, you wouldn't know that 81 is the first byte set in all backnet packets. This indicates the BLVC layer. Again, this indicates that there's some networking data in the system. And if we take a look at R8 and we account for the Indians inside the computer, we know that this is 47808 or the source or destination port. So once again, we have some clues that we have networking data where the crash is occurring. Obviously the next and most important question is where in the system is it crashing? And we can look at the backtrace in the LR register to give us hints on that. So let's just do that. Let's go to the exact addresses in memory where the crash is occurring. Well, lucky for us, we find ourself inside memcopy. And not only do we find ourself inside of memcopy, but the exact line of code which it's crashed on, it is trying to take the data in R3 and store it at the address located in R0. Well, this fully explains why the system crashed. R0 has an invalid address in it that came from our payload and it's attempting to store the first byte of the networking payload into that address. So this is obviously extremely interesting. But I don't know for you, the last time I opened up any commercial Linux application, memcopy was called more than once. So this is not enough. Sometimes memcopy is called hundreds of times. So what is the exact code path that triggered this crash? We can use the LR register to help us figure that out. In ARM, the LR register points to the instruction that's going to be executed after a function call. So to actually know what function was called, we need to look one instruction before the address being pointed to you by the LR register. But in doing so, we can see a function called SC net moved. Thank you again for leaving the symbols in. It was extremely useful. If we dig into a SC net move function, it's actually just a wrapper for memcopy. And this becomes a place to start as far as understanding why this vulnerability exists. And if we continue down this path, and we use the I2D compilers and a little bit of intuition, we can actually very easily statically analyze this bug and figure out why it's there. So I've renamed some variables here to help this be a little simpler to see. But what we have is we have a buffer, which I've named source. And that buffer is being used to read data off the wire through a socket function. That buffer is hard coded to be 1732 bytes, both in size and what it is to read off the network. And then after it's reading that off the network, it stores that in a variable and I've renamed that size. So I want to point out for a second that this in itself, there is no development flaw here. It's statically defined. It's ensuring that it doesn't read more than 1732 bytes. This is perfectly fine code. However, if we continue to look at this code, we'll see a second buffer, which I've named destination, which is allocated using the Linux packet alloc function to 1476 bytes. Again, if you didn't fall asleep in the beginning of the presentation, that number might mean something to you. That is the number that is the acceptable amount of bytes, which is expected in a back net packet. However, it doesn't match the 1732 from the other buffer. Those experience with vulnerability research and exploitation probably see where I'm going with this. There's a further call down the line where that sd net move function is called, and it uses both those buffers, but it hasn't validated that it's the same size. And hence we have a buffer overflow. But now I'll step back and remind you that I said just sending that large packet did not crash the device. In fact, sending two of the large packets in crash device, it took 97. So what's that all about? Well, the interesting thing is the large packet triggers a buffer overflow. It overflows a section of memory or an address is being stored for a future mem copy. So what we've overwritten is that address, hence why it was stored in our, our zero in the beginning. So in order to exercise this vulnerability, it took 97 more packets before it tried to access that address. And what, so what we have is we have the initial packet, which overwrites a section of memory because of the buffer overflow, and 97 packets later, it takes that data and tries to write it to that address. And we have a typical write what wear condition. This is really promising for us as vulnerability researchers, because this means that exploitation is highly likely. Well, now that we've analyzed this statically, and we think that we have something worth going forward on, we'd really like the ability to dynamic dynamically debug the system. Anyone that has done this type of work before, static analysis is great, but dynamic analysis really makes it a lot simpler. So as expected, we compile a GDB server for the correct architecture of our device, plopped it on there, and started to debug, except for we instantly had a crash. And as you can see, this has been heavily redacted at the request of the vendor. But what you have going on here is there is a, a watchdog error which occurs because we've triggered a watchdog timer and the system reboots. For those not familiar, in ICS systems, watchdog timers are extremely common. They're used so that if the system stalls in any way, because these are critical systems, it takes some action in order to ensure that the system doesn't stay down, and this instance, the system reboots. However, it's a bit of a problem if you're trying to dynamically debug the system. Well, because the error messages were left in, and because symbols were left in, it was actually very easy to track down this line of code. As you can see here, there are, I think it's about three, three counters, which are being decremented by five. So when the counters hit zero, it triggers the watchdog timer and it trips in the device reboots. Well, this is not a hard problem for us to fix as reverse engineers. We will just simply binary patch this, this binary. So we, we take the five, we change it to zero, and now as far as the system is concerned, it, it still executes that line of code and decrements the value, but it decrements it by zero. As you can see on the right-hand side of the screen, even Ida now removes that line. It's not that it's not there, it's just ineffective. So thinking that we're, you know, pretty smart, we reload this back home, the system, and we start debugging. And of course, it starts to work until exactly three minutes later. And three minutes later, the system reboots itself again. Now, at this point, Mark's pretty agitated because he thought he already fixed the problem. So now we're, we're looking and trying to figure out why the heck did the system reboot? Well, unfortunately, we forgot that in ICS systems, there's generally a hardware watchdog timer as well. And this hardware watchdog timer was set in boot, as you can see on the UART screen here, to 180 seconds or three minutes. So, how do we get past this? Well, if there's a hardware watchdog timer, that means the software on the system has to kick that watchdog timer. Well, in this instance, the developers for all of their functions exported the, the functions of the SO files, which means that all we had to do was use their code to kick the watchdog. So we wrote a small C program. We put, compiled the program for the device to execute those functions and then set it to run on boot up. And so when the system boot up, it called our watchdog kicker and it always kicked the dog. A combination of this hardware watchdog fix in the binary patch. And we were able to effectively remove the watchdog as a requirement for debugging. And we were on our way. Now, that was a short tangent, but I thought it was worthwhile. So let's get back to the job at hand. We want to write an exploit for the system. So, where are we at? Well, we have a broadcast packet with a payload of 1732 bytes. By sending that packet, we can trigger a buffer overflow. That buffer overflow by itself does not crash the system. In fact, it takes another 97 packets to cause the crash. But when we cause the crash, it manifests itself into a right-what-where condition. We know from our initial analysis that there is no ASLR enabled on the system, but we do know that NX or DEP is enabled. So, the next step is we want execution control. And if we have a right-what-where condition, this question simply becomes, what do we want to write where? Well, considering that NX is enabled, we want to find a location in memory that is writable that would allow us to gain some control of execution. Lucky for us, there's something called the global offset table. This is native to Linux. And it's a table created at runtime. Therefore, it is usually writable. And simply speaking, it has a list of function names and addresses. When a function is called, it looks up the address for that function, and then it jumps to that section of memory. Well, since we have a right-what-where and we can write anywhere we want, hypothetically speaking, we could take something like malloc, change the address of malloc, and then when malloc was called, we would be able to jump to our section of code. This would gain us control of execution. But we also need to know what function do we want to overwrite. Now we know where we want to overwrite, but what do we want to overwrite. This is a multi-threaded application, and so we really want to make sure that we gain execution control as soon as possible after the vulnerability is triggered. If we go back to where we saw the vulnerability exist in the SCNetMove function, we can see approximately 20 to 30-inch assembly instructions later. We end up with a function called SCD code backnet UDP. This becomes the ideal place for us to gain control of execution as fast as possible from when the vulnerability is triggered. With all that background, the next simple thing to do was to write our own code to gain to execute. And for that, I'm going to turn this over to Mark. Thanks Doug. Alright, well before we could finish ponying this device, it's important that we step back and look at the resources we already had available. So to begin, if you're paying attention and haven't fallen asleep, you know that we have execution control in the system using the GOT override that Doug mentioned previously. Additionally, the developers were kind enough to leave Netcat installed on the device. This is your granddaddy's kind with the dash E flag, so you knew this was going to be good. Lastly, we still control some memory on the heap from our initial buffer overflow, although a lot of it does get clobbered by the time we gain execution control. Okay, so that's all well and good. The next question we have to ask ourselves is, what do we want? A simple question, but as Mr. Gosling can attest to, sometimes you just got to ask. Well, we decided to start pretty simple. We wanted root access obviously, but ideally we also wanted persistence on the device across reboots. So the last questions we have to ask ourselves were, how do we get this? But more importantly, how do we get it easily? You'll soon see that we still had a very long road ahead of us, so we wanted something quick. Well, by looking back at what we already had available to us, a straightforward way to get root access was to use the Netcat already installed on the device to obtain a root shell or a reverse shell. We could accomplish this hypothetically by putting some shell code into that heat memory we control, and this shell code would essentially store a Netcat command for the reverse shell into R0 register, and then branch to the address of the system function in the libc. The system function, as you may or may not know, executes the command stored in its first and only parameter, in this case a Netcat reverse shell command stored in R0. This ultimately comes together to create what is commonly referred to as a return to libc style attack, and although this would not grant us persistence on its own, ultimately we could use our reverse shell in order to alter some of the startup scripts and that would that would grant us persistence on the device. So that's all well and good, but if we actually take a look at the heat memory we control, we'll see that it's actually not so easy. So the the memory we still have in that we control on the heap is the 22 bytes you see in front of you, and particularly we have the longest continuous chunk that we control is only 32 bytes long, highlighted there in red. Now why is this a problem? Well, the reason being is that somehow in this 32 byte section we had to fit all of our shell code instructions and the command string for Netcat, which on its own is 24 bytes. Using some very complex arithmetic, this leaves us with a grand total of two ARM instructions, which is simply not enough to do what we want. Now I know some smartasses out there probably thinking to themselves, just use thumb mode, you dingus, those instructions are half the length. But although this is a great idea, through trial and error we discover that thumb mode is actually not enabled on the processor on the device. So that's out. I'm gonna be, I'm gonna level for you guys here. At this point we were stuck. I couldn't sleep, I couldn't eat, I even considered switching over to an IOT webcam. Things were looking very, very dark, but suddenly I was struck with some motivation. I thought to myself, and if I could live off of chili chow, cup of noodles, register trademark for four years, then this should be child's play. And then I got thinking some more. Child's play, children playing, children play hopscotch, memory hopscotch. That was the key. Now what the hell am I talking about? Well, when we started digging in further, we found that we don't have to just use the 32 continuous bytes. We could use any section of memory we control, as long as it's at least eight bytes long. This grants us one shell instruction and a jump to the next region of memory we control, or hop if you will. So if we look back at the heap memory we control, you'll see two such regions that qualify. This effectively doubles the number of shellcode instructions we have from two to four, which is a great news. But we weren't out of the woods just quite yet. Unfortunately arm is actually very cheap with its immediate values to be, to, as an understatement, in fact it limits them to only a single byte each with optional zero padding left or right. This meant that if we wanted to load the address of system into a register, it would take all four of our instructions and that wasn't going to fly. Well thankfully we were able to use the address already located at R4 because it was pretty close to the address of system, so with a simple offset we could get there. In the end this resulted in shellcode that met our tight space memory space requirements and granted us a reverse shell. But instead of explaining in detail how cool this all is, how about I just show you instead. So here we have a demo video of the reverse shell in action. On the right half of the screen, I hope you can read it, is the UR interface of the device. Now the first thing we're going to do is we're going to run ifconfig to find out that it's IP address. So you can see there ends in 7.14. Next we're going to print out the first few lines of the program, the device's startup script. This is just to prove that we are in fact in the delta device and you can see the copyright message there. Next we're going to show that there's no instances of Netcat already running on the device, as you can see, we'll refer to this later. Moving over to the attack machine on the left, we start up a Netcat lesson there on port nine, this will capture our reverse shell. And on the same attack machine we launch our exploit script, which leverages the vulnerability and launches the Netcat command you see there. So once it's finished executing, we move back to the UR interface and show that there is in fact an instance of Netcat now running that wasn't before. And it has the same command string, so far so good. Okay, moving back to the Netcat lessoner, which should have connected, we run ifconfig again and the IP address match. Imagine that. And just to confirm, we do in fact have root access. Okay, that's great. Mission accomplished, right? We've got root access to the system, everything's good, raw. Like a tenured physics professor, we don't know when to quit. I mean after all, we wanted IO control on the device. We're more interested in the HVAC systems, the access control, the pressure rooms that are being managed by this device. And root access does not grant us that on its own. We need to keep digging. Our next strategy was to look at how the device natively handles controlling the IO hardware and maybe get some of that code to work for us instead. So the first approach we tried is to look at the database files located on the device's file system. Now something that immediately jumped out at us here is that I had no idea what the hell I was looking at. This was too complicated. Well, the next thing we tried is to look at what happens in terms of a packet sent when we try to change the IO state from the touch screen. And maybe we could replace some of those packets. Now those of you paying very close attention might notice that the structure of the packet is actually very similar to the database and that I still have no idea what the hell I'm looking at. This was still too complicated. While the last thing we tried is hooking to the IO control functions natively. And this turned out to be just right. Now as Doug mentioned before, symbols being left and proved invaluable here because functions of names like CANIL right output immediately jumped out at us because we knew that the IO modules were controlled through the CAN bus. Third of more, through reverse engineering of these IO control functions, we discovered that there was different ones dedicated to controlling each category of IO hardware and there were six such categories. You got your inputs, you got your outputs and you got variables and these can all be either analog or binary. Now our first initial naive approach was to try and execute these functions from external C code like we did with the watchdog kicking code. But unfortunately the handles to these hardware devices were trapped inside the program space allocated for the Delta's existing programming and they simply couldn't be accessed from an external code. Somehow we had to figure out how to insert our malicious code whatever ended up being inside the program space of the existing programming. While the solution ended up being something called LD preload and for those that don't know, LD preload is a Linux environment variable and its job is that any shared objects this variable points to are loaded first by the dynamic linker when a binary is executed. Now this is not a new or novel idea, this is actually a pretty common approach for inserting code into an existing programming's memory space which is exactly what we wanted to do. So in our case we used our persistence on the device to alter one of the startup scripts, have this variable point to our malware and then get it inside the existing programming. Now that's all well and good but how does this work mechanically? Well let's begin by looking at the normal operation of the device. So in normal operation the first thing that occurs is that the delta programming will execute pretty straightforward. Once the dynamic linker starts doing its job it loads the shared objects in the following order. First the dactetra binary which is the entry point. Then all the delta proprietary shared objects and finally all the other miscellaneous libraries like libc. Now once the programming is actually running you have an IO polling thread that consistently runs in the background and this is what calls those IO control functions I mentioned earlier. So in this case we're going to look an example where it calls the function can IO write output in order to flip a relay. Okay. Now how does our use of LD preload change all this? Well as before the delta programming will execute but now the dynamic linker loads our malicious binaries first before any of the other shared objects. This becomes important when that background thread is running because now it loads the uh it calls the function with the same signature in our malicious binary instead of the real one because those symbols are loaded first. Better yet through the use of a C function called DL sim we're actually able to get a handle to the real function at run time which means we can sort of do a catch and release approach where we intercept the calls to these IO control functions, mess with them however we want and pass it back to the real deal with the program being none the wiser. Okay. So this is all well and good. We had malware. We knew how to insert it but the question is where the hell do we put it? Well here are our options. Now this diagram is a very high level overview of the startup routine for the delta programming and through some reversing we discovered that our best approach would be to use the function highlighted in yellow, can IO init. The reason why is because as Doug mentioned or maybe not mentioned I don't remember is uh that this programming is all vastly multi-threaded. So in order to avoid race conditions or inconsistencies we wanted a function that was called early boot called by single thread and only called once and this function met all those criteria. Now what is it look like once the malware is inserted here? Well this is what it looks like. When this function is called our malware spins up a thread that runs in the background and it listens for attack or for it listens for commands set by the attacker over the network. Based on the content of these commands the malware intercepts the corresponding IO control function in order to control the device the attacker wants to uh influence. Now I've sort of been doing a lot of hand waving about how we actually alter these parameters in order to get it to do its job so why don't I dig into that a little bit? Now although there's a whole array of IO control functions they did share one key commonality that we were able to take advantage of and that's the fact that the first parameter passed to them is a data structure that essentially just describes the hardware being managed or being controlled. So in this case you see an output of it here through GDB and highlighted in red is the device's ID the first four bytes and this is unique to each device. At a 12 by offset highlighted in blue is the current state of the device which is actually the most useful. In this case we have 75 degrees Fahrenheit as a floating point value and then at an arbitrary offset you could also find a descriptive string of the device which is also extremely useful because this is how we know this device in particular is responsible for monitoring room temperature. Using this information is actually pretty straightforward to just alter the state stored in these data structures pass it along and then we have control of IO. Okay so now mission accomplished right? We control the IO we got root access well the answer is still no. The reason being is that our motto here at ATR unofficially is to overdo everything and in that spirit we decided to pimp out our malware of all kinds of premium features. First of which you get automatic discovery of all the IO devices. Sit back and relax as the malware does all the recon for you. Next you actually get remote control of the malware through an interactive TCP session. My therapist told me that the most important key to a healthy relationship is now am I saying this malware will fix your marriage? Yes that's exactly what I'm saying. Next you can see the state of all the hardware in real time. So you can see exactly how much damage you're causing. Who said happiness couldn't be quantified? And last but certainly not least with a single command you can revert the device to its original unhacked state wiping it off any traces that the malware was ever there. And if you call the next 30 minutes you can get all this and more for just 30,000 easy payments of 1995 taxes and shipping not included. And if you're still not convinced be sure to check us both out at ICS village where you can see this bad boy in action. Now we were getting pretty happy for malware. Our baby was looking pretty good but we're still missing one key premium feature and that's a remote attack vector. Now this looked pretty grim at first because after all we're using broadcast traffic and that typically doesn't travel over the internet. But thankfully a certain backnet technology came to save the day. And that is BBMD or backnet IP broadcast management device. A real tongue twister but suffice it to say it allows for the transmission of backnet broadcast traffic exactly the kind we're using. Imagine that over the internet between different networks. So on the diagram on the right you can see two such backnet networks each having a BBMD. The way this works is that broadcast traffic intended for a foreign network is first sent to the source networks BBMD. This sends it to the destination networks BBMD and its job is to rebroadcast it on the destination network. That's a bit of an aside but how does this help us? Well through testing we found out that using this technology allows for our exploit to work entirely remotely. Now let me repeat that. At the time the slide was created any eBMGR connected to the internet of its default network settings could be pwned 100% remotely using this exploit. This is all pretty scary stuff but what's the actual impact? What can someone do with this? Well for that I'm going to hand it back to Doug. Thanks. So as Mark said we confirmed that this would work 100% over the internet. Now I know everyone in the room will agree with me that no one would ever connect these systems to the internet that would be completely unreasonable. Oh that's right. Shodan tells us a little bit differently. At the time that we created this slide there was approximately 500 of these exact devices running firmware that was vulnerable to this connected worldwide. Because of the nature of this vulnerability and where it's found in the code if we extrapolate out that other delta devices likely have the same vulnerability this number balloons up to 1600 to 1700 devices. Give or take about 10% for known honeypots. So as Mark said in the spirit of overdoing things we actually decided to build a fully functional HVAC unit controlled by a delta system in order to demonstrate the effectiveness of this type of attack. So if you'll watch on the video as we move to the back of this demo unit you'll see all the components you would see in a real working HVAC system. You'll have valves, pumps, fans, etc. And this was actually created by a contract company that actually puts these systems into current data centers. So this is as accurate as we could possibly make it. The only thing that's not 100% accurate is we use cold water instead of a compressor because my boss would not pay $8,000 for a compressor. On this side we have an enclosed data, miniature enclosed data center again with all the normal HVAC components a raised floor and a server which generates heat. For a moment I want to draw your attention to something that was just on the screen the independent temperature sensor. The reason this is important is it's the only component that you would not find in real life and it's there to, we always know the true temperature in the data center regardless of what the delta says. Then on top of the system we've added some lights that just show the state of different devices and to indicate an alarm is active. Once again the boss got annoyed at having a siren so we forced us to turn it into a light. So, but this alarm would simply indicate whether an alarm has been triggered. This could be in the form of an audible siren, a light or even email notifications. This just indicates whether an alarm has been sent or not. So if this is the system, an HVAC system that is cooling a data center, what would happen if we applied the research we did to this system? Let's take a look. Here on the left hand side of the screen you can see attacker running the exploit script and the top right is a picture and picture of the delta controller. The attacker leverages the vulnerability to download the premium malware which Mark was talking about and a few other extra pictures and the device reboots in order to implement the LD preload strategy which Mark discussed. Now when the device comes back up we've been a little creative with the images to show that the device has been hacked and we will also log into the system. I want to emphasize that logging into the system is not part of the attack. We are simply demonstrating what the screen would look like and to follow along. It is not needed for that trigger anything of the attack. So something the attacker might want to do is control outputs on the device. This is as I said, the device's function is to turn outputs on and off. So what would it look like if the attacker started to modify these outputs using the premium malware? You can see in the bottom right hand corner that the device will react accordingly. In the top right hand corner the delta screen you might take notice that it is not updating. This is because the attacker has the ability to choose to change or not change the screen. If they want the user to know that something is changing they can change it. If they don't it won't providing them this attacker with a lot of different attack scenarios. Now on these type of devices there are multiple types of outputs. There are analog and binary outputs. What you just saw was binary outputs. We either turn it on or off. Analog outputs require a specific value, a floating point value like Mark was mentioning of room temperature earlier. So here what we're going to see the attacker do is modify one of these values and this time the attacker is going to choose to modify the delta screen as well. Just proving that we can do it either way. So we have the fan speed and we have the valve and you'll notice once again that the components on the actual demo rig react as you would expect. So and also as a premium feature we've built in a reset command which sets everything back to its initial state. Now with the attacker still having persistence on the box. So controlling output is kind of fun. We can think of some scenarios that we may be able to influence by controlling each individual output. But if you remember from the beginning of my presentation the devices are designed to take data as input and react. So what if the attacker was to modify the data the system was ingesting or the inputs. As you can see here the attacker is going to change what the system is reading for temperature to third from the real temperature to 30 and 40 degrees respectively. Now what happens in your house if the HVAC system thinks it's 30 degrees in the room? Well it's not going to kick on it's going to turn off right and you can monitor our independent temperature system on the bottom right hand corner of the screen and the temperature in the data center is starting to rise. And there's no alarms being triggered because the system thinks it's 30 degrees. Why would it trigger an alarm? There's nothing going nothing that's going on wrong. So this is just one small scenario of one purpose of these devices in HVAC system in a data center of the impact we might have. I don't know if anyone here manages a data center but what would happen if your data center went unattended with no HVAC for a long period of time? I cannot imagine that it would be a positive effect on the system. So let's look at some of the other scenarios that are possible with control of an industrial control system like this. One of the interesting things about systems like this is they are using a very wide variety of industries because they're using commercial buildings. You're not going to find one at home but you will find them in the different industries listed here. I'm going to take a moment to talk about just a couple. I'm going to look at healthcare, government and education. Excuse me. Healthcare is an interesting new case because that's usually used for something called pressure rooms. For those that don't understand what that means in a hospital setting there's different rooms are kept at different pressure points in order to prevent disease from spreading and it's not much. It's just a little bit difference here and a little bit difference there in order to protect things like the OR or quarantine areas. And if attacker was to get into one of these systems which is this is what it's used for and to just set all the pressures to the same value and chose not to update the screen and not to allow any alarms to send nobody would notice it's not something you're going to feel going in a room that the pressure was different. All of a sudden those diseases that were contained by one of these systems could easily spread throughout the hospital. Might sound slightly dramatic but it's definitely possible in this scenario. If we move on to a different situation and think about government through OSINT we were actually able to pull up documents openly available on the internet to see that these systems are used for access control in some state government buildings. I don't think I have to explain too in depth what the impact would be if an attacker was able to open and close doors as they chose in certain pretty sensitive areas of buildings. And lastly I want to talk about education just because I think it's fun when people ask me questions why would I care if you change the egg vacuum in my kid's room? Well, you probably don't care but one of the other avenues of attack on these systems is they're an entry point into the network. If I have a hundred percent control of one of these devices and it's not isolated which again is nothing we ever see in the real world but if they're not isolated from other networks this now becomes the point that we can leverage in order to get onto other systems. I don't know maybe stream cameras from different rooms out to the attacker's terminal screen or other things like that. All of a sudden you start to become slightly more concerned. So this is an example of some uses in the industry and because of this and because that it's a true RCE over the internet it was assigned to CVSS store of 9.8. Per McAfee's responsible disclosure policy once we understood what we have we reached out to the vendor. This was in late 2018. We assigned the CVE number and we started working very closely with the vendor. The vendor was extremely responsive and ends of June of 2019 they ever released a patch which fully mitigates this vulnerability. ATR has also tested the patch and can confirm that it is in fact effective. I'd like to take just a moment to highlight this because I think sometimes there's a problem in our industry with security researchers and vendors. Delta was extremely cooperative was wonderful to work with and we were actually able to come up with a solution to help fix this problem. And I think this really needs to become the gold standard in the industry for security research. We need to do this type of research to find these type of bugs and the vendors need to be receptive just like Delta was in order for us to be able to fix these problems before the before malicious attacks can be created. I hope we've demonstrated that the impact of these attacks can be pretty severe and if they're not attended to we can actually have a problem. So thank you Delta for your cooperation. So with that said that concludes the technical part of our presentation. I thank you very much all for coming. If you have any questions as long as the goons allow us to stay up here we'll answer them or please see us in the back. I believe that's where they're doing questions. So thank you.