背景

在工业控制系统中，为了防止其他人员对组态工程文件进行修改，很多组态软件都支持对组态工程文件进行加密。当打开一个有密码的组态工程文件时，必须输入正确的密码方可查看和编辑该组态工程文件，否则不能打开，从而实现了工业控制系统中组态工程文件的安全管理。
本文中从厂商后门，设计缺陷，算法缺陷三个方面来介绍组态工程文件加密存在的安全问题，同时在最后总结了正确的组态工程文件加密的设计机制。

加密机制漏洞

厂商后门

厂商在设计组态工程文件加密机制的时候，会考虑到用户忘记密码这个需求，即用户在不输入密码的情况下绕过验证直接打开工程文件。用户只需要证明该组态工程文件属于自己，之后将组态工程文件发给厂商，厂商通过预留的后门（绕过密码）将用户的组态工程文件解密后再发回给用户。这样的设计虽然方便了用户，但是也为不法分子大开方便之门。攻击者只需要找到组态软件中的组态工程后门密码，也能在不输入密码的情况下编辑组态工程文件。
下面是某个国产的组态软件存在的后门问题，当配置文件的pass字段为1时，就能直接绕过组态工程密码保护机制打开组态工程文件。

设计缺陷

当然，很多厂商设计之初并不会预留后门。但是在设计加密组态工程文件的时候考虑不够周全，采用了下面的组态工程密码验证机制。

初看之下好像没有问题，但是仔细分析下来，输入密码并没有参与组态工程文件的加密，只是简单的对比了密码的哈希值，这就导致了可以通过修改组态工程文件中的密码哈希或者通过补丁的方式将本来应该走向错误的处理分支修改为走向正确的处理分支。通过这类方式也可以在不知道组态工程文件密码的情况下强行绕过组态工程文件密码保护机制而编辑组态工程文件。
这种安全问题不仅出现在国内的工控厂商，国外的工控厂商也会出现类似的问题。下图为三菱的某个组态软件中存在的组态工程文件密码保护机制绕过问题：

算法缺陷

组态工程文件密码需要作为加密密钥参与到组态工程文件的加密运算才能保证组态工程文件的安全。但是在算法选择一定要注意，选择弱加密算法也会存在组态工程文件密码保护绕过问题。
下面是一个存在安全问题的加密算法：

这个组态工程文件的加密算法选择了循环异或加密，但是众所周知，这个加密算法是非常容易被攻破的。在知道足够长度的明文情况下，可以把组态工程文件的密码key算出来。

漏洞挖掘

如何快速挖掘这类漏洞？对于玩二进制的同学非常简单：

1. 找到对比密码的地方，强制让其走向正确的分支，如果密码不参加加密流程就可以直接将工程文件打开。
2. 逆向加密或者解密算法，分析其弱点，如果容易受到已知明文攻击则编写利用程序解密工程文件。
   根据不同的场景，给出相应的评分，并进行上报：
   
   可以看到，这类漏洞评分是偏低的，偏低并不意味着是一个鸡肋的漏洞，和其他漏洞结合起来使用往往会有奇效。

安全加密机制

毫无疑问，组态工程文件加密的算法实现一定是需要让组态工程密码参与到数据的加解密运算中，否则使用密码的任何加密存储形式（sha1 ，md5，sha256等hash算法）都是没有作用的。在设计组态工程加密的机制要考虑以下原则：

1. 加密算法必须保证非常可靠，能够防止攻击者从加密的密文反向推出明文或者密钥。在这里，可以选择AES(Advanced Encryption Standard)这类非常成熟的加密算法。
2. 足够长度的salt是必须的，将salt值附加到密码后面作为加解密密钥以此来保证密钥强度，这样可以有效抵御字典暴力攻击。
3. 考虑到用户如果忘记密码，软件生产商必须有能力从用户的组态工程文件中恢复密码（当然留下后门密码肯定是不可取的），所以必须将正确的加密密钥通过非对称算法(如RSA2048)加密存到工程文件中，一旦证明了该组态工程文件是该用户所有的，软件生产厂商可以使用拥有的私钥去解密密文从而恢复密码。
4. 算法选择应该尽量选择现成加密库的算法，例如OpenSSL，减少开发商编写代码的成本。
   加密流程如图2所示：
   
   一旦存在有些粗心的用户忘记了自己的组态工程密码，只要能证明该组态工程文件为自己所有，那么用户就可以通过开发商找回密码，具体找回密码流程如图3所示：
   

总结

可以看到这类漏洞非常容易挖掘，但是难以修复——厂商往往要重新设计加密机制，这就导致了这类漏洞在国内厂商中几乎不出补丁。如果有想挖掘属于自己的工控CNVD编号的同学可以从这方面入手，很多工控软件厂商都存在类似的问题，我就不一一列举了。

[CTF入门培训]顶尖高校博士及硕士团队亲授《30小时教你玩转CTF》，视频+靶场+题目！助力进入CTF世界