by au2o3t @ 360信息安全部-云安全团队(Qihoo360 Cloud Security Team)
一. 前言
最近360信息安全部的战友们够辛苦的，连夜修复漏洞，外部漏洞(ImageMagick)太凶残了，以致于连OpenSSL的洞都没有泛起多少波澜。
目前为外部企业服务的360天眼团队和360安服团队还在一线为企业救火。
回到这个OpenSSL的漏洞上，我们关注了下OpenSSL在5月份公布的 CVE-2016-2107。
然并卵，CVE-2016-2107却是个现实几乎无法利用的漏洞。
hf!
二.技术分析
攻击者需要（苛刻的）：
1、能控制受害者进行多次通信连接
2、能在受害者明文头部添加数据（加密前）
3、能修改受害者明文数据（加密前）
4、能截断和修改受害者发送的密文
5、能获得服务器返回的数据
（有这些能力直接读到明文好不好）
相关攻击测试程序截图：
服务器端 ：
服务器端(当服务器那边出：data length too long 那行就是成功测出1个字节 )
攻击原理：
openssl 开启 AES-NI 后，对 CBC 模式填充检测逻辑存在漏洞，且握手未完成时服务器报错信息以明文返回，
令攻击者可利用（根据服务器不同响应）来探测特定位置的字节。
攻击过程示例（以 AES-128-CBC 为例）：
如用户请求的秘密信息明文为“GET 360.cn/”，
那么加密包大概是这个样子（不包含SSL头）：
31 81 3b 3d e3 54 cd fc 38 53 9c a5 61 de 42 ce
6a 98 94 b0 a2 40 ff 53 54 46 6a ea 47 0d 83 31
4a 55 04 86 a6 f4 8c 40 14 a5 5e 48 70 1d bf 90
加密前：
c5 cf b7 73 7c ec c4 70 b3 ce 78 7c 25 72 aa 6a
47 45 54 20 33 36 30 2e 63 6e 2f a5 f1 dc 9e 94
26 7a da 99 b4 88 34 e8 3a b8 92 b7 55 bc 3b 00
“47 45 54 20 33 36 30 2e 63 6e 2f”即为“GET 360.cn/”
假如攻击者不能直接读取到秘密信息明文，但其可以：
令用户多次建立连接，在握手过程中，客户端完成 “ChangeCipherSpec” 后，攻击者令用户发送秘密信息。
选择此时，是因为握手尚未完成，服务器此时返回报错信息是明文形式的，攻击者可分辨。
首先，攻击者以 31 个 0x?? 相同字节覆盖加密前数据包后 31 字节：
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
47 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
不超过 256 次，当覆盖 31 个 0x47 时：
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47
47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47
收到服务器返回报错信息为“02 16”（RECORD_OVERFLOW），否则收到报错“02 14”（BAD_RECCORD_MAC），
由此可知用户的秘密信息第一个字节为 0x47 (G)。
接着，攻击者在加密前用户秘密信息前插入 15 字节任意内容，并在尾部补 1 字节任意内容。
以 32 个 0x?? 相同字节覆盖后 32字节，像这样：
4f ee df 83 37 27 59 ee 6b 30 e7 94 dd df 87 cf
xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx <– 插入 15 任意字节 47 45 54 20 33 36 30 2e 63 6e 2f a5 f1 dc 9e 94 26 7a da 99 b4 88 34 e8 3a b8 92 b7 55 bc 3b 00 xx <– 补充 1 任意字节对齐
整理下：
4f ee df 83 37 27 59 ee 6b 30 e7 94 dd df 87 cf
xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 47
45 54 20 33 36 30 2e 63 6e 2f a5 f1 dc 9e 94 26
7a da 99 b4 88 34 e8 3a b8 92 b7 55 bc 3b 00 xx
覆盖后：
4f ee df 83 37 27 59 ee 6b 30 e7 94 dd df 87 cf
xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 47
45 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
此时，要对加密后发送出的数据做截断处理，仅发送后 48 字节（当然SSL头也要修改 length 域，0x40 改为 0x30）
同样，不超过 256 次，当覆盖 ?? 值为 0x45 时，会收到报错信息为 RECORD_OVERFLOW。
由此知用户的秘密信息第二个字节为 0x45 (E)。
重复这个过程，即可解出其余秘密信息内容。
