schwachstelle

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

SQL-Injections - eine Analyse an PHP & MySQL [UPDATE]

Samstag, August 30th, 2008 | PHP, Schwachstellenanalyse, Sicherheit | 3 Kommentare

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


SQL-Injection-Angriffe beschreiben das Injizieren von SQL-Code [Wika] in eine Anwendung, sodass dieser von der Datenbank ausgeführt wird. Das geschieht typischerweise durch eine entsprechend manipulierte Nutzereingabe. Wird diese ungeprüft in eine SQL-Abfrage eingefügt, so können enthaltene SQL-Befehle die Datenbank in nicht vorhergesehener Weise manipulieren.

3.2.1 Gefahreneinschätzung

Dynamische PHP-Anwendungen beziehen ihre Daten meist aus zwei Quellen:

  • Dateisystem und
  • Datenbanken.

Die Verwendung von Daten aus Dateien ist für SQL-Angriffe nicht anfällig und wird hier nicht weiter behandelt. Setzt die Anwendung allerdings auf eine Datenbank zur Datenverwaltung, so kann je nach Anwendungsfall beispielsweise folgendes durch einen erfolgreichen SQL-Angriff erreicht werden:

  • Hinzufügen, Ändern, Löschen von Datensätzen, Tabellen, Datenbanken,
  • Auslesen und Stehlen von Datensätzen und
  • Erzeugen von Dateien auf dem Dateisystem der Anwendung.

Durch das Hinzufügen oder Ändern von Datensätzen in einer Tabelle mit Zugangsdaten für eine Webanwendung kann sich der Angreifer selbst gehobene Rechte selbst zuweisen oder den bestehenden Nutzern Rechte entziehen. Ist es dem Angreifer möglich, Dateien zu erzeugen, so kann er gezielt Webseiten in der Anwendung ersetzen und so Nutzer oder Systemdaten ausspionieren.

3.2.2 Angriffsvektoren

Auch bei dieser Angriffsart dringt der Schadcode durch die Nutzereingabe in die Anwendung ein. Dabei versucht der Angreifer eigenen SQL-Code in vorhandene Datenbankabfragen einzufügen und so neue SQL-Befehle zu erzeugen. Es werden dabei typische Programmcode-Schwächen ausgenutzt, die teils durch die Programmiersprache PHP gegeben sind und teils durch weit verbreitete, unvollständige Programmieranleitungen in der Literatur und im Internet vorgegeben werden. Dabei entstehen die Schwachstellen hauptsächlich aus Fehlern in der Programmierung:

  • Werteübergabe ohne umschließende Hochkommas,
  • eine fehlende Typenprüfung der Werte,
  • eine fehlende Längenprüfung der Werte und
  • die fehlende Maskierung von Sonderzeichen.

Der eingeschleuste SQL-Code kann vom Angreifer auch derart platziert werden, dass er seine Wirkung zeitverzögert entfaltet. Ein Angriffsbeispiel auf eine Anwendung, die eine Liste der Nutzernamen erstellt, könnte wie folgt aussehen: ein Angreifer könnte den Nutzernamen manipulieren, sodass dieser zusätzlich SQL-Code führt. Verwendet die Anwendung den Nutzernamen innerhalb einer ungesicherten SQL-Abfrage, so wird der Code eingefügt und ausgeführt. Das Besondere an einem solchen Angriff ist demnach, dass der Augenblick der Infizierung der Anwendung meist in zeitlicher Entfernung von deren Ausführung liegt. Darüber hinaus zielt der Angriff auf keinen bestimmten Nutzer sondern kann potentiell von jedem zur Ausführung gebracht werden.

Der kompromittierende SQL-Code kann dabei aus unterschiedlichen Quellen stammen:

  • Nutzereingaben,
  • Cookie-Werten,
  • Session-Werten und
  • anderen Datenbank-Daten.

3.2.3 Angriffsformen

Der Angreifer versucht bestehende SQL-Anfragen durch geeignete, eigene SQL-Abfragen zu ändern. Durch das Einfügen geeigneter SQL-Befehle kann er:

  • Logische Verknüpfungen ändern,
  • Teilabfragen entfernen,
  • zusätzliche Abfragen erzeugen,
  • den Datenbankprozess beeinflussen und
  • verräterische Fehlermeldungen erzeugen.

Logische Verknüpfungen ändern



Abbildung 13: Ein für SQL-Angriffe anfälliges Skript

Dieser Code nimmt die Daten einer Eingabemaske mit "Nutzername" und "Passwort" entgegen und prüft in einer Datenbank nach dem Vorkommen dieser Kombination. Wird der Nutzer gefunden und passt das angegebene Passwort, so ist der Nutzer legitimiert.

Die Datenbankabfrage besteht aus einem festen Teil (SELECT * FROM users WHERE user='' AND password='') und aus zwei Variablen, die eingesetzt werden. Das funktioniert solange wie beabsichtigt, bis ein Angreifer folgende Eingaben macht:



Die Abfrage, die an MySQL übermittelt wird lautet nach der Injizierung des Schadcodes1 :



Diese neu entstandene SQL-Abfrage wird von MySQL logisch ausgewertet. Dabei wird zuerst die OR-Verknüpfung ausgeführt und anschließend die AND-Verknüpfung. Es ergibt sich folgende SQL-Abfrage:



Das Ergebnis der OR-Verknüpfung ist WAHR, denn 'a'='a' ist WAHR. Es ergibt sich:



Die Abfrage lautet also:



Sie ist WAHR, sofern ein Nutzer „admin“ existiert und sie liefert dessen Datensatz. Da meist im folgenden PHP-Code nur noch geprüft wird, ob die Datenbank als Antwort NULL (Nutzer oder Passwort sind falsch.) oder aber einen Datensatz (Nutzer und Passwort sind gültig.) zurückgibt, ist der Angreifer, auch ohne ein gültiges Passwort, authentifiziert.


Teilabfragen entfernen

Teile der SQL-Abfrage können durch Einfügen von Kommentarzeichen sogar komplett aus der Ausführung entfernt werden.


Abbildung 14: Abfrage von Pressenachrichten

Diese Abfrage zeigt auf der Webseite eines Unternehmens aktuelle Pressenachrichten an. Dabei können von einer Redaktion bereits fertiggestellte Meldungen für den Webseitenbesucher unsichtbar bleiben, bis sie beispielsweise nach Absprache mit der PR-Abteilung werbewirksam freigegeben werden. Dazu wird jeder Datensatz in der Datenbank mit der Eigenschaft „freigabe“ belegt. Durch die in Abbildung 14 gezeigte SQL-Abfrage wird sichergestellt, dass nur freigegebene Nachrichten sichtbar sind. Darüber hinaus hat der Nutzer die Möglichkeit, sich über ein Auswahlmenü nur Pressemeldungen eines gewünschten Datums anzeigen zu lassen.


Abbildung 15: Auswahlmenü des Datums in HTML

Ein Angreifer könnte versuchen, andere Werte als in dem Auswahlmenü vorgegeben an das Skript zu senden. Falls er bereits vermutet, dass die Datumsangaben direkt in eine SQL-Abfrage eingefügt werden, könnte er folgende Anfrage an das Skript senden:



Wird das Datum ungeprüft übernommen, ändert sich durch diese Eingabe die Datenbankabfrage wie folgt:


Abbildung 16: SQL-Teilabfrage mit Injizierung im „datum“-Feld

Die Zeichengruppe (/*) bedeutet in der MySQL-Syntax einen Kommentar-Anfang. Daher wird der folgende SQL-Code nicht weiter beachtet. Es ergibt sich aus der Sicht des Datenbankservers die Abfrage:



Damit wurde der Parameter „freigabe“ aus der ursprünglichen SQL-Abfrage entfernt. Somit hat ein neugieriger Nutzer Zugriff auf Pressemeldungen, die noch nicht für die Öffentlichkeit bestimmt waren. Bei brisanten Meldungen kann eine solche unbeabsichtigte Enthüllung etwaigen Konkurrenten einen Vorsprung geben.


Zusätzliche Abfragen

Die MySQL-Datenbank unterstützt nativ keine multiple queries. Das heißt, dass eine abgesetzte Datenbank-Abfrage eine einzige Aktion ausführen kann. Jedoch unterstützt MySQL das SQL-Kommando UNION [MySb], mit dem sich, über die ursprüngliche Abfrage hinaus, zusätzliche Datensätze der Antwort hinzufügen lassen. Dazu muss der Angreifer die ursprüngliche Struktur der Datenbank näher kennen. Ist die angegriffene Anwendung frei verfügbar, so kann er den SQL-Code analysieren. Ansonsten versucht er sich diese Informationen über einen Umweg zu beschaffen.


Abbildung 17: SQL-Abfrage für Pressenachrichten

Je nach eingegebener Kennung ($id) wird bei der regulären Verwendung die jeweilige Pressemeldung angezeigt. Ein Angreifer kann mit einem UNION-Befehl die MySQL-eigene Nutzertabelle auslesen, da diese in Standard-MySQL-Installationen leicht zu erraten ist. Dazu gibt er als Wert der Kennung ($id) folgende SQL-Abfrage ein:



Wird dieser Wert ungefiltert übernommen, so entsteht folgende Abfrage :



Diese zeigt zwar keine Pressemeldungen an, dafür aber die Liste der Datenbanknutzer, inklusive der kodierten Passwörter. Mit Hilfe einer „Rainbow-Table“2 lassen sich manche Passwörter wieder nach Klartext umwandeln.

Datenbankprozess beeinflussen

MySQL bietet mit dem Befehl BENCHMARK die Möglichkeit zu ermitteln, wie schnell eine SQL-Anfrage ausgeführt wird [MySa]. Dazu wird eine zu testende Abfrage bestimmte Male wiederholt. Je nach auszuführender Testanfrage ist der MySQL-Server mehr oder weniger mit dieser Aufgabe beschäftigt. Diese Eigenschaft kann sich ein Angreifer zunutze machen, um den Server fast vollständig durch eine sinnlose aber rechenintensive Aufgabe zum Erliegen zu bringen.


Abbildung 18: SQL-Abfrage für Pressenachrichten

Der Angreifer injiziert folgenden Code:

Es entsteht aus der Sicht des Datenbankservers die Abfrage3:



Zu der ersten SELECT-Anfrage fügt der Angreifer eine UNION-Anfrage an. Diese ist jedoch nicht dazu bestimmt, zusätzliche Daten aus der Datenbank zu lesen, sondern allein um einen BENCHMARK-Befehl abzusetzen. Dieser ist angewiesen, eine Million Mal den MD54-Hash des Zeichens „A“ zu erstellen. Durch die Rechenzeit, die das tausendmalige Erzeugen eines MD5-Hashes in Anspruch nimmt, ist der MySQL-Server unter Umständen nicht mehr für andere Nutzer oder Prozesse verfügbar. Startet der Angreifer mehrere solche Angriffe zeitgleich, kann es zum kompletten Stillstand des Datenbankservers kommen. Zwar gelangen durch diesen Angriff keine Daten nach Außen, jedoch wird die Funktionalität derart beeinträchtigt, dass durch die Nichtverfügbarkeit des Servers resultierende Ausfälle durchaus beträchtliche Schäden verursachen können.



Fußnoten

  1. Es wird vorausgesetzt, dass die PHP-Einstellung „magic_quotes_gpc“ ausgeschaltet ist.
  2. Es wird vorausgesetzt, dass die PHP-Einstellung "magic_quotes_gpc" ausgeschaltet ist.
  3. "Rainbow-Tabelle" sind Listen oft verwendeter Passwörter und der dazugehörigen Kodierungen nach mehreren Methoden. Ein kodiertes Passwort kann damit abgeglichen werden, um das Passwort in Klartext zu gewinnen. [Wikb]
  4. MD5 ist eine kryptographische Hashfunktion. [Wikd]

Literaturverzeichnis

[Wika] Wikipedia
„SQL“
http://de.wikipedia.org/wiki/SQL
[letzter Besuch: 20.02.2008]
[MySa] MySQL 5.1 Referenzhandbuch
„Informationsfunktionen“
http://dev.mysql.com/doc/refman/5.1/de/information-functions.html
[letzter Besuch: 26.02.2008]
[MySb] MySQL 5.1 Referenzhandbuch
„UNION“
http://dev.mysql.com/doc/refman/5.1/de/union.html
[letzter Besuch: 26.02.2008]
[Wikb] Wikipedia
„Rainbow Table“
http://de.wikipedia.org/wiki/Rainbow_Table
[letzter Besuch: 25.02.2008]
[Wikd] Wikipedia
„Message-Digest Algorithm 5“
http://de.wikipedia.org/wiki/Message-Digest_Algorithm_5
[letzter Besuch: 29.03.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