OPC UA Assessment Series

13 Oct 2008 | 2008

Digital Bond has just completed a security assessment report on the OPC Unified Architecture [UA] protocol, and we will be issuing a series of blog posts supported with SCADApedia content on the results.

The assessment included both a paper security review of the multi-part OPC UA specification and an application assessment of the OPC Foundation’s Software Development Kit [SDK]. The SDK consists of a communication stack that vendors can build OPC UA applications on top of as well as sample client and server applications. The OPC UA security controls are in the communication stack. You can think of this as an assessment of a library with the sample client and server exercising the library.

This is an ideal time to review OPC UA security. The specifications are complete enough to support a review, and the SDK that many vendors will use to develop OPC UA client and server applications is out in beta, and OPC UA is not yet used in production systems. So by identifying and correcting vulnerabilities now, we can prevent them from getting deployed and avoid the reluctance and difficulty in making changes in operational systems.

The tentative organization of this series is:

One last point that is important to highlight in this introduction is the OPC Foundation’s interest in security. The OPC Foundation took an attitude that is still all too rare. They were eager and supportive of this assessment. In addition to the specification and SDK that any member can get, the OPC Foundation also provided the source code. In return, Digital Bond provided the OPC Foundation the full assessment report including findings and recommendations.

In discussions throughout the assessment it was very clear the OPC Foundation wanted to identify any security problems, and they wanted to fix them. In fact, you will note that Part 7 will list how the OPC Foundation has addressed and corrected the majority of the findings. We are aware a lot of this is already done or in process, but we will hold off on Part 7 until the revised specification and SDK are available.

Positive Findings

Security assessments by their nature focus on negative findings that could lead to vulnerabilities, and the preponderance of our report focused on what Digital Bond viewed as security deficiencies in the OPC UA specification and SDK code. That said, there are numerous examples of positive findings and text in the report. In fact, there is no comparison between the security in OPC UA and the security of any other control system protocol, with the possible exception of Secure DNP3 and its IEC equivalent. The OPC Foundation should be commended for their security efforts and pressure should be applied to other protocols to step up.

[Note: The security details of OPC UA are being written on a SCADApedia page as the OPC UA blog series is being published]

The major positive security findings are:

  • The OPC UA specification supports options for the use of encryption for confidentiality and signatures for source authentication and integrity. Asset owners using OPC UA will be able to secure client / server communication using the protocol itself rather than add-on security.
  • OPC UA uses a profile approach for specifying functionality including the crypto algorithms and key lengths. This provides flexibility and extensibility. For example, a country or industry sector may develop a new algorithm or select a set of algorithms and parameter settings. These could be listed as a new profile without changing the OPC UA specification. Additionally, the current profiles have leveraged existing, vetted crypto primitives and algorithms rather than try to tackle the difficult process of developing a new security algorithm. Smart choice. [Slight negative – we would have liked to see elliptic curve cryptography because of its computational and message overhead efficiency, but it was not included in the additional profiles due to patent and licensing issues].
  • The overall code quality of the OPC UA SDK was very good. The code base is surprisingly clean of vulnerabilities for a code base of its size. In fact, it is among the cleanest code Digital Bond has seen in the control system space. The code is well written, easy to follow and contains good use of comments. Many common coding errors were not found. For example, there were no off-by-one buffer overflows found, very limited use of insecure function calls, and good boundary checking of buffers both on the stack and on the heap. There are a number of well-written OPC wrappers of common C functionality. Comments in the code remind developers to use safe functions.
  • The security event logging required by the specification will be a fantastic help to attack detection and after incident analysis. It is the best the Digital Bond team has seen in this space by far.

Specification Vulnerabilities

OPC UA is a complex, interleaved 12-part specification. To understand OPC UA security one has to read multiple parts of the specification, but we have provided an overview in an OPC UA SCADApedia page that continues to be developed.

The specification analysis portion of our assessment report had many findings at the Exposure, Concern and Observation level. This is not unusual given the complexity of the specification, and the effort required to maintain consistency across many different parts of the specification. Also, we want to reiterate that the OPC Foundation is addressing many of these findings, and we will provide the resolution or mitigation when available in Part 7 of this series.

So here are the highlights:

The biggest issue we found in numerous parts of the OPC UA specification was the security features can provide a high level security, but an OPC UA user could easily have a false sense of security even with a compliant product with security measures turned on. Even worse, the default, out-of-box configuration could be compromised even in an OPC UA server that is billed by a vendor as secure because it is encrypted and signed.

X.509 Certificate Infrastructure
The specification requires OPC UA client and server applications create self-signed certificates at application installation. Any entity or attacker can create a self-signed certificate. This is similar to verifying a person’s identity by asking the person if he is who he claims to be. No trust should be placed on a self-signed certificate without some sort of out-of-band process.

The specification allows OPC UA client and server applications to accept self-signed and other certificates without any automated or manual process to determine if a certificate should be trusted. It is likely that many vendors, and subsequently many users, will want to avoid the difficulties of deploying a public key infrastructure (PKI) or forcing a manual process to approve new certificates as they arrive at the OPC UA client or server.

The result is an OPC UA server, even one requiring encryption and signatures, could be compromised by anyone who is able to gain access to OPC UA client software. The attacker would just have an encrypted and authenticated Secure Channel to pass attacks through to the server. The OPC UA specification should be modified and be very clear that all certificates must be explicitly trusted through a PKI or other process prior to use. This is true for both the OPC UA client and server receiving an unknown application instance certificate.

The specification also is unclear and conflicting in places on the requirement to sign and encrypt security critical service messages, most importantly, OpenSecureChannel and CloseSecureChannel messages. It appears at one time the intention was to make security mandatory on these messages even when the Message Security Mode is set to NONE, which would provide a useful minimal level of security prior to any communication, but the specification has not accomplished this due to conflicting information in different specification parts.

If Secure Channels are allowed to be created and closed without security the OPC Foundation should modify the specifications to indicate there are Secure Channels and Channels. Again this is a false sense of security issue with someone thinking they are getting security from a Secure Channel even though sign and encrypt are set to none.

Other Issues

  • The Secure Channel used to register an OPC UA Server with a Discovery Server could have sign and encrypt set to NONE and be considered compliant with the specification. An attacker could use this to fool users with OPC UA clients into connecting to a spoofed OPC UA server.
  • There were no requirements for the random number generation used in the crypto. This is a recurring area of vulnerabilities in other protocol implementations.

There were many areas in the specification that provided the vendor with implementation choices that would have a dramatic impact on the security of the OPC UA server. We will cover these in Part 5 of the series. These are not necessarily deficiencies in the specification, but a yellow flag for potential OPC UA users that all OPC UA security is not equal.

SDK Vulnerabilities

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.

Vendor Implementation Security Considerations

During our application assessment of the OPC UA SDK, it was very clear that vendors creating OPC UA clients and servers are going to make a number of choices that affect security of their offerings. All OPC UA servers will not be created equal from a security perspective.

When the fixes from our assessment are completed, which hopefully will remove some of the possibilities for a vendor to do something insecure, we plan on issuing a Security Considerations For the Purchase of an OPC UA Server document. In the meantime here are some of the interesting areas:

  • Certificate Handling: This is a huge area as mentioned in previous parts of this blog series. How are self-signed certificates going to be marked as trusted or replaced with signed certificates? Verify, preferably through testing, that self-signed certificates will not be accepted or used until specifically trusted. How can a CA certificate be trusted and then used to automatically trust any certificates signed by that CA? How are trusted certificates removed or marked as untrusted? Does this close any open Secure Channels that relied on the now untrusted certificate?
  • Message Processing: The specification recommends, but does not require, “strict message processing”. The recommendation is messages that are not in the required format be dropped and an appropriate error logged. This would significantly lessen the effectiveness of fuzzing to identify and exploit coding errors. An OPC UA server should return a Bad_DecodingError or Bad_EncodingLimitsExceeded ServiceFault if message processing fails. A reasonable test is to fuzz the OPC UA protocol and verify one or the other of these Service Faults is returned.
  • Authorization: Authorization is left completely up to the vendor implementation. How are roles supported? How granular is the authorization? This will be a huge area to consider for some implementations.
  • Key Storage: OPC Security relies on the secure key storage of a client or servers asymmetric private key. If this key is known an attacker could recover all of the other keys. Part 4 of the specification says, “Each application instance certificate has a private key which should be stored in a location that can only be accessed by the application”. However it does not levy any specific requirements or testing of this general requirement. Potential purchasers should learn how the private key is stored and determine if there are possible or likely circumstances in which an attacker would be able to gain access to this private key.
  • Secure Channel / Session Compromise: Part 4, Section 5.3 levies requirements that a Secure Channel or Session be immediately terminated if “through some out-of-band mechanism” that security credentials have been compromised. However there are no specifications or recommendations of out-of-band mechanisms or requirements on how the termination should take place.
  • Denial of Service Protection: There are a number of considerations in this category. For example, the OPC UA specification requires the server vendor to identify the maximum number of Secure Channels it will support, but it does not require the server to stop establishing Secure Channels as the threshold is neared or reached. Vendors should program these limits into the server application. It may prevent new Secure Channels, which would likely have a very minor short-term impact since Secure Channels are long lasting, but it would prevent a complete loss of availability. The server application should also set a high priority alarm as the threshold is neared and met.
  • Random Number Generation: Random numbers are used to create the security parameters used in the Secure Channel and Session establishment. A weak random number generator could compromise all the other security algorithms used in OPC UA. The specification recommends a number of random number generators, but does not have any specific requirements on the random number generator algorithm or process.

Beyond these items, there is the issue of secure coding practices – – or lack thereof. These tend to be ignored when people are purchasing a “standard protocol”. The folly of believing all OPC implementations are created equal was seen in Langner’s denial of service testing paper from S4, Mora’s 24 test cases for overflows and other problems, and Lewis’s DCOM endpoint checking. And this was on the old OPC that had been out for years. It is reasonable to ask vendors about their security development lifecycle, see copies of their design documents, QA tests and results, and any security analysis performed. I’m not going to throw stones at specific vendors in this blog entry, but Digital Bond definitely has OPC vendors we recommend to be avoided and those we recommend from a security perspective. We expect this will be true for OPC UA implementations, maybe even more so.