Nozomi Networks Labs Takes on the Armasuisse ICS and Automotive Hackathons

Nozomi Networks Labs Takes on the Armasuisse ICS and Automotive Hackathons

Last year the Nozomi Networks Labs team was invited to take part in two hackathons at the Cyber-Defence campus of armasuisse Science and Technology. These hackathons brought together cybersecurity enthusiasts and professionals to delve into the complexities of securing Industrial Control Systems (ICS) and automotive cybersecurity. These hands-on sessions aim to give cybersecurity professionals a deeper understanding of the challenges of securing critical infrastructure. Participants included experts and researchers from critical infrastructure and cybersecurity companies, as well as the Swiss Government agencies, including the National Cyber Security Center and Federal Department of Defence, Civil Protection and Sport.

So what does it look like to participate in these hackathons? In this blog we take a look at the activities involved, including reverse engineering of firmware of devices used in SCADA industrial settings, opportunities for analysis and fuzzing of car infotainment system firmware, and analysis of wireless communications exposed by modern cars.

ICS Hackathon: Network traffic analysis and firmware reverse engineering in SCADA scenarios

The Industrial Control Systems (ICS) Hackathon held in Thun focused on the theme of "Forensics and attack detection in critical infrastructure," emphasizing the need for proactive cybersecurity measures in safeguarding industrial processes. Participants engaged in technical training sessions on ICS forensics while also working independently to craft attacks and develop mitigations for industrial control systems and operational technology (OT) devices. The two participants from the Nozomi Networks Labs team focused on firmware reverse engineering and the wireless attack surface exposed by the components used during the event.

A notable aspect of the event was the simulated SCADA scenario, which provided a practical platform to test vulnerability identification and mitigation skills within industrial control systems. All devices were accessible through a jump host with all necessary software already installed and ready to be used.

Figure 1. The SCADA lab setup at the ICS Hackathon hosted by armasuisse Science and Technology at the Cyber Defense Campus.
Figure 1. The SCADA lab setup at the ICS Hackathon hosted by armasuisse Science and Technology at the Cyber Defense Campus.

Our Labs researchers dedicated days to improving our skills in analyzing the devices within the SCADA rack, encountering some that were entirely new to us. We started by performing basic port scanning and trying to understand the network communication between the devices. During these tests, the protocol used by Omicron CMC256-6 to communicate with its control software was partially reverse engineered. Delving into the complexity of understanding data exchange by treating the device and control software as a black box proved both challenging and stimulating. Our focus in these cases was on decoding and understanding proprietary protocols.

This hackathon provided a unique opportunity to investigate and collect data from various devices used in industrial settings, including the ABB Relion 670, Elvexys XPG, Omicron Stationguard RBX1, and Omicron CMC256-6. This firsthand experience allowed us to gain valuable insights into the vulnerabilities and potential threats associated with these devices. We took the opportunity and spent some time collecting network traffic produced by these devices and extracting the corresponding firmware that will come in handy for our future vulnerability research activities.

A highlight of our participation at this hackathon was a Nozomi Networks' Guardian sensor being included as part of the equipment for participants to test. Guardian was installed in the SCADA scenario and we are proud to confirm that all the devices were correctly identified along with their detailed information (model, firmware version, etc.). By allowing other researchers to test Guardian with their own Packet Capture (pcap) files, we were able to contribute to the collective understanding of robust cybersecurity solutions in ICS.

As a participating team, we provided a Programmable Logic Controller (PLC) and an overcurrent time protection as experimentation targets, allowing fellow researchers to test and refine their skills in a controlled setting. This collaborative approach underscored the spirit of knowledge sharing and teamwork prevalent throughout the hackathon.

Automotive Hackathon: Car infotainment system firmware analysis and wireless attack surface

Armasuisse's Automotive Hackathon set the stage for an in-depth exploration of automotive cybersecurity. The goals for this hackathon were to research electric vehicle attack vectors, as well as vulnerabilities in cars and their software/firmware. Participants had the opportunity to interact with five electric vehicles: two Renault Zoes (ZE Electric), a Skoda Octavia, a Skoda Enyaq IV 80, and a Honda. The organizers also provided a plethora of tools, including OBD2 Dongles, CAN to USB adapters, Software-Defined Radios (HackRF, USRP), and Wi-Fi/Bluetooth antennas.

Figure 2. Three-car hackathon laboratory. Skoda Octavia on the left and Renault Zoe on the right, together with SDR equipment for wireless communication analysis.

Track 1 - Electric Vehicle Hacking

Two PhD students from the University of Oxford (Sebastian Köhler and Marcell Szakaly) presented this first Electric Vehicle (EV) track. The session started with a presentation on Broken Wire, an attack against the Combined Charging System (CCS), one of the most widely used DC rapid charging technologies for EVs. The name of the attack derives from the fact that replaying a special packet called a "preamble" over the air against an established communication between an electric vehicle and a charging station, to interfere with this communication and induce an error state in the charging station, causing it to be interrupted. This attack, which can be performed remotely through the use of an SDR, can be particularly dangerous in situations where a large fleet of vehicles is targeted and therefore not properly charged.

A paper focusing on an attacker's capability to meddle with circuits that control the voltage necessary for battery operation was also showcased. Such interference can enable a remote attacker to manipulate circuit regulators, leading them to perceive incorrect voltage levels. Consequently, if voltage beyond the designated limit is allowed pass through, a permanent hardware Denial-of-Service could occur to the batteries used in electric vehicles.

Track 2 - Firmware Analysis and Fuzzing

In this second track, the focus of the presentation by Tobias Scharnowski and Johannes Willbold was on a paper titled "Fuzzware: Using Precise MMIO Modeling for Effective Firmware Fuzzing", presented at Usenix 2022. Fuzzware is a project developed over the course of two years (and still maintained and developed) that aims to automate fuzzing attempts on bare-metal firmware images. The project leverages a combination of three other tools:

  • AFL++: an engine used for fuzzing and code coverage;
  • Unicorn Engine: a solution used for firmware emulation;
  • Angr: a framework for dynamically solving constraints posed by MMIO peripherals.

With this combination it is possible to leverage re-hosting as a technique to enable scalability for embedded firmwares.

Car Infotainment System Firmware Reverse Engineering

For the Nozomi Networks Labs team, the primary focus at the automotive hackathon was on the Firmware Analysis and Fuzzing track, due to its broad applicability across various embedded systems and relevance for our daily jobs. During a workshop on firmware re-hosting, two different approaches were demonstrated:

  • Approach 1 (Manual): Leveraging the Unicorn Engine, the goal was to emulate a firmware in order to reproduce a well-known vulnerability: CVE-2023-23609.
  • Approach 2 (Fuzzware-based): The goal was to demonstrate how fuzzing efforts can be automated using the Fuzzware tool over a simple toy binary. Such a program was designed in a way that it was possible to trigger a buffer overflow (and therefore a crash) by providing a large input after inserting the correct password.
Figure 3. Firmware reverse engineering activity on the left and vehicle related PCB on the right.

We also had the opportunity to to analyze the firmware of Volkswagen’s MIB III infotainment system. We initially focused on understanding the structure of this very large archive and then moved our analysis to specific components that captured our attention, such as:

  • Reverse engineering of the Carcom component, a free real time operating (RTOS)-based firmware responsible for handling communication messages exchanged over the CAN bus.
  • Reverse engineering of Trusted Applications loaded by the Kernel and involved in tasks such as distributing keys to vehicle components later used to sign/authenticate CAN messages.

Attack Surface of the Wi-Fi Networks Exposed by the Cars

In addition to the firmware analysis, we invested some time in analyzing Wi-Fi technology as a possible attack surface on the Skoda Enyaq IV 80. This particular vehicle exposes an access point where passengers can connect to the internet for navigation, so our first approach for investigating a potential vulnerability was that of an external attacker capable of seeing the SSID.

Figure 4.Testing wireless communication inside the Skoda Enyaq iV 80.

Since the Wi-Fi protected setup (WPS) technology (a network security standard designed to simplify the connection of devices to a Wi-Fi network) was available on the access point exposed by the car, some well-known attacks were tested, including the following, which are typically used against IT routers in wireless networks:

  • Pixie Dust Attack: This attack exploits a vulnerability in the WPS protocol where the WPS PIN is based on non-random, predictable elements, allowing attackers to retrieve the Wi-Fi network's WPA/WPA2 passphrase with fewer attempts than brute-forcing the PIN.
  • NULL PIN Attack: This attack is another form of WPS vulnerability exploitation. In this scenario, an attacker sends a PIN consisting of all zeroes (or null) in an attempt to bypass the authentication process. Some poorly implemented WPS configurations may not adequately validate the PIN, allowing unauthorized access to the network.
  • PIN Attack: This is a brute-force attack on the WPS PIN itself. Since the PIN is typically an 8-digit number, an attacker can systematically try every combination until the correct one is found. The last digit is a checksum of the previous seven, reducing the number of attempts to 10^7 (10 million) possibilities, which is achievable with automated software. Once the PIN is discovered, the attacker can gain access to the Wi-Fi network's WPA/WPA2 security key.

Proper mitigations were in place against these well-known attacks, so we decided to limit ourselves to capturing some association requests and move one step further. We then decided to enumerate for possible internal services available once already connected to the access point. Since the password can be customized by end-users, such scenario could occur if a user configures a particularly simple password that is subsequently discovered using WPA-2 cracking techniques.

After a standard port scan for TCP services available on the default gateway (10.173.189.1), we managed to identify one port open (7000/TCP) exposing an HTTP/RTSP server (AirTunes/320.17.7).

   Nmap scan report for 10.173.189.1

   Host is up (0.0063s latency).

   Not shown: 995 filtered tcp ports (no-response), 4 closed tcp ports (reset)

   Some closed ports may be reported as filtered due to --defeat-rst-ratelimit

   PORT     STATE SERVICE

   7000/tcp open  afs3-fileserver

   MAC Address: 2E:D1:C6:8A:C4:B5 (Unknown)

   

   Nmap done: 1 IP address (1 host up) scanned in 4.49 seconds

Attempts were made to interact with the service using BurpSuite, given that RTSP is text-based, but nothing too obvious was observed during this preliminary analysis. More time and exploration would be required to establish a dependable RTSP fuzzer and to identify the same service in a different firmware online belonging to Skoda.

Wrapping Up

The two hackathons proved to be more than technical competitions; they were catalysts for teamwork, growth, and innovation. Our collaboration with Armasuisse and the Cyber-Defense Campus deepened, promising exciting research projects in the pipeline. We had the opportunity to learn new technical skills, put our hands on new types of devices, and to showcase Nozomi Networks' Guardian capabilities. Besides all this, we had the pleasure of working alongside the talented Armasuisse team and fellow security researchers.

On our side, we are very thankful for these kind of events as they not only keep participants sharp and up-to-date but also create an environment where shared knowledge and novel approaches contribute to the broader enhancement of cybersecurity research and best practices.