designing exploits & implants for industrial control ... ©2019 check point software...

1©2019 Check Point Software Technologies Ltd. ©2019 Check Point Software Technologies Ltd.

Jos Wetzels | Principal Security Consultant, Secura

Marina Krotofil | Senior Security Engineer, BASF

CPX 360 2019

DESIGNING EXPLOITS & IMPLANTS FOR INDUSTRIAL CONTROL SYSTEMS

2©2019 Check Point Software Technologies Ltd.

• Jos Wetzels

Embedded Systems Security (ICS, Automotive, IoT, …)

Principal Security Consultant @ Secura

Security Researcher @ Midnight Blue

Security Researcher @ UTwente

Who are we?

• Marina Krotofil

ICS / SCADA Cyber-Physical Security

Senior Security Engineer @ BASF

Principal Analyst @ FireEye

Lead Cyber Security Researcher @ Honeywell

@s4mvartaka @marmusha


• Introduction

• ICS Device Exploitation

• Developing ICS Device Implants & OT Payloads

• Conclusions

Agenda


WARNING: FAST PACED TALK

https://www.disneyclips.com/imagesnewb/alice4.html


INTRODUCTION

http://ats-transporttechnieken.nl/wp-content/uploads/photo-

gallery/Draadloze%20shuttle%20voor%20zwembaden/2H8_016.JPG


Industrial Control Systems (ICS)

Physical

process

Attacker

end target

Information Technology (IT)

Operational Technology (OT)

Computer science

Engineering


ICS ARE EVERYWHERE

Electric Power Oil & Gas Water

Nuclear Manufacturing


Threats - Motives

Geopolitics Extortion Competition


Threats - Means

Espionage Sabotage


Sabotage can come in many forms

Denial of Service Injury / Loss of Life

Damage to Equipment Damage to Production Damage to Environment


All of these critical systems are safely air-gapped … right?


“Forget the myth of the air gap – the control system that is

completely isolated is history.”-- Stefan Woronka, Siemens ICS Security Director


IT / OT Convergence

Hardwired Electrical Relays

PLCs

Serial Networks

IP Networks

Wireless Networks

Industrial IoT

• Fieldbus

• Industrial Ethernet

• Wireless

• IIoT

• …• Predictive Maintenance

• Real-Time Decisions

• COTS Integration

• ‘Big Data’

• …


Brief History of ICS Security

14

https://q

ph

.fs.q

uora

cd

n.n

et/

main

-qim

g-

f741c6e5d

b3

2b

87f2

82

e5

44

48

a2

12

9ce

STUXNET

2010 20172015 2016

Ukraine

power grid

attack

(Industroyer)

Ukraine power

grid attack

(BlackEnergy)

TRITON

It’s happening: Publicly

known cyber-physical attacks

Planned

operation to

hinder Iran’s

nuclear program

First publicly

known OT recon

activities

(HAVEX)

2013

Recon and

weaponization of

capabilities

htt

ps:/

/ww

w.s

chneid

er-

ele

ctr

ic.c

om

/ww

/en/I

mages/t

ricon-I

C-

654x654.jpg

Watershed Moment

htt

ps:/

/ww

w.t

hedailybeast.

com

/cia

-eyes-r

ussia

n-h

ackers

-in-

bla

ckout-

att

ack

htt

ps:/

/ww

w.a

rabia

nbusin

ess.c

om


Example: TRITON Attack

15


Hazards and Layers of Protection


Safety Instrumented Systems

Spi-ltuf.org

• Digital, Parallel to BPCS

• Sensors / Final Elementscan be SIS-only or sharedwith BPCS

• Ideally on separate SISnetwork segmented fromPCN


Schneider Electric Triconex (SIL3)

http://iom.invensys.com/EN/pdfLibrary/Datasheet_Triconex_TriconSIL3_06-11.pdf


Schneider Electric Triconex (SIL3)


Triconex is everywhere … [OSINT]

https://w

ww

.blu

ew

ate

r.com

/fle

et-

op

era

tio

ns/o

ur-

fpso

-fle

et/

gla

s-d

ow

r/

http://s

oft

ware

.schn

eid

er-

ele

ctr

ic.c

om

/abo

ut-

us/s

uccess-s

tories/lis

ting

-con

tent/

blu

ew

ate

r/


TRITON Attack Overview

https://www.cyberark.com/threat-research-blog/anatomy-triton-malware-attack/

Improper

segmentation

between PCN & SIS

Attacker obtained

remote access to SIS

engineering station


• Attacker attempted to inject passive implant into safety controller

Read/Write/Execute Memory

TRITON Payload Overview

TriStation protocol

Eng. Workstation

“Your wish is

my command”

imain.bin + inject.bin

trilog.exe• script_test.py

• library.zip

• inject.bin

• imain.bin


Increasing Attack Complexity

• TRITON used implant on Triconex SIS controller

• Process shutdown could’ve been achieved much easier

What is going on here?


• Attack scenario depends on attacker goal

Sometimes this means explosions, sometimes it doesn’t

• Simple process shutdown can be costly for plant owners & achieved by simple means

Downtime, restart issues (residue in tanks/vessels/pipes, off-quality product, equipment fatigue), …

DoS on networking equipment, controllers, …

Obvious ‘Do not press’ button on HMI

• But the more precise, damaging & lasting attacks are more complicated

Attacks on Industrial Systems


• Blackout != Spoiling Chemical Batch != Pipeline Rupture != Vessel Collapse

• Damage scenario requires good process comprehension

What causes the right pipeline to explode at the right moment

What are the (uncontrollable) side-effects of my actions?

What safety mechanism & alarms might kick in?

Industrial processes are designed to be robust & recoverable

• This is why espionage & reconnaissance matter

Obtaining P&ID diagrams, historian databases, software versions, …

Cyber-Physical Attacks are Process-Specific


•“Trivial! Look at the state of ICS security!”

•“Borderline impossible! These processes are extremely complex & engineered for safety!”

Two Common Views of Cyber-Physical Attacks


• Pwning a PLC != ‘Winning’

If you don’t have a response to “OK, so now what?”, you don’t really control anything. There is more to CPS attacks than cyber-security.

• Safety != Security

Safety Controllers can be compromised too. Are you sure independent ‘dumb’ fallbacks are sufficient when SIS fails?

Both are wrong


OT is about control loops

Actuators

Control system

Sensors

Measure

process state

Computes control commands for

actuators

Adjusted to influence process

behavior

Set Point (SP)Process

Variable (PV)


Industrial Attack Components

1

Manipulate theprocess

Prevent response

Direct Indirect

Manipulationof actuators

Deceive controller/ operator

about process state(e.g. spoof sensor)

3

Operators Control / Safety System

Blind Mislead

Modify operational /safety limits

Blind aboutprocess

stateOT Payload

2

Obtain Feedback

Direct or Derived (e.g., via proxy

sensors /calculations)

Often hardest to achieve


Likely TRITON Implant Role

1


Prevent response

Direct Indirect




3

Operators Control / Safety System

Blind Mislead


Blind aboutprocess

stateOT Payload

2

Obtain Feedback

Direct or Derived (e.g., via proxy

sensors /calculations)


• Cyber-Physical Attack is collection of ‘clandestine control loops’• Cycle of process observation & manipulation to achieve unsafe state

• Attack Timing & Coordination are Crucial• Processes aren’t vulnerable all the time. Many scenarios take time to execute.

• Observation of state A in component B needs to trigger payloads X, Y, Z

• Need to be able to observe states equipment might not be able to directly measure

• Requires granular control across process

• Manage task quantity & timing

Clandestine Control Loops


Need implants to coordinate & execute attack• MPC860, 50 MHz

• 6 MB Flash

• 16 MB DRAM

• 32 KB SRAM

• ARM9, 14 MHz

• 512 KB Boot Flash

• 8 MB RW Flash

• 2 MB SRAM

Will need to fit implant in there

• Signals processing?

• Malicious logic?

• Comms?

Often jam-packed with functionality already

You better enjoy programming…


Implant Communications

EXPECTATION VS. REALITY


• Implant 1 needs to take action X when we enter state B. Can we measure or infer?

• Communicate through process physics Eg. change in flow rate

• Upside: Limited electronic chatter after implanting

• Hinders monitoring & forensics

• Downside: Can get real complex

• Process state detection might depend on properties sensors don’t directly measure

• Abnormal physics might propagate to places where we’re not suppressing alarms or cause other side effects ruining our attack

Implant Communications & Attack Feedback Loops

* Evil Bubbles: How to Deliver Attack Payload via the Physics of the Process, Black Hat USA 2017


Detection of process state

Non-parametric CUSUM (cumulative sum) algorithm


• This is complicated, expensive stuff

• Engineering know-how, RE, vuln research, exploit & implant dev, testing, …

• High chance of messing up

• Offsets terrible IT / OT security

• Check out ‘Hacking Critical Infrastructure Like You’re Not a N00b’ @ RSAConf 2016 by Jason Larsen

• Let’s walk through the process required for developing a single exploit / implant / payload combo (eg. TRITON)

Ah, so that’s why everything isn’t blowing up all the time ….


ICS DEVICE EXPLOITATION

http://invensyscustomersuccess.blogspot.com/2013/07/bermuda-electric-evolution-and.html


1. Obtaining Materials

2. Device Analysis

3. Reverse Engineering

4. Vulnerability Discovery

5. Exploit Development

The Process


Obtaining the Documentation


• Vendor website, Direct purchase

• Steal from asset owner

• Piracy & other sketchy sources

Open webdirs & FTPs

Ebay, Alibaba

Obtaining the Engineering Software


Obtaining the Device


• Various Options

• Download from Vendor Website

• Extract from FW Update Utility, Extract from Flash

• Obtaining firmware can be complicated

• Worst-case scenario: encrypted firmware + chip readout protection requiring bypass & invasive or side-channel attacks

• Not so much for Triconex

• No readout protection on flash. Desolder -> adapter + universal programmer does the trick

• Or extract from FW update util

Obtaining the Firmware



2. Device Analysis




The Process


• We need to know

External & internal communication interfaces (how can we enter device / move laterally?)

Functional domains (where does what happen in device?)

Architectural details (MCUs / SoCs used, HW security features, …)

• Sometimes we’re lucky

FCC IDs, public teardowns, block diagrams in guides (Triconex), …

• Sometimes we’re not

• Teardown time

Device Analysis


Don’t be afraid of teardowns

* Serge Bazanski, Michal Kowalczyk


ICS Devices aren’t magic

* Stephen A. Ridley, Senrio Inc., 2016


Programmable Logic Controllers (PLCs) 101

• Originally designed to replace hardwired relays

• Ruggedized, can be standalone or modular

Power supply, CPU, IO, external comms.

IO connected to field devices (sensors, valves, …)

Source: edgefx.in,

plcdev.com


PLC CPU Firmware


Control Logic Execution


Triconex TMR Architecture

https://www.nrc.gov/docs/ML0932/ML093290420.pdf


Triconex 3008 MP

https://www.nrc.gov/docs/ML0932/ML093290420.pdf



2. Device Analysis




The Process


• Engineering protocols are of great interest

Can contain sensitive functionality: PLC start/stop, file download, firmware & control logic download

Often legacy, proprietary protocols.

Usually no security whatsoever

• If we can talk to PLC via this protocol, might get RCE on device!

• Want to know packet structure & semantics

Protocol RE

https://www.gegridsolutions.com/products/manuals/energy/994-

0146-D20MX-v1.5x-Product-Documentation-Set-Binder.pdf


• Compare to functionally similar older (documented) protocols

• Functionally granular packet capturing & group diffing

Start packet capture -> initiate action X -> stop capture

• Testing for common encodings & fields

TLV, sequential identifiers, checksums, entropic analysis, …

“Believe it or not, if you stare at the hex dumps long enough, you start to see the patterns”

– Rob Savoye, FOSDEM 2009

Protocol RE – PCAP Only


PCAP-Only Analysis


• Want reconstruction to be complete & sound

• Want to write reliable exploits

• PCAP-Only can be incomplete, inaccurate or opaque

• Undocumented / rare behavior, inferred semantics, encryption / compression

• PCAP-Only can damage your sanity

Ideally we assist analysis with binary RE


• tr1com40.dll

TriStation (UDP/1502) communication DLL

Debug symbols present

RE message structure

Easy semantic mapping of function codes

• Don’t need full RE

Only interested in handful of message types

We want an exploit not a protocol parser

Protocol RE – From Binary



2. Device Analysis




The Process


• The next step is getting code exec

• Ideally pre-auth vulnerability but

• Pre-auth is a relative concept here…

• ICS Vulns are often simple byproduct of RE

• Shake a stick at it & vulns fall out

Vulnerability Discovery

http://www.fao.org/docrep/006/AD226E/AD226E12.gif


• Serial-to-Ethernet/WiFi Gateway

• Web Interface

• Broken auth (hashing on client side)

• CMD injection in ping test form

Example: Moxa Nport W2150A*

* Thomas Roth, 2017


• Energy usage monitoring & control fans,coolers, load shedders

• OptoMMP protocol (TCP/UDP 2001)

Based on IEEE 1394 (FireWire)

No authentication

Byte-addressable R/W memory map

Disable IP filter, enable FTP, fetch creds

• Upload unsigned firmware over FTP

Example: Opto 22 OPTEMU-SNR-DR2*

* David Barksdale, Jeremy Brown, 2016


• Large PLC for process applications

• Backdoors

• FTP w. hardcoded creds: Read / Write configuration, firmware, passwords, …

• Telnet: C interpreter

• Unauthenticated Proprietary Modbus Extension

• Start / Stop PLC, Overwrite programmable logic

• Gazillion ways to get code exec

Example: Modicon Quantum PLC*

* K. Reid Wightman,

Rubén Santamarta,

2011-2012


You get the idea …

https://i.redd.it/e5l1ngm7rzr01.jpg


Insecure by Design


Legacy & Long Lifespans


“The pro’s don’t bother with vulnerabilities; they use features

to compromise the ICS”*

-- Ralph Langner

* Depending on your definition of vulnerability


• Vuln is a freebie of protocol RE

Unauthenticated safety program download

‘Start Download Change’ (FC: 0x01)

‘Allocate Program’ (FC: 0x37)

‘End Download Change’ (FC: 0x0B)

• No safety program signing

• Skip directly from RE to XDEV …

TRITON: Execute My Packet Please!



2. Device Analysis




The Process


• After finding a suitable vulnerability / feature, we need to craft an exploit to gain code execution, e.g.

Insert implant into unsigned firmware update

Hijack control-flow with buffer overflow

…

TRITON: How to go from downloading safety program to executing code on PLC CPU?

Exploit Development


• Developed in IEC 61131-3 and CEMPLE

Compiled for PowerPC, executed by runtime on CPU module main processor

• Another freebie: no breaking out of sandboxes, runtime exploitation or chip lateral movement

Triconex Safety & Control Applications


• TRITON does not overwrite original logic but appends to it

‘Download Changes’ (FC: 0x01) instead of ‘Download All’ (FC: 0x00)

Adds malicious code to internal linked list of programs

Safety logic continues to run without interruption!

TRITON Code Execution


Complication: Keyswitch

https://images-na.ssl-images-amazon.com/images/I/41jr93jKzML._SX466_.jpg


ICS IMPLANT & OT PAYLOAD DEVELOPMENT

http://iom.invensys.com/EN/Pages/IOM_NewsDetail.aspx?NewsID=78


• Directly implant OT payload or implant backdoor

Keeps OT payload secret until Zero Hour (‘killswitch’)

• Cross-Boot Persistence

Requires modifying flash / enough space

• Memory Residence

Requires executable RAM

Reboot = implant gone (but… safety controller uptime)

Also complicates forensics!

ICS Implant Strategies


• Common Devices Throughout ICS (cross-facility)

> 18000 Triconex systems in > 80 countries

• Common Software Throughout ICS (cross-vendor)

Protocol / Connectivity Stacks

Control Runtimes / RTOSes

• Construct arsenal of exploits & implants against common devices & software stacks

One time upfront investment, no huge turnover

TRITON makes more sense as tool in such an arsenal than as expensive on-off

ICS Implant Scalability


THE TRITON IMPLANT


• Runs Enhanced Triconex System Executive (ETSX) 6236

Sparse documentation exists on NRC site

27 system calls, flat memory model w/o permissions, minimal privilege separation

Safety / Control programs stored in linked list, executed by runtime in user mode

Triconex 3008 MP Firmware

Source: United States Nuclear Regulatory Commission , Document number NTX-SER-09-10, Page 96


• Stage 1: Argument-Setter

• Stage 2: Implant Installer (inject.bin)

• Stage 3: Backdoor Implant (imain.bin)

• Stage 4: Missing OT Payload

TRITON: Multi-Stage Payload

* ICS-CERT MAR-17-352-01 HatMan—Safety System Targeted Malware (Update

A)


• Egghunt for Control Program (CP) fstat field

• Sanity test write operation

• Use field for stage 2 FSM control

Payload Stage 1: Argument-Setter


A)


Payload Stage 2: Full FSM


A)


Payload Stage 2: Implant Installer


A)

Requires Supervisor Privileges


Payload Stage 3: Backdoor Implant


A)


• Once backdoor is injected, we have god mode

• Still need OT payload to carry out ‘meat’ of the attack

• Not recovered from incident, hard to determine attack (sub) goal

• Asset owner can make educated guess, we can only speculate …

• Which we will!

Payload Stage 4: OT Payload Delivery?


Possible TRITON OT Payloads

1


Prevent response

Direct Indirect




3

Control / Safety System


Blind aboutprocess

state


OT Payload:I/O Spoofing


I/O Spoofing

Measurement InstrumentationController

Input Signal Output Signal


I/O Translation


OT payload:Alarm Suppression


Alarm Propagation

Safety shutdown

Alarm

Alarm

Goal: catalyst deactivation


Hiding Alarms


Suppressing Alarms


• PC-based HMI

• Management & Bypass of Priority 1Alarms

• Each HMI function is mapped toTriconex logic function blocks

Example: Triconex Safety View

Source: Invensys / Schneider Electric


• Consider simple water tank level alarm

• OR of measurement DIs -> alarm DO

Example: Triconex Alarm Function Blocks


• Safety Program resides in-memory as code

• OT payload can modify instructions to set alarm to fixed FALSE

• Stored program on flash remains untouched

• Attacker needs to know

1. Where program lives in memory

2. Which instructions of program to modify

Example: Suppressing Alarms


Analyzing Safety Program


Hot-Patching Safety Program


Example: Alarm Suppression


More Speculation Ahead:Why Did The Attack Fail?


• Failed Privilege Escalation / Backdoor allows for raw RWX

• You read / write / execute the wrong thing in the wrong place …

• Getting into a fight with the watchdog

• Very common embedded way to shoot yourself in the foot

• Missed diagnostics?

Option A: b0rked payload?

* https://betterembsw.blogspot.com


Option B: TMR?

https://patentimages.storage.googleapis.com/5a/1a/88/f75a93ace8c548/US8037356.pdf


Conclusions


• Obtaining Necessary Materials – Easy

• Public documentation, no firmware protection, buy 2nd hand components

• Protocol RE / Vulnerability Discovery - Easy

• Unauthenticated engineering protocol

• Software with debug symbol

• Exploit Development - Moderate

• No program signing, no sandboxing

TRITON Cost & Complexity Assessment


• Implant Development - Moderate

• Required (simple) Privesc Exploit, required firmware RE or other ways to know internals, Take TMR / diagnostics into account

• OT Payload Development - Hard

• Hardest part: deep firmware RE + understand position of particular SIS instance in process

• Likely doesn’t scale well beyond target facility

TRITON Cost & Complexity Assessment


• If part of broader ICS arsenal, where’s the rest?

• In what light should TRITON dev cost be seen?

• Expensive for a one-off, cheap for a scalable one-time upfront?

• What does the attack failure tell us?

• Implant development = Software development = 99% Frustration

• Maybe stability sacrificed in R&D cost/benefit judgement? Maybe they were in a rush?

• If or when for copycats?

• Either of TRITON or as blueprint against other SIS and ICS

Open Questions


• Ali Abbasi, Uni Bochum, Germany

• Thorsten Holz, Uni Bochum, Germany

• Felix ‘FX’ Lindner, Recurity Labs

• Various security community folks who kindly contributed to our knowledge and experience

Thank You

107©2019 Check Point Software Technologies Ltd. ©2019 Check Point Software Technologies Ltd.

Jos Wetzels | Principal Security Consultant, Secura

Marina Krotofil | Senior Security Engineer, BASF

Designing Exploits & Implants for Industrial Control Systems

THANK YOU

designing exploits & implants for industrial control ... ©2019 check point software...

Documents