Cyber Security in Industrial Control Systems - CRISALIS Project

SysSec Summer School

“Cyber Security in Industrial Control Systems”

Damiano Bolzoni

Dina Hadziosmanovic

DISTRIBUTED AND EMBEDDED SECURITY RESEARCH GROUP.

Amsterdam October 12, 2012

•  Introduction

•  Regular IT vs. ICS

•  How ICS works?

•  A bit about PLCs.

•  How can things go wrong?

•  Attack the process: On reverse engineering a production process.

•  Attack the system: On reverse engineering network protocols for vulnerability analysis.

AGENDA

12/10/12 D. Bolzoni & D. Hadziosmanovic 2

Dina

Damiano

Damiano

WHAT “INDUSTRIAL CONTROL SYSTEMS” MEANS?


§  SCADA became a buzz word in the past years

§  Mostly used inappropriately

§  SCADA: Supervisory Control and Data Acquisition

§  DCS: Distributed Control System

§  PCS/PA: Process Control System / Process Automation

ICS != SCADA != DCS != PCS (PA)

ICS: everything

SCADA: wide geographical areas

DCS: a single location

PCS/PA: one step of the process

“Regular” IT

§  Change every 3-5 years

§  Cyber security is at a mature stage §  Most people understand

cyber risks

§  Windows XP is (eventually) disappearing

THE SECURITY CYCLE


ICS

§  Change every 10-20 years

§  Cyber security is at a very early stage §  People seldom understand

cyber risks

§  Full of Windows XP §  And other legacy systems (15

years old)

“Regular” IT

§  Confidentiality: 50%

§  Integrity: 30%

§  Availability: 20%

WHAT ABOUT THE 3 SECURITY PROPERTIES?


ICS

§  Availability: 60% §  Vendors have VPN lines

coming into PCS…

§  Integrity: 35%

§  Confidentiality: 5%

“Regular” IT

§  Standard architectures/protocols

§  Proprietary/unknown components are present to a certain extent

ARCHITECTURE & PROTOCOLS


ICS

§  There is no standard architecture §  Most protocols are open, but

with proprietary implementation

§  Massive amount of proprietary components

“Regular” IT

§  (Security) patches are released regularly §  Applied almost right away

PATCHING & RECONFIGURATION


ICS

§  Vendors are quite slow in providing patches

§  Patches are tested before being deployed §  What if there is a conflict with

another software (AV) ?

§  Every component must be functional afterward

§  “If it works, don’t touch it”

“Regular” IT

§  There are several ISO standards

§  2700x series

§  There are international regulations

§  SOX

§  There are well-known methodologies to perform assessments

§  OSSTMM

SECURITY STANDARDS, REGULATIONS AND METHODOLOGIES


ICS

§  No real international standards §  NIST (USA)

§  If a regulation exists, it’s mostly “local”

§  NERC (USA)

§  There are no standard methodologies to assess security

§  Several vendors are trying to propose

theirs

•  Introduction







AGENDA


Dina

Damiano

Damiano

HOW ICS works? Operator, ICS engineer, PLC programmer


OPERATOR VIEW


OPERATOR HMI CONTROL SYSTEM FIELD

OPERATOR VIEW


OPERATOR HMI FIELD

Keep the process in a safe state: •  Respond to alarms;

•  Change process setpoints;

•  Change working scheme;

ENGINEER VIEW


CONTROL SYSTEM

ENGINEER VIEW


CONTROL SYSTEM

SCADA server

Backup SCADA Historian

Domain server

PLC

PLC

Office network

•  Users and parameters configuration;

•  Pull information from PLC every 0,5s for trending purposes;

•  Forward user commands;

•  Update HMI screen

Vendor software: ABB, Siemens, Schneider,

Rockwell Automation,….

Internet

PLC PROGRAMMER


CONTROL SYSTEM

SCADA server


Domain server

PLC

PLC

Vendor software: ABB, Siemens, Schneider,

Rockwell Automation,….

PLC PROGRAMMER

PLC PROGRAMMER


PLC 2

PLC 1

PLC 4

PLC 3

•  Connect inputs from field sensors,

•  Write PLC process code,

•  Implement process dependencies and safety interlocks.

PLC PROGRAMMER

TYPICALLY SERIAL COM

PLC?


PLC –PROGRAMMABLE LOGIC CONTROLLER


PLC 2

PLC 1

PLC 4

PLC 3 •  Embedded device enabled to run code; suitable for process automation

•  Serial or over TCP

•  Talks: Modbus, DNP3, MMS, IEC family, Profibus,….

Modbus, DNP3, MMS, IEC,…

INSIDE PLC


Source:PAControl.com

PLC OPERATION


CHECK INPUT STATUS

EXECUTE PROGRAM

UPDATE OUTPUT

•  Read all inputs from the field;

•  Read relevant data from other PLCs;

PLC PROGRAMMER

•  Assign I/O address to all field inputs

•  Assign input address to outputs from other PLCs


How is data stored?

•  Combination of vendor + plant implementation policies;

•  Exact mapping specific to each particular PLC.

Source: vendor websites

PLC OPERATION


CHECK INPUT STATUS

EXECUTE PROGRAM

UPDATE OUTPUT

•  Execution of the

main code •  Ladder logic,

boolean expressions

PLC OPERATION


CHECK INPUT STATUS

EXECUTE PROGRAM

UPDATE OUTPUT


main code •  Ladder logic,

boolean expressions if INPUT 1 and (INPUT 2 or INPUT 3) then OUTPUT 1

PLC OPERATION


CHECK INPUT STATUS

EXECUTE PROGRAM

UPDATE OUTPUT


main code •  Ladder logic

PLC PROGRAMMER

•  Write code to run in a loop;

•  Implement process dependencies;

PLC OPERATION

12/10/12 zoni & D. Hadziosmanovic 26

CHECK INPUT STATUS

EXECUTE PROGRAM

UPDATE OUTPUT

•  Collect and update

outputs: output 1= alert; output 2 = input 4 for

PLCx; ……

PLC PROGRAMMER

•  Assign I/O address to all outputs – so the data can be pulled by other PLCs

PLC PROGRAMMER EXAMPLE


PLC 2

PLC 1

PLC 4

PLC 3

PLC PROGRAMMER

•  INPUTS: PLC1: Register 100: % valve opening Register 101: process counter Register 102: tank level •  CODE: 1. Heating for 10min 2. Wait 1min 3. Draining 10min

•  DEPENDENCIES: If (tank level in PLC1 >100) close valve in PLC3.


HOW CAN THINGS GO

WRONG?


PROCESS-RELATED THREAT SYSTEM-RELATED THREAT


PROCESS-RELATED THREAT (un)intentionally bring the process in an undesirable state

PROCESS-RELATED THREATS


a) MAIN SYSTEM - an unintentional operator mistake or insider attack (e.g., Maroochy water breach); 3 months , 1000000 l sewage water out [Slay08] b) NETWORK - e.g., send malicious command “write water level tank setpoint (on address 5) to 98” “write water level tank setpoint (on address 5) to 2” 1 byte difference in PDU!

c) FIELD - compromise field sensors and send bad data wrong measurements unreliable automation [Liu2009]


SYSTEM-RELATED THREAT exploit a vulnerability in system software or communication protocol to cause problems

SYSTEM-RELATED THREAT


a) OPERATING SOFTWARE- on PLCs or SCADA [Stuxnet] [HeapModbus] [Auriemma] b) COMMUNICATION PROTOCOL- protocol design or implementation vulnerability unauthorised command execution [Carcano09] e.g., protocol: Modbus; no authentication;

specification incompliance [Byres06] e.g., send FC=8 subFC=4, result: drop TCP connection c) CONFIGURATION PROBLEM -in SCADA, firewalls, telemetrical systems access control, protection of radio communication [Slay08]

•  Introduction







AGENDA


Dina

Damiano

Damiano

Attack the process:

On reverse engineering

a production process


STARTING ASSUMPTION: a)  Have access to the plant network

OR b) Control the programming machine



CONTROL SYSTEM

SCADA server


Domain server

PLC

PLC

Office network

Internet

b) Control over the programming machine

a) Access to the plant network

LEVEL OF PROCESS KNOWLEDGE:

a) Know everything upload PLC code and send exact values that damage the process [Stuxnet]

b) Known nothing listen to communication and flip the values [Carcano09]

c) Discover!


MEANS OF INFORMATION INFERENCE


•  Gain control over the programming machine

•  Upload & download PLC code

•  Infer information from PLC configuration

[McLaughlin11]

•  Operate from plant network

•  Infer information from sending/observing network packets

[Gonzalez07][Shayto09][Oman07]

ATTACK THE PROCESS

HOST NETWORK



ATTACK THE PROCESS

HOST NETWORK

ACTIVE

PASSIVE

ACTIVE

PASSIVE



•  Query configuration data to acquire information about field device

(e.g.,collect device ID fieldbus.com) Stuxnet asked for device ID! •  Infer safety interlocks from PLC code (e.g., recover boolean expressions)

•  Discover plant devices

(e.g., upload scanner program to query device information)

ATTACK THE PROCESS

HOST

ACTIVE

PASSIVE



•  Record PLC “fingerprint” (e.g.,record used function codes, memory map locations) •  Infer data usage (e.g., reconstruct the usage of memory locations, send semantically dangerous data)

•  Discover PLCs (e.g., see who is talking Modbus) •  Discover functional implementation (e.g., scan Modbus FC to discover which codes are used)

ONGOING WORK

ATTACK THE PROCESS

NETWORK

ACTIVE

PASSIVE

Goal Infer part of process information

Approach Passive, unsupervised analysis of parsed network packets

Data resources Network data (Modbus, 3d + 30d) from 2 plant sites

ONGOING WORK - INFER DATA USAGE


Makes sense? YES. Total 16 PLCs in two plant sites.

Chatty. Different roles, similar behaviour.

ONGOING WORK


What do we see in observed data ?

A Typical PLC: Uses ~ 2200 memory addresses (registers),

~45% of registers hold constant values

~21% registers hold enum values, Rest are:

•  counters (up and down), •  trending data (from the field), •  process state

ONGOING WORK


MANY SETPOINT VALUES

MANY BITMAPS OF DEVICE STATUSES AND ALARMS

PROGRAM COUNTERS

REAL LIFE VALUES

PROGRAM STATE

So what?


Try to change normal process flow!

Water purification

Gas distribution

Train scheduling

Car production

Chocolate production


EACH CONTROL SYSTEM HAS: PROCESS STEPS, PROCESS RECIPE, PROCESS DEPENDENCIES.

EXAMPLE


A process: 1. Fill in ingredient 1 2. Fill in ingredient 2 3. Mix for 40min 4. Cool down 5. Add unhealthy chemicals 6. Cut into pieces 7. Pack


CONTROL SYSTEM

SCADA server PLC

PLC Ingredient 1

Ingredient 2

TANK LEVEL: 40 PROCESS STATE: 3 (cool down) Products per hour: 50

Product X


CONTROL SYSTEM

SCADA server PLC

PLC 1 Ingredient 1

Ingredient 2

Plc 1 Addr 5. 37 38 39 38 40 41 39… Addr 6. 11 12 13 14 15 16 17 … Addr 7. 40 40 40 40 40 40 40… ……. Addr 50. 4 4 4 4 4 4 4 4 4 4 4 4... Addr 51. 4 5 3 4 5 4 3 4 5 5 4 3… Addr 52. 4 2 3 5 4 2 3 5 4 2 3… Addr 53. 2 3 1 15 2 3 15 11 11….

MALICIOUS SCENARIO 1


Plc 1 Addr 5. 37 38 39 38 40 41 39… Addr 6. 11 12 13 14 15 16 17 … Addr 7. 40 40 40 40 40 40 40… ……. Addr 50. 4 4 4 4 4 4 4 4 4 4 4 4... Addr 51. 4 5 3 4 5 4 3 4 5 5 4 3… Addr 52. 4 2 1 4 2 1 4 2 1… Addr 53. 2 3 15 2 3 15 11 11….

FIND SETPOINT! •  Compare constants and

trending data

•  Identify and change setpoint: NEW VALUE: ADDR. 7 = 80 RESULT: MORE CHOCOLATE?




FIND SOME ALARMS! •  Look into enum data, are

they bitmaps?

•  Flip (non)changing bits?

RESULT: NO CHOCOLATE?

Value 2 0010 Value 3 0011 Value 11 1011 Value 15 1111




CHANGE PROCESS STEP! •  Look into sequences, are

they process states? •  Enforce process to skip one

state: 4 2 1 4 2 1 4 2 1

•  E.g., Write state 4 after 2… 4 2 4 4….

RESULT: NUTELLA? :p

•  Introduction







AGENDA


Dina

Damiano

Damiano

Attack the system:

On reverse engineering network

protocols for vulnerability analysis


§  There are many legacy systems out there

§  10 years ago vendors were not really keen on in-depth testing

§  Even new systems are based on legacy code

§  Cannot be really audited let alone replaced

§  Consultants/3rd-party engineers connect their laptops (almost) freely

§  Networks are seldom monitored

§  Network services are a good target to attack an ICS system

§  Remember their AIC model!

PLENTY OF OPPORTUNITIES


§  Forget about character-based protocols (HTTP, SMTP, etc.)

§  Some protocols are open, but vendors usually have their own stuff §  Proprietary protocols are harder to test…a single vulnerability

can allow a full take over

CHALLENGES IN ICS NETWORK PROTOCOLS


Ø Achilles testing platform from Wurldtech Inc §  Uses grammars to automatically select test cases §  Several attacks are based on connection/ping flooding

Ø Sally fuzzer §  Spun-off project from HP TippingPoint

§  Not really maintained

WELL-KNOWN TEST TOOLS FOR ICS


§  Install an Agent on the host §  Matches/intercepts incoming and outgoing traffic with data

structures/functions

§  Impractical in this context §  PLCs cannot be monitored in the same way

REVERSE ENGINEERING OF UNKNOWN PROTOCOLS WITH HOST-BASED AGENTS


§  Unlike character-based protocols, you won’t find any delimiters §  Bad for out-of-the-box automatic tools

§  New protocols have been built for carrying heterogeneous data §  Developers use, for instance, tags

§  PDUs can be of variable size…but the receiver must know how much data to expect

HUMANS DO IT BETTER


1a) Write protocol specs for known protocols 1b) Reverse engineer unknown protocols

§  Isolate fields

§  Length/string fields above all

2) Write a stub of the protocol specs for a standard fuzzer §  We like Peach, but there are many others

3) Automate tests with fuzzer

FIND MORE VULNERABILITIES YOURSELF!


?

QUESTIONS


[Slay08] J. Slay and M. Miller, Lessons Learned from the Maroochy Water Breach. ;In Proceedings of Critical Infrastructure Protection. 2007, 73-82 [Liu2009] Liu,Y.,Ning, P.,Reiter, M.: False data injection attacks against state estimation in electric power grids. In: Proceedings of 16th ACM Conference on Computer and Communications Security, CCS ’09, pp. 21–32. ACM, New York, NY, USA (2009) [Carcano09 ]Andrea Carcano, Igor Nai Fovino, Marcelo Masera, and Alberto Trombetta. 2009. Scada Malware, a Proof of Concept. In Critical Information Infrastructure Security, Roberto Setola and Stefan Geretshuber (Eds.). LNCS 5508. Springer-Verlag, Berlin, Heidelberg 211-222 [HeapModbus] CVE-2010-4709 Heap-based buffer overflow in Automated Solutions Modbus/TCP Master OPC Server [Byres06] E.J. Byres, D. Hoffman, and N. Kube, "On Shaky Ground - A Study of Security Vulnerabilities in Control Protocols," 5th American Nuclear Society International Topical Meeting on NPI, HMIT, American Nuclear Society, Albuquerque, USA, November 2006. [Stuxnet] N. Falliere, L.O. Murchu, and E. Chien. W32.Stuxnet Dossier. Technical report, Symantec, September 2010. [Oman07] P.W. Oman and M. Phillips, Intrusion Detection and Event Monitoring in SCADA Networks. In Proceedings of Critical Infrastructure Protection. 2007, 161-173.

INTERESTING REFERENCES


[Gonzalez07] J. González and M. Papa, Passive Scanning in Modbus Networks. ;In Proceedings of Critical Infrastructure Protection. 2007, 175-187. [Shayto09] Shayto, R; Porter, B.; Chandia, R.; Papa, M.; Shenoi, S. Assessing The Integrity Of Field Devices In Modbus Networks; Critical Infrastructure Protection II, The International Federation for Information Processing, Volume 290. ISBN 978-0-387-88522-3. Springer US, 2009, p. 115, 2009 [McLaughlin11] Stephen McLaughlin. 2011. On dynamic malware payloads aimed at programmable logic controllers. In Proceedings of the 6th USENIX conference on Hot topics in security (HotSec'11). USENIX Association, Berkeley, CA, USA, 10-10. [Auriemma] http://aluigi.altervista.org/

INTERESTING REFERENCES


Cyber Security in Industrial Control Systems - CRISALIS Project

Documents

Transcript of Cyber Security in Industrial Control Systems - CRISALIS Project