Wir haben Burp Suite verwendet, um ein Experiment zur Aufzählung von Sitzungs-IDs zu demonstrieren, die mit der Sprache PHP erstellt wurden. Der Quellcode verwendete einen anfälligen Mechanismus zur Erstellung der Sitzungs-ID, indem er einen numerischen Wert in einem vorgegebenen Bereich zuwies und ihn mit dem Profil des Benutzers verknüpfte. Wenn die Sitzungs-ID nicht zufällig generiert wird, macht sie die Webanwendung anfällig für Session-Hijacking-Angriffe. Wir haben zu Demonstrationszwecken die OverTheWire-Kriegsspiele Natas Level 18 – 19 Challenge verwendet. Dies war Teil von OverTheWire Kriegsspiele Natas Level 18 – 19
Holen Sie sich Hinweise zum OSCP-Zertifikat
Praktische Hinweise zur Burp Suite
Natas Level 19 Passwort
8LMJEhKFbMKIL2mxQKjv0aEDdk7zpT0s
Video-Transkript
Was geht, Leute? Willkommen zurück zu diesem heutigen Video. Wir machen WarGames über das Kabel.
Und wir werden uns Level 18 vornehmen. Das letzte Video, das wir gemacht haben, war Level 17. Sie haben Level 18 gemacht, und ich werde euch daran erinnern, dass es Level 18 nachts gibt, unsere Herausforderungen beim Penetrationstest von Webanwendungen. Wir gehen also zu Level 18, nachdem wir das Passwort des vorherigen Levels eingegeben haben.
Ich werde ein Anmeldeformular sehen. Okay, wir klicken auf „Quellcode anzeigen“, da dies eine Art White-Box-Pen-Test ist. Wir haben Zugriff auf den Quellcode der Anwendung. Also klicken wir auf „Quellcode anzeigen“.
Und das Erste, was uns hier auffällt, ist diese Zeile? Diese Zeile definiert eine Variable namens Max ID, deren Wert 640 ist.
Wenn wir den Code durchlesen. In dieser Zeile gibt es eine Funktion zum Erstellen einer ID. Und wie Sie hier sehen können, wird die ID generiert. Sie muss zwischen 1 und der maximalen ID liegen, die zuvor im Code als gleich oder gleich 640 definiert wurde. Scrollen Sie also später nach unten. Wir sehen hier die Funktion, die für das Generieren der Sitzung verantwortlich ist.
Und hier ist, was wir bekommen, wenn wir die richtige Sitzung haben. Das Problem in diesem Code liegt also grundsätzlich darin, dass die Sitzungs-ID oder diese Nummer zum Generieren der Sitzungs-ID verwendet wird. Okay. Nun, Sitzungs-IDs, wenn der Angreifer sie erraten oder generieren oder die richtige Sitzungs-ID für den Benutzer finden kann, nach dem er sucht.
Der Angreifer kann auf das Profil des Benutzers zugreifen, ohne das Passwort herausfinden zu müssen. Wir nennen das Session Hijacking. Und was ist hier das Problem? Das Problem ist, dass die Sitzung definiert ist oder als eine Zahl zwischen eins und sechshundertvierzig generiert wird.
Das bedeutet, dass die meisten Benutzer, die auf dieser Website registriert sind, als Benutzer registriert sind. Okay, diese Benutzer haben solche IDs zwischen einem.
Und 640, was bedeutet, dass wir erraten können, welche Benutzer-ID zu welchem Benutzer gehört, und wir auf jedes Benutzerprofil zugreifen können.
Das ist also das Problem in diesem Code. Die sichere Alternative hierzu besteht darin, die Sitzungs-ID zufällig zu generieren.
Wir können keinen bestimmten Wert oder Bereich für die Sitzungs-ID definieren. Okay. Also, was Sie hier tun, wir können diese Herausforderung mit zwei Methoden lösen. Wir können es entweder mit Python machen. Wir erstellen ein Skript und erzwingen mit Brute Force die Sitzungs-ID des Administratorbenutzers. Grundsätzlich werden wir bei jeder Sitzung Zahlen zwischen eins und sechsundvierzig ausprobieren und sehen, welche beim Administratorbenutzer endet, oder wir müssen Burp Suite verwenden, was ich in diesem Video verwenden werde, da wir viele Herausforderungen gemacht haben, bei denen wir die Herausforderung heute mit Python gelöst haben. Wir werden Purple Sweet verwenden. Gehen wir zurück und öffnen Burp Suite. Sehen wir uns zunächst die Anfrage an. Nehmen wir also an, wir starten Admin Admin.
Lassen Sie uns jetzt eine Anmeldeanforderung mit dem Benutzernamen „admin“ und dem Kennwort „admin“ simulieren.
Jetzt können wir die Antwort abfangen, da wir das zugewiesene Cookie sehen möchten.
Schauen wir uns das mal an. Wie Sie in der Antwort sehen können, ist die Sitzungs-ID auf 498 eingestellt.
Okay. Was wir jetzt tun werden, ist, das hier zu nehmen und es an den Eindringling zu senden. Okay, jetzt leiten wir es weiter und jetzt setzen wir erneut die Abfangfunktion oder gehen erneut zur Abfanganforderung. Also aktualisieren.
Lassen Sie uns die Anfrage nun noch einmal simulieren. Also gut, hier ist die Anfrage noch einmal. Beachten Sie, dass es sich bei der Anfrage um „Get Requests“ handelt.
Und noch etwas, das hier zu beachten ist, ist die Sitzungs-ID. Das werden wir hier also tun. Wir wollen jetzt die Sitzungs-ID mit Brute-Force-Methode herausfinden, um die richtige Nummer zu finden, die mit dem Administratorkonto verknüpft ist. Okay, also wollen wir dies an den Eindringling senden, bevor wir das tun. Wir müssen das irgendwie entfernen, wir müssen diese Zeile entfernen.
Wir möchten nur die Sitzungs-ID behalten. Dann kann sie an den Eindringling gesendet werden.
Machen Sie weiter. Er würde die Payload-Positionen definieren, indem er die Position löscht und einstellt. Von Grund auf. Hier markieren wir also die Sitzungs-ID und klicken auf HINZUFÜGEN. Und jetzt ist die Sitzungs-ID markiert. Als Nächstes definieren wir den Payload-Typ. Also legen wir den Typ auf zwei Zahlen fest und hier legen wir die Sequenz fest. Wir beginnen also beispielsweise bei Null und gehen ganz nach oben, bis wir 1000 erreichen. Sie können mehr definieren, aber nicht weniger als 700 oder so.
140 und dann starten wir den Angriff. Okay, jetzt haben wir also damit begonnen.
Wie Sie hier sehen können, haben alle Anfragen eine ähnliche Länge in der Antwort. Schauen Sie hier. Die meisten davon sind 608 608 607, Entschuldigung, 67, und 67 endet also mit 68. Wir werden also nach einer Antwort suchen, die in der Länge ziemlich unterschiedlich ist, also weit von dieser Länge entfernt.
Damit wir wissen, dass wir für diese Anfrage eine andere Antwort haben. Wir sehen uns die Anfrage an, notieren uns die Sitzungs-ID und werden es versuchen. Warten wir jetzt ab.
Okay, der Eindringling ist fertig und ich habe festgestellt, dass die ID 119 ist, die die unterschiedliche Risikoreaktion generiert hat. Wir werden sie also als neue Sitzungs-ID festlegen und „Weiter“ sagen.
Ich habe den Browser überprüft und wie ihr sehen könnt, Leute, ist das der Bastard für das nächste Level. Die ID wäre also 119 gewesen.
Video-Komplettlösung
