Mail-Header Injection – eine Analyse an PHP

Den vollständigen 1. Teil des Dokumentes unter Creative Common-Lizenz als PDF-Datei herunterladen:

• Analyse und Maßnahmen gegen Sicherheitsschwachstellen bei der Implementierung von Webanwendungen in PHP/MySQL (Teil 1)

Zu den eher unbeachteten Sicherheitsschwachstellen in PHP gehört die Mail-Header-Injection. Sie zeigt sich, wenn Nutzereingaben ungeprüft mit der mail()-Funktion [PHPe] verwendet werden. Es ist dann möglich, den Versand von Nachrichten zu manipulieren. Der Grund liegt darin, dass die mail()-Funktion die übergebenen Parameter ungeprüft nach Spezifikation [RFC2822] des „Internet Message Format“ an den jeweils installierten Mailserver¹ schickt.

1.3.1 Gefahreneinschätzung

Durch das Manipulieren der E-Mail-Header² sind der Webserver oder die Webanwendung nicht direkt bedroht. Jedoch entsteht womöglich ein weit größerer Schaden durch:

• Spamer³ und
• Konkurrenz / Saboteure.

Spamer haben früh die Möglichkeiten entdeckt, über ungeschützte E-Mail-Formulare auf Webseiten, anonym auf fremde Kosten und in fremdem Namen massenhaft ihre Werbe-E-Mails zu versenden. Sie bringen dadurch womöglich sogar die E-Mail-Infrastruktur der betroffenen Seite und des dahinter liegenden Unternehmens zum Erliegen, falls die missbrauchten Server in weltweit verfügbare black lists⁴ eingetragen werden. Diese Listen werden gerne von E-Mail-Dienstleistern konsultiert, um auf Grund der Einträge, E-Mails von bestimmten Servern als SPAM zu klassifizieren oder gar nicht erst weiter zu leiten.

Saboteure oder die unbeliebte Konkurrenz können ebenfalls ungeschützte E-Mail-Formulare missbrauchen um E-Mails mit unvorteilhaften Texten oder Kündigungsschreiben im Namen der sabotierten Firma zu versenden. Der entstandene Imageschaden kann erheblich sein.

1.3.2 Angriffsvektoren

Hinzufügen von E-Mail-Empfänger

Ein typischer Angriff besteht in der missbräuchlichen Nutzung eines Kontaktformulars einer Webseite. Solche Formulare bieten meist Eingabefelder für:

• Namen des Benutzers (für Ansprache),
• E-Mail des Benutzers (für mögliche Antwort),
• Betreff und
• Nachricht.

Sofern aus den eingegebenen Daten eine E-Mail erstellt und versendet wird, besteht die Möglichkeit der Manipulation⁵. Aus Gründen der Usability wird die E-Mail des Nutzers auf solche Weise in die abgehende E-Mail eingefügt, dass bei einem Klick auf „Antworten“ in einem E-Mail-Programm, die Antwort an diese Adresse geht. Es folgt ein Beispiel, welches dies leistet, so wie es im Internet gefunden werden kann:

Die Funktion mail() erzeugt daraus eine korrekt formatierte E-Mail:

Wie zu sehen ist, wird die Nutzereingabe aus der Variable $email ungeprüft und ungefiltert im Funktionsaufruf verwendet. An dieser Stelle nimmt die Funktion mail() zusätzliche Parameter für den Kopf-Bereich der E-Mail an. Dieser kann laut Mailprotokoll weitere Daten enthalten, die durch das Sonderzeichen line feed⁶ getrennt werden.

Hier seien die Empfänger-Felder [RFC2822, Kap. 3.6.3] genannt, die sich gut für einen Missbrauch eignen:

• Cc (Carbon Copy)⁷,
• Bcc (Black Carbon Copy)⁸.

Ein Angreifer nutzt die ungeprüfte Datenübergabe im Feld „Ihre E-Mail“ aus und trägt anstatt einer einzigen – der eigenen E-Mail-Adresse – eine beliebige andere Adresse ein, gefolgt von dem hexadezimal kodierten line feed (%0A). Somit hat er laut RFC-Definition den Teil des E-Mail-Kopfes „From:“ abgeschlossen und kann zusätzliche, definierte und gültige Parameter einfügen. Da die Definition es erlaubt, eine E-Mail an mehrere Empfänger zu senden, indem mehrere E-Mail-Adressen mit Komma (,) getrennt eingetragen werden, kann der Angreifer die manipulierte E-Mail an beliebig viele Empfänger senden.

Abbildung 15: Missbrauch des Cc:-Parameters um mehrere Empfänger einzufügen

Damit der Angriff nicht allzu offensichtlich wird, verwendet der Angreifer wahrscheinlich den „Bcc:“-Parameter. So sehen die Empfänger nicht, dass die E-Mail an viele andere Empfänger gegangen ist.

Abbildung 16: Missbrauch des „Bcc:“-Parameters um mehrere Empfänger einzufügen

In der Spezifikation [RFC2822, Kap. 3.6] wird die Anzahl der Feldnamen im E-Mail-Kopf definiert. Dabei wird präzisiert, dass beispielsweise das Feld „To:“ nur einmal im E-Mail-Kopf vorkommen darf. Jedoch gelingt es, der PHP-Funktion mail() mehrere „To:“ – Felder zuzuordnen. Das doppelt vorkommende „To:“-Feld stört die weitere Verarbeitung nicht, denn der E-Mail-Kopf wird im weiteren Transport durch E-Mail-Gateways und Relays korrigiert und neu zusammengefügt⁹. Diese Fehlertoleranz erweist sich als leicht zu missbrauchen. Da der Angreifer im oben genannten Beispiel das „To:“-Feld des Formulars nicht ändern kann, versucht er dieses über die anderen Mail-Kopf-Felder neu zu setzen. Dabei beachtet er die notwendige Trennung der Felder durch das Sonderzeichen line feed (n, Hexadezimal: %0A) und definiert so ein zweites „To:“-Feld

Abbildung 17: Injizieren des „To:“ und des „Bcc:“- Feldes

Die Funktion mail() erzeugt daraus folgenden E-Mail-Body¹⁰:

Diese E-Mail hat also nach der Manipulation drei direkte Mail-Empfänger („To:“) und drei unsichtbare Empfänger („Bcc:“).

Manipulieren des Inhaltes

Die Missbrauchmöglichkeiten durch Manipulation des E-Mail-Kopfes beschränken sich nicht nur auf das Hinzufügen von E-Mail-Empfängern. Selbst beliebte Webseitendienste wie „Diese Seite einem Freund empfehlen“ mit zuvor festgelegtem und nicht über ein Formular veränderbarem E-Mail-Text, können zu SPAM-Zwecken manipuliert werden.

Teilweise Ersetzen des E-Mail-Textes

In [RFC822] wird das Ende des E-Mail-Kopfes und der Anfang der E-Mail-Nachricht durch das zweifache Vorhandensein der Sonderzeichen carriage return (r) und line feed (n) spezifiziert, die praktisch eine Leerzeile erzeugen¹¹. Um die E-Mail-Nachricht einzuleiten genügt es also, innerhalb des E-Mail-Kopfes diese Sonderzeichen einzufügen.

Als Beispiel wird ein Empfehlungsformular mit folgenden Eingabefeldern dienen:

• Name des Empfängers und
• E-Mail des Empfängers.

In diesem Fall ist der E-Mail-Text oft festgelegt, damit ungewünschten Änderungen vorgebeugt wird.

Der Angriff wird mit Hilfe des Beispielcodes aus Abbildung 18 analysiert. Zu Gunsten der Übersichtlichkeit wird der im Formular eingegebene Name nicht weiter behandelt.

Abbildung 18: Formular zur Weiterempfehlung einer Webseite

Der E-Mail-Körper mit sichtbar gemachten Sonderzeichen (n) die das Protokoll verlangt, sieht wie folgt aus (Dieses ist für Unix, Linux und MacOS-Sytsteme; unter Windows: rn):

Angriffsvektor

Gelangt die vom Nutzer eingegebene E-Mail-Adresse ohne weitere Prüfung in die PHP-mail()-Funktion, so kann ein Angreifer unter Beachtung der Sonderzeichen einen eigenen E-Mail-Text definieren, obwohl er keinen Zugriff auf den bereits vordefinierten Text hat. Dazu fügt er am Ende eines durch ihn veränderbaren E-Mail-Kopf-Feldes die Sonderzeichen (n) in hexadezimaler Schreibweise (%0A) ein:

Abbildung 19: Text über den E-Mail-Kopf in die E-Mail einfügen

Die erzeugte E-Mail sieht jetzt wie folgt aus:

Beim Empfänger wird die E-Mail wie folgt dargestellt:

Durch das Einfügen von Sonderzeichen in eine ungeschützte mail()-Funktion, gelingt einem Angreifer sogar das Ändern des vordefinierten E-Mail-Textes. Im folgenden Abschnitt wird analysiert, wie der alte E-Mail-Inhalt komplett unsichtbar gemacht werden kann.

Komplettes Ersetzen des E-Mail-Textes

Zu diesem Zweck wird das erweiterte Konzept der E-Mail verwendet, welches es erlaubt, Inhalte in einen E-Mail-Text einzufügen, die nicht nur aus US-ASCII-Zeichen bestehen. Die unter [RFC2045] definierte MIME-Kodierung beschreibt ein neues E-Mail-Kopf-Feld „Content-Type:“ welches das Vorhandensein von unterschiedlich kodierten Teilnachrichten markiert. Desweiteren wird eine Zeichenkette definiert, die als Trennzeile (boundaries) dient, um solche speziell formatierten Inhalte im E-Mail-Körper für die korrekte Anzeige voneinander zu unterscheiden.

Abbildung 20: „Content-type:“ mit zugehörigem Text

Laut Spezifikation der MIME-Kodierung, ist der E-Mail-Inhalt nach der abschließenden Trennzeile zu Ende¹². Diese Eigenschaft kann ein Angreifer nutzen, um den ursprünglichen E-Mail-Inhalt auszublenden und allein den von ihm eingefügten Text anzuzeigen. Dazu injiziert er im E-Mail-Kopf eine eigene Content-type-Definition:

Abbildung 21: Injizieren von Content-type

Die erzeugte E-Mail sieht jetzt so aus:

Abbildung 22: E-Mail-Körper mit injiziertem Content-type

Die E-Mail kommt wird beim Empfänger wie folgt dargestellt¹³:

Andere Möglichkeiten des Angriffs mit MIME-Kodierung

Die MIME-Spezifikation lässt das Einbinden unterschiedlicher Datentypen in E-Mails zu. Ein Angreifer kann also auch Base64-kodierte Bilder oder ausführbare Programme versenden [RFC2045].

---

Fußnoten

1. Je nach Konfiguration kann es sendmail (http://sendmail.org/) oder SMTP [RFC2821] sein.
2. Im weiteren Text wird „Header“, „Kopf“ genannt.
3. SPAM : Bezeichnung für eine unerwünschte Werbebotschaft meist als E-Mail. (Anmerkung des Autors)
4. „schwarze Listen“ enthalten Namen von Server, die z.B. SPAM versenden. Vergleiche: [Wikm]
5. Nicht betroffen sind beispielsweise Systeme, die keine E-Mail erzeugen, sondern die Daten in eine Datenbank schreiben.
6. „Line Feed“ oder „Zeilenvorschub“ ist ein nicht darstellbares Sonderzeichen.
7. „Carbon Copy“: ein Durchschlag der E-Mail geht an diesen Empfänger. Die anderen Empfänger sehen an wen eine Kopie gegangen ist. (Erklärung des Autors.)
8. „Black Carbon Copy“: ein Durchschlag der E-Mail geht an diesen Empfänger. Für die anderen Empfänger ist die Existenz dieser Kopie nicht sichtbar. (Erklärung des Autors.)
9. Vergleiche: [RFC1521, Kap. 7.2]
10. Im weiteren Text wird „Body“ „Körper“ genannt.
11. „B.2. SEMANTICS Headers occur before the message body and are terminated by a null line (i.e., two contiguous CRLFs).“ [RFC822]
12. „The encapsulation boundary following the last body part is a distinguished delimiter that indicates that no further body parts will follow.“ ([RFC1521, S. 30, Kap. 7.2.1]
13. Voraussetzung ist ein E-Mail-Client, der die „multipart“-Definition versteht.

---

Literaturverzeichnis

[PHPe]	PHP- Manual „mail“ http://de.php.net/manual/de/function.mail.php [letzter Besuch: 20.01.2008]
[RFC2821]	Klensin, J.; AT&T Laboratories „Simple Mail Transfer Protocol“ http://tools.ietf.org/html/rfc2821 [letzter Besuch: 20.01.2008] September 1993
[RFC2822]	Resnick, P.; QUALCOMM Incorporated „Internet Message Format“ http://tools.ietf.org/html/rfc2822 [letzter Besuch: 20.01.2008] April 2001
[RFC822]	ARPA Net; Crocker, David H. „STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES“ http://tools.ietf.org/html/rfc822 [letzter Besuch: 20.01.2008] 13.08.1982
[RFC2045]	Borenstein, N.; Bellcore, Freed, N.; Innosoft, First Virtual „ Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies“ http://www.ietf.org/rfc/rfc2045.txt [letzter Besuch: 20.01.2008] November 1996
[RFC1521]	N. Borenstein, Bellcore, N. Freed, Innosoft „MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies“ http://www.ietf.org/rfc/rfc1521.txt [letzter Besuch: 20.01.2008] September 1993
[Wikm]	Wikipedia „Schwarze Liste“ http://de.wikipedia.org/wiki/Blacklist#Schwarze_Listen_im_Kommunikationsbereich [letzter Besuch: 03.04.2008]

---

Diese Arbeit wird im Rahmen der „Creative Commons“-Lizenz zur Verfügung gestellt.
Sie dürfen:

• das Werk vervielfältigen, verbreiten und öffentlich zugänglich machen
• Bearbeitungen des Werkes anfertigen

Zu den folgenden Bedingungen:

• Namensnennung. Sie müssen den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen (wodurch aber nicht der Eindruck entstehen darf, Sie oder die Nutzung des Werkes durch Sie würden entlohnt).
• Keine kommerzielle Nutzung. Dieses Werk darf nicht für kommerzielle Zwecke verwendet werden.

Vollständiger Lizenztext: http://creativecommons.org/licenses/by-nc/3.0/deed.de