Hello,
My name is Urban Jonson, and I’m the Chief Technology Officer and Program Manager, Heavy Vehicle Cyber Security Program, with the National Motor Freight Traffic Association, Inc. (NMFTA).
I’m honored that IOActive has afforded me this guest blogging opportunity to connect with you. The research at IOActive is always innovative and they have done some really good work in transportation, including aviation, truck electronic logging devices, and even satellites. Being among such technical experts really raises the stakes of the conversation. Luckily, I can lean on some of my awesome collaborators like Ben Gardiner at NMFTA, as well as countless industry experts who I’m privileged to call friends.
I feel a profound sense of loss of technical progress in our field this year. All of my favorite technical events, where I can connect with people to discuss and share ideas, have been canceled (heavy sigh). The cancellation of the NMFTA HVCS meetings have been the hardest for me, as they pull together an incredible community in the motor freight industry. Many of the attendees are now my friends and I miss them.
The cancelation of my other favorite industry events, Blackhat/DEF CON, CyberTruck Challenge, and ESCAR, have been hard as well. While I do enjoy many of the presentations at these conferences, my biggest benefit is meet one-on-one with some of the brightest minds in the industry. Where else do I get to sit down with Craig Smith and casually discuss the state of the automotive industry? I remember having great conversations with Colin O’Flynn about wily new ideas on power fault injection at many different events. These one-on-one opportunities for conversations, collaboration, and information sharing are invaluable to me.
This year I had wanted to talk to some of my friends about Triton malware and vehicle safety systems such as lane departure assist, crash avoidance, and adaptive cruise control. Alas, no such luck this year. So, I’m going to dump this discussion out in the open here.
The Triton Malware
First, for the uninitiated, a quick review of the Triton malware. The Triton malware intrusion was a sophisticated attack that targeted a petrochemical plant in the Middle East in 2017. How the attackers first got into the network is a little bit of a mystery, but most likely the result of a misconfigured firewall or spearphishing attack. The first piece was a Windows-based remote access tool to give the attackers remote access to an engineering workstation. What came next was very interesting: according to reports1, a highly specific secondary attack was mounted from the compromised engineering workstation against a specific Schneider Electric Triconex2 safety controller and select firmware versions (10.0 – 10.4) using a zero-day vulnerability. The safety controllers in question are designed to take direct action to initiate shutdown operations for the plant without user intervention in the case of serious safety issues.
Stop and think about that for a second—someone had taken the time to figure out which specific controller and firmware versions were running at the plant, obtain similar hardware to research, find a zero-day vulnerability, then research and compromise the plant’s IT infrastructure, just to install this malware. That is not an insignificant effort, and not as easy as they make it out to be in the hacker movies.
An unplanned “accidental” shutdown of the plant revealed the presence of the malware and the intrusion. It was theorized that the attackers wanted to obtain the capability but not use it, and that the shutdown was an accidental reveal3. Cyberphysical attacks are usually broken into separate cyber and physics packages. Given the effort put into the attack, it is extremely unlikely the attacker would have intended on such a dumb physics package. If you want an example of a well thought out cyber-physical attack read up on Operation Olympic Games which targeted Iranian uranium centrifuges4. This goes to show that if you play around with bombs, physical or digital, they can go off unintentionally.
Another interesting tell occurred as the response team was trying to secure and clean up the intrusion, when the attackers fought back to try to maintain a foothold. Actively engaging blue-team efforts in real-time is risky, as it can quickly lead to full attribution and unwanted consequences. This tells us that the attackers considered this capability a high priority; they had made a large investment in resources to be able to compromise the safety controllers and they were determined to keep it. A great deal of information about this intrusion is still murky and closely guarded, but it is generally considered to have potentially been one of the deadliest malware attacks so far, had the capability been leveraged.
Safety Controllers
The safety controller concept of a contained device taking decisive action without user intervention sounds eerily familiar. The concept is virtually everywhere in the new safety technologies in modern cars and trucks in the form of crash avoidance, lane departure assist, and other features for which we have all seen the ads and literature. FMCSA is even studying how to retrofit existing trucks with some of these promising new safety technologies, which can help reduce accidents and save lives.
These automotive safety systems rely on sensors such as cameras and LIDAR to get the input they need to make decisions affecting steering, braking, and other actions. This brings up some interesting questions. How secure are these components? How diverse is the marketplace; that is, do we have risk aggregation through the deployment of just a few models/versions of sensors? Is there a specific sensor model that is ubiquitous in the industry? Do we have our own version of a Triconex safety controller that we need to worry about?
How secure are these components? How diverse is the marketplace; that is, do we have risk aggregation through the deployment of just a few models/versions of sensors? Is there a specific sensor model that is ubiquitous in the industry?
The short answer seems to be yes. I read an interesting paper on Fault Detection, Isolation, Identification and Recovery (FDIIR) for automotive perception sensors by Goelles, Schlager, and Muckenhuber from Virtual Vehicle Research5. (Note: This paper is an interesting paper worth reading in its own right, and discusses a sensor fault classification system that can be applied to other domains, such as aviation and maritime.) The conclusion of the paper is that, for the most part, systems such as LIDAR treated as black boxes with little or no knowledge of the internal firmware or interfaces. This is mostly due to a small number of companies in fierce competition working hard to protect their intellectual property. In my opinion, that is not a good sign. If we need multiple sensors to cooperatively decide on safety-critical actions, transparency is going to be crucial to designing a trusted system. The present lack of transparency in these systems almost certainly implies a lack of security assurance for their interfaces. This sort of inscrutable interface (aka attack surface) is a hacker’s delight.
All of this is not really new—our own Ben Gardiner discussed similar points in 20176. So, what other truck-specific safety system black boxes can we discuss through the filter of the Triton attack that might not be ready knowledge to you? Enter RP 1218.