© Akhararat Wathanasing, 123RF

Webapplikationen sind häufig Ziel von entfernten Angreifern. Die nutzen dabei die verschiedensten Schwachstellen aus, beispielsweise SQL-Injection-Fehler oder Cross-Site-Scripting-Gelegenheiten. Etwas seltener findet man Sicherheitslücken, die eine so genannte XML-External-Entity-Attacke ermöglichen.

Bei XML-External-Entity-Attacken nutzt der Angreifer aus, dass XML-Dokumente Verweise auf externe Dokumente oder Entities enthalten können, die der Parser im Zuge der Verarbeitung automatisch auflöst. Dabei darf er auch externe Ressourcen nachladen. Dieses Feature ist nützlich, weil es kürzeren und effizienteren Code ermöglicht.

Grundsätzlich unterscheidet man internal und external Entities. Bei einer external Entity kann ein Pfad oder eine externe Referenz in das Dokument eingebaut sein. Der Angreifer schickt spezielle XML-Inhalte an eine Webapplikation, die sie nicht korrekt filtert. Neben Denial-of-Service-Attacken sind durch diese Schwachstelle auch Angriffe auf interne Systeme in einer DMZ möglich.

Eine solche Schwachstelle [1] wurde kürzlich im Zusammenhang mit einer Java-Implementation des FTP-Clients-Protokolls gefunden. Java erlaubt für external Entities nämlich nicht nur HTTP- und HTTPS-, sondern auch FTP-Verbindungen.

Die eigentliche Verbindung realisiert Java über »sun.net.ftp.impl.FtpClient«. In dieser FTP-Client-Implementierung befindet sich allerdings ein Programmierfehler. Das Besondere an dieser Lücke ist, dass der Angreifer damit auch Befehle auf SMTP-Servern ausführen darf. Damit eine Java-Applikation FTP-Verbindungen aufbaut, muss der Anwender lediglich eine URL der Art »ftp://user:password@host:port/file.ext« übergeben.

Der Programmierfehler in der FTP-Implementierung betrifft das Verarbeiten des FTP-Benutzernamens. Laut RFC 959 darf der nämlich keine »CR«- und »LF«-Sequenzen enthalten. Die filtert die Java-Routine aber nicht heraus. Dadurch kann ein Angreifer via »%0D%0A« in der URL den »USER«- oder »PASS«-Befehl abbrechen. Danach darf er dann beliebige andere FTP-Befehle ausführen.

Das ist an sich schon eine interessante Schwachstelle, aber der Report zu der Sicherheitslücke weist zudem darauf hin, dass ein Angreifer damit auch Mails via SMTP verschicken kann, indem er damit einen SMTP-Server angreift. Grund hierfür ist, dass die SMTP- und FTP-Protokolle sehr ähnlich aufgebaut sind. Das macht bereits die erste Kontaktaufnahme mit einem FTP- und SMTP-Server deutlich:

$ nc ftp.kernel.org 21
220 Welcome to kernel.org
$ nc mail.kernel.org 25
220 mail.kernel.org ESMTP Postfix

Das hat zur Folge, dass die obige Attacke genauso auch gegen einen SMTP-Server gelingt. Der Angreifer sendet einen User-Befehl, den SMTP nicht interpretieren kann. Doch der Angreifer bricht aus dem Prozedere aus und führt so beliebige SMTP-Befehle auf dem Server aus. Java selbst wird sich über die präparierte URL zwar mit

sun.net.ftp.FtpLoginException: Invalid username/password

beschweren. Die übergebene Mail verschickt der SMTP-Server dann allerdings trotzdem.

Besonders kritisch ist diese Schwachstelle, wenn die Attacke als XML External Entity Angriff (XXE) durchgeführt wird. Sollte dann der Mailserver keine Spam- oder Malware-Filter haben, so kann der Angreifer auf diese Weise beliebige Dateien verschicken. Zudem kann er sehr einfach auch Attachements in der URL verpacken.

Neben Java ist auch die Python-FTP-Implementation (»urllib2« in Python 2 und »urllib« in Python 3) von einer ähnlichen Schwachstelle betroffen [2].