 So I'm Mickey, that's Jesse, the end that's Alex. We're going to start running by the slides. If the screen goes black, please scream so we know because there's a problem with the cable. I'm going to put a little bit of emphasis on this. Alex tells me that the first two slides and the last two slides are the most important in the talk. And you don't mess with the Ukrainian. So in high level we're going to talk about what we did, how we started, cover the vulnerabilities we found. And I'm guessing most of you are here to hear about the remote vulnerability. We'll cover that too. So we don't have time to do introductions, that's us. A little bit of a background. We started, we did a lot of things last year. So we faked the Defcon black badges, we did DMA attacks over the air using YGIG, we also hacked the Wemo and we did some radio infotainment stuff. Just for fun. Now we wanted to get into automotive, right? So we touched a little bit of the radio, but that's it. That's all we know. So what do we do? This is what we know about cars. There's autonomous cars, there's connected cars that talk to themselves, to all the other cars and to specific cars. And all this drive by wire stuff and we have no idea how it works. I'm not stuck. There you go. That's our budget. We really don't know what to quantify, right? You start, you go like, okay, how do I hack cars? So we already knew from doing the radio ransomware POC that how much of radio costs, right? We know it costs like around $1,500 new, half the price when it's refurbished. So we get a sense of cost. Where do we go from there, right? We go to the wrecking yard. So allow me to introduce the Hillsborough wrecking yard in Oregon. It's very, what's it called? Ordered and sorted, very nicely. Funny story about that. When you walk down a wrecking yard with one of the owners and you tell them you have a really nice junk yard, they get offended. So try not to do that if you do this. When we got in there, we said, hi, we need whatever car you have that's 2015 and above. So we start walking around the wrecking yard and we see Ford F-150 that's the size of a Fiat 500. Like, okay, that's a cool car but we need parts that we can use, not parts of parts. So we see another Acura, another Honda and a couple of other cars that are compressed. We're like, maybe, and then we walk by this. Like, that's a nice car. It's almost completely pristine except the dent on the front. They did have the motor out for sale in the front of the shop but yeah, it had a little bit of a fender issue. So we did a cut and a paste, no formatting in the back of my car, a bit of carception there, got it back to our lab, did a trip to the hardware store and lo and behold, we have somewhat of a front of a car, I don't know if I call it a third of a car. And then the challenge was to get it functional. So we hooked up a desktop power supply to it, right? Cars run on 12 volts. That thing outputs 12 volts. Yellow. It worked. It kind of worked. The car was still complaining about us moving. We needed to find a handbrake which was interesting. There's no handbrake. There's a handbrake. It's not a mechanical handbrake. It's a different story. Once we got all the electrical running, we had to get the connection working. So this specific car is a Nissan Leaf. It has the back end for Nissan is called Nissan Connect, also known as car wings. It's a whole website that allows you to control your cars, some of the cars function remotely. Like A.C., charging on and off. I don't own a Leaf, but that's what I hear. So we decided to try and get that connected. So we need to switch the owners. We call Nissan. We say, hey, we open an account on your website. We want to associate this VIN with our account. They say, okay, show us proof of ownership. So we go to the wrecking yard. We ask the guy, hey, can you give us the title for the junk? Sorry, the direct car. And that's his exact expression. Like, wrecking yard folks, they're not amused by anyone. So we can't move the title. What can we do? Do a get a bill sale? Do anything else? Okay. Let's try a Hail Mary, get a receipt of a wrecking yard, scan it and send it to Nissan. And we got it. So they connected us in the back end. We had a third of a car almost functional. Now, once we have that, we have to decide what do we go after, right? So we look at the radio. Just the IVI. This is the high level diagram for the, what's it called? The clarion based IVI in the car. As you can see, there's a lot of stuff going on. Okay, let's put that aside for a second. Let's look at it. It's running Windows Automotive 7. Okay, a little bit of Googling, a little bit of snooping. It's closed source, it needs license. But that's too boring. You want to hack the car, but not like this. Okay, maybe there's something else. Let's keep looking. So the car, the radio has a diagnostics mode. You do a 3, 2, 1 and it puts the radio in diagnostics mode. So we put ours in it and we're like, okay, put an SD card in, dump debug log and we get the navigation, debug data, contacts, waypoints, SRAM dump and flash dumps. Okay. Moving to the web vulnerability, we took the data from the debug logs and we run strings on it. So we find this URL in it. That's interesting. What's that? Do a who is, no one owns it. We look at each other and we laugh like, let's buy it. So we buy it. Let's put a honeypot on it on all ports. Let's see what's knocking. First knock comes from Japan. I ask the IP block belongs to Nissan Motor Corporation. Okay. At the time, Jesse and I were presenting in pack stack, so we were in Japan. We're like, okay, let's go to Nissan crossing and take a selfie. After that, we waited a little bit, not too long though, a couple of weeks maybe. And we get another one. And we look at it and it's like, okay, it says user agent Nissan car wings, something, something. Huh? That looks like compressed data. Let's just uncompress it. Okay. Once we uncompressed it, we see some interesting stuff. So me and Jesse look at each other and we go like, is that a car connecting to our server? And now Jesse. So if we take a closer look at the information that we actually got here, it includes some information like navigation ID, DCM ID, but then it also has like complete telephone number including area code, SIM ID, the VIN of the vehicle itself, and then user ID and passwords for the car wing site. It has a couple more authenticate, version numbers, but then it also has GPS coordinates of the car itself, including the direction that the car is pointing and the speed that it's traveling at. And it also has the particular cell network that it's roaming on, that life with a smiley there is the cell network that it's on. And we'll talk about that a little bit later. So that's cool. We can actually map, like take all the check-ins that we've gotten for a particular car and map everywhere that it's been. This one looked funny. So we took a little bit of a closer look at this one and it didn't make sense. Like some of the cars, you could clearly see the person lives here. It's checking in all the time at somebody's driveway. So we didn't want to show you that one anyway, but this one looked funny even beyond that. And the day we looked at this particular trace, you'll take a look down here at the bottom. It had checked in in the center of the Delaware River. And we were like, this doesn't make sense. We looked up news reports. Is there a car in the river? Was there a car accident? Are we getting incorrect GPS coordinates? Right next to this spot, there's actually like a little industrial area with kind of tall metal buildings. So maybe the signal was bad. It still seemed funny. So we also like, do we need to call somebody? Do we call up and say, there might be a car in the river? Go look. I can't really tell you how I found out. So this car did start checking in elsewhere a few hours later, but for a couple hours there we were like, holy crap, what do we do? To look a little bit closer at this one, we just took the VIN and googled it and found this. It's a shipment record. It looks like Russian, but it's actually Ukrainian. And this, if you throw it into Google Translate, it basically is a shipment record saying that it's being imported into the Ukraine. And it talks about motor vehicle for use on public roads. So we thought this is getting even weirder. So we looked up car facts for this vehicle. And it was sold in 2015. Like not even a month later, after only 700 miles total loss, like declared total loss written off, it was then purchased with a rebuilt title and exported to Poland in 2016. So for some reason we have a vehicle, the other thing, the cellular network that I pointed out before, the life with a smiley after it, that's a network provider that only operates in Belarus and the Ukraine. So we have a vehicle that was totaled in the US, was exported to Poland, is driving around, or at least the radio is driving around, sending us check-ins on a Ukrainian network provider. That's kind of weird. We don't know why it's sending coordinates from Philadelphia. Maybe the map in the device is set up for one area and it doesn't know how to process that and send us coordinates that are offset by some amount. So that's weird. We don't know why that's happening still. But why is this happening at all? And it turns out that all of these vehicles ship with a SIM card for a Jasper wireless is a connected car cloud. According to Wikipedia, 11 different automotive manufacturers use this service, which basically they have a SIM card for Jasper that it roams on all the different networks and sends the data back to Jasper where it is transmitted via a VPN to the automotive manufacturers back-end server. But if the owner or someone else has taken the SIM and replaced it with their own SIM, it bypasses all that hard-coded routing and just goes out to the real internet. So that's why it's ending up coming to our server. So this is interesting and cool, but it's not a common thing. We have seen posts on various web forums about people replacing the SIM for various reasons. So we know this is happening to a number of people. But maybe we can find something more interesting. Moving from the car, from the whole web angle to a different aspect, let's look at the telematics. What is the telematics? It is the module that connects the car to the internet. It's basically the cell modem in your car. In this case, it's a continental made TCU. We found the one, we got one with the car, but whatever is left of the car, and we wanted more because we're kind of hardware hackers. We want to tear it apart and look at it. So we go on eBay and we found 20 for 12 bucks. Okay, cool. So a bit more information about this telematics unit. It's using 2G networks. Only 2G. It sits on the can bus. This is the spec for it. It's connected to all kinds of devices on the can bus. We'll get to it later in a little bit deeper. But let's look under the hood. The top of the telematics unit is very simple. You can see the SIM card on the right and you can see at the bottom there is a USB footprint on the PCB. They gave us a good indication. If you can see from the bottom footprint, there's a thick line going to the right and up. Those are the traces for the USB to go to the top right connector. So we now know there's a USB connection going through there. We also found out in the spec that it's also documented there. Now let's flip this thing and look at the bottom. There's a lot more chips on the bottom. It's more interesting there. So there's a big one and a cluster of small ones. So break it down a little bit. The big chip is the free scale chip that is used to connect to the can bus. The cluster or the complex to the right is the 2G cellular complex. It's a bunch of chips. There's a baseband processor. There's a flash chip. Excuse me. And the bottom left you see there's a footprint. So I'm going to go back one and show you there's a little arrow there. That's my way of indicating pin 1. That's a footprint that we've kind of recognized from previous hacks with free scale processors that we've had laying around. So we've had the debugger. We just solder a header on it and plug it in. So we got some of the firmware off the free scale processor. We didn't manage to get the whole of it. But you know, let's put it aside for a second and keep looking. We know the radio is connected to the TCU over USB. So let's man in the middle that USB. We have a USB interposer. So a couple of custom cables later. And after realizing we have no cell signal in our lab, we had to put it on two office chairs and wheel it next to the window. Then we put everything up. You see the power supply on the right to change it because it didn't have enough watts. So we plug it in, we put it up, and we look at the communications and we see the USB enumeration. It says com neon. Anyone here? Does it ring a bell to anyone? No? Okay. So we keep looking at it. And we see the AT commands going on USB. You see on the left you see GPS coordinates going on. And on the right you see the setup where it establishes the comms with the TCU telling it this is the user in password and all that stuff. And I'm like this is very familiar. And then it hit us. Let's take a look at the chip. Does anyone recognize this chip? No? Let's try it again. Here's a hint. No? Okay. This chip was used in the original iPhone. The what's it called? The iPhone, not the iPhone 2. The original. No number. The iPhone. No number. So yeah, this is the Infinion PMB 8876. It was in the original iPhone, not even the 3G. So then it has basically 2G cellular modem. But this does not mean that your car runs iOS. This is the base band processor, not the application processor. So we wanted to take a closer look at it. So we basically wrote a little Python USB wrapper to talk to this. And you can send it AT commands like get the vendor model. There's the SIM IMZ at the bottom there. But because it's effectively an iPhone chip set, why don't we try and see if the old classic vulnerabilities are there? So I believe the ATX app vulnerability was founded in 2007 and publicly disclosed then. So we tried that. And it causes our TCU to crash and reboot. So then we reconnect to it. And one of the nice features about this base band is that you can actually read the exception log. And we can see that we've generated an exception. We have the start of the data here. And we scroll down a little bit further. Then here's part of our stack where we've got our 41 characters from the A's. That's the start of the stack. And then we scroll down a little bit more. And there's the registers. So we have the registers they're being filled in with 41s from the stack overflow. Including R15, which is the ARM program counter. So we now control code execution at this point. So we tried the other ones. SDKPROF, XLog, FNS. Those all worked also. So this is cool. But it still requires that you own the IVI in order to exploit this. So in this particular vehicle, there's two different CAN buses. The IVI is on one. And then there's the TCU on a different one. So potentially, you could potentially jump from one CAN bus to the other by exploiting this. So that makes it interesting. But it still, I think we can do better than that. So in the iPhone, it was actually found in the 3G, there was an over-the-air overflow found by Ralph Philipp Weinman and published in 2010. There was a Timsy field in the GSM protocol where it's the specification specifically says this must be 32 bits. But then in how it's actually encoded in the protocol, it's a TLV field, which means that it can be dynamically sized. So we can put 64 more, like, 72 bytes in this field that the spec says must be 32. And so we're like, this is cool. Let's try and do this. The iOS Hacker's Handbook actually has a chapter describing this vulnerability. And on page 356, it actually has proof of concept code that you can use with OpenBTS. Basically, you are emulating a malicious base station and letting the car connect to you and then sending a Timsy reallocation command and overflowing with a long, overlong Timsy. And OpenBTS, by now, they've basically removed the test call functionality, which this proof of concept in the book depends on. Basically, they didn't want to make it easy for people to use this to hack the cell stations that they were trying to deploy. And there was a little bit of controversy because people didn't, they thought that was security through obscurity and kind of silly. So people forked it and we were able to find other versions that had this test call re-implemented. But we also needed a Faraday cage because it's a licensed spectrum. And we can't, we can't broadcast in the spectrum without a Faraday cage. So we got a Faraday cage. We put the TCU and antenna and Raspberry Pi in there so that we could try this out. Here's another shot of us, actually, with it going. We've got a Blade RF software-defined radio feeding the antenna into the Faraday cage, trying it out. We originally had, we were trying with a USRP software-defined radio. We had some hardware issues and just general flaky behavior. And after we had a discussion with Jared Boone and talked to him about the problems we were having. And he helped us realize what was wrong. And it turned out that the specific USRP model that we were using didn't have strong enough frequency, or didn't have good enough frequency stability to keep a cell phone connection with this older Infineon chipset. So that mismatch caused us a lot of problems and banging heads because it would start to connect and then it wouldn't keep the connection because it would drift off. So after a while, we were able to fully confirm the over-the-air exploit. This is actually a screenshot of a text message that I sent Mickey while he was driving to a conference to go present somewhere else. So we finally got this working. We wanted to thank Jared for his help here. But in this case, also, we control registers with arbitrary access. We control R15 program counter again. So we have remote code execution potentially because we control the program flow. So where can we go from here? We don't have a copy of the firmware because we didn't have a good way to extract the firmware. We can just talk to it. One interesting thing is that the original Apple hackers, they were able to download the firmware off of Apple's website and extract the baseband firmware and start reversing it from there. But we need to actually exploit one of the existing vulnerabilities in order to extract the firmware itself. And we do have that exception log that has register state when the system crashes. And we also have some of the stack. We have a small amount of stack value. We do have to reset every time in order to get that exception log. But we can work with that. So at this point, we pulled Alex in to help us out. Thank you, Jason. So as Jason mentioned, we don't have the firmware. But we have a bunch of information in our crash exception log. Like system stack and registers. So that's enough for us at least to play a bit, to understand at least what kind of protection this chip has. Because if it has all protections like ISLR, DAB, and all of the software protections, then it will be really hard to exploit the blind lever vulnerability. So let's start the investigation with how many protections and what kind of protections is there. So we run a couple of times and see the addresses and the addresses was not changed. So kind of there is no SLR, which is really good, but not enough to make the final exploit. So then we start playing a little bit because we control in the R15, the program counter, we may to jump somewhere and see if this code is cute or not. And also we can spray a little bit, like run nobslats or run some instructions like jump R4. We can spray them through the same buffer up to 212 bytes. So we spray the one of the instruction which is jump to R4 and then we try to brute force and jump to that instruction. So then finally when we got the execution, we figure out there's no depth at all and also the stack is executable. So basically there is no protection chip at all. And then later on we check the configuration of the MMU which will tell us the memory protection and the value is C00 in that specific register, meaning that it allows to read, write, execute any segments in the memory. So that's really good in the perspective of the exploitation. From here, that's another indication of. From here we understand that we need to somehow run our shell code more stable. So we spray the nobs and we put our shell code somewhere in the stack and then we jump to that shell code later. So pretty old school techniques. But now after we have the code execution, we need to run some post exploitation shell code which will allow us to make the next step. But what is the next step? It's not the full OS, you cannot run the reverse shell. But we really want to investigate what kind of messages we can send, what kind of protocols it supports, does it support UART and so on. So to make this happen, we need to extract the firmware. But we don't have the print, we cannot print the firmware. But we have that log information which Jason and Miki already previously showed. So we were thinking about, okay, let's use this log buffer and copy the firmware to this buffer and then extract this buffer and combine it together to get the final firmware image. So for one iteration, we extract 212 bytes. And we have sanity checks before and after to make sure that our shell code is running successfully and we dump the 212 bytes to the stack which we will print in the next iteration when we run the log command. So, and in this case and the Rust instruction, we will jump to invalid address to make sure that the exact, exactly our controller dump will be in the log after reboot. So again, we run a log after reboot and we got 212 bytes. So that's the example of that log. We have the sanity checks that beef. We have R15 which is invalid address to making sure that we stop in specific moment. And then before that beef, we have the dump of our 512 bytes. So, and then we do it 13,000 times to extract all of the parts of the firmware, then we combine it together. And then now, we have the capabilities to reverse engineer it to find what protocols it supports and to build entire picture of post-exploitation. From here, Jesse will continue. So, one other point with this is that we now have extracted the firmware. It does, most of the address spaces are at fixed locations, but there are some dynamic memory allocations that are happening. So, we can read the firmware and have a reliable read for the firmware, but the SRAM is moving around a little bit. And sometimes the pointers and structures don't entirely make sense because we have to crash and reboot in order to read every single block. So, and I think this took what, four or seven days? Seven days to read this and get the entire block once because it reboots, it has to wait a few seconds before it can connect again. So, but once we're able to do this, what can we do from there? And the impact of this is very vehicle specific. So, different, like this particular device can be connected different places, different architectures in different cars. So, in the vehicle that we found it in, it's connected to the EVCAN this way, which is connected to the power delivery module, the traction motor inverter, the AC amplifier and controls, and then the lithium-ion battery pack. So, in other vehicles, it'll be different and there'll be different things happening there. So, this vehicle or this TCU does have the ability to send CAN messages on the bus. It also, it was originally designed to work with the vehicle immobilizer so it could receive a message and block the starter. We don't know if that actually works or we don't know if it's hooked up because we don't have a full car and we only, we did ask a few people if we could borrow their cars and they're like, hell no, you can't even drive by my house. So, we don't really know what the full ramifications of this are at this point but it's, and it will very specific vehicles are different. So, for conclusions, as of Thursday, this ICS cert advisory went out. Basically CVS version 3, 8.8, remotely exploitable, low-skill level to exploit, public exploits are available. It's for the Continental AG Infini-NES goal that contains the Infini-NES goal, stack-based overflow. We do have some affected products. We now know that BMW and Ford have a few models. We don't know how many but basically any telematics control modules built by Continental that contain this chipset are affected. So, the way I'd like to talk a little bit about just how these chips were distributed around and originally the chip and the baseband firmware, the reference baseband firmware came from Infini-N. It then went to Apple. Those showed up in the iPhone and external researchers found vulnerabilities in the baseband firmware. One thing I thought was really interesting was the Timsy overflow, the original advisory for that only mentioned iPhone 3G and later, but we found this in the same chip that was in the original iPhone. So, I was wondering if the original iPhone actually was vulnerable and they just didn't care because iPhone, like the phone market moved so much more quickly. And that kind of brings me to my next point is that these are different market segments. Like, there's been large focus on mobile phones, everything going in there for over 12 years. This particular vulnerability was found 10 years ago and made public 10 years ago, but these chips also went to the automotive market segment where there's only the last few years been this heavy focus. So, we're just now finding out that these things went other places and it's possible that they went to other market segments also that we don't know either. So, I think it's really critical to understand that and I'd like to point out that this is not an O-day. This is a, as of today, it is a 2,441 day, but also the different market segments, so the different market segments, they have different levels of security maturity and they can have very different product life cycles. Like, mobile phones, they expect you to upgrade your mobile phone and get a new one every two years. And vehicles, they don't even get the car out the door, like, within two years of the time they start, they start producing this. So, there's a very long development life cycle, there's a very long in use life cycle. And the problem with this is that they can share components and you can have something with this very long life cycle that's already been exploited 10 years ago in a different market segment and people just don't realize that. So, you really need to be aware of security issues that could exist in your product that happen somewhere else. So, if you're designing and developing something that is important for your car or your device or any other, maybe it's a medical device or something, I don't know. Maybe there's a, anything that you're working on, you should look and see if the components in your device have already been owned or if there are any issues with any of those components elsewhere. So, this is a pretty interesting example because it's survived 10 years after publication. So, for, we'd like to thank a few people. We would like to thank Nissan North America. They took this issue and were, they helped us and they, they did help us provide information to the supplier. They helped get information to other, other manufacturers. So, they were definitely responsive to this. We'd also like to contact ICS cert, specifically Jason Berkeley. There was a period of time there where we were calling him every day to figure out what's going on. He also helped us get information to the affected parties and coordinated everything, got the advisory out. We had a few rounds of drafts to make sure that it was as correct as we could get it. We also wanted to thank AutoISAC. They're an industry coordination body that has also helped to try to get some of this information to other members and other OEMs. We also wanted to thank Intel P-Cert because it's kind of funny because Infineon was purchased by Intel. So, when ICS cert was trying to get a hold of Infineon, we were like, we can go talk to them and get, we know these people. So, we could get a call for, you could get a call back from them in an hour. So, we definitely wanted to thank P-Cert about that. So, we do have the advisory up here again. So, definitely go take a look at that. Yeah. Yeah. It does have more information. So, go take a look at that. Before, the next slide is the final slide. But before we do that, because of, we have to move the slides before we come to present to like PDF and USB and print any animated GIFs and all that. We need to do all this kind of stuff. We lost the slide. And it's a really important slide. It basically says we couldn't have done this without previous work. And the previous work we mentioned is Charlie Miller and Chris Velasek and Mark Rogers and the Keen team and Scott Helm and their previous work on the Nissan API. So, it's really important to mention if you do use some of other people's work to give them credit. And I just wanted to do that before we say thank you.