This article was originally published on Techaeris on August 07, 2020.
For centuries, the automotive industry has benefited from the rapid development of technology. From the introduction of Ford’s Model A back in 1903 till in recent times, when cars are being equipped with assistive sensors helping the driver park safely, with the evolution of multimedia systems, or the computerized engine systems that can alert of technical issues, we have come a long way since the horse-driven buggies. But what we were not counting on is that with innovations came vulnerabilities and fully computerized IoT connected automobiles are exposed to the same type of security threats as your laptop. But there is a simple solution to take the necessary precautions and it is called Fuzzing.
What is fuzzing?
Fuzzing is an automated process used to find 0-day vulnerabilities in software and devices. Fuzzers use permutations of data that are randomly or in a unique order being fed into the DUT ( device under test). As a result, a fuzzing tool is capable of finding vulnerabilities that were not found before and would be announced as a zero-day. Fuzzers will normally target the buffers within the protocol and send sequences of bytes, letters, or integers.
Connecting cars to the Internet
Nowadays cars are equipped with a much more sophisticated technology rather than just having an engine. With that comes the connectivity to IoT (Internet of Things) which is the main mode of attacking the car’s control systems. Every new technology introduced comes with benefits to society in general but also with security loopholes that bad actors can take advantage of.
Even though cars today are fully equipped with computers and computerized control systems, they still require a human operator. As we know from previous research done by Fagnant and Kockelman back in 2015, humans are responsible for 90% of all road accidents. But according to a recent study by Bertoncello, et al has predicted that 80% of road accidents would be reduced by 2040 due to the increasing utilization of automated cars.
Security implications for automated cars
Researchers worldwide have considered the benefits and risks of the usage of automated cars. Dino Causevic has even suggested the use of machine learning for improving the security aspects of automated cars in an article published at toptal.com. It is great to see the rising awareness of the security issues in automated cars, but here we would like to suggest a new way of looking at the problem.
While Machine Learning and Artificial Intelligence require “training sets” to enhance the system’s ability to operate and one needs to feed the machine with enough scenarios for it to develop enough intelligence to operate in an adequate manner, this training might not be enough to prevent new security issues.
What further complicates things, even more, is the fact that car manufacturers typically developed their own security protocols on top of proprietary platforms and standards such as Canbus, OBDII, and CAN-FD. Therefore, training the computer on all those unique protocols and situations becomes an expensive and extensive process.
Fully automated cars are not yet widely used and therefore security holes are not yet properly researched and documented. For example, the national institute of Standard and Technology (NIST) has very few documented issues in its CVE database (common vulnerability and exposure) for automated car systems and components. Therefore, I would like to introduce to you today the concept of fuzzing and how it could assist in ensuring the security of automated cars.
Fuzz testing autonomous and connected cars
Imagine the following situation: you are driving your automated car, the engine communicates with its sensors, thousands of packets are being sent and received by the engine. Suddenly another node is sending thousands of more packets to your engine. This node is not playing by the rules and doesn’t send the accepted number of bytes as defined in the protocol. Your engine has been tested so it has the ability to resist those packets, however as the node keeps on sending more and more packets and they are of integers or hexadecimal combinations that are not usually processed by the engine, suddenly a buffer overflow created, causing your engine to shut down while you are on the freeway. It’s a terrifying scenario yet very simple to carry out. To prevent such situations, it is recommended using fuzzers that would test each specified region and buffer in the protocol one that can suggest a fix to the engineers and assurance that this automated car is safe against attackers trying to crash the DUT, Bypass login and operate a remote code execution.
There are several well-known fuzzing methods known in the industry today:
- Mutation: samples of valid codes are being mutated randomly in order to create malformed inputs, mutation may not be providing a clear output on what buffer caused the DUT to crash, it is difficult to replay the scripts and find the exact loopholes.
- Replay: the fuzzer will use saved sample inputs mutate them and then replay to create an attack, it is not a recommended or effective way to fuzz automotive as it will require a robust set of information and it does not work well in dynamic protocols in automotive where the communication is bidirectional.
- Grammar and generation based: in this method the fuzzer will learn the RFC and understand its grammar, the fuzzer would learn what fields may not be mutated and what fields can be tested. It gives a more in-depth ability to communicate with the DUT, the packets are generated based on the grammatical structure of the RFC. Unlike mutation, the fuzzer will be able to create attacks and replay it to a specific field later. The generation-based fuzzer will construct valid sequences of inputs applying fuzzing to specific parts of that communication it will be more time effective since it will assure that all packets are not being immediately blocked by the DUT, unlike mutation where my first sequence of packets will be normally indigestible and would not be testing my protocols since those would be blocked immediately.
While fuzzing is not the only solution out there it is indeed the best fit for the automated cars industry. Static analysis tools would require source code access to detect potential vulnerabilities fuzzing does not require. The source code is not being fuzzed at all rather it is the protocol and communication method that are being fuzzed.
Additionally, static analysis would require information about the DUT, what language the source code was written in, and what is the entire stack fuzzing on the other hand operates as a black box test. It does not require any information about the DUT, it does not require special access for testing, and it would be finding vulnerabilities in the post-development and prerelease stages.
Nowadays vehicles are using several protocols such as Can and OBDII, which have been described before in addition to Bluetooth stack and even in-car Wifi using the IEEE 802.11 protocol. Machine learning would not be able to provide an extensive solution to all of those potential points of entering and taking over car control it will test the car in endless scenarios as one operating unit while has fuzzing will test endless scenarios for each protocol and for each unique situation.
Another key advantage of fuzzing is the ability to communicate over protocols that require a serial connection. Unlike vulnerability assessment, which is used for finding vulnerabilities by using IP communication fuzzing can provide robust testing for products that do not have TCP/IP communication.
As we understand that the security implications of automation should be addressed and there might be other solutions that give adequate security coverage, there is still no solution as fuzzing that gives a full extensive and exhaustive testing that can assure the safety of automated cars while they are in the verification stage. If using the right type of fuzzer, you will benefit from the ability to recreate the attack and understand the structure of your protocol thus having the ability to understand what parts of your protocols are more vulnerable and what are the methods and causes. So next time you are in the open road, driving your smart car, keep in mind that fuzzing can be the smart way to avoid unnecessary and often critical unseen danger.
ABOUT THE AUTHOR
Joel Sivan is a Senior Engineer and Support team leader at Beyond Security (www.beyondsecurity.com), a US-based company specializes in vulnerability scanning, source code analysis, and black-box testing. He has extensive experience in the field of IT security, which started at the age of 19 when he became a communication sergeant in the IDF responsible for radio communication systems and proprietary.
Joel has specialized in these unique tools which emerged him to understand the importance of protecting OT equipment and protocols which are not covered in regular IT vulnerability testing. While serving at the IDF Joel also worked at Magic Software where he handled projects involving interconnecting IT systems and supporting the sales and R&D by ensuring that the servers and environment is secured and scalable. At
At Beyond Security, he oversees vulnerability scanning and fuzzing of unique protocols. He has seen hundreds of test cases as part of his role as Senior Sales Engineer and his work with high caliber clientele within North America, Europe, and Africa. He is currently pursuing a degree in Business Administration and Psychology. He is an assistant researcher at the Research Center for Internet Psychology.
Other Publications
Black Box Fuzzers: A Tool Against the Unknown
Black box fuzzing tools like beSTORM protect against both known and unknown vulnerabilities. This guide, How Black Box Fuzzers Protect Against The Unknown has more information about protecting against the unknown.