[NT] Poor Security on Default Windows 2000 Server Installation Could Lead to Unauthorized Database Access
From: support@securiteam.comDate: 08/04/01
- Next message: support@securiteam.com: "[TOOL] Firewall Builder, an Object Oriented Policy Compiler"
- Previous message: support@securiteam.com: "[NEWS] Netaddress Security Issue Solved (Passwordless Logon)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: support@securiteam.com To: list@securiteam.com Subject: [NT] Poor Security on Default Windows 2000 Server Installation Could Lead to Unauthorized Database Access Message-Id: <20010804203143.6A8FD13903@mail.der-keiler.de> Date: Sat, 4 Aug 2001 22:31:43 +0200 (CEST)
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
Poor Security on Default Windows 2000 Server Installation Could Lead to
Unauthorized Database Access
------------------------------------------------------------------------
SUMMARY
A vulnerability exists in Microsoft's default security settings for ODBC
data sources. Under certain circumstances, this vulnerability could
contribute to unauthorized users gaining access to one or more databases.
For those of us that operate shared web hosting servers, this problem is
of particular importance.
DETAILS
Any user with access to the machine (e.g. a customer with FTP access to
their site content) can use standard scripting methods to enumerate the
entire list of system DSNs on the server. If any of the DSNs point to a
data source that is not secured by a user name and password, this data
source will become available to anyone with the DSN name. A good example
would be a hosting customer that does not secure their Access database
with a username and password, despite best efforts to the contrary.
Technical details:
By default, Windows 2000 stores system DSN information in two locations: a
file called ODBC.INI located in %systemroot% and in the registry under
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI. The default permissions on both
the file and in the registry have the local machine's "users" group added
with read permissions. On an IIS server, the anonymous IUSR account is a
member of the "users" group. Any user capable of uploading a script can
enumerate a list of DSNs using standard scripting methods to access either
the registry or the ODBC.INI file under the authentication of the IUSR
account. Macromedia produces a product for beginning web developers called
Dreamweaver Ultradev that does exactly this, FTPing an ASP script that
uses the file-scripting object to read the contents of the ODBC.INI file.
Solution:
Web applications making use of DSNs do so by accessing the registry - the
ODBC.INI file is not used. Removing read permissions for the "users" group
from this file has no adverse affects on web sites that use DSNs to access
various data sources. In the registry, the only locations where the
"users" group needs read permissions is on each individual sub-tree
created for each DSN. The resolution is to remove read permissions for the
"users" group on the ODBC.INI tree and add read permissions only to the
sub-trees that exist for each DSN.
The script Macromedia's product use contains comments that would indicate
that Windows NT 4.0 is also vulnerable to system DSN enumeration. For
administrators operating shared hosting web servers, it is highly
recommend that you lock down the security on both the ODBC.INI file and
associated registry settings. Microsoft has thus far been unwilling to
acknowledge this as a bona-fide security vulnerability. This problem is
not mentioned in any of Microsoft's security documentation. We think
you'll agree, however, that the anonymous IUSR account (or any standard
user account, for that matter) should NOT be allowed to obtain information
as meaningful as a complete list of system DSNs.
ADDITIONAL INFORMATION
The information has been provided by <mailto:erik@SITESPECIFIC.NET> Erik
Power.
========================================
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: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
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.
- Next message: support@securiteam.com: "[TOOL] Firewall Builder, an Object Oriented Policy Compiler"
- Previous message: support@securiteam.com: "[NEWS] Netaddress Security Issue Solved (Passwordless Logon)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
