BMW and VW/Audi are the most recent automotive cyber victims. Fortunately the vulnerabilities were uncovered by researchers and the reports published. Unfortunately the reports are long and technical. Read below for a discussion of the attacks’ similarities and differences and, more importantly, what you can learn to prevent your products from being the subject of the next hack!
Computest (VW/Audi) published their research on the VW/Audi vulnerabilities and Keen Security Lab (BMW) published theirs on BMW. Even though the OEMs are different, there are more similarities than one would expect – the vehicles’ architectures, protocols, vulnerability identification approaches and, at a high-level, even the vulnerabilities. Though the vulnerabilities are not presented in technical detail (to help the script kiddies), the results from the publications are relevant to every automotive professional (not just cyber security professionals). This FEV article’s aim is to spark a discussion of the hacks similarities and differences so everyone can not only learn from their findings, but also take a look at their own products driving on the road every day.
Let’s start with a combined summary of the hacks, aka vulnerabilities, illustrated in these publications.
THE SCOPE
The research scope included the following vehicle models:
· BMW research from Keen Security Labs
– BMW i3 94 (+REX), manufacturing year 2017
– BMW X1 sDrive 18Li, manufacturing year 2016
– BMW 525Li, manufacturing year 2016
– BMW 730Li, manufacturing year 2012
· VW/Audi research from Computest
– Volkswagen Golf GTE, model year 2015
– Audi A3 e-tron, model year 2015
At this point you might be thinking these are 2015, 2016, and 2017 vehicles so the vulnerabilities are outdated and, since you are most certainly working on building an impenetrable shield to protect your future models, this information isn’t relevant to you. However, even superman was weak against Kryptonite. The vulnerabilities highlighted by these publications are foremost architectural and process weaknesses common throughout the automotive industry with a secondary focus on OEM specific vulnerabilities. Lessons applicable to future architectures, even yours.
GETTING STARTED
The process of vulnerability identification has high-level similarities across OEMs and you can implement this process of security analysis within your own teams. Traditional teams for hardware and software design, development, testing and release can all learn valuable lessons from these examples. Cyber security-specific teams are no exception; although, they have a different mindset than the traditional teams since security testing is part art and part science. Your penetration testing team runs on creativity, but as an automotive professional you might not be accustomed to the unpredictability of the creative process and want a more quantifiable standardized process. This vulnerability process should put you in the direction to achieve a standardized, predictable methodology which is aligned with your development life-cycle.
Both research teams started by analyzing which targets were ripe for investigation. They selected models with certain features such as WiFi, USB, Cellular, Bluetooth and a connectivity app – i.e. connectivity features. So what is the first lesson learned? Connectivity is the target. Attention has moved away from CAN or solely physical or component attacks to connected services in the automotive domain. Hence, focus your strengths and might more towards securing connectivity.
The primary target modules from there on are the Infotainment Unit, Telematics Unit and Central Gateway – a typical architecture for any car on the road (any car!). It is a sensible idea to have a central gateway segregating the in-vehicle network with the external world of connectivity. However, the BMW architecture is a bit odder than the rest. It has a Telematics Unit connected to the Infotainment Unit over USB! Why choose such a unique architecture? The reasons are not clear and raise many questions. Without delving very far into the pros and cons, just know that it is not a good idea to peak a security researcher’s interest with unusual features, keep it subtle. Chances are, if they dig deep enough, they will find a vulnerability anywhere they look, but if something catches their interest – like an abnormal architecture – that will be their focus. Don’t give them that head’s up. Exception, not in this case though as they had other “¡Ay, caramba!” moments with Cellular, WiFi and other interfaces.
Once the target vehicles are shortlisted and the target modules are identified, it’s time to go through each interface. Both the publications perform respective analysis on cellular, Bluetooth, USB, OBD-II, and the holy connectivity of application interfaces – the phone.
The BMW research identifies vulnerabilities in USB (USB-to-Ethernet), Bluetooth and are able to take advantage of the cellular interface to showcase a remote hack. They also leverage the OBD-II interface and demonstrate a physical attack scenario. Computest (VW/Audi) targets the USB (USB-to-Ethernet), Wi-Fi, and the cellular interfaces.
HOW THEY DID IT!
The Keen Security Lab (BMW) researchers presented and focused on both remote and physical attack scenarios resulting in a demonstrable attack. Computest (VW/Audi), on the other hand, focused solely on proving remote attacks by illustrating individual component vulnerabilities and, in some instances, theoretical attack scenarios. Even though the focus was on remote attacks, if they had the requisite time and effort they most likely would have identified more vulnerabilities. But there are certainly lessons to be learned in what they did identify, so please read on.
Focusing on the physical attack is also important, as highlighted by Keen Security Lab (BMW). Buzz words such as “risk profile”, “insider threat”, “mass impact” and of course, CAN are probably already floating in your mind. Yes, it might not be a mass-impact attack. Yes, it might not have a high-risk profile. And yes, your company might be working on or has already worked on securing CAN so your in-vehicle network will be secure in future models. What is more important are the architecture changes that can be adopted for security. These are the lessons that must be learned.
THE ATTACK PROCESS
So what do you do first? You scan any and all available interfaces which is precisely what the researchers did. They scanned the USB, OBD-II, and cellular interfaces to determine what was there. A USB (specifically USB-to-Ethernet) port scan using Nmap was used to identify what services were running on the vehicle. Nmap is not rocket science (inner functionality may be, definitely not its usage). It uses simple command line instructions and is available for both Windows and Linux. Not surprisingly, the researchers all reached the same destination – QNX. Lesson two, simple tools are all you need to start your journey towards security.
With their first scans they found vulnerabilities and were able to get root access to Infotainment Units running QNX. Wink-wink, even your systems are probably using QNX. QNX has 50% market share (as reported in 2015); 50 million vehicles have QNX running. Not included in the vehicles researched in these studies are QNX-using vehicles from GM, Mercedes-Benz, Toyota, Porsche, and Land Rover.
Once both research teams got root access to the Infotainment Units, they were able to perform local code executions. After earning this right, what more do you need? You are in the Infotainment Unit and have access to QNET, the bridge between the common automotive architecture and the in-vehicle network of respective targets. Root access grants the same privileges as software developers or service personnel.
They did not stop with USB; both research teams upped the ante by going cellular. They reached similar attack goals by two different methods over cellular. Keen Security Lab (BMW) does this by setting up a local cellular network using Universal Software Radio Peripheral (USRP) and OpenBTS. Computest (VW/Audi) does this by using the client-to-client communication feature and assigning public IPv4 addresses to target vehicles from an ISP.
Keen Security Lab (BMW) even analyzed Bluetooth and the E-NET OBD-II interfaces. And, as you might have guessed, they found vulnerabilities in both. However, the E-NET OBD-II is more interesting from an architecture standpoint and is discussed below.
WHY DO VEHICLES HAVE MULTIPLE WAYS TO UPDATE?
Does it make sense to allow updates using USB-to-Ethernet and OBD-II?
USB-to-Ethernet allows the end consumer to update their vehicle via a USB dongle. Ok, updates are great and customer satisfaction is important. But then why allow similar firmware updates through the OBD-II interface? Most likely to allow a service individual to perform updates, but couldn’t the service provider use the same USB-to-Ethernet interface to do the tasks from the OBD-II? Two interfaces performing the same task means double the vulnerabilities.
Have you seen a mobile company sending a USB update to its consumers? They have OTA. Maybe all vehicles aren’t ready for OTA updates, but the real point is they only have one highly reliable means to update. Lesson three – master one update interface. Allocate your budget to one interface and you might have a larger budget for security. Too many interfaces doing the same functionality lead to multiple vulnerabilities, stretched budgets for security implementation and so much more.
VULNERABILITIES
Memory corruption, remote attacks, code signing, open ports and services – you name it, the vulnerabilities can be demonstrated. Here is the list of categories illustrated in the publications. The publications do not reveal the exact executable code that is vulnerable, but the high-level vulnerability areas to consider.
– Root access: Both the research teams are able to get root access to the target units.
– Memory Corruption: Telematics Unit, Bluetooth, and Connected Vehicle App have memory corruption vulnerabilities. Memory corruption is a huge topic to consider.
– Code Signing: Both the research teams identify code signing vulnerabilities. They are not cryptography vulnerabilities, but highlight inconsistent implementation vulnerabilities. Lesson four, deploy security solutions consistently.
These vulnerabilities deserve a second look, we all do. So look for more articles detailing these vulnerabilities and more.
LESSONS LEARNED
Lesson One: Connectivity is the target
– Connectivity is the new normal in automotive cyber security research. The community has moved from solely in-vehicle attacks to focus primarily on Infotainment, Telematics and the Central Gateways.
– The near future is going to be shared mobility services (Maven, Zipcars etc.) which increases the need for cyber security considerations.
Lesson Two: Start with simple security tools that do not need Subject Matter Experts
– Quick, easy and every engineer in testing, design and development can perform them. Not just for penetration or security engineers.
– The ROI from an open-source tool such as Nmap is large as it is the common thread in all the hacks.
– The list is enormous, but some notable open-source tools that you can use without expert knowledge are Wireshark, Metasploit (there is more than meets the eye), OpenVAS and Aircrack.
Lesson Three: Master one update method
– Do not have multiple ways to do the same thing. OBD-II, USB-to-Ethernet, WiFi or cellular – choose one.
– If you focus on the development of one master means or interface for a function, you do not need to divide the budget of the function to multiple interfaces, leaving more budget to hardening one interface. Consider the function’s purpose and focus.
Lesson Four: Deployment of security solutions consistently
– Code signing can be bypassed in both the research publications.
– Vulnerabilities are not due to weak cryptography, but due to inconsistent implementation throughout the system.
We hope you have gained some “water-cooler knowledge” about these most recent attacks and how to apply them to your own architectures. As mentioned, look for more articles from your FEV automotive cyber security experts.
Attack Interfaces Targeted
REFERENCES:
– Experimental Security Assessment of BMW Cars, Keen Security Lab. https://keenlab.tencent.com/en/2018/05/22/New-CarHacking-Research-by-KeenLab-Experimental-Security-Assessment-of-BMW-Cars/#more
– The Connected Car Ways to get unauthorized access and potential implications, Computest. https://www.computest.nl/wp-content/uploads/2018/04/connected-car-rapport.pdf
– http://www.navpro.co.nz/media/catalog/product/cache/1/image/9df78eab33525d08d6e5fb8d27136e95/7/1/715c.jpg(Head Unit image source)
