This document discusses vulnerability inheritance in programmable logic controllers (PLCs) from third-party libraries and software. It provides a specific example of vulnerabilities found in the CoDeSys runtime and engineering software used by hundreds of industrial control system vendors. The document outlines how two major Japanese PLC vendors were found to be affected by these vulnerabilities due to their use of CoDeSys, and concludes that vendors need to implement secure development practices like security testing to prevent inheriting vulnerabilities from third-party components.

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
– …but honestly, hire any outside team (or build your
own)

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

4. Vulnerability
• Any mechanism which allows unauthorized
changes to configuration or control
• Includes traditional bugs
– Authentication bypass
– Parsing error
• Includes ‘insecure by design’

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

6. 3rd Party Libraries
• Any OS (vxWorks, GNU/Linux, Windows CE)
• Common embedded servers (e.g. GoAhead
Webserver)
• CoDeSys

7. 3rd Party Libraries
• Ownership is the issue
• You ‘own’ any problems with 3rd 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
patch
• 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?
• 3rd 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
Basic Components
• Engineering Workstation (EWS) Software
– Common GUI for programming PLCs
– Supports LAD, STL, FBD, etc.
– Communicates with PLC via plugins
• PLC Ladder Logic Runtime
– Runs on vxWorks, WinCE, Linux, Nucleus, and others
– Executes ladder logic
– Service for sending status and receiving commands
• OPC Server
• Gateway (Optional) between EWS and PLC

11. CoDeSys Deep Dive
• CoDeSys V2 protocol analysis and tools released
in 2012
• CoDeSys V3 protocol analysis done by DB Labs
September 2014, internal tools developed
– The protocol changed a bit from V2 (more complex)
– Identical vulnerabilities as V2

12. CoDeSys V2 – Flaws
• Unauthorized ladder logic upload
• ‘Secret’ command line
• Start/Stop process control
• Directory traversal
• Upload/Download arbitrary files
• Rootkit deployment possible
• Many systems internet-connected (see joint
paper with Eireann Leverett)

13. CoDeSys V3 – Flaws
• Unauthorized ladder logic upload
• ‘Secret’ command line
• Start/Stop process control
• Directory traversal quite likely
• Upload/Download arbitrary files
• Rootkit deployment possible
• Internet scan underway

14. CoDeSys Flaws Summary
• No Security
• 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

15. Red Team
• If Internal, best if they are dedicated to security
work (not the developers)
• Focus on looking for design problems early in
development
• Focus on looking for implementation problems as
development progresses
• Red Team should have spotted CoDeSys
problems
• Likely that affected vendors have no Red Team

16. CoDeSys V2
• 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 easy)

17. CoDeSys V2
• 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, 0 vendors have applied patch to PLCs
• “PLC-enforced password protection interferes
with 3S OPC Server” (heard from anonymous
friend)
• ‘Patching’ insecure-by-design is too late in
Development Lifecycle – Requires changing too
much other software

18. CoDeSys V2 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

19. CoDeSys V2 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

20. CoDeSys V3
• Protocol differs from v2
• Can use UDP or TCP
– UDP limits attack surface somewhat, although we can
get around this
– TCP has not been thoroughly tested on live PLCs, only
our simulator…

21. CoDeSys V3 Notes
• No documentation on CoDeSys protocols 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

22. CoDeSys V3 First Packet M->S
c5 73 40 40 00 11 00 e6 00 1e 00 00 c3 00 01 01
6a d5 79 f4 e1 17 9d 84 00 40 1f 00 04 00 00 00
• Destination Address, Last Octet
– E.g. 192.168.63.230, 230 == 0xE6
• Source Address, Last Octet
– E.g. 192.168.63.30, 30 == 0x1E
• CRC
– CRC is calculated based on 0xC3 (byte 13) onward
– CRC algorithm is selected via protocol (more on this)
• Random Nonce

23. CoDeSys V3 First Reply S->M
c5 f3 40 40 00 11 00 1e 00 e6 00 00 83 00 01 01
51 a7 eb 4c e1 17 9d 84 00 00 00 2c 94 24 00 00
01 04 62 de
• Session ID (2 bytes)

24. CoDeSys V3 Session Packet M->S
c5 73 40 40 00 11 00 e6 00 1e 00 00 01 81 00 2c
37 02 00 00 fd 01 00 00 1c 00 00 00 97 fa b3 5e
cd 55 00 0c 00 02 00 10 00 00 1a c5 00 00 00 0c
81 01 88 00 11 84 80 00 00 00 45 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
• CRC

25. …So CoDeSys V3 Is Vulnerable!
• ICS-CERT gets it wrong
• Anonymous friend: “ICS-CERT probably got this
information from 3S-Software. They don’t verify
vendor claims.”

26. …So CoDeSys V3 Is Vulnerable!
• 3S-Software gets it wrong
• Bad Info (‘affects V2’)
• Only OEMs can download patch

27. CoDeSys V3 Lessons
• 3rd party library vendor analysis
– Most will say, “We have no problem”
– Ask to see 3rd party vendor’s SDL documentation
– “Trust But Verify” – Bring in Red Team and test
yourself

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

29. Vulnerable Vendor Highlight
Hitachi EHV+ Line
– CoDeSys V3

30. Hitachi EHV+ Line: CoDeSys V3
• 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.

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

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

33. Hitachi EHV+: Exploiting UDP
• No security on CoDeSys V3 Protocol, just SID
– 0-65535
– But PLC increments by 4, so only 16384 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

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

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

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

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

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

39. Vulnerable Vendor Highlight
Sanyo-Denki SanMotion C
– CoDeSys V2
– vxWorks debugger service
– Backdoor accounts (FTP)

40. Sanyo-Denki SanMotion C

41. SanMotion C
Festo CECX-X-M1

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

43. Festo/Sanyo/OEM?
• Festo and 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

44. Festo/Sanyo/Etc Vulnerabilities
• CoDeSys V2
– All V2 problems exist
– First contacted Festo via ICS-CERT in early 2013
– See ICS-CERT advisory ICSA-14-084-01, Festo refused
to fix any problems
• vxWorks Debugging Backdoor CVE-2005-3804
– Unauthenticated read/write to all memory
– Vulnerability was 5 years old at product release
• Backdoor FTP account
• CANBus debugging protocol ports

45. Festo/Sanyo/Etc Vulnerabilities
• 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?)

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

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

48. Conclusions 2
• “Plan to Patch”
– 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
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. Still 0 adoption of that
patch!

49. Questions?
Reid Wightman
wightman@digitalbond.com
@ReverseICS – Twitter