How People Attack Web Servers

[Previous] [Next]

The majority of attacks on Web sites aren't attacks at all—they're "scans" that probe to see what applications the site uses. Sometimes people are just being nosy and don't mean any harm. But from time to time, a scan might be a precursor to an attack. Let's take an in-depth look at how people attack servers.

Step 1: Find a Host to Attack

Most attackers choose sites with known vulnerabilities, but some attackers might choose a host at random using a host scan. A host scan is a program that "pings" a series of Internet addresses to see what's alive. The Ping command helps verify IP-level connectivity by sending a small packet of data to the host and waiting for a response; a response indicates that the host is running.

The following program, which we wrote using the Perl programming language, checks for running hosts. The program pings a series of IP addresses. If an address is up, the program performs a reverse Domain Name System (DNS) lookup to get the DNS name.

 use strict; # Similar to Visual Basic's strict option. use Socket; # Socket support. use Net::Ping; # Ping support. # A subnet to check. my $subnet = "207.46.171.*"; # Make sure subnet format is correct and parse out octets. if ($host =~ /(\d+)\.(\d+)\.(\d+)\.\*/)) { my $i; for ($i=0 ; $i < 254; $i++) { ping ($1,$2,$3,$i); } } ############################################## # Ping. # Pings the host with only 1 byte using ICMP. sub ping { my ($a, $b, $c, $d) = @_; print " Attempting to ping $name ($a.$b.$c.$d) -> "; # Replace with TCP or UDP if target drops ICMP packets. my $p = Net::Ping->new("ICMP"); my $ok = $p->ping("$a.$b.$c.$d"); $p->close(); if (!defined $ok) { print "failed (host/ip invalid)\n"; } elsif (!$ok) { print "failed (host unreachable)\n"; } else { # Attempt to resolve the IP address. my $name = gethostbyaddr(pack('C4',$a,$b,$c,$d), PF_INET); print "$name\n"; } } 

The following is an example of output from the program:

 Attempting to ping 207.46.171.194 -> failed (host/ip invalid) Attempting to ping 207.46.171.195 -> failed (host/ip invalid) Attempting to ping 207.46.171.196 -> www.exair.com Attempting to ping 207.46.171.197 -> secure.exair.com Attempting to ping 207.46.171.198 -> failed (host/ip invalid) Attempting to ping 207.46.171.199 -> failed (host/ip invalid) Attempting to ping 207.46.171.200 -> failed (host/ip invalid) 

As you can see, two hosts are running, www.exair.com and secure.exair.com. Now we can see what software they're running.

Step 2: Scan for Open Ports

Internet servers such as Web, mail, and Telnet servers listen on TCP or UDP ports. For example, by default a Web server listens on TCP port 80. Therefore, when you type http://www.microsoft.com in your Web browser, it knows to connect to TCP 80 on a server called www.microsoft.com.

NOTE

---

You can force the browser to use another port if the server is listening on another port—say, port 81. To do so, you type http://www.exair.com:81.

We know that the server at 207.46.171.196 (www.exair.com) is up, so let's perform a port scan on it. There are many ways to perform a port scan. The easiest way is to simply attempt to open the port at the server. If the port is open, a service (or a daemon, in UNIX terms) is listening.

For example, the following Perl and Microsoft Visual Basic, Scripting Edition (VBScript) code attempts to open TCP port 80 on 207.46.171.196:

Perl code:

 # Set up socket and attempt connection. socket(SERVER, PF_INET, SOCK_STREAM, getprotobyname('tcp')); my $ip = pack('C4',207,46,171,196); my $paddr = sockaddr_in(80,$ip); if (connect(SERVER,$paddr)) { print "CONNECTED."; } else { print "failed."; } close(SERVER); 

VBScript code:

 Set o = CreateObject("MSWinsock.Winsock") o.Protocol = 0 o.Connect "207.46.171.196", 80 WScript.Sleep 2000 If o.State = 9 Then WScript.Echo "failed." If o.State = 7 Then WScript.Echo "CONNECTED." o.Close 

Many tools are available for scanning a series of well-known ports to see whether they're open. The following is the output of a scan of www.exair.com at IP address 207.46.171.196.

NOTE

---

When you scan a DNS name, you might see many IP addresses. This is quite normal because it enables a simple form of load balancing called DNS-Round-Robin. For example, two physical Web servers might exist—one with an IP address of 207.46.196.4 and the other with an IP address of 207.46.196.5—and both might have the DNS name www.advworks.com. When a user types www.advworks.com in a browser, either Web server might be accessed.

 SCAN - A Simple Port Scanner v1.01.12 ([e-mail]) Attempting to ping www.exair.com using ICMP -> SUCCEEDED 21/TCP FTP at 207.46.171.196 CONNECTED. 'Microsoft FTP Service (Version 5.0).' 23/TCP TELNET at 207.46.171.196 CONNECTED. 25/TCP SMTP at 207.46.171.196 failed. 53/UDP DNS at 207.46.171.196 failed. 80/TCP HTTP at 207.46.171.196 CONNECTED. 'Microsoft-IIS/5.0' 110/TCP POP3 at 207.46.171.196 failed. 119/TCP NNTP at 207.46.171.196 failed. 135/TCP RPC-DHCPMANAGER at 207.46.171.196 failed. 137/UDP NETBIOS-NAME-SERVICE at 207.46.171.196 failed. 138/UDP NETBIOS-BROWSE at 207.46.171.196 failed. 139/TCP NETBIOS-SESSION at 207.46.171.196 failed. 389/TCP LDAP at 207.46.171.196 CONNECTED. 443/TCP HTTPS at 207.46.171.196 CONNECTED. 1433/TCP SQLSERVER at 207.46.171.196 failed. 8080/TCP SOCKS at 207.46.171.196 failed. Done... 

Now we know a great deal more about www.exair.com. We know that the following services are running:

• File Transfer Protocol Server (FTP)
• Telnet Server
• Hypertext Transfer Protocol Server (HTTP, or Web Server)
• Lightweight Directory Access Protocol (LDAP) Server
• Secure Hypertext Transfer Protocol Server (HTTPS or SSL/TLS Web Server)

You'll also notice that we know what products the FTP and Web servers are—Microsoft FTP Server 5 and Microsoft Internet Information Services (IIS) 5. We got the Web server information by issuing a GET / HTTP\1.0 request to the server and looking at the response, which includes the server type. The FTP server information was even easier to get. You just wait for the 220 status code, which includes the name of the server.

You can try this yourself without any code by using a Telnet client:

1. Type telnet www.exair.com 80 at the command line to open TCP port 80 at www.exair.com.
2. In the telnet client, type GET / HTTP\1.0 and press Return or Enter twice. You should see a message similar to this:

 GET / HTTP\1.0 HTTP/1.0 400 Bad Request Server: Microsoft-IIS/5.0 Date: Sun, 03 Sep 2000 04:53:33 GMT Content-Type: text/html Content-Length: 87 <html>.. .. .. .. </html> Connection to host lost. 

It doesn't really matter what data is returned. All you're interested in is the Web server type in the Server: header.

Once an attacker knows what ports are open and what services are running, he can start mounting an attack. For example, the attacker can easily search the Web to check for any known vulnerabilities in one of the services running on the computer and use this information to attempt an attack on the site.

A note on port-scanning strategies

By far the easiest way for a would-be assailant to scan for open ports is to use a simple TCP connect; it's also the fastest way. The good news for Web site operators is that this scanning method is the easiest to detect. Any good intrusion detection tool (covered later in this chapter) will warn you when it sees a series of sockets being opened and closed in rapid succession.

However, most attackers use other port scanning techniques that are more difficult—but not impossible—to detect. A common method is the half-open technique. To understand how this works, you need to understand how a TCP connection is made.

When a client wants to open a connection to a remote host, it constructs an IP packet that includes a flag called the SYN (synchronization) bit set to 1. The packet is then sent to the remote host. If the remote host is listening to the port specified in the IP packet, it sends a packet back to the client with both the SYN and the ACK (acknowledge) bits set to 1. Finally, the client sends another packet to the host with only the ACK flag set, and communication begins. This is often referred to as the TCP three-way handshake and is shown in Figure 12-1.

Figure 12-1. The TCP three-way handshake.

You can easily look at the TCP handshake by using a protocol analyzer such as the Microsoft Network Monitor included with Microsoft Windows 2000. Figure 122 shows part of the initial sequence when a Telnet client opens a connection to a Telnet server.

That's enough of the low-level TCP stuff for the moment. The point of all of this is that a common way to perform port scanning is to perform a SYN scan. In other words, you perform only the first part of the TCP handshake. If a SYN | ACK comes back, the server is listening on that port. The server should send back a reset (RST) if the port is not open. The SYN scan mechanism is more difficult to detect than a full connect, but most good intrusion detection tools will pick it up easily.

There are many other ways to scan for open ports. For details, see the online hacking magazine Phrack at http://phrack.infonexus.com/search.phtml?view&article=p51-11.

Figure 12-2. An initial TCP packet used to connect to a Telnet server.

Step 3: Gather Other Information

Once the attacker knows which ports are open, he might want to gather more details about the server before launching an attack. There are a few ways of gathering data (including user information and server information) about a computer running Microsoft Windows NT or Windows 2000. Most require TCP port 139 to be open. You can prevent this data gathering by shutting down the port (as described later).

Gathering user information

By default, Windows NT 3.1 and later don't require an authenticated connection to enumerate users and groups; you can use a NULL session (anonymous) connection. Therefore, it's a good idea to disable support for anonymous connections to secure computers on the Internet. (For a checklist on securing a Windows 2000 Internet server, see Appendix F, "Secure Web Server Checklist.")

Checking to See Whether Your System Allows Anonymous Connections

You can run a simple test on any server running Windows NT or Windows 2000 to see whether it supports anonymous connections. Type the following at the command prompt:

 net use \\myserver\ipc$ "" /u: "" 

You're vulnerable to anonymous information gathering if you see The Command Completed Successfully.

You can disable this support in Windows NT by taking these steps:

1. In the Regedt32 tool, open HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA.
2. Choose Add Value from the Edit menu.
3. Enter the following information in the Add Key dialog box:

Value name: RestrictAnonymous
Data type: REG_DWORD
Value: 1

4. Exit the Registry editor, and reboot your computer.

You can disable this support in Windows 2000 by taking these steps:

1. In the Local Security Policy tool (or the Domain Policy tool if you're using a domain), select Local Policies (or Domain Policies).
2. Select Security Options.
3. Double-click Additional Restrictions For Anonymous Connections, and choose No Access Without Explicit Anonymous Permissions.
4. Close the policy tool. (There's no need to reboot.)

The following sample C++ code displays a list of users on a remote computer:

 void EnumUsers(LPWSTR wszServer) { const DWORD dwLevel = 1; const DWORD MAX_ENTRIES = 100; DWORD dwIndex = 0; DWORD dwEntryCount; wprintf(L"EnumUsers on %s\n\n",wszServer); NET_API_STATUS err = ERROR_MORE_DATA; while (err == ERROR_MORE_DATA) { char *pUsers; err = NetQueryDisplayInformation( wszServer, dwLevel, dwIndex, MAX_ENTRIES, MAX_ENTRIES * 2, &dwEntryCount, (LPVOID *)&pUsers); if (err != NERR_Success && err != ERROR_MORE_DATA) Error(err); // Error function is elsewhere. for (DWORD i=0; i < dwEntryCount; i++) { NET_DISPLAY_USER *pStart = (NET_DISPLAY_USER*)pUsers; NET_DISPLAY_USER pUser = pStart[i]; wprintf(L"Name : %s\n", pUser.usri1_name); if (lstrlen(pUser.usri1_full_name)) wprintf(L" %s\n", pUser.usri1_full_name); if (lstrlen(pUser.usri1_comment)) wprintf(L" %s\n", pUser.usri1_comment); wprintf(L" RID: %d\n", pUser.usri1_user_id); if (pUser.usri1_flags & UF_ACCOUNTDISABLE) wprintf(L" Account is disabled\n"); if (pUser.usri1_flags & UF_LOCKOUT) wprintf(L" Account is locked out\n"); wprintf(L"\n"); dwIndex = pUser.usri1_next_index; } NetApiBufferFree(pUsers); } } 

Note that you must use Unicode when you compile this code using a C++ compiler because the Windows NT and Windows 2000 NetXXXXX APIs require Unicode strings.

Here's an example of output from this code:

 EnumUsers on exair Name : Administrator Built-in account for administering the computer/domain RID: 500 Name : Guest Built-in account for guest access to the computer/domain RID: 501 Account is disabled Name : exair Dummy account for development RID: 1037 Name : test RID: 1035 

Gathering server information

A tool in the Microsoft Windows 2000 Server Resource Kit called Srvinfo.exe displays information about a remote server such as disk space, services, and networking information. As you can see in the following abbreviated sample output from the tool, it can give you a great deal of information:

 Server Name: exair Security: Users NT Type: NT Member Server - Enterprise Version: 5.0 Build: 2195 Current Type: Multiprocessor Free Product Name: Microsoft Windows 2000 Registered Owner: IS Registered Organization: ExAir ProductID: 50292-170-1133541-11117a Original Install Date: Wed Feb 16 02:11:04 2000 Domain: EXAIRCORP PDC: \\EXAIRDC Hotfixes: [Q147222]: [LastRan]: Wed Feb 16 02:31:18 2000 Services: [Running] Alerter [Stopped] Application Management [Running] Computer Browser [Stopped] Indexing Service [Stopped] ClipBook [Running] Insight Host Agents [Running] Insight Server Agents [Running] Insight Storage Agents [Running] Distributed File System [Running] DHCP Client [Stopped] Logical Disk Manager Administrative Service [Running] Logical Disk Manager [Running] DNS Client [Running] Event Log [Running] COM+ Event System [Stopped] Fax Service [Stopped] IMDB Server [Stopped] Intersite Messaging [Stopped] Kerberos Key Distribution Center [Running] Server [Running] Workstation [Stopped] License Logging Service [Running] TCP/IP NetBIOS Helper Service [Running] Messenger [Stopped] NetMeeting Remote Desktop Sharing [Running] Distributed Transaction Coordinator [Stopped] Windows Installer [Stopped] Network DDE [Stopped] Network DDE DSDM 

Another useful tool is nbtstat.exe, which comes with Windows 2000. This diagnostic command displays protocol statistics and current TCP/IP connections using NBT (NetBIOS over TCP/IP). Here's some sample output from nbtstat:

 C:\>nbtstat -A 207.46.171.196 -n Node IpAddress: [207.46.171.196] Scope Id: [] NetBIOS Local Name Table Name Type Status --------------------------------------------- EXAIR <00> UNIQUE Registered EXAIR-DOM <00> GROUP Registered EXAIR <03> UNIQUE Registered EXAIR <20> UNIQUE Registered EXAIR-DOM <1E> GROUP Registered INet~Services <1C> GROUP Registered IS~EXAIR <30> UNIQUE Registered 

Using this data, you can find out a great deal about the server. The NetBIOS naming convention allows for 16 characters in a NetBIOS name. The sixteenth character is a NetBIOS suffix, which identifies functionality installed on the registered device. Table 12-1 lists the NetBIOS suffixes used by Windows NT and Windows 2000. They're listed in hexadecimal format because many of them are unprintable otherwise.

Table 12-1. NetBIOS suffixes.

NetBIOS Name	Suffix (Hex Format)	Type	Service
<computername>	00	U	Workstation Service
<computername>	01	U	Messenger Service
<__MSBROWSE__>	01	G	Master Browser
<computername>	03	U	Messenger Service
<computername>	06	U	RAS Server Service
<computername>	1F	U	NetDDE Service
<computername>	20	U	File Server Service
<computername>	21	U	RAS Client Service
<computername>	22	U	Microsoft Exchange Interchange
<computername>	23	U	Microsoft Exchange Store
<computername>	24	U	Microsoft Exchange Directory
<computername>	30	U	Modem Sharing Server Service
<computername>	31	U	Modem Sharing Client Service
<computername>	43	U	SMS Clients Remote Control
<computername>	44	U	SMS Remote Control Tool
<computername>	45	U	SMS Clients Remote Chat
<computername>	46	U	SMS Clients Remote Transfer
<computername>	4C	U	DEC Pathworks TCPIP
<computername>	52	U	DEC Pathworks TCPIP
<computername>	87	U	Microsoft Exchange MTA
<computername>	6A	U	Microsoft Exchange IMC
<computername>	BE	U	Network Monitor Agent
<computername>	BF	U	Network Monitor Application
<username>	03	U	Messenger Service
<domain>	00	G	Domain Name
<domain>	1B	U	Domain Master Browser
<domain>	1C	G	Domain Controllers
<domain>	1D	U	Master Browser
<domain>	1E	G	Browser Service Elections
<INet~Services>	1C	G	IIS
<IS~computer name>	00	U	IIS
<computername>	2B	U	Lotus Notes Server Service
IRISMULTICAST	2F	G	Lotus Notes
IRISNAMESERVER	33	G	Lotus Notes

Using this table, you can see that the server being probed has the following functionality:

• It's running the Workstation Service (<00> Unique)
• It's running in the EXAIR-DOM domain (<00> Group)
• It's running the Messenger Service (<03> Unique)
• It's running the File Server Service (<20> Unique)
• It's a domain controller in the EXAIR-DOM (<1E> Group)
• It's running IIS (<1C> and <30>)

NetBIOS name types describe the functionality of the registration, as shown in Table 12-2.

Table 12-2. NetBIOS name types.

NetBIOS Name Type	Comments
Unique (U)	The name might have only one IP address assigned to it. On a network device, multiple occurrences of a single name might appear to be registered. The suffix might be the only unique character in the name.
Group (G)	A normal group. The name is unique but might exist with many IP addresses. Windows Internet Naming Service (WINS) responds to a name query on a group name with the limited broadcast address (255.255.255.255).
Multihomed (M)	The name is unique, but due to multiple network interfaces on the same computer, this configuration is necessary to permit the registration. The maximum number of addresses is 25.

While nbtstat can supply a great deal of information about a server, other tools can probe for vulnerabilities and gather additional data:

• Legion (rhino9.ml.org), which scans multiple machines for unprotected shares on a computer running Windows.
• DumpAcl (www.somarsoft.com), which displays a remote computer's user, group, and permissions information.
• L0phtcrack (note the zero) (www.l0pht.com), which attempts to guess passwords for Windows user accounts.
• NetCat (www.l0pht.com), an all-around useful IP tool.
• Teleport (www.tenmax.com), which queries a Web site looking for key words. This tool can also copy a Web site or portions of a site to your computer.
• Grinder (hackersclub.com), which quickly scans a series of IP addresses to look for Web server version information.
• Whois database (Web interface at www.networksolutions.com/cgi-bin/whois/whois, Whois client [WS_Ping ProPack] at www.ipswitch.com, and Geektools at www.geektools.com/cgi-bin/proxy.cgi), which can obtain a great deal of information about a Web site by using only an IP address or DNS name. (You must use only the second-level domain name—for example, microsoft.com, not www.microsoft.com.)
• NSLookup (included with Windows 2000), a diagnostic tool that finds DNS information held on DNS name servers.

Attackers often spend quite a bit of time gathering information, like a burglar who "cases" a building before attempting to break in.

Step 4: Attack!

The next phase is the attack. As described in Chapter 2, "A Process for Building Secure Web Applications," there are six kinds of attacks based on the STRIDE vulnerability model: spoofing user identity, tampering with data, repudiability, information disclosure, denial of service (DoS), and elevation of privilege. The DoS attack is probably the easiest to perform and is less technically sophisticated than the other types. The problem with DoS attacks is that they can easily be launched from scripts written in Perl or executable programs written in C or C++. This code can be downloaded by "script kiddies" (people who understand security and low-level TCP/IP details and like to mount random attacks) or by people with little or no technical security experience who want to cause a little mayhem on the Web.

The evolution of many hacks goes like this:

1. A hacker finds a vulnerability in an application.
2. He writes some code to automate an attack.
3. He posts the code to various Web sites with a description of the attack.
4. A script kiddie finds a site that she wants to attack and performs a scan to determine what services are used on the site.
5. She uses a search engine to search the Internet for the words "vulnerability" and "security" and the name of the application she wants to attack.
6. She goes to a site that explains the vulnerabilities, common administration errors, or configuration errors in the specific version of the application.
7. She uses the hacker's code to mount an attack.

It's all too easy to mount this kind of automated attack. This is why you must stay on top of security-related fixes from vendors.

Although some other attack categories are scripted, they tend to be more technically challenging. A common data-tampering attack is one that defaces a Web site's home page. This usually involves exploiting a vulnerability in the Web server or operating system to give the hacker a high-privileged account—hence it's also an elevation of privilege attack—such as administrator or, in the UNIX world, root.