Padding Oracle攻击（POODLE）技术分析

SSLv3降级加密协议Padding Oracle攻击（POODLE）技术分析 漏洞概述：

　　SSL 3.0的历史非常久远，已经有将近15年了，现今几乎所有的浏览器都支持该协议。今天该协议爆出了一个漏洞，该漏洞由谷歌公司率先发现，下面是此漏洞的大致描述。 
　　攻击者可利用该漏洞获取安全连接当中某些是SSLv3加密后的明文内容。因为兼容性问题，当浏览器进行HTTPS连接失败的时候，将会尝试使用旧的协议版本，这其中就包括SSL 3.0，于是加密协议由更加安全的协议（比如：TLS 1.0）降级成SSL 3.0。 
　　攻击者在此漏洞利用中扮演一种中间人的角色，比如A，C进行通信，B（攻击者）在中间作为一个代理，B截获A，C之间的通信后经过SSLv3加密后的数据包，利用SSLv3中存在的漏洞，解密得到其数据包的明文信息，而这些明文信息极有可能是用户的隐私数据，比如Cookie，这样攻击者就可以拿到这些隐私数据，进行更深层次的攻击。 
　　由此可见此，黑客们可以利用此漏洞。截获用户的隐私数据，进而造成了用户隐私的泄漏，危害较大，应当引起我们的高度重视，而现今唯一解决该问题的方式就是禁用SSLv3加密协议。

漏洞细节：

以下是一个会受到Padding Oracle影响的信道： 
1、A和C沟通，其中含有敏感数据使用SSLv3加密； 
2、有一个中间人B代理A和C的通信，其中A和B采用明文传输例如http协议（但A不会发送任何敏感数据到B）； 
3、B可以让A对C发出多次请求（比如通过脚本化）并且可以通过控制脚本来控制A发出的请求包的长度和敏感信息的位置（请见技术分析中阐述的一个web请求实例）； 
4、B可以截获并修改A发送到C的SSL记录（如果B本身既是代理也是A的出口网关）。目标是通过Padding Oracle攻击拿到SSLv3所加密的敏感信息的明文，下面给出一个不安全的web请求场景并对其做技术分析。

(1).场景描述：

　　假定A要访问C并且通过B，而B是一个基于JavaScript的代理请求引擎，B可以指定JavaScript的内容但B绝对不会收集任何敏感信息。但B的脚本可以让A使用SSL3.0发送多个HTTPS请求到C并且B可以截获并修改由A发送到C的SSL记录。在SSLv3工作在CBC（cipher­block chaining密文块串联）加密模式的情况下会受到Padding Oracle攻击方式的影响而还原加密包中的明文例如web cookie。

(2).技术分析：

　　为了保证数据流按加密块粒度对齐，CBC模式下的SSLv3采用末尾填充机制，填充数据长度为1到L中的任意一个值，L为块粒度，以字节为单位，一般是8或者16。在填充数据长度为L时攻击最易于实现，其中填充数据为含有L-1个字节的任意数据加上最后一个字节其值一定为L-1。处理这样一个由n+1个密文块组成的加密请求C0C1 ... Cn（其中C0是起始块）的过程是首先依据解密算法Pi = Dk(Ci) ⊕ Ci-1（Dk是使用连接key解密的函数）算出P1 ... Pn然后检测Pn末尾字节是否为L-1，然后去除该填充验证并移除MAC（Message Authentication Code信息授权码）后接受数据。 
　　问题出现在SSLv3协议只验证填充块Pn最后一个字节的值是否为填充块长度减1。在填充块大小为L时Pn[L-1]的值如果为L-1则授权通过。这为攻击者提供了一个窥探C1 ... Cn中Ci的一个明文字节即Ci[L-1]的方法那就是强行将Cn块替换为Ci然后发给目标服务器，有1/256的可能性会通过服务器的验证。只要通过服务器验证，则可以通过以下公式反推明文块中Pi[L-1]的值： 
　　Pi[L-1] = (L-1) ⊕ Cn-1[L-1] ⊕ Ci-1 
　　可以看到L和C0C1 ... Cn都为已知值。如此一来黑客通过发送大量请求（平均256*n个包）并且改变数据包数据的相对位置可以通过密文块逐字节推断出数据包中长度为n的明文，以上提到的基于JavaScript的网关可以实现上述攻击。

(3).构造一个SSLv3的web中间人攻击：

　　如果B服务器上的JavaScript可以让A发送大量带cookie的请求，例如让A去访问一个社交网站而A本身保存有那个社交网站的cookie（根据cookie机制每次请求肯定会使用同样的cookie）。通过构造大量SSLv3请求再结合截包替换SSL数据可以做到逐字节还原cookie字段，而在这种情况下cookie作为敏感信息，地位和用户名+密码是相同的。 
下面假设填充粒度为8字节，某社交网站的cookie为abcdefgh。 
　　首先JavaScript可以让用户A生成一个图中第一行所示的明文web请求包...B服务器拿到使用CBC模式下的SSLv3数据然后将最末尾块替换为左起第四个块的密文然后反复发送这个包直到解密后的Cn[7]碰巧为7（因为每次连接key都不同），收到连接成功信息。使用之前介绍的反推公式（L为8代入）可以反推出cookie字段第8字节为’h’。 
　　然后通过填充请求路径字段让A生成一个图中第二行所示的“右移1字节”的请求包...同样方法可以推算出cookie字段第7字节’g’。 
　　依此类推直到获取整个cookie值”abcdefg”。此时黑客通过中间人攻击已经获得用户cookie，用户隐私暴露无遗。

解决方案：

　　目前解决该问题可以禁用SSL3.0，或者SSL3.0中使用的CBC模式加密，但是有可能造成兼容性问题。建议支持TLS_FALLBACK_SCSV，这可以解决重试连接失败的问题，从而防止攻击者强制浏览器使用SSL3.0。 它还可以防止降级到TLS1.2至1.1或1.0，可能有助于防止未来的攻击。

(1).Apache

(2).Nginx

(3).普通用户 1.Firefox用户：

2.Chrome用户：

●编辑/usr/share/applications/google-chrome.desktop文件 
●编辑所有Exec=的行，并在后面插入--ssl-version-min=tls1比如： 
将Exec=/usr/bin/google-chrome-stable %U修改为：Exec=/usr/bin/google-chrome-stable --ssl-version-min=tls1 %U 
●最后重启您的Chrome浏览器

3.IE浏览器用户：

Internet选项->高级->使用SSL 3.0 （去除多选框） 

原文：http://cn.ui.vmall.com/thread-1345963-1-1.html

Summary:

The SSLv2 (Secure Socket Layer version 2) and/or SSLv3 service is running.

Info:

The Secure Socket Layer (SSL) protocol allows for secure communication between a client and a server. There are known flaws in the SSLv2 protocol. A man-in-the-middle attacker can force the communication to a less secure level and then attempt to break the weak encryption. The attacker can also truncate encrypted messages. An attacker can exploit this vulnerability to read secure communications or maliciously modify messages. NIST has determined SSL v3.0 is no longer acceptable for secure communications, in large part due to 2014's POODLE vulnerability. As of the date of enforcement found in PCI DSS v3.1, any version of SSL will not meet the PCI SSC's definition of "strong cryptography." See also : http://www.schneier.com/paper-ssl.pdf http://support.microsoft.com/kb/187498 http://www.linux4beginners.info/node/disable-sslv2 https://www.openssl.org/~bodo/ssl-poodle.pdf http://www.nessus.org/u?5d15ba70

General Fix:

Configure the server to disable SSLv2 and SSLv3 and enable TLS (preferably v1.2).  As usual with configuration changes, it will likely be necessary to restart the affected services once the changes are implemented. While no official tools are provided by IBM, you can use the following openssl command to verify if an SSLv2 connection is successful (change to -ssl3 for SSLv3): $ openssl s_client -connect <IP Address>:<port> -ssl2 SMTP services will need to add the relevant STARTTLS options: # openssl s_client -starttls smtp -connect <ip address>:<port> -ssl2 There are also websites that enable users to test servers on the Internet, such as http://foundeo.com/products/iis-weak-ssl-ciphers/test.cfm.  Server owners can also use ScanOnDemand. NOTE:  This finding is rarely, if ever, a false positive. IBM HTTP Server Upgrade to the latest versions of IBM HTTP Server, which disable SSLv2 and SSLv3 by default.  If by some means they are re-enabled, add the following to each server context (every instance of “SSLEnable”): SSLProtocolDisable SSLv3 SSLv2 For more information, see http://www-01.ibm.com/support/docview.wss?uid=swg21687172 Apache For Apache/mod_ssl, ensure that httpd.conf or ssl.conf has the following directive for each SSL enabled server: You can either explicitly disable both SSL versions: SSLProtocol ALL -SSLv2 -SSLv3 Or explicitly disable everything and enable TLS versions: SSLProtocol -ALL +TLSv1 (TLSv1.1 and TLSv1.2 are also options if available). The old style Apache/apache_ssl is very outdated and should no longer be in use. Apache Tomcat For Tomcat, update the server.xml configuration to use the SSLProtocol directive: sslProtocol="TLS" sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1" Websphere Edge Proxy For Websphere Edge Proxy, edit ibmproxy.conf to include the following directive: TLSOnly=On For more information, see http://www-01.ibm.com/support/docview.wss?uid=swg21693751 IBM iSeries For iSeries, configure the QSSLPCL setting as described in http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/index.jsp?topic=/rzarl/rzarlqsslpcl.htm to only use *TLSV1. Microsoft IIS For IIS, refer to the following Knowledgebase entry: Microsoft Security Advisory 3009008 Lotus Domino For Domino, refer to the following IBM reference: http://www-01.ibm.com/support/docview.wss?uid=swg21687167 ITM - Tivoli Monitoring Add the following lines to each agent configuration.  You can do it with the ITM mTEMS, Advanced, Edit Variables, or script it. GSK_PROTOCOL_SSLV2=OFF GSK_PROTOCOL_SSLV3=OFF GSK_V3_CIPHER_SPECS="350A" For more information, see http://www-01.ibm.com/support/docview.wss?uid=swg21691775 WebSEAL For WebSEAL, update the disable-ssl-v2 and disable-ssl-v3 directives in webseald.conf to "yes" instead of "no." RemotelyAnywhere Upgrade to version 11.3.2821 or later to eliminate SSLv3 usage. Note:  RemotelyAnywhere has some denial of service prevention capabilities that can be enabled/disabled.  When enabled, RemotelyAnywhere has been known to drop scanner traffic and cause false negatives, leading users to believe their findings have been resolved, only to have them appear again in a later scan. Java While the Java Control Panel general affects client-side settings, it's possible that it may also affect server instances in rare cases where the server has no fix of its own. In the Java Control Panel,  click the Advanced tab. Under Advanced Security Settings, uncheck SSL 3.0. Click Apply/Okay and restart the service.  In some cases a full reboot may be necessary. In Windows, the Java control panel can generally be found in the following locations: Windows 32-bit OS: c:\Program Files\Java\jre7\bin\javacpl.exe Windows 64-bit OS: c:\Program Files (x86)\Java\jre7\bin\javacpl.exe Other Other webservers may have different configuration methods. Summary: It is possible to obtain sensitive information from the remote host with SSL/TLS-enabled services. Info: The remote host is affected by a man-in-the-middle (MitM) information disclosure vulnerability known as POODLE. The vulnerability is due to the way SSL 3.0 handles padding bytes when decrypting messages encrypted using block ciphers in cipher block chaining (CBC) mode. A MitM attacker can decrypt a selected byte of a cipher text in as few as 256 tries if they are able to force a victim application to repeatedly send the same data over newly created SSL 3.0 connections. As long as a client and service both support SSLv3, a connection can be 'rolled back' to SSLv3, even if TLSv1 or newer is supported by the client and service. The TLS Fallback SCSV extension prevents 'version rollback' attacks without impacting legacy clients however, it can only protect connections when the client and service support the extension. Sites that cannot disable SSLv3 immediately should enable this extension. This is a vulnerability in the SSLv3 specification, not in a particular SSL implementation. Disabling SSLv3 is the only way to completely mitigate the vulnerability. See also : https://www.imperialviolet.org/2014/10/14/poodle.html https://www.openssl.org/~bodo/ssl-poodle.pdf https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00 General Fix: Disable SSLv3. Services that must support SSLv3 should enable the TLS Fallback SCSV extension until SSLv3 can be disabled. While no official tools are provided by IBM, you can use the following openssl command to verify if an SSLv3 connection is successful: $ openssl s_client -connect <IP Address>:<port> -ssl3 SMTP services will need to add the relevant STARTTLS options: # openssl s_client -starttls smtp -connect <ip address>:<port> -ssl3 Server owners can also use ScanOnDemand. IBM HTTP Server Add the following directive to the httpd.conf file to disable SSLv3 and SSLv2 for each context that contains "SSLEnable": SSLProtocolDisable SSLv3 SSLv2 Stop and restart IHS for the changes to take affect. Alternatively, SSLv3 is disabled implicitly when no SSLv3 ciphers are enabled. Use the SSLCipherSpec directive to remove any SSL ciphers: http://publib.boulder.ibm.com/httpserv/ihsdiag/ihs_performance.html#SSL Also, these directives must be placed in each SSL enabled container configuration (typically <VirtualHost *:443>). Please refer to the following list of TLS cipher configurations which are all 128-bit or greater: SSLCipherSpec TLS_RSA_WITH_AES_256_CBC_SHA SSLCipherSpec TLS_RSA_WITH_AES_128_CBC_SHA Alternative configuration using shortnames: SSLCipherSpec 35b SSLCipherSpec 2F Any SSL ciphers should be removed or commented out. For additional cipher information, visit: http://publib.boulder.ibm.com/httpserv/ihsdiag/ssl_questions.html Apache For Apache/mod_ssl, ensure that httpd.conf or ssl.conf has the following directive for each SSL enabled server: SSLProtocol -ALL +TLSv1 Alternatively: SSLProtocol ALL -SSLv2 -SSLv3 Apache Tomcat For Tomcat, update the server.xml configuration to use the SSLProtocol directive.  Currently, the only acceptable value is TLSv1. Microsoft IIS For IIS, refer to the following Knowledgebase entry: Microsoft Knowledge Base Article - 187498 Java While the Java Control Panel general affects client-side settings, it's possible that it may also affect server instances in rare cases where the server has no fix of its own. In the Java Control Panel,  click the Advanced tab. Under Advanced Security Settings, uncheck SSL 3.0. Click Apply/Okay and restart the service.  In some cases a full reboot may be necessary. In Windows, the Java control panel can generally be found in the following locations: Windows 32-bit OS: c:\Program Files\Java\jre7\bin\javacpl.exe Windows 64-bit OS: c:\Program Files (x86)\Java\jre7\bin\javacpl.exe