Android Malware Used to Hack and Steal a Tesla Car(bleepingcomputer.com)
bleepingcomputer.com
Android Malware Used to Hack and Steal a Tesla Car
http://www.bleepingcomputer.com/news/security/android-malware-used-to-hack-and-steal-a-tesla-car/
41 コメント
"Almost" doesn't count for security. Android is a known insecure platform, don't allow things running on the platform to open people's cars.
> Android is a known insecure platform
And so is iOS, macOS, Windows, Linux, etc. if by insecure you mean "has has historically had security holes and can be used in an insecure manner".
If you mean that Android is just "insecure" as a general statement, though, I'd have to disagree. The operating system itself can be used in a moderately secure way is relation to other popular mobile OS's like iOS.
And so is iOS, macOS, Windows, Linux, etc. if by insecure you mean "has has historically had security holes and can be used in an insecure manner".
If you mean that Android is just "insecure" as a general statement, though, I'd have to disagree. The operating system itself can be used in a moderately secure way is relation to other popular mobile OS's like iOS.
There are lots of ways to get access to this data, installing an app is a pretty convenient and common way to do so.
Any app can be hacked with enough effort. The Tesla app provided absolutely no resistance, and technically no privilege escalation is required to steal the relevant data. Your screen reader app, or custom keyboard has the relevant access.
>Promon engineers recommend that the Tesla app provide two-factor authentication, should avoid storing the OAuth token in cleartext, prevent easy access to its source code, and use a custom keyboard layout when entering passwords to fight against mobile keyloggers.
We did not recommend this, however the OAuth token should not be in clear text.
Any app can be hacked with enough effort. The Tesla app provided absolutely no resistance, and technically no privilege escalation is required to steal the relevant data. Your screen reader app, or custom keyboard has the relevant access.
>Promon engineers recommend that the Tesla app provide two-factor authentication, should avoid storing the OAuth token in cleartext, prevent easy access to its source code, and use a custom keyboard layout when entering passwords to fight against mobile keyloggers.
We did not recommend this, however the OAuth token should not be in clear text.
> however the OAuth token should not be in clear text.
How would you suggest to store it in a way that prevents someone with root access to the phone from reading it? Any encryption keys stored by the application would surely be just as easily readable by root, right?
How would you suggest to store it in a way that prevents someone with root access to the phone from reading it? Any encryption keys stored by the application would surely be just as easily readable by root, right?
you know that storing OAuth token in anyway (encrypted etc) doesnt change anything right?
for screen readers and custom keyboards, thats why OS warns you with a really scary notice, that keyboard can read your passwords.
I dont think you can read OAuth token without priviledge escalation btw.
for screen readers and custom keyboards, thats why OS warns you with a really scary notice, that keyboard can read your passwords.
I dont think you can read OAuth token without priviledge escalation btw.
>and use a custom keyboard layout when entering passwords to fight against mobile keyloggers.
mobile keylogger ?
is that a thing ?
AFAIK, the only way to access keyboard input on Android is to be the Active keyboard. Now that I think about it, maybe that accessibility services can too (not sure about that one).
Both need the approval of the user. I have no doubt that some users click yes without reading the warnings though.
mobile keylogger ?
is that a thing ?
AFAIK, the only way to access keyboard input on Android is to be the Active keyboard. Now that I think about it, maybe that accessibility services can too (not sure about that one).
Both need the approval of the user. I have no doubt that some users click yes without reading the warnings though.
This blog post does contain those recommendations:
https://promon.co/blog/tesla-cars-can-be-stolen-by-hacking-t...
Near the bottom, it says:
The app should provide its own keyboard for entering the username and password. Otherwise, malicious third party keyboards can act as keyloggers to obtain the user’s credentials.
And:
The app should be protected against reverse engineering.
https://promon.co/blog/tesla-cars-can-be-stolen-by-hacking-t...
Near the bottom, it says:
The app should provide its own keyboard for entering the username and password. Otherwise, malicious third party keyboards can act as keyloggers to obtain the user’s credentials.
And:
The app should be protected against reverse engineering.
> The app should provide its own keyboard for entering the username and password. Otherwise, malicious third party keyboards can act as keyloggers to obtain the user’s credentials.
This doesn't really help, if the attacker already has root on the device they can simply hook the login or key entry function in the application. They can also just screenshot on tap when the app is launched (though that's the lame way).
> The app should be protected against reverse engineering.
There's no such thing, I hate when people say things like this. If you rely on protections against reverse engineering, you rely on half-measures.
A determined reverser will always break your app. It might take minutes or days, but it'll always happen and they only need to break it once for it to be broken for everyone.
Ultimately this is a phone security issue. Don't download and run untrustworthy code, doubly so if your ROM is out of date and vulnerable.
As the immutable law of security says: If someone has root on your device, it's not your device anymore!
This doesn't really help, if the attacker already has root on the device they can simply hook the login or key entry function in the application. They can also just screenshot on tap when the app is launched (though that's the lame way).
> The app should be protected against reverse engineering.
There's no such thing, I hate when people say things like this. If you rely on protections against reverse engineering, you rely on half-measures.
A determined reverser will always break your app. It might take minutes or days, but it'll always happen and they only need to break it once for it to be broken for everyone.
Ultimately this is a phone security issue. Don't download and run untrustworthy code, doubly so if your ROM is out of date and vulnerable.
As the immutable law of security says: If someone has root on your device, it's not your device anymore!
if the attacker has root on the device, he can do absolutely everything he wants with it.
I don't think any app can do anything at that point.
Do other car companies allow cars to be controlled via an Android app? Some people might see that as a feature, but to me that seems like a pretty bad product decision precisely because Android is so vulnerable.
> An attacker can read this token if he has access to the user's phone.
> the app will prompt the user to enter his password again, providing the perfect opportunity to collect the user's password. Attackers also modify the Tesla app's source code to steal login data
Come on, if an attacker has access to an unlocked phone there are far more valuable targets than a "connected car" that can possibly be remote disabled any time.
The chain of dependencies outlined in the article is borderline ridiculous.
> the app will prompt the user to enter his password again, providing the perfect opportunity to collect the user's password. Attackers also modify the Tesla app's source code to steal login data
Come on, if an attacker has access to an unlocked phone there are far more valuable targets than a "connected car" that can possibly be remote disabled any time.
The chain of dependencies outlined in the article is borderline ridiculous.
At the end of the day, a username and password is everything you need to drive off with any app enabled Tesla.
You can perform your attack in a number of different ways to achieve this, but setting up a free wifi hotspot near a Tesla super charger allows you to target and harvest several such usernames and passwords with very little effort.
Disclaimer: I work for Promon. Feel free to ask me about the attack.
You can perform your attack in a number of different ways to achieve this, but setting up a free wifi hotspot near a Tesla super charger allows you to target and harvest several such usernames and passwords with very little effort.
Disclaimer: I work for Promon. Feel free to ask me about the attack.
Well a username and password would let anyone into your primary email account possibly letting them steal your identity and money from your bank account which is again potentially more harmful than stealing a connected car
Are you performing an MITM attack from the WIFI hotspot?
Are you performing an MITM attack from the WIFI hotspot?
Yes, in our case we did MITM to display ads for a "free burger" app containing malware. The app was hosted on Google Play.
And, you're right. Once we have access to the phone we can probably do a lot worse than just stealing a car.
When it comes to banking apps, they often have mitigations which would require a lot more targeted effort.
And, you're right. Once we have access to the phone we can probably do a lot worse than just stealing a car.
When it comes to banking apps, they often have mitigations which would require a lot more targeted effort.
If I may, I am a bit perplexed by:
>Promon engineers recommend that the Tesla app provide two-factor authentication, should avoid storing the OAuth token in cleartext, prevent easy access to its source code, and use a custom keyboard layout when entering passwords to fight against mobile keyloggers.
Security by obscurity?
>Promon engineers recommend that the Tesla app provide two-factor authentication, should avoid storing the OAuth token in cleartext, prevent easy access to its source code, and use a custom keyboard layout when entering passwords to fight against mobile keyloggers.
Security by obscurity?
I'm not sure where this quote came from, but I can say that the Tesla app should avoid storing the OAuth token in cleartext.
Disclaimer: I work for Promon. See our blog post: https://promon.co/blog/
Disclaimer: I work for Promon. See our blog post: https://promon.co/blog/
The quoted text is the last sentence in the article this thread is about:
http://www.bleepingcomputer.com/news/security/android-malwar...
If the Author of the bleepingcomputer.com article has misunderstood your findings and conclusions and is reporting as yours something you didn't recommend, you should let him know and ask for a correction.
http://www.bleepingcomputer.com/news/security/android-malwar...
If the Author of the bleepingcomputer.com article has misunderstood your findings and conclusions and is reporting as yours something you didn't recommend, you should let him know and ask for a correction.
> I can say that the Tesla app should avoid storing the OAuth token in cleartext.
Why? What additional security would encrypting it with a key that's on the same device give you?
Why? What additional security would encrypting it with a key that's on the same device give you?
A Tesla model S is worth > $50k unless its been in an accident or otherwise damaged. What more valuable thing could someone possibly steal with access to my cell phone?
You can remotely kill someone with a tesla.
The Tesla Android app (there is a new version coming out soon to replace the very dated Android and iOS versions) stores its oauth credentials in plain text in the Tesla app folder. So in order for this to work:
1. User must enable the installation of apps from unknown sources.
2. User must then find and install malicious app.
3. Malicious app must then try and root phone in order to be able to read the oauth credentials stored in the Tesla app folder.
4. And finally, user must own a Tesla.
Chances of this ever happening in the real world: Zero.
1. User must enable the installation of apps from unknown sources.
2. User must then find and install malicious app.
3. Malicious app must then try and root phone in order to be able to read the oauth credentials stored in the Tesla app folder.
4. And finally, user must own a Tesla.
Chances of this ever happening in the real world: Zero.
> Chances of this ever happening in the real world: Zero
I dunno. I've seen more than one person get caught by setting up their phone for development (1), getting suckered into installing some mal-ware laden game (2)... 3 and 4 don't seem _like_ that much of a stretch in the valley.
I dunno. I've seen more than one person get caught by setting up their phone for development (1), getting suckered into installing some mal-ware laden game (2)... 3 and 4 don't seem _like_ that much of a stretch in the valley.
1. The free burger malware was hosted from Google Play
2. The attack was performed at a restaurant near a Tesla super charger, offering a free Wifi which pushed the Google Play link as ads.
3. The app must not root the phone, but this is pretty straight forward.
4. Pretty likely near a Tesla super charger.
> Chances of this ever happening in the real world: Zero.
We certainly hope so.
We're raising awareness of IoT app security. Read our blog for the original technical details: https://promon.co/blog/
2. The attack was performed at a restaurant near a Tesla super charger, offering a free Wifi which pushed the Google Play link as ads.
3. The app must not root the phone, but this is pretty straight forward.
4. Pretty likely near a Tesla super charger.
> Chances of this ever happening in the real world: Zero.
We certainly hope so.
We're raising awareness of IoT app security. Read our blog for the original technical details: https://promon.co/blog/
The number of things that must work correctly in your scenario are so unrealistic that I would still say the odds are near zero. If someone wants a Tesla they'll do it the easy way and use a flatbed truck.
The malicious app also needs to be undetected by Google.
So it cannot use a root method detected by Play Services apk analyser.
It is definitely doable .. but yeah, not really a credible threat at scale.
Or, maybe:
1. The thief saw the target (Tesla owner) have an Android phone
2. The thief somehow arranges to have couple of minutes with target's phone (with some sort of social engineering) and installs necessary software.
Chances of this ever happening in the real world: not zero.
1. The thief saw the target (Tesla owner) have an Android phone
2. The thief somehow arranges to have couple of minutes with target's phone (with some sort of social engineering) and installs necessary software.
Chances of this ever happening in the real world: not zero.
Why have a drive train that can "talk" or take commands from a phone at all? One would think that an air gap or air wall will be would be job one.
That's quite a bright line to draw, especially given that so few cars are air-gapped today (remote keyless ignition has been widely available since the 1990s).
Moreover, auto theft was a thing long before computers were.
Moreover, auto theft was a thing long before computers were.
This sort of attack should not be possible. What sort of sandbox sits on disk unencrypted (regardless of its contents)?! That's not a sandbox, it's just a directory. Android is an abomination.
"Android app saves OAuth token in cleartext"
Sheesh.
Sheesh.
I'm not sure that "sheesh" is an appropriate response.
It's perfectly valid for an app to reply on the security of its own storage space, and isolation from other apps, and drive encryption services of the platform. These are the guarantees provided by the underlying OS, and if they are broken, all bets are off.
And what would you do differently? Any effort you put in here is going to cost you complexity and only likely provide security through obscurity. Fundamentally, the app has the authority to unlock and start the car. And a root exploit fundamentally has power over the app. This doesn't change even if you put the "key" material into hardware storage. Or maybe you could add an in-app password to encrypt the Tesla password? This is nasty UX, and the root exploit can still wait around for a moment when the password is provided.
If there's any take away here, it is regarding Android. If you want a secure Android phone, choose it carefully. Very few Android phones keep up with the Google automatic security patch schedule. You may want one that does, such as a Pixel.
It's perfectly valid for an app to reply on the security of its own storage space, and isolation from other apps, and drive encryption services of the platform. These are the guarantees provided by the underlying OS, and if they are broken, all bets are off.
And what would you do differently? Any effort you put in here is going to cost you complexity and only likely provide security through obscurity. Fundamentally, the app has the authority to unlock and start the car. And a root exploit fundamentally has power over the app. This doesn't change even if you put the "key" material into hardware storage. Or maybe you could add an in-app password to encrypt the Tesla password? This is nasty UX, and the root exploit can still wait around for a moment when the password is provided.
If there's any take away here, it is regarding Android. If you want a secure Android phone, choose it carefully. Very few Android phones keep up with the Google automatic security patch schedule. You may want one that does, such as a Pixel.
That's a reasonable reply. I think my comment was hasty, made after skimming the article and not thinking about it too deeply.
Yeah, they should encrypt the token. They should encrypt the encryption key as well. But the key to decrypt the encryption key is OK to store in plaintext, because by that point attackers will have lost interest.
I think it's happening a lot more than you'd expect:
http://www.bleepingcomputer.com/news/security/over-one-billi...
Self-driving cars are going to be so much "fun" - for hackers.
http://www.bleepingcomputer.com/news/security/over-one-billi...
Self-driving cars are going to be so much "fun" - for hackers.
You are right, if the security sandbox is broken, then you have lost control.
But at the same time, you also know that only 0.3% of the Android user base is using this year's version, and less than 25% are using last year's version.
The security design of the app should reflect this.
But at the same time, you also know that only 0.3% of the Android user base is using this year's version, and less than 25% are using last year's version.
The security design of the app should reflect this.
Out of curiosity doesn't this just mean the user access token and user access secret are in plaintext? Aren't those useless without the app token/secret -- so if the app is encrypted and you can't run strings to get those your only vector of attack is still through the app itself right? I'm not a security expert.
[deleted]
Has anyone tried to "Poison Tap" a Tesla?
http://www.valuewalk.com/2016/11/poison-tap-5-usb-hijack-loc...
http://www.valuewalk.com/2016/11/poison-tap-5-usb-hijack-loc...
Tesla clearly has no fault here.
so basically:
- you need to download an malicious app - your phone has to have some security bug to bypass 'sandbox' via some root privilidges
I can understand if you blame google for android, or user for downloading app. But after this chain, there is virtually no app you cannot hack.
>Promon engineers recommend that the Tesla app provide two-factor authentication, should avoid storing the OAuth token in cleartext, prevent easy access to its source code, and use a custom keyboard layout when entering passwords to fight against mobile keyloggers.
btw none of these suggestions preventing anything if you have the conditions above, suggests me they have no idea what they are talking about