Amit Klein's security corner - FTP

Safari FTP PASV manipulation vulnerability

amit — Wed, 16 Sep 2015 16:37:33 +0000

Release date

September 16th, 2015

Vulnerability description

FTP PASV manipulation attack was first described by mark@bindshell.net in his 2007 paper “Manipulating FTP Clients Using The PASV Command” (originally at http://bindshell.net/papers/ftppasv, but no longer there; live mirror at https://web.archive.org/web/20120904163048/http://bindshell.net/papers/ftppasv/ftp-client-pasv-manipulation.pdf). The reader is encouraged to make himself/herself familiar with that paper, and with the PoC at https://web.archive.org/web/20111228004729/http://www.bindshell.net/papers/ftppasv/ftp-pasv-poc-v1.0.zip.

The impact of the attack is as following (directly quoting from the above paper, with some original references removed for clarity):

It is possible for malicious FTP servers to cause [the FTP client] to connect to TCP ports on other hosts. This allows us to extend existing JavaScript-based port scan techniques in the follow ways:

• Scan ports which modern browsers would not normally connect to

• Fingerprint services which do not send a banner by timing how long the server takes to terminate the connection

• Perform simple “banner grabbing” to identify services running on other hosts

Apple Safari is not vulnerable to the attack as described in 2007. However, it turns out that if the FTP server responds to the CWD command or to the PASV command with a response that ends with LF (instead of CR+LF), then Safari becomes vulnerable, i.e. it will respect a PASV response that points at any IP and any port (instead of the FTP server’s IP address).

To demonstrate this, the following changes need to be applied to the original PoC (for simplicity only a single PoC will be demonstrated – that of grabbing banners):

In file “ftp-server.pl”, line 193, change from:

sendit("250 Directory successfully changed.\r\n");

To:

sendit("250 Directory successfully changed.\n");

And in file “ftp-pasv-demo3.html”, line 25, change from:

status.value += (time / 1000) + ' (t + ' + elapsed_time + '): ' + message + "\n";

document.getElementById('status').value += (time / 1000) + ' (t + ' + elapsed_time + '): ' + message + "\n";

The latter is due to WebKit-based browsers (e.g. Safari) exhibiting different behavior w.r.t. this DOM action – it has nothing to do with the actual vulnerability.

On top of these changes, the demonstrator needs to follow the instructions in the PDF paper and in the HTML page comments in order to prepare the PoC.

Affected products/libraries

Safari for iOS 8.4.1. User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 8_4_1 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12H321 Safari/600.1.4. Earlier versions of Safari for iOS are probably vulnerable.

Safari 5.1.7 (7534.57.2) for Windows (latest, but no longer supported). User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2

The issue may also apply to Safari for MacOS/X – probably up to and including OS/X 10.10.5.

According to Apple, the issue resides in the “CFNetwork FTPProtocol” API/library.

CVE

Apple obtained the CVE identifier CVE-2015-5912 to denote the issue. Bugtraq has BID 76764 to denote the iOS vulnerability.

Fix information

According to Apple, the issue fixed at least for the iOS platform in version 9 (iOS 9), immediately available (APPLE-SA-2015-09-16-1 for iOS, and later APPLE-SA-2015-09-30-3 for OS/X). For more information about this security update, please refer to https://support.apple.com/en-us/HT205212 and https://support.apple.com/en-us/HT205267.

The localhosed attack (stealing IE localhost cookies)

amit — Sun, 21 Jun 2015 18:40:09 +0000

This extended advisory describes a vulnerability in Microsoft Internet Explorer 11/10/9/8/7 (on Windows Vista and above). The vulnerability allows stealing cookies for local machine domains/IP addresses. Additionally, the local IP address used by IE to communicate to the Internet is exposed (even if behind a NAT or a SOCKS proxy). On Windows XP, IE 8-6 are vulnerable to the IP exposure vulnerability only.

Having an HTTP (web) server listening locally on a Windows machine is not too rare, due to a multitude of software installations that do just that, e.g. for administration/control panel. Googling for e.g. Windows “http://localhost” yields almost 1 million hits. There’s no need to name names, but it suffices to say that there are major players from many software types, from virtual machines, to analytics, and of course content management systems.

Of course, such setup may be susceptible to a plain and simple CSRF attack. However, stealing the cookies has several advantages over CSRF:

If the server employs anti-CSRF code, having the session cookies (in combination with DNS rebinding) can, in some cases (depending on the exact nature of the anti-CSRF technique) work around this protection.
Session cookies (in combination with DNS rebinding) can enable reading data off sensitive pages.
Cookies may contain sensitive information in and out of themselves.

The attack method can only steal cookies sent with HTTP requests (not HTTPS). Fortunately for the attacker, a web server bound to a local address is unlikely to use SSL.

As for local IP address disclosure, this can be used to map an organization behind a NAT, or as a SOCKS proxy piercing (i.e. exposing the real IP address of a client “hiding” behind a SOCKS proxy).

The impact of the cookie stealing attacks is summarized in the below table:

	New window	Frame	Self navigation
Browser affected	All IE versions on Windows Vista and above	All IE versions on Windows Vista and above	IE11
User interaction?	Yes (one click)	No	No
Host scope	Internet, Local Intranet	Internet	Local Intranet
Cookie type	persistent, session	session (and any cookies assigned with P3P acceptable compact policy)	persistent, session
UAC mode supported	(all)	(all – if UAC is off, the scope can also cover Local Intranet, and there, persistent cookies can be stolen as well)	On (default)
SmartScreen mode supported	Medium (default) or below	(all)	(all)

Full details here.

Filezilla FTP server is vulnerable to FTP PORT bounce attack and PASV connection theft

amit — Wed, 06 May 2015 15:40:04 +0000

Filezilla FTP server is vulnerable to FTP PORT bounce attack and PASV connection theft

Date: May 6th, 2015

Filezilla FTP server (affected versions: 0.8.0 - 0.9.50) is vulnerable to PORT bounce attack and to PASV connection theft. The attack concepts are very old. FTP PORT bounce attack is described e.g. in Hobbit’s 1995 writeup “The FTP Bounce Attack” and in CERT’s 1998 tech tip “Problems With The FTP PORT Command or Why You Don't Want Just Any PORT in a Storm” (originally at http://www.cert.org/tech_tips/ftp_port_attacks.html, that page is no longer responsive; mirrored at http://web.archive.org/web/20131105191347/http:/www.cert.org/tech_tips/ftp_port_attacks.html). Among the first descriptions of the PASV connection theft attack are David Sacerdote’s 1996 paper “Some problems with the File Transfer Protocol, a failure of common implementations, and suggestions for repair”, Jeffrey R. Gerber’s 1999 paper “FTP PASV ‘Pizza Thief’ Exploit” (originally at http://www.infowar.com/iwftp/iw_sec/iw_sec_01.txt but no longer available there; mirrored at https://web.archive.org/web/20000303212433/http://www.infowar.com/iwftp/iw_sec/iw_sec_01.txt), and Daniel J. Bernstein’s 1999 paper “PASV security and PORT security”, which names the attack and discusses effective and ineffective defense mechanisms. This advisory will refer to Bernstein’s work for terminology.

Filezilla FTP server was designed to protect against these attacks chiefly by verifying that the data channel remote IP address is identical (in “strict mode”) or at least from the same class C (in the more relaxed mode, which is the default) to the control channel remote IP address. See the Filezilla Server Interface (GUI) screenshot:

Unfortunately, due to a bug in Filezilla FTP server (introduced in version 0.8.0, released January 1^st, 2003), it is not the remote IP address of the channels which is subject to these tests, but rather the local IP address. This means that as long as the control channel and the data channel are established to the same IP address (that of the Filezilla server, naturally), the security test is passed, regardless of the remote addresses. In other words, practically there’s no IP address restriction, no matter what settings are chosen in the Filezilla server GUI.

For the (PORT) bounce attack, the net result is that the attack can proceed without hindrance.

For PASV connection theft, Filezilla FTP server offers an additional de-facto security layer in the form of a weak variant of “PASV SYN protection”, namely “Closing a socket as soon as accept() succeeds”. From experiments, Filezilla doesn’t verify that there’s only a single TCP connection established to the data port. It does close the listening port for the data channel almost immediately after the first connection is established (this is done after the accept() call returns). However, as Bernstein mentions, this defense is inadequate. It is still possible to have two (or even more) connections established to the data port (the first one is the attacker’s and the second one is the legitimate client’s), with the extra connections being sent RST by the Windows server soon after they’re established (in experiments, this was around 0.2-0.4 milliseconds after the first connection is established) due to the application (Filezilla FTP server) not accepting them and closing the listening socket (after the first accept()). Moreover, on Windows 8 the port number is used by Filezilla for the passive connection is predictable (it increments by 1 on each incoming connection, if there’s no additional port-consuming activity on the server).

This means that it is possible to mount a “PASV connection theft” attack against Filezilla FTP server from any IP address. Such attack requires accurate timing on behalf of the attacker (to both win the race condition, and yet allow the legitimate client to momentarily establish a connection), and a bit of guesswork or enumeration (to get the port guessing right). First the attacker needs to predict the port Filezilla server will use for the data channel. If the attacker has access to the FTP service (i.e. has an account, or can use a public account), the attacker can obtain a port number sent by the server in a PASV response, and presume that the next port to be assigned is the port he/she received, incremented by 1 (the attacker can of course try increments by other small numbers to compensate for additional port consuming activities taking place in the meanwhile). Next, the attacker waits for the legitimate client’s session to reach the point where Filezilla opens a data port. The attacker then needs to carefully time his/her actions: the attacker needs to establish a 3-way TCP handshake to that port such that the final ACK packet will reach the Filezilla server just before the ACK packet of the 3-way TCP handshake established by the legitimate client. If the attacker manages to establish the TCP connection before the legitimate client, but in such timing that the legitimate client’s TCP connection is established before the port is closed, then the attacker’s TCP connection will be used by Filezilla server as the data connection, while the legitimate client’s TCP connection is established successfully, thus allowing the FTP logic on the legitimate client to proceed, issuing e.g. RETR/STOR/LIST, resulting in the data being sent or received via the data channel open between Filezilla server and the attacker. The end result is data theft (RETR – file, LIST – directory) or data spoofing (STOR – file).

The attack was simulated successfully over a switched LAN with the legitimate FTP client being Internet Explorer 11 (RETR scenario).

FXP transfers are also possible (again, regardless of the GUI settings) and trivial to mount because the PASV additional hurdle is irrelevant – the FTP servers are coordinated and hence there’s no race condition.

A new version of Filezilla FTP server (0.9.51) is available for immediate download at https://filezilla-project.org/download.php?type=server

I would like to thank the vendor (Tim Kosse) for his prompt response and highly professional and friendly conduct.

BugTraq ID: 74535

Amit Klein's security corner - FTP

Safari FTP PASV manipulation vulnerability

Tags:

The localhosed attack (stealing IE localhost cookies)

Tags:

Filezilla FTP server is vulnerable to FTP PORT bounce attack and PASV connection theft

Tags: