Archive for September, 2008

Wir brauchen "Free Security Audit"!

Donnerstag, September 11th, 2008 | PHP, Sicherheit, sseq-lib | 1 Kommentar

Stefan Esser, dessen Arbeit ich mit Interesse verfolge, hilft, Sicherheitsschwachstellen in PHP zu entdecken und zu beheben. Darüberhinaus entwickelt er einen PHP-Patch mit Namen Suhosin, der den PHP-Code selbst von bekannten Schwachstellen befreien soll.

Stefan kommentiert in seinem Blog die Anfrage von den Machern von TikiWiki zwecks eines Security Audits, also einer Prüfung auf Schwachstellen in der Software. Diese hatten ihn - und offenbar noch weitere Sicherheitsexperten - in eine Rundmail angeschrieben und um eine - kostenlose - Überprüfung der aktuellen Wiki-Software geworben. Ich möchte ich nicht auf die Beweggründe eingehen, warum er letztendlich dieser Anfrage nicht nachging und nicht half.

Jedem Webentwickler "sein Stefan Esser"

Bei mir warf diese Geschichte die Frage auf, ob jedes Open-Source-Projekt einen Security Auditor von Stefans Kaliber braucht. Und wenn ja, warum? Gibt es keinen Mittelweg zwischen "scripten ohne Sicherheitskenntnisse" und "security Experte"? Denn nicht jedem Entwickler steht "ein Stefan" zur Seite, auch wenn es wünschenswert wäre.

Was ist zu tun? Sollten alle Hoster verpflichtet werden Web Firewalls, neueste PHP-Versionen und den Suhosin-Patch einzusetzen? Sollten alle Webentwickler zu Sicherheitsschulungen gezwungen werden?

Wie Websicherheit aussehen könnte

Vornweg: Frameworks helfen nicht, denn sie erfordern gerade soviel Wissen um ihrer Verwendung, dass die meisten Webentwickler die zusätzliche Einarbeitung scheuen nicht darauf aufsetzen.

Ich denke, der richtige Weg wäre, jedem Webentwickler ein wenig entgegen zu kommen, so dass er sich nicht zwingend neues Wissen aneignen (und dann aktuell halten) muss um eine Grundsicherheit seiner Software zu erreichen und auch nicht auf externe Hilfe z.B. der Hoster bei der Installation neuester Software angewiesen ist.

Die Lösung wäre meiner Meinung nach eine frei verfügbare Sammlung von Funktionen, die mit einem einzigen "include_once" in jedem PHP-Skript eingebunden wird und frei von Abhängigkeiten ist, so dass sie sowohl in einfache 10-Zeilen-Skripte als auch in komplexe Frameworks eingesetzt werden kann. Die Installation sollte mit dem Entpacken weniger Dateien auf dem Server auch schon getan sein.

Die dann zur Verfügung stehenden Funktionen sollten zumindest effektiv einige der Top-10 - Angriffe abwehren oder den Angriff erschweren können und so einfach zu verwenden sein, dass sie ohne weiteres in laufende Projekte eingebunden werden können.

Kennt jemand eine solch einfach einzubindende aber wirkungsvolle Bibliothek? (Das direkte Produkt dieser Überlegung, die SSEQ-LIB braucht hier nicht genannt werden. Ich suche tatsächlich ähnliche Projekte.)

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: , , , , , ,

stripslashes() schleust XSS-Angriffe am Filter des Internet Explorer 8 vorbei

Dienstag, September 2nd, 2008 | PHP, Sicherheit, sseq-lib | 5 Kommentare

Der Microsoft Internet Explorer 8 ist in eine Beta-Version bereits verfügbar und bringt einige Neuerungen mit, unter anderem einen XSS (Cross Site Scripting)-Filter.

Außer der Tatsache, dass der Filter nicht alle im Umlauf befindlichen XSS-Angriffe abwehren können wird, was den Entwicklern bei Microsoft auch klar ist, gibt es einfache Methoden um sogar triviale Angriffe am Filter vorbei zu schleusen.

Interessanter Weise betrifft die gezeigte Methode vor allem PHP-Applikationen, denn sie geht von der Verwendung von "stripslashes()" bei der Verarbeitung von Nutzereingaben aus. Wie oft diese Funktion tatsächlich pauschal auf Eingabedaten verwendet wird - ob nötig oder nicht - lässt sich erahnen, wenn man nach dem klassischen Problem mit den doppelt "escapten" Eingaben im Netz sucht:

Bei PHP.NET findet man direkt die erste Anleitung, um die doppelten Slashes zu entfernen:


<?php
function stripslashes_if_gpc_magic_quotes$string ) {
    if(
get_magic_quotes_gpc()) {
        return 
stripslashes($string);
    } else {
        return 
$string;
    }
}
?>


Oder wie wäre es, alle Eingangskanäle zu stripslash-en??


<?
if (get_magic_quotes_gpc() == 1) {
    function 
stripslashes_deep($value) {
        
$value is_array($value) ? array_map('stripslashes_deep'$value) : stripslashes($value);
        return 
$value;
    }
    
$_POST array_map('stripslashes_deep'$_POST);
    
$_GET array_map('stripslashes_deep'$_GET);
    
$_COOKIE array_map('stripslashes_deep'$_COOKIE);
    
$_REQUEST array_map('stripslashes_deep'$_REQUEST);
}
?> 


In beiden (und ähnlichen) Fällen sind alle glücklich, bis auf die armen Nutzer oder Anwendungen, die Pfade verarbeiten wollen ("bilder\bild.jpg") oder sowas wie "DOMAIN\user". Darüberhinaus trickst diese pauschale Löschung der Slashes die XSS-Prüfung des IE8 aus. Wie das geht, ist hier zu lesen. Hier sei die Methode an einem Beispiel dargestellt:

Der XSS-Filter des IE8 reagiert auf typische Angriffsmuster:
index.php?name=<script>alert('XSS');</script>
Typischer Angriffs- oder Testvektor

Maskiert man die Buchstaben mit Backslashes, erkennt der IE solche Worte wie "script" und "alert" nicht mehr:


index.php?name=<s\cr\ip\t>al\er\t('XSS');</s\cr\ip\t>
Mit Backslashes unkenntlich gemachter Angriffs- oder Testvektor

Filtert die Webanwendung nun alle Eingaben mit stripslashes() durch, so entsteht wieder der Angriffsvektor und zwar hinter der "Verteidigungslinie" des Internet Explorer.


index.php?name=<script>alert('XSS');</script>
Angriffs- oder Testvektor nach dem Behandeln mit stripslashes()

PS: Die SSEQ-LIB-Funktion "seq_remove_slashes_" ist von dieser Schwachstelle nicht betroffen, da hier nur Slashes entfernt werden, die tatsächlich ein Sonderzeichen maskieren.

Tags: , , , , ,

Search