Menu > Articles de la revue de presse : - l'ensemble [tous | francophone] - par mots clé [tous] - par site [tous] - le tagwall [voir] - Top bi-hebdo de la revue de presse [Voir]

---

S'abonner au fil RSS global de la revue de presse

---

Présentation : Security Advisory 977377 Vulnerability in TLS Could Allow Spoofing In August of 2009, researchers at PhoneFactor discovered a vulnerability in the Transport Layer Security TLS and Secure Sockets Layer SSL protocols. As the issue is present in the actual TLS SSL-standard, not only our implementation, Microsoft is working together with ICASI, the Industry Consortium for Advancement of Security on the Internet to address this vulnerability. Today, Microsoft released an advisory and an associated workaround package that experienced administrators can use to protect their web services. Explaining the risk of the security vulnerability The issue, CVE-2009-3555, allows an attacker who successfully became a man-in-the-middle to prepend information to a TLS SSL protected connection. It does not allow an attacker to read, change or edit the encrypted data. This vulnerability exists because certain SSL-protected protocols, such as HTTP, assume that information received after a TLS-renegotiation is sent by the same client as the information sent before that renegotiation. Renegotiation is a feature of the TLS protocol, described in RFC 2246 which allows either peer to renegotiate the parameters of a protected connection at any point in time. An attacker could exploit this vulnerability by intercepting a legitimate connection from a client, then initiating a renegotiation to the vulnerable server, or by piggybacking on a TLS renegotiation initiated by the web server. This vulnerability can affect different protocols that use TLS SSL, but most clearly affected is the HTTPS protocol which protects web transactions. IIS 6, IIS 7, IIS 7.5 not affected in default configuration Customers using Internet Information Services IIS 6, 7 or 7.5 are not affected in their default configuration. These versions of IIS do not support client-initiated renegotiation, and will also not perform a server-initiated renegotiation. If there is no renegotiation, the vulnerability does not exist. The only situation in which these versions of the IIS web server are affected is when the server is configured for certificate-based mutual authentication, which is not a common setting. Scope of the vulnerability in IIS 5 IIS 5 does allow clients to initiate a TLS renegotiation and is vulnerable in its default configuration. Our investigation has shown it is unlikely that these attacks will be exploited successfully. An attacker would already need to successfully leverage a man-in-the-middle attack to intercept a connection between a client and vulnerable server in order to exploit this vulnerability. Likelihood of the vulnerability being exploited in general case Eric Lawrence, a Program Manager in the Internet Explorer security team also evaluated the exploitability of the vulnerability and found the following The below is an example of an exploitation of this vulnerability. The text in red is prepended to an SSL connection by an attacker, the text in blue is sent by the unwitting victim client, and the text in green is the web server s response 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 Successfully sent 2000USD from account 12345 to account 6666. The lines highlighted in yellow represent client state or identification information by being in the same header block as the attacker s request, they effectively authorize that spliced request. There are two reasons why this attack is unlikely to be exploited If a site is vulnerable to this attack, they are almost certainly vulnerable to classic Cross Site Request Forgery style of attack. The attacker need only send the client some HTML containing an IMG SRC to the victim URL and the client will dereference that URL, automatically providing the credentials to the server. This is a simpler mechanism of accomplishing the same thing than the more complicated TLS SSL and request-splicing attack hopes to achieve. If an attacker were able to overcome the previous issue, this technique will not work for a site that only accepts parameters via HTTP POST requests. The reason is that the attacker must convey the malicious request within the POST s body. By definition, the HTTP POST body occurs after the request header block has completed. So, the malicious attack would look something like this 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 Credentials required. Because the victim s spliced request is sent after the header block, the credentials will not be used to authenticate the submitted transaction. The only way an attacker could make this work is if the server accepted what are called Trailer headers from the HTTP request, like so 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 However, it is unlikely that real-life web applications actually would accept this type of Trailer header, as it is a very little-used part of HTTP, not supported by mainstream browsers such as Internet Explorer. Workaround package available to disable TLS renegotiation While a comprehensive, multi-vendor fix is in the works, today we released a workaround package which allows system administrators to disable TLS renegotiation on their server. This package is described in KB article 977377 and disables TLS SSL renegotiation for all TLS SSL-protected protocols. We need to stress that TLS SSL renegotiation is a feature of the protocol that is used by several applications. One common example is Microsoft Exchange and ActiveSync. These applications may operate inappropriately upon installation of this workaround package. We recommend that administrators carefully test the workaround prior to deploying it on production systems. The package will protect all clients making SSL connections to the server on which it is installed. Installing it on clients will not provide any security benefit. We recommend that customers only install this workaround if they have very specific concerns regarding this vulnerability and require an ad-interim solution while Microsoft and other vendors work on a revision of the protocol. Despite the low risk of active exploitation, this vulnerability breaches a security promise made by the TLS protocol and we intend to address it comprehensively. We are working with the relevant standards body and our partners in ICASI to ensure that our fix for this issue is compatible with third party SSL TLS-enabled solutions. Thanks to Nasko Oskov from Windows Security, Eric Lawrence from Internet Explorer and Jonathan Ness from the MSRC Engineering team for their significant contributions to this blog post. -Maarten Van Horenbeeck, MSRC Program Manager Posting is provided AS IS with no warranties, and confers no rights.

Les mots clés de la revue de presse pour cet article : advisory
Les éléments de la revue Twitter pour les mots clé : advisory





Les derniers articles du site "Security Research Defense" :

- CDD.dll vulnerability Difficult to exploit
- MS10-031 VBE6 Single-Byte Stack Overwrite
- MS10-030 Malicious Mail server vulnerability
- Sharepoint XSS issue
- Registry vulnerabilities addressed by MS10-021
- MS10-020 SMB Client Update
- Assessing the risk of the April Security Bulletins
- Help keypress vulnerability in VBScript enabling Remote Code Execution
- Using code coverage to improve fuzzing results
- Details on the New TLS Advisory

---

S'abonner au fil RSS global de la revue de presse

---