Security issue with InControl Remote?
#1
Security issue with InControl Remote?
Hey,
Just thinking here... What if someone were able to gain access to a phone with the InContol Remote app (mine does have a passcode lock, but let just say...) Conceivably they could unlock, then start using the remote climate, and then... drive off??
Just thinking here... What if someone were able to gain access to a phone with the InContol Remote app (mine does have a passcode lock, but let just say...) Conceivably they could unlock, then start using the remote climate, and then... drive off??
#3
#5
In most cases it's also far easier to steal someone's keys than it is to steal their phone and unlock it. While there are exploits that exist for all of the various phone OS, the need to unlock the phone provides a (limited) degree of 2-factor authentication.
Assuming you use a good passcode of course.
When you add in the need for a special PIN that's certainly a reasonable level of security.
Assuming you use a good passcode of course.
When you add in the need for a special PIN that's certainly a reasonable level of security.
#6
I would argue that InControl Remote is insecure "at any speed" and would recommend people concerned with security and privacy to not activate this service.
There are many potential ways to attack (often referred as attack surfaces) InControl Remote aside from ones resulting from a compromise or theft of a smartphone. To better explain this, I will outline below how it is likely operates.
Your app sends requests over public internet to a remote JLR server. JLR server authenticates your request and transmits unlock codes over public internet to your car. These connections must incorporate both strong encryption, replay counter-measures, and robust authentication of all end points. It is possible that an implementation flaw would allow replay attacks (your unlock message stored and used later), tampering and substitution attacks (someone else's unlock message redirected to your car), or impersonation (someone pretending to be JLR server sending your car unlock codes or someone pretending to be you sending JLR server a request to unlock). It is possible that a smartphone, JLR server, or even your car will get compromised directly, where attackers could subvert protection and checking mechanisms. This could be data containing necessary credentials to impersonate, or data containing cryptographic secrets allowing attackers to decode and tamper with messages, including past messages that were recorded and stored.
InfoSec is what I do for living, well enough to afford an F-type. In my opinion, without analyzing (thanks DMCA!) actual application in question, an automotive company has a snowball chance in hell to get all of this right. There are just so many nuances and pitfalls that even IT companies often fail. JLR, without core competencies in IT security, would not, could not, will not be able to design a secure system. This is just like asking a roofer to also do plumbing in your house.
You probably heard of Chrysler fiasco, where security researchers managed to remotely take over a Jeep, including climate controls, emergency braking, gear selection, throttle application and so on. There is no reason to expect JLR to do any better. There is no reason to expect that unlocking your car is the only possible remotely activated feature.
If you are using InControl, the only reason you are still in control is because nobody bothered to hack it or subpoena JLR.
There are many potential ways to attack (often referred as attack surfaces) InControl Remote aside from ones resulting from a compromise or theft of a smartphone. To better explain this, I will outline below how it is likely operates.
Your app sends requests over public internet to a remote JLR server. JLR server authenticates your request and transmits unlock codes over public internet to your car. These connections must incorporate both strong encryption, replay counter-measures, and robust authentication of all end points. It is possible that an implementation flaw would allow replay attacks (your unlock message stored and used later), tampering and substitution attacks (someone else's unlock message redirected to your car), or impersonation (someone pretending to be JLR server sending your car unlock codes or someone pretending to be you sending JLR server a request to unlock). It is possible that a smartphone, JLR server, or even your car will get compromised directly, where attackers could subvert protection and checking mechanisms. This could be data containing necessary credentials to impersonate, or data containing cryptographic secrets allowing attackers to decode and tamper with messages, including past messages that were recorded and stored.
InfoSec is what I do for living, well enough to afford an F-type. In my opinion, without analyzing (thanks DMCA!) actual application in question, an automotive company has a snowball chance in hell to get all of this right. There are just so many nuances and pitfalls that even IT companies often fail. JLR, without core competencies in IT security, would not, could not, will not be able to design a secure system. This is just like asking a roofer to also do plumbing in your house.
You probably heard of Chrysler fiasco, where security researchers managed to remotely take over a Jeep, including climate controls, emergency braking, gear selection, throttle application and so on. There is no reason to expect JLR to do any better. There is no reason to expect that unlocking your car is the only possible remotely activated feature.
If you are using InControl, the only reason you are still in control is because nobody bothered to hack it or subpoena JLR.
Last edited by SinF; 02-16-2017 at 10:59 AM.
#7
Trending Topics
#8
I would argue that InControl Remote is insecure "at any speed" and would recommend people concerned with security and privacy to not activate this service.
There are many potential ways to attack (often referred as attack surfaces) InControl Remote aside from ones resulting from a compromise or theft of a smartphone. To better explain this, I will outline below how it is likely operates.
Your app sends requests over public internet to a remote JLR server. JLR server authenticates your request and transmits unlock codes over public internet to your car. These connections must incorporate both strong encryption, replay counter-measures, and robust authentication of all end points. It is possible that an implementation flaw would allow replay attacks (your unlock message stored and used later), tampering and substitution attacks (someone else's unlock message redirected to your car), or impersonation (someone pretending to be JLR server sending your car unlock codes or someone pretending to be you sending JLR server a request to unlock). It is possible that a smartphone, JLR server, or even your car will get compromised directly, where attackers could subvert protection and checking mechanisms. This could be data containing necessary credentials to impersonate, or data containing cryptographic secrets allowing attackers to decode and tamper with messages, including past messages that were recorded and stored.
InfoSec is what I do for living, well enough to afford an F-type. In my opinion, without analyzing (thanks DMCA!) actual application in question, an automotive company has a snowball chance in hell to get all of this right. There are just so many nuances and pitfalls that even IT companies often fail. JLR, without core competencies in IT security, would not, could not, will not be able to design a secure system. This is just like asking a roofer to also do plumbing in your house.
You probably heard of Chrysler fiasco, where security researchers managed to remotely take over a Jeep, including climate controls, emergency braking, gear selection, throttle application and so on. There is no reason to expect JLR to do any better. There is no reason to expect that unlocking your car is the only possible remotely activated feature.
If you are using InControl, the only reason you are still in control is because nobody bothered to hack it or subpoena JLR.
There are many potential ways to attack (often referred as attack surfaces) InControl Remote aside from ones resulting from a compromise or theft of a smartphone. To better explain this, I will outline below how it is likely operates.
Your app sends requests over public internet to a remote JLR server. JLR server authenticates your request and transmits unlock codes over public internet to your car. These connections must incorporate both strong encryption, replay counter-measures, and robust authentication of all end points. It is possible that an implementation flaw would allow replay attacks (your unlock message stored and used later), tampering and substitution attacks (someone else's unlock message redirected to your car), or impersonation (someone pretending to be JLR server sending your car unlock codes or someone pretending to be you sending JLR server a request to unlock). It is possible that a smartphone, JLR server, or even your car will get compromised directly, where attackers could subvert protection and checking mechanisms. This could be data containing necessary credentials to impersonate, or data containing cryptographic secrets allowing attackers to decode and tamper with messages, including past messages that were recorded and stored.
InfoSec is what I do for living, well enough to afford an F-type. In my opinion, without analyzing (thanks DMCA!) actual application in question, an automotive company has a snowball chance in hell to get all of this right. There are just so many nuances and pitfalls that even IT companies often fail. JLR, without core competencies in IT security, would not, could not, will not be able to design a secure system. This is just like asking a roofer to also do plumbing in your house.
You probably heard of Chrysler fiasco, where security researchers managed to remotely take over a Jeep, including climate controls, emergency braking, gear selection, throttle application and so on. There is no reason to expect JLR to do any better. There is no reason to expect that unlocking your car is the only possible remotely activated feature.
If you are using InControl, the only reason you are still in control is because nobody bothered to hack it or subpoena JLR.
If this system were to say.. unlock my office.. hell no. To unlock my car *shrug*.
The following users liked this post:
Misujerr (02-16-2017)
#9
LobsterClaws, here are couple threat models to stimulate your imagination:
A. Pay 10BC to this address to stop continuous door lock cycling
B. Pay us 100BC or we will mail your wife google earth picture corresponding to GPS coordinates of where your car was parked every Thursday night when you were supposedly working late.
C. Exhibit A: Your honor, the unlock request sent to LobsterClaw's F-type parked 0.5 miles from the crime scene from his phone, as corroborated by cell tower triangulation place him at the crime scene at the exact time of the event.
D. Screw 1%s! $ sh ~/JLRpwnscript.sh
A. Pay 10BC to this address to stop continuous door lock cycling
B. Pay us 100BC or we will mail your wife google earth picture corresponding to GPS coordinates of where your car was parked every Thursday night when you were supposedly working late.
C. Exhibit A: Your honor, the unlock request sent to LobsterClaw's F-type parked 0.5 miles from the crime scene from his phone, as corroborated by cell tower triangulation place him at the crime scene at the exact time of the event.
D. Screw 1%s! $ sh ~/JLRpwnscript.sh
#10
LobsterClaws, here are couple threat models to stimulate your imagination:
A. Pay 10BC to this address to stop continuous door lock cycling
B. Pay us 100BC or we will mail your wife google earth picture corresponding to GPS coordinates of where your car was parked every Thursday night when you were supposedly working late.
C. Exhibit A: Your honor, the unlock request sent to LobsterClaw's F-type parked 0.5 miles from the crime scene from his phone, as corroborated by cell tower triangulation place him at the crime scene at the exact time of the event.
D. Screw 1%s! $ sh ~/JLRpwnscript.sh
A. Pay 10BC to this address to stop continuous door lock cycling
B. Pay us 100BC or we will mail your wife google earth picture corresponding to GPS coordinates of where your car was parked every Thursday night when you were supposedly working late.
C. Exhibit A: Your honor, the unlock request sent to LobsterClaw's F-type parked 0.5 miles from the crime scene from his phone, as corroborated by cell tower triangulation place him at the crime scene at the exact time of the event.
D. Screw 1%s! $ sh ~/JLRpwnscript.sh
A and D I'll grant you seem like reasonable concerns. As with many things it's a tradeoff between convenience and security. I think a reasonable person could look at those threats and choose to proceed anyway.
#11
Presumably, whether you as an owner use Remote or not, someone ( at Jaguar?) can use it and track the car anyway. The car has the equivalent of a phone SIM card installed and can be contacted at anytime. At least it does in the UK for the first 3 years.
Edit
And who knows? After the 3 year warranty, if you don't renew Remote it's not to say that it's still active to Jaguar.
Edit
And who knows? After the 3 year warranty, if you don't renew Remote it's not to say that it's still active to Jaguar.
Last edited by malbec; 02-16-2017 at 02:26 PM.
#12
Holy crap SinF, youhave hacked my system log!
I am still trying to locate the SIM card on the car, so that I can drive anonymously! No one 'apparently' knows of its whereabouts?
Last edited by Tel; 02-16-2017 at 03:56 PM.
#13
Yikes, SinF, now I'm reeeally freeked out
And you also touched on something else too, in that once that barn door is open, ain't no closing it again. i.e. once we have signed up & logged in, even if we pull the plug, they still have that data and still track us down, right? Even if you don't sign up for Remote, if you sign up for roadside assistance & SOS, they can still track you down, it's what they do...
What can be done to protect ourselves? I'm not worried about my car showing up at an "indiscreet" place, I'm more worried about the "black box" aspect, where they could tell how fast you were going, if you were on a racetrack and your insurance didn't cover it, etc..
Thanks for your input, I appreciate it.
And you also touched on something else too, in that once that barn door is open, ain't no closing it again. i.e. once we have signed up & logged in, even if we pull the plug, they still have that data and still track us down, right? Even if you don't sign up for Remote, if you sign up for roadside assistance & SOS, they can still track you down, it's what they do...
What can be done to protect ourselves? I'm not worried about my car showing up at an "indiscreet" place, I'm more worried about the "black box" aspect, where they could tell how fast you were going, if you were on a racetrack and your insurance didn't cover it, etc..
Thanks for your input, I appreciate it.
#14
Local logging is done via something called EDR (event data recorder). Remote connection is done via cell modem + sim card (just like your smartphone). You need to find hardware for both and disconnect/disable it. Chances are, EDR couldn't be practically disabled, however if you find cell modem you could disconnect antenna to 'soft' disable it.
Last edited by SinF; 02-16-2017 at 09:43 PM.
The following users liked this post:
Misujerr (02-17-2017)
#16
The following users liked this post:
Misujerr (02-19-2017)
#18
Nit-picking aside, your contention that we should be really aware of security vulnerabilities is spot on.
The following users liked this post:
Misujerr (02-21-2017)
#19
Hyundai app hacked. Allows remote start and unlock. There is no reason to expect JLR InControl to be any more secure than this.
#20
Hyundai app hacked. Allows remote start and unlock. There is no reason to expect JLR InControl to be any more secure than this.