Raptor Firewall FTP Bounce vulnerability
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.
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.
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
We verified and analysed the vulnerability using the following setup:
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, including annotated "tcpdump" packet traces are available at:
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/