原创 | OPC UA .NET Standard Stack可信应用认证绕过漏洞分析
The following article is from 网络安全应急技术国家工程实验室 Author CISRC
漏洞概述
OPC UA .NET Standard Stack是OPC基金会官方维护的OPC UA协议栈的参考实现。该参考实现采用.NET语言开发，包含了可移植的OPC UA协议栈和核心库（包含客户端、服务端、配置、复杂类型支持库等）。
OPC UA协议是工业控制领域中的一种十分流行的通讯协议，启明星辰ADLab研究员在漏洞情报跟踪中发现该可信应用认证绕过漏洞（编号为CVE-2022-29865）后对该漏洞进行了深入分析和验证。
漏洞分析
该漏洞影响OPC UA .NET Standard Stack的应用认证机制。根据协议规范，OPC UA客户端和OPC UA服务端是通过创建Secure Channel来进行应用层（Application Layer）的会话（Session）数据传输，如下图所示：
图 1、OPC UA安全架构-客户端/服务端[1]
在客户端和服务端创建Secure Channel时，有一个应用认证机制（App Authentication），该机制是基于应用证书（Application Instance Certificate）来实现的。具体参见OPC UA security architecture 6.1.3【2】:
图 2、确定应用证书是否可信
漏洞CVE-2022-29865即是针对此证书校验机制的绕过。OPC UA .NET Standard Stack校验应用证书的关键代码位于协议栈源码文件CertificateValidator.cs的InternalValidate函数中，如下图的关键代码逻辑：
在883行处，调用GetIssuersNoExceptionsOnGetIssuer获得待校验证书的颁发者，并检查其是否为信任的证书颁发者。在该函数中，首先通过GetIssuersNoException函数来获取客户端证书的Issuer并创建证书链，然后检查证书链中的Issuer是否在自己的信任列表中。在检查Issuer过程中，调用了Match函数。
Match函数将待校验证书Issuer名称和潜在Issuer证书的Subject Name进行对比，此外还检查证书的X.509 Extension中Authority Key Identifier属性中的Serial number和潜在Issuer证书的Serial number是否匹配或者key id是否匹配。如果issuer名匹配且serial number或key_id中有一项匹配，则GetIssuersNoExceptionsOnGetIssuer会返回true。
Match函数调用CompareDistinguishedName进行匹配，如下所示：
图 3、Match函数调用CompareDistinguishedName对比Issuer Name
但是，函数CompareDistinguishedName内部直接忽略了大小写，如下图所示。
图 4、CompareDistinguishedName忽略大小写对比Issuer Name
显然，在这个证书匹配过程中，没有对证书的签名进行校验，而仅仅根据证书的元信息进行匹配，而且在Issuer时还忽略大小写。因此，可伪造证书元信息来通过该函数校验。
在909行处，InternalValidate函数使用X509Chain进行待校验证书的证书链创建。如下图所示，该过程对证书的签名等信息进行校验，在创建后通过CheckChainStatus函数来检查证书链是否存在问题，结果在result中保存。如果证书链检查没有问题，则result变量为空。至此，证书校验的大部分工作已经完成，后续还会对证书的密钥用途、长度等进行校验。
在CheckChainStatus函数中，将根据证书链元素的不同状态返回不同的结果。但是，对于UnTrustedRoot状态，只需要证书的签名合法，如下图所示。
因此，可通过伪造证书来使验证中：GetIssuersNoExceptionsOnGetIssuer函数返回true，CheckChainStatus函数因UntrustedRoot不产生错误，从而使InternalValidate函数因正常返回而通过证书校验。
漏洞复现
复现环境
OPC UA Vulnerable Server
OPC UA .NET Standard Reference Server（Version: UA-.NETStandard-1.4.368.53）
OPC UA Client
Unified Automation UA Expert
复现过程
首先，编译OPC UA .NET Standard Reference Server。修改配置文件Quickstarts.Reference Server.Config.xml，将Server应用证书从默认的自签名证书修改为由CA颁发的证书。然后，将CA证书添加到Server的信任证书列表中。最后，启动该OPC UA Server。
图 5、配置OPC UA Server证书
图 6、配置OPC UA Server可信证书存储
图 7、OPC UA Server应用证书和CA证书
根据OPC UA Server的应用证书信息（可在OPC UA客户端认证的时候获得），使用python cryptography库生成伪造证书，并将其设置为uaexpert应用证书，如下所示：
图 8、OPC Client UaExpert使用的伪造应用证书
在UaExpert中配置OPC UA Server信息，使用上述伪造的应用证书登录成功。
图 9、UaExpert配置Server信息
图 10、UaExpert使用伪造证书成功登录OPC UA Reference Server
漏洞修复
根据OPC UA的官方漏洞公告【3】，该漏洞在OPC UA .NET Standard 1.4.368版本中修复。实际在Commit 51549f5ed846c8ac060add509c76ff4c0470f24d中该问题就已被修复。
主要修复的方式如下：
1.证书信息对比采用了二进制方式对比。
2.增加了对证书链构造的校验，确保证书验证中构造的两个证书链是一致的。
参考：
1.https://reference.opcfoundation.org/v104/Core/docs/Part2/4.5.1/
2.https://reference.opcfoundation.org/v104/Core/docs/Part4/6.1.3/
3.https://files.opcfoundation.org/SecurityBulletins/OPC%20Foundation%20Security%20Bulletin%20CVE-2022-29865.pdf
来源：网络安全应急技术国家工程研究中心
启明星辰积极防御实验室（ADLab）
ADLab成立于1999年，是中国安全行业最早成立的攻防技术研究实验室之一，微软MAPP计划核心成员，“黑雀攻击”概念首推者。截止目前，ADLab已通过CVE累计发布安全漏洞近1100个，通过 CNVD/CNNVD累计发布安全漏洞2000余个，持续保持国际网络安全领域一流水准。实验室研究方向涵盖操作系统与应用系统安全研究、移动智能终端安全研究、物联网智能设备安全研究、Web安全研究、工控系统安全研究、云安全研究。研究成果应用于产品核心技术研究、国家重点科技项目攻关、专业安全服务等。