Dipl.-Inform. Carsten Eilers

Einige Angriffe auf Logikfehler haben haben Sumit Siddharth und Richard Dean auf der Black Hat Abu Dhabi 2012 vorgestellt. Weitere Untersuchungen gab es zum Beispiel von David Byrne und Charles Henderson, die ihre Ergebnisse auf der OWASP AppSec DC 2012 präsentiert haben (Präsentation als PDF), und Marcus Pinto, der seine Ergebnisse auf der OWASP AppSec Ireland 2012 vorgetragen hat.

Was sind Logikfehler?

Beim Auftreten eines Logikfehlers verhält sich die Anwendung in einem bestimmten Status anders, als eigentlich erwartet wird. Evtl. kann der Arbeitsfluss manipuliert und zum Beispiel ein eigentlich notwendiger Schritt übersprungen werden. Solche Schwachstellen entstehen meist, weil bei der Entwicklung mögliche externe Einflüsse (und insbesondere keine absichtlichen, bösartigen Manipulationen) auf den Ausführungspfad nicht oder nicht ausreichend berücksichtigt wurden.

Ein klassisches Beispiel ist ein Bestellvorgang, bei dem der Preis der Ware manipuliert werden kann. Es ist normal, dass der Server den Preis an den Client sendet, er muss dem Kunden ja angezeigt werden. Wird er bei der Bestellung aber als versteckter Parameter zurück an den Server übertragen, ist das verdächtig. Wieso sollte der Client dem Server den Preis mitteilen, den der doch kennt? Manchmal wird dann ein geänderter Preis vom Server übernommen. Wenn die Waren dann ohne weitere Prüfung ausgeliefert werden, kann das für den Shopbetreiber teuer werden.

Da für die Erkennung von Logikfehlern das Verständnis der Anwendung nötig ist, lassen sie sich mit automatisierten Tools im Allgemeinen nicht erkennen. Kein noch so aufwendig programmiertes Tool kann erkennen, ob ein Schritt in einem Arbeitsablauf übersprungen werden kann/darf oder nicht. Logikfehler können daher nur durch manuelle Tests gefunden werden. Und da dabei alle Schritte zumindest aller potentiell gefährlichen Arbeitsabläufe meist mehrmals durchlaufen werden müssen, ist das aufwendig und fehleranfällig.

Beispiele für Angriffe

Sumit Siddharth und Richard Dean haben einige Beispiele vorgeführt:

Beispiel 1: Onlinebanking mit Authentifizierung in 2 Schritten

Im ersten Authentifizierungsschritt werden Benutzer-ID und Passwort abgefragt, im zweiten Schritt drei Zeichen aus einer längeren "memorable information", also einer leicht zu merkenden Information. Im Beispiel werden das 1., 3. und 4. Zeichen verwendet, wobei es sich anscheinend immer um Ziffern handelt, wie die Fortsetzung des Beispiels verrät.

Es wird niemals die gesamte "memorable information" abgefragt, so dass die nicht in fremde Hände fallen kann. Theoretisch, denn wie die Vergangenheit gezeigt hat, gibt es Leute, die mal eben 20 TANs ihrer iTAN-Liste auf einer Phishing-Seite eingeben, und die würden sicher auch die komplette "memorable information" irgendwo eingeben, wenn sie dazu aufgefordert werden. Aber das ist in diesem Fall nicht von Belang.

Schlägt die Überprüfung der im zweiten Schritt abgefragten Information fehl, wird die Eingabe in einer Fehlermeldung ausgegeben, damit der Benutzer sie korrigieren kann. Der Fehler dabei: Beim erneuten Versuch werden genau die gleichen Indizes wie beim ersten Mal abgefragt. Jetzt kommt es darauf an, ob der Server den Zugriff nach einer bestimmten Anzahl Fehlversuchen zum Schutz vor Brute-Force-Angriffen sperrt. Ist das der Fall, hat der Angreifer nur einige wenige Versuche, den korrekten Wert zu erraten. Gibt es keinen Brute-Force-Schutz, ist er nach spätestens 1000 Versuchen eingeloggt, da ja nur die Zahlen von 000 bis 999 durchprobiert werden müssen.

Gibt es einen Brute-Force-Schutz, kommen mögliche weitere Logikfehler zum Zuge: Was passiert, wenn die Indizes nicht geprüft und die vom Benutzer gelieferten Werte übernommen werden? Welcher Wert gehört zu nicht existierenden Indizes, zum Beispiel 7, 8 und 9 für eine 6-stellige PIN als "memorable information"?

Im Beispiel kann sich der Benutzer einloggen, indem er die Parameternamen von pinchar_1, pinchar_3 und pinchar_4 auf pinchar_7, pinchar_8 und pinchar_9 ändert und keinen Wert übergibt. Anscheinend vergleicht der Server die Werte an den Stellen 7, 8 und 9 der "memorable information" mit der Eingabe. Die Zeichen sind nicht vorhanden, die Eingabe ebenfalls nicht, und nach der Logik

"Nichts = Nichts" ist TRUE

ist die "PIN-Prüfung" erfolgreich.

Sumit Siddharth und Richard Dean haben die sehr einfache Schutzmaßnahme gegen diese Art von Schwachstellen so formuliert:

"It's a server side piece of knowledge, keep it server side"

Auf deutsch könnte man es als "Serverseitige Informationen müssen auf dem Server bleiben" formulieren. Im Beispiel sind die Indizes dem Server bekannt, es besteht keine Notwendigkeit, sie auch im Parameternamen aufzunehmen. Die Parameter könnten problemlos pinchar_1, pinchar_2 und pinchar_3 für das 1., 2. und 3. eingegebene Zeichen heißen, die Zuordnung zu den Indizes kann auf dem Server erfolgen. Denn dem ist ja bekannt, welcher Index für welchen Parameter bei der Abfrage der "PIN" verwendet wurde.

In der nächsten Folge geht es weiter um Logikfehler in Webanwendungen.

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