BHUSA2017: Free-Fall: Tesla Hacking 2016: Hacking Tesla from Wireless to CAN Bus

This is their first time going through all of the remote attacks on the Tesla in public. In September 2016 they successfully implemented a remote attack against the Tesla without physical access to the car.

There was an OLD WebKit used in QtCarBrowser on Tesla. Tesla car automatically scan and connect to known SSIDs, has a "tesla guest" with password abcd123456 in Body shop and Supercharger. QtCarBrowser will automatically reload its current webpage and trigger their webkit exploit.  In Cellular mode they can target phising and mistyped URLs.

Tesla has since patched all of the vulnerabilities found by KeenLab. They had attacked a vuln in JSArray::sort(compareFunction).  They could use this to leak some addresses. They took advantage of type confusion and an overlap in array storage. They shifted the array one time in the compareFunction, copy backed into JSC::JSArray::sort() and then unshif TWICE to trigger increaseVectorPrefixLength() and fastFree arbitrary address (palyload of JSValue-A).

Took advantage of powerful CVE-2011-3928 for leak, with corrupted HTMLInputElement structure.. Arbitrary address READ/WRITE to leak JSCell address of Uint32Array, got address of Uint32Array from JSCell, fastFree the address and defined a new Uint32Array to achieve AAR/RRW.

Finally they got a shell from the browser, but was a low privelge account (browser uid=2222), so they needed to elevate their privilege. The kernel was very old, so there were many well known kernel attacks - were able to fully dump the kernel with a corrupted syscall entry in syscall table.

A brief introduction of the gateway (gw/gtw): it's a powerPC chip running RTOS (most likely FreeRTOS), and SDCard. They were able to get their own code on the firmware. Can do this during an ECU Upgrade (the details are fuzzy here, as the slides moved by really fast). Best - trigger the ECU upgrade by giving a command to the gw (0x08 - update trigger) and get your own boot image loaded and get it to run with taskUpdate.


They sent messages then to other ECUs, including the CAN bus using diagnosis (though the ability to do this is limited when the car is in drive mode). But, can work around this by swapping the handlers.  Still, some ECUs will not respond at all under drive mode. Some ECUs will notice the speed and disable dangerous functions if necessary. They then focused on the forwarding table to block the forwarding process.  Could use the UDS to unlock the ECU, because the seed/key for security access to ECU is fixed


They were able to get access with 3G/Wi-FI, exploit a webKit Brwoser, root the in-vehicle systems, patch and disable appArmor, bypass ECUs firmware integrity verification, reprogram and do dangerous things while the car was driving. Tesla was very responsive and appreciative about the disclosure and fixed the issues in 10 days. Browser security enhancements, firmeware improvements also came out at the same time.  there are now more restictive AppArmor rules (Yes, Tesla uses AppArmor instead of SELinux) and restricted where you can run executibles and where you can write files.

Improved kernel security with all patches and setting CONF-G_SPU_SW_DOMAIN_PAN=Y, NORMAL KERNEL ACCESSES ARE UNABLE TO ACCESS USERSPACE ADDRESSES.

Additionally added code signing everywhere, to protect the ECU, but found some issues due to ECU not being able to verify signature itself. Reported issues to Tesla in the end of June 2017 and all cars have the fixes by July 2017.

Cool video demonstrating the results. Apparently they had to use all of their hacks to do a fun music show with headlights going on and off (single lamp at a time) and doors opening and shutting.

UPDATE: now with the fun video!