[NT] Security considerations to keep in mind when using Site Server 3.0From: firstname.lastname@example.org
- Previous message: email@example.com: "[REVS] SQL Injection Whitepaper Released"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: firstname.lastname@example.org To: email@example.com Date: Sun, 3 Feb 2002 21:20:49 +0100 (CET)
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -
Security considerations to keep in mind when using Site Server 3.0
Multiple security vulnerabilities have been found in Microsoft's Site
Server, ranging from default password usage information leaks and
anonymous access to arbitrary file uploading. Some of the vulnerabilities
are still present current versions of Site Server version 3.0.
Site Server version 3.0 with SP3 (and prior) on NT4 SP5
Site Server version 3.0 Commerce Edition (contains some of the bugs)
Site Server version 3.0 with SP4 on NT4 SP5 (do not contain all of the
LDAP_Anonymous account w/ default password:
The installation of Site Server 3.0 includes the creation of an
LDAP_Anonymous user account, which is used by the included LDAP service.
Unfortunately, the password for this account is set to 'LdapPassword_1'.
This password is also hard coded into two system DLLs as well:
The account is added to the 'Guests' group, and is given the 'Log on
locally' privilege. Shimmer actually ran across this during his own
hack-fest. He also noted that the system appears to meticulously clean up
after this particular user account, as in, erase left over profile files
and such - basically, the system removes all traces that this user account
was used to log in.
The risks at this point are moderate: someone can use this account to log
into the machine and otherwise access system resources (but with few
actual privileges). However, we will build upon this.
This is actually a known bug to Microsoft, and is discussed in MSKB
<http://www.microsoft.com/technet/support/kb.asp?ID=248840> Q248840. It
just has not surfaced in the security community.
Systems that have (or had in the past) Site Server 3.0 installed, without
having been upgraded to Site Server SP4, will have this vulnerability.
Upgrade to Site Server SP4.
Information leakage and more via administrative pages:
There is a host of administrative pages in the /SiteServer/Admin/ virtual
directory. Normally they require a valid user login to access;
fortunately, we just so happen to know that the LDAP_Anonymous account is
available (and it works). So onto the information leaks:
This page gives a list of installed Site Server components. Fortunately,
the LDAP_Anonymous account does not have privileges to enumerate the IIS
components as well. View the source, the information is stashed in META
Displays known domains of which that server is involved. You will need IE
to run the ActiveX, or view the data passed as parameters in the HTML
Displays a list of installed ODBC drivers, which then leads to:
Displays all DSNs configured for selected ODBC driver (from driver.asp)
Create, modify, and potentially delete LDAP users and groups. Can add
arbitrary users, and put them in arbitrary groups (including Admin Group).
Note: this is separate from Windows NT user/groups, and is limited to
within the LDAP realm, and thus the online web apps.
From here, LDAP_Anonymous can view current search catalog configurations.
These all expose various LDAP service and backend configuration
The impact varies according to what information is leaked, but none of it
would likely lead to a system compromise directly.
Deny access to the /SiteServer/Admin/ directory by unauthorized sources
Information leakage via _mem_bin pages:
The Site Server installation places a few ASPs and DLLs in the _mem_bin
directory in the \wwwroot\. Two of the three DLLs require privileges not
granted by LDAP_Anonymous. The only ASP pages of interest:
Displays the default AUO (LDAP) schema, including host and port. If you
changed the port of the LDAP service, this would expose the new port.
Will give the password reminder for any user requested (but username must
be known). The password reminders are stored in the LDAP database, and
only for LDAP users, (this is unrelated to NT user accounts).
Vulnerability lies in the attacker deriving an obvious password from
password reminder clues (or, maybe users are silly enough to put their
password as their password reminder). Nevertheless, considering that the
LDAP_Anonymous user can add/modify/view user data (via the UserManager.asp
script, above), this is not anything special.
The overall impact of both of these is minimal.
You can probably live without both pages, so perhaps removing them would
Cross-site scripting in various files:
Many of the ASP pages appear vulnerable to CSS, but here are two specific
ones (URLS are wrapped):
They do require a valid login, so this greatly minimizes exploitability.
Anonymous LDAP access:
Site Server installs an LDAP service used to house user data for the local
web site subscription database. The LDAP service runs on port 1002. By
firing up an LDAP client/browser (we used Softerra's LDAP Browser 2.1),
it's possible to log in anonymously (essentially what the LDAP_Anonymous
account is meant for).
While this is read-only access, the concern is that by browsing ou=Members
(probably of the default o=Microsoft), all of the indicated members
(cn=xxx) have a plain-text 'userPassword' attribute. Thus, an anonymous
LDAP browser can access the password of every user in the LDAP database.
Do not allow access to port 1002 by anyone other than the web server(s).
User publishing of files:
Back in mid-1999 Mnemonix posted an advisory that showed how Site Server
2.0 was vulnerable to people uploading files to the /user/ virtual
directory--which was given write access by default. The problem was that
an anonymous user could use a PUT request to upload a malicious ASP file,
and then have it ran by requesting it normally.
Well, in 3.0 things were improved. The Virtual directory was moved to
/Sites/Publishing/Users/. A valid NT user account is required to upload
(more on this in a bit). While the, /Users/ directory and everything below
is given write permissions, it is not given any type of file browsing or
script permissions--so even if an attacker did upload a malicious ASP
page, it would not be run (in fact, it would come back with a
403/Forbidden error page).
So at this point, anyone with a valid user account can upload
non-executable content. Enter the LDAP_Anonymous account once again. Using
this account, it is possible to upload large files in an effort to consume
disk space, leading to a potential DoS. The virtual directory is mapped to
the Site Server install directory, which defaults to C:\Microsoft Site
Server\Sites\, so it is possible that the attack could fill the system
Remove write access from specified directories.
Content publishing (cphost.dll) issues:
Besides using a PUT command to upload a file, a remote user can use the
forms provided at /SiteServer/Publishing/ to upload a file via a HTTP POST
to /scripts/cphost.dll, which was added on installation (there are other
versions of cphost.dll as well; this one is coded to specifically jive
with Site Server's way of doing things).
The intended functionality of cphost.dll does not provide anything beyond
what was described in section [f] (above). It allows a user (with valid NT
account credentials, a la LDAP_Anonymous) to upload files to the
/Sites/Publishing/Users/... directory. The content deployment page also
refers to uploading a file to a 'Content Deployment project directory', as
well as uploading a server side component to be installed. We did not
really dig into these avenues, but we assume them to be as equally (or
more so) vulnerable as the one we are describing.
The upload form takes two parameters: the my_file parameter that contains
the file to be uploaded, and the TargetURL parameter that specifies the
final location of the uploaded file(s). The TargetURL must be in an
IIS-configured writable directory (which is separate from the NTFS write
ACLs on the filesystem). This means that cphost.dll will not place files
in anything but /Sites/Publishing/Users/. It does allow the user to make
subdirectories, and the typical place to put user 'LDAP_Anonymous' files
is /Sites/Publishing/Users/Solce/ldap_anonymous/ (keep in mind that Solce
is the name of the server). While this is the default location for user
LDAP_Anonymous's files, they can technically be put anywhere under
/Sites/Publishing/Users/. Directory browsing is not enabled, so you cannot
view files that are already uploaded (or a gain a list of usernames).
There are two bugs in cphost.dll. First, if you give cphost.dll a
TargetURL that's over around 250 characters, it will abort mid-operation.
Specifically, cphost.dll temporarily writes files (as they are being
uploaded) to a random directory in C:\temp--this location is hardcoded
into the DLL. Normally, once the files are uploaded (and thus written
out), cphost.dll will then move them to the final resting place specified
by TargetURL. However, if the TargetURL is large enough, the move
operation will fail, leaving the files forever in C:\temp taking up space.
So yes, another denial of service attack, this time it is hard coded to
the C:\ drive.
As mentioned one more bug exists in cphost.dll, and this one is more fun
(or scary, pending your point of view).
Like any good researcher, we played with using '..' types of tricks in the
TargetURL, including using Unicode and other fun stuff in order to see if
we could get cphost.dll to put files lower than the .../Users/ directory
(/Sites/Publishing/ has script execute permissions, unlike
/Sites/Publishing/Users/*). However no tricks yield anything usable with
TargetURL. So we took the "road-less-traveled".
It turns out that modifying the filename disposition parameter of the
multipart POST request is just enough to put an uploaded file one
directory higher. So by specifying a filename of '../test.asp', and a
TargetURL of '/Sites/Publishing/Users/' (which is writable and thus valid
to cphost.dll), the end result is the uploaded test.asp being placed at
/Sites/Publishing/test.asp, WHICH HAS SCRIPTING PERMISSIONS.
To exploit this you will need the capability of doing NTLM authentication
and providing an arbitrary multipart POST data body (both of which are
featured in upcoming libwhisker versions.
An example content body (with the obvious content boundary):
Content-Disposition: form-data; name="my_file"; filename="../test.asp"
Does it work?
<% Response.Write("Yes!") %>
Content-Disposition: form-data; name="TargetURL"
This resulted in the indicated file contents being saved to the URL
mentioned above, which then, when requested, would print "Yes!",
indicating it was parsed through the ASP parser. This allows arbitrary ASP
execution, which can then further be used to compromise the system, read
Disable access to cphost.dll, and probably remove the entire publishing
system in general.
Site Server 3.0, Commerce Edition:
Probable SQL tampering in sample sites:
We reviewed the sample sites found in /clocktower/, /vc30/, /mspress30/,
and /market/. Our general theory is that these were generated by the code
wizards, as none of them validates user parameters before sticking them
into SQL queries. Since Site Server required MS SQL for a backend (and MS
SQL allows the piggy-backing of SQL queries and other SQL injection
tricks), it seems possible that someone could use the samples to play
around in the DB--but they will be limited to whatever sample user context
and database that was specified during installation (which could be the
master DB under 'sa' privileges, or a special garbage DB with a user
account created just for it). We believe that the sample DSN created
during install will have more permissions than should be warranted to a
As always, remove all the sample sites, and remove the sample DSN(s)
created. You do not need sample applications on production servers.
Changes in prior bugs:
The only change after installing Commerce addition was that the following
page (which displayed installed ODBC drivers) did not function anymore:
That might be a glitch in our server configuration, but oh well.
Everything else was confirmed to still exist.
Site Server 3.0, Commerce Edition + updates:
Bye-bye to old bugs:
The password on the LDAP_Anonymous account was changed. This greatly
affects the overall exploitability of the other bugs, since a valid NT
account is required to access almost all of the web scripts. According to
MSKB <http://www.microsoft.com/technet/support/kb.asp?ID=248840> Q248840,
the LDAP_Anonymous password is a new random string generated every time
the LDAP service starts up. Looking at the code in
\winnt\system32\inetsrv\dscomobj.dll this is true, but it is done in an
odd manner. Basically a 10 character password is generated using the
SSLGenerateRandomBits() function in schannel.dll, or using rand() (seeded
with time()) if schannel.dll is not available. The 10 character password
is composed of 64 possible characters (A-Z, a-z, 0-9, _, %, and hex 0x16).
registry key is defined, then more password mangling takes place;
otherwise, the string 'Ab&1' is preened !
Now the weird part: instead of updating/replacing the old password with
the new password, the service instead deletes the LDAP_Anonymous account,
and recreates it with the new password. When deleting the account, the
service does not remove the old account SID from the list of users allowed
in the "Log on locally" privilege; after a few system reboots and service
restarts, you will have a long list of "Account Removed" entries. Also
since the SID of the account keeps changing, it's hard to maintain any
local filesystem ACLs to limit local access by the LDAP_Anonymous account,
not to mention if you audit user and group management functions, you'll be
swamped with entries detailing the deletion and addition process (over 6
entries ever time the service starts).
Of course, all of that is an inconvenience. However, there is something
interesting to note, using a null session NetBIOS query, it is possible to
get the 'password last changed' value of the LDAP_Anonymous account. Now,
systems that lack schannel.dll fall back to a rand() using srand(time()).
This means that on systems without schannel.dll, a null NetBIOS session
will indicate the approximate time the password was created, which could
then be brute-forced with feasible effort by seeding the random function
with times just prior to the indicated password creation time, and trying
the resulting password.
This vulnerability is very limited though, since it requires access to
port 139 and the absence of schannel.dll. However, it is interesting
Bugs that did not leave:
The LDAP service still allows anonymous browsing.
All of the administrative info-leaking URLs, _mem_bin scripts, and CSS
pages still work when used with a valid NT account (we do not have the
password for the LDAP_Anonymous account anymore, but normal domain
accounts will still expose the information).
The cphost.dll upload script still allows a valid NT user to upload files,
and still is vulnerable to the evil multipart request that puts ASP pages
Hello to new bugs:
Well, the new server had Site Server SP4, then NT Server SP6a, followed by
the IIS security rollup installed (in that order). According to history,
the viewcode.asp bug should have been fixed. However, we are still able to
view the source of arbitrary ASP pages (URL wrapped):
Looking at the source for viewcode.asp it appears that it is possible to
view the source of any page *except* pages in a directory named /secure/.
The script is also limited to files contained in IIS virtual directories,
it does not appear that '..' tricks will work.
So there you have it--nothing earth shattering, but enough bad stuff that
Site Server administrators should be made aware of. If you have not
installed Site Server SP4 yet, you really need to. The install order for
SS3.0 SP4 places it *before* NT SP6(a), so make sure to reapply SP6a
afterwards (and then the IIS security rollup!).
It only takes one known NT account login to exploit these bugs over port
80, so this is still a problem in internal/intranet settings. The known
password on the LDAP_Anonymous account just made it easy for a random
attacker who did not have prior knowledge of a NT user account to still
exploit the problems.
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: firstname.lastname@example.org
In order to subscribe to the mailing list, simply forward this email to: email@example.com
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.