Android Malware Used to Hack and Steal a Tesla Car
bleepingcomputer.com
bleepingcomputer.com
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
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.
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.
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?
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.
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.
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.
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!
> 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.
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.
>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?
Disclaimer: I work for Promon. See our blog post: https://promon.co/blog/
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.
Why? What additional security would encrypting it with a key that's on the same device give you?
Are you performing an MITM attack from the WIFI hotspot?
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.
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.
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.
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/
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.
Moreover, auto theft was a thing long before computers were.
Sheesh.
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.
http://www.bleepingcomputer.com/news/security/over-one-billi...
Self-driving cars are going to be so much "fun" - for hackers.
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.
http://www.valuewalk.com/2016/11/poison-tap-5-usb-hijack-loc...