Schwachstellenanalyse

Unicode security issues on PHP

Freitag, Oktober 23rd, 2009 | PHP, Schwachstellenanalyse, Sicherheit, sseq-lib | 5 Kommentare

The last 3 days I put some other things by side to work on this here: A couple of unicode issues on PHP and Firefox. As one can see, securing web applications is also about knowing and understanding how data is coded and converted. To me it was obvious I had find out how to cope with this problems inside the security library SSEQ-LIB.

What are these vulnerabilities about

It's once again all about not checking / encoding user input, which we all know that it's evil. Let's learn something about Overlong UTF-8:

Overlong UTF-8 (non-shortest form)

First go read what sirdarckcat wrote about overlong UTF-8!

So you're back? Let us understand how an attacker can manufacture such an overlong UTF-8: We take for example the apostrophe ('). Converted to binary it is 00100111. (Actually we put the numeric char code from apostrophe into the converter (see asciitable) which is 39.)

So we now have this binary string 00100111 which means 39 which itself corresponds to apostrophe. Now we are going to make it overlong. But before we must have a look at how UTF-8 is coded. Look exactly at this binaries in the columns Byte 1 to Byte 4: The first ones and zeros are very important because they tell the UTF-8 decoder how long the entire character is and which byte belongs to it.

Ok, back again? So we want to enlarge a UTF-8 char by one more byte, so we look in the second row of the table from wikipedia: the first bit has to start with "110" because it means that this UTF-8 char is 2 byte long. The rest we can fill with zeros: 11000000. So we have the first Byte.

The second byte has to carry the initial value of 39 which is our apostrophe. We already know that 39 in binary is 00100111. Too bad that this string does not correspond with the UTF-8 definition for second bytes: it has to start with "10". Well actually we replace the first 2 bit with "10" and we're done! Out second byte is: 10100111.

We put them together: 11000000 10100111
We convert each to hexadecimal: \xc0 \xa7 or url encoded: %c0%a7.

What's wrong with overlong UTF-8

It is known, that interpreting non-shortest form UTF-8 is a security issue. Unfortunately PHP does interpret this overlong UTF-8. This is not a security breach by default. The point is that other software like web application firewalls, vulnerability scanners and even functions like "addslashes()" does not interpret this overlong UTF-8 code and so attack vectors or chars which should be escaped can pass by unidentified.

So when you escapes database input like this:
<?php
  $name 
utf8_decode(addslashes($GET_['name']));
  
mysql_query("SELECT * FROM table WHERE name='$name';");
?>


Or when you rely on "magic_quotes" (and you should not!):
<?php
  $name 
utf8_decode($GET_['name']);
  
mysql_query("SELECT * FROM table WHERE name='$name';");
?>


Just hope that no one inserts as "name": %c0%a7%20OR%201%2F%2A which would result in something to ask for all users in the database:
SELECT * FROM table WHERE name='' OR 1/*'


To sum up: addslashes() and "magic_quotes" are not capable to interpret this overlong UTF-8 so it passes by without escaping.

What can we do about it?

I spent some time to figure out how to check if non-shortest UTF-8 data contains potentially dangerous payload or not. Finally the most precise solution seems to me to be counting the special chars before and after "utf8_decode()". The reason why this works is that this kind of attack is based on infiltration of additional special chars which are kept hidden until they are revealed through "utf8_decode()". So after decoding we should count some more special chars than before.

When encoding to an inappropriate encoding like from UTF-8 to iso-xxxxxx-x some characters have to be replaced by a question mark (?). This question mark we must not count.

This function tells apart potentially dangerous overlong UTF-8 from harmless overlong UTF-8:
<?php
function seq_mb_count_symbols_($string_ '') {
    
$count 0;
    
    for (
$i=0$i mb_strlen($string_'UTF-8'); $i++){
        
$ch mb_substr($string_$i1'UTF-8');
        if (
ord($ch) != 64 && (
                                (
ord($ch) >= 33 && ord($ch) <= 62) ||
                                (
ord($ch) >= 91 && ord($ch) <= 96) ||
                                (
ord($ch) >= 123 && ord($ch) <= 126))
           )
        {
            
$count++;
        }
    }
    return 
$count;
}

function 
seq_check_nonshortest_utf8_($string_ '') {
    
$count seq_mb_count_symbols_(stripslashes($string_));
    
$after_count seq_mb_count_symbols_(utf8_decode(stripslashes($string_)));

    if (
$after_count $count) {
        return 
true;
    }
    
    return 
false;
}
?>


Check if string is dangerous:
<?php
if (seq_check_nonshortest_utf8_($string)) {
  
// yes, string contains hidden special chars. now take some appropriate action.
  
return false;
}
?>


Tell me if it works for you too, especially when your OS has some special encoding.

Additional thematic links

Bypass addslashes with UTF-8 characters

Tags: , , , , , ,

Session-Angriffe - eine Analyse an PHP

Sonntag, September 14th, 2008 | PHP, Schwachstellenanalyse, Sicherheit | 9 Kommentare

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




Eine „Session“ ist eine Arbeitssitzung mit einer Software. Webanwendungen basieren auf dem HTTP-Protokoll, welches die Kommunikation zwischen Client (Webbrowser) und Server (Webanwendung) regelt. HTTP ist ein zustandsloses Protokoll. Mehrere Kommunikationsschritte eines Webbrowsers zu einem Server werden nicht als eine Arbeitssitzung, eine Session, zusammengefasst, sondern unabhängig voneinander betrachtet. Die Möglichkeit, den Zustand der Webanwendung während einer Arbeitssitzung zu speichern, macht jedoch dynamische Webseiten erst möglich. Dadurch wird beispielsweise ermöglicht, dass ein einmal identifizierter Nutzer die Webseite verwenden kann, ohne sich beispielsweise jedes Mal erneut identifizieren zu müssen. Darüber hinaus kann sich die Webanwendung anhand der Sitzung, Daten und Einstellungen zu einem bestimmten Nutzer merken.

Im Folgenden wird die PHP-interne Sessionverwaltung näher beleuchtet. Sie wurde mit PHP Version 4.0 eingeführt und ist in ihrer Handhabung so einfach, dass sie fast ausschließlich und ohne weitere Anpassungen verwendet wird.

1.4.1 Gefahreneinschätzung

Mit Hilfe von Sessions wird in den meisten Fällen eine Identifizierung und Autorisierung gegenüber der Software durchgeführt. Alle Angriffe, die diese Autorisierung zweckentfremden, klonen beziehungsweise kopieren oder umgehen können, haben Kontrolle über das zu schützende System samt seinen Daten und sind als höchst gefährlich zu betrachten.

1.4.2 Das Sessions-Mechanismus

Eine Session stellt eine Identifizierung eines Clients gegenüber einem Server dar. Dazu wird in einem frühen Stadium der Kommunikation ein Identifikationsschlüssel vom Server zum Client geschickt. Fortan sendet der Client bei jeder Anfrage den Schlüssel mit, der als Kurzzeit-Passwort verstanden werden kann. Der Schlüssel kann über URL-Parameter, in Formularen als verstecktes Feld sowie in Cookies gesendet werden. Das Setzen des Schlüssels in ein Cookie gestaltet sich für einen Anwendungsentwickler als einfach, da das HTTP-Protokoll die Aufgabe der Übermittlung zwischen Server und Client übernimmt.

Der Session-Schlüssel

Da die Authentifizierung des Clients an den Server alleine über den Schlüssel statt findet, darf dieser nicht erraten werden können. Wenn der Schlüssel erraten werden kann, so kann eine Identität gestohlen werden, indem der Angreifer den bekannten Schlüssel zur Kommunikation mit demselben Server verwendet. Jedoch erzeugt PHP den Schlüssel mit einer ausreichend hohen Zufallswahrscheinlichkeit und mit einer Länge von 32 Zeichen. Ein Erraten ist praktisch nicht möglich.

1.4.3 Session-Fixation

Session-Fixation ist ein Angriff auf den Sessionschlüssel, der zur Identifizierung bei der Webanwendung benötigt wird. Da der Angreifer diesen nicht erraten kann, versucht er ihn vorzugeben. Der Angriff ist erfolgreich, wenn er einen Nutzer dazu bewegen kann, diesen fixierten Sessionschlüssel zu verwenden.

Um die Schadenswirkung bei Kenntnis des Schlüssels verständlich zu machen, wird sich eines Beispiels bedient:

In einem Bahnhofsgebäude befinden sich Schließfächer. Ein Angreifer verwendet ein Schließfach, entnimmt den Schlüssel und fertigt eine Kopie an. Anschließend gibt er das Schließfach wieder frei. Verwendet ein Opfer anschließend dasselbe Schließfach, so besitzt der Angreifer bereits einen passenden Schlüssel dazu. Da an solche Schließfächer keine weiteren Kontrollen (Identitätskontrolle, einmaliger Zugangscode) stattfinden, genügt der Besitz des Schlüssels um an fremde Inhalte zu kommen.

In [Kol02] werden zwei Typen von Sessionsystemen beschrieben:

  • permissiv
  • strikt

Permissive Systeme sind solche, die jeden beliebigen Sessionschlüssel akzeptieren und für die laufende Sitzung verwenden. Dabei spielt es keine Rolle, ob dieser bestimmten Sicherheitsanforderungen genügt1 oder ursprünglich auf dem Server auf dem er verwendet wird, generiert wurde.

Die Session-Fixation macht sich die permissive Eigenschaft der Sessionverwaltung in PHP zunutze. Findet diese einen alten Sessionschlüssel in der Kommunikation mit dem Client, so wird dieser als neuer Schlüssel akzeptiert, anstatt einen neuen zu generieren2. Gelingt es also dem Angreifer, dem Nutzer seinen Schlüssel zu übertragen, so kann er mit demselben Schlüssel ebenfalls auf die Nutzerdaten zugreifen. Dabei kann der fremde Schlüssel in einem Link, einem Formular oder Cookie versteckt sein [Kol02, S. 5]. In manchen Fällen ist ein vorgelagerter XSS-Angriff notwendig um den vorbereiteten Sessionschlüssel beispielsweise direkt im Cookie des Opfers einzufügen.

Die offizielle Dokumentation zur PHP-Sessionverwaltung [PHPf] verwendet zur Veranschaulichung der Funktionsweise der Session folgendes Beispiel:

Abbildung 23: Codebeispiel der Sessionverwaltung in der offiziellen PHP-Dokumentation

Wird dieser Code aufgerufen, so startet die Funktion session_start() eine neue Sitzung und erzeugt einen eindeutigen Sitzungsschlüssel. Dieser wird als Cookie im Browser gespeichert.

Tabelle 1: Inhalt des Session-Cookies im Browser der Nutzer

Diese Daten sind jedem zugänglich, der ein Cookie von der betroffenen Seite empfängt. Dabei ist der Inhalt des Cookies der eigene Sitzungsschlüssel, der den Nutzer eindeutig identifiziert.

Angriffsvektor


Abbildung 25: Session-Fixation-Angriff. Quelle: eigene Darstellung.

  1. Der Angreifer ruft die Anwendung als anonymer Nutzer auf.
  2. Für die neue Session wird ein Cookie mit einer Sessionkennung erzeugt (123).
  3. Das Cookie mit der Sessionkennung wird dem Angreifer gesendet.
  4. Der Angreifer entnimmt dem Cookie die Kennung und gestaltet damit einen speziellen Link. Diesen lässt er dem Opfer zukommen.
  5. Das Opfer verwendet den Link, um zur Anwendung zu gelangen. Dabei meldet es sich mit seinen Daten an.
  6. Die Anwendung akzeptiert die Sessionkennung (123) und ordnet diese dem korrekt angemeldeten Nutzer „Müller“ zu.
  7. Auch der legitimierte Nutzer bekommt ein Cookie zugeschickt.
  8. Der Angreifer kann jetzt mit seinem eigenen Cookie die Anwendung aufrufen.
  9. Da in der Zwischenzeit die Sessionkennung (123) des Angreifers dem Nutzer „Müller“ zugeordnet wurde, wird der Angreifer mit dieser Kennung als Nutzer „Müller“ von der Anwendung akzeptiert werden.

Der Angriff auf eine Webanwendung, die sich ausschließlich auf den gültigen Schlüssel verlässt, kann stattfinden durch:

  • Link / Formular und
  • Cookie-Änderung.

Das Setzen des Sitzungsschlüssels über Links oder Formulare bleibt ohne Auswirkung, wenn das Opfer bereits ein gültiges Cookie der Zielseite besitzt. Um den im Cookie gespeicherten Sitzungsschlüssel zu ändern, braucht der Angreifer eine XSS-Lücke in der Zielanwendung. Dann muss er das Opfer dazu verleiten, über einen präparierten Link oder Formular den Skriptcode in der Seite aufzurufen [Kol02].

Abbildung 26: Code zum Ändern des Cookie-Sitzungsschlüssels

Beide Beispiele ändern erfolgreich ein bereits gesetztes Cookie. Dabei ist der Aufruf in b) besonders heikel, denn er umgeht eine etwaige Filterung nach dem typischen XSS-Angriffs-Muster: „<script>“.


1.4.4 Session Hijack

Dieser Angriff beschreibt das Kopieren des Sitzungsschlüssels eines Nutzers durch den Angreifer. Dies kann geschehen durch:

  • Mitlesen des Netzwerkverkehrs,
  • Auslesen des Sitzungsschlüssels aus der Webseite und
  • Auslesen des Sitzungsschlüssels aus der Sessionverwaltung.

Gegen ein Auslesen des Schlüssels aus dem Netzwerkverkehr hilft das Verwenden einer sicheren HTTP-Verbindung zwischen Client und Server (HTTPS).

Die einfachste und daher häufigste Angriffsart besteht darin, den Sitzungsschlüssel aus dem Cookie des Nutzers oder aus der betroffenen Webseite auszulesen. Voraussetzung dafür ist, dass zuvor ein erfolgreicher XSS-Angriff stattgefunden hat. Dabei fügt der Angreifer Skriptcode in die Seite ein, der beim Aufruf durch einen Nutzer dessen Cookie ausliest und die Daten an einen fremden Server sendet. Mit diesen Daten kann der Angreifer auf seinem Browser eine Kopie des Cookies erstellen und erlangt so die Identität und die Privilegien des angegriffenen Nutzers.

Abbildung 27: XSS-Code um den Cookie an einen Fremdserver zu senden

1.4.5 cookie replay attack

Hierbei handelt es sich um die Wiederverwendung eines gestohlenen Identifikations-Cookies. Dieser Angriff wird dadurch ermöglicht, weil einige Webanwendungen die Sitzungsdaten länger speichern, als der Nutzer diese tatsächlich verwendet. Auch nach dem Abmelden des Nutzers bei einer Webseite wird oft nur der Identifikations-Cookie des Nutzers gelöscht, nicht jedoch die dazugehörige Sitzung auf dem Server. Ein Angreifer kann so auf die in der Sitzung gespeicherten Daten zugreifen oder die Identität des Opfers annehmen.


1.4.6 Session Riding oder CSRF (Cross Site Request Forgery)

Dieser Angriff nutzt das Vertrauen einer Webanwendung gegenüber einem authentifizierten Nutzer aus. Bei den meisten Webanwendungen genügt eine einmalige Authentifizierung mit Nutzername und Passwort, um diesem Nutzer je nach seinen Rechten, weitergehende Aktionen zu erlauben. Der CSRF-Angriff nutzt diese Authentifizierung aus, indem er im Namen des Nutzers und mit seinen Privilegien eigene Befehle an die Anwendung absetzt.

Anhand der folgenden Abbildung soll ein solcher Angriff analysiert werden.

Abbildung 28: CSRF-Angriff. Quelle: eigene Darstellung.

  1. Der Nutzer ruft eine Webanwendung auf und authentifiziert sich.
  2. Es wird ein Cookie mit dem Sessionschlüssel zur Identifizierung erstellt.
  3. Der Cookie wird dem Nutzer gesendet und bei diesem abgespeichert.
  4. Der Nutzer besucht anschließend unwissentlich einen kompromittierten Server.
  5. Die Antworten des Servers enthalten ein unsichtbares Element innerhalb der Seite.
  6. Eine manipulierte Webseite wird dem Nutzer geschickt.
  7. Beim Anzeigen der manipulierten Seite wird das unsichtbare Element darin aktiv.
  8. Ein für den Nutzer unsichtbarer Befehl geht an den Bankserver und mit ihm automatisch auch der aktuelle, gültige Zugangs-Cookie des Nutzers. Damit hält der Bankserver den Befehl für authentifiziert und legitimiert und führt ihn aus.

Chris Shiflett [Shi07] demonstrierte in März 2007 eine SCRF-Schwachstelle in Amazons „1-Click“- Kaufsystem. Ein angemeldeter Amazon-Kunde der eine spezielle Beispielseite besuchte, hatte dann unerwartet Chris’ Buch3 in dem digitalen Einkaufswagen. Über ein Jahr nach der Bekanntmachung der Lücke war diese von Amazon noch nicht geschlossen worden.




Fußnoten

  1. „Anforderungen an eine SessionID“ [BSI01, Kap. M210]
  2. In der PHP-Konfiguration muss dazu die Einstellung "session.use_trans_sid" eingeschaltet sein.
  3. Vergleiche: [Shi04]

Literaturverzeichnis

[Kol02] Kolšek, Mitja
„Session Fixation Vulnerability in Web-based Applications“
http://www.acros.si/papers/session_fixation.pdf
[letzter Besuch: 08.02.2008]
Dezember 2002
[PHPf] PHP- Manual
„Sessions“
http://de.php.net/session
[letzter Besuch: 08.02.2008]
[Shi07] Shiflett, Chris
„My Amazon Anniversary“
http://shiflett.org/blog/2007/mar/my-amazon-anniversary
[letzter Besuch: 08.02.2008]
2007
[BSI01] „Sicherheit von Webanwendungen, Maßnahmenkatalog und Best Practices“
http://www.bsi.de/literat/studien/websec/WebSec.pdf
[letzter Besuch: 26.02.2008]
2001
[RFC2616] Fielding, R.; UC Irvine; Gettys, J.; Compaq/W3C; Mogul, J.; Compaq; Frystyk, H.; W3C/MIT; Masinter, L.; Xerox; Leach, P.; Microsoft; Berners-Lee, T.
„Hypertext Transfer Protocol -- HTTP/1.1“
http://www.ietf.org/rfc/rfc2616.txt
[letzter Besuch: 26.02.2008]
1999


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

Tags: , , , , , ,

Mail-Header Injection - eine Analyse an PHP

Freitag, September 5th, 2008 | PHP, Schwachstellenanalyse, Sicherheit, sseq-lib | 2 Kommentare

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




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 Mailserver1 schickt.


1.3.1 Gefahreneinschätzung

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

  • Spamer3 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 lists4 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 Manipulation5. 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 feed6 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)7,
  • Bcc (Black Carbon Copy)8.

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ügt9. 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-Body10:



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 erzeugen11. 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 Ende12. 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 dargestellt13:




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

Tags: , , , , , ,

Search

RSS Mister Wong Blogroll

  • Ein Fehler ist aufgetaucht - der Feed funktioniert zurzeit nicht. Probiere es später noch einmal.