Exploiting __VIEWSTATE without knowing the secrets
Last updated
Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Bug-Bounty-Tipp: Melde dich an bei Intigriti, einer Premium-Bug-Bounty-Plattform, die von Hackern für Hacker erstellt wurde! Schließe dich uns heute unter https://go.intigriti.com/hacktricks an und beginne, Prämien von bis zu 100.000 $ zu verdienen!
ViewState dient als das Standardmechanismus in ASP.NET, um Seiten- und Steuerungsdaten über Webseiten hinweg zu erhalten. Während der Darstellung des HTML einer Seite werden der aktuelle Zustand der Seite und die Werte, die während eines Postbacks erhalten bleiben sollen, in base64-kodierte Zeichenfolgen serialisiert. Diese Zeichenfolgen werden dann in versteckten ViewState-Feldern platziert.
ViewState-Informationen können durch die folgenden Eigenschaften oder deren Kombinationen charakterisiert werden:
Base64:
Dieses Format wird verwendet, wenn sowohl die Attribute EnableViewStateMac
als auch ViewStateEncryptionMode
auf false gesetzt sind.
Base64 + MAC (Message Authentication Code) aktiviert:
Die Aktivierung von MAC erfolgt durch Setzen des Attributs EnableViewStateMac
auf true. Dies bietet eine Integritätsprüfung für ViewState-Daten.
Base64 + Verschlüsselt:
Verschlüsselung wird angewendet, wenn das Attribut ViewStateEncryptionMode
auf true gesetzt ist, um die Vertraulichkeit der ViewState-Daten zu gewährleisten.
Das Bild ist eine Tabelle, die verschiedene Konfigurationen für ViewState in ASP.NET basierend auf der .NET-Framework-Version detailliert. Hier ist eine Zusammenfassung des Inhalts:
Für jede Version von .NET, wenn sowohl MAC als auch Verschlüsselung deaktiviert sind, ist kein MachineKey erforderlich, und es gibt somit keine anwendbare Methode, um ihn zu identifizieren.
Für Versionen unter 4.5, wenn MAC aktiviert, aber die Verschlüsselung nicht aktiviert ist, ist ein MachineKey erforderlich. Die Methode zur Identifizierung des MachineKey wird als "Blacklist3r" bezeichnet.
Für Versionen unter 4.5, unabhängig davon, ob MAC aktiviert oder deaktiviert ist, wenn die Verschlüsselung aktiviert ist, wird ein MachineKey benötigt. Die Identifizierung des MachineKey ist eine Aufgabe für "Blacklist3r - Future Development."
Für Versionen 4.5 und höher erfordern alle Kombinationen von MAC und Verschlüsselung (ob beide true sind oder einer true und der andere false) einen MachineKey. Der MachineKey kann mit "Blacklist3r" identifiziert werden.
Es ist auch möglich, das ViewStateMAC vollständig zu deaktivieren, indem der AspNetEnforceViewStateMac
Registrierungsschlüssel auf null gesetzt wird in:
Identifizieren von ViewState-Attributen
Sie können versuchen zu identifizieren, ob ViewState MAC-geschützt ist, indem Sie eine Anfrage mit diesem Parameter mit BurpSuite erfassen. Wenn Mac nicht verwendet wird, um den Parameter zu schützen, können Sie ihn mit YSoSerial.Net ausnutzen.
Entwickler können ViewState daran hindern, Teil einer HTTP-Anfrage zu werden (der Benutzer erhält dieses Cookie nicht). Man könnte annehmen, dass, wenn ViewState nicht vorhanden ist, ihre Implementierung sicher vor potenziellen Schwachstellen ist, die mit der Deserialisierung von ViewState verbunden sind. Das ist jedoch nicht der Fall. Wenn wir den ViewState-Parameter zum Anfragekörper hinzufügen und unser serialisiertes Payload, das mit ysoserial erstellt wurde, senden, werden wir immer noch in der Lage sein, Codeausführung zu erreichen, wie in Fall 1 gezeigt.
Um ViewState MAC für eine spezifische Seite zu aktivieren, müssen wir folgende Änderungen an einer bestimmten aspx-Datei vornehmen:
Wir können es auch für die gesamt Anwendung tun, indem wir es in der web.config-Datei wie unten gezeigt festlegen:
Da der Parameter diesmal MAC-geschützt ist, müssen wir zuerst den verwendeten Schlüssel haben, um den Angriff erfolgreich auszuführen.
Sie können versuchen, Blacklist3r(AspDotNetWrapper.exe) zu verwenden, um den verwendeten Schlüssel zu finden.
Badsecrets ist ein weiteres Tool, das bekannte machineKeys identifizieren kann. Es ist in Python geschrieben, sodass es im Gegensatz zu Blacklist3r keine Windows-Abhängigkeit gibt. Für .NET viewstates gibt es ein "python blacklist3r" Dienstprogramm, das der schnellste Weg ist, es zu verwenden.
Es kann entweder direkt mit dem viewstate und dem Generator versorgt werden:
Oder es kann sich direkt mit der Ziel-URL verbinden und versuchen, den viewstate aus dem HTML herauszuschneiden:
Um anfällige Viewstates im großen Maßstab zu suchen, in Verbindung mit der Subdomain-Enumeration, kann das badsecrets
BBOT Modul verwendet werden:
Wenn Sie Glück haben und der Schlüssel gefunden wird, können Sie mit dem Angriff unter Verwendung von YSoSerial.Net:
In Fällen, in denen der _VIEWSTATEGENERATOR
-Parameter nicht gesendet wird, müssen Sie nicht den --generator
-Parameter angeben, sondern diese:
In diesem Fall ist nicht bekannt, ob der Parameter mit MAC geschützt ist. Dann ist der Wert wahrscheinlich verschlüsselt und Sie benötigen den Machine Key, um Ihre Payload zu verschlüsseln, um die Schwachstelle auszunutzen.
In diesem Fall ist das Blacklist3r Modul in Entwicklung...
Vor .NET 4.5 kann ASP.NET einen unencrypted ___VIEWSTATE
_Parameter von den Benutzern akzeptieren, selbst wenn ViewStateEncryptionMode
auf Always gesetzt wurde. ASP.NET prüft nur die Präsenz des __VIEWSTATEENCRYPTED
Parameters in der Anfrage. Wenn man diesen Parameter entfernt und die unverschlüsselte Payload sendet, wird sie trotzdem verarbeitet.
Daher, wenn die Angreifer einen Weg finden, den Machinekey über eine andere Schwachstelle wie Dateitraversierung zu erhalten, kann der YSoSerial.Net Befehl, der im Fall 2 verwendet wurde, verwendet werden, um RCE unter Verwendung der ViewState-Deserialisierungsanfälligkeit durchzuführen.
Entfernen Sie den __VIEWSTATEENCRYPTED
Parameter aus der Anfrage, um die ViewState-Deserialisierungsanfälligkeit auszunutzen, andernfalls wird ein Viewstate MAC-Validierungsfehler zurückgegeben und der Exploit schlägt fehl.
Wir können die Verwendung des ASP.NET-Frameworks erzwingen, indem wir den untenstehenden Parameter in die web.config-Datei einfügen, wie unten gezeigt.
Alternativ kann dies erreicht werden, indem die folgende Option im machineKey
-Parameter der web.config-Datei angegeben wird.
Wie im Vorherigen ist der Wert verschlüsselt. Um eine gültige Payload zu senden, benötigt der Angreifer den Schlüssel.
Sie können versuchen, Blacklist3r(AspDotNetWrapper.exe) zu verwenden, um den verwendeten Schlüssel zu finden:
Für eine detailliertere Beschreibung von IISDirPath und TargetPagePath siehe hier
Oder mit Badsecrets (mit einem Generatorwert):
Sobald ein gültiger Machine key identifiziert ist, besteht der nächste Schritt darin, eine serialisierte Payload zu generieren, indem YSoSerial.Net
Wenn Sie den Wert von __VIEWSTATEGENERATOR
haben, können Sie versuchen, den --generator
Parameter mit diesem Wert zu verwenden und die Parameter --path
und --apppath
auszulassen.
Eine erfolgreiche Ausnutzung der ViewState-Deserialisierungsanfälligkeit führt zu einer Out-of-Band-Anfrage an einen vom Angreifer kontrollierten Server, die den Benutzernamen enthält. Diese Art von Exploit wird in einem Proof of Concept (PoC) demonstriert, der über eine Ressource mit dem Titel "Exploiting ViewState Deserialization using Blacklist3r and YsoSerial.NET" gefunden werden kann. Für weitere Details, wie der Ausnutzungsprozess funktioniert und wie man Tools wie Blacklist3r zur Identifizierung des MachineKey verwendet, können Sie den bereitgestellten PoC of Successful Exploitation überprüfen.
Die ViewStateUserKey-Eigenschaft kann verwendet werden, um sich gegen einen CSRF-Angriff zu verteidigen. Wenn ein solcher Schlüssel in der Anwendung definiert wurde und wir versuchen, die ViewState-Payload mit den bis jetzt besprochenen Methoden zu generieren, wird die Payload von der Anwendung nicht verarbeitet. Sie müssen einen weiteren Parameter verwenden, um die Payload korrekt zu erstellen:
Für alle Testfälle, wenn die ViewState YSoSerial.Net Payload erfolgreich funktioniert, antwortet der Server mit “500 Interner Serverfehler” und dem Antwortinhalt “Die Statusinformationen sind ungültig für diese Seite und könnten beschädigt sein” und wir erhalten die OOB-Anfrage.
Überprüfen Sie weitere Informationen hier
Bug-Bounty-Tipp: Melden Sie sich an bei Intigriti, einer Premium-Bug-Bounty-Plattform, die von Hackern für Hacker erstellt wurde! Treten Sie uns heute bei https://go.intigriti.com/hacktricks und beginnen Sie, Prämien von bis zu 100.000 $ zu verdienen!
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)