Re: Leveraging search engines against FrontPage enabled websites

[dleblanc () MINDSPRING COM (David LeBlanc)]

[NOTE - cross-posted to NTBUGTRAQ]

At 04:45 PM 4/26/98 -0700, MrJeKKyL wrote:
>        After rather quickly discovering more than a dozen websites within
less
> than half an hour using the _vti_inf.html method. I decided to see if the
> Microsoft Management Console (MMC) would provide the same results as did
> the FP Explorer. I was able to connect and view what particular services
> were being used by the MMC for a few of the websites. Thankfully, I did
> recieve "Access Denied" warnings and "Network name not found" when trying
> to view the properties for those services.
>        I'm curious if anyone else has taken this apporach. Or tried
different
> methods using the same tools. As it could lead to a serious problem. There
> are huge holes waiting to happen to people if a remote MMC can be used on a
> misconfigured FP enabled webserver.

There are a number of issues at work here -

1) As I mentioned previously, the file system permissions on a default
install are very loose (to put it mildly).  The IIS install, and the FP
install after that don't do anything to change them, instead taking what is
inherited from the file system above it.  Default permissions on anything
coming off of the root of the system drive will be everyone:RWXD, admins,
system:F.  If it is a freshly formatted drive, it will be everyone:F.
Without FP installed, this is annoying, and doesn't provide a second layer
of protection for your site, but the IIS metabase permissions sit in front
of the NTFS permissions, and it isn't a problem by itself.  With FP
installed, it makes the everyone group able to admin and author the site
(whoops).

2) MMC and a number of the newer admin tools for various NT-ish sorts of
things use DCOM, which runs across 135 UDP, and does NOT depend on 139
being accessible to function.  Also note that DCOM does NOT depend on the
right to log on from the network.  It is definately a smart thing to put
filters in front of the NT box which keep it from accepting packets to 135
(UDP and TCP).  Some of the DCOM utilities have overly broad permissions to
access the thing, but appear to be fairly reasonable about letting you
actually change important items.

Things you should do to lock things down are:

1) Set reasonable NTFS permissions on your web site.  Start with giving the
IUSR_machine account RX access (and admins/system:F) all the way up the
tree. Next go find anything you need to be writable, and allow that.  Make
sure everything still works.

2) The IUSR_machine account will install into the domain users group by
default if it is a PDC or BDC - check the groups this user (and the IWAM
user) belong to.  Make the IUSR_machine account a member of guests only,
and the IWAM user a member of guests and the MTS Trusted Impersonators.

3) It might be a fix to set the NTFS permissions on the _vti_inf.html file
to exclude the IUSR_machine account, which would make it non-readable to
anonymous users, and would keep people from being able to easily find out
whether you've got FP installed.  Note that I have NOT tested this, so if
someone with FP would please test this and let me know if it breaks, I'd
appreciate it.  Setting the AuthFlags to NT auth only on this file may also
be a good idea - my reasoning is that FP should only be used by
authenticated users other than the IUSR_machine account, and this would
accomplish that.

4) Use two network adapters - set the internet exposed adapter to only
accept TCP:80, and deny all UDP.  Set the other adapter to allow people to
admin the box as appropriate, using whatever scheme you think works
(probably very site-specific).

5) Make an authors group, and a site admins group - then set NTFS
permissions on the web site(s) to reflect that.  Try to avoid using either
the users or everyone groups.

IMHO, MS should be tweaking the NTFS settings to something more appropriate
on install and NOT leaving it to the individual admin to figure things out.
 Your average admin isn't going to know all the ins and outs, is going to
break things, then get frustrated and open things up too far - resulting in
what we're seeing.

Another note - the mere presence of the _vti_inf.html file doesn't always
indicate FP is present - this will show up on a default install of IIS
without FP being added.


David LeBlanc
dleblanc () mindspring com