Topic:	Apple Airport Wireless Products FTP Proxy Provides Security Bypass
Credit:	Sabahattin Gucukoglu
Date:	2010.03.15
CWE:	CWE-264 (Show similar)
CVE:	CVE-2010-0962 (Show details) Use CVE to see details like: - CVSS2, - Affected Software, - References

The FTP proxy used in Apple's Airport Express, Airport Extreme, Time Capsule and possibly elsewhere doesn't check the
client provided address and port given by the FTP PORT command against the IP address of the connecting client, or
against the use of privileged ports. (The FTP PORT command is used by a FTP client to tell an FTP server which address
and data port to initiate the data connection on.) The FTP proxy is used to provide assistance to clients operating in
NAT environments served by the Apple products. FTP servers running behind a NAT with this assistance can have addresses
in the command channel rewritten for them so that external clients can reach them when operating in passive mode. The
ALG operates as a proxy server, assuming responsibility for connections to the FTP server, and must therefore also
handle and modify rewriting of the PORT command. It looks like it might be ftp-proxy from PF.

The effect of this problem is to allow anybody with access to the FTP port forwarded on the exterior side of an Apple
Airport product that offers NAT to internal clients, which for a publicly-accessible FTP server is the big bad world, to
induce an FTP server operating behind a NAT to send data to arbitrary addresses and ports. This is true even if the FTP
server is configured to operate more securely, since it sees connections from the NAT's exterior interface, not the
connecting client. This is useful for bouncing anonymous port scans off the victim NAT, or if data is available or can
be written to and then read from the FTP server, potentially for anonymous attacks, spam, news floods, and other such
badness. Any trust relationship and/or security implied or assumed by a NAT is also gone, since the PORT command can
also specify private addresses, inside the NAT, for victimisation. Best of all, the gateway itself makes no log entry
concerning FTP connections that have been run through the proxy.

Workarounds: do not use FTP; do not trigger the use of the ALG (FTP proxy) by explicitly using ports other than 21 on
the inbound port mapping. If you can't do those things, you can avoid the worst effects of this attack by disabling FTP
uploads that can later be downloaded by anonymous users.

Apple likes to keep secrets for the protection of its customers. Since the reasonable release of this advisory removes
that protection, confidential information vouchsafed to me can be safely disclosed with no ill effects. Apple has a
fix, and according to its last seemingly automatic template message, they are still testing it and do not know precisely
when it will be released. This is confidential information. DO NOT DISCLOSE!

Advisory history:

Apple were notified on 4 Dec 2009, and responded promptly. They were given 60 days initially.

Apple contacted me on 7 January 2010 to ask who to give credit to. Personal attribution.

On 18 Jan I contacted Apple, advising that they'd passed the six weeks milestone.

On 25 January I contacted Apple, advising that they'd passed the 7 weeks milestone. They volunteered confidential
information.

On 4 Feb, I urged Apple to tell me when a fix was to be issued, approximately. They'd had their two months, and release
cycles happen, but I wanted news within a fortnight. Didn't they understand that their customers were at easy risk, and
that keeping it quiet didn't change that? By today - that is, by about 3 months - they would certainly be beyond
reconciliation. They volunteered confidential information.

On 4 March, I got bored of waiting, and made this announcement. The fix is not out; apply workarounds, or trust to the
fates and the security of your network.

Cheers,
Sabahattin

References: