Vulnerability Inheritance in PLCs. K. Reid Wightman Director, Digital Bond Labs

Transcription

1 Vulnerability Inheritance in PLCs K. Reid Wightman Director, Digital Bond Labs

2 About Digital Bond Labs New division of Digital Bond Focused on working with vendors Finding new vulns in products Fixing bugs before they re an issue We find the kinds of bugs shown here I am biased Strong advocate of Red Teaming products Hire any outside team (or build your own)

3 Outline Vulnerabilities: What are they? Inheritance -3 rd party libraries Specific example Deep Dive Affected Vendor #1 Affected Vendor #2 Conclusion

4 Vulnerability In Industrial space this is strangely ambiguous, thanks to ICS-CERT My definition: Any mechanism which allows unauthorized changes to configuration or control Includes traditional bugs Authentication bypass Parsing errors Includes insecure by design

5 Outline Vulnerabilities: What are they? 3 rd party libraries Specific example Deep Dive Affected Vendor #1 Affected Vendor #2 Conclusion

6 3 rd Party Libraries Any OS (vxworks, GNU/Linux, Windows CE) Common embedded servers (GoAhead Webserver, fnord, boa, etc) Common libraries (OpenSSL, GNU/Bash) Specialized Industrial Libraries: CoDeSys, ProConOs

7 Ownership is the issue 3 rd Party Libraries You own any problems with 3 rd party software If Vendor software depends upon library, end user must have Vendor assurance that patch will work For embedded, end user needs Vendor to produce patched firmware Ex: Windows CE may have bugs Will vendor keep track of the bugs? Will vendor produce a patch to firmware? Will vendor inform customers of the patch?

8 Outline Vulnerabilities: What are they? 3 rd party libraries ICS-Specific example Deep Dive Affected Japanese Vendor #1 Affected Japanese Vendor #2 Conclusion

9 CoDeSys Programmable Logic Controller (PLC) Runtime and Engineering Software Used by hundreds of ICS vendors Primarily used in Europe, though some inroads into USA, Japan

10 CoDeSys: Select Vendors

11 CoDeSysComponents PLC Ladder Logic Runtime Runs on vxworks, WinCE, Linux, Nucleus, and others Executes ladder logic Comms for sending status and receiving commands Engineering Workstation (EWS) Software Common GUI for programming PLCs Supports LAD, STL, FBD, etc. Communicates with PLC via plugins OPC Server Gateway (Optional) between EWS and PLC

12 CoDeSys Components G L24V G 0V Y0 Y2 C1 Y5 Y7 Y10 Y12 C3 Y15 Y17 AC(L) AC(N) C0 Y1 Y3 Y4 Y6 C2 Y11 Y13 Y14 Y16 +V OUTPUT6-27V= :Sinking PWR: V~ 50-60Hz 1.0A Output 40VA Y X INPUT: 12-24V ~15mA PWR RUN CPU TX1 RX1 TX2 RX2 C0 X1 X3 X4 X6 C2 X11 X13 X14 X16 C4 X21 X23 N.C. X0 X2 C1 X5 X7 X10 X12 C3 X15 X17 X20 X22 N.C. PLC WWW Web Application Gateway Server OPC Server HMI Engineering Station

13 CoDeSysDeep Dive CoDeSysV2 protocol analysis and tools released in 2012 CoDeSysV3 protocol analysis done by DB Labs September 2014, internal tools developed The protocol changed a bit from V2 (more complex) Identical vulnerabilities as V2

14 CoDeSysV2 Flaws Unauthenticated ladder logic upload Unauthenticated command line for debugging Unauthenticated start/stop process control Directory traversal Upload/Download arbitrary files Rootkit deployment is free Many systems internet-connected (see joint paper with Éireann Leverett)

15 ICS-CERT advisory CVE (CVSS score: 10.0) CVE (CVSS score: 10.0) ICS-CERT Advisory ICSA

16 CoDeSysV3 Flaws Unauthenticated ladder logic upload Unauthenticated command line for debugging Unauthenticated start/stop process control Directory traversal quite likely Upload/Download arbitrary files Rootkit deployment possible Internet scan more difficult

17 CoDeSysDeployment Issues Usually installed/runs with root privileges (Linux) and SYSTEM (Windows) Why? CoDeSys runtime interacts with IO directly Easiest to run with elevated privs, instead of learning what is actually required A symptom of rushed development WHY? Bad news: CoDeSysruntime executes binary blobs that are uploaded to it, by design. rootkit ability is a side-effect.

18 No Security CoDeSysFlaws Summary Original vendor (3S-Software) may have assumed that no-one would learn protocol Original vendor (3S-Software) likely never had a Red Team look at components Original vendor has taken the stance, This is not our problem.

19 CoDeSysV2 Simple Protocol: Start bytes (usually 0xbbbb or 0xcccc), length field, function code, arguments Uses TCP/1200 (some systems use TCP/2455 or custom port) Determined how protocol works through protocol analysis (quite straightforward)

20 CoDeSysV2 3S Software included password protection in V2 Password protection was not enforced by PLC initially 3S Software provided patch for PLC to fix that To date, one model of PLC has the patch PLC-enforced password protection interferes with 3S OPC Server one reason offered by vendor Patching insecure-by-design is too late in Development Lifecycle Requires changing too much other software

21 CoDeSysV2 Ladder Logic PLC Runtime Loads DEFAULT.PRG into RAM Runtime then literally jumps into copied program Ladder Logic rootkit possible No verification of DEFAULT.PRG functionality PLC Runtime often runs with administrator privileges Needs access to hardware: read+write hardware I/O On poorly configured deeply embedded OSes(vxWorks), can read/write any memory Very bad design decision Example: Ladder Logic can call system()/execve() as root on Linux PLCs, if it wants

22 CoDeSysV2 Application Literally code injection, without authentication PC equivalent: service open on PC which accepts and runs binary blobs with admin privileges with no authentication Exploitation == learn how it works

23 CoDeSysV2 Lessons to Learn Apply Security Development Lifecycle to products Have Red Team review components Look at the design early and the implementation often Decide: Will we live with these vulnerabilities, will we fix them, or will we stop using the component? Determine how you will monitor and patch future problems Catching this problem early saved the two vendors who fixed it a lot of trouble

24 CoDeSysV2 Lessons to Learn Component DESIGN problems are contamination One component s insecure-by-design causes add-ons to expect that behavior Now instead of one fix, you need at least two The problem gets worse as more components communicate Fixing a design problem late is often impossible Great example: Modbus It could have security added via reserved function code but then every system on Earth would have to be changed

25 Protocol differs from v2 Can use UDP or TCP CoDeSysV3 UDP limits attack surface somewhat, although we can get around this TCP has not been thoroughly tested on live PLCs, only our simulator

26 CoDeSysV3 Notes No documentation on CoDeSysprotocols is publicly available Example presented is based entirely on reverse engineering and protocol analysis Our terminology may not match 3S Software s (debugging symbols removed from binaries, mostly) UDP/1740, TCP/11740

27 CoDeSysV3 First Packet M->S c e6 00 1e c a d5 79 f4 e1 17 9d f Destination Address, Last Octet E.g , 230 == 0xE6 Source Address, Last Octet E.g , 30 == 0x1E CRC CRC is calculated based on 0xC3 (byte 13) onward CRC algorithm is selected via protocol (more on this) Random Nonce

28 CoDeSysV3 First Reply S->M c5 f e 00 e a7 eb 4c e1 17 9d c de Session ID (2 bytes)

29 CoDeSysV3 Session Packet M->S c e6 00 1e c fd c fa b3 5e cd c a c c f9 Session Identifier, 2 bytes Master Sequence number Little Endian Unsigned Int Starts with 1, increments with each request from master Slave Sequence number Little Endian, increments with each response from slave Length CRC

30 CRC Algorithm Took some time to learn how this works Appeared to be CRC32 Several CRC algorithms implemented in GatewayService.exe, but no calls to these algorithms Debugged application to learn how it gets called

31 CoDeSysV3 CRC Selection (packet parser disassembly)

32 CoDeSysV3 CRC Selection Interesting place to look for bugs, both in EWS and Firmware Some suggestions that other fields in the protocol work the same way (no function references that we would expect in the disassembly) A good Red Team would shout about this implementation lots to go wrong

33 CoDeSysV3 UDP Security Security completely dependent upon session ID Local Subnet == Hacker wins 100% Remote Subnet == Easy to work around Session ID only values 2 bytes (up to values) but PLC increments value by 4 with each new session

34 So CoDeSysV3 IsVulnerable! ICS-CERT gets it wrong ICS-CERT probably got this information from 3S- Software. They don t verify vendor claims.

35 So CoDeSysV3 IsVulnerable! 3S-Software gets it wrong Bad Info ( affects V2.3? Also V2.4 and V3!) Only OEMs can download patch

36 CoDeSysV3 Lessons 3 rd party library vendor analysis Most will say, We have no problem Ask to see vendor s SDL documentation Trust But Verify Bring in Red Team and test yourself

37 CoDeSysV3 Lessons ICS-CERT reports untrustworthy ICS-CERT either can t do or can t publish own analysis Pretty obvious in this case would have spotted problem in 1 day of analysis Does more harm than good in this case (V3 users read, we aren t vulnerable, unlikely to pay attention to future issues)

38 Outline Vulnerabilities: What are they? 3 rd party libraries Specific example Deep Dive Affected Vendor #1 Affected Vendor #2 Conclusion

39 Vulnerable Vendor Highlight Hitachi EHV+ Line CoDeSysV3

40 Hitachi EHV+ Line: CoDeSysV3 EHV-CPU 1025 tested UDP only* Command line disabled* * These features might be enabled via updating config.cfg file on the PLC. No success yet.

41 Hitachi EHV+ Line: What They Did Right Hitachi deserves some credit EHV+ has no open TCP ports by default Only one open UDP port that we could tell (CoDeSys V3) This is much smaller attack surface than most vendors

42 Hitachi EHV+ Line No mechanism seen for applying a firmware update (Have not reverse engineered firmware, though, so maybe there is a way)

43 Hitachi EHV+: Exploiting UDP No security on CoDeSysV3 Protocol, just SID 2 bytes, so range is but PLC increments by 4, so only values No mechanism for adding password via CoDeSys Engineering Software Exploit script capabilities tested: Stop/Start CPU Retrieve/Send Ladder Logic Send New config.cfg Change IP address

44 Attacking UDP Attacker Network Router CoDeSys PLC PC (Might not exist)

45 Attacking UDP Attacker Request Session Source address: PC Network Router CoDeSys PLC PC (Might not exist)

46 Attacking UDP Attacker Network Router PLC Sends Session ID To Local PC PC may not expect message, or PC may not exist! CoDeSys PLC PC (Might not exist)

47 Attacking UDP Attacker Attacker must guess Session ID to STOP CPU Network Router CoDeSys PLC PC (Might not exist)

48 Outline Vulnerabilities: What are they? 3 rd party libraries Specific example Deep Dive Affected Vendor #1 Affected Japanese Vendor #2 Conclusion

49 Vulnerable Vendor Highlight Sanyo-Denki SanMotion C CoDeSysV2 vxworks debugger service Backdoor accounts (FTP)

50 Sanyo-Denki SanMotionC

51 SanMotionC FestoCECX-X-M1

52 SanMotion C Festo CECX-X-M1 Keba CP 232/Z

53 Festo/Sanyo/OEM? Festoand Sanyo seem to use same OEM Identical firmware on all systems Also in use by Keba, Kuka, Trumpf, Haitian, Buehler, Duerr, Engel, and other vendors OEM probably Keba Automation CP 232/Z (Austria) Tons of software components in system vxworks CoDeSys CANOpen protocol stack Etc

54 Festo/Sanyo/EtcVulnerabilities CoDeSysV2 All V2 problems exist First contacted Festo via ICS-CERT in early 2013 See ICS-CERT advisory ICSA , Festorefused to fix any problems vxworks Debugging Backdoor CVE Unauthenticated read/write to all memory Vulnerability was 5 years old at product release Backdoor FTP account CANBus debugging protocol ports

55 Festo/Sanyo/EtcVulnerabilities Of the 9 total companies affected, none of them spotted the security problems Likely that none of these companies do internal or external red teaming Unknown if any of these companies share vulnerability information (what about hardware defect information?)

56 Outline Vulnerabilities: What are they? 3 rd party libraries Specific example Deep Dive Affected Vendor #1 Affected Vendor #2 Conclusion

57 Conclusions but first.nl Shared scan script with John Matherly~2014 CoDeSys now searchable on Shodan country:nl 3s-smart 68 total devices (number has been increasing) Quite a few devices in Netherlands! Many HVAC systems One navigation/engine controller identified onboard a ferry (public transportation) Mostly devices for which we do not know the purpose

58 On Scanning for Systems Leverett smetric: cost for finding vulnerable devices 2013 stats: 600 devices found on Internet, cost was 1.30 per discovered device Cost: VPS rental and time to massage data 2015 stats: 1500 devices found on Internet, cost is 0.01 per discovered device Cost: 17 for Shodanfilter access

59 On Scanning for Systems Hardest part is what to do with device lists Most CERT/CSIRT have no authority to do anything May have friends at ISPs/companies, but cannot compel action Most ISPs refuse to forward security advisories to clients Legal issues abound: sometimes not allowed, sometimes afraid if we do it for this vuln, and not another, we may get sued Very rarely, device owners can be identified, but even they don t always take action One recent conversation: Yes, that is ours, but we don t know where it is.

60 Conclusions Identify security issues before product release Vendors should build list of 3 rd party products and monitor them for vulnerabilities In Sanyo-Denki example, controller released April 2010 (5 years after vxworksvulnerability widely known) In Hitachi example, EHV+ line released before v2 vulnerability was public, ~June-September Should have been noticed during internal security analysis

61 Plan to Patch Conclusions 2 Design an update mechanism Secure by design (functional/interface security) Genuine bugs are then easy to patch Design problems major problem for ICS Ex: Schneider patches webserver directory traversal (Billy Rios) quickly, but years later design problems persist Ex: 3S Software patched directory traversal bugs (Aaron Portnoy) quickly, took >1 year to patch CoDeSys design problem.

62 Questions? Reid Twitter