前言

继上篇，最近小老板布置了一个任务，做一下关于这篇thesisSecurity Analysis of OPC UA in automation systems for IIoT的pre，也就是Cover一下这篇thesis，遂在研究这篇thesis的literature review，发现其大量引用了OPC UA reference，所以刚好以此reference为学习资料，学习一下安全领域、IIoT、ICS的各种知识。(*^_^*)

在写完所有的威胁介绍后，发现OPC UA在reference中对每一种安全都进行了reconciliation of that threat，于是乎今晚回到家后打算对这一部分进行整理，然后一并整合到这篇博文之中。（已于第二天下午补完reconciliation of that threat，\O(\∩_\∩)\O。）

正文

针对系统的威胁有很多种，我们这篇博文主要介绍OPC UA中介绍的，也就是ICS和IIoT常遇见的，有如下：

  1. Denial of Service
  2. Eavesdropping
  3. Message spoofing
  4. Message alteration
  5. Message replay
  6. Malformed Messages
  7. Server profiling
  8. Session hijacking
  9. Rogue Server
  10. Rogue Publisher
  11. Compromising user credentials
  12. Repudiation

1. Denial of Service

拒绝访问攻击(DoS)，是最出名也最常用的一个攻击，其主要目的就是让服务器宕机，或者让服务器无法正常访问，其主要手段可以通过Message flooding、Resource Exhaustion 和 Application Crashes来达成。

1.1 Message flooding

消息泛洪攻击(Message flooding)，攻击者可以发送大量消息或者大量请求的单个消息来耗尽服务器的资源，进而使服务器无法处理来自其他客户端的消息，更甚者会让服务器直接宕机。

1.2 Resource Exhaustion

资源耗尽攻击(Resource Exhaustion)，这类攻击往往会比毫无目的的消息泛洪攻击更有效果，因为攻击者会针对服务器上的每一个资源，发送特定的消息，这类消息往往一个就会用完服务器的一个资源，导致单个客户端能够获取服务器所有的资源，阻止其他客户端再访问服务器。例如，在只有10个会话的服务器上，攻击者将尝试打开所有10个会话，并且一直占用这10个会话，这就会导致其他客户端无法与服务器会话，因为服务器已经没有空余的会话通道了。

1.3 Application Crashes

应用崩溃攻击(Application Crashes)，这类攻击往往比泛洪和资源耗尽更加有效，因为它通常会直接让服务器崩溃并且宕机。在此类攻击中，攻击者将发送导致服务器应用程序（容器）崩溃的特殊消息，它可以上应用程序中已知的某些BUG，这些BUG将会产生系统错误并导致服务器崩溃，这样其他客户端也无法访问服务器了。

1.4 解决办法

由上可知，拒绝访问攻击将会影响可用性。针对此问题，OPC UA提出了自己的解决方法。针对消息泛洪攻击、资源耗尽攻击和应用崩溃攻击分别有各自的针对办法。

对于消息泛洪攻击，OPC UA通过在消息被验证之前最大限度减少对消息的处理量，从而最大限度地减少由消息泛洪攻击造成的可用性损失。这可以防止攻击者利用少量攻击就导致合法的OPC UA应用程序瘫痪。具体服务器实现可以通过两种方式来免受消息泛洪攻击，由于OpenSecureChannel是服务器和客户端通过身份验证之前处理的唯一服务，所以对OpenSecureChannel的响应会消耗大量服务器资源，主要是针对OpenSecureChannel响应的保护：

  1. 一旦服务器收到超过某个最小数量的错误的OpenSecureChannel的请求的时候，它可能会故意延迟其对OpenSecureChannel请求的处理，并且发出警报以提醒工厂人员正在进行的攻击会阻止新的合法的OpenSecureChannel的调用。
  2. 当OpenSecureChannel请求尝试超过服务器指定的最大并发通道数时，服务器会以错误响应进行恢复，而不执行签名和加密处理。（OS：错误响应隐藏了系统等信息了吗？不然会导致Server Profiling；但是这样其他客户端也无法开启OpenSecureChannel了吧，虽然保证了当前的会话正常，那如果攻击者同时对所有通道进行合法的会话，但是不处理呢？）

对于资源耗尽攻击，OPC UA用户和客户端身份验证降低了使用合法客户端进行耗尽攻击的风险。但是，如果合法的客户端执行了资源耗尽攻击（可能由于受损的用户凭据(Comprimising user credientials)），这时，服务器应该审核允许检测的客户端（允许检测？那不允许检测呢？），服务器还需要回收尚未完成的OpenSecureChannel，这将消除来自非合法客户端的攻击。

对于应用崩溃攻击，（私以为这更是OPC UA的问题，需要对自身产品进行足够的代码审计，不然会被攻击者利用某些已知或者0DAY漏洞来导致客户端/服务端崩溃。）攻击者可以可以发送将导致应用程序崩溃的特殊消息，这通常是堆栈或者应用程序中已知的问题的结果。这些系统错误可能允许客户端发出导致客户端崩溃的命令；或者可能是服务器的合法相应但是导致客户端崩溃。（但是OPC UA并没有给出解决的方案，只是阐述了一遍什么是应用崩溃攻击，hmmmm，/(ㄒoㄒ)/~~）

P.S.: DDOS攻击只能被减弱，无法被彻底消除。来自知乎《如何防御DOS及DDOS攻击？》。

2. Eavesdropping

窃听(Eavesdropping)，窃听指未经授权而获取某些敏感信息。如果这类敏感信息关乎于系统，可能直接导致严重的安全漏洞；如果这类敏感信息关乎于数据，可能直接导致用户严重的个人信息泄漏。

窃听将会直接影响机密性，如果会话没有被安全地建立，并且在不安全的会话中进行身份验证和授权的话，它将会造成严重的后果，甚至间接威胁到所有其他的安全目标(e.g., 可用性)。

针对此问题，OPC UA提出了加密的解决办法。为了保证机密性，OPC UA用了混合密码机制，通过公钥密码来进行密钥协商，通过对称密码来进行消息加密。（公钥密码可以解决密钥配送问题，但是加密耗时长，所以用公钥密码来进行传递密钥；用快速的对称密码来进行加密。）

3. Message spoofing

消息欺骗(Message spoofing)，指的是攻击者可能会伪造客户端来给服务端发送消息、或者伪造服务端来给客户端发送消息，以试图破坏机密性、完整性甚至授权等安全目标。

欺骗可能发生在协议栈的多个层。

通过欺骗来自客户端、服务端的消息，攻击者可以执行为授权的操作并且客户端和服务端将不会发现（因为他们没有意识到自己并没有和正确的对象进行沟通）

消息欺骗将会影响完整性和授权。

OPC UA对于消息欺骗的解决办法是对消息进行签名。同时，消息将始终包含有效的SessionId、SecureChannelId、RequestId和时间戳以及正确的序列号（这样的话消息就没有办法在中途被欺骗？）

4. Message alteration

消息更改(Message alteration)，攻击者通常在截获客户端/服务器的消息之后，可以对其进行更改，这种消息可以是网络流量或者应用层的消息，在更改之后再转发给客户端或者服务器，以实现对应的目的，e.g.,消息更改可能允许非法访问系统。

消息更改将会影响完整性、授权、可审计性、抗否让行以及会话/安全通道建立期间的身份验证。

OPC UA的解决办法：通过指定的消息来计数消息更改。（为什么不直接用one-way hash function，单向散列函数？）如果消息被更改，检查签名将显示任何并允许收件人丢弃消息。此检查还可以防止由于通信传输错误导致的意外消息更改。

5. Message replay

消息重放(Message replay)，攻击者可以在捕获来自网络流量或者应用层的消息后，重新发送给客户端/服务端，而不进行任何的修改。这将会导致攻击者可以误导客户端/服务端在某些不恰当的时间进行某些命令，例如在ICS系统中的控温系统中，重复发送升高温度的消息，可能会导致严重的后果。

消息重放影响授权和会话/安全通道建立期间的身份验证。

解决办法中描述了，由于在会话中，OPC UA为每个请求和响应消息使用了SessionIds、SecureChannelIds、时间戳、序列号和Requests。并且这类的签名是经过签名的，还有所谓的通过指定的消息来计数消息更改（想了想不适用于单向散列函数？不是人不能够实时确认？）。因此，消息可以被签名且不能在没有检测到的情况下更改（何为不能在没有检测到的情况下更改？），导致重放消息会变得异常困难。

6. Malformed Messages

格式错误消息(Malformed Messages)，攻击者可以制作各种具有无效消息结构的恶意消息（格式错误的XML、SOAP、UA二进制）或者数据值等消息，并将它们发送到客户端/服务端。客户端/服务端可能会通过执行未经授权的操作或者处理不必要的信息来错误的处理某些格式错误的消息。这将可能会导致拒绝服务、或者服务降级，包括应用程序的终止，或者在嵌入式设备的情况下，完全崩溃，例如拒绝服务中的应用崩溃攻击。

格式错误的消息将会影响完整性和可用性。

OPC UA应用程序的实现通过检查消息是否具有正确的格式以及消息的参数是否在其合法范围内来对抗格式错误消息的威胁,e.g., 白名单（详见解决办法）（但是也许能够被绕过？这样也会增加对抗DoS的负担）

7. Server profiling

服务器分析(Server profiling)，攻击者试图推断服务器或者客户端的身份、类型、软件版本甚至供应商，以便通过漏洞库学习有关产品的特定漏洞知识来发起更具侵略性或者破坏性的攻击，服务器分析通常是一次攻击的起始。攻击者可能通过向目标发送有效或者无效的格式化消息来分析目标的响应，通过这些正常或者错误的响应来识别目标的类型。

服务器分析将间接影响所有的安全目标。

OPC UA的解决办法是通过限制了服务器提供给尚未识别的客户端的信息量。（那如果是已经验证的用户但是未授权的用户呢？应该只给安全人员返回一定的响应吧？）

8. Session hijacking

会话劫持(Session hijacking)，攻击者可以使用有关在两个程序之间建立的正在运行的会话的信息（通过嗅探通信或者通过猜测来检索）来注入被操作的消息（具有有效的会话消息），从而允许攻击者从授权用户/或者服务器手上接管会话，并造成一系列安全后果，例如，攻击者可能会未经授权访问数据或者执行未经授权的操作。

会话劫持会影响所有的安全目标。

正如之前所说的，OPC UA会为每个会话开启安全通道OpenSecureChannel来对抗会话劫持（解决办法）。因此，如果需要劫持Session首先需要破坏安全的上下文，即安全通道。

9. Rogue Server

流氓服务器(Rogue Server)，攻击者可能构建恶意的流氓服务器例如，Evil Twin，或者在系统中安装未经授权的服务器实例来尝试伪装成合法的服务器，通过与此流氓服务器进行会话，客户端可能会造成验证、授权的数据泄漏，继而通过客户端验证、授权信息的泄漏造成更严重的后果。

流氓服务器会影响除完整性和抗否认性之外的所有安全目标。

由于OPC UA客户端和服务端的沟通过程中，客户端会用服务端的公钥对消息进行加密（需要验证，但是Sean认为应该是这样的）。这就会导致，没有正确私钥的流氓服务端是无法解密这样的信息的。同时流氓服务器也无法对消息进行签名，因为他没有正确的私钥，客户端会对签名验证失败。（解决办法）

10. Rogue Publisher

流氓发布者(Rogue Publisher)，其具体的定义与实现类似流氓服务器(Rogue Server)，只不过一个是Client-Server架构，一个是Publisher-Subscriber架构。（并且如果我没有猜错的话，在ICS中，Server对应的是Subscriber，而Client对应的是Publisher，所以这里Rogue Publisher也可以看作的Rogue Client?）

流氓发布者会影响除完整性和不可否认性之外的所有安全目标。

同流氓服务端一样，如果流氓的发布者没有有效的私钥对消息进行签名的话，正常的订阅者是无法通过正常发布者发布的公钥来对这样的消息进行验证的，因为这样的没有被正确私钥签名过的验证会失败。（解决办法）

11. Compromising user credientials

受损的用户凭据(Comprimising user credientials)，攻击者可以通过社工的方法（纸、屏幕、电子通信）来观察用户的凭据，例如用户名、密码、证书或密钥等，或者通过社会工程学密码生成软件强行爆破以此来获得用户的凭据。这类有效的用户凭据可以让攻击者启动并且访问系统以获取所有信息并且进行控制和修改，从而损害工厂运营或者信息，这类受损的用户凭据一旦泄漏，后续的任何活动看起来都是合法的。

受损的用户凭据会影响用户身份验证、授权和机密性。

这类攻击其实更多与社工有关，用户没有很好的保护好自己的凭据，OPC UA能做的解决办法就是在会话中，开启安全通道OpenSecureChannel，保证用户的凭据在会话的过程中不被窃听。同时，OPA CU依靠站点CSMS来防止其他攻击以获取用户凭据，例如密码猜测或社会工程。（什么是站点CSMS？找了半天没有找到，知道的小伙伴求告诉一下\0.\0）

12. Repudiation

否认(Repudiation)，攻击者可以通过对某件已经发生的事情进行否认、或者对某件未曾发生的事情进行诽谤，这往往不会是直接对系统（客户端、服务端）的攻击，因为它与会话无关，更多的是会话之后的信任，这将会导致数据的发送者和接受者出现信任危机。

否认影响抗否认性

OPC UA的解决方法是通过客户端和服务端签署指定的消息来对抗否认，这一过程需要用到客户端的私钥。签名消息能够表明消息来自客户端的私钥，在OpenSecureChannel的会话建立期间，通信方应该清楚地识别和确认。

总结

以OPC UA为例子，介绍了各种各样存在于IIoT和ICS，甚至其他系统中的威胁。同时，也介绍了每个威胁所影响的安全目标。但是，私以为有的并不一定只影响这么一点，例如消息欺骗(Message spoofing)，钓鱼(Phishing)完全可以影响机密性，但也许钓鱼也可以列入到流氓服务器(Rogue Server)中，这一点我们见仁见智。

除此之外，今天晚上将会对OPC UA在reference中的reconciliation of that threat进行一系列的补充。（已经补全，虽然是在第二天的下午）

参考

[1] Security Analysis of OPC UA in automation systems for IIoT
[2] OPC UA Online Reference - 4.3 Security threats to OPC UA systems
[3] 如何防御DOS及DDOS攻击？

Q.E.D.

立志做一个有趣的碳水化合物