关于新TLS安全公告的详细说明 | MSRC博客

安全公告977377：TLS协议漏洞可能导致欺骗攻击

2009年8月，PhoneFactor的研究人员发现了传输层安全（TLS）和安全套接层（SSL）协议中的一个漏洞。由于该问题存在于TLS/SSL标准本身而非仅微软的实现中，微软正与互联网安全促进行业联盟（ICASI）合作解决此漏洞。今日，微软发布了安全公告及相关解决方案包，经验丰富的管理员可用其保护Web服务。

安全漏洞风险解析

漏洞CVE-2009-3555允许成功实施中间人攻击的攻击者在TLS/SSL保护连接前添加信息。该漏洞不允许攻击者读取、更改或编辑加密数据。此漏洞存在的原因是某些受SSL保护的协议（如HTTP）假设TLS重新协商后接收的信息与协商前发送的信息来自同一客户端。重新协商是TLS协议的一个功能（在RFC 2246中描述），允许任一端点随时重新协商受保护连接的参数。

攻击者可通过以下方式利用此漏洞：拦截来自客户端的合法连接，然后向易受攻击的服务器发起重新协商；或通过搭载Web服务器发起的TLS重新协商。

此漏洞可能影响使用TLS/SSL的不同协议，但最明显受影响的是保护Web交易的HTTPS协议。

IIS 6、IIS 7、IIS 7.5在默认配置下不受影响

使用Internet信息服务（IIS）6、7或7.5的客户在默认配置下不受影响。这些版本的IIS不支持客户端发起的重新协商，也不会执行服务器发起的重新协商。如果没有重新协商，漏洞就不存在。这些版本的IIS Web服务器仅在配置为基于证书的相互认证时才会受影响，这不是常见设置。

IIS 5中的漏洞范围

IIS 5确实允许客户端发起TLS重新协商，并在默认配置下易受攻击。我们的调查显示，这些攻击成功利用的可能性较低。攻击者需要成功利用中间人攻击来拦截客户端与易受攻击服务器之间的连接才能利用此漏洞。

漏洞被利用的一般可能性

Internet Explorer安全团队的项目经理Eric Lawrence也评估了该漏洞的可利用性，发现以下情况：

以下是该漏洞利用的示例。红色文本由攻击者预添加到SSL连接，蓝色文本由不知情的受害客户端发送，绿色文本是Web服务器的响应：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


GET /app/transaction.asp?action=sendMoney&srcAcctID=12345&targetAcctID=6666&amount=2000 HTTP/1.1
X-Ignore-This-Line: GET /app/updatecheck.asp HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; Trident/4.0;)
Cookie: PREF=ID=0d3e398a45b12d8a:U=ed647eec50a4edca:HSID=AOHxfGVRaYatVUIUs
Authorization: Basic c2VjcmV0OnBhc3N3b3Jk
Host: www.victim.com

HTTP/1.1 200 OK
Content-Type: text/html
Server: Microsoft-IIS/6.0
Connection: close
<html><body>Successfully sent $2000USD from account #12345 to account #6666.</body></html>

黄色高亮行代表客户端状态或标识信息；通过与攻击者请求位于同一头块中，它们有效地授权了拼接的请求。

此攻击不太可能被利用的原因有两个：

如果站点易受此攻击，几乎肯定也易受经典跨站请求伪造（CSRF）攻击。攻击者只需向客户端发送包含指向受害URL的IMG SRC的HTML，客户端将解引用该URL，自动向服务器提供凭据。这是实现相同目标的更简单机制，比复杂的TLS/SSL和请求拼接攻击更易实现。
如果攻击者能够克服前一个问题，此技术对仅通过HTTP POST请求接受参数的站点无效。原因是攻击者必须在POST主体中传递恶意请求。根据定义，HTTP POST主体在请求头块完成后发生。因此，恶意攻击可能如下所示：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


POST /app/transaction.asp HTTP/1.1
Host: www.victim.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 62

action=sendMoney&srcAcctID=12345&targetAcctID=6666&amount=2000GET /app/updatecheck.asp HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; Trident/4.0;)
Cookie: PREF=ID=0d3e398a45b12d8a:U=ed647eec50a4edca:HSID=AOHxfGVRaYatVUIUs
Authorization: Basic c2VjcmV0OnBhc3N3b3Jk
Host: www.victim.com

HTTP/1.1 400 Bad Request
Content-Type: text/html
Server: Microsoft-IIS/6.0
Connection: close
<html><body>Credentials required.</body></html>

由于受害者的拼接请求在头块之后发送，凭据将不会用于验证提交的事务。攻击者使此方法有效的唯一方式是服务器接受HTTP请求中的所谓"Trailer"头，如下所示：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


POST /app/transaction.asp HTTP/1.1
Host: www.victim.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Trailer: Authorization, Cookie, X-Ignore

3E
action=sendMoney&srcAcctID=12345&targetAcctID=6666&amount=2000
0
X-Ignore: GET /app/updatecheck.asp HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; Trident/4.0;)
Cookie: PREF=ID=0d3e398a45b12d8a:U=ed647eec50a4edca:HSID=AOHxfGVRaYatVUIUs
Authorization: Basic c2VjcmV0OnBhc3N3b3Jk
Host: www.victim.com

然而，现实中的Web应用程序不太可能接受这种类型的Trailer头，因为这是HTTP中很少使用的部分，不受Internet Explorer等主流浏览器支持。

可用的解决方案包禁用TLS重新协商

虽然全面、多供应商的修复正在进行中，今天我们发布了一个解决方案包，允许系统管理员在其服务器上禁用TLS重新协商。该包在KB文章977377中描述，并为所有TLS/SSL保护的协议禁用TLS/SSL重新协商。我们需要强调，TLS/SSL重新协商是协议的一个功能，被多个应用程序使用。一个常见示例是Microsoft Exchange和ActiveSync。这些应用程序在安装此解决方案包后可能运行不当。我们建议管理员在生产系统上部署之前仔细测试该解决方案。该包将保护所有向安装它的服务器建立SSL连接的客户端。在客户端安装不会提供任何安全好处。

我们建议客户仅在对此漏洞有非常具体的担忧，并在微软和其他供应商致力于协议修订期间需要临时解决方案时安装此解决方案包。

尽管主动利用的风险较低，但此漏洞违反了TLS协议做出的安全承诺，我们打算全面解决它。我们正与相关标准机构和ICASI的合作伙伴合作，确保我们对此问题的修复与第三方启用SSL/TLS的解决方案兼容。

感谢Windows Security的Nasko Oskov、Internet Explorer的Eric Lawrence和MSRC工程团队的Jonathan Ness对此博客文章的重要贡献。

-Maarten Van Horenbeeck，MSRC项目经理 发布内容"按原样"提供，无任何保证，也不授予任何权利。

TLS协议漏洞深度解析与微软应对措施

本文详细分析了CVE-2009-3555 TLS协议重协商漏洞的技术细节，探讨了IIS不同版本的受影响情况，提供了微软官方缓解方案，并深入评估了实际攻击场景的可行性。