mailing list archives
Re: Translate:f summary, history and thoughts > Simple perl script exploit for the problem.
From: SMILER <smiler () VXD ORG>
Date: Thu, 17 Aug 2000 15:19:01 +0100
Find in attach simple perl script that exploits bellow described problem.
smiler () vxd org
----- Original Message -----
From: "Daniel Dočekal" <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
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
and FrontPage 2000 Server extensions) is the source of Translate:f
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_
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
adding this to HTTP GET is sign for WebDAV component to really return
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
"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
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
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
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 (we do, and Svet
Namodro has released its own priority warning and we have patched our
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
Result is - many well know web sites are having security problem and
business logic including passwords to databases.
After sending many, many, mails to Microsoft (including
secure () microsoft com, Mr. Ballmer office, passing letter through support
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.
Security bulletin talking about "Translate:f" but hiding this fact from
inside you will find POSTFIX URL which is
Q256888 (now inaccessible) where original version was clearly talking
"Translate:f" (curious how it will look when it is "rewritten").
original US ENGLISH hotfix from 6th of June
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
for your kids to see how Microsoft changes history!
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).
Most important and dangerous aspect of bugs leading to source of ASP/ASA
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
of Access databases. This is how sites are hacked and private sensitive
are falling in hands of strangers.
Even after YEARS of existence of ASP files, Microsoft did nothing to
one from most dangerous aspect - that ASP/ASA files are used for storing
passwords and sensitive information.
- Re: Translate:f summary, history and thoughts > Simple perl script exploit for the problem. SMILER (Sep 19)