SSL/TLS的近年相关攻击研究综述（二）
协议设计不足的漏洞 (基于CBC padding 的攻击)
作者：韦俊琳 （清华大学）
简介：
SSL/TLS在协议设计方面，存在一些弱点，可以被利用。本文综合介绍SSL/TLS使用CBC加密模式时，可能产生的攻击。 我们首先简单介绍CBC加密模式的工作原理。然后介绍基于CBC padding的相关攻击，包括Lucky Thirteen 攻击，POODLE 攻击，Bleichenbacher 攻击，和DROWN 攻击。
在SSL协议较早的版本中，大量使用CBC分组加密的模式对数据加密，如图2.1所示，加密解密过程都是分块进行。在实际应用中，当明文最后一块内容不足时，会进行填充。根据填充的内容，Serge Vaudenay在[1]中引入了padding attack，从理论上证明了利用填充内容进行攻击的可能性，阐述了在SSL/TLS、IPSEC、WTLS和SSH2中使用CBC模式具有严重的安全隐患。
图1 CBC 模式加密解密
CBC模式下，明文会被分割为固定大小的块。如果明文内容最后一块不足整块大小，根据PKCS#5 [2][3]，会在最后一块中进行填充，构成完整的块；如果刚好具有块大小，则填充一个整块。CBC模式加密通过块密钥和初始向量来加密明文块，其中明文的每个块都会和先前的密文块进行异或运算，每个字符只和每个块的对应位置相关。为了保证对同一明文加密后的密文不同，其初始向量通常是随机生成的。
进行密文解密时也是分段进行的，解密完成之后通常会检查是否符合规则，如果不符合，则会抛出Padding error异常，提示填充不正确。如果攻击者获得了合法的密文，可以通过不断的向服务器发送篡改的信息，通过观察服务器返回的信息，即可知道构造内容是否正确。如果收到错误提示信息，则再进行修改，从查询中，试探出IV的内容，然后通过中间密文逆向解析可以得到明文。当然这样做需要做大量的查询，在一般的情况下，攻击还是很难成立的。当利用填充内容的特性时，攻击就会变得高效很多。如lucky thirteen，POODLE attack 等都利用了padding内容的特性来提高攻击的效率，使攻击具有更强的实用性。
Lucky Thirteen 攻击
利用填充的不确定性，攻击者能够通过修改填充的内容来进行测试。AlFardan和Paterson在[6]公布了Lucky Thirteen攻击。在采访中，Paterson表示，攻击者作为中间人拦截TLS数据包，并对数据包进行篡改，由于传输给服务器的数据包具有特殊的排列方式，其中的一个包头域含有13字节，所以命名为“幸运 13”。
该攻击用来破解小块的CBC加密数据，这是一种针对TLS记录协议的时间侧信道攻击，要求TLS记录协议采用MEE ( MAC-Encode-Encrypt ) 方式和分组密码的CBC模式。引发攻击的最重要原因是填充，使用CBC模式，并且利用TLS完整性保护机制。攻击者可以通过修改填充字节并观察服务器做出的响应和响应时间，从而提取相关的信息，判断修改的内容是否正确。根据作者的描述，TLS协议会将错误的填充在MAC检测时当作零字节的填充，这个过程比正常协议解密的过程要短很多，产生了一个时间差。检测时这个较小时间差可以被利用，作者也用实验证明了确实能够被利用。虽然实验中会存在各种因素的偶然对准，如MAC标签的大小，密码块大小和报头字节的数量等，但是对于处理TLS记录所花费的时间上存在的时间差影响并不是很大。对于好的和坏的填充，这种差异最终将体现在错误消息出现在网络上的时间。这种利用时间的侧信道攻击在实际攻击中有广泛的应用，具有一定程度的威胁性。
作者在文中提出的解决措施是添加随机时间延迟，使用RC4，或者使用认证加密和仔细应用MEE-TLS-CBC 解密方式。在这些方法中，使用RC 4代替加密方式是不可取的，RC 4在近年来发现存在的被充分利用的严重漏洞，这种方式只会转移漏洞到RC 4 上。而增加时间延迟总体上会造成较长的延迟，而且这个延迟的影响足以抵消它所带来的好处，牺牲较高效率来换取安全的方式可能不是很好的选择，所以增加随机时间延迟的方式也是不可取的。而使用认证加密则是选择较安全的加密方式，但是认证加密只在TLS 1.2版本上有添加，对低版本的TLS协议不能有效的解决。作者重点介绍的仔细应用MEE-TLS-CBC 解密方式，核心的思想是确保一个对于MEE-TLS-CBC 密文固定大小具有相同的处理时间，把重点放在处理密文上，而不是明文部分，如块长度或者其它长度信息，修改了TLS的解密方式来移除时间侧信道的影响。
POODLE 攻击
而如果对填充内容不做限定，那么CBC模式的缺陷将被放大，利用填充的最后一个字节固定为填充长度的特性，攻击将变得更为可行。2014年10月，Google安全团队公布了POODLE(Padding Oracle On Downgrade Legacy Encryption)，这是针对SSLv3版本协议的漏洞，可以让攻击者破解小段的加密数据[4]。不同的浏览器对于SSL握手失败后采取的行为不同，服务器端在协议握手匹配失败后，会采取降级的措施。如表2-1(内容来源于《HTTPS权威指南》)所示，开始握手时服务器会选择最高的协议版本给客户端，如果握手失败，服务器会重试旧版本的协议，最后很可能被降级到SSL 3版本。而且存在类似Windows上的IE 6浏览器只支持SSL 3。攻击者也可以用这种对协议的兼容性使握手降级到SSL 3，然后进行POODLE 攻击来劫持会话。
| Browser | First Con | Second Con | Third Con | Fourth Con |
| IE6 | SSL 3 | SSL 2 | ||
| IE 7 | TLS 1.0 | SSL 3 | ||
| IE 8～10 | TLS 1.0 | SSL3 | ||
| IE 11 | TLS 1.2 | TLS 1.0 | SSL 3 | |
| Safari 7 | TLS 1.2 | TLS 1.0 | SSL 3 | |
| Firefox 27 | TLS 1.2 | TLS 1.1 | TLS 1.0 | SSL 3 |
| Chrome 33 | TLS 1.2 | TLS 1.1 | TLS 1.0 | SSL 3 |
表 2-1 浏览器自动降级
造成POODLE攻击的根本原因也是CBC模式在设计上的缺陷，CBC只对明文进行了身份验证，而没有对填充字节部分进行完整性验证。SSL 3在填充方式上是保留密文的最后一字节，填写为填充的长度。但是，规范中没有规定的填充的具体数据内容，也没有被MAC验证，所以就没有规则来确认填充的内容是否被篡改过，只能验证填充的长度是否正确。这样，SSL 3的填充就产生了严重的不安全性。
进行POODLE攻击时，攻击者能够截获密文，正常情况下，直接修改填充字节的内容的方法是不可行的，因为如果改变了MAC值时会引发错误，只有当最后整个块都是填充数据时，攻击者才能够可以进行自由的修改并且不会导致MAC校验的失败。正常情况下，攻击者尽管对密文只做了一位修改，也会导致密文解密发生大量的变化，而且解密后的内容也会变成随机内容。实际上，SSL 3在做解密校验时，只需最后的填充长度字节是正确的。在每次攻击尝试时，攻击者将需要解密的块移至最后一块，然后修改倒数第二块的最后一个字节进行查询，一直重复修改直到服务器成功接收修改后的内容。攻击的主要思路是攻击者针对较大的的URL和较小的请求体，通过缩短URL，每次一个字节，直到找到正确填充长度。通过提交足够多次的修改来破解一个字节，最后同步修改URL内容和请求体的大小并循环破解剩余部分。攻击的主要原理是数据块最后一个字节解密后的值为15（假设块大小为16）
(Ci[15]) + Cn-1[15] = 15
Pi[15] + Ci-1[15] = (Ci[15]) = 15 + Cn-1[15]
Pi[15] = 15 + Cn-1[15] + Ci-1[15]
面对这个严重的漏洞，Chrome和Firefox等浏览器都禁止回退到SSL3，IETF也出台相应的方案来应对POODLE攻击。根据标准化的防降级方法，浏览器可以采用一个特殊的信号套件 TLS_FALLBACK_SCSV[5]信号，当信号值改变时，浏览器能够通知服务器自己被降级了。这个方案不仅是为了解决SSL 3的POODLE攻击，而且是为了长期解决降级攻击问题提出的增添防降级信号。这个攻击的出现实际上大幅度推进了SSL 3的禁用，促使服务器采用更安全的协议，使用更安全的加密方式。
Bleichenbacher 攻击
当然填充的方式多种，而具有固定格式编码的PKCS也会受到填充的影响。Wagner 和 Schneier 在论文[7]中描述到，攻击者能够通过修改ClientHello信息，使SSL 3版本看起来像SSL 2版本的ClientHello信息，强制服务器使用漏洞更多的SSL 2。作为应对，便提出了把版本信息包含在PKCS编码ClientKeyExchange的PreMasterSecret 信息中，PKCS 编码格式如表2-2。
| Block Type | Padding | Separation Byte | Encapsulated Data |
| 00 02 | … | 00 | PreMasterSecret |
表2-2 PKCS#1 v1.5
但是这种编码方式具有固定的格式，可以被利用来解析数据信息内容。Daniel Bleichenbacher在[7]中提出了新的攻击(Bleichenbacher attack)。基于RSA的SSL密码套件方式，利用PKCS#1的标准格式在可接受的时间内解密预主密钥内容。预主密钥是客户端使用RSA密码套件时生成的随机值，使用服务器公钥加密后传送给服务器。服务器通过私钥解密后，能够获得一份和客户端相同的预主密钥和随机值，其前两个字节为版本号。攻击者能够窃听加密密文，应用Bleichenbacher攻击到SSL 3，通过接收服务器返回的不同错误信息来辨别修改的正确性。
Bleichenbacher攻击可以识别在0x00 02后以明文开始的密文信息，然后进行Padding Oracle攻击来解密预主密钥，进一步可以取得SSL的会话密钥。充分利用0x00 02 开头的特性，假设攻击者获得密文C0，想恢复出明文M0。攻击方法是通过向服务器多次发送修改后的密文，分析响应是正确还是错误来确定修改结果，进而解密信息。如果收到正确，则表示是0x00 02开头，那么2B < m < 3B-1，且B= 28(L-2)，而且基于RSA加密的延展性，可得 C=(C0 * Se) mod N=(M0 *S)e mod N，攻击者可用C进行查询，如果收到错误则增加S，并重复上一步骤。攻击者可以利用0x00 02大幅度减少可能的取值，2B < M0*S – rN < 3B，因此攻击者能够降低范围(2B+rN)/S < M0 < (3B+rN)/S，然后迭代选择S，进行Oracle查询，计算新的r值，攻击者便可以不断缩小包含M0的范围，不断重复直到最后只剩唯一解。
但这个攻击在被发现不久之后，研究人员便对错误信息做了统一，并且关闭了这个侧信道，使得这个攻击短期内得到了解决。针对这个改进，Klima，Pokorny和Rosa 对Bleichenbacher攻击在[8]中做了改进，他们在优化中重新定义符合PKCS 明文的可能区间值。根据SSL/TLS 规范：
- PreMasterSecret正好是46个字节
- PreMasterSecret前缀有两个版本字节
- 填充字节不等于00
- 符合明文Mi的PKCS包含将填充与有效载荷数据分开的空字节。
从而得知一些有效信息，填充内容已知，其中包含2类型字节，k-51个填充字节，单个空字节作为分隔符，2个字节的版本号和46个PreMasterSecret字节。加密内容中不仅有PreMasterSecret的值，还应该存在版本号信息，攻击者可以通过验证构造的版本号的正确性达到查询的目的。他们还进行了对之前的Bleichenbacher 攻击的防御措施进行破坏研究，如生成随机预主密钥。为应对握手信息的泄漏，设定直到对Finished消息的验证和解密发现密钥不同而中止会话。后来，Bleichenbacher 攻击又被Bardou，Focardi等人进行了改进，在[9]中提出了相应的改进方法，使得攻击执行得更快，而且大量减少查询的次数，极大的增加了攻击的效率。他们还结合他们的结果做出了分析，从结果来看是一个非常明显的改进。
为了应对Bleichenbacher 攻击，从RFC 2246（TLS 1.0）开始的所有TLS RFC建议“以与正确格式化的RSA块不可区分的方式处理错误格式化的消息”。在[10]中，作者展示了这个工作并没有成功实现，提出了四个新的Bleichenbacher侧信道和三个成功的Bleichenbacher攻击针对Java安全套接字扩展（JSSE）SSL / TLS实现和硬件安全家电使用Cavium NITROX SSL加速器芯片。作者成功验证Bleichenbacher攻击还能够成功的对SSL／TLS协议进行攻击，改善工作还需要继续。
DROWN 攻击
Bleichenbacher 攻击进一步升级，在2016年，利用PKCS#1 v1.5加密填充的遗留问题，结合SSLv2发起了对SSL／TLS近年来较为严重的一场攻击。在[11]中，DROWN(Decrypting RSA using Obsolete and Weakened eNcryption)攻击威胁到了百万级的服务器。SSLv2 虽然是退役的协议，但是还有大量的服务器支持该协议，没有完全移出废弃协议，从而导致严重的后果。利用该漏洞，观察服务器的响应来解密的RSA密文信息。并且利用这个这个漏洞，攻击者可以在没有RSA密钥私钥的情况下，可以完成跨协议的攻击，来解密SSL 3 或者更高级的TLS 会话。就算服务器本身不支持SSLv2，但是与使用SSLv2的服务器共享RSA密钥，也会受到DROWN攻击的连锁反应。
DROWN攻击区别于Bleichenbacher攻击是它利用SSLv2 解密ClientKeyExchange信息。其中要利用Bleichenbacher的方法，必须解决两个问题，首先是攻击者需要吧TLS密文转换成有效的SSLv2 密钥交换信息，才能应用Bleichenbacher 攻击，然后是Oracle查询需要严格的检测非填充部分的长度。
根据Bardou 发表的论文，Bleichenbacher 攻击需要大约百万级以上的查询次数。而DROWN攻击则利用了一些特殊的攻击技巧来优化攻击效率，使用Trimmer来剪切截获的经过RSA加密的明文信息，然后精心构造00|02|PS|00|密文消息的结构。然后利用SSL协议的出口协议来弱化会话密钥，攻击者将截断会话密钥至5字节。然后进行Oracle查询，一旦成功查询，便可以对成功篡改的密文做多次平移操作，从而对未知长明文消息做分段攻击。最后将各个小段的解密信息组合起来，构成解密明文信息。作者还对Bleichenbacher攻击做出了新的改进，他们发现该旁信道仍存在可被利用的方式，如使用同一个剪切过的RSA密文对Oracle做两次询问。若剪切正确，在Oracle的两次答复会使用正确的短会话密钥返回结果，让攻击者通过成功验证得知剪切是成功的。否则Oracle-E的两次答复会使用两个不同的随机数伪装“短会话密钥”，通过仔细验证收到的返回信息，攻击者也能得知剪切是否成功。攻击者还利用了SSLv2 协议的漏洞中的一种“高效设计”，即允许客户端通过明文指令要求服务器把高位RSA加密的密钥置零，攻击者加以利用，甚至能达到将服务器的会话密钥设置为只含有一个字节的信息量。
充分利用这些优化攻击技巧，DROWN 攻击能够通过以下方式进行：收集大量的TLS RSA 密钥交换信息，大约1000个左右就可以进行解密。把截获的含有48字节预主密钥的TLS密文截断成多个小段，然后组建成RSA PKCS#1 v1.5编码格式。构造00|02|PS|00|小段密文结构，使用改进的Bleichenbacher攻击，发起多个SSLv2 Export_40连接，并进行多次Oracle解密信息把解密的明文组建成原来的消息。
研究人员表示他们能够通过1000个记录的握手信息，40000个SSLv2连接和250次离线计算，在使用2048字节RSA密钥的服务器中，解密TLS1.2握手信息，而且如果使用共享云资源，可以在8小时内完成攻击，成本约440美元。他们还指出如果使用特殊的DROWN攻击可以降低SSLv2连接到14000个。
攻击威胁到了大量的用户，能够破解会话信息，如果被截获的信息是银行账号或者国家机密信息，危害将不可估计，攻击成本也不高，而且如果攻击对象是普通用户，解密过程将更简单，速度更快，成本将更低。DROWN攻击充分体现了使用最新协议，及时将废弃协议完全停止的重要性，也显示了密钥重用带来的重大危害，使用过时的加密协议和弱加密原语对会话造成的严重威胁。
总结
很多加密方式在最初设计的时候，并没有考虑太多的安全性问题。在实际的应用中，使用可靠加密原语和侧信道强化的算法是很有必要的。侧信道的大量信息泄漏给攻击者提供了检测的条件，使得攻击者将这些条件作为修改密文后的测试结果。而服务器端返回的错误信息提示越多，攻击者检测就越便利。减少一些非必要的返回信息在服务器端是很有必要的，而侧信道中泄漏的信息也需要尽可能的减少。SSL 虽然定义了相同的错误消息填充和解密，但是仍然不能避免时间侧信道的攻击。所以类似CBC这样的弱方案应该被重新审视，应该考虑使用更安全，更有效的加密方式。废弃的协议一定要及时完全禁用，利用老版本协议，DROWN这种大规模的攻击是具有很严重威胁性的，一些低版本的协议影响着新协议的安全性，所以推进SSL 3的完全禁用也是很有意义的。
参考文献
[ 1 ] S.Vaudenay. Security flaws induced by CBC padding, application to SSL, IPSEC, WTLS… . In EUROCRYPT, 2002
[ 2 ] B. Kaliski. PKCS #5: Password-Based Cryptography Specification Version 2.0 .
RFC 2898, Sep 2000
[ 3 ] B. Kaliski, and A. Rusch. PKCS #5: Password-Based Cryptography Specification Version 2.1. RFC 8018, Jan 2017
[ 4 ] B. Möller, T. Duong, and K. Kotowicz. This POODLE Bites: Exploiting The SSL 3.0 Fallback. Google, Sep 2014
[ 5 ] B. Moeller, A. Langley. TLS fallback signaling cipher suite value (SCSV) for preventing protocol downgrade attacks. RFC 7507, 2015
[ 6 ] N. AlFardan and K. G. Paterson. Lucky thirteen: breaking the TLS and DTLS record protocols. In IEEE, 2013
[ 7 ] D. Wagner and B. Schneier. Analysis of the SSL 3 protocol. In USENIX, 1996
[ 8 ] V. Klíma, O. Pokorný and T. Rosa2. Attacking RSA-based sessions in SSL/TLS. In CHES, 2003
[ 9 ] R. Bardou, R. Focardi, Y. Kawamoto. Efficient padding oracle attacks on cryptographic hardware. INRIA, 2012
[ 10 ] C. Meyer, J. Somorovsky, E. Weiss. Revisting SSL/TLS implementations: New Bleichenbacher side channels and attacks. In USENIX, 2014
[ 11 ] N. Aviram, S. Schinzel, J. Somorovsky. DROWN: Breaking TLS using SSLv2. USENIX, 2016
