| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20030514094257.28267.qmail@www.securityfocus.com> Date: 14 May 2003 09:42:57 -0000 From: Hugo "Vázquez" "Caramés" <overclocking_a_la_abuela@...mail.com> To: bugtraq@...urityfocus.com Subject: Inktomi Traffic-Server XSS: man-in-the-middle XSS ! Please we would like that credits of this vulnerability go to INFOHACKING (Hugo Vázquez Caramés and Toni Cortés Martinez). Actually we work at "Secdor R&D". The vulnerabily was found, once again, during a pen-test. ###################################################################### INKTOMI Traffic-Server XSS ###################################################################### We have just discovered a bug in a software called "Inktomi Traffic- Server", this is a proxy cache server used by Large ISPs and Backbone Providers to increase speed of web surfing. The software seems to have been adquired by WebSense,but there's not too much public info about this. We don`t know who is responsabile for this software. THE PROBLEM (Tested on Traffic-Server 5.5.1 used by Telefónica in Spain) A special request by a client passing through the Inktomi Traffic-Server causes an error page generated by the proxy. This dinamic error page is vulnerable to Cross Site Scriptting... The really important thing is that the client making the request IS UNABLE to distinguish what domain generated this code... so the XSS on this proxy makes vulnerable any client going trough it. Indirectly any server whose clients come trough the Traffic-Server and using cookies to track sessions are "vulnerable". The Inktommi's Traffic-Server is used at our country (Spain) by Telefonica, friendly known as "Timofonica", but also on many other places in the world, nowadays more and more providers are using this software. Many, many people, is affected by this problem. --How to reproduce-- With a web client: 1) First you need a client that is going through a Traffic-Server. You can check it making an http TRACE request to a server that supports this method.If you see a response like this: HTTP/1.0 200 OK Date: Wed, 14 May 2003 07:31:13 GMT Server: XXXXXX Content-Type: message/http Age: 1523 TRACE / HTTP/1.0 Client-ip: XXXXXXXXXXXX X-Forwarded-For: XXXXXXXXXXXX Connection: keep-alive Via: HTTP/1.0 proxy[AC1EF246] (Traffic-Server/5.5.1-58900 [uSc ]) Host: XXXXXXXXXXXX your http traffic is being proxyfied by a Traffic-Server. Configure this client to use a proxy* (any IP on port 80) on the other side of the Traffic-Server. *(It is not necessary that the proxy exists: the request will be grapped by the Trafiic-Server) 2) Make a request like this: http://<spoofed_domain>:443/</em><script>alert()</script> You will see the script executed on your browser! Manually: C:\>nc -v -v <spoofed_domain> 80 <spoofed_domain>: inverse host lookup failed: h_errno 11004: NO_DATA (UNKNOWN) [<spoofed_domain>] 80 (http) open GET http://<spoofed_domain>:443/</em><script>alert()</script> <HEAD><TITLE>Access Denied</TITLE></HEAD> <BODY BGCOLOR="white" FGCOLOR="black"><H1>Access Denied</H1><HR> <FONT FACE="Helvetica,Arial"><B> Description: You are not allowed to access the document at location "<em>http://<spoofed_domain>:443/</em><script>alert() </script></em>".</B></FONT> <HR> <!-- default "Access Denied" response (403) --> </BODY> sent 61, rcvd 350: NOTSOCK As you can see the error page is not generated by the final server, instead is the Traffic-Server the one who generates this error. The BIG problem here is that the client believes the response page generated comes from the <spoofed_domain>... this makes posible to exploit this flaw to steal cookies of ANY (yes any) domain... This is like a "man in the middle" attack...a new way of taking advantage of XSS... probably more devices working as "transparent" proxys will be affected in the future by similar flaws...and exposing clients and servers. The trick of the exploit is that the socket opened is on port 80 to force the proxy to capture the connection, then you have to request an URL to an open port other than 80, for example 25. If the port is open on the final server, the Traffic-Server will respond with the error page, if the port is closed, the connection will time out (so this method can also be used to port scan from a Traffic-Server). Now there's the challenge to make it work on a server with only port 80 open... Once again it seems that there's a trick to bypass this restriction: using port 443. As far we could test, for resquests on port 443, the proxy does not check if that port is opened on the final target, so the best way to exploit this is using the port 443. A screenshoot of our exploit working against Hotmail will be available at http://www.infohacking.com. This can be extented to any domain. E- commerce/Home-Banking are probably the most affected scenarios. Regards, "We would like to dedicate this research to all the people in spain that have been affected by those inconvinient devices." "Nos gustaria dedicar esta investigación a todos aquellos usuarios que se han visto afectados por los jodidos proxys de Telefónica" Hugo Vázquez Caramés & Toni Cortés Martínez INFOHACKING RESEARCH 2003 www.infohacking.com Barcelona (SPAIN) (We are working at Secdor R&D)
Powered by blists - more mailing lists