The FTP-NAT-problem - How does it work?

The active FTP protocol

The demonstarted exploit works due to the router supporting NAT or firewall rules for the active FTP protocol.
To understand how the exploit works, we must have a look into the inner workings of FTP:

FTP uses two connections (for historical reasons). One is the so called "Control Connection" which is used to log in the user, change directories and also for initiating data transfers.

The data transfers themselves use a second connection called "data connection".

This allows for simple client and server design, as you don't need to differentiate between commands and data being exchanged over the same connection. For example you don't need to supply a mechanism to detect the end-of-file on the transferred data, like SMTP has with it's "."-line.

Traditionally, ftp has used so called "active mode", though nowadays many ftp clients request "passive mode" by default. The difference is in who builds the connection and who waits for it to come in:
With passive FTP, the client also builds the data connection, so all is well from a firewall/NAT-perspective.
However with active FTP, the server builds the data connection, connecting to a port on the client, which the client tells him in a control message.

Active FTP and packet filters/NAT

This poses a problem, both for packet filters and for NAT devices. There will be an incoming connection, which has to be checked for validity and has to be directed to the right client in the case of NAT.

To be able to do this, the PF/NAT device will have to "snoop" on the FTP control connection to see that there will be an inbound connection coming and where it will come from. In the case of NAT, it will even have to manipulate the control connection, because it has to redirect the inbound connection to its official IP first so that it can forward it. The server wouldn't be able to reach the internal network otherwise.

Now this behaviour is nice functionality-wise (active FTP works), but it is dangerous security wise. the PF/NAT device has no evidence that the data it is looking at is really coming from an FTP client.

How JavaApplets come into play

Java is a client side language that can be executed inside a so called "sandbox". A sandbox is a defined environment, with only little access to the outside world. It is supposed to allow running untrusted code (e.g. from some website you don't fully trust) without it being able to cause harm to the host system - it can't break out of the sandbox.

Now the sandbox policy for Java Applets allow them to connect back to the server they were downloaded from. This is an intentional feature, which is important for many Java applets to be able to work properly.
Examples of useful uses for this feature are chat applets, applets loading data like pictures from the server, map applets loading detailed map data as the user zooms in somewhere, etc.)

What the test applet does, is emulating an FTP-Client which connects back to a test "FTP-Server" on the machine it was loaded from.

The Applet talking to the server will look like a perfectly valid FTP-Connection from the outside. However the applet does not - like a real FTP client would - allocate a receiving port for the inbound connection it requests, but rather tells the server a port from its list of ports to test.

The PF/NAT device will now intercept this port command, modify it, if needed (NAT) and send it along, waiting for the incoming connection.
When the inbound connection shows up, it will forward it to the machine that made the request. And thus allow my test server to connect to an arbitrary port on this machine.

So if I disable Java, I am safe?

Not necessarily. There are other Client side methods of making such connections. Flash and JavaScript via XmlHttp come to mind.
Some particularly braindead Routers might also fall for straight HTML tricks like strange refresh commands or links.