Die FTP-NAT-Lücke - Wie funktioniert sie?

Das active-FTP-Protokoll

Der gezeigte Angriff funktioniert, weil der Router in seinen NAT- oder Firewall-Regeln das active-FTP-Protokoll unterstützt.
Um den Angriff zu verstehen, benötigen wir etwas Hintergrundwissen über die Funktionsweise von FTP:

FTP verwendet (aus historischen Gründen) zwei Verbindungen. Eine wird Kontrollverbindung genannt. Sie wird verwendet, um den Nutzer einzuloggen, Verzeichnisse zu wechseln, und auch, um Datenübertragungen einzuleiten.

Die Daten selbst werden über eine zweite Verbindung, die sog. Datenverbindung.

Diese Konstruktion vereinfacht das Design des FTP Clients und auch des Servers. Man muß dann nicht innerhalb einer Verbindung zwischen Daten und Anweisungen unterscheiden. Man benötigt auch keinen Mechanismus um z.B. das Dateiende bei einer übergebenen Datei zu erkennen, wie z.B. bei SMTP mit der "."-Zeile.

Traditionell hat FTP den sog. "active mode" benutzt - heutzutage verwenden aber die meisten FTP-Clients den "passive mode". Der Unterschied besteht darin, wer die Datenverbindung aufbaut, und wer drauf wartet, daß die Verbindung aufgebaut wird:
Bei passivem FTP, baut der Client nicht nur die Kontroll- sondern auch die Datenverbindung auf. Diese Vorgehensweise macht keine Probleme aus der Sicht einer lokalen Firewall oder NAT-Komponente.
Bei aktivem FTP baut hingegen der FTP-Server die Datenverbindung auf. Dabei verbindet er zu einem Port, den der Client ihm in einer Kontrollanweisung mitteilt.

Aktives FTP und Paketfilter/NAT-Geräte

Dies führt zu einem Problem - sowhl für Paketfilter (Firewalls) als auch für NAT-Geräte.
Es erscheint eine hereinkommende Verbindung, die auf ihre Berechtigung geprüft werden muß. Bei NAT muß auch noch entschieden werden, wohin die Verbindung weitergeleitet werden muß.

Um das tun zu können, muß der Paketfilter/das NAT-Gerät die Kontrollverbindung "mitlauschen", um mitzukriegen, wann eine eingehende Verbindung zu erwarten ist, und von wo. Bei NAT muß das Gerät diese Anweisung sogar manipulieren, um die Antwort zunächst auf seine eigene IP umzuleiten. Der FTP-Server könnte das innere Netzwerk ja nicht direkt erreichen.

Dieses Verhalten ist zwar gut für die Funktionalität (aktives FTP ist möglich), aber es ist gefährlich aus Sicherheitssicht. Der Paketfilter/das NAT-Gerät hat keinerlei Chance festzustellen, ob die Daten, die es betrachtet wirklich von einem FTP-Client kommen.

Was Java Applets damit zu tun haben

Java ist eine clientseitige Sprache. D.h. Sie wird auf dem Rechner desjenigen ausgeführt, der eine Webseite besucht. Da das offensichtlich gefährlich ist, wird der Code in einer sog. "Sandbox" ausgeführt. Eine "Sandbox" ist eine Umgebung, von der aus nur wenig Zugang zur "Außenwelt" besteht. Damit wird es möglich, nicht vertrauenswürdigen Code (z.B. von einer Webseite, der Sie nicht völlig vertrauen) auszuführen, ohne daß das dem System schaden kann. Der code kann aus seinem "Sandkasten" nicht raus.

Das Sandbox-Sicherheitsmodell für Java Applets erlaubt, daß sie Verbindungen zu dem Server aufbauen, von dem sie geladen wurden. Das ist eine beabsichtigte Eigenschaft. Sie ist wichtig, damit viele Applets korrekt funktionieren können.
Beispiele für sinnvolle Verwendung sind z.B. Chat-Applets, Applets, die Daten nachladen, wie z.B. Bilder, Applets, die Karten anzeigen und Details nachladen, wenn der Benutzer zoomt, etc.

Das Test-Applet "simuliert" nun einen FTP-Client. Es verbindet sich mit einem "FTP-Server" auf dem Testserver, von dem es geladen wurde.

Die Verbindung sieht von außen wie eine ganz normale FTP-Verbindung aus. Allerdings öffnet das Applet nicht - wie es ein realer FTP-Client täte - nicht einen eigenen Port für die hereinkommende Verbindung, sondern wählt einfach einen Port von der Liste, die es testen soll.

Das Firewall-/NAT-Gerät wird die KOntrollnachricht abfangen und ggf. ändern (bei NAT) und weiterleiten. Danach wartet es auf die hereinkommende Verbindung.
Wenn diese kommt, leitet es sie an die Maschine weiter, die die Kontrollverbindung hält - und erlaubt damit dem Testserver Zugriff auf einen beliebigen Port dieser Maschine.

Wenn ich Java deaktiviere, bin ich dann sicher?

Nicht unbedingt. Es gibt andere Möglichkeiten, solche Verbindungen auszulösen. Flash und JavaScript via XmlHttp wären möglich.
Besonders schlechte Router könnten sogar auf "normales" HTML hereinfallen. Z.B. auf seltsame Refresh-Kommandos oder Links.