Fortunately with the update bundles signed they'd still have to find an approach to get into the system in the first place to replace the firmware on modules aside from hacking Tesla's servers that hold the signed updates.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Security from the frontlines... (OR How to Hack A Model S talk at DEFCON)
- Thread starter W.Petefish
- Start date
Fortunately with the update bundles signed they'd still have to find an approach to get into the system in the first place to replace the firmware on modules aside from hacking Tesla's servers that hold the signed updates.
I'm leaving out the case where they compromise Tesla's servers.
The question is where on the car the signature validation is done. If it's done on the touchscreen - the attackers had root. They simply bypass the Tesla bundle validation checks and download/directly push their own unverified firmware to the unsecured module(s) using the same method Tesla does.
From this thread:
Successful connection on the Model S internal Ethernet network - Page 21
...there's an interesting snippet that suggests the .102 IP address on the bus (the gateway) may handle the elements of firmware push (at least I see filenames there that would indicate charger and battery management firmware being updated). So then you have to look at where the bundle signature validation is taking place and how the touchscreen (which handles the networking) gets the firmware updates to the gateway - does the touchscreen push the entire large firmware bundle, meaning you'd have to compromise the gateway to bypass signature checks? or does it unbundle on the touchscreen and start handing individual component firmware images to the gateway to start applying to modules, in which case you might be able to bypass the bundle signature checks, fetch your own module firmware, and make the TPMS module do what you want to do?
jvonbokel
John VonBokel
I think they disabled the one open port that was discovered, but the researchers appear to have used the port that the instrument cluster connects through.
Well, I think the compromised servers is part of what was referred to regarding unsigned updates.
As for the internal layout, I'm pretty sure the "gateway" is just a small processor that is physically part of the MCU housing. I'm not sure exactly the specs on it, but I've checked out data dumped from various flash chips and an SD card on the gateway and MCU. I'm reasonably certain the actual update process is handled by the gateway but the firmware package is downloaded by or via the MCU (which has internet access). It would make sense for the gateway to verify the signature in this case.
However the gateway would need to communicate with the other modules to update their firmware. I'm doubtful there is signature verification at this level.
Right, and that's the attack vector that is getting the most attention right now from embedded systems attackers -- the USB controller chip hacks, the HD firmware hacks, etc. are all relying upon insecure firmware updates that can easily hide information. The question I ask is - if you can gain root on the touchscreen (say, via the WebKit attack vector mentioned), could that turn into compromise of the drivetrain via arbitrary CANbus messages?
A lot of the talk today is about how Tesla walls off the MCU from the drivetrain... but I can see how you might circumvent that by researching some of the modules and pushing your own firmware to that module that would give you the ability to send to the CANbus -- IF you can get past Tesla's bundle signature checks. You might be able to accomplish that with root on the touchscreen if the conditions are right (if the MCU unbundles the firmware and does the signature checking).
I surely hope it's not the MCU that's doing the unbundling of firmware and validation of signatures -- I hope it's via a separate, dedicated processor (a/k/a "the gateway") on which it is far more difficult to acquire superuser.
As far as I could tell in testing with a salvage vehicle was that the MCU has no CAN access. Everything you do on the MCU that could affect anything with the drive system or anything important was sent as a request to the gateway, which appears to handle the CAN communication. I have no idea what the criteria the gateway has for honoring these requests, but it would stand to reason that hacking the MCU would at most just get you ethernet comm with the gateway, which can already be done physically if you feel like removing the dash.
Ahh, but the MCU *could* have CAN access if it used the software update mechanism to reach the CAN bus, and I'm offering how you do it if you can compromise the MCU remotely.
Let's assume the following scenario:
The attacker learns that a module (let's just say TPMS) is made by ABC Corp. and does not use validated or signed firmware from ABC Corp. The attacker learns about the microcontroller and its CANbus connection, and disassembles the firmware to learn what it does and the messages it sends. He formulates a new firmware that - instead of accepting firmware image update commands and dropping to the bootloader to update - instead uses information inside a fake image to send arbitrary CANbus messages.
Okay, so now he needs to get this firmware onto the TPMS module.
Let's assume for a moment that Model S does signature validation on the MCU - that's easier for an attacker to work with. The attacker gains superuser access, downloads his special TPMS firmware onto the MCU, and pushes it via the gateway to the firmware updater, just as Tesla would do. It's not subject to Tesla's bundle signature or server source requirement because he already has superuser access and are pushing the individual image via the gateway (bypassing Tesla's unbundling and validation checks). The gateway happily pushes the attacker's new firmware to the TPMS module. As the module's firmware updates are insecure (unsigned / unvalidated from ABC Corp.), it happily installs the new code onto the TPMS module and restarts it. Meanwhile, the attacker installs a trojan that actively makes a connection out to a command & control server.
Now, the attacker wants to send an arbitrary CANbus message. From the command & control server he sends a packet containing whatever magic he needs, along with the arbitrary CANbus command he wants to execute. The trojan on the MCU receives that, then formulates a special firmware image update and sends it to the gateway. To the gateway, it appears that there's another image upgrade to the TPMS module. The TPMS module's special attacking firmware ignores the whole image update process and instead takes the firmware update (a cloaked CANbus message), and dumps it onto the CANbus.
This is the easiest scenario to imagine. It's foiled with a number of different architectural components:
First, if the "gateway" functionality is what does the unbundling and signature validation, having superuser access on the MCU doesn't accomplish anything because you won't be able to send a properly-signed bundle to the "gateway". But it's unclear whether Tesla handles signature validation on the MCU (which would render it vulnerable) or on the gateway.
Second, Tesla could always layer insecure/unsigned module updates in its own signature wrapper that is confirmed by the gateway - like the first case, it would take away the ability for the attacker to sign the firmware update and it would be ignored, not pushed by the gateway.
Third, the gateway could always refuse to update firmware on modules unless the car was in update mode. The gateway would reject any image update messages if the car was deemed to be "active" in any way, and this would eliminate the vector. (That said, it would still be vulnerable to an attack whereby the hacked TPMS code stores the CANbus message to be dumped onto the bus at a later time when the car is active.)
Fourth, Tesla could insist all module suppliers sign and validate firmware updates in their modules as a condition for being a supplier.
Fifth, Tesla could sign and validate CANbus messages so that the TPMS couldn't inject a "hit the brakes hard" message.
- - - Updated - - -
EDIT: The bottom line is that there is a way to connect through the systems to get a message to the CANbus, if one works hard enough.
In addition to the much praised wireless firmware updates from Tesla, their supercharger infrastructure is unique, and the supercharger unit is doing at least some kind of communication with the car (to determine battery state and whatever).
So let's say that Tesla becomes aware that their wireless firmware updates can be compromised (via a man-in-the-middle attack or whatever these clever but bad people can come up with).
Then, if Tesla were able to push out firmware updates via the supercharger unit (that they are in control of), then they could
1) send out a general message (via their website or snail mail or whatever) instructing Tesla owners to switch off the wireless antenna of their car, and
2) instruct the Tesla owner to go to a supercharger station and connect - and get the firmware update via the cabled connection there,
3) Optionally, once the firmware installation is complete, it could instruct the Tesla owner to re-activate the wireless antenna.
I would not be surprised if a software company like Tesla had thought about using their supercharger infrastructure as a trusted connection to the Tesla vehicles.
Since this is pure speculation on my part, I would be curious if anyone actually knows about this.
The gateway is a 32bit freescale microcontroller. It resides in the same box as the MCU (touchscreen), but is otherwise totally separate. It's connected via Ethernet to the Tegra3 Linux box, and it has access to all the cars CAN and LIN buses. When Tesla sends an update, the Linux box downloads the bundle only from Tesla's servers and only from over the VPN. Once downloaded it verifies the bundle and if it's valid, sends it to the gateway as a tarball. (and of course updates itself and the IC via ethernet) The tarball has firmware for all the cars various embedded systems and is fully CRC32'd. If you were to gain access to the gateway, you could most definitely compromise the other systems, but it's unlikely without physical access.
The gateway also stores information unique to each car, such as the VIN and the VPN keys, so if an attacker had these they could impersonate the car, but not the other way around without Tesla's private key (asymmetrical crypto). If you impersonate the car probably the worst you could do is grab firmware tarballs.
The gateway also stores information unique to each car, such as the VIN and the VPN keys, so if an attacker had these they could impersonate the car, but not the other way around without Tesla's private key (asymmetrical crypto). If you impersonate the car probably the worst you could do is grab firmware tarballs.
Can you help me understand what you mean by "fully CRC32'ed"? Since that's just a data verification function, it seems a malicious attacker with control of the MCU untar it, make his own bundle with his own compromised firmware, perform the CRC32 calcs to make the check work, then export that to the gateway? Or is it more than CRC32, and the tarball is signed crypotgraphically, so that the gateway validates it and the MCU couldn't modify it?
(I'm amazed at the level of detail you know about the makeup of the system.)
The CRC32 is an integrity thing, not a security feature. The Gateway is secured such that you don't have access to it. (at least not anymore after 2.5.21 supposedly) Tesla has also closed the trick used to gain control of the MCU, so you'd have to get past that fix too.
Again, with physical access you can probably manipulate these things, but we're talking a complete remote hack of some sort, which was only theorized in any event.
I'm at DEFCON and going to see the presentation tomorrow. I'll report back.
Again, with physical access you can probably manipulate these things, but we're talking a complete remote hack of some sort, which was only theorized in any event.
I'm at DEFCON and going to see the presentation tomorrow. I'll report back.
Does the firmware get pushed to the gateway at time of install or as soon as the download has been verified and then it gets queued? Any idea as to how one could hypothetically clear a downloaded update from memory and then reload it at a later time?
Johan
Ex got M3 in the divorce, waiting for EU Model Y!
Reading this thread makes me think back to the early days of firmware 4.xx.... Oh, that would have been like the Wild West in the early 19th century: Acres upon acres of untouched green pastures (for hackers that is).
Right (integrity vs. security) - so this means that if you had control of the MCU, you could (at least based on this information) bypass Tesla's bundle signatures, roll your own tarball including your hacked TPMS code (see example earlier), generate proper CRC hashes for it, then send it to the gateway and have it installed on the module for use later.
Looking forward to hearing what they learned in more detail.
Blog is up:
Hacking a Tesla Model S: What we found and what we learned | Lookout Blog
---update---
Kind of disappointed. Was really looking forward to the tool they were going to release to let us get access to all to this diagnostic info. Turns out it's just a fancy UDP capture tool and the exploits have already been patched rendering it useless. Not to mention I'd have to dismantle the MCU to rip the VPN keys off the flash memory since they didn't bother to release those either.
Hacking a Tesla Model S: What we found and what we learned | Lookout Blog
---update---
Kind of disappointed. Was really looking forward to the tool they were going to release to let us get access to all to this diagnostic info. Turns out it's just a fancy UDP capture tool and the exploits have already been patched rendering it useless. Not to mention I'd have to dismantle the MCU to rip the VPN keys off the flash memory since they didn't bother to release those either.
Last edited:
This was great:
Tesla engineers are Monty Python fans: there is a script in the car which makes a request to hxxp://firmware-bundles.vn.teslamotors.com:4567/custom-packages/knights-who-say. The response body contains thousands of lines of the word “ni”
Tesla engineers are Monty Python fans: there is a script in the car which makes a request to hxxp://firmware-bundles.vn.teslamotors.com:4567/custom-packages/knights-who-say. The response body contains thousands of lines of the word “ni”
Similar threads
