Skip to content

Websecurity - Logikfehler in der Authentifizierung und auf der Flucht

Auch in dieser Folge geht es noch um Beispiele für Angriffe über Logikfehler in Webanwendungen, wie sie im Jahr 2012 zum Beispiel von Sumit Siddharth und Richard Dean, David Byrne und Charles Henderson (Paper als PDF) oder Marcus Pinto auf Sicherheitskonferenzen vorgestellt wurden.

Ein weiterer Fehler in der Authentifizierung

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

Trackbacks

Dipl.-Inform. Carsten Eilers am : Drucksache: Entwickler Magazin 2.2014 - Die OWASP Top 10, Teil 1

Vorschau anzeigen
Im Entwickler Magazin 2.2014 ist der erste Teil eines zweiteiligen Artikels über die OWASP Top 10, die zehn gefährlichsten Schwachstellen in Webanwendungen, erschienen. Die Reihenfolge der Schwachstellen ergibt sich aus vier Faktoren

entwickler.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 18

Vorschau anzeigen
Weiter geht es mit der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP. Zur Zeit sind wir beim Punkt 2: &quot;Insufficient Authentication/Authorization&quot;. Die ve

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Noch keine Kommentare

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Formular-Optionen

Kommentare werden erst nach redaktioneller Prüfung freigeschaltet!