OpenSSL CVE-2016-2107 漏洞分析

usxp9095 4年前
   <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>