OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq archives for 1st quarter (Jan-Mar) 1999: Index Server 2.0 and the Registry

Index Server 2.0 and the Registry

Mnemonix (mnemonixGLOBALNET.CO.UK)
Tue, 23 Mar 1999 23:40:55 -0000 

This is a multi-part message in MIME format.

------=_NextPart_000_0028_01BE7586.98B44110
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

When Microsoft's Index Server 2.0 is installed on NT 4 with Internet =
Information Server 4 it opens a new "AllowedPath" into the Windows NT =
Registry.

Administrators can control who can access the Windows NT Registry via =
the network by editing permissions on the Winreg key found under

HKLM\SYSTEM\CurrentControlSet\Control\SecurePipeServers\Winreg

By default, on NT Server 4, the permissions on this key are set to =
Administrators with Full Control. No-one else should have access =
(although it doesn't really work out like this in the end.) There are =
certain paths through the Registry that remote users, whether they are =
Administrators are not, may access. These are listed in the AllowedPaths =
subkey found under the Winreg key. These paths are to allow basic =
network operations such as printing etc to continue as normal.

Index Server 2.0 creates a new "AllowedPath":

HKLM\System\CurrentControlset\Control\ContentIndex\Catalogs

meaning that anyone with an local or domain account for that machine, =
including Guests, are able to discover the physical path to directories =
being indexed or if a directory found in a network share is being index =
they can learn the name of the machine on which the share resides and =
the name of the user account used to access that share on behalf of =
Index and Internet Information Server. Permissions on the above key and =
its sub-key give Everyone read access.

Note that regedit and regedt32 can not be used to access this =
information. Tools such as reg.exe or home-baked efforts must be used.

In most cases this issue represents a mild risk, but one worth noting =
and resolving by removing if this adversely affects you and your =
security policy.=20

Cheers,
David Litchfield
http://www.infowar.co.uk/mnemonix/



------=_NextPart_000_0028_01BE7586.98B44110
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
When Microsoft's Index Server 2.0 is = installed=20 on NT 4 with Internet Information Server 4 it opens a new=20 "AllowedPath" into the Windows NT Registry.
 
Administrators can control who can = access the=20 Windows NT Registry via the network by editing permissions on the Winreg = key=20 found under
 
HKLM\SYSTEM\CurrentControlSet\Control\SecurePipeServers\Winreg
 
By default, on NT Server 4, the permissions on this = key are=20 set to Administrators with Full Control. No-one else should have access=20 (although it doesn't really work out like this in the end.) There are = certain=20 paths through the Registry that remote users, whether they are = Administrators=20 are not, may access. These are listed in the AllowedPaths subkey found = under the=20 Winreg key. These paths are to allow basic network operations such as = printing=20 etc to continue as normal.
 
Index Server 2.0 creates a new=20 "AllowedPath":
 
HKLM\System\CurrentControlset\Control\ContentIndex\Catalogs
 
meaning that anyone with an local or domain account = for that=20 machine, including Guests, are able to discover the physical path to = directories=20 being indexed or if a directory found in a network share is being index = they can=20 learn the name of the machine on which the share resides and the name of = the=20 user account used to access that share on behalf of Index and Internet=20 Information Server. Permissions on the above key and its sub-key give = Everyone=20 read access.
 
Note that regedit and regedt32 can not be used to = access this=20 information. Tools such as reg.exe or home-baked efforts must be=20 used.
 
In most cases this issue represents = a mild risk,=20 but one worth noting and resolving by removing if this adversely affects = you and=20 your security policy.
 
Cheers,
David=20 Litchfield
http://www.infowar.co.uk/mnem= onix/
 
 
------=_NextPart_000_0028_01BE7586.98B44110--