Recently we, Marina & Jos, presented a talk titled ‘Through the eyes of the attacker: Designing Embedded Systems Exploits For Industrial Control Systems’ at the DEF CON 101 track (slides here). Unexpectedly, accusations of plagiarism were leveled against the talk by one company. These accusations were made on Twitter during and after our presentation without any prior attempt at conversation or conflict resolution. The unfounded plagiarism claims were widely distributed via numerous retweets and returned to us in the form of negatives comments on our ethics, which were both unjust and damaging to our reputation.

After careful consideration and consultations with other InfoSec professionals, we are publishing this post to present our side of the matter, to set the record straight and refute the unfounded accusations of plagiarism. Both affected researchers have accumulated many years of original security research and have never had either need or motive for any kind of plagiarism.

Background

On May 2nd, 2018, Marina and co-speakers submitted a talk proposal to DEF CON via the general CfP procedure. The presentation was intended as an educational introduction to the process of engineering & implementing embedded ‘cyber-physical exploits ’ for the newcomers to the field of industrial security. The goal was to broaden public understanding of the involved nature of such exploits and provide an assessment of their complexity and required investments. The talk was set up as a collaboration between experienced researchers into cyber-physical attacks and embedded security, both of whom have accumulated many years of original research. This was done in order to illustrate the complex interplay between engineering & hacking required for carrying out such attacks.

The talk was initially planned to be given by Marina and another co-researcher. However, due to personal circumstances, the initial co-speaker asked Jos to substitute for him. Although the TRITON malware [9, 10] was the main motivation for developing the talk, it was used in the presentation only in an illustrative capacity. Both presenters and the initial co-speaker were engaged in analyzing TRITON from late 2017, resulting in publishing of the first public analysis of the stage 3 payload (imain.bin) by Jos and the initial co-speaker in January 2018.

The Plagiarism Accusation

During and immediately after the talk accusations of plagiarism were made publicly on twitter by a few individuals related to the accusing company, without any prior attempt at conversation or conflict resolution.

Below we summarize important clarifications, which refute the plagiarism claims and express our position on the matter. A detailed account, including timeline of public TRITON research, can be found in the Details section below. In addition, we have included our presentation slide deck for reference and comparison with the allegedly “plagiarized” talk.

The accusation claimed our talk ‘lifted’ materials from the accusing company’s presentation. It has come to our attention that this claim seemed to rest on two key arguments:

The claim that we ‘pretended’ to have reverse-engineered the Triconex controller. This claim was supposedly supported by the (unintended and unknown to us) inclusion of a picture, hidden behind another picture, of a Triconex controller board which belonged to a researcher from the accusing company. The supposedly copied narrative in terms of ‘idea and flow’.

With regards to the first issue, nowhere in our presentation (neither in the talk abstract nor in the submitted outline) have we claimed to reverse-engineer the Triconex controller. In fact, we explicitly made clear that we did not even have access to a Triconex controller and therefore demonstrated an ‘OT payload’ on a Wago PLC, and illustrated firmware rebasing using an unrelated ARM-based RTU as an example. The discussion on TRITON and the affected controller merely served in an illustrative capacity to a generic process of developing embedded implants. In our presentation we followed the TRITON analysis from the U.S. ICS-CERT report (dated April, 2018), which is the most complete report on the TRITON incident and which includes information on all stages of the payload, the exploited Triconex firmware features revealed by the affected vendor Schneider Electric in January (backdoor relocation, network dispatch command hooking, diagnostics bypassing and privilege escalation). The screenshots of the reversed firmware used in our presentation to illustrate TRITON malware functionality were our own and came from an in-memory image of the Triconex firmware and TRITON malware.

Regarding the image of the PCB board of the Triconex controller on our slide 48, its inclusion was unintended and its presence on our slide deck was not known to us prior the DEF CON presentation itself because it was hidden behind a picture of the Triconex block diagram from the public documentation. Contrary to the accusations, this image was not lifted from any public presentation but was a private image given to the initial co-presenter by the accusing researcher personally for purposes unknown to us. As a substitute presenter, Jos inherited a few slides from the initial co-speaker, including the image in question. The photo was not visible to us and we were unaware of its presence until the DEF CON presentation itself, when presentation mode in PowerPoint turned these stacked images into an animation (see Details section below). The fact that this private image was unintentionally shared with us and unknowingly included was confirmed to the accusing researcher by the initial co-speaker twice. To claim we lifted the image from a prior presentation in order to pretend we reverse-engineered controller hardware is a gross distortion of the facts and makes little sense given our presentation purpose which was concerned with the interplay between cyber-physical attacks and embedded security analysis (rather than reverse-engineering the specifics of the Triconex controller).

Concerning the second issue, the first thing to note is that the proposal and detailed outline for our talk were submitted to DEF CON 1.5 months before the supposedly “plagiarised” talk took place and 2 weeks before it was even announced. Secondly, it should be noted to the two talks are very different in terms of topic and contributions. The supposedly “plagiarized” talk is concerned with the reverse-engineering of the Triconex controller in order to illustrate details of the TRITON malware. Our DEF CON talk is concerned with the generic process of designing & implementing embedded exploits for physical damage by putting exploitation & implantation in a wider ICS context and assessing the complexity of the endeavor. The talk is based on a mix of our own prior works and know how based on a mix of our own prior experience, work and know how [eg. 12,13,21,23,24,25,26,27,29,30,31] as well as cited references to prior work by others (including cited prior work by a researcher from the accusing company). TRITON malware analysis merely served in an illustrative capacity in our presentation (together with other examples of ICS vulnerabilities). The outlined process of reverse-engineering and exploiting embedded systems presentation follows a high-level overview of generic embedded device analysis (gathering documentation, teardown, firmware analysis, etc.), as gone through by every embedded reverse-engineering talk or training. As such, the claim that the talk’s idea and flow were lifted from the “plagiarized” presentation (from the future, no less!) is completely unfounded.

Curiously, considering the claim of plagiarized narrative and flow, researchers from the accusing company publicly praised the Black Hat USA 2018 TRITON presentation given by Marina and researchers from a third company which shared narrative and flow regarding the TRITON exploit and implant, precisely the part against which the unfounded plagiarism claims against the DEF CON talk are leveled.

We hope that this statement, and the detailed discussion and timeline below, have helped dispel the unfounded claims of plagiarism and have aided in rectifying the situation.

Marina & Jos

Details

Regarding the first claim, the image in question (Figure 1a), on slide 48 of our presentation, was included into our slide deck unbeknownst to us.

Figure 1a: The hidden picture in our presentation

Contrary to the claims that the image has been lifted from the allegedly “plagiarized” presentation [2,3], this image is not public. Instead, it was privately given to the initial co-speaker by a researcher from the accusing company and ended up in our presentation inadvertently and invisibly to us.

In their presentation, the accusing company’s researchers used another image (Figure 1b):

Figure 1b: The board picture in the accusing company’s presentation

Due to a change of speakers we inherited a few slides from the initial co-speaker, one of which included the image in question hidden behind a picture of the Triconex Main Processor block diagram (publicly available from Triconex documentation hosted by the US Nuclear Regulatory Commission). The photo was not visible to us and did not show up in the PDF version of slides submitted to DEF CON (see Figures 2 and 3).

Figure 2: The board image hidden behind the block diagram

Figure 3: The slide in question as it appears in PDF

As such, we were unaware the image was included in our slide deck until the presentation itself, when PowerPoints’ presentation mode turned these stack images into an animation (see Figure 4).

Figure 4: The stacked images turned into animations

The fact that the inclusion of said image was unintended is self-evident from the subsequent slides such as slides 105 and 106 (and the demo video) where we demonstrate the I/O spoofing OT payload implemented for a Wago PLC (because we did not have access to a Triconex controller). This fact is also emphasized in the discussion of manners in which to obtain the firmware where we describe obtaining the firmware from the firmware manager utility instead of extracting it from the flash. Therefore, accusing us of having pretended to reverse-engineer the Triconex hardware makes no sense.

The presentation narrative: Idea & Flow

Regarding the second claim, the statement that the idea or flow of the talk were taken from either the June 17 presentation by the accusing company or any other presentation is preposterous. First of all, the proposal for our DEF CON talk (which already outlined the presentation idea and narrative flow) was submitted on May 2nd 2018, 1.5 months before the allegedly “plagiarized” talk and two weeks before that talk was even announced. Both presenters have worked on analyzing the TRITON malware starting from late 2017, with the majority of analysis results obtained by the end of January 2018. The presentation was crafted on our own prior work in addition to fully cited public prior work by others (including cited work by a researcher from the accusing company) and was meant to be an educational talk for newcomers to the field of embedded ICS security.

In addition, both talks are completely different in essence. Whereas our talk sought to be an introductory experience (hence the 101 track)

“providing the audience with a ‘through the eyes of the attacker’ experience when designing advanced embedded systems exploits for Industrial Control Systems (ICS)”

using TRITON as an illustration, the accusing company’s talk sought to

“explain our approach to analyzing this sample and at the same time, provide a detailed walkthrough of TRISIS with a focus on the PowerPC payloads and relevant portions of the Triconex firmware”.

This difference is amply illustrated by the flow of our presentation:

Our presentation starts with a general introduction to industrial control systems, the TRITON incident and a process of designing cyber-physical attacks ( slides 1 to 31 ). The material in this section is based on public information about ICS and TRITON, Marina’s prior work on components of cyber-physical attacks and cited prior work by Jason Larsen [33] on comparing the reliability of cyber-physical exploits.

). The material in this section is based on public information about ICS and TRITON, Marina’s prior work on components of cyber-physical attacks and cited prior work by Jason Larsen [33] on comparing the reliability of cyber-physical exploits. The next segment of the presentation consists of a discussion on ICS device exploitation ( slides 32 to 66 ) and follows the general pattern of reverse-engineering and exploiting embedded devices. It is a typical sequence of steps (obtaining relevant materials, performing a teardown, RE of protocols, etc.) that is covered in every embedded security training or book on offer and followed by every practicing reverse-engineer in the world. We illustrate this sequence with our own approach to obtaining and analyzing the TriStation engineering software (which we purchased from the Alibaba e-commerce platform) and cited examples of vulnerable ICS devices (including prior work by a researcher from the accusing company). Nowhere do we claim access to the actual Triconex controller which, for the purposes of our 101 talk, was superfluous.

) and follows the general pattern of reverse-engineering and exploiting embedded devices. It is a typical sequence of steps (obtaining relevant materials, performing a teardown, RE of protocols, etc.) that is covered in every embedded security training or book on offer and followed by every practicing reverse-engineer in the world. We illustrate this sequence with our own approach to obtaining and analyzing the TriStation engineering software (which we purchased from the Alibaba e-commerce platform) and cited examples of vulnerable ICS devices (including prior work by a researcher from the accusing company). Nowhere do we claim access to the actual Triconex controller which, for the purposes of our 101 talk, was superfluous. The following segment of the presentation consists of a discussion on strategies for ICS implant development ( slides 67 to 85 ), which begins with the common process of firmware analysis as, again, covered in every embedded security training or book. The slides use an unnamed ARM-based RTU as an example for base address discovery and make no pretense at reverse-engineering the full Triconex firmware from the device here (which would be out of scope for our purposes anyway). The discussion proceeds with a short overview of the Triconex 3008 MP firmware as based on publicly available documentation [6,7,8].

), which begins with the common process of firmware analysis as, again, covered in every embedded security training or book. The slides use an unnamed ARM-based RTU as an example for base address discovery and make no pretense at reverse-engineering the full Triconex firmware from the device here (which would be out of scope for our purposes anyway). The discussion proceeds with a short overview of the Triconex 3008 MP firmware as based on publicly available documentation [6,7,8]. Subsequently, the presentation moves on to illustrating the end-result of such a process by discussing the TRITON payload (slides 86 to 98). The TRITON discussion is based on the ICS-CERT report published on April 10, 2018, which is the most complete overview of the incident and malware available and draws heavily upon the S4x2018 talk of the affected vendor Schneider Electric from January 23, 2018. This was the first public presentation on the second stage payload (inject.bin) and discussed its internals such as backdoor relocation, network dispatch command hooking, diagnostics bypassing and privilege escalation.

The TRITON payload consists of three known stages as discussed by ICS-CERT and Schneider Electric:

The argument-setter payload. The implant installer (inject.bin) which we illustrated with a few IDA images from our own in-memory copy of the Triconex firmware. The backdoor implant (imain.bin). Despite the fact that Jos published the first public analysis of this backdoor and its functionality on January 16, 2018 we only cite ICS-CERT’s analysis in our discussion here.

The segment after that consists of a discussion on OT payload development ( slides 99 to 117 ). Specifically, we present the principle of I/O spoofing and a video demo based on the prior work by the initial co-speaker from November 3, 2016. Marina was involved in this work as a research mentor. It is followed by a discussion of alarm suppression as illustrated against the TriStation Emulator software, original work by us which had not been presented before and is not present in any prior work.

). Specifically, we present the principle of I/O spoofing and a video demo based on the prior work by the initial co-speaker from November 3, 2016. Marina was involved in this work as a research mentor. It is followed by a discussion of alarm suppression as illustrated against the TriStation Emulator software, original work by us which had not been presented before and is not present in any prior work. The final segment (slides 118 to 128) discusses possible causes of the TRITON attack failure and the conclusions of our talk. The discussion is brief and of a general nature regarding ways in which (embedded systems) exploits can cause crashes (access violations, watchdog problems, diagnostics checks). Our conclusions summarize attacker efforts when designing and implementing cyber-physical attacks against industrial systems and evaluate TRITON along these lines by means of a discussion on cost and complexity of exploit & implant development. By contrast, the accusing company’s presentation conclusions focus on defensive advice for ICS manufacturers and aspiring ICS security researchers & reverse engineers.

In short, as should already be abundantly clear from the DEF CON abstract and the fact that it was a 101 track talk, we did not claim to present original reverse engineering of either Triconex hardware or software but instead based ourselves on our own previous work and skillset as well as on well-cited prior work.

TRITON PUBLICATIONS & ANALYSIS TIMELINE

In addition to the above explanations and statements, we include the timeline of the public research and publications on TRITON, which aids in dispelling any claims of plagiarism in this matter: