Unter der Annahme, dass der Server Maßnahmen basierend auf einer bestimmten Bedingung ergreift, analysieren wir die Situation, in der der Server Berechnungen abhängig vom Ergebnis dieser Bedingung durchführt und dann die Antwort an den Benutzer übermittelt. In beiden Fällen, ob die Berechnungen durchgeführt werden oder nicht, gibt der Server eine Antwort an den Benutzer zurück. Es ist bemerkenswert, dass, wenn der Server Berechnungen durchführt, er eine bestimmte Menge an Ressourcen verbraucht, was zu einer Verlängerung der Serverantwortzeit führt. Im Allgemeinen sind diese Unterschiede in den Antwortzeiten so gering, dass sie für den Endbenutzer nicht wahrnehmbar sind. Dennoch kann das Offenlegen dieser subtilen Unterschiede in den Antwortzeiten zu unbeabsichtigten Datenlecks führen.
Betrachten wir nun ein praktisches Beispiel für diese Situation, das auf dem Anmeldeprozess einer Anwendung basiert. Angenommen, der angegebene Login-Name ist korrekt, aber das Passwort ist falsch: In diesem Fall kann der Server entscheiden, Berechnungen durchzuführen, z.B. die Passwortüberprüfung. Wenn der Server diese Berechnungen durchführt, kann dies zusätzliche Ressourcen erfordern und zu längeren Antwortzeiten im Vergleich zu dem Fall führen, in dem keine Berechnungen durchgeführt werden. Obwohl die Unterschiede in den Antwortzeiten normalerweise gering sind, sind sie vorhanden und können von einem Angreifer gemessen werden.
Der gleiche Prozess, aber wenn auch der Login-Name falsch ist:
Im Falle solcher subtilen Unterschiede in den Antwortzeiten kann ein Angreifer versuchen, diese Informationen zu nutzen, um Rückschlüsse auf die Richtigkeit der Anmeldung zu ziehen. Beispielsweise könnte ein Angreifer einen Timing-Angriff durchführen, indem er die Zeit analysiert, die der Server benötigt, um auf Anfragen mit verschiedenen Logins zu antworten. Durch den Vergleich der Antwortzeiten kann der Angreifer erkennen, welche Anfrage mehr Zeit in Anspruch genommen hat, was darauf hindeutet, dass der Login korrekt war. Die Offenlegung des Benutzer-Logins ermöglicht es Angreifern, eine Brute-Force-Attacke auf das Passwort durchzuführen. In einigen Fällen kann dies auch die Offenlegung sensibler Informationen bedeuten, insbesondere wenn der Login eine E-Mail-Adresse ist, die einer bestimmten Person zugeordnet ist, und die getestete Anwendung ein Portal mit kontroversen Inhalten ist.
Testen mit Burp Suite – Request Timer
Bei der Suche nach dieser Art von Verwundbarkeit ist ein Plugin für Burp namens Request Timer hilfreich. Dieses Plugin ermöglicht es uns, die Antwortzeit des Servers für von uns festgelegte Anfragen zu untersuchen.
Der erste Schritt besteht darin, die Anfrage abzufangen, die für den Benutzeranmeldevorgang verantwortlich ist, und sie an das Modul Intruder zu senden:
Als nächstes ändern wir das Passwort in eine lange Zeichenkette, um die Serverlast beim Generieren des Passwort-Hashes zu erhöhen. Wir geben die Stelle an, an der sich der Benutzerlogin befindet. Bei der getesteten Anwendung ist es ebenfalls notwendig, den Header „X-Forwarded-For“ hinzuzufügen und ihm eine zufällige IP-Adresse zuzuweisen, um das Sperren mehrerer Login-Versuche von derselben IP-Adresse zu umgehen. Daher müssen wir den Angriffstyp auf „Pitchfork“ ändern.
Wir fügen eine Liste von Logins hinzu, die geprüft werden sollen:
Im Plugin Request Timer definieren wir, dass es auf das Intruder-Modul hören soll:
Nach dem Starten des Tests erscheinen im Tab die generierten Anfragen zusammen mit der Antwortzeit. Wie man sehen kann, ist die Antwortzeit für den korrekten Login deutlich länger. Dadurch haben wir bewiesen, dass die Anwendung anfällig für Benutzer-Login-Enumeration ist, indem die Antwortzeit des Servers analysiert wird.
Was tun, wie leben?
Eine Lösung für dieses Problem ist das Hinzufügen einer Funktion, die für das zufällige Verzögern der Serverantwort verantwortlich ist:
Allerdings besteht bei dieser Lösung das Problem, dass wir immer noch keine Kontrolle über Situationen wie Netzwerkverlangsamungen während des Verbindungsversuchs zur Datenbank oder Unterschiede haben, die auftreten, wenn die Datenbank signifikant wächst.
Eine bessere Lösung scheint es zu sein, die Überprüfung der vom Benutzer eingegebenen Daten asynchron im Hintergrund durchzuführen und den Benutzer sofort über den Anmeldeversuch zu benachrichtigen. In diesem Fall bleiben die Berechnungen und die damit verbundenen Verzögerungen für den Angreifer unsichtbar.
