 I'm Nathaniel Boggs from Red Balloon Security and this is our talk on the Automotive Exploitation Sandbox. So Red Balloon Security, we do, you know, basically three things. Commercially, we license our host-based defense technology for embedded devices to large vendors. We also do a lot of fundamental research. And then thirdly, we like to do a lot of talks, raising awareness or educational, giving back to the community. And this is, this is one of those. So our goals here in this, for the Automotive Sandbox, is to educate all stakeholders about typical automotive attack chains and more generally, embedded device attack chains. And to actually provide hands-on experience with real hardware to people. So we've found we're going to different industry verticals, talking about security, working with large vendors, is that a lot of people, you know, have lots of engineering experience, that they really haven't learned about security before. And they just read some articles, have some buzzwords, but they never actually, like, hacked something, right? Which is always a fun experience. I think back to the first time you actually, like, hacked something to face the web page, you know, that you saw, you know, using a device in a strange way. But one of our goals for this is we wanted to really make it hands-on. So with real hardware, realistic exploits, you know, real code running on, you know, a typical operating system, and then provide, you know, we'll provide the exploits, but then talk through how an attacker would actually come up with those, what kind of reverse engineering they would do. And this is, we wanted to actually have a lot of depth to it, right? We didn't want to just have a little toy exercise in a VM. We wanted to have like a full software and hardware stack that then both as the amateur person who wants to just hack for the first time can enjoy it and have a walk-through, whereas then more experienced people can also then actually have the depth to really play with the sandbox, potentially write their own exploits, et cetera. So, and accessibility, so we wanted this to actually be free, publicly available, so if it's not available, you know, if you're, oh, we have to, like, come to us and, like, sign your life away and be like, I swear, I'll never do anything with it. It just, nobody's, nobody's actually going to use it, right? So we want to actually make it available on the internet. We're going to have really clear instructions, right? So we actually tested these instructions, like, here, here's our office administrator, like, can you get, can you run through this thing? Tell us where we're too technical, we don't explain it well enough, and then remotely accessible. So if we're doing real hardware, it's very expensive to, like, hand out everyone a dev, you know, a few hundred dollar dev boards. So we actually want to actually do that remotely. So to build this out, we, you know, we obviously want to, like, segment this far away from any sort of internal network. We want to have this completely isolated. So that's what we did. Put a firewall in front of it, and then you can see we have these Saber Lite development boards, which is what we used for this, because this is a typical board for automotive. And then we're like, okay, well, if the people are hacking these, we need a way to reset the boards periodically to a clean state. So we put up remote power that we can check and control and reset the board, have the boards boot off of the network off of TFTP server. So we're going to actually reset these boards to kind of a pristine state so that people can do it. We have a walk-through web server that has all the instructions, not wave my arms too much. So the hardware, like I mentioned, is the Saber Lite board arm, you know, pretty typical here. Here's the breakdown. We're a little tight for time, but, you know, you can take a look at it. You know, multi-core kind of typical features. We used the QNAC 6.6 microkernel for this. This is fairly common in automotive, especially, and gives you kind of that depth. We just used a little simple web server. So, you know, any sort of embedded device is going to have some exposed network service. That may not always be a web server, you know, in automotive, maybe something else sometimes. Oftentimes, embedded devices will have web servers. So for this, just to make it easier for people to follow along, we went with a web server. And then we put in synthetic vulnerabilities, right? We're not going to, like, find zero days and port them here. But these are inspired by, you know, very common vulnerabilities that we've seen time and time again. And embedded devices, a command injection, a heap overflow for the initial remote exploit, and then a kernel arbitrary memory modification via a vulnerable system call for a privileged escalation type of attack. I mentioned before, we wanted this to be ephemeral so that, you know, we don't have to manually, like, reset the board, reflash them or something every time somebody walks through the sandbox. So now I kind of go through a high level walkthrough. And then depending on the time, I'll actually take you through actually doing it on a board. So the stage one is where, you know, we're going to walk people through our initial remote exploit, right? So this is where they're going to connect to the web server. There's a little file upload option even, just to make it a little easier for people. And you know, which you do see, sometimes somebody wants to upload their logo image or something to the device to, like, brand it. And then there's two vulnerabilities that you can choose from for the initial remote exploit. You can do command injection or a heap overflow. And then with that, after you upload netcat, you can then get a remote shell. So you can actually then connect to the device, have a user privilege cell. And then you've, you know, gotten your first first foothold on on the device. Then stage two, right, we want to use now this user privilege shell to do privilege escalation to get you a root shell, right? So now you're going to then run an exploit to compromise and use the vulnerable syscall to modify memory. And the one that we used for this was, okay, you know, we can use this vulnerable syscall modify memory, and we can just modify the SU binary to instead of prompting for a password, we'll just knock out that and return every password works, even no password, you know, and then I can get you the full, the full root access here. And then stage three, which is, you know, the fun part, where now you have root access, now you can modify the web server. We put like a little, a little flag on the device that, you know, it's only readable by root that you can read as, you know, the secret file that have a fun, fun message for you. And then anything else you can think of, right? So we'll walk through users on these two things, but it's a full system. So that's why we wanted to make it actually fleshed out real hardware. So you can actually do, do whatever, whatever you like. Okay, so now I'll actually go through a live demo. These is also available online. And if you got one of the flyers, it has the URL as well, the HTTPSandbox.RibblinSecurity.com. I'm actually going to do this on this local board here, just so no one hijacks the same board I'm using while I'm doing the demo. And I know, I know how you guys think. So here I have this local board. And this is, you can see here, this little SaberLite development board. So I'm going to bring up my web page here. So this is the, this is like local copy, but this is the same page that you'll see when you go to the, to our sandbox URL. You'll see kind of the overview of the sandbox and explanation of it, support email. And then you'll come down to these available end points where these are the actual, you know, publicly accessible IPs that you can go to. So if you click on one of those, then you're going to see, you know, a little mocked up web page of a typical embedded device web server where you might have some different things. And oftentimes I'll have a diagnostic page where you'll have like, oh, I can ping things or I can upload files for, you know, rebranding purposes or something. Or maybe there's some other service here. So we put these vulnerabilities, right? So this one has, the ping has a simple command injection. The echo test has a heap overflow that then you can, can use to, to go through the exploitation. So then the actual walkthrough is going to go through, you know, in great detail, step by step. So it's going to discuss, you know, the stages, kind of what I just told you, and then it's going to come down to and actually give you, you know, example commands that you could run. So for instance here, you know, I have this semicolon, which is the escape character for bash, to run two commands instead of just one. So if this is going to ping something, I could ping something and run the ls command, for instance. So here you can see the results of your ping command, but then you can also see now the listing of the files in the local directory where this service is running, for instance. So that's how, you know, we walk everyone through, it's like, oh, that's how an attacker would see whether or not this is vulnerable to this type of command injection. And then we'll even have, you know, a little video play through typing it out just so, you know, right? So in our office admin, they're like, ping was, you know, what's box, you know, it's like, no, this is the actual box you type in, this is how you do it. So it's really going to, you know, both hold your hand all the way if you need it, which is fine, you know, we're loved to educate people who are new to security as well as kind of give you the highlights, the commands you want to run if you just want to like bang it out real quick and explore it and do your own thing. So you can also do, so things like this where, you know, an attacker is going to want to know what sort of system, you know, it's running, they might check and see and be like, oh, okay, this is actually Q and X system, it's ARM, little indian, so now I know, you know, the sort of tool chain I might need to compile the attack for this. And then we're actually going to then upload a file. So we actually have, you know, so you could, as an exercise as a reader, you can, you know, go out, grab netcat, open source, you know, compile it for this target and put it on there. That's going to be out of the scope of what, you know, a lot of people are going to want to do if they're very new to security, they probably also don't want to compile for ARM, little indian, random open source, you know, projects. So we actually have those files available. So we can actually just upload this and then we can now pull it over. So now this has been uploaded as a very random file here. I might want to save out that file name because those are randomized each time. And then we're going to want to mod it. So it's actually executable because when, you know, most web servers, you upload a file, they're not going to just give you the full executable right away. Although hilarious, you know, there's always the hilarious ones that just, oh, yes, this file needs 777 permissions all across the board. So now we actually give you the command, okay, now you want to run netcat to listen, to pipe, you know, the shell. So basically we're just forwarding all of the, you know, the bnsh into netcat, which just gives us this little network socket where we can interact with bnsh. Now you can see, oh, this web page is actually hanging because now I've started a program that's not returning. So now I can jump in here and connect back to it. Nope, if I get the right port, what port did I, oh, one, three, if I get my right leak port combination, then now, now I have a remote shell on the device, right? So I can check what ID, actually I'm so I'm running as nobody, which is probably what, you know, the web server is running as presumably, you know, then we can continue on. So we also have an in browser terminal. So we found very early on that, you know, a lot of these users who are new to security are running Windows. They don't have netcat installed by default. It's actually non-trivial install netcat on Windows. They're like, here, we'll actually make a little JavaScript web socket proxy that you can connect back to one of our servers that'll spawn up a netcat, connect to it, and then forward back, you know, the commands back and forth through your JavaScript. So even on a Windows machine, you can use, you can actually use this, have users walk through the whole thing. Okay, so we connected, we checked the ID. So now here's the alternative stage one where you can do the heap overflow exploit. I won't do that since we're running short on time. And now here, we know how to do privilege escalation, right? Now we're in stage two. So we can, if I try to do SU right now, it's gonna say it's sorry. I'm sorry too. I'm still nobody. This is very disturbing. And then, so we actually here have a walkthrough of how an attacker would then, you know, kind of reverse engineer this. So right here, okay, they know SU says, you know, the sorry string when you're wrong. So now I can, you know, look through the code, find out where that actual final check is, right? Look at the check, and then just change this string compare, you know, it'll always return true basically. So it's like these basic principles, but we want to make it accessible as accessible as possible to people. So now I'm going to upload, we have another binary to upload here to exploit the privilege escalation. So again, we write this one for you, whereas as an extra side of the reader, you could then use your user's tell to like pull down things and try to explore and actually write this exploit to exploit the vulnerable syscall that we injected. Again, we're going to want to chmod this. And then, and this is all these commands I'm kind of breezing through are all very in detailed written out here. So now this little tool here basically is just a primitive tool to do arbitrary read and writes of memory using this vulnerability. So if you run the help on it, you'd see, you know, kind of the details, but the two is going to tell me to write, you know, at this address, this binary hex, which is going to be the opcode that's going to just make this little change in the SU binary, that's now going to remove the requirement to have a password. And now it did not say sorry, and now I'm root, right? So it's just walks you through like very step by step, this process of having this visceral, you know, visceral reaction to being able to actually see what it's like to hack something. So for ease of use, you know, now you can do anything. For ease of use, we added another file you can upload that'll do like a large copy paste, so you can more easily deface the web server. But you know, you're root now, so you can do whatever you want. But this one is a little easier for the lay user to use. So again, we have to go through all the mechanics here, or I could do this actually inside my shell now that I have a shell as well. But this shell is just so more convenient because it's on a web server, so that's nice too. So now, right, I can put some text, the famous urname here hacker for instance, as he's really dastardly, he's hacked all kinds of things. And then I can actually, if I remember what file it was, I uploaded, now I can run this and copy over this this file. But you can, you can be, I hope you guys are more creative. You can have some cool ASCII art or something. So again here, we're giving you this memory address, which is actually the memory address of where the web server is storing in memory, you know, the text, the web pages. But that again, right, is an exercise to the reader. You could go through reverse engineering, search through the memory space, now you have root privilege and do that. So that's patching everything in. So now, if I'm lucky, and sometimes you have to do a hard refresh, you know, for these, but I can actually have the experience of like hacking, hacking the web server. So this may not seem like, you know, those of you who are more experienced in security, this isn't anything new or like crazy. But our main goal here was to really just detail this walkthrough so that anyone could do it. So then we also put a little secret flag here. So if I look in the data folder, there's a secret file. Right up here it does not work here. You know, that you can see is only rewritable by root. So, but I'm not going to show you what that is. You have to go and do it, and do it yourself. So that's the gist of it. Where's my presentation at? Yeah. So Sandbox is available here. Well, maybe. It's thinking about it. Well, Sandbox.RedBloomSecurity.com. You know, you're welcome to try it out, show your colleagues, send it to the person who always like, was like, what do you do? You hack things. How is that this magical craziness? Be like, no, here, it's actually not that hard. You know, experienced person will burn through this in like 10 minutes. Our office admin took like 45, I think. You know, but it's there for a whole set of users. So you have any questions that really does not want to show up? Okay, well, maybe it'll show. I'll just keep saying it. Sandbox.RedBloomSecurity.com. Any questions? We have no plans to take it down. If you all like, break it horribly. Right now we have eight boards set up. So if you guys physically destroy all eight of our boards, we'll be sad and like, maybe we'll bring it back up with bigger and better boards and more security or maybe we won't. But no, we plan to like keep this, keep this online for people to play with and to use. So, you know, now that it's set up, it's all pretty automated and as long as nothing horrible happens to it. You know, feel free, you know, it's there. You do what, you do what you need to do, but, you know, and they do power cycle periodically. So we'll keep an eye on it. But the goal is to leave it up. So every, I don't think we're going to run out of people who want to or need to learn about security and new verticals and embedded devices anytime soon. So, depending on the interest, we're definitely considered, you know, adding, you know, kind of a multi-state, right? The obvious next step is to say, okay, well, here's this little dev board. Maybe once you get root on this, you need to like go over can or something to some other device and like start building it out. Obviously that takes more effort. So, like, if there's interest, we'd love to hear about it, you know, be like, oh, this is really cool, but can you add this cool thing? And then, yeah, we've definitely thought about, you know, in the future we may continue to build this out. You know, especially as, you know, if we have internal things that, oh, we could just spend a little extra time and adapt it to this, where we have little tests and things that we, that we write for our own, you know, for other purposes, whether it's research or commercial. So, yep. Well, that's a very good question. So, we thought about that and we're like, okay, people are going to have some weird checkout interface and, like, we're like, no, free for all. You have more power to you. Hence why I have my board right here. Not, not one of the ones online. But realistically, you can actually go through most of the same thing. As long as they don't, like, really mess up the board. If they're just following the instructions, the only thing you're going to notice is that one, the webpage may already be defaced, but you could just deface over it and be like, no, your name here, no, my name here. And then when, if they already patched the SU binary, you're going to get root without having to patch it yourself. But that's the only thing. So, you can actually still go through most of the steps. But the boards do reset every hour and they're staggered. So, every 15 minute, you can kind of choose a board that has a little more lifetime in it. But yes, that is, there is a race condition there that we're like, well, they can still go through most of it. The other side of building all that out would be a lot more. Yeah, yeah. Sure. So, I mean, yeah, these are used actively in development. So, this is the kind of, the kind of thing. So, you know, this one of the ECUs you would see, what's going to make it, you know, very particular to a car is the, you know, user binaries that you're putting on it, right? So, obviously, this little web server is not, hopefully, not one of those binaries you would put on it. But you just, if you wanted to make it more realistic, you'd be like, oh, here's an old binary that was actually put on a car and you could put on it. And then you'd have a more, a more, you know, in-depth environment. But the concept is the same. You're going to have some service, there's going to be some vulnerability. Yeah, it might look a little different, but it's the same, so it's the same thing. Yep. So, I had one question over there, maybe. No? Oh, perfect. Okay. Two for one. Any other questions? I can end a little early and try to catch up on time. All right, thank you all.