Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!


TUCoPS :: Web :: Specific Sites :: bt177.txt

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>&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://<spoofed_domain>: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://<spoofed_domain>: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)



TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2014 AOH