This post was written by Christiaan Beek, Jesse Michael, Raj Samani, and Mickey Shkatov.
Sometime in the distant past, that thing in your driveway was a car. According to Intel however, the “connected car is already the third-fastest growing technological device after phones and tablets.” The days when a Haynes manual, a tool kit, and a free afternoon/week to work on the car are fast becoming a distant memory.
Our connected cars today generate up to 4,000GB of data per 50Kb every second and using on-board cameras generates 20MB to 40MB per second. Not only do these devices generate significant data, but there are so many connectivity options with the cars we use each day. With the continuing introduction of more connected features to cars, and our dependency on connected cars only increasing, a key part of the focus within our Advanced Threats Research team has been to consider the possible attack vectors in automotive.
2016: the year of ransomware
It seems that every year is the year of ransomware! In 2016, however, the reality of ransomware on IoT was demonstrated following research the team did in identifying a vulnerability within a popular In Vehicle Infotainment (IVI) system: we were able to insert ransomware over the air. In our demonstration the payload was not malicious, of course. Well perhaps it was since a very popular 80s song would be played at full volume until the victim paid up!
This demonstrated that the nightmare scenario so often talked about in which you were unable to start your car without paying criminals is indeed something quite possible, but thankfully to date not witnessed in the wild.
DEFCON 2017
So with this year at DEFCON our ATR team, in particular Oleksandr Bazhaniuk, Jesse Michael, and Mickey Shkatov work continued their focus into automotive. The start into the research was not particularly auspicious however, with a trip to the wreckers yard in search for hardware that ended up with a car full of loot!
The dashboard was reconstructed in our US Lab.
After fixing some errors, the unit was ready. Since we already worked on an IVI, the on-board IVI looked interesting but after some research we determined it would be quite some work to get into that area. By researching the system’s diagnostic info, we might be successful in retrieving useful data from the navigation system, SRAM and Flash dumps. In one of the dumps, the team discovered a possibly interesting URL, which was referring to a domain owned by a car-manufacturer. After researching the WHOIS credentials of the domain, we discovered that nobody owned it any longer. The team quickly registered the domain and setup generic honeypot to capture any incoming connections of any sort that were sent to the domain.
To our surprise, we had several connection attempts registered with information about the geographic location of the cars, and if the car was currently set to navigate to a particular waypoint, we received the GPS coordinates of that waypoint as well as the name of the waypoint.
After responsibly disclosing this issue in February 2017 to the car manufacturer, a fix for the owners has since been released.
Telematics
We presented these findings during the DEFCON conference this year, and other findings about a Telematics Control Unit (TCU) used in multiple cars across at least four car manufacturers as far as we can confirm. What is a telematics unit? A telematics unit is used by the vehicle to have a connection to the outside world, be it the internet or a manufacturer specific intranet site.
These units are used as a conduit for the car to connect to the backend. This particular telematics unit was using 2G cellular connectivity technology. Investigating the circuit board for interesting components, the team researched the USB interaction by placing an USB sniffer as a ‘Man-in-the-middle’ to learn about the traffic interactions. What data was being exchanged between the IVI and the modem potentially being shared with outgoing connections.
After more researching and testing, the team found locally exploitable classic buffer overflow vulnerabilities. More and more were discovered, including a known over the air telematics vulnerability discovered by Dr. Ralf-Philipp Weinmann (CVE-2010-3832) using a buffer overflow. After we used one of the local vulnerabilities to write an exploit and extract the baseband firmware of the telematics unit we started our work on reverse engineering the code to see if we could send arbitrary Controller Area Network (CAN bus) messages from the TCU.
We followed again our responsible disclose process and informed the involved parties, including US-CERT. After studying our submission of the findings, US CERT released an advisory on Thursday, the first day of DEFCON, allowing us the time to study it and reference it and any mitigations mentioned in it during our talk on Saturday.
Update
Since the initial notification to Nissan and BMW we have been advised that a free fix via a Technical Service Bulletin has been issued to their dealers, which is available now to all affected customers in U.S. and Canada.
Through the process of coordinating this disclosure via ICS-CERT, we additionally discovered that a small number of other vehicles were also affected by these issues. We will update this blog as more data becomes available.
Stay up to date on this story and follow @McAfee and @McAfee_Business.
The post DEFCON – Connected Car Security appeared first on McAfee Blogs.