The Accidental Hacker Exploits IIS Bugs

In July, many people reported a new bug in Internet Information Server (IIS) 3.0 and 4.0. NTFS supports multiple data streams within a file. The main data stream, which stores the main content, is called DATA. Users accessing this NTFS attribute directly from a browser might see the source code for scripts on the Web server. For example, accessing http://myserver.com/passwords.asp::$DATA can display the contents of the file, not the processed results of the file. Microsoft immediately released a patch for the bugs at ftp://ftp.microsoft.com/bussys/IIS/iis-public/fixes/usa/security/iis3-datafix and ftp://ftp.microsoft.com/bussys/IIS/iis-public/fixes/usa/security/iis4-datafix.

When I tested this bug, I found that it is very dangerous, and users everywhere need to close the hole. I've scanned a few corporate servers in Moscow, Russia (and a few in the United States and in other countries, too), and I see that most corporations still haven't installed the patch. They apparently have forgotten about Microsoft's and my recommendations. In "The Accidental Hacker" (February 1998), I told you never to put script files in a virtual directory that has read access.

When I typed the URL of a Web server in Moscow (I've changed the server names and IP addresses in this article)

http://www.somehost.ru/global.asa::$DATA

in my Web browser, I received the username and password for accessing SQL Server, as Listing 1 shows. (Heaven help the company if it runs all its scripts from the sa account, because that configuration usually would let me go anywhere in its site.)

The next hack I tried was to access SQL Server on the corporations' system. In my earlier article, I described a simple technique I used when companies had installed SQL Server on computers with NetBT enabled and I knew the username and password for accessing their site. Today, most servers on the Internet have disabled NetBT and locked down the Guest account.

If the company has disabled Guest but still has NetBT on the server, I can try to log on as Anonymous and then access SQL Server. This command does the job:

net use \\555.555.14.34\ipc$ "" /user:""

(Microsoft Support Online article Q143474--http://support.microsoft.com/support/kb/articles/q143/4/74.asp--explains this feature and how to restrict access.)

What can a hacker do if a company has closed all these avenues to access? First, I can check whether the company has installed SQL Server with TCP/IP-sockets type of client-server connection on the same computer as the Web server. To check for TCP/IP sockets, I run the SQL Server Client Configuration Utility from the Microsoft SQL Server 6.5 Program, Start menu and add new computers to the list of SQL Servers, as Screen 1 shows. The Connection String uses the format ip_address, [socket_number], where ip_address is the IP address of the computer running SQL Server and socket_number is the optional socket number that SQL Server is listening on. By default, SQL Server uses port number 1433, the official Internet Assigned Numbers Authority (IANA) socket number for SQL Server.

If I can connect to SQL Server over TCP/IP sockets, I don't need a correct domain name and password to access the database, and I can log on to the database with only a database username and password. If you want to know what I can do when I log on to SQL Server as sa, read my February article.

If I don't have the correct database username and password, I can try to use the probe login for accessing the database. The probe login is a special ID that the setup program installs. Some administrative applications (e.g., SQL Server Performance Monitor) use the probe login for connecting to a SQL Server system configured for standard security. If I can get into a system with the probe login, I can use any database that has the guest ID. If a system has integrated security, you can't use the probe login to get into SQL Server.

Protect Your Servers
To protect your server from these problems, follow these steps.

1. Install the IIS patch immediately, before somebody hacks your site.
2. Never run scripts from a virtual directory with read access enabled
3. Restrict the information available to anonymous login users, as Microsoft Online Support article Q143474 describes.
4. Protect SQL Server from access over TCP/IP sockets.
5. Disable all unneeded accounts (e.g., probe) in SQL Server and in NT.

I think I've made some headway. When I checked the sites of the friends I wrote about in my previous article, I found that they had already patched their servers.