Critical Vulnerabilities Discovered in Automated Tank Gauge Systems

Introduction

Industrial Control Systems (ICS) have become a ubiquitous part of modern critical infrastructure. Automatic Tank Gauge (ATG) systems play a role in this infrastructure by monitoring and managing fuel storage tanks, such as those found in everyday gas stations. These systems ensure that fuel levels are accurately tracked, leaks are detected early, and inventory is managed efficiently. Although the typical gas station comes to mind when thinking about fuel tanks, these systems also exist in other critical facilities, including military bases, hospitals, airports, emergency services, and power plants, to name a few.

Recent investigation by Bitsight TRACE has discovered multiple critical 0-day vulnerabilities across six ATG systems from five different vendors. These vulnerabilities pose significant real-world risks, as they could be exploited by malicious actors to cause widespread damage, including physical damage, environmental hazards, and economic losses. What’s even more concerning is that, besides multiple warnings in the past, thousands of ATGs are still currently online and directly accessible over the Internet, making them prime targets for cyberattacks, especially in sabotage or cyberwarfare scenarios.

Bitsight strongly believes in responsible disclosure of vulnerabilities. For the past six months, Bitsight has been collaborating closely with the U.S. Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA), as well as with affected vendors, in order to mitigate these vulnerabilities. This coordinated effort aims to safeguard critical infrastructure and prevent the dire consequences that could result from successful attacks. CISA published remediation advisories for interested parties.

In this blogpost, we will explore the ATG systems, their inherent risk when exposed to the Internet and the several critical vulnerabilities uncovered by Bitsight TRACE. By understanding these vulnerabilities, we hope that the reader can better appreciate the urgent need for enhanced security measures and the steps that need to be taken to protect these systems from exploitation.

What is an ATG system and why it matters

Automatic Tank Gauging refers to a system that automatically measures and records the level, volume, and temperature of products in storage tanks, such as gas stations fuel tanks. It can also monitor leaks, issue high-level and low-level alarms, trigger sirens, emergency shutoff valves, ventilation, fuel dispensers and other peripherals. The ability to control physical processes is made by interfacing with the internal or external relays. This technology helps ensure compliance with environmental regulations and is used to optimize inventory management at a gas station or other facilities that store fuel (hospitals, airports, military facilities).

There are several brands and models of controllers that are commonly used in Automatic Tank Gauging systems. Our research focused on some of the brands and models most commonly found online. It is by no means exhaustive, but we considered a good first approach to the issue.

Part of what makes these devices attractive to security researchers, or a malicious actor for that matter, is the potential ability to control physical processes that could lead to disastrous consequences if they are abused in unintended ways.

What Happens When ATG Systems Are Abused

So what could happen when malicious actors gain access to an ATG system with full privileges? Depending on the abused functions, the actual physical installation of the device, and the lack of mitigating controls, the consequences could be disastrous. It is a concern that vendors acknowledge and some even issued warnings about such consequences in the past. To cite one of the vendors:

“WHAT CAN HAPPEN IF YOU DO NOT TAKE OWNERSHIP OF YOUR NETWORK?

1. Rename Tank Information: On consoles using Telnet, hackers find the MAC address, determine whether it is a TLS-350 or TLS-450PLUS and simply change the tank names to something inappropriate.
2. Resize Tanks (From 10K to 20K Gallons): It is possible to change the tank size, so it appears the tank can hold more than it really can. The thresholds could also be changed so that overflow alarms appear at a higher level. The potential would be to overfill the tank causing an environmental leak.
3. Shutdown Dispensing (PLLD and Relay Settings): The relays could be deprogrammed so that the pump wouldn’t be activated on a hook signal. Additionally, PLLD could be turned off so catastrophic leaks may not be detected.
4. Capture Sensitive Corporate Data: By monitoring insecure Telnet connections, observers can gather operations data (delivery, inventory, alarms, etc.) for sale to third parties.
5. Shutdown IP Cards / Networking Services: After gaining access to a vulnerable corporate network, hackers could alter TLS-350 Ethernet cards lacking passwords; changing configurations and rendering management systems ineffective. Critical operations could be impacted (hospitals, emergency providers, cell service, power plants, etc.).
6. Loss of Compliance Data: Reprogramming the console could result in the loss of compliance data translating to potential regulatory fines.”

While the vendor refers to a specific product and version, these warnings are likely applicable to others, as most ATG systems share many of the same features. An administrator user on another ATG system also has the ability to perform some, if not all, of these actions with similar impact. In fact, most of the vulnerabilities we discovered allow for just that: for an attacker to have full control of the ATG as administrator!

Based on feedback from manufacturers of ATG equipment, we recognize that owners and operators may implement mitigating controls, external to the ATG systems themselves, that would prevent the worst case scenarios from occurring. In certain jurisdictions, for example, owners and operators are legally required to reduce the likelihood of spilling or overfilling – and many may have taken measures to do so. Nevertheless, it is important to share information about the potential consequences of exploitation so that owners and operators are aware of the risks.

Past Security Research

ATGs were already mentioned in the past as vulnerable systems, as far back as 2015. In January that year, H.D.Moore published in the Rapid7 blog an article titled: “The Internet of Gas Station Tank Gauges” based on Jack Chadowitz research on ATGs. The article stated:

"Approximately 5,800 ATGs were found to be exposed to the internet without a password. Over 5,300 of these ATGs are located in the United States, which works out to about 3 percent of the approximately 150,000 [1] fueling stations in the country.”

In August 2015, Trend Micro published “The Gaspot Experiment: How Gas-Tank-Monitoring Systems Could Make Perfect Targets for Attackers.” Instead of probing the landscape, Trend Micro took another approach:

”To better understand the current gas-tank-monitoring system attack landscape, we developed a way to simulate the existence of these devices to check whether threat actors will find them venues attractive enough to go after. […] These are essentially gas tank-monitoring system honeypots, hence the nickname, “GasPot.”

Later on, there were two follow up Rapid7 articles, one in November 2015 and another in November 2016, led by Jon Hart, who also produced an ATG client module for Metasploit which implements some basic TLS-250 and TLS-350 commands.

In November 2022, a company called Cyborg Security raised the alarm again in a blogpost. Their conclusions were clear:

“For an attack surface of critical systems to increase by nearly 120% over 7 years is unacceptable.”

These legacy issues were essentially about the so-called “ATG protocol.” We will share our insights about this protocol and why it is not safe by design before we dig into the other new, vendor-specific, vulnerabilities.

Why We Are Researching ATGs

Critical infrastructure sectors have come to heavily rely on Industrial Control Systems (ICS) to control cyber-physical systems. If you have been following our TRACE research blog posts, you might have already realized that Bitsight has been setting up an ICS laboratory for a while. We hinted at that in the recent ICS introduction article. It serves several purposes, one of which is helping us to properly and safely identify an increasing number of ICS devices that are reachable via the Internet. Ever since I wrote about the different ICS protocols and the thousands of exposed ICS systems, one protocol caught my attention: ATG.

The ATG protocol appeared as having a high prevalence, with several thousand devices online and reachable, which I knew nothing about. This was a perfect target on which to conduct research within our ICS lab.

The Legacy Issues

Before we dive into the new vulnerabilities we found, it is important to stress the impact of the old ones. As we’ve mentioned, security researchers warned about the “ATG” protocol being exposed in different ATG systems. It appears there are references to this protocol described in multiple ways, such as the Veeder-Root protocol, Gilbarco protocol or TLS protocol. In fact, the Veeder-Root TLS series has excellent documentation about the protocol.

The protocol itself seems to have been designed for the serial RS-232 interface, which is normally used to connect the system to a controlling computer. When an ATG system is connected to a network (either via a modem or ethernet card), a TCP/IP port (default 10001) is listening which essentially mirrors the serial interface behavior over a socket. So by directly connecting to the TCP/IP port and calling the desired functions in the right format, an attacker can simply use the system as if he was using an RS-232 cable.

By analyzing the detailed TLS manuals, it is possible to gain a deeper understanding about the protocol features. The Veeder-Root TLS-450 Serial Command Manual has over 600 pages and documents almost as many different functions. It is not exactly clear which devices implement which functions, but we’ve seen many other ATGs implement this protocol to expose some of the functions defined in the manual. There are several functions that allow for settings and parameters to be changed that might have a security implication in some way, shape or form.

Furthermore, the protocol seems to be insecure by nature and cannot be fixed without changing the specification itself, since the only security feature it contains is a code in each command message:

This security code is, however, both optional and insufficient. By default, it is not used, perhaps because some models require manual dip-switch configuration to enable the feature to begin with. There also seems to be conflicting information about what is considered an acceptable security code. The security code is described as a six digit code. It makes sense if you consider that the older models had a numeric keypad. This yields about 1,000,000 combinations, a code that can nowadays be trivially guessed. An attacker able to try a modest amount of 100 combinations per second would need less than 3 hours to iterate over the entire code space. Further research, however, indicates that at least in newer models like the TLS4B, we were able to confirm that these actually accept more than only numbers:

This increases the search space considerably, although the fact remains that it has a maximum of 6 characters.

These are some of the actions that could be performed by an attacker via the protocol:

1. Network related configurations (DoS, traffic monitoring, firmware updates,etc)
   1. Change DNS server / gateway
   2. Change contact numbers and alarms destination (silent alarms, trigger alarms to paid numbers)
2. General configurations
   1. Delete/change automatic events
   2. Change product labels (ex. switch diesel for gasoline)
3. Physical related configurations
   1. Change tank volume/diameter/tilt/limits/other parameters (spillage)
   2. Change pump control devices and parameters
   3. Change relay, relay types and configurations (potential physical impact)
4. Other actions
   1. Start/stop In-Tank Leak Detection Test
   2. Start/stop pressure line leak detection test
   3. Remote reboot (and DoS by looping the reboot command)

In a nutshell, those actions can lead to the disastrous consequences to which the vendors warned about. This is why it is paramount to disconnect any ATG from the Internet. Still, looking at the last month alone we can find 6,542 devices (excluding GasPots) directly connected to the Internet without any security code at all.

Discovering New ATG Vulnerabilities

All these features make the ATG protocol a potential target for attackers. It looks and feels like a legacy serial protocol that was just given the ability to become online. That alone would make it an interesting target for an attacker.

But what about other ATG systems? ATGs that don’t necessarily communicate using the old “ATG” protocol. What interfaces do they provide? Are they also exposed over the Internet? And, more importantly, are they more secure?

These were the kind of questions that Bitsight TRACE set out to find out, so we leveraged our ICS lab to better understand the risks that these devices pose.

In one single but intensive week, we’ve found multiple vulnerabilities in several different devices. To be more precise, 11 vulnerabilities in 6 different models, each one underscoring the critical need for better security practices. Of the 11, one was found to be a duplicate of an existing vulnerability. Here’s a summarized view of what we found:

It is not the number of new vulnerabilities that is most concerning, and probably not even their criticality, but that they reflect fundamental security flaws that should have been addressed long ago. CISA, in their advisory on Categorically Unsafe Software, describes that focusing on quality and eliminating groups of errors improves security. They cite Steve Christey from MITRE, who published a paper in 2007 describing the “unforgivable vulnerabilities” and the criteria that they obey. In short, all these new vulnerabilities fit these criteria.

We found vanilla Reflected XSS. The authentication bypasses were direct path access. The command injections lacked filtering. There were hardcoded administrator credentials. The arbitrary file read was a direct path traversal access, yielding admin credentials. The SQL injection could be exploited aided by full SQL error logs.

All these vulnerabilities allow for full administrator privileges of the device application and, some of them, full operating system access.

The reader might ask, why do we keep encountering these types of vulnerabilities in ICS devices? Well, there are a number of reasons. Designing and maintaining ICS systems presents additional challenges compared to pure software systems, and even IoT devices. To start, many ICS systems were designed decades ago, long before cybersecurity was a big concern. These systems were built to prioritize reliability and efficiency, not security. As time goes by, they do get new features but usually they are not completely designed from scratch. As a result, they often lack modern protections. In addition, many of them were not designed to be connected to a hostile environment like the Internet. Vendors recently started to integrate them with newer technology to improve efficiency and remote access and this significantly changes their threat model. Of course, there is also a lack of cybersecurity experts that are familiar with ICS systems. It is hard to find vulnerabilities if no one is looking for them.

From DoS to Physical Damage: The Impact of ATG Exploitation

What exactly is the potential impact associated with these vulnerabilities?

Denial of service

The simplest attack that can have a significant impact is simple DoS by reconfiguring the system, deleting values or reflashing the device with faulty firmware. These changes would effectively disable the device, lead to downtime and would usually require human intervention. In fact, these types of attacks are currently ongoing, with claims of exploitation of at least one brand of devices for which we published a vulnerability on just two weeks ago.

These types of attacks, conducted at scale, can be highly effective in disrupting day to day operations.

Physical damage

More sophisticated attacks target the actual purpose of the ATG systems – the monitor and control of fuel tanks and their peripheral systems. Our research shows that attackers can easily change critical parameters that may result in fuel leaks, such as tank geometry and capacity. It is also possible to disable alarms and the respective actions that are triggered by them, both manual and automatic ones (such as ones activated by relays). But perhaps the most damaging attack is making the devices run in a way that might cause physical damage to their components or components connected to it. In our research, we’ve shown that an attacker can gain access to a device and drive the relays at very fast speeds, causing permanent damage to them.

On the right, a relay used in one of the models we tested (Maglink LX4) in a test rig. Who knew that driven very fast, if they are serving a high enough load, a relay can become a lightbulb? (albeit for a short amount of time, once the magic smoke is emitted it fails to be a lightbulb or a functional relay) Of course, not all device relays will be affected in this spectacular fashion, especially if they keep within the voltage and current that their specifications allow. They will, however, reach their operational limits pretty fast and eventually will stop working.

This can be done in several ways, achieving different speeds and results, ranging from using the ‘ATG’ protocol, custom programs run on an ATG after system access, and even by living off the land tools. Living off the land refers to an attacker behavior that uses tools or features that already exist in the target environment. An example of living of the land tools, in the Maglink LX4 case, would be using i2c instrumentation:

        root@imx6ul-var-dart:~# i2cdetect -y 0
             0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
        00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
        10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
        20: 20 21 -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
        30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
        40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
        50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
        60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- UU 
        70: -- -- -- -- -- -- -- --                                               
        root@imx6ul-var-dart:~# i2cdump -y 0 0x21
        No size specified (using byte-data access)
             0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
        00: 00 ff 00 00 00 00 00 00 00 00 20 20 00 00 00 00    ..........  ....
        10: 00 00 0f 00 0f 00 00 00 00 00 00 00 00 00 00 00    ..?.?...........
        20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        ...
        root@imx6ul-var-dart:~# while true; do i2cset -y 0 0x21 0x14 0x01; i2cset -y 0 0x21 0x14 0x00; done

The above commands would drive the relay #1 to turn ON and OFF over 50 times per second.

By reading the relay (OMRON G6S-2) datasheet, we can have an idea of how long it will take to exceed the component service life. The rated mechanical service life is 100,000,000 operations min. (at 36,000 operations/hour). The electrical service life is much lower, in the order of 1,000,000 operations at best, i.e. using the lowest operating current.

At 50 operations per second, it would take around 6h to reach the electrical service life, after which the relay would break down at any time and would be stuck in an ON or OFF position.

We did, in fact, also test these conditions in our lab and we must say we were very impressed with the performance of the relays used in the Maglink LX4 - the OMRON G6S-2F. In our setup, we stayed with the range of the technical characteristics defined by the vendor:

We toggled the relay ON and OFF, at around 50 times per second, to simulate what we could achieve by using living off the land tools. Initially, we ran the tests without any load for ~9.5 hours (1.729.084 operations). The relay performed flawlessly. Then we proceeded to apply a 2A, 30V DC load. This time the relay performed well the first 4 hours, then started to exhibit some hiccups, and finally it failed after around 6.25 hours (1.123.520 operations). Looking at the relay datasheet, this was an heroic performance. For that operating current, it should have failed in less than an hour (per specs). Nevertheless, in little over 6 hours under load, it inevitably failed and got stuck in the ON position.

Another example geared towards ‘ATG’ protocol speaking devices, albeit slower if using it over the Internet, would be using the function code 809, which allows for setting the relay orientation.

By toggling the orientation of a relay, the side effect is to actually turn the relay on or off, depending on the default orientation of the relay (either normally open or normally closed) and the actual state it should be.

Regardless of the way an attacker might be able to toggle the relays and damage them, the damage to the peripherals connected to them might be much more serious. Ventilations systems, emergency shutoff valves, alarm sirens and pumps are just some of the devices that can be connected to the relays which likely won’t react nicely to being turned on and off several times per second.

These were just some examples of how an attacker can cause physical damage to ATG systems. In practice, each system will have their own characteristics and limits, depending on the hardware used and level of access that the attacker has. But the idea remains the same, an attacker can use the hardware in a way that is clearly out of specifications, in order to cause physical failure of some components and/or peripherals.

Experts that we have spoken with expressed specific concern about the ability for an attacker to change tank settings remotely. Alarms are very important for refilling operators to understand when the tank is about to be full and to have enough time to stop the refilling. Without alarms the probability for a spill will increase significantly, which, depending on the type of fuel, could create a dangerous situation.

Indirect damage

Other stealthier actions can be taken by attackers with different intentions. For example, it is possible to monitor sales and get financial insights about sales in gas stations. It is also possible to simply delete an entire tank before proceeding to silently steal the fuel, an increasing trend. Or monitor fuel levels in critical infrastructures to decide the best time to conduct a kinetic attack. Or even plainly use the device as a means to pivot into internal networks. The possibilities are vast and the implications extremely worrisome.

Global Prevalence: Interactive Map

We could find these kinds of devices everywhere around the world, although there are clear concentrations in some countries more than others. In addition, some areas are more biased towards a particular brand and vendor. One can explore both the number of devices speaking the ‘ATG’ per country and the geographical distribution of the new vulnerabilities we’ve mapped so far in the interactive map below (the position is approximate and anonymized).

Among the organizations affected by these new vulnerabilities, we were surprised to find airports, government systems, manufacturing and utilities companies, to give some examples. One thing is clear, regarding ATG systems in general and these new vulnerabilities in particular: the US is the most affected country by far. Bitsight is working with CISA in order to raise awareness and warn the owners of such systems of the dangers of having them exposed to the public Internet.

We began to monitor these vulnerabilities at scale back in June, including the duplicate vulnerability we found. Three months past and we can’t say that we see a significant change in terms of exposure, as we can see in the chart below.

Our hopes are that we can contribute to lower these numbers, as we continue to raise awareness on this subject and work with the relevant organizations to highlight the importance of mitigating these vulnerabilities. Bitsight will continue to monitor the evolution of the situation going forward.

Coordinated Vulnerability Disclosure

Bitsight believes in responsible vulnerability disclosure. Given the number of vulnerabilities we discovered impacting different vendors and the importance of these devices to critical infrastructure, we engaged the U.S. Department of Homeland Security's Cybersecurity and Infrastructure Security Agency (CISA) to help coordinate the vulnerability disclosure process.

All new vulnerabilities described were disclosed on March 21, 2024. For 6 months, CISA has been leading a coordinated effort to inform vendors of these vulnerabilities and work collaboratively on remediation efforts. Bitsight wanted to provide all vendors with ample information and time to remediate issues prior to public disclosure.

Our joint publication ensures that organizations have the information they need to proactively protect themselves.

Why ATG Systems Must Prioritize Cybersecurity

Given all these vulnerabilities, attack scenarios and potential impact, will we start to see fuel tanks blowing up in the next news cycle? Probably not. For an attack like this to occur successfully a set of very specific circumstances would have to align, some of them outside of an attacker's control. Regardless, we should take a lesson from history. As we saw in the Colonial Pipeline attacks, it is not so much the actual impact on the infrastructure, but the perception of such impact and the general public reaction. The pipelines were shut down out of precaution, but it was probably the panic buying that followed in the days after that had the most effect on society. We believe that this would be the most likely scenario in case of mass attack on ATG systems. And in this case, to make matters worse, actual physical damage may occur, and that would significantly increase the downtime of such systems.

We do understand that ICS vendors face significant challenges in balancing security with system reliability. ICS systems often control critical infrastructure where downtime can cause major, highly problematic disruptions. Many of these systems are outdated and, at the same time, difficult to update, forcing vendors to ensure new security measures are compatible with legacy technology. Additionally, vendors must address increasing regulatory requirements, manage vulnerabilities in their supply chains, and keep up with an evolving cyber threat landscape in a product that was designed to reliably work for long periods of time. The long lifecycle of ICS systems and investing in and adopting newer technologies, as well as customers’ resistance to change further complicate the vendor’s ability to maintain secure and reliable products. Not to mention the high cost of implementing robust security measures, which sometimes call for a complete product remake. Despite all these challenges, one thing is certain: change needs to happen.

So what can be done? As the industry moves towards a “secure by design” philosophy, these findings highlight the urgent need for action, not only in this specific field of ATGs but in the ICS ecosystem as a whole. It’s not just about fixing vulnerabilities, it’s about adopting security practices that make them difficult to exist in the first place. And it is not just about the vulnerabilities themselves, it's about their exposure. Organizations need to understand they should not expose these types of critical systems to the public Internet. They need to effectively assess their exposure, understand their current risk and start addressing such issues, regardless of vendors ability to update their systems in a timely fashion.

For industrial control systems in general and ATGs in particular, with all their peculiarities and challenges, the road ahead is clear: security must become the foundation, not an afterthought. The price to pay otherwise can become just too high.

Recommendations to Safeguard ATG Systems

We’ve covered the overall recommendations about ICS systems in the past and we will reiterate them here. An ATG system should be treated as any other ICS.

For security leaders

Organizations should immediately engage in outreach and remediation efforts:

• Identify any ATG deployed by your organization and/or your third-party business partners, and promptly assess the security of these systems.
• Remove any ATG from the public internet.
• Employ safeguards like firewalls to protect against unauthorized access to your ATG systems.
• Security leaders must acknowledge the unique control needs that apply to OT including industrial control systems rather than just apply a traditional IT risk model to this infrastructure.

For manufacturers

Manufacturers of ATGs must take action to increase the cybersecurity of their devices, not only in their internal software development life-cycle, but also throughout their supply chain. Just earlier this year the U.S. Department of Energy’s (DOE) Office of Cybersecurity, Energy Security, and Emergency Response (CESER) published a set of the principles with input from leading ICS manufacturers and asset owners who participate in CESER’s supply chain research and development, and drawing from research and insights at Idaho National Laboratory, which characterize the foundational actions and approaches needed to deliver strong cybersecurity throughout the vast global supply chains of industrial control systems. In addition, manufacturers should work with their customers to ensure the proper configuration and security of already deployed devices.

Although broader in scope than ATGs, ICS manufacturers are leading with innovative initiatives to enhance the security of their devices and their customers. For example, Schneider Electric has made device security and customer security a business priority. Through a joint effort with Bitsight, Schneider Electric is working to identify externally observable risks to the OT community and engage customers in remediation initiatives. Manufacturers should follow Schneider Electric’s lead and take steps to:

• Use secure-by-design principles to develop more secure technology.
• Improve the security posture of deployed equipment and machinery by leveraging data and insights.
• Promote the importance of end users securing their operations, thereby reducing their exposure.
• Build programs to accurately and swiftly detect misconfigured or otherwise exposed systems.

For government policymakers

The exposed ATG systems identified in this research should alert policymakers to the current state of ICS — and more broadly, OT — security. Due to the potentially serious consequences resulting from incidents involving industrial systems, policymakers should:

• Understand the risks of exposed industrial control systems, including ATGs, particularly those involving critical infrastructure.
• Inform national security strategies and programs to include adversarial threats targeting operational technology, and how an industrial cyber attack could impact national security and human safety.
• Quantify the impact — financial and otherwise — that a cyber attack targeting industrial infrastructure could inflict on national, regional, and local economies as well as diplomatic relationships.

If you believe you may have an issue, please contact Bitsight so we can help.

Acknowledgements

Coordinating multiple vulnerabilities from different vendors is a challenging task. Our close collaboration with CISA was essential for the success of a responsible disclosure process. We would like to extend our sincere thanks to the CISA team for their assistance in this process. We would also like to acknowledge the steps that vendors have taken to improve the security of their devices. Thank you to Ben Thomas for sharing his perspective on the impact of vulnerability exploitation. Ben is an experienced practitioner who has been working with tank operators, regulators, inspectors and service providers for nearly 40 years.