Hâck The Hague 2024

This year, Hâck The Hague, a responsible disclosure event organized by the municipality of The Hague, focused on Operational Technology (OT). Along with three teammates, I had the chance to participate and attempt to breach the hardware systems provided. I even thought I had discovered a vulnerability, until I found out otherwise.

The Event

Before diving in, it’s important to note that all participants, systems, and findings from the event are strictly confidential.

Alongside 40 other security professionals, we were tasked with identifying flaws in 15 different OT setups provided by various vendors. These systems are critical for city infrastructure, think of traffic control and access control mechanisms.

Our Testing Process

Our team chose a specific system to focus on. The setup consisted of several devices, all connected to a central server that managed their operations. We were given IP addresses and began testing immediately.

Physical access

Initially, we tried to physically access the components of the system. Unfortunately, the entire printed circuit board (PCB) was encased in epoxy, making physical tampering impossible. We quickly shifted our attention to investigating the software.

Firmware Research

We identified the make and model of the devices and used Google to search for their firmware. While we could locate the vendor, the firmware was not publicly available. Only companies that had purchased the devices could request the firmware, so we had to pivot to other avenues.

Gaining Root Access

Using nmap to scan the server connected to the system, we discovered that ports 22 (SSH) and 443 (HTTPS) were open. I attempted to connect via SSH using the command: ssh root@\<IP>.

However, I was met with an error: Unable to negotiate with ip port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss.

After tweaking the command by specifying the key type: ssh -oHostKeyAlgorithms=+ssh-rsa root@\<IP> I was prompted for a password.

Finding the password

Port 443 led to a login page and also had a link to “help” documentation. Surprisingly, the default root password was mentioned in this documentation, with a note that it should be changed after installation.

Using this default password, I successfully logged in and gained root access:

Fig.1 Root account

The file in figure 1 was not in the folder from where I tried to open it.

Partial Control of the System

While navigating the filesystem, I found the folder containing the firmware that controlled the devices, allowing me to partially control them. However, the default root password didn’t grant access to the web portal running on port 443.

The Reality Check: Demo Model

Upon reporting the issue to the vendor, they weren’t particularly alarmed. They explained that SSH was disabled on all operational devices, and passwords were updated during installation. This particular system was a demo model, and no one had bothered to disable SSH or change the root password.

The vendor reassured us that disabling SSH and updating passwords were standard parts of their installation process. In fact, after checking another setup of the same device, we confirmed that port 22 wasn’t even open.

Wrapping Up

By 5:30 PM, the testing phase was complete. It was a fantastic experience, and I learned a lot throughout the day. Even though my “vulnerability” turned out to be just a demo oversight, the brief excitement was worth it.