Cyber Security in Industrial Control Systems - CRISALIS Project

SysSec Summer School “Cyber Security in Industrial Control Systems” Amsterdam October 12, 2012

Damiano Bolzoni Dina Hadziosmanovic DISTRIBUTED AND EMBEDDED SECURITY RESEARCH GROUP.

AGENDA

Damiano

•  Introduction •  Regular IT vs. ICS •  How ICS works? •  A bit about PLCs.

Dina

•  How can things go wrong? •  Attack the process: On reverse engineering a production process.

Damiano

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

D. Bolzoni & D. Hadziosmanovic

12/10/12

2

WHAT “INDUSTRIAL CONTROL SYSTEMS” MEANS?


12/10/12

3

ICS != SCADA != DCS != PCS (PA) §  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: everything SCADA: wide geographical areas DCS: a single location PCS/PA: one step of the process

THE SECURITY CYCLE “Regular” IT

ICS

§  Change every 3-5 years

§  Change every 10-20 years

§  Cyber security is at a mature stage

§  Cyber security is at a very early stage

§  Most people understand cyber risks

§  Windows XP is (eventually) disappearing

§  People seldom understand cyber risks

§  Full of Windows XP §  And other legacy systems (15 years old) D. Bolzoni & D. Hadziosmanovic

12/10/12

5

WHAT ABOUT THE 3 SECURITY PROPERTIES? “Regular” IT §  Confidentiality: 50% §  Integrity: 30% §  Availability: 20%

ICS §  Availability: 60% §  Vendors have VPN lines coming into PCS…

§  Integrity: 35% §  Confidentiality: 5%


12/10/12

6

ARCHITECTURE & PROTOCOLS “Regular” IT §  Standard architectures/ protocols §  Proprietary/unknown components are present to a certain extent

ICS §  There is no standard architecture §  Most protocols are open, but with proprietary implementation

§  Massive amount of proprietary components


12/10/12

7

PATCHING & RECONFIGURATION “Regular” IT §  (Security) patches are released regularly

ICS §  Vendors are quite slow in providing patches

§  Applied almost right away

§  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” D. Bolzoni & D. Hadziosmanovic

12/10/12

8

SECURITY STANDARDS, REGULATIONS AND METHODOLOGIES ICS

“Regular” IT §  There are several ISO standards §  2700x series

§  There are international regulations §  SOX

§  No real international standards §  NIST (USA)

§  If a regulation exists, it’s mostly “local” §  NERC (USA)

§  There are well-known methodologies to perform assessments §  OSSTMM

§  There are no standard methodologies to assess security §  Several vendors are trying to propose theirs D. Bolzoni & D. Hadziosmanovic

12/10/12

9

AGENDA

Damiano


Dina


Damiano



12/10/12

10

HOW ICS works? Operator, ICS engineer, PLC programmer


12/10/12

11

OPERATOR VIEW

OPERATOR

HMI

CONTROL SYSTEM


FIELD

12/10/12

12

OPERATOR VIEW

Keep the process in a safe state: •  Respond to alarms; •  Change process setpoints; •  Change working scheme; OPERATOR

FIELD

HMI


12/10/12

13

ENGINEER VIEW

CONTROL SYSTEM


12/10/12

14

Internet

ENGINEER VIEW

Backup SCADA

Office network

Historian

PLC

•  Update HMI screen

PLC SCADA server

Vendor software: ABB, Siemens, Schneider, Rockwell Automation,….

Domain server

•  Users and parameters configuration; •  Pull information from PLC every 0,5s for trending purposes;

CONTROL SYSTEM

•  Forward user commands; D. Bolzoni & D. Hadziosmanovic

12/10/12

15

PLC PROGRAMMER

Backup SCADA

Historian

PLC

PLC SCADA server

Domain server

CONTROL SYSTEM

Vendor software: ABB, Siemens, Schneider, Rockwell Automation,….

PLC PROGRAMMER D. Bolzoni & D. Hadziosmanovic

12/10/12

16

PLC PROGRAMMER

PLC 1

PLC 3

•  Connect inputs from field sensors, •  Write PLC process code,

PLC PROGRAMMER PLC 2

PLC 4

•  Implement process dependencies and safety interlocks.

TYPICALLY SERIAL COM


12/10/12

17

PLC?


12/10/12

18

PLC –PROGRAMMABLE LOGIC CONTROLLER

PLC 3

PLC 1

Modbus, DNP3, MMS, IEC,…

PLC 2

•  Embedded device enabled to run code; suitable for process automation •  Serial or over TCP •  Talks: Modbus, DNP3, MMS, IEC family, Profibus,….

PLC 4


12/10/12

19

INSIDE PLC

Source:PAControl.com D. Bolzoni & D. Hadziosmanovic

12/10/12

20

PLC OPERATION

CHECK INPUT STATUS

•  Read all inputs from the field;

EXECUTE PROGRAM

•  Read relevant data from other PLCs; • 

Assign I/O address to all field inputs

• 

Assign input address to outputs from other PLCs

UPDATE OUTPUT


12/10/12

21

How is data stored? •  Combination of vendor + plant implementation policies; •  Exact mapping specific to each particular PLC.

Source: vendor websites D. Bolzoni & D. Hadziosmanovic

12/10/12

22

PLC OPERATION

CHECK INPUT STATUS

•  Execution of the main code •  Ladder logic, boolean expressions

EXECUTE PROGRAM

UPDATE OUTPUT


12/10/12

23

PLC OPERATION

CHECK INPUT STATUS

•  Execution of the main code •  Ladder logic, boolean expressions

EXECUTE PROGRAM

if INPUT 1 and UPDATE OUTPUT

(INPUT 2 or INPUT 3) then OUTPUT 1


12/10/12

24

PLC OPERATION

CHECK INPUT STATUS

•  Execution of the main code •  Ladder logic

EXECUTE PROGRAM • 

Write code to run in a loop;

• 

Implement process dependencies;

UPDATE OUTPUT


12/10/12

25

PLC OPERATION

CHECK INPUT STATUS

•  Collect and update outputs: output 1= alert; output 2 = input 4 for PLCx; ……

EXECUTE PROGRAM • 

UPDATE OUTPUT

PLC PROGRAMMER

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

zoni & D. Hadziosmanovic

12/10/12

26

PLC PROGRAMMER EXAMPLE

PLC 1

PLC 2

PLC PROGRAMMER

PLC 3

•  INPUTS: PLC1: Register 100: % valve opening Register 101: process counter Register 102: tank level

PLC 4

•  CODE: 1. Heating for 10min 2. Wait 1min 3. Draining 10min •  DEPENDENCIES: If (tank level in PLC1 >100) close valve in PLC3. D. Bolzoni & D. Hadziosmanovic

12/10/12

27

HOW CAN THINGS GO WRONG?


12/10/12

28

PROCESS-RELATED THREAT

SYSTEM-RELATED THREAT


12/10/12

29

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


12/10/12

30

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]


12/10/12

31

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


12/10/12

32

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] D. Bolzoni & D. Hadziosmanovic

12/10/12

33

AGENDA

Damiano


Dina


Damiano



12/10/12

34

Attack the process: On reverse engineering a production process


12/10/12

35

STARTING ASSUMPTION: a)  Have access to the plant network OR b) Control the programming machine


12/10/12

36

Internet Office network

a) Access to the plant network Backup SCADA

Historian

PLC

PLC SCADA server

Domain server

b) Control over the programming machine

CONTROL SYSTEM D. Bolzoni & D. Hadziosmanovic

12/10/12

37

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! D. Bolzoni & D. Hadziosmanovic

12/10/12

38

MEANS OF INFORMATION INFERENCE ATTACK THE PROCESS HOST

NETWORK

• 

Gain control over the programming machine

• 

Operate from plant network

• 

Upload & download PLC code

• 

Infer information from sending/observing network packets

• 

Infer information from PLC configuration

[McLaughlin11]

[Gonzalez07][Shayto09][Oman07]


12/10/12

39


NETWORK

ACTIVE

ACTIVE

PASSIVE

PASSIVE


12/10/12

40


• 

Discover plant devices

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

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)


12/10/12

41

MEANS OF INFORMATION INFERENCE ATTACK THE PROCESS •  Discover PLCs (e.g., see who is talking Modbus) •  Discover functional implementation (e.g., scan Modbus FC to discover which codes are used)

• 

ACTIVE

Record PLC “fingerprint”

(e.g.,record used function codes, memory map locations)

• 

NETWORK

PASSIVE

Infer data usage

(e.g., reconstruct the usage of memory locations, send semantically dangerous data)

ONGOING WORK D. Bolzoni & D. Hadziosmanovic

12/10/12

42

ONGOING WORK - INFER DATA USAGE

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


12/10/12

43

ONGOING WORK

Makes sense? YES. Total 16 PLCs in two plant sites. Chatty. Different roles, similar behaviour.


12/10/12

44

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

MANY SETPOINT VALUES MANY BITMAPS OF DEVICE STATUSES AND ALARMS PROGRAM COUNTERS REAL LIFE VALUES PROGRAM STATE


12/10/12

45

So what?


12/10/12

46

Try to change normal process flow! Water purification Gas distribution Train scheduling Car production

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

Chocolate production


12/10/12

47

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


12/10/12

48

PLC

Ingredient 1

TANK LEVEL:

40

Product X

PROCESS STATE: 3 (cool down)

Ingredient 2

Products per hour:

PLC

50 SCADA server


12/10/12

49

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….

PLC 1

Ingredient 1

Ingredient 2 PLC SCADA server


12/10/12

50

MALICIOUS SCENARIO 1

Plc 1

FIND SETPOINT! •  Compare constants and trending data

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… •  Identify and change setpoint: ……. Addr 50. 4 4 4 4 4 4 4 4 4 4 4 4... NEW VALUE: ADDR. 7 = 80 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… RESULT: Addr 53. 2 3 15 2 3 15 11 11….

MORE CHOCOLATE?


12/10/12

51


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 SOME ALARMS! •  Look into enum data, are they bitmaps? Value 2 Value 3 Value 11 Value 15

0010 0011 1011 1111

•  Flip (non)changing bits?

RESULT: NO CHOCOLATE? D. Bolzoni & D. Hadziosmanovic

12/10/12

52


Plc 1

CHANGE PROCESS STEP!

Addr 5. 37 38 39 38 40 41 39… •  Look into sequences, are Addr 6. 11 12 13 14 15 16 17 … they process states? Addr 7. 40 40 40 40 40 40 40… •  Enforce process to skip one ……. state: Addr 50. 4 4 4 4 4 4 4 4 4 4 4 4... 421421421 Addr 51. 4 5 3 4 5 4 3 4 5 5 4 3… •  E.g., Write state 4 after 2… 4 2 4 4…. Addr 52. 4 2 1 4 2 1 4 2 1… Addr 53. 2 3 15 2 3 15 11 11….

RESULT: NUTELLA? :p D. Bolzoni & D. Hadziosmanovic

12/10/12

53

AGENDA

Damiano


Dina


Damiano



12/10/12

55

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


12/10/12

56

PLENTY OF OPPORTUNITIES §  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!


12/10/12

57

CHALLENGES IN ICS NETWORK PROTOCOLS

§  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


12/10/12

58

WELL-KNOWN TEST TOOLS FOR ICS

Ø 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


12/10/12

59

REVERSE ENGINEERING OF UNKNOWN PROTOCOLS WITH HOST-BASED AGENTS

§  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


12/10/12

61

HUMANS DO IT BETTER

§  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


12/10/12

62

FIND MORE VULNERABILITIES YOURSELF!

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


12/10/12

64

QUESTIONS

? D. Bolzoni & D. Hadziosmanovic

12/10/12

65

INTERESTING REFERENCES [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. D. Bolzoni & D. Hadziosmanovic

12/10/12

66

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/


12/10/12

67