Posts Tagged ‘security’

Different approaches towards the (fully) automated car

Google Chauffeur patent - source: Reilly Brennan

Google Chauffeur patent – source: Reilly Brennan

The race towards the fully automated car has only just begun. Car makers and their new potential competitors from the Tech industry have different views on the best approach for a driverless future.

While car OEMs like BMW or Daimler (and even newcomers like Tesla) are adding more and more driver assistance features such as lane-departure warning, brake assist, traffic jam assist, or parking pilot, in order to increase automation step by step over the next years, Tech industry companies like Google think of “leap-frogging” to as much automation as possible.

There are good reasons for both approaches. The classic step-by-step approach is very much in line with technology development and refinement, and with the slow moving other stakeholders such as governments and insurances. Ultimately a fully autonomous car would challenge the existing regulations and insurance schemes intensively, bringing up many unsolved issues of liability. What happens, for example, if a malfunctioning autonomous car hits a pedestrian? Driver or car maker liability?

The fully autonomous car, though, has the potential to be much safer than a car steered by a human, so naturally there is some incentive to go to as many automated functions as fast as possible. Especially as there are some indications that drivers in a only partly-automated car might be too slow to take over control in a situation that the partial automation cannot handle. As Chris Urmson, Head of Google’s Self Driving Car program, said in a recent article: “The better the technology gets, the less reliable the driver is going to get.”


Depending on the level of automation and intensity of alert, some drivers took an average of 17 seconds to respond to a takeover request and regain control of the vehicle, in a study just released by the National Highway Traffic Safety Administration and supported by Google and several leading automakers and suppliers. In that time, a car traveling at 60 miles per hour would travel more than a quarter of a mile.
Automakers, Google take different roads to automated cars


The current state of the Android ecosystem

If you are about to launch a new app or service for mobile devices, doing that for Android is kind of a double-edged sword. On the one hand, you can access a vast community of users based on the sheer number of Android installations world-wide. On the other hand, this massive amount of users are not running a homogeneous Android base or devices. Vast differences in performance, screen size, installed Android version, and more,  makes it extremely difficult for developers to fully exploit the potential of the platform.

In addition, there is always a latent security risk of having devices running old and outdated versions of Android. A very prominent – and extremely severe – example has just happened with the Stagefright bug, allowing an attacker to get control of the Android device by simply sending a multimedia text message to the target. This vulnerability concerns millions of Android devices in the market, which haven’t received an appropriate security update. However, due to the nature of the Android update process – an update is developed by Google and given to the handset manufacturers and to the telecom providers, which have to roll the update out to the users – this security update either has not happened, or even is not going to happen at all.

Analysts from opensignal have created an extremely interesting overview map of the current state of Android fragmentation by devices, OS version, and brands, based on data of 682,000 devices worldwide. The first chart below show the over 24,000 distinct device types of the study. The second chart show the differences between iOS and Android, and the fragmented state of OS versions developers for the platform have to consider – from both application/service and data security point of view.


Android Device Fragmentation -

Android Device Fragmentation –


Comparison with iOS -

Comparison with iOS –

GM O(w)nStar

After the Fiat-Chrysler uConnect vulnerability it is now GM that has to fix a certain security flaw in their OnStar system. In contrast to the uConnect hack, this exploit takes place using a flaw in the RemoteLink mobile phone companion app of OnStar. The researcher Samy Kamkar uses a self-built device called OwnStar to get access to the user’s credentials by using a combination of wifi spoofing and man-in-the-middle attack.


The book-sized gadget he developed, which he calls “OwnStar” in a reference to the hacker term to “own” or gain control of a target computer, is designed to be hidden under the chassis or bumper of a GM vehicle the attacker is targeting. When the car’s owner uses the OnStar RemoteLink app within Wi-fi range of the car, OwnStar exploited an authentication flaw in the app to intercept the user’s credentials and send them wirelessly to the hacker.

Patch Your OnStar iOS App to Avoid Getting Your Car Hacked


“If I can intercept that communication, I can take full control and behave as the user indefinitely,” says Kamkar, a well-known security researcher and freelance developer. “From then on I can geolocate your car, go up to it and unlock it, and use all the functionalities that the RemoteLink software offers.”

This Gadget Hacks GM Cars to Locate, Unlock, and Start Them


Thankfully, GM seems to have resolved the problem with a change to its server software and update to its OnStar RemoteLink iOS app. Kamkar is scheduled to talk in detail about his hack at this year’s DefCon conference.


Your Car is going to get Hacked!

Having state-of-the art cyber-security and protection for your car will get more and more crucial, with having more and more cars connected to the Internet. Obviously, your car’s connection to the Internet is there for for various reasons such as telemetry data or value added services, but will get even more integral for solutions of autonomous driving.

Previous attempts to control cars over the CAN bus were rather clumsy and required physical access to the CAN to be possible.

Back then, however, their hacks had a comforting limitation: The attacker’s PC had been wired into the vehicles’ onboard diagnostic port, a feature that normally gives repair technicians access to information about the car’s electronically controlled systems.

“Hackers Remotely Kill a Jeep on the Highway—With Me in It”

However, as usual in this topic, it is always just a matter of time until somebody finds a better exploit for easier access and more control. A report from seems to indicate that two researchers – Charlie Miller and Chris Valasek -have found a way into at least one of the common connected car solutions – Uconnect from Fiat Chrysler. The report states that Miller and Valasek were able to remotely get control of the head unit of affected cars, install patches to the firmware, and subsequently are able to communicate with the CAN bus. With far reaching options from turning on the wipers to disengaging the transmission or brakes.

And thanks to one vulnerable element, which Miller and Valasek won’t identify until their Black Hat talk, Uconnect’s cellular connection also lets anyone who knows the car’s IP address gain access from anywhere in the country.


Miller and Valasek’s full arsenal includes functions that at lower speeds fully kill the engine, abruptly engage the brakes, or disable them altogether. The most disturbing maneuver came when they cut the Jeep’s brakes, leaving me frantically pumping the pedal as the 2-ton SUV slid uncontrollably into a ditch.

“Hackers Remotely Kill a Jeep on the Highway—With Me in It”

We still have to see proof and validation of the exploit, though. Miller and Valasek are going to present during the next Black Hat Conference, and I guess (and hope!) that they will have some attentive automotive guys in the audience.