7 ms·

Android Malware Used to Hack and Steal a Tesla Car

68 points by SCAQTony 10y ago

leephillips 10y ago
"Android app saves OAuth token in cleartext" Sheesh.
- mtgx 10y ago
  I think it's happening a lot more than you'd expect: http://www.bleepingcomputer.com/news/security/over-one-billion-android-users-susceptible-to-app-hijacking-via-oauth-2-0-attack/ http://www.bleepingcomputer.com/news/security/over-one-billi... Self-driving cars are going to be so much "fun" - for hackers.
  - janvidar 10y ago
    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.
- scarybeast 10y ago
  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.
  - leephillips 10y ago
    That's a reasonable reply. I think my comment was hasty, made after skimming the article and not thinking about it too deeply.
- sowbug 10y ago
  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.
- ranman 10y ago
  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.
sfifs 10y ago
> 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.
- janvidar 10y ago
  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.
  - sfifs 10y ago
    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?
    - janvidar 10y ago
      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.
  - jaclaz 10y ago
    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?
stcredzero 10y ago
Has anyone tried to "Poison Tap" a Tesla? http://www.valuewalk.com/2016/11/poison-tap-5-usb-hijack-locked-computer/ http://www.valuewalk.com/2016/11/poison-tap-5-usb-hijack-loc...
bluesign 10y ago
I hate when people use some brands publicity to promote themselves. 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
- obastani 10y ago
  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.
  - bluesign 10y ago
    if you mean by control, unlock, tracking etc, I am sure BMW supports.
  - izacus 10y ago
    Yes, most major companies support mobile start with both ios and android apps.
- janvidar 10y ago
  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.
bitmapbrother 10y ago
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.
- janvidar 10y ago
  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/ https://promon.co/blog/
  - bitmapbrother 10y ago
    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.
- barclay 10y ago
  > 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.
- apetrovic 10y ago
  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.
SCAQTony 10y ago
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.
- sowbug 10y ago
  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.
deleted 10y ago
[deleted]
huslage 10y ago
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.

68 points by SCAQTony 10y ago

leephillips 10y ago

"Android app saves OAuth token in cleartext" Sheesh.

mtgx 10y ago
I think it's happening a lot more than you'd expect: http://www.bleepingcomputer.com/news/security/over-one-billion-android-users-susceptible-to-app-hijacking-via-oauth-2-0-attack/ http://www.bleepingcomputer.com/news/security/over-one-billi... Self-driving cars are going to be so much "fun" - for hackers.
- janvidar 10y ago
  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.
scarybeast 10y ago
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.
- leephillips 10y ago
  That's a reasonable reply. I think my comment was hasty, made after skimming the article and not thinking about it too deeply.
sowbug 10y ago
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.
ranman 10y ago
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.

sfifs 10y ago

> 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.

janvidar 10y ago
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.
- sfifs 10y ago
  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?
  - janvidar 10y ago
    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.
- jaclaz 10y ago
  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?

stcredzero 10y ago

Has anyone tried to "Poison Tap" a Tesla? http://www.valuewalk.com/2016/11/poison-tap-5-usb-hijack-locked-computer/ http://www.valuewalk.com/2016/11/poison-tap-5-usb-hijack-loc...

bluesign 10y ago

I hate when people use some brands publicity to promote themselves. 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

obastani 10y ago
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.
- bluesign 10y ago
  if you mean by control, unlock, tracking etc, I am sure BMW supports.
- izacus 10y ago
  Yes, most major companies support mobile start with both ios and android apps.
janvidar 10y ago
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.

bitmapbrother 10y ago

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.

janvidar 10y ago
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/ https://promon.co/blog/
- bitmapbrother 10y ago
  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.
barclay 10y ago
> 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.
apetrovic 10y ago
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.

SCAQTony 10y ago

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.

sowbug 10y ago
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.

deleted 10y ago

[deleted]

huslage 10y ago

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.