Controlling vehicle features of Nissan LEAFs across the globe via vulnerable APIs

Last month I was over in Norway doing training for ProgramUtvikling, the good folks who run the NDC conferences I've become so fastened to. I was running my usual “Hack Yourself Very first” workshop which is targeted at software developers who’d like to get up to speed on the things they should be doing to protect their apps against today’s online threats. Across the two days of training, I cover sixteen separate discrete modules ranging from SQL injection to password cracking to enumeration risks, basically all the highest priority security bits modern developers need to be thinking about. I also cover how to inspect, intercept and control API requests inbetween rich client apps such as those you find on a modern clever phone and the services running on the back end server. And that’s where things got interesting.

One of the guys was a bit inspired by what we’d done and just happened to own one of these – the world’s best-selling electrical car, a Nissan LEAF:

What the workshop attendee ultimately discovered was that not only could he connect to his LEAF over the internet and control features independently of how Nissan had designed the app, he could control other people’s LEAFs. I subsequently discovered that friend and fellow security researcher Scott Helme also has a LEAF so we recorded the following movie to demonstrate the problem. I’m putting this up front here to clearly put into context what this risk enables someone to do then I’ll delve into the details over the remainder of the post:

We elected for me to sit outside in a sunny environment whilst Scott was shivering in the cold to demonstrate just how remote you can be and still control feature of someone else’s car, literally from the other end of the earth. Following is a accomplish walkthrough of the discovery process, how vehicles in other countries can also be managed and a total disclosure timeline of my discussions with Nissan.

Connected LEAFs

The LEAF is an electrical car which is particularly popular in countries like Norway which suggest massive financial incentives to stay away from combustion engines. It does all the things you’d expect of a modern EV and because it’s here in the era of the internet of things, it also has a companion app:

Back at my workshop in Oslo and being the nosey type, Jan (not his real name – he requested to remain anonymous) goes back to his hotel after the very first day of the course and proxies his iPhone through Fiddler running on his PC as we’d done during the day (this was on January 20). This takes a few minutes to setup and effectively what it means is that he can now observe how the mobile app talks to the online services. Jan then fires up the NissanConnect EV app:

I’m using publicly available screen grabs of the app in part so as not to disclose private information about Jan and part because his app runs in Norwegian. When the app opens, he observes a request like this (I’ll obfuscate host names and the last five digits of VINs via this post):

Which comes back the following JSON response:

This is pretty self-explanatory if you read through the response; we’re witnessing the battery status of his LEAF. But what got Jan’s attention is not that he could get the vehicle’s present status, but rather that the request his phone had issued didn’t emerge to contain any identity data about his authenticated session. In other words, he was accessing the API anonymously. It’s a GET request so there was nothing passed in the figure nor was there anything like a bearer token in the request header. In fact, the only thing identifying his vehicle was the VIN which I’ve partially obfuscated in the URL above.

The VIN is the Vehicle Identification Number which uniquely identifies the chassis of his LEAF. It is by no means a “secret” suitable for authorisation purposes, the significance of which I’ll come back to shortly.

On the surface of it, it looked like anyone could get the battery status of Jan’s vehicle if they knew his VIN. Not ideal, but not exactly serious either as it’s a passive query (it doesn’t actually switch anything on the vehicle) and there’s also nothing of a individual or sensitive nature returned in the response beyond potentially telling you when it was last driven based on the OperationDateAndTime field. So Jan kept looking.

He found he could check the status of the climate control using this request:

Which then returned a similar status result:

This is reflected within the app on this screen:

But again, it’s passive data – is the climate control on or off and as a result, what should the buttons say. But then he attempted turning it on and observed this request:

That request returned this response:

This time, individual information about Jan was returned, namely his user ID which was a variation of his actual name. The VIN passed in the request also came back in the response and a result key was returned.

He then turned the climate control off and observed as the app issued this request:

All of these requests were made without an auth token of any kind; they were issued anonymously. Jan checked them by loading them up in Chrome as well and sure enough, the response was returned just fine. By now, it was pretty clear the API had absolutely zero access controls but the potential for invoking it under the identity of other vehicles wasn’t yet clear.

Connecting to other vehicles

When Jan came into the workshop the following day, he also brought in a picture he’d managed to locate by searching the web:

This was the vehicle's VIN which clearly, left us nosey (obfuscation is mine, it’s legible in its entirety on the web).

Let me clarify something before going any further and it’s something I harp on about in my workshops too; when a potential security flaw is identified, you’ve got to think very cautiously about how you proceed with verification. You need to have a sufficient degree of confidence that it’s a legitimate flaw before reporting it ethically (which is what we ultimately did), but you also need to ensure you don’t breach someone else’s privacy or influence them adversely in any way. We wouldn’t, for example, want to begin operating mechanical features of someone else’s car such as turning on the climate control nor would we want to retrieve private information about them, even if it was just their username.

The VIN above differed merely by the last five digits. We grabbed the number and plugged it into the request to get the battery status – a request that didn’t switch anything nor disclose anything private – and got this response:

This appeared to indicate that the response couldn’t be processed but it wasn’t clear why. On reflection, it’s possible that the VIN hadn’t been registered for the app. It could also be possible that one of the query string parameters in the very first URL I collective above wasn’t valid for that VIN. For example, the RegionCode field may not have matched with the vehicle’s location. Without a positive result from the API, we couldn’t emphatically conclude that there was indeed a lack of authorisation.

The thing about VINs however is that they’re lightly enumerable. Both Jan’s and the VIN found on the web were identical except for the last five digits which meant we could lightly test for other matches using a instrument like Burp suite. We proxied Chrome through Burp then issued the battery status request again:

We then sent it over to the Intruder feature and added one position for payload injection:

This was the last five digits of the VIN, those being the ones which differed across both Jan’s and the number found online. (Note: not all LEAF VINs necessarily differ by just the last five digits, the VIN specification permits for the range to be broader, i.e. it may be the last six digits. Our test simply kept the range constrained inbetween known numbers for the sake of time.) We then configured Burp to randomise those last five digits and choose integers inbetween Ten,000 and 30,000 which is the range both Jan’s and the VIN online fell within:

This gave us the capability to issue requests one after the other, each differing only by a unique VIN in the payload column. We didn’t need to test all 20,000 possible VINs within that range, we just had to issue requests until we found one that returned the battery status of another vehicle. We commenced Burp issuing the requests:

Request zero in the screen above is the one to Jan’s car which returned a response size of six hundred thirty one bytes. The subsequent responses with the randomised VINs mostly returned two hundred eighty eight bytes and the response you see in the screen above. Until we found one that didn’t:

This wasn’t Jan’s car; it was someone else’s LEAF. Our suspicion that the VIN was the only identifier required was confirmed and it became clear that there was a accomplish lack of auth on the service.

Of course it’s not just an issue related to retrieving vehicle status, recall the other APIs that can turn the climate control on or off. Anyone could potentially enumerate VINs and control the physical function of any vehicles that responded. That’s was a very serious issue. I reported it to Nissan the day after we discovered this (I wished Jan to provide me with more information very first), yet as of today – thirty two days later – the issue remains unresolved. You can read the disclosure timeline further down but certainly there were many messages and a phone call over a period of more than four weeks and it’s only now that I’m disclosing publicly, right after I received an email from a Canadian follower…

Vulnerable LEAFs in Canada

By unspoiled coincidence, just as we hit the four-week mark since initial disclosure and I was about to revert to Nissan yet again, an email landed in my inbox from a Canadian follower titled “weird Nissan api”. It commenced out like this:

I read your Vtech article and however that you would be well placed to appreciate this.

Im a Nissan Leaf possessor and I found out that Nissan security is pretty abismal. They have an App to remote begin charging, begin/stop the AC/Warmth, and get updated on current state of the vehicule.

This came in just last weekend on twenty Feb and it went on to explain the following:

I found out that the entire API is unauthenticated and only require the VIN to target a vehicle. To add insult to injury those activity are from plain http Get request.

This is precisely what Jan had found in Oslo and what’s more, it was being discussed openly on a forum. Browsing through the discussion courtesy of Google translate, clearly people were not glad with the Nissan app. In fact, they were so unhappy that one post suggests taking the app out of the picture altogether and controlling the vehicle’s functions by making requests directly to the APIs:

For hard-core, the following information:

URL to activate / deactivate air conditioning / heating. Put your VIN in the URL, this works very well in your browser. Create bookmarks with these two

They go on to conclude precisely what we had earlier on:

In all this, it works for me without being authenticated, which is very surprising, and not safe at all, this means that anyone can act on any vehicle, provided it knows the VIN (in more is it not written down the visible windshield everyone?). Looks like the authentication uses has get the VIN in the user profile.

Now this was back in December so we’re talking a duo of months ago already. Note also that the URLs above are different to the API endpoints we eyed for the Norwegian example (I obfuscated the other host names as I’ve not seem them discussed publicly, but even the paths are different). It’s an odd design decision for a global car manufacturer to segment their app in this way. There are always local idiosyncrasies to be considered (particularly in the auto industry), but there shows up to be very little reuse across Canada and Norway in terms of how the API is implemented. It has me wondering if perhaps the build of these apps is delegated to local groups who perhaps don’t pass through the same levels of rigour you’d expect at the global level.

The person who reported the Canadian finding to me finished up by telling this:

My hypothesis on this is that it was tied to surface due to the poor quality of the app, the more tech savvy “with free time” users will thinker with violated things to get them working for them. The fail was most likely discovered soon after the app switch and numerous times but by people that didn't fully appreciate the greater implication or by people like me that didn't know what to do with that skill.

His very first sentence is spot on – the ease of discovery of this risk is high as is evidenced by three separate parties already finding it independently (my Norwegian student, the Canadian follower and the folks in the forum). The Norwegian case alone was cause for concern and the Canadian one displayed that the issue was now well and truly out there in the public domain, but I wished further verification which is where Scott Helme came into the picture.

Nissan LEAFs in the UK

It was by unspoiled coincidence that Scott Helme from the movie in the intro has a LEAF, that he’s a security professional and that I spent some time with him in the UK just after my Oslo workshop. It was then that the penny dropped and we both realised that he could be of assistance. He’s proofed everything I’ve written here and obviously also suggested up his own car to verify that indeed, it’s only the VIN required to operate the functions described in this blog post. Given his involvement, I asked him if he wouldn’t mind sharing his own view of the situation and he gave me this paragraph:

Fortunately, the Nissan Leaf doesn't have features like remote unlock or remote begin, like some vehicles from other manufacturers do, because that would be a disaster with what's been uncovered. Still, a malicious actor could cause a good deal of problems for owners of the Nissan Leaf. Being able to remotely turn on the AC for a car might not seem like a problem, but this could put a significant drain on the battery over a period of time as the attacker can keep activating it. It's much like being able to begin the engine in a petrol car to run the AC, it's going to commence consuming the fuel you have in the tank. If your car is parked on the drive overnight or at work for ten hours and left running, you could have very little fuel left when you get back to it. You'd be stranded

Of course the other thing we covered in the movie was pulling the driving history from the vehicle which looks like this:

These are two trips he took on Feb twenty one when he dropped his son off at his parents. He took two other trips that day, one to go snowboarding and another one to come back. They were all recorded by the vehicle and are publicly accessible if you know his VIN which again, is displayed in his windscreen or can simply be guessed by enumerating through those last five digits.

This gives you details on movements per day which raises all sorts of privacy risks. Scott gave me a comment on that too.

The other main concern here is that the telematics system in the car is leaking *all* of my historic driving data. That's the details of every excursion I've ever made in the car including when I made it, how far I drove and even how efficiently I drove. This could lightly be used to build up a profile of my driving habits, considering it goes back almost two years, and predict when I will be away from home. This kind of data should be collected and secured with the utmost respect for my privacy.

Whilst it’s not specifically personally identifiable information such as the individual’s address, by the time you have a VIN which you know belongs to a LEAF registered within a specific country, it may not take too much effort to pack that gap. For example, down here in Australia we have services such as revscheck.com.au which can report on a pretty extensive set of data based on nothing more than a VIN. Jan sent me an equivalent service for Norway at vegvesen.no. I suspect that there are numerous other avenues where extra data about the vehicle and the possessor can be retrieved once the VIN is known and that opens the door to a raft of other possible privacy risks.

Rectifying the risk and opting out of the service

The underlying risk is elementary and I’ll quote Scott’s comments on it:

This API thing is just nuts. It's not even like they just missed auth or didn't check, it's actually not implemented.

It was built, intentionally, without security.

Clearly the reaction is to implement adequate authorisation on all API calls, which when building an app in the very first place would be a trivial feature to add. It’s trickier to add to a “brownfield” app however and in Nissan’s case, even trickier again because of the design of it. What’s unique about their treatment is that Norway and the UK seem to be hitting a entirely different set of APIs to Canada. In fact the European API is on a host not even wielded by Nissan, it’s registered to “ZENRIN DataCom CO.,LTD.” which may mean that we’re looking at numerous API endpoints managed by different parties that need to be rectified. Then of course the apps have to be updated across different client devices (iOS, Android, etc) and for different languages then shoved out to consumers. Whilst waiting for this to happen, LEAF owners remain at risk.

Because the question would inevitably arise, I asked Scott how he’d opt out of the service and he provided some steps:

Given the ease with which someone can enumerate valid VIN numbers, this issue raises a few concerns. It could be a gigantic inconvenience to have someone run my car plane by using the heating and accessories all day and the exposure of my entire driving history poses fairly the privacy concern too. To disable CarWings, owners need to login to the service form their browser, it can't be done through the mobile app. Once logged in, select 'Configuration' from the menu and there is a 'Eliminate CarWings' button. It shows up to be greyed out but the button does work. Once clicked you will receive a prompt to confirm that you wish to disable CarWings and asked to provide a reason why. Click 'Validate' when the adequate option has been selected and you will get a confirmation message that CarWings has been disabled. You should also receive a confirmation via email. Once Nissan have resolved this issue it should be safe to re-enable your CarWings account and resume using features associated with it. Simply login to your account and go after the prompts on screen.

Nissan’s “CarWings” is their telematics service and it’s accessible in the UK via this page on their website (other countries will have different URLs).

Existing public domain skill

One of the key factors in publishing this now is the existence of numerous other public discussions about the unauthenticated API. The fact that only the VIN is required to invoke these services has been covered at length and published in locations including:

1. A GitHub repository documenting the API including the observation that “All other operations take the DCMID and the VIN of your vehicle as parameters for authorizing the requested operation” (albeit the DCMID value is not actually required and is empty in many of the examples above)
2. Another GitHub repository, this time a Python script to connect to and manage vehicle features via the API (also includes region codes for managing vehicles in other parts of the world)
3. Yet another GitHub repository built to target an earlier generation of the service and referenced as inspiration for the previously mentioned project
4. A blog post on switch roles engineering the API which observes that “curiously, it seems like you just need the constant DCMID and VIN fields” (again, the DCMID parameter wasn’t actually used in our tests)
5. A forum post on integrating the data into Domoticz (a home automation system) which makes this observation: “No other authentication necessary!”

Whilst I haven’t linked directly to the resources, they’re lightly discoverable via Google and demonstrate that there is ongoing public discussion via numerous channels, each documenting the lack of authorisation on the services.

Disclosure timeline

I made numerous attempts over more than a month to get Nissan to resolve this and it was only after the Canadian email and French forum posts came to light that I eventually advised them I’d be publishing this post. Here’s the timeline (dates are Australian Eastern Standard time):

1. 23 Jan: Utter details of the findings sent and acknowledged by Nissan Information Security Threat Intelligence in the U.S.A.
2. 30 Jan: Phone call with Nissan to fully explain how the risk was discovered and the potential ramifications followed up by an email with further details
3. 12 Feb: Sent an email to ask about progress and suggest further support to which I was advised “We're making progress toward a solution”
4. 20 Feb: Sent details as provided by the Canadian holder (including a link to the discussion of the risk in the public forum) and advised I’d be publishing this blog post “later next week”
5. 24 Feb: This blog published, four weeks and four days after very first disclosure

All in all, I sent ten emails (there was some to-and-fro) and had one phone call. This morning I did hear back with a request to wait “a few weeks” before publishing, but given the extensive online discussions in public forums and the more than one-month lead time there’d already been, I advised I’d be publishing later that night and have not heard back since. I also invited Nissan to make any comments they’d like to include in this post when I contacted them on twenty Feb or provide any feedback on why they might not consider this a risk. However, there was nothing to that effect when I heard back from them earlier today, but I’ll gladly add an update later on if they’d like to contribute.

I do want to make it clear however that especially in the earlier discussions, Nissan treated this truly well. It was effortless to get in touch with the right people quickly and they made the time to talk and understand the issue. They were receptive and whilst I obviously would have liked to see this rectified quickly, compared to most ethical disclosure practices security researches have, Nissan was exemplary.

The ethics of discovery and disclosure

Just one last thing on how these vulnerabilities are discovered and reported because the ethics of this often comes up in my workshops. Risks like the one above were discovered by doing nothing more than using the app as it was intended to be used and observing the traffic going rearwards and forwards. This is the mobile equivalent of opening your browser’s dev instruments and watching the network tab. Sometimes (such as with the realestate.com.au vulnerability I reported last year), this is all that’s required. Other times and as was the case with the LEAF, it meant testing that the theory of one user being able to access another user’s resource could be proven. In a situation where it’s a car involved, you can’t exactly head out and buy a 2nd one in order to prove that when accessing one you can switch a parameter to access another and whilst the proof above did involve checking the battery status of another vehicle, it didn’t involve accessing any personally identifiable information or disadvantaging anyone in any way.

To me, it’s this elementary: if the intent is ethical and any findings are reported privately and instantaneously the moment you’re certain a serious risk is present – and especially if it can be done without viewing anyone else’s private date – then I’m convenient that’s in everybody’s best interests. If you report before being certain there’s a risk you end up wasting people’s time and if you don’t report, then you end up leaving people – and the organisation involved – at risk. A post such as this one is reviewed dozens of times over by myself and where possible, a peer or peers (Scott, in this case) to ensure fairness and accuracy.

Summary

Nissan need to fix this. It’s a different class of vulnerability to the Charlie Miller and Chris Valasek Jeep hacking shenanigans of last year, but in both good and bad ways. Good in that it doesn’t influence the driving controls of the vehicle, yet bad in that the ease of gaining access to vehicle controls in this style doesn’t get much lighter – it’s profoundly trivial. As car manufacturers rush towards joining in on the “internet of things” craze, security cannot be an afterthought nor something we’re told they take earnestly after realising that they didn’t take it earnestly enough in the very first place. Imagine getting it as wrong as Nissan has for something like Volvo’s “digital key” initiative where you unlock your car with your phone.

By unspoiled coincidence, this week Nissan unveiled a revised LEAF at the GSMA Mobile World Congress. Clearly, like many car makers, their future involves a strong thrust for greater connectivity in their vehicles:

In a fully connected, fully mobile world, in-vehicle connectivity is an absolute must for today’s drivers. That is why Nissan is proud to be at the forefront of developing efficient and reliable in-vehicle connected technologies that are available and accessible to all

Amongst the list of features the media release talks about being added to the NissanConnect app is the capability to remotely showcase the vehicle position on a map and analyse your driving. Whilst there are demonstrable upsides to drivers having access to these features, witnessing them introduced within the security implementation of the current app would be very worrying for visible reasons.

I would have preferred to see swifter activity from Nissan. In my view, this is the sort of flaw that needs to have the service pulled until it can be immobile decently and restored; it’s not a critical feature of the vehicle yet it has the potential to influence its physical function and there’s the privacy risk as well. Plus of course it’s already being discussed publicly via that Canadian forum so the risk is well and truly out in the public domain already. I want to see Nissan secure this; I own a Nissan myself (albeit not a connected one) which I’m sultry about and am very invested in the brand, both emotionally and financially. But they do need to take activity on this because clearly the current state is not satisfactory.

Update Two, twenty five Feb, 14:20: Per the comment below and further correspondence I've had via email, it emerges that Canadian resources are still accessible using only the VIN.

Troy Hunt

Hi, I'm Troy Hunt, I write this blog, create courses for Pluralsight and am a Microsoft Regional Director and MVP who travels the world speaking at events and training technology professionals

Troy Hunt

Hi, I'm Troy Hunt, I write this blog, create courses for Pluralsight and am a Microsoft Regional Director and MVP who travels the world speaking at events and training technology professionals

Upcoming Events

I usually run private workshops around these, here’s the upcoming public events I’ll be at:

Troy Hunt: Controlling vehicle features of Nissan LEAFs across the globe via vulnerable APIs

Controlling vehicle features of Nissan LEAFs across the globe via vulnerable APIs

Last month I was over in Norway doing training for ProgramUtvikling, the good folks who run the NDC conferences I've become so affixed to. I was running my usual “Hack Yourself Very first” workshop which is targeted at software developers who’d like to get up to speed on the things they should be doing to protect their apps against today’s online threats. Across the two days of training, I cover sixteen separate discrete modules ranging from SQL injection to password cracking to enumeration risks, basically all the highest priority security bits modern developers need to be thinking about. I also cover how to inspect, intercept and control API requests inbetween rich client apps such as those you find on a modern wise phone and the services running on the back end server. And that’s where things got interesting.

One of the guys was a bit inspired by what we’d done and just happened to own one of these – the world’s best-selling electrical car, a Nissan LEAF:

What the workshop attendee ultimately discovered was that not only could he connect to his LEAF over the internet and control features independently of how Nissan had designed the app, he could control other people’s LEAFs. I subsequently discovered that friend and fellow security researcher Scott Helme also has a LEAF so we recorded the following movie to demonstrate the problem. I’m putting this up front here to clearly put into context what this risk enables someone to do then I’ll delve into the details over the remainder of the post:

We elected for me to sit outside in a sunny environment whilst Scott was shivering in the cold to demonstrate just how remote you can be and still control feature of someone else’s car, literally from the other end of the earth. Following is a finish walkthrough of the discovery process, how vehicles in other countries can also be managed and a total disclosure timeline of my discussions with Nissan.

Connected LEAFs

The LEAF is an electrified car which is particularly popular in countries like Norway which suggest massive financial incentives to stay away from combustion engines. It does all the things you’d expect of a modern EV and because it’s here in the era of the internet of things, it also has a companion app:

Back at my workshop in Oslo and being the nosey type, Jan (not his real name – he requested to remain anonymous) goes back to his hotel after the very first day of the course and proxies his iPhone through Fiddler running on his PC as we’d done during the day (this was on January 20). This takes a few minutes to setup and effectively what it means is that he can now observe how the mobile app talks to the online services. Jan then fires up the NissanConnect EV app:

I’m using publicly available screen grabs of the app in part so as not to disclose individual information about Jan and part because his app runs in Norwegian. When the app opens, he observes a request like this (I’ll obfuscate host names and the last five digits of VINs across this post):

Which comebacks the following JSON response:

This is pretty self-explanatory if you read through the response; we’re witnessing the battery status of his LEAF. But what got Jan’s attention is not that he could get the vehicle’s present status, but rather that the request his phone had issued didn’t show up to contain any identity data about his authenticated session. In other words, he was accessing the API anonymously. It’s a GET request so there was nothing passed in the figure nor was there anything like a bearer token in the request header. In fact, the only thing identifying his vehicle was the VIN which I’ve partially obfuscated in the URL above.

The VIN is the Vehicle Identification Number which uniquely identifies the chassis of his LEAF. It is by no means a “secret” suitable for authorisation purposes, the significance of which I’ll come back to shortly.

On the surface of it, it looked like anyone could get the battery status of Jan’s vehicle if they knew his VIN. Not ideal, but not exactly serious either as it’s a passive query (it doesn’t actually switch anything on the vehicle) and there’s also nothing of a individual or sensitive nature returned in the response beyond potentially telling you when it was last driven based on the OperationDateAndTime field. So Jan kept looking.

He found he could check the status of the climate control using this request:

Which then returned a similar status result:

This is reflected within the app on this screen:

But again, it’s passive data – is the climate control on or off and as a result, what should the buttons say. But then he attempted turning it on and observed this request:

That request returned this response:

This time, individual information about Jan was returned, namely his user ID which was a variation of his actual name. The VIN passed in the request also came back in the response and a result key was returned.

He then turned the climate control off and observed as the app issued this request:

All of these requests were made without an auth token of any kind; they were issued anonymously. Jan checked them by loading them up in Chrome as well and sure enough, the response was returned just fine. By now, it was pretty clear the API had absolutely zero access controls but the potential for invoking it under the identity of other vehicles wasn’t yet clear.

Connecting to other vehicles

When Jan came into the workshop the following day, he also brought in a picture he’d managed to locate by searching the web:

This was the vehicle's VIN which clearly, left us nosey (obfuscation is mine, it’s legible in its entirety on the web).

Let me clarify something before going any further and it’s something I harp on about in my workshops too; when a potential security flaw is identified, you’ve got to think very cautiously about how you proceed with verification. You need to have a sufficient degree of confidence that it’s a legitimate flaw before reporting it ethically (which is what we ultimately did), but you also need to ensure you don’t breach someone else’s privacy or influence them adversely in any way. We wouldn’t, for example, want to begin operating mechanical features of someone else’s car such as turning on the climate control nor would we want to retrieve individual information about them, even if it was just their username.

The VIN above differed merely by the last five digits. We grabbed the number and plugged it into the request to get the battery status – a request that didn’t switch anything nor disclose anything private – and got this response:

This appeared to indicate that the response couldn’t be processed but it wasn’t clear why. On reflection, it’s possible that the VIN hadn’t been registered for the app. It could also be possible that one of the query string parameters in the very first URL I collective above wasn’t valid for that VIN. For example, the RegionCode field may not have matched with the vehicle’s location. Without a positive result from the API, we couldn’t emphatically conclude that there was indeed a lack of authorisation.

The thing about VINs however is that they’re lightly enumerable. Both Jan’s and the VIN found on the web were identical except for the last five digits which meant we could lightly test for other matches using a instrument like Burp suite. We proxied Chrome through Burp then issued the battery status request again:

We then sent it over to the Intruder feature and added one position for payload injection:

This was the last five digits of the VIN, those being the ones which differed across both Jan’s and the number found online. (Note: not all LEAF VINs necessarily differ by just the last five digits, the VIN specification permits for the range to be broader, i.e. it may be the last six digits. Our test simply kept the range constrained inbetween known numbers for the sake of time.) We then configured Burp to randomise those last five digits and choose integers inbetween Ten,000 and 30,000 which is the range both Jan’s and the VIN online fell within:

This gave us the capability to issue requests one after the other, each differing only by a unique VIN in the payload column. We didn’t need to test all 20,000 possible VINs within that range, we just had to issue requests until we found one that returned the battery status of another vehicle. We commenced Burp issuing the requests:

Request zero in the screen above is the one to Jan’s car which returned a response size of six hundred thirty one bytes. The subsequent responses with the randomised VINs mostly returned two hundred eighty eight bytes and the response you see in the screen above. Until we found one that didn’t:

This wasn’t Jan’s car; it was someone else’s LEAF. Our suspicion that the VIN was the only identifier required was confirmed and it became clear that there was a finish lack of auth on the service.

Of course it’s not just an issue related to retrieving vehicle status, recall the other APIs that can turn the climate control on or off. Anyone could potentially enumerate VINs and control the physical function of any vehicles that responded. That’s was a very serious issue. I reported it to Nissan the day after we discovered this (I wished Jan to provide me with more information very first), yet as of today – thirty two days later – the issue remains unresolved. You can read the disclosure timeline further down but certainly there were many messages and a phone call over a period of more than four weeks and it’s only now that I’m disclosing publicly, right after I received an email from a Canadian follower…

Vulnerable LEAFs in Canada

By unspoiled coincidence, just as we hit the four-week mark since initial disclosure and I was about to revert to Nissan yet again, an email landed in my inbox from a Canadian follower titled “weird Nissan api”. It embarked out like this:

I read your Vtech article and tho’ that you would be well placed to appreciate this.

Im a Nissan Leaf holder and I found out that Nissan security is pretty abismal. They have an App to remote embark charging, embark/stop the AC/Fever, and get updated on current state of the vehicule.

This came in just last weekend on twenty Feb and it went on to explain the following:

I found out that the entire API is unauthenticated and only require the VIN to target a vehicle. To add insult to injury those act are from plain http Get request.

This is precisely what Jan had found in Oslo and what’s more, it was being discussed openly on a forum. Browsing through the discussion courtesy of Google translate, clearly people were not blessed with the Nissan app. In fact, they were so unhappy that one post suggests taking the app out of the picture altogether and controlling the vehicle’s functions by making requests directly to the APIs:

For hard-core, the following information:

URL to activate / deactivate air conditioning / heating. Put your VIN in the URL, this works very well in your browser. Create bookmarks with these two

They go on to conclude precisely what we had earlier on:

In all this, it works for me without being authenticated, which is very surprising, and not safe at all, this means that anyone can act on any vehicle, provided it knows the VIN (in more is it not written down the visible windshield everyone?). Looks like the authentication uses has get the VIN in the user profile.

Now this was back in December so we’re talking a duo of months ago already. Note also that the URLs above are different to the API endpoints we witnessed for the Norwegian example (I obfuscated the other host names as I’ve not seem them discussed publicly, but even the paths are different). It’s an odd design decision for a global car manufacturer to segment their app in this way. There are always local idiosyncrasies to be considered (particularly in the auto industry), but there emerges to be very little reuse across Canada and Norway in terms of how the API is implemented. It has me wondering if perhaps the build of these apps is delegated to local groups who perhaps don’t pass through the same levels of rigour you’d expect at the global level.

The person who reported the Canadian finding to me finished up by telling this:

My hypothesis on this is that it was tied to surface due to the poor quality of the app, the more tech savvy “with free time” users will thinker with cracked things to get them working for them. The fail was very likely discovered soon after the app switch and numerous times but by people that didn't fully appreciate the greater implication or by people like me that didn't know what to do with that skill.

His very first sentence is spot on – the ease of discovery of this risk is high as is evidenced by three separate parties already finding it independently (my Norwegian student, the Canadian follower and the folks in the forum). The Norwegian case alone was cause for concern and the Canadian one displayed that the issue was now well and truly out there in the public domain, but I wished further verification which is where Scott Helme came into the picture.

Nissan LEAFs in the UK

It was by unspoiled coincidence that Scott Helme from the movie in the intro has a LEAF, that he’s a security professional and that I spent some time with him in the UK just after my Oslo workshop. It was then that the penny dropped and we both realised that he could be of assistance. He’s proofed everything I’ve written here and obviously also suggested up his own car to verify that indeed, it’s only the VIN required to operate the functions described in this blog post. Given his involvement, I asked him if he wouldn’t mind sharing his own view of the situation and he gave me this paragraph:

Fortunately, the Nissan Leaf doesn't have features like remote unlock or remote commence, like some vehicles from other manufacturers do, because that would be a disaster with what's been uncovered. Still, a malicious actor could cause a superb deal of problems for owners of the Nissan Leaf. Being able to remotely turn on the AC for a car might not seem like a problem, but this could put a significant drain on the battery over a period of time as the attacker can keep activating it. It's much like being able to begin the engine in a petrol car to run the AC, it's going to embark consuming the fuel you have in the tank. If your car is parked on the drive overnight or at work for ten hours and left running, you could have very little fuel left when you get back to it. You'd be stranded

Of course the other thing we covered in the movie was pulling the driving history from the vehicle which looks like this:

These are two trips he took on Feb twenty one when he dropped his son off at his parents. He took two other trips that day, one to go snowboarding and another one to comeback. They were all recorded by the vehicle and are publicly accessible if you know his VIN which again, is displayed in his windscreen or can simply be guessed by enumerating through those last five digits.

This gives you details on movements per day which raises all sorts of privacy risks. Scott gave me a comment on that too.

The other main concern here is that the telematics system in the car is leaking *all* of my historic driving data. That's the details of every excursion I've ever made in the car including when I made it, how far I drove and even how efficiently I drove. This could lightly be used to build up a profile of my driving habits, considering it goes back almost two years, and predict when I will be away from home. This kind of data should be collected and secured with the utmost respect for my privacy.

Whilst it’s not specifically personally identifiable information such as the individual’s address, by the time you have a VIN which you know belongs to a LEAF registered within a specific country, it may not take too much effort to pack that gap. For example, down here in Australia we have services such as revscheck.com.au which can report on a pretty extensive set of data based on nothing more than a VIN. Jan sent me an equivalent service for Norway at vegvesen.no. I suspect that there are numerous other avenues where extra data about the vehicle and the possessor can be retrieved once the VIN is known and that opens the door to a raft of other possible privacy risks.

Rectifying the risk and opting out of the service

The underlying risk is ordinary and I’ll quote Scott’s comments on it:

This API thing is just nuts. It's not even like they just missed auth or didn't check, it's actually not implemented.

It was built, intentionally, without security.

Clearly the reaction is to implement suitable authorisation on all API calls, which when building an app in the very first place would be a trivial feature to add. It’s trickier to add to a “brownfield” app however and in Nissan’s case, even trickier again because of the design of it. What’s unique about their treatment is that Norway and the UK seem to be hitting a entirely different set of APIs to Canada. In fact the European API is on a host not even wielded by Nissan, it’s registered to “ZENRIN DataCom CO.,LTD.” which may mean that we’re looking at numerous API endpoints managed by different parties that need to be rectified. Then of course the apps have to be updated across different client devices (iOS, Android, etc) and for different languages then shoved out to consumers. Whilst waiting for this to happen, LEAF owners remain at risk.

Because the question would inevitably arise, I asked Scott how he’d opt out of the service and he provided some steps:

Given the ease with which someone can enumerate valid VIN numbers, this issue raises a few concerns. It could be a massive inconvenience to have someone run my car vapid by using the heating and accessories all day and the exposure of my entire driving history poses fairly the privacy concern too. To disable CarWings, owners need to login to the service form their browser, it can't be done through the mobile app. Once logged in, select 'Configuration' from the menu and there is a 'Liquidate CarWings' button. It shows up to be greyed out but the button does work. Once clicked you will receive a prompt to confirm that you wish to disable CarWings and asked to provide a reason why. Click 'Validate' when the suitable option has been selected and you will get a confirmation message that CarWings has been disabled. You should also receive a confirmation via email. Once Nissan have resolved this issue it should be safe to re-enable your CarWings account and resume using features associated with it. Simply login to your account and go after the prompts on screen.

Nissan’s “CarWings” is their telematics service and it’s accessible in the UK via this page on their website (other countries will have different URLs).

Existing public domain skill

One of the key factors in publishing this now is the existence of numerous other public discussions about the unauthenticated API. The fact that only the VIN is required to invoke these services has been covered at length and published in locations including:

1. A GitHub repository documenting the API including the observation that “All other operations take the DCMID and the VIN of your vehicle as parameters for authorizing the requested operation” (albeit the DCMID value is not actually required and is empty in many of the examples above)
2. Another GitHub repository, this time a Python script to connect to and manage vehicle features via the API (also includes region codes for managing vehicles in other parts of the world)
3. Yet another GitHub repository built to target an earlier generation of the service and referenced as inspiration for the previously mentioned project
4. A blog post on switch roles engineering the API which observes that “curiously, it seems like you just need the constant DCMID and VIN fields” (again, the DCMID parameter wasn’t actually used in our tests)
5. A forum post on integrating the data into Domoticz (a home automation system) which makes this observation: “No other authentication necessary!”

Whilst I haven’t linked directly to the resources, they’re lightly discoverable via Google and demonstrate that there is ongoing public discussion via numerous channels, each documenting the lack of authorisation on the services.

Disclosure timeline

I made numerous attempts over more than a month to get Nissan to resolve this and it was only after the Canadian email and French forum posts came to light that I eventually advised them I’d be publishing this post. Here’s the timeline (dates are Australian Eastern Standard time):

1. 23 Jan: Utter details of the findings sent and acknowledged by Nissan Information Security Threat Intelligence in the U.S.A.
2. 30 Jan: Phone call with Nissan to fully explain how the risk was discovered and the potential ramifications followed up by an email with further details
3. 12 Feb: Sent an email to ask about progress and suggest further support to which I was advised “We're making progress toward a solution”
4. 20 Feb: Sent details as provided by the Canadian holder (including a link to the discussion of the risk in the public forum) and advised I’d be publishing this blog post “later next week”
5. 24 Feb: This blog published, four weeks and four days after very first disclosure

All in all, I sent ten emails (there was some to-and-fro) and had one phone call. This morning I did hear back with a request to wait “a few weeks” before publishing, but given the extensive online discussions in public forums and the more than one-month lead time there’d already been, I advised I’d be publishing later that night and have not heard back since. I also invited Nissan to make any comments they’d like to include in this post when I contacted them on twenty Feb or provide any feedback on why they might not consider this a risk. However, there was nothing to that effect when I heard back from them earlier today, but I’ll gladly add an update later on if they’d like to contribute.

I do want to make it clear however that especially in the earlier discussions, Nissan treated this indeed well. It was effortless to get in touch with the right people quickly and they made the time to talk and understand the issue. They were receptive and whilst I obviously would have liked to see this rectified quickly, compared to most ethical disclosure practices security researches have, Nissan was exemplary.

The ethics of discovery and disclosure

Just one last thing on how these vulnerabilities are discovered and reported because the ethics of this often comes up in my workshops. Risks like the one above were discovered by doing nothing more than using the app as it was intended to be used and observing the traffic going rearwards and forwards. This is the mobile equivalent of opening your browser’s dev instruments and watching the network tab. Sometimes (such as with the realestate.com.au vulnerability I reported last year), this is all that’s required. Other times and as was the case with the LEAF, it meant testing that the theory of one user being able to access another user’s resource could be proven. In a situation where it’s a car involved, you can’t exactly head out and buy a 2nd one in order to prove that when accessing one you can switch a parameter to access another and whilst the proof above did involve checking the battery status of another vehicle, it didn’t involve accessing any personally identifiable information or disadvantaging anyone in any way.

To me, it’s this ordinary: if the intent is ethical and any findings are reported privately and instantly the moment you’re certain a serious risk is present – and especially if it can be done without viewing anyone else’s private date – then I’m convenient that’s in everybody’s best interests. If you report before being certain there’s a risk you end up wasting people’s time and if you don’t report, then you end up leaving people – and the organisation involved – at risk. A post such as this one is reviewed dozens of times over by myself and where possible, a peer or peers (Scott, in this case) to ensure fairness and accuracy.

Summary

Nissan need to fix this. It’s a different class of vulnerability to the Charlie Miller and Chris Valasek Jeep hacking shenanigans of last year, but in both good and bad ways. Good in that it doesn’t influence the driving controls of the vehicle, yet bad in that the ease of gaining access to vehicle controls in this style doesn’t get much lighter – it’s profoundly trivial. As car manufacturers rush towards joining in on the “internet of things” craze, security cannot be an afterthought nor something we’re told they take gravely after realising that they didn’t take it earnestly enough in the very first place. Imagine getting it as wrong as Nissan has for something like Volvo’s “digital key” initiative where you unlock your car with your phone.

By unspoiled coincidence, this week Nissan unveiled a revised LEAF at the GSMA Mobile World Congress. Clearly, like many car makers, their future involves a strong shove for greater connectivity in their vehicles:

In a fully connected, fully mobile world, in-vehicle connectivity is an absolute must for today’s drivers. That is why Nissan is proud to be at the forefront of developing efficient and reliable in-vehicle connected technologies that are available and accessible to all

Amongst the list of features the media release talks about being added to the NissanConnect app is the capability to remotely display the vehicle position on a map and analyse your driving. Whilst there are demonstrable upsides to drivers having access to these features, eyeing them introduced within the security implementation of the current app would be very worrying for demonstrable reasons.

I would have preferred to see swifter act from Nissan. In my view, this is the sort of flaw that needs to have the service pulled until it can be immobile decently and restored; it’s not a critical feature of the vehicle yet it has the potential to influence its physical function and there’s the privacy risk as well. Plus of course it’s already being discussed publicly via that Canadian forum so the risk is well and truly out in the public domain already. I want to see Nissan secure this; I own a Nissan myself (albeit not a connected one) which I’m sultry about and am very invested in the brand, both emotionally and financially. But they do need to take activity on this because clearly the current state is not satisfactory.

Update Two, twenty five Feb, 14:20: Per the comment below and further correspondence I've had via email, it emerges that Canadian resources are still accessible using only the VIN.

Troy Hunt

Hi, I'm Troy Hunt, I write this blog, create courses for Pluralsight and am a Microsoft Regional Director and MVP who travels the world speaking at events and training technology professionals

Troy Hunt

Hi, I'm Troy Hunt, I write this blog, create courses for Pluralsight and am a Microsoft Regional Director and MVP who travels the world speaking at events and training technology professionals

Upcoming Events

I usually run private workshops around these, here’s the upcoming public events I’ll be at:

Related movie: