Exposed Cloud-Storage Services Leak OT/ICS Data Too

Executive Summary

• Cloud-based storage services such as Amazon S3 buckets have been left unsecured and numerous data leaks have resulted.

• Team82 found some exposed S3 buckets that contain ICS project files. Others contain photographs of factory floors and equipment.

• While most of these files are old and likely out of date, it illustrates the risk posed by leaving cloud storage services exposed.

• Stolen OT project files can allow an attacker to blueprint a network and build attacks accordingly.

Poorly configured Amazon S3 buckets have been at the core of many embarrassing data leaks in recent years, as giant mobile companies, military contractors, and financial and consulting firms among many others have publicly exposed sensitive customer information, internal business documents, and even voter registration records.

Most of these leaks have largely been contained to personal and business information, yet that may be shifting to include data relevant to operational technology (OT) networks and industrial control systems (ICS). Specifically, some organizations are storing ICS project files inside varied cloud-storage platforms, and if access control lists and policies guarding these buckets are not configured properly, an attacker can quickly assemble a blueprint of an OT network and strategize attacks.

Team82 has found some exposed buckets storing ICS project files, and in some cases, photographs of factory equipment and shop floors. The data in these specific cases is old, and the integrators who owned them are out of business or otherwise unreachable. Claroty has shared the information with the Industrial Control System Computer Emergency Response Team (ICS-CERT) in an attempt to facilitate disclosure.

In the meantime, OT network operators must be made aware of the risks and not only understand how simple it is to leak information from an S3 bucket, shown above, but also the need to protect ICS project files.

What are ICS Project Files?

Project files are files or directories created within engineering stations. They are software programs used by engineers to monitor, configure, and communicate with programmable logic controllers (PLCs) and other ICS gear. Project files include program logic that governs ICS devices and oversees processes, and also may include network configuration data and, at times, a complete OT network layout.

An attacker with the ability to access and parse project files can understand how to forensically analyze an OT network. Such an examination can render vital information, not only about the network, but also about assets (IP address, MAC address, device serial numbers), as well as network-related attributes and indicators that reveal more about the company and industry in which it's running.

All of this information is useful to an attacker assembling malware or exploits, for example. Exposed buckets that contain project files may indicate not only the software running on an OT network, but also version numbers that might simplify intelligence gathering around vulnerabilities related to certain products and versions. If exploits for specific flaws have been shared publicly or are available through an underground marketplace, this exacerbates the threat to an organization, and thus presents a risk that must be managed.

Configuration files may also contain critical I/O variable mapping information. This is key, not only in understanding how to connect to a PLC, but more importantly, understanding process-related information and which variables can be changed to disrupt or affect processes. Attackers may use configuration files to learn addresses and variables depending on the specific protocol supporting it, and therefore, conduct attacks relevant to the specific implementation. Addresses and variables are crucial to an attacker, because they are what differentiates projects and can eliminate the need to enumerate addresses.

This information may also make attacks much less noisy once they're executed, and therefore, more challenging to monitor for and alert against. An attacker with a network foothold via phishing or some other exploit and in possession of a complete OT network layout, for example, would not have to scan the network for other machines or open ports. By having a familiarity with internal assets and an understanding of available pathways to their targets, an attacker would be able to gather dedicated attack tools in advance in order to drop ransomware, steal data, or otherwise disrupt processes.

Given the potential impact of the attack methods described above, it's critical for OT and ICS operators to understand the importance of keeping project files protected and secret. Not only is it an unacceptable risk to expose them via publicly accessible S3 buckets, but project files should never be uploaded to engineering forums, below, and other arenas where engineers gather, share information, and help each other solve problems.

Tools such as Claroty's AppDB, a passive scanner integrated into our Continuous Threat Detection (CTD) product, may be used to dissect project files without actively scanning an OT network. Unique to Claroty, AppDB provides a non-intrusive method for identifying and managing assets in OT environments by parsing artifacts such as PLC and remote terminal unit (RTU) project configuration files.

The screenshot below shows some of the data that may be gathered from parsing a project file:

Proper Amazon S3 Bucket Security Configurations

One of the most frustrating aspects of data exposure via S3 is that buckets are set to private by default. If data is publicly available via an S3 bucket, an administrator somewhere has to have configured it for public access. In most cases, this would likely be done to simplify collaboration between internal teams or between a company and partners, such as integrators and service providers.

Attackers with valid S3 credentials—access may also be granted to anonymous public requests—can, with some work, use available tools to enumerate company names and ultimately, find exposed data via public buckets with read-only or read-and-write access. It's not a terribly difficult guessing game to uncover URLs belonging to a targeted organization, be it an enterprise or third-party provider.

Amazon secures its infrastructure, but users must manage the security of their data and who accesses it. Amazon has always set access to buckets as private by default and provided users with the option of using access control lists, access point policies, and bucket policies to allow other Amazon accounts or anonymous requestors, to access data.

Subscribers must share in securing their personal information, and that means configuring buckets correctly and not pretending that hiding in the weeds with a relatively obscure bucket name and URL is enough protection. Users should also turn on cloud-based logging for their buckets; this is a separate charge that many organizations may not be willing to pay for.

In 2018, Amazon introduced Amazon S3 Block Public Access, an account- and bucket-level feature that allows users to centrally block public access and ensure public access is overridden if granted to newly created objects by individual users.

In the meantime, it's critical that OT network managers and ICS operators understand the risks of exposed project files and unsecured cloud-storage containers. As more IT and OT networks converge, attackers are going to seek out such exposures and use them to, at a minimum, gain a foothold on a network. This is particularly relevant to engineering workstations and PLCs which control physical plant processes and affect the reliability and safety of the domain.