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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/