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