SecurityTracker.com
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 


Category:   Application (Generic)  >   Inktomi Traffic Server Vendors:   Inktomi
Inktomi Traffic Server Input Validation Flaw Lets Remote Users Execute Scripting Code in Arbitrary Security Domains
SecurityTracker Alert ID:  1006755
SecurityTracker URL:  http://securitytracker.com/id/1006755
CVE Reference:   CVE-2003-0292   (Links to External Site)
Updated:  Feb 28 2004
Original Entry Date:  May 14 2003
Impact:   Disclosure of authentication information, Disclosure of user information, Execution of arbitrary code via network, Modification of user information
Exploit Included:  Yes  
Version(s): 5.5.1
Description:   Hugo Vazquez Carames and Toni Cortes Martinez of INFOHACKING reported an input validation vulnerability in the Inktomi Traffic Server. A remote user can conduct cross-site scripting attacks against users on networks that have implemented the Traffic Server. Attacks can be executed against arbitrary domains.

It is reported that a remote user can create a specially crafted URL of the following form that will cause the Inktomi Traffic Server to generate an error page:

http://<spoofed_domain>:443/</em><script>alert()</script>

The error page will reportedly display the user-supplied HTML code, including any scripting code. When a target user loads the URL, the arbitrary scripting code will be executed by the target user's browser. The code will run in the context of the specified security domain ("<spoofed_domain>"). As a result, the code will be able to access the target user's cookies (including authentication cookies), if any, associated with the specified web site, access data recently submitted by the target user via web form to the site, or take actions on the site acting as the target user.

To trigger the vulnerability, the URL must open a socket on port 80 (to ensure that the connection is proxied) but then request a URL on a different port that is an open port on the destination web site. The report indicates that you can also request port 443, regardless of whether the port is open or not.

[Editor's note: Support for this Inktomi product is now provided by Satyam Computer Services, which has been contacted.]

Impact:   A remote user can access the target user's cookies (including authentication cookies), if any, associated with arbitrary web sites, access data recently submitted by the target user via web form to the sites, or take actions on the sites acting as the target user.
Solution:   No solution was available at the time of this entry.
Vendor URL:  support.inktomi.com/cns-satyam-redirect.html (Links to External Site)
Cause:   Input validation error
Underlying OS:  UNIX (Solaris - SunOS)
Underlying OS Comments:  Solaris 2.6, 7, 8

Message History:   None.


 Source Message Contents

Subject:  *



[Editor's note:  Credit for this vulnerability goes to INFOHACKING
(Hugo Vazquez Carames and Toni Cortes Martinez)]



################################################################
		                 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.


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."

INFOHACKING RESEARCH 2003
http://www.infohacking.com
Barcelona (SPAIN)
(We are working at Secdor R&D)

_________________________________________________________________
hasta 2 Mb con MSN Almacenamiento Extra. http://join.msn.com/?pgmarket=es-es



 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, SecurityGlobal.net LLC