技术分享 | OPC UA简介及安全性分析
导语：
2018年5月，SecureList公布了针对OPC UA的几个安全问题的分析报告。由于OPC UA被广泛应用于工业4.0，随之而来的问题变得十分突出。
首先我们需要了解一下OPC UA的前身OPC，OPC是OLE for Process Control的简写，即用于过程控制的OLE（OLE即面向对象的链接和嵌入），是一个诞生于1996年的工业标准。由OPC Foundation（OPC基金会）维护。OPC基金会现有200多家会员单位，包括各大主要的自动化、仪器仪表、过程控制系统的公司和企业，研究机构等。
早期，不同厂商的产品，其监控系统通常使用各自专用的通讯协议，互相不兼容。OPC协议的目的是在不同的工控系统、遥测、监控系统之间建立起统一兼容的接口，规范工业企业的控制流程。
OPC技术最主要的优点是解决了不同厂商开发造成的异构问题。使得工业控制解决方案可以具有更简单的系统结构，更长的寿命，更低的成本。同时现场设备与系统的连接也更加简单方便，灵活高效。
OPC主要涉及领域包括：
1）数据采集软件：众多硬件厂商提供的产品均带有标准的OPC接口。
2）历史数据访问：OPC提供了读取存储在过程数据存档、数据库或远程终端设备中的历史数据及操作编辑的方法。
3）报警和事件处理：OPC服务器发生异常或设定事件时，可以向OPC客户端发送通知，从而更好地捕捉控制过程中的各种报警事件，给予相应处理。
4）数据冗余：冗余技术是工业控制系统长期稳定工作的重要保障技术。OPC提供了软件冗余。
5）远程数据访问：高性能的远程数据访问使得工业控制软件之间的数据交互更加方便。
早期的OPC基于微软的DCOM（分布式COM）技术，衍生出一些明显的局限性，例如操作系统依赖性，多端口鉴权导致的实现复杂性和安全问题等。尤其2002年微软提出了.NET并停止了COM/DCOM的研发，使得OPC的前景更加黯淡。为了摆脱这些DCOM的局限性，OPC Foundation重新设计发布了一套升级版本的OPC协议，称之为OPC UA。原来的基于DCOM的OPC也被称为OPC DA。
OPC UA（全称IEC 62541 OPC Unified Architecture），即OPC统一架构，是由OPC Foundation于2006年发布的一套标准。用于重要工业网络和关键基础设施网络中不同系统之间的数据安全传输。OPC UA作为OPC的改进版本，在现代工业环境中可以说无处不在。
OPC UA相对于OPC，摆脱了对微软DCOM技术的依赖，具备良好的设计架构。在自动化厂商中迅速普及。越来越多的工业企业都安装起了OPC UA网关，其协议也越来越多地应用于工业互联网组件，智能设备之中。
工业4.0概念，最初源于德国人根据其工业基础，生产经验以及已有的科技手段总结出的一套理论体系。工业4.0提出了“智能制造”的模式，要求有效整合生产资源，快速适应市场的生产要求。要求智能工厂的解决方案必须具备标准化、实时性、横向协同、纵向整合、SOA架构的物联网系统、工业大数据、应用场景可扩展、安全性等诸多特性。对照这些特性，智能工厂的解决方案提供商们发现，OPC UA具有便于整合标准化的产品家族，完全满足作为工业4.0的技术路线的要求。
同时，对于物联网信息系统的开发者，OPC UA是规范的实施数据中间件开发框架，具备功能完整性、易用性、可扩展性、跨平台、支持多种开发语言的特点。
目前支持OPC UA的情况：
Siemens最新PLC已嵌入OPC UA Server
通用公司的工业互联网平台采用了OPC UA架构
SAP的智能制造管理系统
Unified Automation
PLCOpen
Harting 的RFID Reader
……
1） OPC UA框架的技术层面设计，开发和产品化由OPC基金会联盟旗下多家厂商参与制定和实现。
OPC UA的基础代码由OPC Foundation组织开源维护，有C，Java，.NET等多个版本实现。以下是一份参考列表。
https://github.com/opcfoundation
https://github.com/open62541/open62541/wiki/List-of-Open-Source-OPC-UA-Implementations
2） 众多厂商基于开源代码修改并支持该通讯体系
OPC UA框架是独立于厂商，平台无关，多种开发语言实现的。其访问统一性，冗余性和可靠性要求都相当高。基于这一考虑，为了能完整支持该通讯体系，众多工业和自动化厂商都选择基于开源代码，尤其是OPC Foundation的代码来修改并快速实现对OPC UA的支持。
3）OPC Foundation的代码本身就有若干漏洞，uastack.dll
问题在于，OPC Foundation提供的ANSI C的UA实现代码，本身就有许多问题，代码分析表明其中包括大量指针运算，不安全的数据结构，magic常数等等显而易见的问题。
举例说明：
在使用了UA .NET Stack的.NET程序中，某些数据包含一个is_xml字段，默认值为0，应用程序使用了XmlDocument函数来处理这个字段。在.NET 4.5之前，.NET易受到XXE攻击，只要将is_xml字段从0改为1，并精心构造一段XML数据，就能以NT Authority/SYSTEM权限读取远程计算机上的任何文件，甚至可能升级为RCE（远程任意代码执行）。
此外，通过一组fuzzing实验，研究人员发现并在2018年初披露了17个0-day漏洞。虽然OPC Foundation及时响应和修补了漏洞，但是，参考使用了这套代码的商业开发者却并没有及时跟进修补。
目前这些漏洞主要有两个类型，DoS和远程代码执行。我们知道，在工业控制系统中，DoS的危害实际是大于远程代码执行的，也远大于其它类型的漏洞。DoS可能造成生产停顿，工业过程中断，甚至设备损坏，从而带来严重的经济损失。
4）第三方应用程序引入的新的安全问题。
另外一个问题在于导出API的不正确调用。
原始的开源代码中，并不包含合适的单元测试代码或者自动测试的代码。因此使用OPC UA Stack的第三方软件中的缺陷往往是由于开发人员未正确调用OPC Foundation的uastack.dll库中实现的API的功能而导致的。例如，传输的数据结构中的字段值不正确。或者修改了从uastack.dll中数据读取的逻辑，放弃了原始例程中的附加检查。
举例说明：
某个第三方编译的Uastack.dll中存在一个堆破坏漏洞，由于从socket中读取数据的函数会错误地计算数据的大小，然后该数据被复制到堆上的缓冲区内，精心设计网络数据会导致RCE（远程任意代码执行）。经过仔细检查，OPC Foundation版本中并无此漏洞，显然是第三方调用的时候被引入到代码中的。
OPC Foundation开放了源码，并且做了很多工作致力于使其更加安全。然而对源码的分析和商业软件的漏洞挖掘表明，OPC UA的协议栈仍然相当脆弱。OPC UA框架的开发人员和各大厂商的二次开发人员也暂时并未将安全问题作为第一要考虑的事情。
基于这种现状，小威提示：要谨慎使用OPC UA协议的工业自动化产品，建议增设额外的防护措施以缓解潜在的安全问题。
威努特的工控安全监测与审计平台，采用先进的工业协议白名单机制，能有效地针对协议层出现的不符合规约的网络报文进行监测和告警。有助于发现和防范不合规的网络数据对采用了OPC UA协议的自动化产品造成的危害，帮助重要工业网络和关键基础设施的用户更有效地应对各种已知和未知漏洞，保障工业系统更稳定地运行。
威努特工控安全
专注工控·捍卫安全