|
Date:
4/8/2001
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.
Credits
Additional information
The information has been provided by Erik Power.
http://www.securiteam.com/ |