Inktomi Traffic-Server XSS: man-in-the-middle XSS !

From: Hugo (overclocking_a_la_abuelaat_private)
Date: Wed May 14 2003 - 02:42:57 PDT

  • Next message: Shaun Moore: "PalmOS ICMP flood DoS." 

    
 ('binary' encoding is not supported, stored as-is)
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://>:443/</em>&lt;script&gt;alert()&lt;/script&gt;

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://>:443/</em>&lt;script&gt;alert()&lt;/script&gt;
<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://>:443/</em>&lt;script&gt;alert()
&lt;/script&gt;</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)

    

    



    

    


This archive was generated by hypermail 2b30 
: Wed May 14 2003 - 09:56:35 PDT