Unfortunately, again this year, I wasn’t able to attend BSides LV / BlackHat US / DEFCON in-person.
I did however try to watch a few ICS-related talks, and here are my thoughts. Please be aware that this is not an exhaustive list of all interesting talks!
BlackHat
As a trainer, I received a pass to “attend” the conference. Since all trainings happened remotely, I stayed in France and watched a few talks. They’re all available for replay on SwapCard if you registered (and paid 😉 ) for BlackHat.
A Broken Chain: Discovering OPC UA Attack Surface and Exploiting the Supply Chain
In this talk, Eran Jacob from OTORIO explains how a large number of OPC-UA implementation rely on a very few software libraries, mostly provided by the OPC Foundation.
The research was then focused on these stacks, and several vulnerabilities were identified:
- CVE-2021-27432: Sending large XML data, that happens pre-authentication -> able to crash the OPC-UA server
- CVE-2021-27434: XXE vulnerability in XML processing allowing to access sensitive data from the OPC-UA server or more globally from the OPC-UA server subnet
- CVE-2021-32994: Denial of Service in Softing OPC-UA C++ SDK
The author also recommended the following research:
Takeaways
As mentioned in my training, OPC-UA clearly is one the ICS protocols of the future and provides long awaited security features. However, it is a very complex protocol and using it in an insecure way (like security=none, as I’ve seen in assessments) is actually worse than using Modbus.
In this talk, we learn about vulnerability heritage in the different software components used by most vendors. This is another call to start working on SBOM (Software Bill of Materials).
Lastly, the vulnerabilities identified probably could have been found by performing a security review of the code. As an integrator/vendor relying on external software components, it is also part of your duty to ensure that this external code complies with your security requirements, and the ones from your customers.
Hacking a Capsule Hotel – Ghost in the Bedrooms
While not strictly related to ICS, I liked this presentation by Kya Supa from LEXFO during which he explained how he was able to get access to most connected devices (light, curtains, fan…) for all “rooms” in a capsule hotel.
Your Software IS/NOT Vulnerable: CSAF, VEX, and the Future of Advisories
Vulnerability management is a very difficult job, and quite frankly we’re mostly quite bad at it. Why? It’s still a mostly manual job of reading/analyzing vulnerabilities and comparing to your asset inventory (or delegating this job to an external provider).
In this talk, Allan Friedman from NTIA and Thomas Schmidt from BSI present two important concepts/tools :
- CSAF (Common Security Advisories Framework): A standard defining a way to automate security advisories by making it available in machine-readable format
- VEX : A sort of “negated” security advisory. It’s a way to tell customers that your product is not affected by a specific vulnerability. This was added to the CSAF as a specific profile.
Takeaways
As software dependencies are everywhere, using SBOM and CSAF seems like a great way to achieve more efficiency while reducing the manual labor and alert-fatigue from security teams.
What can you do?
- As a end-client, require your vendors to provide all advisories in machine-readable format
- As a vendor, doing so will reduce the friction with clients and the ability to explicitly state that your product is not vulnerable to the latest vulnerability on one of your software component will likely reduce workload for your clients, and for your support team.
A Hole in the Tube: Uncovering Vulnerabilities in Critical Infrastructure of Healthcare Facilities
In this talk, Ben Seri and Barak Hadad from Armis showcase their security research into PTS (Pneumatic Tube Systems), that are used for example in a lot of hospitals in the US.
They identified numerous – very classical- vulnerabilities in the embedded devices used in such systems.
DEFCON ICS VILLAGE
Fortifying ICS – Hardening and testing
The topic of hardening systems is rarely mentioned in ICS cybersecurity, but plays a very important role in preventing attacks or slowing them down.
Takeways/thoughts
- You can use GPO (Group Policy objects) to harden a Windows machine that is not domain-joined: it’s called LGPO (Local GPO)
- Network interfaces tend to keep their default bindings on Windows
- Expect things to break. Virtualized systems are easier to harden as you can use snapshots to easily revert if a setting is breaking normal operations
- Hardening could happen during FAT and SAT. Those are specific moment in a project lifecycle during which you can perform in-depth training without impacting production. Performing hardening tests during FAT/SAT also allows vendors/integrators/asset owners to get a better understanding on what we’re trying to achieve, and sometimes how their product works 😉
You can also take a look at Cutaway’s SAWH (Stand-Alone Windows Hardening) that was recently published on Github. It’s a first step to quickly secure your machines. I’m more in favor of integrating cybersecurity as part of the project requirements, and asking the vendor to either :
- Use your own hardened template OS
- Comply with your hardening guide
and document exceptions. But I understand it’s not always possible.
Bottom-Up and Top-Down: Exploiting Vulnerabilities In the OT Cloud Era
Sharon Brizinov and Uri Katz from Claroty take a look at vulnerabilities in cloud-connected automation.
This new paradigm implies that all communication from/to the PLC/ remote IOs go through a cloud platform of some sorts.
For this study, they take a deeper look at Codesys solution for cloud automation, centered around Codesys PLCs (Wago PFC 100/200 in this example) and the Codesys automation server, that allows to centrally manage all PLCs.
They managed to identify two attacks paths:
Bottom-up
By exploiting overflows in a configuration service running on port TCP 6626 on the PLC, they can then exploit the lack of anti-CSRF protection in the web management console to add a new user there.
Top-down
By creating a malicious Codesys package, and publishing it to the Codesys store, an attacker could execute code on the workstations on which the package was installed. This package could steal the credentials from the legitimate cloud server user and send it to the attackers. They would then be able to perform all kinds of admin tasks on all the connected PLCs, including and up to running arbitrary code on the devices.
Takeaways / thoughts
- Centrally managing all your PLCs is an appealing idea, but clearly comes with challenges. Defining the perimeter we’re comfortable centralizing in a single platform needs to include cybersecurity considerations.
- Reminds me on the work on PLCNext platform by Kelly Leuschner: https://cs3sthlm.se/program/presentations/kelly-leuschner/
- Codesys has a pretty bad record track for security, and this seems to extend to Codesys automation.
Security Coding Practices for PLCs
This is a project that I know quite well, since I watched the starting point at S4 conference in Miami last year.
PLC code security is probably not the first topic to address in a cybersecurity program, but will be a logical next step once you cover the basics. I hope to be able to talk in more depth about this project in a dedicated blog post.
In the meantime, check https://www.plc-security.com/, and contribute if you can!
ICS cybersecurity academy 