The Accidental Hacker

This story will interest network administrators who use Windows NT Server as their platform for Internet and database processing. The events I report can happen only if staff are unprofessional and have no knowledge of security. I'm not saying that NT is not secure--I think NT is the most stable, robust, and secure operating system in the world--but organizations must have a good administrator. I hope this story shows you how to protect your site from unauthorized access.
­Andrey Kruchkov

This story began in early 1997. I was in my office in Russia, beta-testing a Windows NT Internet package for Internet Service Providers (ISPs). I didn't have time to test a component that replicates Web servers, so I decided to do a stress test by replicating a big Web server on the other side of the earth. While replicating the site, I had time to browse the original Web server. I saw that the server was completely unsecured, and the administrator had a very bad security policy.

My first look at the server showed me that the company had not installed any security patches for Internet Information Server (IIS). Contrary to Microsoft's recommendations, not only could users execute folders with Web scripts and Common Gateway Interface (CGI) programs but they also had Read access and could browse the folders' contents.

I added an extra period at the end of the universal resource locator (URL). This period lets you download Active Server Pages (ASP) files unprocessed, potentially exposing SQL Server passwords and other secure information. (This security hole is very well known; see NT News Network, Tim Daniels, "Active Server Pages Security Hole," April 1997.) When I added the period in this case, I saw the display, shown in Screen 1, in my Internet Explorer (IE) window.

Security tip:
If you follow Microsoft's recommendation and put all your Web scripts in the Internet Service Manager(ISM) folder, which has only Execute access permissions, your site will be safe, even if you have a security hole in IIS and don't have a fix for it. If you secure your scripts in this way, the intruder will see the display shown in Screen 2.

Of course, if the site administrator had spent some time checking the NT News Network in Windows NT Magazine, the administrator would have known about possible security holes and fixes available at ftp://ftp.microsoft.com. If you install this IIS patch, you'll see the screen shown in Screen 3. (The sidebar, "Stop, Thief!"--page 183--offers suggestions for protecting IIS and other components of your system.)

But the most important problem was not the IIS hole, but that I could see the default systems administrator login (sa) in Microsoft SQL Server. This administrator has no password--as anyone can see on the Web site.

Security tip:
Tell me: Who at this site let users access the database from the sa login for all scripts? Why didn't the administrator change the password immediately after installation? I hope you aren't giving a hacker such a present. If you are, stop reading now and change the sa password immediately.

I am a really good man, so I sent email to the Web master of this site. I explained briefly why his site was unsecure (this site has more than 2 million hits per day, and processes orders and accepts credit card information from customers). Here is our correspondence:

Administrator: Dear Andrey, Thanks for your comments. We are aware of the [security] problem. We installed the patch, and no one could access any of our Internet Database Connectors (IDCs). I don't think this is a potential security risk because you can't place a new .idc in our script directory.

Wow! He didn't understand what I'd written. I decided to tell him that he was wrong, and this security hole is really dangerous! I proposed a deal to him: To confirm my security analysis, I would try to hack his site.

Andrey: I hope that from now on your site is much more secure than it was in past, but I will try to break into it.

Administrator: That's a deal! We'll send you a nice package to compensate you for your work. We are not using any firewalls, so go ahead (but please be careful with our data ;-)).

Kind regards,

admin

Security tip:
Never talk to strangers. You would not believe how much useful information an unscrupulous person can gain and use from a conversation such as this one.

Finding the Holes
OK! At first, I ran a nice program called nslookup (NT Server includes nslookup for testing Domain Name System--DNS--servers). I looked at the company's DNS zone information. Figure 1, page 180, shows the servers I found.

Then, I thought, let's see which server processes email and is running the DNS service. Figure 2, page 180, shows the additional information and the mail server addresses.

What other computers are in this network? I might find something interesting there. Figure 3, page 181, shows the computers' names and their IP addresses. (The ls command is a UNIX command for List.) Not much there, but something was better than nothing.

Security tip:
You can configure DNS so that it won't show address records to strangers. Don't give anyone the right to inspect your network. Hackers usually need only a small amount of information. Don't give it to them for free.

The next step: Did he disable NetBIOS over TCP/IP (NetBT)? NetBT performs name-to-IP address mapping for name resolution. For computers connected to the Internet, Microsoft recommends disabling this service. I entered

C:\>nbtstat -A 555.555.200.1

The computer responded Host not found. I typed

C:\>nbtstat -A 555.555.200.2

The computer answered Host not found.

Hmm, was he smarter than I thought? But I needed to test all the computers in the network, not just a few servers. When I typed

C:\>nbtstat -A 555.555.200.16

C:\>nbtstat -A 555.555.200.17

Figure 4, page 181, shows what appeared on the screen. Thanks to Windows NT Magazine, I could understand what this stuff means. You can see each record's type after the computer name. The presence of a unique record for EEG1 and the __MSBROWSE__ record signifies that this server is the Primary Domain Controller (PDC) or the Backup Domain Controller (BDC). You can also see that the Administrator is logged on.

To connect to the server \\pluto, I entered

Press

Start _ Run and \\pluto.server.com

Screen 4 shows that I can connect as a guest. (In NT 4.0, I connected easily; in NT 3.51 and Windows 95, I had to add records into the LMHOSTS file.)

Next, I connected to the company's printer (everyone wants to print something to a cool color laser printer) and printed a small letter, saying that I had broken into the company's network. Funny, isn't it?

Security tip:
In any book about NT, you will read, "Disable Guest account." Moreover, NT Server disables the Guest account by default, so I don't know why this company had enabled it. Stop reading now! Look in User Manager, and disable the Guest account if it is enabled!

On another project I worked on, I found that somebody had installed Network Monitor Agent (NMA) on his computer, as Callout A in Figure 5, page 181, shows. (NMA lets a network administrator use Network Monitor to track activity on that remote client.) Do you know what the record with <BE> inside is? This is the NMA signature. If people are foolish enough to put the NMA on a computer, you can use your network sniffer in their network. Even if they use a password, you can use the tool at http://www.nmrc.org/files/nt to break in by brute force.

   Previous  [1]  2  Next