In the OPC UA SDK assessment, Digital Bond analyzed the OPC UA source code and binaries from the SDK. It should be noted that the source code will be unavailable to most OPC Foundation members.

As mentioned in Part 1 the overall code quality was quite good, but there were a small number of important findings including heap and stack overflows. Some of these overflows were in orphaned code, that should nevertheless be removed, and would not have affected an OPC UA application. Details on all of the identified vulnerabilities in the code have been provided to the OPC Foundation, and we anticipate they will be fixed in the next revision of code.

Perhaps the most serious finding came from black box testing using the Server Test Application provided with the SDK. In this case, the team used the provided Server Test Application as a ‘fuzzer’ caused the OPC UA server to crash, typically after three to ten connections. It is common for attackers to use and enhance test tools as attack tools, so this must be considered a likely attack.

We also analyzed, to the degree possible, the security component of the development teams’ software development lifecycle. Recommendations for improvement included automated source code testing, using compiler security options (such as memory randomization at load time, stack canaries and C# microcode obfuscation) and implementing security checklists.

WARNING
The OPC UA SDK evaluated in this assessment should be viewed as a library that OPC UA client and server applications will call. Very simple sample applications are included in the SDK, but they do not fully exercise the SDK. This leads to two warnings:

1. OPC UA client and server applications will have significant vendor specific application code, some of which will call this SDK. Some vendors will have a secure development process with minimal, or at least minimal easily exploitable, vulnerabilities. If history is a guide, most will not have significant security in the development process and introduce vulnerabilities. This is similar to what we saw from Mora’s and Langner’s 2007 S4 papers on OPC vulnerabilities. Same OPC protocol implementations, even interoperable, but very different quality of implementations from a security perspective.

2. More extensive black box testing could and should be done when more representative OPC UA client and server applications are available.

See the rest of the OPC UA blog series:

• Part 1: Intro
• Part 2: Positive Findings
• Part 3: Specification Vulnerabilities
• Part 4: SDK Vulnerabilities
• Part 5: OPC UA Vendor Implementation Vulnerabilities
• Part 6: Asset Owner Tip Sheet to Analyzing The Security of Competitive OPC UA Servers
• Part 7: Specification and SDK Improvements