Security researcher Vera Mens and her colleagues on Claroty’s Team82 took on some of the toughest challenges in the industrial cybersecurity field at Pwn2Own Miami earlier this year as they hunted for zero-day vulnerabilities in software found in critical infrastructure worldwide. She recounts her own experience participating remotely in the high-stakes hacking competition.
My journey into vulnerability research began four years ago; it was a specific moment and I remember it vividly. It was my second year after graduating from the university with a computer science degree. I was a junior software engineer in a company specializing in network equipment. I had little experience, but my hunger for learning and understanding this new world didn’t seem to be ever satisfied.
It still isn’t.
This was before the COVID pandemic when open and free infosec conferences were common. One of them was big enough to be advertised in broader circles, not just to researchers but also to developers. There were two tracks to this event: One for hacking sessions and the other a hardware workshop.
I fell in love with both. This was the moment.
At first it didn’t seem there was an option for such a transition to vulnerability research. The researchers I knew were born with a shell in their hands. I turned 30 by then with no hacking experience or knowledge. Fortunately for me, I wanted it so much so I didn’t care. I went all in.
I left my position as a programmer and put all my energy and free time into achieving this goal. Three and a half years later, I found myself a part of a vulnerability research team with Claroty’s Team82, and participating in one of the most prestigious hacking competitions, Pwn2Own.
Inside Pwn2Own
For anyone unfamiliar with the competition series held by the Zero Day Initiative, the best comparison may be to a capture-the-flag contest. But instead of finding known vulnerabilities in software of varying difficulty that were put there by CTF writers, Pwn2Own contestants need to find previously unknown vulnerabilities in real commercial software — in other words: zero-days.
Competition targets are published about three months before the event. After the announcement, those who want to participate — teams and individuals — start the research on those targets. The goal is not only to find exploitable vulnerabilities, but also ones that are not obvious. For example, if another team or individual find the same vulnerability, this is called a collision, and there’s a good chance you’ll get less points for your discovery.
I and my colleagues competed in Pwn2Own Miami, a version of Pwn2Own that focuses on industrial control systems, which is Team82’s sweet spot. As an ICS-focused vulnerability research team, it was only logical to test our skills at this competition.
It was a great opportunity for me, not only professionally, but also as a team experience. Although everyone typically worked on their tasks individually, we moved forward as a team, helping each other by brainstorming, and yes, celebrating together the wins. It was a feeling of inclusion and pursuing a mutual goal, and I’ve craved for such an experience for a long time.
Technical focus
Even though the platforms were familiar to the team, the competition wasn’t easy. We worked around the clock for two months, with team leader Sharon Brizinov leading our preparation for the competition.
There were four categories at the competition:
● Control Server: These servers monitor and manage various programmable logic controllers (PLCs) and other field systems. These are critical systems to secure because an attacker with access to a control server could alter industrial processes, limited only by their engineering and automation skills. Specifically, we were to target control servers from Iconics and Inductive Automation.
● OPC UA Server: The OPC Unified Architecture (UA) is a framework that integrates all the OPC Classic specifications into an extensible service-oriented framework. Think of OPC UA as a translation protocol between ICS devices on the OT (operational technology) network; it’s used by almost all ICS products to send data between disparate vendor systems. OPC UA was designed to be more secure than the previously used DCOM and is gaining in popularity. In this category, we were looking for zero-days in the Unified Automation C++ Demo Server, the OPC Foundation OPC UA .NET Standard SDK, the Prosys OPC UA SDK for Java, and the Softing Secure Integration Server.
● Data Gateway: These devices connect devices that communicate over different protocols. We were instructed to target the Triangle Microworks SCADA Data Gateway product and the Kepware KEPServerEx server. Triangle Microworks makes the most widely used DNP3 protocol stack, while KEPServerEX is a connectivity platform that provides automation data to multiple applications.
● Human Machine Interface (HMI) Category: HMIs are the interface an ICS operator uses to monitor and manage various Level 1 and 0 devices on the Purdue Model for ICS. Attackers that take over the HMI can prevent the operator from seeing process issues in the ICS until it is too late. Within the HMI category, we were to go after the AVEVA Edge and the Schneider Electric EcoStruxure Operator Terminal Expert.
Within each category, there were different vulnerability classes in scope, each eligible for a different number of points: denial-of-service (5 points), remote code execution (20) and bypass trusted application check (40).
Although no one was kept from working on any target they wanted, every researcher focused mostly on one category. Noam Moshe took the control servers while Uri Katz and I took the OPC UA Server and the Data Gateway categories. Sharon started with HMI and soon after joined me and Uri.
The OPC UA Server and the Data Gateway categories included six applications. Four of them contained all the possible vulnerability types (denial-of-service, remote code execution, bypass trusted application check), while the Data Gateway category had only the remote code execution type. Our goal was to find vulnerabilities that no one found before on the most updated version of the target.
The vulnerabilities in the OPC UA server category needed to be triggered by sending a specially crafted payload over the network, causing the target application to work unexpectedly. The first thing we had to do, especially me because it was my first encounter with OPC UA, was to understand the protocol.
OPC UA protocol is used in the OT world, encompassing all industrial equipment you can imagine. including small thermal sensors within factories that measure heat from machines, PLCs that control processes, to the software within the computers of the administration personnel who manage that factory from another part of the world.
A lack of interoperability between ICS/SCADA protocols and the PLCs using them is a challenge. Each protocol is proprietary, and often products from different vendors are unable to exchange data. The development of the OPC protocol was meant to solve this problem. The idea was to create a standardized protocol for process control to allow easy maintenance from a single server that is capable of communicating with all endpoint devices in the OT network.
Every OPC UA message starts with a three-byte ASCII code that makes the message type. The four main message types are:
● HEL: Hello message
● OPN: OpenSecureChannel message
● MSG: A generic message container (secured with the channel’s keys)
● CLO: CloseSecureChannel message
The protocol itself is quite complex and we won’t be able to cover it all here. (If you are curious, check out the whitepaper Uri and Sharon wrote about OPC after the team’s first Pwn2Own competition in 2020.)
So we needed to trigger the vulnerability with specially crafted payload over the network. It seemed logical to tackle the problem from two fronts: fuzzing and manual vulnerability research.
Fuzzing covers network and static testing. The network fuzzer sends random payloads over the network to the OPC UA servers during various stages of OPC UA session creation. This method is built once and deployed on all servers simultaneously.
We built our fuzzer from scratch on top of a great network fuzzer framework named boofuzz.
For the static fuzzer, we used both the OPC UA ANSI C protocol stack and the .NET OPC UA protocol stack because we had their source code. We compiled them with known fuzzers such as AFL, libfuzzer and sharpfuzz. We deployed all fuzzers on 50-plus machines, built and wrote some instrumentation and code coverage monitors to keep track of all the fuzzers.
The second approach was manual vulnerability research, which means to study the protocol in depth and try to reach certain flows that will potentially trigger a bug. For example, focusing on esoteric features of the OPC UA protocol specification and thinking about what the developers might have forgotten to check when writing their protocol stack implementation.
I took the OPC UA network fuzzer approach while Uri and Sharon started to research the targets manually. Each of the targets had a different OPC UA implementation, so if a vulnerability was found within one target, that didn’t mean the exploit would “work” on the other targets.
I won’t lie, I was very stressed.
It was my first such competition, and I had only been on the team for about seven months. Everyone wanted to be a part of the success. At that time, the fuzzers had been running for a couple of weeks with little success. We changed the fuzzing strategy every few days, hoping to increase the coverage, and there were times that it looked like a win but turned out to be a false positive because the flow wasn’t really reachable in real-life scenarios.
One night we noticed another crash in one of our network fuzzers. We taught ourselves not to jump for joy before being one 100% sure the bug was real. This time it was.
I checked again and again. The fuzzer had found a crash in Kepware’s KEPServerEx. After a few days of intensive work, we were able to leverage the crash into a full-blown pre-authentication remote code execution on the Kepware target! We had a reliable exploit and we were confident it could work on stage (spoiler alert: it did!).
With time, we had more exploits against most of the targets and we felt strong about the competition. Sharon and Uri attended the competition physically in Miami while Noam and I stayed at home in Israel [BS1] and followed the competition online. Not all attempts were broadcasted, but we were up-to-date with guys on-site in Miami. One that was broadcast online was our attempt against KEPServerEx.
Each team had three attempts within five minutes to trigger the vulnerability. Noam and I were stuck to the screen. The attempt started. The exploit was complex and it took some time to kick in. The first two minutes were peaceful for me, but then we saw Sharon looking anxious, and my heart started to beat fast. Another minute passed and we saw one of the officials point to the screen. An MS Paint application appeared out of nowhere on the screen, and only by sending our crafted packets to the server without authentication. Our exploit demonstration was successful, and we got full points for it!
We had executed three denial-of-service attacks and three remote code execution attacks, which earned us 45 points ($45,000) and third place in the competition. In addition to the main event, there was an ongoing CTF in which we took first place.
.webp?width=720&height=583&name=1_O2K-cmQlZ1KkfslM1VvHog%20(1).webp)
It has been more than a month since the competition, and only now can we take a deep breath and focus on our regular research until the targets for Pwn2Own Miami 2023 are published.
From being a junior C++ developer to competing in top-tier competitions such as Pwn2Own, it’s been a long journey. It was a risk for me to leave my programmer job for vulnerability research, and it was worth it, not only because I had the opportunity to research and find zero-days at Pwn2Own, but also because I do what I love, and (I think) I do it well.
