[25070] in bugtraq
Raptor Firewall FTP Bounce vulnerability
daemon@ATHENA.MIT.EDU (Roy Hills)
Tue Apr 16 14:37:31 2002
Message-Id: <4.3.2.7.2.20020415144003.00ae4730@192.168.124.1>
Date: Mon, 15 Apr 2002 15:11:58 +0100
To: bugtraq@securityfocus.com
From: Roy Hills <Roy.Hills@nta-monitor.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Raptor Firewall FTP Bounce vulnerability
Summary:
The Raptor Firewall can make an FTP server behind it vulnerable to the
well-known
FTP bounce vulnerability even if the FTP server used is not susceptible to
this issue.
Overview:
While performing a penetration test for a customer, we discovered that
their FTP server
was vulnerable to the well-known FTP Bounce attack from the
Internet. However, subsequent
conversation with the customer showed that the FTP server itself (a recent
version of
wu-ftp) was not vulnerable to the FTP bounce attack.
It appears that the Raptor Firewall's FTP proxy was somehow making the FTP
server vulnerable
to the FTP bounce vulnerability even though the FTP server itself was
immune to this problem.
The Firewall vendor (Symantec) have been informed of this issue.
Environment:
Firewall: Raptor 6.5.3i on Sun Solaris 7
FTP Server: wu-ftpd on internal network with anonymous access
Config: Using built-in Raptor FTP proxy for inbound FTP access from Internet
Analysis:
We verified and analysed the vulnerability using the following setup:
1. "attacker" - A Linux system on the Internet that connects to the FTP
server and
exploits the vulnerability
2. "victim" - A second Linux system on the Internet that is the target of
the bounce attack
3. "server" - The FTP server. External address 194.217.26.147, internal
10.1.13.5
4. "Firewall" - The Raptor Firewall
We verified the FTP bounce vulnerability from the Internet and used the
"tcpdump" packet
sniffer on the Internet "attacker", the Internet "victim" (target of the
ftpbounce test) and the
FTP server to determine what was going on.
It turns out that the Raptor Firewall re-writes the inbound FTP "PORT"
command and
changes the IP address to be the Hacker's IP rather than the Victim's, and
the port number
to be another ephemeral port. This means that the FTP server cannot detect
the FTP
bounce attack because it sees the correct IP address (the one of the hacker
rather than
the victim) and an ephemeral port. However, when the FTP Server makes the
outbound
connection to this IP address and port, the Firewall re-writes the IP
address and port in
the packet to be the IP address and port of the victim which was originally
specified by
the Hacker.
Thus, the Raptor Firewall prevents the FTP Server from detecting the FTP
bounce attack, and
permits the attack to take place. Because the FTP Server will always see
the "correct" IP
address and port in the PORT command, it cannot determine that an FTP
bounce attack is
being carried out and will accept the command.
Further information:
Further information, including annotated "tcpdump" packet traces are
available at:
http://www.nta-monitor.com/news/raptor-set.htm
Roy Hills
Technical Director
NTA Monitor Ltd
--
Roy Hills Tel: +44 1634 721855
NTA Monitor Ltd FAX: +44 1634 721844
14 Ashford House, Beaufort Court,
Medway City Estate, Email: Roy.Hills@nta-monitor.com
Rochester, Kent ME2 4FA, UK WWW: http://www.nta-monitor.com/
