最新的2021 top 10已经出来了，我们从A01开始进行一次详细解读，本系列会详细介绍各个漏洞的变化与内容，并会着重介绍新增的漏洞情况。本篇解读A02  Cryptographic Failures（加密机制失效）。

A02  Cryptographic Failures（加密机制失效）

因素

概述

上移一个位置到#2，以前称为敏感数据暴露，这更像是一种广泛的症状而不是根本原因，重点是与密码相关的失败（或缺乏密码）。这通常会导致敏感数据的泄露。包括显著的共同弱点列举（CWE）是CWE-259：硬编码密码的使用,CWE-327：破产或有风险密码算法，和CWE-331不足.

说明

首先要确定传输中数据的保护需求休息的时候。例如，密码，信用卡号码，健康记录、个人信息和商业秘密需要额外的保护，主要是在数据属于隐私法的情况下，例如欧盟的通用数据保护法规（GDPR）或法规，例如。，金融数据保护，如PCI数据安全标准（PCI DSS）。对于所有此类数据：

• 是否有明文传输的数据？这涉及到协议作为HTTP，SMTP，FTP也使用类似STARTTLS的TLS升级。外部互联网流量是危险的。验证所有内部通信，例如。，在负载平衡器、web服务器或后端系统之间。

• 是否使用了旧的或弱的加密算法或协议默认情况下还是在旧代码中？

• 是否使用默认加密密钥、生成弱加密密钥或重复使用，还是缺少正确的密钥管理或轮换？加密密钥是否签入源代码库？

• 是否未实施加密，例如，是否有任何HTTP标头（浏览器）安全指令或头丢失？

• 收到的服务器证书和信任链是否正确验证？

• 初始化向量是否被忽略、重用或不生成对于加密操作模式是否足够安全？是否在使用诸如欧洲中央银行这样不安全的运作模式？是加密当认证加密更合适时使用？

• 在没有密码的情况下，密码是否被用作加密密钥密码基密钥派生函数？

• 随机性是否用于加密目的而不是设计的满足密码要求？即使正确的功能是选择了，它是否需要由开发人员播种，如果没有，则已经开发人员在它的种子缺乏足够的熵/不可预测性？

• 是否正在使用MD5或SHA1等已弃用的哈希函数，或者加密哈希函数时使用的非加密哈希函数是否需要？

• 是不推荐使用的加密填充方法，如PKCS number 1v1。5使用中？

• 是加密错误消息还是侧信道信息可利用，例如以填充oracle攻击的形式？

请参阅ASVS加密（V7）、数据保护（V9）和SSL/TLS（V10）

如何预防

至少执行以下操作，并参考参考文献：

• 对应用程序处理、存储或传输的数据进行分类。根据隐私法确定哪些数据是敏感的，法规要求或业务需求。

• 不要不必要地存储敏感数据。尽快丢弃它可能或使用符合PCI DSS的标记化甚至截断。没有保留的数据是不会被盗的。

• 确保加密所有静态的敏感数据。

• 确保最新且强大的标准算法、协议和钥匙到位；使用适当的密钥管理。

• 使用安全协议（如TLS）加密传输中的所有数据前向保密（FS）密码，密码优先级由服务器和安全参数。使用指令强制加密像HTTP严格传输安全（HSTS）。

• 对包含敏感数据的响应禁用缓存。

• 根据数据分类应用所需的安全控制。

• 不要使用FTP和SMTP等旧协议进行传输敏感数据。

• 使用强大的自适应和salt哈希函数存储密码使用工作系数（延迟系数），例如Argon2、scrypt、bcrypt或PBKDF2。

• 必须选择适合于模式的初始化向量操作。对于许多模式，这意味着使用CSPRNG（加密安全伪随机数发生器）。对于需要现在，初始化向量（IV）就不需要CSPRNG了。在所有情况下，静脉注射对于一个固定的钥匙绝对不能使用两次。

• 始终使用经过身份验证的加密，而不仅仅是加密。

• 密钥应该以加密方式随机生成并存储在内存作为字节数组。如果使用了密码，则必须对其进行转换通过适当的密码基密钥派生函数。

• 确保在适当的情况下使用加密随机性，以及它没有以可预测的方式或低熵播种。大多数现代api不需要开发人员将CSPRNG植入得到安全保障。

• 避免不推荐使用的加密函数和填充方案，例如MD5，SHA1，PKCS 1号v1。5。

• 独立验证配置和设置。

攻击场景示例

场景1：应用程序在数据库使用自动数据库加密。然而，这个数据是检索时自动解密，允许SQL注入缺陷以明文形式检索信用卡号码。

场景2：网站没有对所有页面或支持弱加密。攻击者监视网络流量（例如不安全的无线网络），将连接从HTTPS降级到HTTP，拦截请求，并窃取用户的会话cookie。这个然后，攻击者重播此cookie并劫持用户的（已验证的）会话，访问或修改用户的私有数据。而不是在上面，他们可以更改所有传输的数据，例如汇款。

场景3：密码数据库使用未添加盐或简单哈希来存储每个人的密码。文件上载缺陷允许攻击者检索密码数据库。所有未加盐的散列都可以公开有一个预先计算的哈希表。生成的哈希简单或快速的哈希函数可能会被gpu破解，即使它们被破解了加盐的。

加密机制失效（敏感信息泄露）

在常规的渗透测试中我们很少会重视这个漏洞，但在红队和护网中这个漏洞变的尤为重要了，很多的入口点其实都是从这里进入的。

这里我们重点描述一下----工程加密机制漏洞（以下内容转自看雪）

背景

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

加密机制漏洞

厂商后门

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

设计缺陷

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

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

算法缺陷

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

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

漏洞挖掘

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

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

安全加密机制

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

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

总结

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