 Thanks for coming to my talk. It's titled Hydra Keys, Hydra Car, Remoly Exploiting Connected Vehicle APIs and Apps. Anybody know LeVar Ball? Anybody? I was going to walk out like that, but if you don't know, I'm done anyway. I figured it wasn't going to be a complete presentation without LeVar Ball. So my name is Aaron Guzman, my Twitter handle, scripting XSS. It'll probably say A-A-Rons, or any of you guys have seen any of the skits. You'll know where it's from. First things first, I love pizza. I had pizza for breakfast. I had pizza probably twice already. Serious fanatic about pizza. Second, I live in Los Angeles. I work for Gotham Digital Science, an A-On company. I like to hack all the things, anything IOT, anything connected vehicles, anything embedded. I'm all for it. I'm head first into it. I also was a technical editor for a book called Practical Internet of Things Security. I'm actually co-authoring a book right now called Pen Testing. It's a pen testing cookbook for IOT, and that's to be released in the next couple of months, hopefully in the last couple of chapters right now. Aside from that, I'm a board member for OWASP and Cloud Security Alliance Southern California. I also contribute a lot to OWASP and Cloud Security Alliance, so for OWASP I am a project leader. I help lead a project called Embedded Application Security Project. So mostly embedded Linux, but also some RTOS as well. And I contribute to a lot for Cloud Security Alliance IOT working group. Even their connected vehicle guidance documents and IOT for secure deployment. And here is my vehicle that we're going to be talking about. So today's topic is Subaru Starlink Remote Services in vehicle technology. Just to kind of set what that is, what Subaru Starlink is capable of doing is you can unlock the car, honk the horn, locate the vehicle, locate the owner, have a vehicle health report so you can check whether your oil is at the right stage, if anything is going on with your ABS, get monthly reports, weekly reports. So it's pretty, it could be pretty detailed. This is all with their telematics. You could also, you know, schedule your services and track your history as well, your mileage, get notifications. But what it doesn't do, it doesn't remote start your vehicle. But it's not to say that that cannot be added here. It's only a $300 add-on. But that was kind of out of scope for my research. I wanted to get what was installed, what was used within Starlink, Starlink in vehicle technology. So I started with okay, I actually had purchased a vehicle 2016, thinking it had telematics installed. But I come to find out only some 2016 versions of Subaru or models do have Starlink. But so far they have official versions of 2017 and 18 vehicles. I think all 2017 and 18 vehicles now have Subaru Starlink by default. So you would have to purchase a subscription but it's always connected. So, you know, so some of the motivations and research that I started with, this is why I kind of got a Subaru is I figured there was no research in this space as far as security research for connected vehicles on the Subaru aspect. Aside from tuning a car, it's a rally car. So it's an STI. So usually there's some modifications made to the engine to compensate for the ECU and air intake, for example. So anything changing within the vehicles, I'd say engine, you'd have to tune it. So, and there's already verified manufacturers who are out there that do that. But as far as security is concerned, I didn't find anything that was out there. So it's an area of interest. Like I said, only 2016 and up have a Talimatix. So when I purchased mine, I literally, you know, thought that I was going to have to, well, I actually did purchase it in the 18 one, just literally just to hack the vehicle. And we'll go through some of the steps that I went through. But also I noticed that, you know, the DMC exemption for security research last October occurred as long as it's locked the device or whatever item you're researching is lawfully acquired, good faith research. So you're not trying to harm anybody. It's in a controlled environment. And also if it happened after October 28, 2016. So obviously, that's that's already way past that. So that was good. That's good for me. I'm not going to get in trouble. It's my car. I want to have some fun with it. And I always wanted STI. I always thought they're pretty cool, pretty fast, pretty fun cars. And like I said, I had a 2016 version. And so my 2016 version, I spoke here last year at IOT Village and I shared some of the findings. So the first thing I did was that, you know, I found multiple bugs there. We'll go through what those what those actually look like. So let's jump right into the demo so I can show you exactly what I found and go through the methodology of it. So it's smaller than I would like, but let's go ahead and I'll walk you through. There's no audio right now. So I figured, hey, I'm from LA. Might as well take a video in Santa Monica. And literally, this is a week after getting my car. We'll go through the timeline in just a bit, but I don't even have plates on the thing. I'm basically right now talking about what I'm going to show. And that's unlocking the car, honking the horn, flashing the lights. I'm going to add two users to my Subaru account that have access to my vehicle and also show that the keys are going to be on the roof. So I'm locking the vehicle, making sure it honks. You can see the lights here. I'm going to go ahead and put those keys right on top of the roof. And from here, I'm setting up just going to show that there are no authorized users in my Subaru account. So there's no users here. They would show up here, email addresses. So what I'm going to do is go ahead and run my exploit script in just a second here. Then you'll see the magic happen. So of course, it's a Python script, like everything else, right? So I'm running my Subaru exploit script here. And what it's doing is bypassing authorization, gaining a session, CSRFing remote service request, meaning unlocking the car, honking the horn, flashing the lights. You can also locate the vehicle as well, like I said, in the owner. But for this particular video, it's only unlocking the vehicle, honking the horn, flashing the lights, and adding two users. So it's going to take just a second. You'll see the lights flash. The car is now unlocked. And we have no audio, but it would honk right now. And I'm going to go ahead and show the car being unlocked. By the way, I'll take a second. One of the organizers for Appset California, it's the last weekend of January, right on the beach in Santa Monica. So it's an OWAS conference. So here we go. It unlocked. Let's go ahead and open the door. There it is. Same backpack that I have right here. And now I'm going to see still see the keys up here. And now we're going to see that two users have been added to the account to the my Subaru account associated with my car, my vehicle. So now I have two users here that are joined. It says car hacking email and car hacking email at Gmail 2 or at one Gmail. So you'll see it right now. I'll have a separate video screen share to show you what's happening on the screen. And these two users have full access to the vehicle as in they could unlock the car, honk the horn, flash the lights, view everything, like I said, locate the owner as well in the vehicle where it's at. So they have kind of full control. There's no delegated access to my Subaru account. So in essence, it's almost their car. So here's a screen share of the adding authorized users and showing you that there isn't any users here. This is my vehicle 2017 WX STI. So no authorized users. Go ahead and just refresh just to show you guys that I'm not faking anything, you know. And go ahead and run my Python script. Again, bypasses authorization here. It takes a second. It's literally going through the internet. It's going through AWS is what the provider has. So it takes about five to 10 seconds for the calls to execute. So I added two users here. And then unlock in the car. You can see I have an active session here. And I'm honking the horn and flashing the lights. And then it gives me a 200 okay afterwards. Just a second. So it will honk for 30 seconds. So now that we know we have two users added here, let's go ahead and log in as those two users that have delegated access or not delegated but full control. So I'm Aaron here. And I'm a login to you see there's two different emails. And here's a different browser logged into my car hacking email account. They don't have to have a Subaru at all, by the way. So here's the remote services that they have access to. And again, lock unlock, honk the horn, locate the vehicle. So that's that's those are the demos. Those are the research, the research aspect of it. I'm going to show you kind of the methodology and the step by step process that I took to locate those and discover, you know, the exploits and how the vulnerabilities arose. And again, I've dealt with Subaru at a small capacity last year. So introducing the Subaru WRX STI World Remote Executable. It's all going through the internet. It's all going through cloud. It's always connected. It worked 100% of the time. When I first found it, it was literally the week of RSA. And I was on the airplane. And I was looking at my camera. Of course, I have a camera in my garage. And I was still writing the script and it still worked 120% of the time. And that's because there is a token that never ever expires. And again, there are most service calls. It could be CSRF. So that's how it always worked. And also to execute it for an attack, you'd have you can utilize the cross-site scripting that I'll show in just a minute. So after, you know, the exploits happen. About the beginning of June, there's some articles written about the research. And again, there are simple findings. And we'll just go through them in just a second. So let's go through the timeline. So again, I purchased a vehicle late January. Got the car delivered a couple of days later. Actually, I actually pinged Sammy Kamkar. And I was like, dude, I got a new car. Let's hack it. And about an hour later, verbatim, I was like, he was like, okay, cool. He's all send me some dumps and we'll work or something. He's like, all right, I'm just doing some burp sweet things. I'm proxying the calls. So then an hour later, I was like, actually, dude, it looks pretty simple to do from the mobile web app. Found off bypass, access and fixation, XSS and a way to add a user to my account who can also unlock my car. Going to script it up. He was like, dude, nice. So then I created a video three days later out of park. But I was like, ah, you know, I went to RSA, came back, I felt like I could do better. So I recorded a video right there in Santa Monica about a couple, you know, week and a half later. So that's when, once I created the videos, I disclosed the vulnerabilities to Subaru. They're easy to work with. Once I found the right people to talk to, Subaru acknowledged right away. And about a month from disclosing the bugs, they fixed the critical findings that were located or discovered, which is pretty fast for any company really, especially a car manufacturer who doesn't have a security team. So, but again, they were easy to work with. They were very open and even to suggestions as well. They definitely came back. We had some dialogue. So they weren't closed off to the community at all. About a couple weeks, a few weeks later, they released a new My Subaru app for Android and iOS. So basically almost all redone, but they still had the original web application that I was showing. So during that time, I gave a talk over at Oxford and Australia on an embedded subject. And that's when I got in touch with a journalist who basically went back and forth with Subaru to verify. And around the same time, literally the same day that the article published, they also pushed a new web application similar to mobile applications. So I don't know if there was some correlation there. But again, they were easy to work with. They were very abrasive to the community. They usually like to point them in the right direction as well. So again, pretty, you know, not too bad of a timeline, especially when they were fixed. The critical bugs that is, you know, they also gave me some credit on their Android and iOS app. So where I first started looking at this when trying to tackle this problem, not this problem, but trying to research a connected vehicle. You know, I've read the news. I've read the car hacking handbook. I know a web app and mobile hardware hacking. So I knew they had Bluetooth. I started with a threat model. I knew it had Bluetooth. I knew it had 4G. They ran over AT&T. I knew it had RF for the key fobs. I knew there was an SD card. I knew there was, I could do something with OBD2, go on the campus research, which is kind of what everybody's doing. I kind of wanted to do something different. I knew I could mess with the ECU or use third party like Cobb, who basically flashes the ECU for tuning, which is the area of research that I'm going to get into if anybody wants to help out. Also infotainment systems. So these are all areas that are kind of familiar already within the car hacking community, community or whatever you want to call it. But there's also the easy stuff. And for me it's the easy stuff. It is the apps. Android app, iOS app, and the web app. And for me, you know, this is the best part about anything connected is, it's basically, you know, the attack surface is huge. So we love IoT, right? It's easy because why? Hard work sucks. I just picked the easiest, weakest link, you know, within the whole attack surface here. And for me, what's the quickest and fastest without spending so much time and effort? I figure I'm going to look at the apps first. Granted, if it's an ECU type of vulnerability infotainment, sometimes, you know, it'll have to go through a whole recall depending on the severity. But I'm fine with that. I'm fine with going through the mobile apps. So again, hard work sucks. I'm going the easiest, weakest link for me, which is the AppSec area. So where does everybody start in any type of AppSec if you're familiar with mobile? Android. Easiest. So I just assemble the APK, analyze the classes and methods, see what has any vulnerabilities, monitor the activities, the services, the intents. I also check my last year's findings from, that I reported to Subaru. They had some OAuth issues with hard coding the client secret and client ID. So if anybody is familiar with OAuth, that's another entry point into getting access. So that was fixed, which was cool. I reviewed the third-party libraries. I found out it was a hybrid app, so they were using Cordova, OK HTTP. So I knew there weren't, you know, pinning SSL pinning so I could proxy. This is before I even touched, you know, installed the app yet. So afterwards, well, next is actually installing the app and running it. Once I found some issues within this area, disassembling, monitoring the classes and methods. So I proxied all the important API calls. Again, logging in, logging out, unlocking, locking the vehicle, how can the whole reflection of lights, locating the vehicle and the owner on adding users. So I'm just doing a recon. I'm not doing any, you know, injection attack. I'm literally going to burp and categorizing the API calls. Then I move on to iOS. Just the same, similar thing, I just assembled the IPA, dump and analyze the classes and methods, analyze the runtime behavior. I checked my last year's iOS findings, and they had an auto log in handoff token, which had been resolved last year when I talked at IoT Village. Somehow it got re-merged and it is not resolved. So that's a key, that's a key item here for me, because any token that's inherently trusted from what it was, it was inherently trusted from the mobile app to all, basically the APIs to everything, basically. So I noted that down, it wasn't fixed. I also reported that caching of all requests and responses were occurring. It was kind of resolved, they took off the sensitive items when caching, but they still cached a lot. It's like, okay, you know, from there I continue to analyze storage, PLIS, SQLite databases, local storage, realm databases as well. Then from there I proxied the API calls again, similar to the Android app. Again, log in, log out, unlock, hunk the horn, flashlights, locate the vehicle and owner, as well as adding users. And there are some different API calls that were made between each app. So that made me think that, you know, there might be some problems for them to keep state. So I just noted that down, added a comment and burp. Now let me demo what I found last year here for you guys. Just so you guys have some context. It's about a minute long. So this is the caching of all requests and responses here. You can't see, but there's a handoff token that I'm pointing to. It's very hard to see, but in essence it's cached. Again, all requests and responses. So it was sent over the URL, you know, that's a no-no. So then it's in the cached database for iOS. So what I do is go ahead and, you know, see what tables I have, click in the middle of any SQLI database, because that's what I always do, just click in the middle. It's in hex right here, but I'll go ahead and change the text. And again, the handoff token is right here again. This video was sent to Subaru, by the way, as well. So last year, when it was fixed. So just copy and pasted it, auto logged in to the account. This is my old vehicle, by the way. That wasn't connected. So look, it says I'm logged out. Just copy and paste it again. Back logged in. You know, back to being logged in without username, password or anything. Just totally copy and paste. So again, that had been fixed and then was re-merged somehow. Somehow. So I used that obviously. I want to gain a valid session into a vehicle account. And so the next step was to do some recon on the web application. Similar steps is proxying basically every call I can find within the web application. So it had more capabilities. You could also change what's called a pin, a four-digit pin. Security questions as well. Personal data and seeing how injection attacks work within the personal data. We'll get to that. This is all just a recon stage. And again, noted everything down and the differences between API calls and BERT. So from there, I noticed some potential road blocks between each application and how it communicated with the server. I noticed there was unique session IDs almost as a CSRF token for the mobile apps. I couldn't find where they were originating from. It didn't look like it was coming from the mobile apps. And it wasn't coming from the server. I was proxying the request. So I just moved on. I was in fear of session expiration, randomization. I wanted to basically have persistent access all the time and make sure my request always worked and executed. So even if I did a CSRF in anybody's car, it would still work. And then so if the user configures email alerts, they would get an email for each remote service call. So unlocking the vehicle, for example. And I said for most, because if you locate the vehicle, you don't get a notification. So that's kind of a safety thing there. So those are some of the roadblocks, this one being the most important here. So some other observations. Again, authorized users who the car owner delegates have full control over the remote services. The owner does not get notified of adding users. The authorized users, though I found a cross site scripting in the vehicle name. So that was key actually. So token and cross site scripting is a way to attack, make this weaponized. That's what I did. There was no anti- CSRF tokens for any state changing configurations. So anything for the pins, for the security questions, there was no CSRF tokens. And that's for mobile web, all mobile apps and all web as well. Only web app. And I noticed obviously the token never expires. It didn't even expire after logging out and we showed that. And even changing the password. So they had some ACL issues there, some authorization, authentication issues. And then once you logged into your MySubaru account with a new device. So I have like five, six devices. You would get a new handoff token. So a new handoff token for a token that never expires. It kind of expands that attack surface. And I'll show you just a bit how that looks like. So not very hard to grab. Again, and even if they change the password, you'll still have access with this handoff token. So essentially that's the off bypass. All you need is the handoff token, which does not require username or password. And then again, you're already right everywhere. Everything over get request. Again, which is a no-no for any APIs. So here's the vehicle name cross-site scripting. Unweaponized, but just to show you guys the, you know, the ability to. And here's an example of this is my car hacking email account. This is I logged in with three different devices here. I have three separate tokens that are valid for the account. Again, that don't expire. And here's car hacking email one logged in with three different devices. Also has three different tokens. So and remember, I added these two users to my account. So these users can also, these tokens are also valid for my account. So it's like kind of, you know, daisy-chained almost. So that's not cool. So some other observations that I found. Again, we talked about get request everywhere. But those get request did not have, well, they can't CSRF, but they didn't have any session IDs that I was worried about for the mobile apps. And that's how I was able to CSRF all the web service calls, the remote service calls. I could just literally template them out and enter the values and they would execute. Again, solves the unique session ID problems we had with the mobile apps. And then the web application did not require security questions to execute remote service calls. But the mobile apps did. So and once you have, well, actually the car pins, a four-digit pin, it didn't always have to be sent. It's trusted after for a number of minutes, but it could be changed without validating the previous pin. So you can see here, it just says create pin and confirm pin. And then here are the security questions. So either way, I mean, you can change those if they are required if at some point you can always change those because they don't ask you for the pin already, the previous pin, and they don't ask you for the previous security questions. They ask you just to update them and put new ones in there. The car is also vulnerable to replay attacks. So the API, there was no rate limiting. You can execute as many as you want. Except not while driving. I know people probably thinking that, but not while driving the remote service calls work. But you had to wait five seconds again because of the internet of going through from my connection to AWS and back to my car via 4G. So at this point I felt like I had a lot to go off of. I have a token that never expires. I have cross-site scripting. I could CSRF my way. I was flying. So at this point, okay, so I have to chain some of these vulnerabilities together. What I did was create a malicious page with a cross-site scripting payload to gain the valid session to acquire the token. And then from there, I added the users via CSRF. And then I made the remote service calls via CSRF. So I automated this. But you could also do it manually and change the pan and change the security questions like I mentioned earlier. And also just track the owner. They're not going to get notified when you log in. And there's no concurrent login either. So you can log in with 20 different users and the owner would never know. Or add as many users as well. This was just earlier today. This is my car and this is me. This is how you could track a user. Cars over here in California. But anyway, it's lovely because it gives you this sort of location thing here where it opens up maps and it gives you directions right to the vehicle. So you can always basically know where they're at. And there's also API calls for this as well. So you can just use JSON, for example, JSON output and just overtime track. So here are some attack scenarios that people are probably wondering. And again, I always use the cross-site scripting as the easiest one to get executed. You can look at the victim's logs. You can back up the mobile devices to view. Or to get access to the handoff token, for example. You can use, you know, any type of man in the middle to victim the traffic, to man in the middle of the victim traffic. Again, you can use, you can export this cache dv file via iFunbox for iOS. So since these are all over get request, if you're logged into your My Super Recount over a network that logs or does man in the middle of your connections and enterprise, that's going to be leaked. Any type of third parties, whatever it may be, social engineering, you can have the victim login to their My Super Recount on your device and be like, yeah, just show me. Unlock your car from here. And you could also again audit logs within not only the mobile apps, but also within the browser or install via malicious applications. There's a number of different techniques and ways you can, you can exploit these vulnerabilities here. Here's the auto login. Literally, I just pressed login and it auto logged me in. So if I have, you know, a victim login with my phone, all I have to do is just press login and I'll have the cache database and it'll be fine. I'll always have access. So some other post exploitation scenarios, once I do have access and I did successfully attack a Subaru user or vehicle, I think the obvious is still in the car contents. What's in there? Sabotage the vehicle's engine, pop up in the engine and it could be expensive. I know for my car, you know, it could run up pretty fast or retain persistence to a car's account without making any type of changes or adding just adding users, implanted out of band tracker, a Wi-Fi pineapple with GSM under the seat maybe in the trunk, a number of different ways you can do that and you could also attack, you know, their local network, you know, reconnaissance or recon their own corporate environment as well. But again, I think the biggest one here is personal safety risk for, you know, unlocking someone's car, leaving them vulnerable to stealing of their contents whatever's in the car but also themselves for locating for privacy purposes. And there's a bunch more as far as post-exploitation scenarios that you can do once you have access and once you successfully exploited this vulnerability are these. But the likelihood and impact is that, okay, only mid-2016 and up Subaru's have telematics. The owners have to purchase the Subaru Starlink services. And it's kind of a targeted attack, right? You can't spray and pray this. You kind of, you have to know who has a Subaru. It has a Subaru with telematics. But that's similar to all IOT and car hacking for the most part. It's also warmable via, you know, the authorized users that were added to the account. So the impact is kind of low for now. Again, it's the first year that they release this. So, you know, and all their vehicles from now, you know, moving forward are going to be connected. So the likelihood right now is kind of low. But I see the impact as being high. And again, moving towards the future, I think it's going to, you know, continue to rise and have more features to be exploited for people like us. And people like you guys as well, you know, this is why I do the research and trying to share, you know, my methodology because you guys can do it too. You can see how kind of simple it is. As far as the tools are concerned of what I use, feel free to ping me. I'll definitely share those. So as far as, you know, after the fact, like I said, Subaru was great to work with, I have always tried to point vendors in the right direction when reporting bugs. So I usually point them to disclosure policy ISO 29147, appoint them to NITSA, best practices for modern vehicles, the DOT's federal automated vehicle policy, auto ISAC best practices, and the observations and recommendations on connected vehicles, connected vehicle security from cloud security alliance. Most importantly, I also point them to the five star automotive cyber safety program from Ion the Calvary. Definitely a great place, good community. You know, if someone in the connected vehicle space wants to get involved, I think we already have most of the manufacturers working on Subaru right now, who are trying to get involved here or any of these areas. But moving in the right direction as far as connected vehicle space is concerned. But some of the other lessons are, you know, learn from others mistakes, continuous testing, internal, external, some crowdsource, pen testing, like, you know, people are doing already with bug crowds, for example, or Hacker One, similar organizations. So, Subaru took some steps after every part of those bugs. They deployed their new applications. They started output encoding. They have a last logon message, which is nice. They don't send raw credentials over clear text or over HTTP. And here's an example of what they send when you're logging into your account. Literally just stars, asterisks. And now you get, now you have an account lockout for incorrect pins. You can also deauthorize devices here. Here's a lockout button, your last logon. And here's output encoding. I still like that, by the way, today. So they're taking steps and that's good. You know, can't expect them to be perfect, especially without a security team. But it's great to see them, you know, embrace the culture in the community and trying to work towards a more, you know, a secure posture for connected vehicles. And they're looking to get into space, like I said. So that's all I have before I, you know, get off the stage. Are there any questions? One question? Yes. Yeah, the question was, how easy would this be to repeat for another vehicle? Very, very simple. I think it's happened before with Nissan Leaf. Similar, a similar type of research, but, you know, for mobile apps, they're much simpler, but code gets pushed much more often. So, and there's web applications. So the attack surface is large. So it's very, it's very, very likely impossible that at a time, some manufacturers going to, you know, slip up, but also fix those issues as well. So it's definitely likely. Any other last questions? Yes. Sure, sure. So the question was, what would be the effect with like autonomous vehicles in the future for research like this? Well, I think the likelihood would be higher because it'll be more common and the impact's going to be critical. It's going to be really, really high. And again, it's just a matter of the vendor turning around the patches quick enough, because, you know, the risk is always going to be there, but it's about catching those vulnerabilities within an acceptable time. So definitely likely. All right, guys. Well, thank you so much. Thanks.