Pwning a nuclear-grade entrance control system easily

Like in any field of critical infrastructure or manufacturing, physical protection is crucial in a nuclear facility. In case an adversary can penetrate the site, they may disrupt operations causing vast economic damage, steal radioactive material to be used later in terrorist attacks, or threaten human life in a wide range of ways.

Therefore, especially in the nuclear field, approaches in physical security are really formalized. It is often said that it has three different functions:

Detect: to stop an intruder, security personnel must be aware of their presence. The goal of this function is to raise attention of it, as soon as possible. Detection relies on physical intrusion detection systems, using sensors, surveillance cameras, a central alarm station (CAS) and so on.
Delay: after coming aware of an intrusion, personnel needs time to arrive on the spot - either they are the police coming from an external location or armed guards employed in the facility. If they let the attacker reach their goals before they get there, it is game over. "Delay" uses both passive barriers (walls, fences, barbed wire, etc.) and active ones (turnstiles, doors and gates with guards or automatic access control mechanisms, etc.).
Deter: this is kind of a two-in-one function. First, it means stopping an ongoing attack by capturing the intruders or forcing them retreat, applying lethal force if necessary. Second, it is best when it can prevent an attack. After all, if an attacker sees high fences and men with guns inside a facility, they might reconsider their plans before even trying.

We are cyber security experts and we can tell that cyber security also relies on physical protection - it is normally much easier to hack a device when we can get our hands on it, push buttons and see what is on its screen. However, physical security depends on cyber security, too. Each function might use computer-based systems, like digital cameras, monitoring stations or - entrance control systems performing authorization before unlocking doors. Hacking these can be troubling on its own, what's more, it can be a perfect opening of a planned physical attack.

What are we dealing with? #

In one project, we examined a complex physical protection system which incorporated access control in a nuclear facility. It had three doors with RFID card readers both from the inside and from the outside. When an employee touched their card to the reader, the system decided if they were authorized to open the respective door and if so, a controller unlocked the door for a few seconds. Although this system operated in a nuclear facility, this was only a test system. The operator had just bought it for training physical protection professionals and the whole thing was brand new. The supplier told us that it was rated grade 3 based on standard EN 50131-1, meaning it was eligible to be installed as a nuclear facility access control system.

Each of the three doors had a control board that managed the two card readers and the lock. These control boards were connected via - what we were told - an RS-485 bus, resulting in an architecture as below.

Architecture for doors and their controllers. Icons by Maniprasanth, Freepik on flaticon.com

Since RS-485 is a bus, it is controlled by a master device (which was responsible for door number 1 in this system, displayed in red). The master will control access to the bus but otherwise each device can see every message sent through.

In this architecture, after an employee touches their card to a reader at say, door 2, the reader will report their card ID to the respective control board, which in turn will forward it to the master when given permission. If door 2 needs to be unlocked, the master will command control board 2 to do so and the latter will deactivate the lock attached to it accordingly.

However, this was a smart system with a ton of fancy features. It had a web interface for adding or updating employees, managing configuration and it provided functionality that required a more powerful computer. So, the full architecture looked like this:

A full view of system architecture. Icons by SBTS2018, Maniprasanth, Freepik on flaticon.com

The master control board was connected to a plain old, Ethernet-based computer network via a regular switch. The same network had an access control server to provide all those fancy features and the supplier also installed a Windows-based PC to access the web interface and configure everything.

Now, when an employee touched their card to one of the readers, their card ID was sent to the master controller in the same way as described above. But the master forwarded it to the server through the network, then the server performed authentication and authorization. If it was necessary to open any doors, the server commanded the master board over the network, which notified the slave over the bus (unless the specific door was the one directly connected).

Our goals #

We assumed the role of attackers in this project. As such, our goals were simple:

Compromise as many parts of the system as possible
Preferably open a door remotely, without a card

Attack against the RS-485 bus #

Looking at the architecture above, the weakest link seemed to be the RS-485 bus. RS-485 is a really low level protocol, it can only carry binary 1's and 0's between devices - it's a bit like Ethernet in the IT world. Knowing this, we assumed the boards didn't do anything much more complex, like encryption or message integrity protection. In addition, bus wires must run throughout whole buildings, likely through areas where random visitors can walk in. Thus, tapping RS-485 sounds fairly realistic. We hoped we can just record the command that opens a door and later replay it. Or if it fails, we hoped the binary protocol would be easy to reverse engineer, allowing us to construct and inject valid commands.

Luckily, one of us had a USB-to-RS485/422 adapter that we could use to get into a man-in-the-middle position just in between the master board and the first slave. This adapter is quite easy to use by the way, on Linux it shows up in /dev as a tty, so one could just read and write data on it, thus intercepting and injecting data on the bus.

Attack against the bus. Icons by SBTS2018, Maniprasanth, Freepik on flaticon.com

Quickly, we started reading data from the bus, while opening several doors with RFID cards - but all we could read was garbage, if we got data at all. It was immensely confusing and frustrating after some time. Then, we found something in the technical specs of the control boards:

Part of the tech specs for the control boards. Source: website of manufacturer.

As it turns out, control boards do not speak proper RS-485, no wonder our adapter didn't work. Instead, they speak a custom, proprietary protocol called 485bus, which is only based on the original and open source RS485. What a bummer.

This project was not some traditional penetration testing or red teaming, so we had the luxury of asking for documentation of 485bus from the supplier. They told us that they don't have any, however they would ask the manufacturer directly. A few weeks later, we received an email from them, that said:

They will not release any documentation on the protocol for the very reason your Cyber Security team are asking for it. If they release any such information, it could be reverse engineered and hacked!

The supplier even added that this is "not what you want to hear". On the contrary! As an attacker, this is exactly what we want to hear. The manufacturer literally said that if we learn anything about the protocol, we could easily compromise it! Again, this is a grade 3 physical protection system, which could be (and is) used in high-risk nuclear facilities! Sadly, we didn't do anything with this knowledge, as we received this email after the project ended and we managed to compromise everything anyway...

That said, we considered tapping the RS-whatever bus a failed attempt. Or a partially failed attempt, more exactly, as we found that although our adapter didn't work perfectly, it could still be used to inject random garbage into the bus. If we did it fast enough, it made messages on the bus incomprehensible for the conrol boards, so no card identifier or door open commands could get through. That means we could essentially disable almost every door. Still a nice attack, as now not even guards can get through, slowing their response a lot.

Attack 2: finally opening the doors #

After MitM on the bus was a dead end, we needed another idea. We admit, we wasted really much time getting one. But at one point, as we were looking through the web-based configuration UI from the configurator PC, we found a highly interesting view. Sadly, no screenshots have been made but it looked something like this:

"Screenshot" of the view showing a table of door data.

At a first glance, this is nothing special. Just a table of all the doors' most important data. It also has a button for every door to unlock and when we tried clicking them, the respective door did unlock, as one shall expect. This means the doors can be opened remotely, without successful authentication! Can we abuse this feature?

We opened the dev tools in Firefox and started looking at the request sent out on click. For door 2, it was this (HTTP headers simplified).

PUT /something/provide-access HTTP/1.1
Host: access_control_server

{
	"content": {
		"entrances": [2]
	},
	"type": null
}

Readers familiar with web technologies probably spotted the same thing as we did. This is an HTTP PUT request which carries a JSON body. Probably the most important line is "entrances": [2] which tells the server which door to unlock. The brackets should be noticed: they tell us that this field does not expect just one number, it expects a list. So we tried editing the request like "entrances": [1,2,3] for all of the doors we had. We sent our new request and boom! All of the doors were unlocked at the same time.

At this point this is of course not an attack. It is just how this system works, even if a little twisted. Still, we knew that the password for the configuration website was very simple, just some lowercase letters. We combined our forged request with a brute-force password guess, and we already had an attack flow that

Obtained a session after a successful brute-force attack
Used that session to unlock every door, at the same time.

This attack only requires a malicious actor to be on the same network as the access control server. It was easy in our test environment but it can be quite hard inside a nuclear power plant due to all the security levels and zones as defined in IAEA NSS 33-T and national standards. In facilities having the usual 5 levels (1 being the strictest and 5 the least secure), such physical control systems go to level 2 or 3, meaning any attacker has to overcome at least three defensive boundaries before even starting the brute-force.

Attack to pwn the master control board #

After abusing the remote door opening feature, it is worth to step back and think about how it could work. Trivially, the server has to send some command over the network to the master control board, so that it can forward it to slaves. Thus, we wanted to take a deeper look at the master device and their link to with the server, to potentially make our attack more elegant or to find something else. Discovering open ports on the master seemed like a good start and nmap really provided us with valuable info.

It is important to say that one should not scan the network in an Operational Technology (OT) environment like this one. It could cause all sort of trouble, leading to outage which counts as a really painful event here. But this was a test system so we had nothing to lose.

$ sudo nmap -p- -sV -O 1.2.3.4       # IP address of the master control board
Starting Nmap 7.94 ( https://nmap.org ) at 2024-01-30 15:51 CET
Nmap scan report for 1.2.3.4
Host is up (0.0013s latency).
Not shown: 65528 closed tcp ports (reset)
PORT     STATE SERVICE      VERSION
22/tcp   open  ssh          OpenSSH 8.2 (protocol 2.0)
1099/tcp open  java-rmi     Java RMI
8081/tcp open  http-proxy   Ncat http proxy (Nmap 4.85BETA1 or later)
8181/tcp open  intermapper?
8182/tcp open  java-rmi     Java RMI
8183/tcp open  java-rmi     Java RMI
8184/tcp open  java-rmi     Java RMI
1 service unrecognized despite returning data. If you know the service/version,
please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port8181-TCP:V=7.94%I=7%D=1/30%Time=65B90D2D%P=x86_64-pc-linux-gnu%r(Fo
SF:urOhFourRequest,7,"\x15\x03\x03\0\x02\x01\0")%r(LDAPSearchReq,7,"\x15\x
SF:03\x03\0\x02\x01\0");
MAC Address: 01:02:03:04:05:06 (Redacted Manufacturer)
Device type: general purpose
Running: Linux 4.X|5.X
OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5
OS details: Linux 4.15 - 5.8
Network Distance: 1 hop

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 194.88 seconds

Java RMI stands for Java Remote Method Invocation. Given we knew that the software providing the web interface was written in Java, it was obvious that this was used for sending commands. Despite that, we did not investigate it as our team had no experience with Java RMI at that point, instead we found port 22 much more exciting.

OpenSSH version 8.2 was fairly new at that time and we could not find any easy exploits on that. So what does a hacker do next? Googles if some default credentials can be found. So we searched the term "[device name] default password" and we found some watermarked PDF which seemed to be some setup guide. And it had a default username-password combo!

Screenshot of a setup guide showing default credentials. Device names and brands censored.

Of course we tried these credentials and they worked like a charm.

$ ssh root@master_board
root@master_board's password: grolle

root@master_board:~# uname -a
Linux something_redacted 5.15.75-yocto-standard-custom #1 SMP PREEMPT Wed Oct 26 10:35:57 UTC 2022 aarch64 GNU/Linux

The master board looked like a Linux-based device with the hardware clock being more than a year off. It also had interesting commands, like

Vendor-related commands to see door event logs, edit configuration, etc.
Everything a small Linux system has, but including some other tools, we assume dependencies of the vendor stuff.
A command called getcve which unironically dumped CVE details of every vulnerability affecting any software component on the device, including its status (not affected/fixed/unpatched). This is actually a gold mine for any attacker. We could analyze this list containing hundreds of unpatched (!) CVEs to find other methods to attack. We suspect this command had been used for some auditing/debug purposes and had been accidentally left on the device after shipping.

What went wrong? #

It is important to say that our attacks worked in a small test system, albeit it was built using the same requirements as in a nuclear facility. So are nuclear facilities insecure now? No. In a real facility there numerous other defensive measures that would have stopped us, at least using our approach. Still, this story highlights how small misconfigurations and other weaknesses can cause a system to fail, even it is deemed very secure. Also, none of our attacks are really difficult or require great expertise. We have done much more complex things in other projects. Thus, it is crucial to understand what lead to these vulnerabilities and how to protect against them.

During our time, we discovered several small mistakes:

Weak (proprietary) protocol
Weak password
Default (and weak) password
Debug commands left on access control boards

None of these mistakes were made by the organization that purchased and used the system. They were made by suppliers, suppliers' suppliers and so on. The weak password for the web interface had been set by the system integrator, who probably assumed the end user will change it anyway. The default password for the master control board was also kind of a miscommunication, as the integrator just followed the setup guide issued by the manufacturer - which forgot to include saying anything about changing that password. In fact, when we asked the integrator about it, they didn't even know about the existence of an SSH access. These mistakes were (almost for sure) not made intentionally, it's just that humans work at every company and get things wrong.

So all of the vulnerabilities we could exploit come down to the supply chain, emphasising the importance of supply chain security. For the nuclear industry, the International Atomic Energy Agency has great guidance on defending against supply chain threats, which comes down to a formalized procurement process where the end user will check and verify its suppliers and purchased goods. To find out more about it, read the freely available document IAEA TDL-011.

Previous post: About Hashcat mask processing

Want to message us? Contact us: blog@ukatemi.com