Many, many, many security holes in the Microsoft Frontpage extensions

Date: Thu, 23 Apr 1998 14:36:00 -0700
From: pedward@WEBCOM.COM
To: BUGTRAQ@NETSPACE.ORG
Subject: Re: More Microsoft debri

First of all, Frontpage is braindammaged (just have to set the stage).

Ok, Frontpage works like this when you want to publish files:

It tries to GET "http://www.yourdomain.com/_vti_inf.html".  This file
contains the version of the FP extensions and the path on the server
where the extensions are located.  When you use Frontpage to upload content,
it will try and fetch this file, if it can, it then tries to POST to
"http://www.yourdomain.com/_vti_bin/shtml.exe/_vti_rpc" (that's the default).

This server binary is not password protected, so it is able to post a query
to it.  The first thing it does is just establish a protocol rev in which the
client and server are going to talk, and what functions the server provides.

If you have any people using Frontpage, it's likely that they FTPed the
_vti_inf.html from their home machine up to your site.  Then they tried
to publish, and it tried HTTP first.  If HTTP fails, it just kicks over to
FTP as the publishing protocol (and notifies the user that they can't use
WebBots and stuff).

Incidentally, I have a passion to hate the FP extensions.  They are fundamentally
stupid in nearly all respects of implementation.

Firsly, they maintain a crapload of meta files (one shadow for every file
managed) then they have all of their config info in a bunch of text files
in the _vti_pvt directory.  (Oh, BTW, there exists a very HUGE privacy hole
in the FP extenstions).  If you go to a site that has FP extensions, just
pick any directory in the URL, yank the filename off, and put "_vti_cnf"
there instead...you'll get a complete listing of all the files in the
real directory.  With this you can snatch files that weren't meant to be
seen by the public...and it's available on ALL FP enabled sites.

Hmm, I've contributed a "privacy bug" now. :)

Want to know an even cooler hack?  Want to break into Frontpage enabled sites?

Just snarf the "administrators.pwd" and "authors.pwd" file in:

"http://www.yourdomain.com/_vti_pvt/administrators.pwd"

That'll net you the password file for the web.  Just convert it properly and run
Crack on it to obtain a useful password for defacing web sites!

Want even more???

Frontpage 98 fucks up the permissions so bad that it makes the _vti_pvt
directory WORLD WRITABLE!!! No shit, you can do whatever you want to stuff
in that directory.

Hmm, I love incompetent nitwits that think they can buy someone elses crappy
Unix shit and sell it as their own!!! :)

Oh, you know why all the directories begin with "VTI"???

"Vermeer Technology Inc". The people the M$ bought for Frontpage. :)

--Perry

>
> i work on the iis team, not fp, but i'll take a stab. the shtml.exe file is
> used by the frontpage editor when it wants to upload work from the editor to
> the server. this communication is performed using http. the same fp server
> extensions (as they are called) are used by visual interdev.
>
> the extensions are not specific to microsoft servers, they are available on
> various flavors of unix too. what's possibly happening is someone is using
> fp or vid to work on your server. if the fp extensions are not there then
> fp/vid will not be able to upload stuff to your server, but you will
> probably see a log entry like that listed below from a tool trying to test
> if the extensions are loaded on the server.
>
> the link updating theory is interesting, but i don't think that fp tries to
> call any executable to verify off-server links. but i'd need to check with
> the fp guys... let me know if you want me to persue it...
>
> cheers, mh
> mikehow@microsoft.com
> program manager
> iis security
>
>
> Looking at my Netscape error log on my web servers recently I have found
> several entries that look like this:
>
> [08/Apr/1998:08:07:07] config: for host *blah* trying to POST
> /_vti_bin/shtml.exe/_vti_rpc, handle-processed reports: no way to service
> request for /_vti_bin/shtml.exe/_vti_rpc
>
> Host name removed to protect the -apparently- innocent
>
>
> The file being posted here is the M$ control file  for servers managed by
> "FrontPage."
>
> In the beginning I thought these were all attempts to "take over" my
> server
> by placing a hacked version of the software in my server.  Since we don't
> run NT or 95, for obvious reasons, I was somewhat surprised by the
> frequency of such brain dead attacks and even more surprised that it
> might work.
>
> Recently I have learned that the M$ software itself attempts to POST to
> this file if you attempt to "verify off site links" on a server managed
> by this software.
>
> IN-other-words, every time you attempt to verify links to other servers
> on your M$ managed
> http server, that server will ASSUME that every one is a M$ managed
> server and add yet another error entry to their error file.
>
>
> I have notified M$   -as expected No response-
>
>

--
Perry Harrington        System Software Engineer    zelur xuniL  ()
http://www.webcom.com  perry.harrington@webcom.com  Think Blue.  /\
Date: Thu, 23 Apr 1998 18:35:34 -0700
From: pedward@WEBCOM.COM
To: BUGTRAQ@NETSPACE.ORG
Subject: Another Frontpage Bug, with promiscuous ScriptAliases

The Apache hack that M$ distributes allows one to create ANY directory
on a Frontpage enabled web server, and execute content in it.
This also goes for the stock Netscape Server config that M$ recommends.

Hmm, I wonder if M$ deliberately places security holes in Unix apps so
that they can claim "but Frontpage under IIS doesn't have that hole!".

Mainly because IIS loads Frontpage as a DLL (I suppose).  Frontpage
wouldn't be anywhere near the PIG it is if it ran as an Apache module
or NSAPI module...but then who has an extra 5 megs per server process
to burn???

EG:

You want a rogue program to run, and the victim has anonymous uploadable
FTP (or you sign up for a service and you want to run binaries on the
server, but can't):

mkdir _vti_bin
cd _vti_bin
put [whatever bin]

Web browser:

http://www.victim.com/somedirectorystructure/_vti_bin/trojanfile

Boom you've got stuff runnin on that server.

They configure the Netscape server the same way.

Unless you make a special NSAPI or Apache module, you're vulnerable
as a freshly born ewe of a cloned sheep named Dolly!

And why is this possible???

ScriptAlias "*/_vti_bin/*" /somedirpath

<Object ppath="*/_vti_bin/*">
...
</Object>


Solution:

Custom NSAPI / Apache module:

NameTrans fn="prefix_fpdir" prefix_path="/somedir/cgi-bin/frontpage" name="cgi"

Plus:

Custom Stub:

/somedir/cgi-bin/frontpage/cgi-wrapper [path to real binary]


--Perry

--
Perry Harrington        System Software Engineer    zelur xuniL  ()
http://www.webcom.com  perry.harrington@webcom.com  Think Blue.  /\
Date: Sun, 26 Apr 1998 14:46:32 -0400
From: frank darden <fdarden@LOCKED.COM>
To: BUGTRAQ@NETSPACE.ORG
Subject: Leveraging search engines against Frontpage enabled servers

Although this isnt really much more than a human bug, I thought I would
share the following information.

After reading some of the above posts, a friend decided to load up
FrontPage Editor, in an effort to seek out vulnerable sites. He did a
search on _vti_inf.html to get a list of some Frontpage servers on the net.
It was effective, and he found site after site that had NO password
whatsoever limiting his ability to edit the servers pages. Actually, I
havent spent much time researching FrontPage, but I can say that most
admins are incapable of setting this up properly.

Frank

http://www.locked.com
Date: Sun, 26 Apr 1998 15:55:18 -0700
From: chameleon <chameleon@PEMAIL.COM>
To: BUGTRAQ@NETSPACE.ORG
Subject: Some Past Frontpage Exploits

    [The following text is in the "iso-8859-1" character set]
    [Your display is set for the "US-ASCII" character set]
    [Some characters may be displayed incorrectly]

I've seen a few posts here recently talking about frontpage bugs and things
of the such so I thought I would share something things me and Vacuum found
6 or so months ago. Note: goto www.rhino9.org/com/net and get the new paper
by Vacuum and I on nt hacking and things of the such. NT registry is Vacuums
b!tch.


1. Frontpage extensions for un!x can lead to some bad bad problems. Around
90% of the time when your sitting on a shell of a provider that has
frontpage server extensions you can do a find / -name service.pwd -print and
then from that list grep out readable ones. Usualy as I said 90% of the
time... you will beable to have read access and sometimes write access to a
persons service.pwd.

2. Frontpage extensions for un!x..... Also more then 50% or so of the time I
have seen that if you do http://www.victim.com/_vti_pvt/service.pwd you will
beable to read the remote computer service.pwd because of bad chmod
permissions.

3. Frontpage password cracking: As Vacuum and I first discovered an
documented, frontpage server extensions use DES encryption. So basically you
can take the frontpage service.pwd (chameleon:jk53kjnb43) and then add
chameleon:jk53kjnb43:0:0:comments:/:/bin/bash and drop that into your
password cracker and boom. You get the idea. Note: A lot of times people
will use the same frontpage password as their other passwords for the un!x
shell. Thats a givin though to any hacker/cracker/security d00d :-]

4. I saw a post today I believe about someone being able to connect to a
server with frontpage server extensions and being able to alter the page
without any password. The reason you can do this is the NT everyone group.
Its very common that a server with, NT4.0 server, IIS3.0 and frontpage
server extensions installed, you can alter their webpage via frontpage
because the everyone group is on the computer and it drops you right in.
That shouldnt be too hard to understand. Note: Right after installation of
frontpage server extensions on a NT4.0 IIS3.0 box it addes the everyone
group to have access to the server via frontpage explorer etc.

5. Find File exploit used for frontpage hacking. It is possible to use the
find file exploit (http://www.victim.com/samples/search/queryhit.htm) and
search for FILENAME=*.pwd. About 20% of the time or so you will beable to
find pwd files on the remote sytem. Note: By default the find file exploit
will let you read any file in its search area with no access restrictions.

6. Something for the neato people out there to look into are the frontpage
buffer overflows. Enough said I hope.

-chameleon
Rhino9 Security Team (www.rhino9.org/com/net)
InterCore Security

"Pointless quote goes here."

"N34t0 4NS1 G03S H3R3" tee hee ;-]