关于 SSL v3 中最近披露的 padding oracle 漏洞的规范问题。其他相同或显着相似的问题应作为该问题的副本关闭。
- POODLE 漏洞是什么?
- 我使用 [
product
/browser
]。我受到影响吗? - [
product
] 是否容易受到 POODLE 攻击? - 我需要做些什么来保护我的 [
product
] 免受此漏洞的影响? - 如何检测网络上的 POODLE 攻击?
- 是否有任何已知的 POODLE 攻击?
参考:
关于 SSL v3 中最近披露的 padding oracle 漏洞的规范问题。其他相同或显着相似的问题应作为该问题的副本关闭。
product
/ browser
]。我受到影响吗?product
] 是否容易受到 POODLE 攻击?product
] 免受此漏洞的影响?参考:
2014 年 10 月 14 日发布的“Poodle”漏洞是对 SSL 3.0 协议的攻击。这是一个协议缺陷,而不是实现问题;SSL 3.0 的每一个实现都会受到它的影响。请注意,我们谈论的是旧的 SSL 3.0,而不是TLS 1.0 或更高版本。TLS 版本不受影响(DTLS 也不受影响)。
简而言之:当 SSL 3.0 在 CBC 模式下使用块密码时,记录的加密过程使用填充,因此数据长度是块大小的倍数。例如,假设使用 3DES,具有 8 字节块。MAC在记录数据(以及记录序列号和一些其他头数据)上计算并附加到数据中。然后附加 1 到 8 个字节,因此总长度是 8 的倍数。此外,如果在该步骤添加n个字节,则这些字节中的最后一个必须具有值n-1。这样做是为了解密。
考虑一条记录的解密:应用 3DES-CBC 解密,然后检查最后一个字节:它应该包含一个介于 0 和 7 之间的值,这告诉我们添加了多少其他字节用于填充。这些字节被删除,而且,最重要的是,它们的内容被忽略了。这一点很重要:记录中的某些字节可以在接收者毫不在意的情况下进行更改。
Poodle 攻击在选择明文上下文中起作用,例如之前的 BEAST 和 CRIME。攻击者对受 SSL 保护的数据感兴趣,他可以:
满足此类条件的主要且几乎唯一可能的场景是 Web 上下文:攻击者运行一个虚假的 WiFi 接入点,并将其自己的一些 Javascript 作为受害者浏览的网页(HTTP,而不是 HTTPS)的一部分注入。邪恶的 Javascript 使浏览器向受害者浏览器有cookie的 HTTPS 站点(例如银行网站)发送请求。攻击者想要那个cookie。
攻击逐字节进行。攻击者的 Javascript 将请求安排为使最后一个 cookie 字节出现在加密块(3DES 的 8 字节块之一)的末尾,并且总请求长度意味着全块填充。假设最后 8 个 cookie 字节的值是c 0 , c 1 , ... c 7。加密后,CBC 的工作方式如下:
所以如果前面的加密块是e 0 , e 1 , ... e 7,那么进入 3DES 的就是c 0 XOR e 0 , c 1 XOR e 1 , ... c 7 XOR e 7。攻击者知道e i值(即加密结果)。
然后,攻击者从外部将加密记录的最后一个块替换为包含最后一个 cookie 字节的块的副本。要了解发生了什么,您必须知道 CBC 解密的工作原理:
因此,最后一个密文块被解密,产生一个以c 7 XOR e 7结尾的值. 然后将该值与前一个加密块进行异或。如果结果以值为 7 的字节结束(概率为 1/256),则填充删除步骤将删除最后 8 个字节,并以完整的明文和 MAC 结束,服务器将满足。否则,要么最后一个字节不在 0..7 范围内,服务器会报错,要么最后一个字节在 0 到 6 之间,服务器会删除错误的字节数,MAC 不会匹配,服务器会抱怨。换句话说,攻击者可以通过观察服务器的反应来知道CBC解密结果是找到了7,还是别的什么。当获得 7 时,会立即显示最后一个 cookie 字节。
当获得最后一个 cookie 字节时,使用前一个字节再次执行该过程,依此类推。
核心点是 SSL 3.0 被定义为忽略填充字节(最后一个除外)。这些字节不被 MAC 覆盖,也没有任何定义的值。
TLS 1.0 不易受到攻击,因为在 TLS 1.0 中,协议指定所有填充字节必须具有相同的值,并且实现 TLS 的库会验证这些字节是否具有预期值。因此,我们的攻击者不能以 1/256 (2 -8 ) 的概率走运,而是以 1/18446744073709551616 (2 -64 ) 的概率走运,这要糟糕得多。
[product]
. 我受到影响吗?[product]
容易受到贵宾犬攻击吗?攻击场景要求攻击者能够注入自己的数据,并拦截加密的字节。发生这种情况的唯一可能的上下文是 Web 浏览器,如上所述。在这种情况下,Poodle 就像 BEAST 和 CRIME 一样,是对客户端的攻击,而不是对服务器的攻击。
如果[product]
是 Web 浏览器,那么您可能会受到影响。但这也取决于服务器。使用的协议版本是客户端和服务器之间的协商;SSL 3.0 只有在服务器同意的情况下才会发生。因此,如果允许使用 SSL 3.0,您可能会认为您的服务器是“易受攻击的”(这在技术上是不正确的,因为攻击是 Web 上下文中的客户端,但我希望 SSL-security-meters 以这种方式工作)。
漏洞发生的条件:支持 SSL 3.0,并选择基于 CBC 的密码套件(RC4 加密没有填充,因此不易受到特定攻击 - 但 RC4 当然还有其他问题)。
解决方法:
这四种解决方案中的任何一种都可以避免该漏洞。
[product]
免受此漏洞的影响?一直如此。您的供应商发布安全修复程序;安装它们。安装补丁。所有的补丁。去做。对于贵宾犬和所有其他漏洞。你不能不安装它们,这不是新的。你应该已经这样做了。如果你不安装补丁,那么 Níðhöggr 会吞噬你的脾脏。
你没有!由于最可能的攻击设置涉及攻击者在他们的网络上引诱受害者,而不是您的网络。
尽管在服务器端,您可能希望对大量因解密错误而失败的请求做出反应。并非所有服务器软件都会记录此类情况下的事件,但这应该在任何体面的 IDS 系统的可能性范围内。
据我所知不是。事实上,当您控制受害者的所有外部 I/O 时,简单地将可怜的草皮引诱到他们银行网站的假副本上仍然要容易得多。密码攻击很简洁,但它们比利用用户轻信的无底洞需要更多的努力。
要禁用 SSL v3.0 支持:
任何一个
或者
about:config
并按[Enter]
tls
security.tls.version.min
将from的值更改0
为1
( 0
= SSL 3.0; 1
= TLS 1.0)--ssl-version-min=tls1
SSLProtocol All -SSLv2 -SSLv3
sudo apache2ctl restart
(%ZEUSHOME
通常是安装位置/usr/local/zeus
)
%ZEUSHOME%/web/global.cfg
:tuning!ssl3_allow_rehandshake never
sudo %ZEUSHOME%/restart-zeus
“对 SSLv3 的 POODLE 攻击”,ImperialViolet,ImperialViolet - 针对 SSLv3 的 POODLE 攻击
《SSLv3 POODLE漏洞正式发布》,InfoSec Handlers日记博客,>互联网风暴中心-互联网安全| SANS ISC
我发表了一篇关于如何在一些最常见的弓箭手和服务器平台中禁用 SSLv3 的博客(https://scotthelme.co.uk/sslv3-goes-to-the-dogs-poodle-kills-off-protocol/)。这至少应该有助于回答有关如何完全缓解 POODLE 的问题,无论您是客户端还是服务器。
以下是关键细节。
POODLE 最简单和最强大的解决方案是在您的服务器上禁用 SSLv3 支持。不过,这确实带来了一些警告。对于网络流量,有一些遗留系统无法连接 SSLv3 以外的任何东西。例如,使用没有 SP3 的 IE6 和 Windows XP 安装的系统将不再能够与任何放弃 SSLv3 的站点通信。根据 CloudFlare 发布的数据,他们在整个客户资产中完全禁用了 SSLv3,由于 98.88% 的 Windows XP 用户使用 TLSv1.0 或更高版本连接,因此只有一小部分 Web 流量会受到影响。
要在 Apache 服务器上禁用 SSLv3,您可以在 SSL 配置部分和所有启用 SSL 的虚拟主机中使用以下内容进行配置:
SSLProtocol All -SSLv2 -SSLv3
这将为您提供对 TLSv1.0、TLSv1.1 和 TLSv1.2 的支持,但明确删除对 SSLv2 和 SSLv3 的支持。检查配置,然后重新启动 Apache。
apachectl configtest
sudo service apache2 restart
在 NginX 上禁用 SSLv3 支持也很容易。
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
与上面的 Apache 配置类似,您将获得 TLSv1.0+ 支持并且没有 SSL。您可以检查配置并重新启动。
sudo nginx -t
sudo service nginx restart
这需要一些注册表调整和服务器重新启动,但仍然不是那么糟糕。Microsoft 有一篇包含所需信息的支持文章,但您需要做的就是修改/创建注册表 DWORD 值。
HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
在协议内部,您很可能已经拥有 SSL 2.0 密钥,因此如果需要,请在其旁边创建 SSL 3.0。在其下创建一个 Server 键,并在其中创建一个名为 Enabled 且值为 0 的 DWORD 值。完成后,重新启动服务器以使更改生效。
测试与 SSL 设置有关的任何事情的最简单且可能使用最广泛的方法是Qualys SSL 测试。只需导航到该站点,输入您要测试的网站的域,然后点击提交即可开始测试。
测试完成后,您将在页面下方获得一个很好的结果摘要和许多详细信息。具体来说,您希望在配置部分中查看您支持的协议。
您想在这里看到的是您没有支持 SSL 协议。您应该早就禁用了 SSLv2.0,现在我们也刚刚删除了 SSLv3.0。支持 TLSv1.0 或更高版本足以支持绝大多数互联网用户,而不会让任何人面临不必要的风险。
也可以通过禁用浏览器中的 SSLv3 支持来保护自己免受 POODLE 的侵害。这意味着即使服务器确实提供 SSLv3 支持,您的浏览器也永远不会使用它,即使在协议降级攻击期间也是如此。
Firefox 用户可以在地址栏中输入 about:config,然后在搜索框中输入 security.tls.version.min。这将显示需要从 0 更改为 1 的设置。现有设置允许 Firefox 在可用的地方以及需要时使用 SSLv3。通过更改设置,您将强制 Firefox 只使用 TLSv1.0 或更高版本,这不会受到 POODLE 的攻击。
Chrome 用户在 GUI 中没有禁用 SSLv3 的选项,因为 Google 删除了它,因为混淆了 SSLv3 或 TLSv1 是否具有更高的数值更好。相反,您可以添加命令行标志 --ssl-version-min=tls1 以强制使用 TLS 并阻止使用 SSL 协议的任何连接。在 Windows 中,右键单击您的 Chrome 快捷方式,点击属性并添加命令行标志,如下图所示。
如果您在 Mac、Linux、Chrome OS 或 Android 上使用 Google Chrome,您可以在此处按照这些说明进行操作。
修复 Internet Explorer 也很容易。转到设置,Internet 选项,然后单击高级选项卡。向下滚动直到您看到使用 SSL 3.0 复选框并取消选中它。
如果您想检查您的浏览器更改是否确实删除了 SSLv3.0 支持,您可以使用几个站点。如果您在浏览器中启用 SSLv3 访问https://zmap.io/sslv3/,您将在 Chrome 中看到我尚未禁用 SSLv3 的警告消息。为了仔细检查该站点是否按预期运行,我在 Internet Explorer 中禁用了 SSLv3 支持并在那里打开了该站点。在这里你可以看到不同之处。
您也可以在 Zmap 旁边尝试https://www.poodletest.com/ 。
如果您不想将您的网站名称泄露给这些其他网站,您也可以使用...进行测试
openssl s_client -ssl3 -host <your host name> -port 443
如果它没有连接,那么你就可以了。
但还要确保您的 openssl 与您的网站正常工作......
openssl s_client -host <your host name> -port 443
禁用 sslv3 也会禁用 IE6 和 Windows XP SP2 及更低版本。没有多少人拥有 IE6,但仍有很多人拥有 Windows XP。