TISC Insight, Volume 2, Issue 17

Welcome to Volume 2, Issue 17 of The Internet Security Conference Newsletter, Insight. Insight provides commentaries and educational columns, authored by some of the best minds in the security community. Many of our columnists teach and speak at The Internet Security Conference.

The editorial calendar at this time includes:

• Phil Cox
• Mike Kramer
• Mandy Andress
• Bill Hancock
• Char Sample

Previous issues are posted here.

TISC is about sharing clue. So is the newsletter. We promise to provide something useful each issue. If we don't, flame me.

Enjoy, and be safe,

Dave

In this issue, Phil Cox discusses vulnerabilities in Windows 2000; specifically, Phil identifies the most attractive and likely W2K targets for attackers.

When thinking about Win2K and security, the thought of "What are the potential vulnerabilities?" always seems to come up. While Win2K has maintained the ability to exhibit all of the vulnerabilities inherent in Windows NT (i.e. it is fully backward compatible), it presents some new vulnerability areas as well. This article will look at some of the more critical areas.

A reality check: The Focal Points

First, I want to take you on a reality check. It is pretty safe to assume that the vast majority of potential attackers must rely on one or more of three factors to gain control of your Win2K systems:

• A user account that has a guessable password
• A system that is improperly configured or administered
• A published exploit for which a hotfix or administrative fix is available

Second, most administrators in the world can assume that there are very few attackers (in relative percentages) in the world that will develop a new method that will be used to specifically target and exploit their particular systems. Doing so would generally take detailed knowledge of the internal systems and often the internal business practices as well.

It turns out that even if you are vulnerable to one or more of the three problems in the list above, an attacker without some knowledge of your systems will find them difficult to exploit without detection if you are using good auditing policies and practices, or you are using a suitable intrusion detection system. This is because an attacker who has no specific knowledge of your systems will normally have to repeat an attempt many, many times. This should either generate an audit trail or set off an alert.

Now on to the show ...

With the understanding that it is mundane things like bad passwords that are mostly used to compromise systems, let's look at some of the "sexy" exploit areas the Win2K has to offer.

Active Directory

The AD is the central nervous system of a Win2K network. An attacker who wants to get the "crown jewels" will go after this. If the AD is compromised, the entire network is effectively compromised. This will be a service or primary attack focus not only because it holds valuable data, but also because a change here could potentially touch every Win2K system on the network. Some of the potential risks associated with the AD are:

• Administrators not applying adequate ACLs on AD objects, thus allowing attackers the ability to access information that they should not have access to.
• Attackers utilizing the transitive trust to gain access to a resource that was not properly secured. (Many administrators are used to Win NT trust, and will not be cognitive of the nuances in transitive trust.)
• Attackers getting access to AD information through a Win NT domain in mixed-mode operation.
• Attackers using a compromised user account to gain access to the AD and exploit improper permission settings.
• Attackers using an anonymous LDAP query to gather information.
• Attackers attempting to change Group Policies.

Microsoft Windows Installer (MSI)

Win2K integrates MSI and the AD. This integration allows users to automatically download and install applications that are not already existent on their systems. The calling program must be MSI-aware, and most Win2K applications are. A program can be automatically downloaded and installed, by creating an installation package (this is defined in the Microsoft Platform Software Development Kit). This installation package has all the information that MSI needs to install or uninstall an application or product.

The Microsoft Management Console (MMC) is a good example. If a user performs an action that requires a snap-in that is not installed, and the AD shows that there is an installation package for the snap-in, the snap-in will be downloaded automatically and installed on the user's local machine.

One of the major risks associated with MSI is the fact that IF an attacker can get privileged access to the AD (see above), they can configure it to support software distribution, then make an MSI installation package that contains a Trojan horse. From this point on, they could use Group Policy to have the package installed on systems based on user logon or system boot. This would work on any system in the domain.

Encrypting File System (EFS)

The NTFS file system supports the Encrypting File System. This encrypted file service provides protection from prying eyes, even when booted from another operating system, and the only way to compromise the system is to get a hold of the keys that were used to encrypt the information in the first place. Potential risks include:

• Corrupting the key store or EFS information on the file, as no one would be able to read the file contents after that.
• A bug in the EFS recovery agent (RA).
• Disclosure of the user password or administrative password for the system on which the files are encrypted. By default, the RA for any file on the system is the Administrator account, so anyone with the administrator (or other designated RA) access, may be able to get access to any file.

Domain Name System (DNS)

DNS replaces WINS as the primary name service and service locator in Win2K. By default, it utilizes dynamic updates of the DNS information to keep the same functionality that WINS and NetBIOS broadcasts provided in WinNT. It also uses server resource records (SRV RR) to provide service location information via DNS. Last, but certainly not least, the Active Directory is directly tied to the DNS namespace. Any one of these would make Win2K very dependent on valid DNS information, but together it makes Win2K Totally dependent on valid DNS information. Thus any compromise/corrupt/spoof information regarding DNS is potentially devastating in a Win2K network (any network for that matter). Here are some of the potential risks to the DNS data:

• Poisoning the DNS data
• Forging DNS responses
• Gathering service information via DNS
• Corrupting or forging dynamic updates

Simple Network Management Protocol (SNMP)

Not much attention is given to SNMP, but it has the potential to be a very serious security hole in your network. SNMP not only provides a way to gather detailed information about a wide variety of information on your systems, but it can also allow you to set a number of configuration options as well. Although SNMP is not new to Win2K (it was in WinNT), its use has been significantly increased, and thus becomes more of a potential issue in Win2K networks. Here are some of the potential risks associated with SNMP:

• Default community strings of "public" and "private"
• Ability to set configuration parameters
• Ability to gather detailed system (and potentially domain) information
• Ability to gather local user information

These are generic risks associated with SNMP. However, Microsoft enterprise extensions that allow SNMP access to domain information and services are a vulnerability more closely associated with W2K.

Routing and Remote Access Service

Now that the RRAS services is installed by default, and just needs to be enabled, it provides a potential path into your internal network. This can be accomplished with the routing, remote access, or VPN services. There are many ways to abuse RRAS to gain access to a network that you would not normally get access to. Here are some of those potential risks:

• Improper configuration could provide a direct "route" to your internal network.
• Unrestricted VPN allows bypass of routers.
• RRAS provides an avenue to attempt username and password attacks.
• If a connection is made, all traffic is encrypted, so the ability to perform intrusion detection on the traffic outside the Win2K machine is not possible.

SMB and CIFS (File and Printer Sharing)

The file and printer sharing system in the Win2K environment is the Server Message Block (SMB) protocol. This is implemented in two ways: first, with the Common Internet File System (CIFS), which implements the SMB protocol using TCP/IP services (such as DNS for name resolution), and second, with the NetBIOS protocol, which is supported for backward compatibility. For all intents and purposes, the two implementations have the same security risks, as the main difference is in the method used for name resolution (CIFS uses DNS, while NetBIOS uses NetBIOS names). We will be referring to both of them in their general form of SMB.

SMB is implemented as the Server and Workstation service on Win2K computers. However, SMB is generally considered a security problem if you are connected to an untrusted network. Some of the potential risks associated with the SMB are:

• Using anonymous connections to access SMB "shares" that do not have appropriate ACLs.
• Having a session "hijacked" by someone who then masquerades as the real client.
• Sniffing the data out of the SMB packets.

Certificate Services

Certificate Services are a likely target, because they potentially hold the keys to the Win2K PKI. Compromise of this service or system will mean the ability to compromise the PKI integrity. This is a big problem! Some risks associated with Certificate Services are:

• Improper configuration of the service.
• Exploit of the underlying Win2K OS.

Terminal Services

The Terminal Services package can now be installed (on Win2K server) in "administrative mode" without any licensing issues. This will make servers running the service a very likely target, because they provide the ability to get an "interactive" session on the remote machine. Since all Win2K servers come with Terminal Services, and all Win2K systems will have clients, there will be many more people wanting to use it "because it's there." Some risks associated with Terminal Services are:

• Exploit of the bugs in the Terminal Services to gain access to other users session and data.
• Improper configuration of the service, allowing compromise of the system.
• Using a valid TS client session to exploit the underlying Win2K OS and .
• Exploit of weak usernames and passwords.
• Inexperienced administrators configuring for usability and not security.

Built-in Telnet Server

All versions of Win2K now come with a Telnet server installed, but not started, by default. When it is started it requires NTLM authentication to connect (that is, no cleartext passwords). This is all well and good, but one of the main purposes of a Telnet server is to allow cross-platform access, thus you will need to enable the cleartext authentication for use by any client other than Win2K or Win NT. The risks associated with the Telnet server are:

• Cleartext authentication for a large number of clients.
• NTLM passwords can be sniffed for use in a password cracker when authenticating a Win2K or Win NT client.

Closing Thoughts ...

Although this article is not exhaustive, it does give a good sampling of the potential problems in Win2K networks. We have seen that there are numerous potential vulnerabilities in Win2K, which range from the simple (bad passwords) to the complex (exploiting Terminal Services bugs to gain access to other users sessions). It can almost seem like a daunting task to secure Win2K, but alas, don't lose hope. There really are just a few things that you can do to get you 80 percent of the way to a secure system:

• Don't use default configurations.
• Require strong passwords.
• Disable unneeded services.
• Use security options in Local or Group policies.
• Disable NTLM.
• Disable NetBIOS (native mode only).

Be systematic and diligent in what you do!