Skip to main content

I'll have a Gamma Frappuccino, please.


A recent story has been making the rounds: "Hundreds of Nuclear Radiation Monitors Were Allegedly Hacked by Former Repairmen".  Basically, it seems that more than a year ago  two disgruntled employees sabotaged +300 radiation monitoring devices, which were part of a nation-wide civil radiation monitoring network (RAR) in Spain. On top of that, they were apparently using the free WiFi of a Starbucks to carry out their activities. Obviously not being the sharpest tool in the box they were eventually caught.

In this story there is a boring part, which is everything related to these guys and their motivations, and a slightly more interesting part which is the underlying technology behind Radiation Monitoring Networks (RMN).

In 2017 I presented at BlackHat USA 'Go Nuclear: Breaking Radiation Monitoring Devices", so I thought  it could be interesting to write a brief post to provide some context.

The NeverEnding story

As in most 'disgruntled employee' attacks, the initial motivation behind the sabotage seems to be a 'poorly assessed' reaction to a troubled employment relationship. 

According to the information publicly released by the police the attacks started on March 2021. Coincidentally, by using the public procurement portal of the Spanish State, we can find that, in 2020, a public contract to support and maintain the RAR network was announced, as the valid one at that time was about to expire in Feb 2021.  

Anyway, if you're interested in the technology,  public procurement documents always provide a lot of information when you are researching into nation-wide systems. As expected, it is possible to find some interesting bits of information about the RAR network, including its topology, devices, deployments...


The radiation monitoring devices are provided by Envinet. Indra seems to have developed some Data Acquisition Units as well as the Control System.

Sensor Units - Envinet

Data Acquisition Units - Indra


A simple search provides some additional information about these DTUs.

https://www.indracompany.com/sites/default/files/dtu_0.pdf

This also seems to match with some  documents from Envinet


If we take a look at the location of the sensor deployments, provided in the procurement document  (Page 23), and map them to a Shodan search for Envinet devices, almost no one is going to be surprised by the fact that, at least, 22 stations of the RAR network were recently exposed to the Internet. For instance, in the image below, we are mapping the station identified  by 'ESCALONA' (a small town in Toledo, a province of Spain), to an Envinet device geo-located to 'El Casar de Escalona', a small town in the same province.



I think we have had enough from the RAR network; a civil network with some legacy devices where, I assume, a questionable password policy is in place. In addition to this, it is likely maintained by a chain of contractors...

Fortunately, as in any other system supporting safety operations, there is no single point of failure so even if the entire RAR network had been wiped out, other networks would have noticed if something really bad was going on.

So the most interesting thing so far is how ubiquitous Envinet systems are (shodan also provides a glimpse into Envinet's NMC system), especially in Europe, but also world-wide. As a result, Envinet products and devices seem to be an interesting target.



Attacking Radiation Monitoring Devices

Radioactivity is invisible for the human eye so, as in many other industrial processes, we're essentially relying on the output from a system able to analyze, on our behalf, what is going on in our environment.

Thus, in the context of Radiation Monitoring Instruments,  their 'output' will have two main purposes:

1.- Provide data to be consumed by operators

2.- Provide inputs to safety systems

As a result, when I was researching into RMN five years ago, I mainly focused on just two kinds of attacks, which are outlined below. It is important to note that in both cases, the motivation for performing the attack is pretty extreme, so we would be essentially talking about scenarios derived from 'profound conflicts' between nation-states or  sophisticated terrorist attacks.

1. - Hide what is happening

By far, this first scenario is usually the worst, as we have to assume the attackers are trying to hide abnormal radiation levels, so we would be  already facing a pretty bad ongoing situation. This secondary attack against the RMN would be only aimed to increase the impact of the primary attack.  

However, there are some other scenarios, where someone would want to hide abnormal radiation levels just transiently, for instance in radioactive material smuggling scenarios.

Back in 2017, I looked into some of the Radiation Portal Monitors deployed at US borders, checkpoints or secure facilities, finding backdoors, insecure protocols and the usual stuff.

In addition to borders and ports, Nuclear Power Plants (NPP) are the most common facilities where RMDs are found.  However, if a malicious actor is trying to hide abnormal radiation levels in a NPP, quite a few systems need to be compromised.  

https://www.blackhat.com/docs/us-17/wednesday/us-17-Santamarta-Go-Nuclear-Breaking%20Radition-Monitoring-Devices-wp.pdf (Page 13)

Therefore, a real-world attack against RMDs in a NPP would likely lie in the next scenario instead.

2. - Show what is not happening

This scenario covers those attacks whose nature is primarily 'cyber'. As I mentioned before, when talking about radiation, our assessment of the situation highly depends on a Radiation Monitoring Instrument's output.

If you can control that output, you could potentially trigger a response that does not correspond to the actual conditions the system is operating at. For instance, in the context of a NPP, the implications of this scenario can be divided in:

- How humans will behave according to the information they are getting 

When the operators are reacting to falsified radioactive leakage alarms according to the defined Emergency Action Levels. (i.e Three Mile island incident)

- How safety systems (Class 1E) will react

These systems are provided to ensure the safe shutdown of the reactor or residual heat removal, or to limit the consequences of anticipated operational occurrences.

Final thoughts 

In 2017, I  managed to compromise the RF security scheme used in RMDs from Mirion, based on Digi's XBEE. This attack allowed to forge arbitrary radiation readings, thus enabling the attackers with the ability to implement some of attacks covered in the scenarios we have been discussing.

https://www.blackhat.com/docs/us-17/wednesday/us-17-Santamarta-Go-Nuclear-Breaking%20Radition-Monitoring-Devices.pdf (Slide 18)

In general terms, we should also assume that most of the commercial RMDs out there, and their corresponding networks, are probably an easy target for malicious actors with a strong motivation and plenty of resources.

Although, technically, two guys at a Starbucks disabling the communication of a civil Radiation Monitoring Network endangers the ability to detect if something bad is going on,  it may seem worse than it actually is. 

On the other hand, I think that the worst-case attack scenarios against this kind of networks are those intended to falsify the 'reality', thus tricking the victim (either operators or safety systems) into triggering a predefined procedure (i.e shutting down a reactor) which has been designed for different conditions.

























Popular posts from this blog

De-Anonymization attacks against Proton services

  In November 2021 YesWeHack invited me to participate in a private bug bounty program organized by  Bug Bounty Switzerland on behalf of Proton AG.  The scope of the program was quite interesting and heterogeneous, as it covered most of the applications and services offered by Proton, such as ProtonMail and ProtonVPN. As a result, multiple technologies and codebases were in scope, ranging from typescript, in the open-source part of Protonmail, to .NET/Swift used by ProtonVPN apps for Windows and macOS respectively. Proton is well-known for its privacy-driven services offer, so they are based on Switzerland where the legislation seems to match Proton's requirements to provide that kind of services: thus maximizing the privacy of their communications, minimizing the amount of data they log from their users while keeping a law-abiding status.  It wouldn't be realistic to think of Proton users as an homogenous group; you may be using Proton because you're genuinely w...
Read more

What Really Happened in Chernobyl During the Beginning of the Russian Invasion?

This blog post contains the web version of my research paper: " Seeing Through the Invisible: Radiation Spikes Detected in Chernobyl During the Russian Invasion Show Possible Evidence of Fabrication ", which was unveiled at BlackHat USA 2023 . It is intended to ease the indexing and dissemination of the information collected during this research.  In a few days, I'll be in Brussels presenting this research.  The original paper (PDF) can be downloaded here . Additional references: https://www.wired.com/story/chernobyl-radiation-spike-mystery/  (Kim Zetter) https://www.zetter-zeroday.com/p/radiation-spikes-at-chernobyl-a-mystery  (Kim Zetter) https://medium.com/war-notes/chornobyl-3-92216d21b223  (Olegh Bondarenko) INDEX Foreword Executive summary Introduction 1. Physical      1986      Resuspension      Transport      Humidity      Traffic 2. Cyber    ...
Read more

Finding vulnerabilities in Swiss Post's e-voting system: part 3

Exactly two years ago I brought my blog back to life, after many years of hiatus, with " Finding vulnerabilities in Swiss Post’s future e-voting system - Part 1 ". That was the first of a series of blog posts covering that system. During these two years I've been periodically assessing the security posture of this e-voting solution, as part of their Bug Bounty program , which I personally recommend.   Since the first time I reviewed their codebase a lot of things have changed, for good, as many areas have been dramatically improved. To be honest, from a security perspective the codebase back then was kind of a mess.   When the first Swiss Post e-voting platform was published, back in 2019, it faced some public scrutiny, mostly from the academic community.  As a result, some significant issues were uncovered , so eventually Swiss Post decided to suspend the deployment of the system. That first version had been developed by Scytl , Spanish company specializ...
Read more

Beware of Java's String.getBytes

Sometimes there are subtle bugs whose origin can be found in some quirks from the underlying language used to build the software. This blog post describes one of those cases in order to let both fellow security researchers and developers, who didn't know about it, become aware of this potential vulnerable pattern. In fact, I'm pretty sure that similar bugs to the one herein described likely affect a bunch of products/codebases out there. In previous posts , I've already described some bugs in the Swiss Post's future E-voting system. While reading their  Crypto-Primitives specification , which among other things describes the custom Hashing algorithm Swiss Post implemented, I noticed something potentially interesting. Basically, there are 4 different types that are supported: byte arrays, strings, integers and vectors. Before being hashed, strings are converted to a byte array via the ' StringToByteArray ' algorithm. However, by comparing ' StringToByteArray...
Read more

Losing control over Schneider's EcoStruxure Control Expert

  During Q2 2022, in view of the geopolitical situation that unfolded after the Russian invasion of Ukraine, I decided that it wouldn't do any harm to kill some bugs in some of the main players within the ICS arena. I focused in those software frameworks that are running on the engineering workstations so, if compromised, attackers would be in a privileged position to manipulate controllers logic, thus enabling sophisticated attacks with a potential physical impact (i.e triton). I responsibly reported a bunch a unauthenticated remotely exploitable bugs to the corresponding vendors. In one case, after being ignored for months, I had to resort to the 'twitter, do your magic' approach and tweeted that I would be disclosing the issues if the situation persisted. It took just few hours for the vendor to get back to me. The positive side is that they found the bugs interesting and all that mess ended up in paid work.   This blog post covers a similar scenario in a different ven...
Read more