Dipl.-Inform. Carsten Eilers

Auch der folgende Fehler wurde von Marcus Pinto vorgestellt:

Beispiel 5: Kryptographie tritt auf Orakel

Eine Webanwendung verwendet zwei Cookies:

• RememberMe enthält das Authentifizierungstoken und besteht aus seinem Benutzernamen, seiner User-ID, seiner aktuellen IP-Adresse und zufälligen Daten (damit das Token nicht vorhersagbar ist). Der Cookie-Wert ist durch eine starke Verschlüsselung vor Manipulationen geschützt.
• ScreenName enthält den im Browser angezeigten "Screen Name" des Benutzers, der nicht zwingend mit dem Benutzernamen überein stimmen muss.

Nach einem Security Audit wird empfohlen, auch den ScreenName-Cookie zu verschlüsseln. Die Entwickler verwenden dafür die gleiche starke Verschlüsselung wie für den RememberMe-Cookie. Das ist zwar etwas übertrieben, aber sicher ist sicher. Bzw. in diesem Fall unsicher. Denn dadurch entstehen zwei Schwachstellen:

Ein "Encryption 'Reveal' Oracle"

Ein Angreifer kann den angezeigten Screen Name verwenden, um den RememberMe-Cookie zu entschlüsseln. Dazu muss er nur dessen Wert als Wert des ScreenName-Cookies an den Server senden, der ihn entschlüsselt und als Screen Name an den Angreifer zurück schickt. Der könnte zum Beispiel so aussehen:

fritz¦123¦217.93.197.11¦1301216856

Das ist zwar ein Informationsleck, aber noch keine wirklich schlimme Schwachstelle. Aber Sie wissen ja: Schlimmer geht immer!

Ein "Encryption 'Write' Oracle"

Die Benutzer können ihren Screen Name frei wählen. Was passiert, wenn ein Angreifer den Namen

admin¦1¦217.93.197.11¦1301216856

wählt? Nun, der Server verschlüsselt diesen Screen Name und speichert den Wert im ScreenName-Cookie. Und dieser Wert ist dummerweise auch ein gültiges Authentifizierungstoken. Der Angreifer muss diesen Wert nun nur noch als Wert seines RememberMe-Cookies an den Server senden, und der akzeptiert ihn als Administrator.

Beispiel 6: Einmal Escapen ist gut, doppelt Escapen ist schlecht

Ein weiteres Beispiel von Marcus Pinto, dass ich so ähnlich auch schon in einer Webanwendung gefunden habe (nur das es in meinem Fall um SQL-Abfragen ging - der Betroffene erinnert sich sicher mit Grausen daran, alle anderen brauchen es nicht zu wissen):

Eine Webanwendung führt Shellbefehle mit vom Benutzer gelieferten Daten aus. Damit darüber keine eigenen Befehle eingeschleust werden können, werden die Metazeichen der Shell durch einen vorgestellten Backslash escaped. Berücksichtigt werden die folgenden Zeichen:

; ¦ & < > ` Space Newline

Aus einer Eingabe wie zum Beispiel

irgendwas;whoami

wird durch das Einfügen des Backslash

irgendwas\;whoami

und damit funktioniert das vom Angreifer beabsichtigte aneinander reihen von Shell-Befehlen nicht. So weit, so gut. Ein Zeichen haben die Entwickler beim Escapen aber übersehen: Den Backslash selbst. Und dadurch wird die Eingabe

irgendwas\;whoami

zu

irgendwas\\;whoami

und das führt dazu, dass der von der Anwendung eingefügte Backslash vom bereits vorhandenen Escaped wird - das Semikolon des Angreifers aber stehen bleibt. Mit der Folge, dass das davon ausgelöste aneinander reihen von Befehlen erfolgt und der Befehl whoami ausgeführt wird.

Nachdem nun eine Reihe von Logikfehlern vorgestellt wurde, geht es in der nächsten Folge um die Frage, wie man solche Fehler entdeckt.

Carsten Eilers

Übersicht über alle Artikel zum Thema

Neue Angriffe auf Webanwendungen über Clickjacking und Cookies

Websecurity - XSS-Angriffe über XML

Websecurity - Angriffe über Logikfehler

Websecurity - Angriffe über Logikfehler, Teil 2

Websecurity - Logikfehler in der Authentifizierung

Websecurity - Logikfehler in der Authentifizierung und auf der Flucht

Websecurity - Logikfehler finden

Websecurity - Logikfehler vermeiden