信息泄露漏洞cve20132566原理扫描

2013年夏天，信息泄露一份安全公告让不少运维人员连夜爬起来打补丁。漏洞理扫CVE-2013-2566，信息泄露Java 7 Update 21之前的漏洞理扫版本里藏着一个要命的问题——TLS/SSL握手过程中，服务器端存在可被利用的信息泄露时序差异，攻击者能在约两万次握手内还原出明文数据。漏洞理扫这不是信息泄露理论推演，当时已经有可用的漏洞理扫概念验证工具在圈子里流传。

漏洞出在Java的信息泄露JSSE实现上。具体位置是漏洞理扫sun.security.ssl.CipherBox类，它在处理CBC模式加密的信息泄露TLS记录时，没有正确使用恒定时间算法来填充校验。漏洞理扫攻击者反复发送精心构造的信息泄露握手请求，通过测量服务器返回错误消息的漏洞理扫时间差，逐步推断出加密块中的信息泄露内容。听起来像侧信道攻击？没错，这就是典型的Padding Oracle攻击在Java TLS栈上的变体。

要理解扫描原理，得先看服务器怎么回应异常。当攻击者发送一个修改过的密文块，服务器解密后会检查填充字节是否合法。如果填充错误，立即返回alert；如果填充正确但MAC校验失败，处理路径稍微长一点。这个“稍微”在纳秒级别，但网络抓包加上统计手段，几千次采样就能把噪声压下去。扫描工具正是利用这一点，向目标端口发送畸形TLS记录，记录响应时间分布，然后逐字节爆破。

实际扫描时，你会看到类似这样的行为：工具先完成一次正常握手，拿到会话密钥和加密参数。接着构造一个包含两个加密块的记录，篡改最后一个块的填充区域。发送后等待服务器响应——如果是bad_record_mac，说明填充碰对了；如果是decryption_failed，填充错了。通过反复调整倒数第二个块的最后一个字节，攻击者能确定中间值的某个字节。这个过程每个字节平均需要128次请求，一个16字节的块大约两千次交互就能还原。

我见过一个内部渗透测试的抓包记录：目标是一台运行WebLogic的服务器，扫描脚本跑了不到四十分钟，就从一段加密的Cookie里提取出了JSESSIONID。当时运维还觉得TLS配了AES-256就高枕无忧，压根没注意Java版本停留在7u17。补丁其实早就有了——Oracle在2013年6月发布7u25，把CBC填充校验改成了恒定时间实现。但企业里升级JDK的节奏，你懂的，拖个一年半载太常见。

扫描这个漏洞不需要什么高级工具。Python写个socket脚本，配合scapy或者直接ssl模块就能干。关键点在于：

• 目标必须支持CBC模式套件（比如TLS_RSA_WITH_AES_128_CBC_SHA）
• 服务器没有启用TLS 1.1+的显式IV或者1/n-1拆分缓解措施
• 网络延迟稳定，否则时间差被抖动淹没

有些扫描器会误报。比如目标前面挂了F5负载均衡，不同后端响应时间本来就有差异，统计模型跑出来一堆假阳性。更靠谱的做法是结合版本探测——直接读服务器返回的ServerHello里有没有Java版本特征，再辅助时序验证。

修复这件事，说简单也简单。升级JDK到7u25以上，或者换用GCM模式套件。但如果你维护的是老系统，动不了代码，那就只能在网络层做文章：禁用所有CBC套件，强制RC4或者3DES——虽然也不完美，但至少堵住了这个特定攻击路径。当年AWS的ELB就干过类似的事，临时把CBC优先级降到最低。

回头看，CVE-2013-2566算不上什么惊天动地的大漏洞，CVSS评分才4.3。但它暴露了一个尴尬现实：加密库的实现细节比算法本身更容易出问题。写Java的那帮人当年大概觉得填充校验快点慢点无所谓，直到有人拿秒表把密钥量出来。现在做TLS扫描，时序侧信道已经是标配检测项了，这大概就是踩过坑之后的进步。