【论文笔记】疯狂的检测工具 —— 静态分析工具

本文目标：精度论文 “CryptoGuard: High Precision Detection of Cryptographic Vulnerabilities in Massive-sized Java Projects” 。

主要针对大规模的 JAVA 项目，静态分析加密API漏洞。论文发布于 2019 年的 CCS ，点击即可免费获取该工具，作者甚至提供了基准测试。近些年来，这类分析已经不足为奇了，继续探索无疑是为了提高精度，正是因为问题无法完全解决，研究才有了意义。CryptoGuard 提出了一个新颖的解决方向，或许能带给你一个新的视角~

视角一：关于检测分析，你或许想知道这些

为什么需要检测分析？必然是因为我们的系统不够安全。就密码算法而言，它的设计本身就是为了提供可证明的安全保障而存在的，但由于一些底层的漏洞，使得这些算法的安全性大大降低。虽然攻击还未发生，但我们势必要防患于未然，除了培训相关人员、规避舆论误导外，我们技术人员能做的就是对程序进行检测分析。

一个程序的检测分析一般包括静态分析和动态分析。

• 静态分析： 不需要执行程序，可扩展，覆盖广泛的安全规则，并且不太可能漏检。
• 动态分析： 需要执行程序，实时检测，观察特定症状，往往具有更少的误检。

CryptoGuard 选择了静态分析方法，其所谓依据应该考虑到进行实验的目的性。 CryptoGuard 的目标是检测密码API的误用 ，针对的是大规模的 Java 项目，这就使得我们在进行工具的选择时不能随心所欲。考虑到这类项目一般为部署级代码，那么选择筛选工具时就要考虑其弹性。上面介绍过，静态分析可扩展，因此静态工具将具有很强的可伸缩性，这便是 依据 。

但是现状是什么呢？现有的基于静态分析的工具并不能在大规模的 Java 项目中运行(或者说，不够优化)，这就是 突破口 。

具体的：现有检测工具检测 SSL/TLS API 受限；不能检测复杂场景。
什么算大规模的 Java 项目呢？ 像那种涉及到数百万LoC的程序就算。
(LoC，the Lines of Code，代码行)

既然提到检测分析，就不得不提一下切片技术。

• 程序切片： 识别影响或受程序变量影响的指令集(大概就是将一部分内容单拎出来分析)。
  包括前向和后向的程序切片技术，其算法通过使用流(flow-)、上下文(context-) 和字段敏感(field-sensitive) 的数据流分析来实现。

总之，我们需要一个使用了切片技术的高精度、低消耗的静态分析工具，下面就来看看 CryptoGuard 是怎么做的吧！

视角二：凡事儿都要想清楚问题在哪儿

要检测至少得清楚测啥吧，下面我们仔细分析一下，先贴个表：
文章一共检测了16种漏洞，并对其做了分类，我们从简单的分类属性说起吧。

• 选择评测的 密码属性(Crypto Property) 有这么几个方面：机密性、完整性、真实性、随机性。

• 这些密码易受五大 类型攻击(Attack Type) (根据 攻击收益 和 攻击难度 划分 严重级 )：

  1. 像密钥、密码这样的可预测 常量 不安全。
     本文假设任何 常量 或 由 API 调用派生的值 都不安全，这些都是硬编码密码，即便 Android 的 APP 只能访问自己的 KeyStore ，攻击者也可以通过升级越权，因此 严重级：高(H) ；
  2. Java Secure Socket Extension (JSSE) API 定制不当，导致针对 SSL/TLS 的 中间人(MitM) 攻击；
     此类攻击收益高、难度低，因此 严重级：高(H) ；
  3. 伪随机数生成器(PRNG) 可预测。
     例：java.util.Random 不安全、 java.security.SecureRandom 可预测；
     可预测性降低了攻击难度，因此 严重级：中(M) ；
  4. 基于密码的加密(PBE) 的 盐值 易受 选择明文攻击(CPA) 以及 字典攻击。
     静态初始化向量(IV) 的密码分组链接模式(CBC) 和 电子密码本模式(ECB) 不安全；
     CPA 也降低了攻击难度，因此 严重级：中(M) ；
  5. 密码机制 不够安全，暴力攻击仍未被解决。
     像伪造数字签名引起的哈希冲突、pre-image 攻击等能够破坏完整性，因此这部分 严重级：高(H)
     一些我们熟知的 密码机制 ——如 MD5、SHA1；64 位对称密码(如 DES、3DES、IDEA、Blowfish)；1024 位的 RSA、DSA、DH；160 位的 ECC ；少于 1000 次迭代的 PBE ——都会被暴力攻击，但攻击难度较大，因此 严重级：低(L) 。

（我认为啊，不管是密钥、密码啊，还是随机数、盐值，基本上都是在讲数的问题，或者说，在解决常量的问题）

• 分析方法(Our Analysis Method) 分为 前向切片(↑) 和 后向切片(↓) 。进程间前向切片按需地用于仅数据类的敏感性字段，过程间后向切片一般按需地用于向上传播的敏感性字段。当然，切片需要一套切片标准，后面我们会提到。

ok，分类属性介绍得差不多了，但是计算机要怎么使用这个表呢？首先我们得让程序清楚检测过程，也就是将密码漏洞映射到具体的程序分析任务中去，注意：这个映射过程是手动的，且每个漏洞也只需执行一次。具体步骤让例子来说话吧：

• 第4条漏洞—— Custom Hostname verifiers to accept all hosts ，属于 API 定制不当，我们需要检验主机名是否经历过验证。
  参数验证方法一般为 javax.net.ssl.SSLSession ，实现接口为 HostnameVerifier 。
  清楚这一系列关系后，我们就可以去对程序切片了，以验证方法的 return 语句 为切片标准，进行 进程间后向切片 。
• 第5条漏洞—— Custom TrustManager to trust all certificates ，也属于 API 定制不当，我们需要检验证书是否有效。
  验证方法实现接口为 X509TrustManager 。
  我们以验证方法的 Throw 语句 或 抛出异常的类型 为切片标准，进行 进程间后向切片 。
  验证证书一般使用 checkServerTrusted ，我们要检查它是否通过 ═▶ 要检查自签名证书是否过期 ═▶ 要通过 getAcceptedIssuers 检查程序是否提供了有效的证书列表。
• 第6条漏洞—— Custom SSLSocketFactory w/o manual Hostname verification ，也属于 API 定制不当，我们需要检测是否正确使用带有正确主机名验证的SSLSocket，也就是说，不能有方法直接使用 SSLSocket 而不执行主机名验证。
  我们以验证方法的 return 语句 为切片标准，进行 进程间前向切片 。
  我们需要检查 SSLSocket 是否被 SSLSocketFactory 创建 ═▶ 验证方法 HostnameVerifier 会调用 SSLSession 参数，我们要检查这个参数是否被 SSLSocket 影响 ═▶ 验证方法 HostnameVerifier 有返回值，我们要检查这个返回值是否在条件语句中使用(如 if )。
• 第15条漏洞—— Insecure asymmetric ciphers (e.g, RSA, ECC) ，属于密码机制不够安全，我们需要检测不安全的非对称密码配置(例：1024位的RSA)，这是最复杂的一项检查。
  我们使用 前向切片 确定密钥大小是显式定义的还是默认定义的；使用 两轮后向切片 确定密钥大小的静态定义以及密钥生成算法，其中对仅数据类的敏感性字段要采用按需后向切片。
• 其他规则的映射都可以从表中推导出来。比如说，第1条和第2条中的 ↑ 表示要使用 进程间后向切片 ，↓ 表示要使用 进程间前向切片，按需要用于仅数据类的敏感性字段。

一些切片标准如下：

标准 Java API 的实现方法及其相应的切片标准(使用 进程间后向切片) ——
标准 Java API 的实现方法及其相应的切片标准(使用 进程间前向切片) ——

标准 Java API 的实现方法及其相应的切片标准(使用 进程间后向切片；粗体表示值得关注的参数) ——
有了这个表，计算机就清楚问题所在了，接下来说说切片细节以及实验难点。

视角三：细枝末节的切片技术

重新声明主题——针对大规模的 JAVA 项目，静态分析加密API漏洞。上一节我们介绍了一张漏洞描述表，根据这张表，我们就可以展开分析工作了。

可以发现作者划分了16个漏洞类别，这16类漏洞需要用不同的程序分析方法来检测，也就是说，这不是一个通用切片能解决的事情，所以，切片方式也很重要。总体来说，对一个程序进行切片分析，首先要用 def-use 属性判断是否进行切片，确定切片后，需要给定一个 切片标准 ，以此进行 后向切片 或 前向切片 。