Global Bob Show

Episode 11 - How a Zero Day Exploit is Developed!

Global Bob Season 1 Episode 11

In this episode Global Bob (Brian Varner) reflects on hackers that gave their life’s in the service of their country.  He also outlines a antimony of a exploit by walking you through how he developed a ZeroDay exploit into a connected power command and control relay system.

Transcripts are automatically generated.

Unknown:

All right. All right, here we go. It is time for the global show. Globalbob show we are the crossroads, technology, and politics. This is episode number 11. The timer the release is Memorial Day. And so as we start this Monday, and think about the ultimate sacrifice that our military folks have given to ensure the freedom of this country, I want to talk a little bit about here in the intro of some other people that gave the ultimate sacrifice to secure our nation. And to in particular, are our brothers and sisters at the Central Intelligence Agency, and our brothers and sisters, at the National Security Agency. You see, when you go through the turnstiles at those agencies, you're greeted with a very somber reminder of just how deadly this hacking and exploitation can be. Now, I know that on the CIA side, not all the stars on the CIA Memorial Wall represent those that were in a capacity for hacking. But the CIA does have what they call tops officers, or technical operations officers. And I'm pretty confident that some of those stars on that wall could be from some of the CIA hackers or the tops officers. But nonetheless, some of these folks are civilian. And to me, I think we need to include them at Memorial Day as well. Now, the NSA, which is part of the Department of Defense, they also have a wall. And they call there's the wall of honor. And NSA Wall of Honor has approximately 178 stars on there. Now we know NSA is chartered with making and breaking codes. And so I would rest assured that most of those stars on that wall are actually folks that gave the ultimate sacrifice while trying to exploit the enemy's communication systems. And so I want to stop for a brief moment and have just a moment to reflect of those guys than girls that gave their life to secure this nation. Okay, moving right along. So this week's topic, I wanted to talk about how hackers hack. Last week, we talked about why people get into hacking. And as I mentioned, the CIA and NSA are always hiring hackers. So if you have the skills, and you feel like you want to apply that you can go to their websites and upload your resume. And if you have something that they're interested in, then they will recruit you. And you could become a government hacker, if that's what you're into. But I want to talk about how hackers hack and I'm going to talk about also a exploit that I found, and so we can kind of talk about the anatomy of that. So if you have listened to previous episodes, you've heard me talk a little bit about the internet. And also we've had some light conversation about firewalls and Nat, right. And I need to introduce you to this just a little bit. So you understand that at your house. Most of you guys, I would probably say all of my listeners have at least a NAT and a NAT and a firewall and this term can kind of be synonymous. With the NAT or firewall let's just call it a firewall from here on out. The firewall is assigned an IP address that's public on the internet, in most cases, so anywhere on the internet, there is an address for your house and it's always changing. And that's where your router sits. So router NAT firewall what you Some all interchangeably. And basically what that does is allow your devices at your house, your Smart TV, your phone, your tablet, your computer, all of that to be connected through that single IP address. And then a derivative of that is is that the device is at your home or not directly accessible on the internet. So that's why it's kind of called a firewall in some instances. So what's important about that is, is that if someone knows your internet address for your router, your public IP address, then they can send packets and communications back and forth. But if your devices are behind this firewall, then they cannot, for all intents and purposes get to that device that's behind the firewall. So how do packets get in and out of that firewall? Well, the simplest terms, your phone at your house or tablet, when you go to say Facebook, then it goes through your firewall. And your firewall keeps track of that communications go into Facebook. And so when Facebook returns that web page, or picture, it goes through the firewall, and the firewall then sends it down to your device. So just think of it that almost everything can get out. But not everything can get in. Now, with a firewall at your house, if you guys have security cameras, you probably have done this before, you've had to forward a port. Now, when you forward a port on your firewall, that takes your public IP address, and it puts a map in to the device behind the firewall, which in this case, it would be your camera. So what you do is if you're away from your house, you can type in your IP address into the camera app on your phone. And then you can view your camera cameras remotely. So I know that's kind of really technical, but I'm setting us up for what we're going to talk about here in a second. So just to bring it all together, your firewall basically controls what packets get in and out of your home network. And in most cases, it is very restrictive. So your devices cannot be accessed directly from the internet unless you forward a port. Now for all my technical listeners out there, I know this is like 101 stuff. And as always, if anybody wants to dive in deeper, we totally can. Now, when I developed this exploit that I'm going to tell you about, it was a device that is used to control electrical switches, and electrical relays. And I'm going to walk you through how I develop the exploit. Now this takes many, many days. But I want you to kind of understand that how these things are developed out. And in this, it was a device that when I arrived, it's packaging. It said that this is optimized for military installations, casinos, hospitals, and other high secure areas. It's like alright, well hope I can find something into this. Now why did I go out and get this device. I've been involved for many, many years, developing out cyber ranges or cyber simulations. And what a Cyber Range is, is where we would find all kinds of devices. I mean, I think probably the numbers north of 200 devices total that we found throughout the years. And we would set up a scenario. And we would have folks from various governments around the world and also folks from industry. And we would set up the cyber range so they could practice their hacking skills. And so it was always an arms race between my team and the best hackers in the world. One we need to define zero day exploits. And now there's a term we should talk about. A zero day exploit means that the no one knows about it besides the person that found it or the team that found it. And it's called a zero day book. Has the manufacturer hasn't been notified. And that this can be weaponized to exploit things. And so every year as we're developing out these cyber ranges, there was a lot of pressure on us to find zero day exploits. So in this particular one, this was a zero day exploit that I found. Now, I should also mention that anytime I bought any of these components, and we'll talk about this on, on the next podcast that are coming up and things like that, but just know that every time I bought any of these components, I always bought them in true name with my personal credit card. And the reason why I did that was because I didn't want any special treatment, treatment being good or treatment being bad. If you contact a manufacturer and tell them that you're a security researchers, such as myself, and that you would like to have one of their devices, so you can exploit it well. Either they hang up the phone on you, or they'll send it to you, and give you maybe some code that's not in development and, and other things like that. And I didn't want, I wanted to, for me, I wanted to go out and buy one of these if I was a regular person that was just buying them. So I would buy them from on a credit card and get them shipped here to my house. And so I bought this particular device, and started to look into it. And I went through my normal procedures, you know, anybody that's in this industry, they kind of you know, have their strong suits with myself, I am a hardware hacker, I would say that I'm more proficient at that, which means getting into devices, and compromising them. And some folks are software hackers, that and researchers that their forte is to actually exploit software that's installed on boxes. But me I'm more of a hardware guy, as you'll hear in the future prod podcast. So this device, you hook it up to an Ethernet cable, and it has a web interface on it. And this web interface was kind of rudimentary, I could log into it. And I could turn the relays on and off in this had a bank of maybe 10 relays. And you really couldn't do more than that. You could do some monitoring of it. But it was pretty much just a web connected device that would turn relays on and off. So I started looking through the source code on the webpage. And if you all wanted to do the same thing, you can go to any web page and hit View Source. And what I started looking for whenever I'm doing that, is to see if the software that's serving up the web page, maybe there's a vulnerability in it. So I looked at all of the web pages I could get to I set a username and password. And it was, you know, kind of kind of boring. Now the case that this came in, it was very much industrial. So this wasn't like a little cheap piece of plastic when they said on the box that this is, you know, for high secure areas, which I thought was comical. I mean, it kind of passed the weight test. I mean, it felt nice and industrious. So then my next procedure was, well, I don't see anything that I can exploit that pops out, you know, really quick. So let me take the case apart. So any of my brothers and sisters that are hardware hackers, that's usually the first thing we do. And then a couple hours, we want to see the guts inside of this. So I open up the case, and I see some chips in there and I write down the numbers of the chips, the make and model. And some of them I just have from memory, I know that that's a chip that stores memory. And this is a chip that kind of serves as the little logic engine. But with this one, it was kind of a pain in the butt. Because a lot of times when these systems are put together, they'll have little pads on them. And these little pads allow you to take your soldering iron out, and you can put down a couple wires on it and then hook it to your computer and see if you can get some output and a lot of times that output will give you view into what the operating system is. But this one here, everything was soldered down. Nothing was socketed and socketed means is that the chips if you've ever seen inside of a circuit board where you can put a clamp on it and pull it off. None of them were socketed. So it was going to take a while to start doing some probing of the internal chips. But the idea was is that if I could probe the chips, I could then maybe read the operating system off of there and start looking at the source code, or the compiled code, I'm sorry, not source code compiled code. And from the compiled code, I could run it through various software like either gi draw or IDA Pro. And that will let you start seeing if there's any variables that are in there that I could then create an exploit into. But in this case, I didn't want to take that time quite yet, because I wanted to see if there was maybe another way I could get into it. And when I hooked it back up, I started running some scripts. Now scripts with hackers, security researchers, you kind of start off by using other people's scripts. And then you start writing your own scripts just to help you aid in research. And so I had looked in a lot of these various devices. And so I started to run a script that would go to the web portal, right, the web portal of the device. And if you're not familiar with a web portal, or login screen, this is like your camera systems again, right? You type in the IP address of the camera. And then you're presented with username and password. So that particular part, I started running a script against it, that would look for directories. And so it would try, let's say the IP address forward slash admin forward slash test, forward slash, name, your forward slash, right, and I have a collection of about 100,000, or more forward slashes. And then what would happen is, is that if it was successful, then my script would stop and say, I received data with this directory, and then you can look at it. And so the scripts that some people use, it's called directory buster. So this was kind of a modified directory buster. And this is kind of a kind of like a point and click and or deploy and pray. And you just let it run for hours. I mean, it could take a long time, depending on the speed and stuff. But that did not yield me any results. So the next thing I went to was called fuzzing. Now, fuzzing is a term that security researchers use. And this is where you try to send lots of random information, some of it not random. But for all intents purposes, random information. So say, the login screen where you type in admin, instead of typing in admin, maybe it would put like, a 400 character username in there, and maybe for the password, you would put in, you know, you know, a couple 100 characters in there, and all this stuff starts running automated and fast. And so with my custom scripts, I had things that had worked on IoT devices in the past. Now IoT is Internet of Things. I call it Internet of toys. This really wasn't an IoT device. But anyways, I was running the fuzzer against it. And all of this happened over the course of about, you know, a week because I do have other things to do. Well, at one point, I was running the fuzzer. And I was looking at the output of the fuzzer. And it's happening so fast, you really can't see but sometimes you can see patterns, right? And just observe as the fuzzing is happening. Well, I heard a beep. It was just an audible and thought, wow, okay, what the heck was that beep. So I stopped the fuzzer. And I tried to access the device, and the device was really, really sluggish. So I unplugged the device and plug it back in. And I hear a beep. And I'll notice this like, okay, yeah, I guess I just, this is the first time I really heard it. But every time you plug in the device, it boots up, it does an audible beep. And that was really cool to me. I was like, Okay, well, if anything, this fuzzing something has caused this device to reboot. So then I start looking through the code and looking through and trying to figure out hey, what did what did this thing sin because you got to remember when the fuzzer is running is sending 1000s of requests per second to the little device. And so I found that and I don't want to go into the details of it. But I basically found that I could send enough information And in such a time that it would cause it to reboot the little device. Now what was happening is, is that the device had a software system in there that would recover itself if it locked up. Because you can think that, you know, if this device locks up and say it's, it's hooked to a conveyor belt or something, it needs to hurry up and reboot. Because what if someone needs to shut down that conveyor belt? And so that's why it had what was a watchdog timer. And that's pretty common with these devices. It basically says, hey, if I'm blocked up reboot, so I was scratching my head, I was like, well, if anything, I can isolate this, and cause some havoc inside of my simulation by saying that you can send some packets to it to cause the device to reboot. Now, mind you, when the device rebooted, it did not change the state of the relays. So if the relays were normally open during device operation, they would stay open. If the relays were normally closed, they would stay close. So this is really just kind of a lamer. I mean, this is like an annoyance, right? Well, we're going to tie all this back together and actually make an exploit out of it. Now, mind you, I say it again, this device, according to its packaging was for high secure areas. And a lot of my brothers and sisters that are involved in security, research and exploitation, and even some folks on record with the government and an industry basically, if you have physical access to a device, it's really kind of game over, right? I mean, it's, in this case, if someone wanted to cause havoc, they could just and they had physical access to it, then why wouldn't they just go, you know, take the device and smash it and make it inoperable. But you got to think when we're hacking into something, you know, the remote capability, the fact that you could do this remotely makes it a lot more dangerous. And what I remembered was was reading through the instruction booklet, and noticed that if you forgot the admin, password to the device, you could type in a special username and password. And what would happen is, is that the device would freeze all the relays where they were, and you would have to power cycle it, within 10 seconds, it was like 10 to 30 seconds, whichever one it was. And so when they made a mistake in their logic, when they manufacture this device, and that was, well, if someone has physical access, then they could cause harm if they wanted to. So this would be a way to ensure that if you reset the username and password, you had physical access to it. And but that's where their problem in the logic lied, is that, yes, I could send it and within 10 seconds is a very short amount of time, you just unplugged the power to the the little computer that controlled all this and plugged it back in and boom, it would set itself to the default password, only, it would not reset the IP address. And it would not change the state of any of the relays it was just a way so someone could put it in, unplug it, plug it back in real quick, you had 10 seconds to do it. And the manufacturer, I'm gonna say it one more time. In their mind, they said, Well, if you got physical access to it, you must be trusted. So what's the harm in this? Alright, so here we go. Now, these devices, I would not recommend putting anything on the open Internet unless there's actually a reason for it. And what I discovered was, is that a lot of these devices, because I have a system that scans the internet, and reports back and we can look at the banners. So I said man, I wonder how many of these things are actually connected to the internet. And at the time of my research, I would say it was north of 1000s of them connected to the internet, I was able to scan the public internet and get what we call open source Intel, which there's tons of services that do this for you. And I said wow, this is a lot of these things on the internet. Now this time, all I could do is send some packets that would cause it to reboot, but it wouldn't affect the relays or anything. It's like okay, good there beeping so if I wanted to deploy this on the internet, I'd have a bunch of boxes beeping now let's tie it all together. So I have a bunch of These are out on the internet, I have a way to reboot them. And I have a procedure, which I would call a logic flaw in the manufacturers assumptions, that if I type in the password that's published inside the owner's manual, and then within 10 seconds of that device rebooted, it would revert to a generic password that was also in the manual. Now, in my fuzzer, when it would run, it would take about a minute or so and I would hear the beep, not fast enough. So once I isolated the packets that was causing this, I was able to create a new script and point it at the device's IP address that would send enough of these fuzzed packets, these very special fuzz packets, and I can get this thing to reboot in about five seconds. Now, once I did that, then my script would detect the reboot, then it would go and change it to the password. Do you see what we done here, we exploited a flaw in the logic of the manufacturer. Now I can take these that were out on the internet, these 1000s of them. And I had a method that I could exploit them and get access to them remotely. Now I know that some of the terms may sound complicated. But here is the other mistake that was made not just from the manufacturer, but for the people that installed these. And so what we find is, is that a lot of times people just want things to work, they don't care. They don't want to set up a VPN to get into these devices. And so what they would do in these manufacturing facilities or anywhere, these were deployed, that a lot of them, the ones I was able to find on the internet, they simply went to their firewall, or their router, and put in a rule that said forward the traffic to the device. And this is the same thing that happens when you have your camera system and you want to view them remotely you put a rule in. And that's not the best thing to do. Because inadvertently, anybody that develops an exploit into the product that you have that's publicly addressable on the internet could cause some havoc. Now, if you listen to episode number 10, the podcast, I talked about weaponization. And this is a perfect example of stopping your research and not weaponizing it now the whole scanning of the internet or using databases that scan the Internet, I could have very simply weaponized this and had it download all of the publicly addressable IP addresses that have these devices connected to it. And I could have fuzzed it, and then change the admin password, and voila, I would have access to all of these devices. But you got to be a good citizen. In this case, I was being funded by a very large company that knew what I was doing. And I did write up everything and submit it to them. So I could do the smart thing and the responsible thing. And that is responsible disclosure. And, you know, once I sent it to our legal department, it was up to them to work with a manufacturer and tell them what we found. Now, what we did for this simulation, because this is something that was pretty easy, we actually had to harden the device. Yeah, that's right, we actually fix the device before we put it in the simulation to make it harder to compromise. The last thing I'll talk about here is is that this device, this exploit into this is what I would call a super set, exploit. Now this device that I had, it was marketed under a certain name, which I don't want to reveal. But whenever I started looking at other devices, they all had the same flaw in them. And what I gathered was and this happens a lot, especially with the IoT Internet of Things, that's why I call it the internet of toys. You'll have one manufacturer and their only job is to create the components, the computer system, everything for these embedded devices, but then they don't actually sell them themselves. They sell to manufacturers that put these devices into various components. And so while this name brand I had exploit into, I actually had the exploit, and to everything that or all the devices that the super manufacturer would put out there. And doing some open source research of the manufacturer, I found that a lot of their customers were embedding these inside of power strips that are used inside of data centers to basically turn power on and off, the other big group of it was used, and the manufacturer and an exploration of natural gas, oil, and other manufacturers of those products. And so you can see that very quickly. If this was to become weaponized, then we don't know what harm would cause by us turning relay valves on and off, or cycling power on various devices. Now in our simulation, what we did to actually show all of this is, is that we had it hooked up to an oil well, and so we had a company create us a mock up of an oil well, and it had oil tanks, and it had a oil offload into a tanker ship. And what we did to train the hackers where they had to log in and exploit this device, mind you, we had to harden it up. So they didn't exploit it too easily. And their job was to simulate an environmental disaster. So what they did was is that on one relay, they turned off the power. So the backup generator turned on, and so everything was good to go. Then the next relay, they open the valve, that was the overflow valve, even though nothing was overflowing. So they opened up that valve. And then the third thing they did was keep filling the tank with the valve open. And it would put this simulated oil inside the simulated ocean. Now, all of this was just to show that the ATTREX around that these devices we don't know where all there deployed at. But this is a scenario that could happen if our exploit would have gotten out in the wild. But, you know, the end result was we learned a lot. And while it sounds pretty simple, you know, when you put it all together, the exploit was pretty straightforward. But this is the kind of stuff that security researchers and hackers go through and is that one little nugget of knowledge that can lead to the whole castle that can lead to the whole house of cards collapsing. Well, there you have so we're at the bottom of the half hour and I really appreciate everybody for riding along. And I hope everybody had a great Memorial Day with their family and friends and pause and reflect those that gave the ultimate sacrifice to ensure they have our barbecues and even these podcasts. I would like to thank everybody that subscribes to the Globalbob show. Facebook page showing now the bombshell. Facebook Share Globalbob Show Hello everybody.