COMMAND
Front Page
SYSTEMS AFFECTED
Win NT (UNIX too)
PROBLEM
Following issues are not bugs, but bad configuration. However, as
these mistakes are made often Security Bugware will address them
here.
Perry Harrington posted following. 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. And why is this
possible???
ScriptAlias "*/_vti_bin/*" /somedirpath
<Object ppath="*/_vti_bin/*">
...
</Object>
And now more about FP extensions. 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. If you go to a site that has FP extensions, you may
encounter following as result of bad configuration. 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.
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. Want
even more???
Frontpage 98 makes permissions so bad that it makes the _vti_pvt
directory WORLD WRITABLE! You can do whatever you want to stuff
in that directory.
'chameleon' from Rhino9 Security Team added following (you can
find more at www.rhino9.org/com/net).
1. Frontpage extensions for UNIX can lead to some 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 said before, 90% of the time...
you will be able to have read access and sometimes write access
to a persons service.pwd.
2. Frontpage extensions for UNIX..... Also more then 50% or so if
you do
http://www.victim.com/_vti_pvt/service.pwd
you will be able to read the remote computer service.pwd
because of bad chmod permissions. IIS 4.0 and FP98 do not use
a service.pwd file, or any .pwd files, NTFS permissions on the
.dlls themselves control access (as is pointed out in the good
reference at:
http://www.rtr.com/fpsupport/SERK/security.htm
3. Frontpage password cracking: As Vacuum and 'chameleon' 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 UNIX shell.
4. You may be 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.
This is from lameness on the part of the admin. When FP is
running on NT, you have an admin.dll and an author.dll. The
NTFS ACL on these DLLs sets who can do what. You typically
want to make an authors group, and set permissions to the DLL
for that group. If you set permissions on the DLL to give
access to everyone, then everyone is an author or an admin -
whatever. If the admin has also left the NTFS permissions on
the web site at default, you can probably use it to insert new
content, and cause various bits of mayhem. Note that these
DLLs aren't always global - there are ways to restrict certain
areas by adding more DLLs and changing their permissions. See
pg 371-372 in the IISRK for details.
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 be able 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.
SOLUTION
Note that if someone has anonymous ftp uploads setup so the upload
are readable and are inside a tree that is available from the web,
_that_ is the problem. As for bug described first, create 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]
The current FP releases (1330 and post) fix the promiscuous
permissions problems with the password files and such. The
outstanding issues are these:
_vti_pvt directory: On a misconfigured webserver, this
directory can be read via /_vti_pvt in a website. This can
still be read via an FTP client, given the default
permissions.
Fixes: * add a deny directive in the obj.conf under NS, or
use a mod_redirect or similar under Apache.
* Make sure that the permissions on the _vti_pvt
directory are somewhat sane.
There is a problem with this: shtml.exe must read the password
files as the user of the webserver. So, either you create
a wrapper which does a setuid(owner of web) before invoking
any FP extensions, or you set the permissions strictly and run
as root.
_vti_cnf directory: This is a privacy issue. If you access an
FP web with /_vti_cnf, you will get a shadow directory listing
of all the files in that current directory. It the meta info
FP keeps about every file it has under control; think of it as
a CVS directory in a checked out tree.
Fixes: * add a deny directive for */_vti_cnf/* in NS or Apache