Exploiting __VIEWSTATE without knowing the secrets
Last updated
Last updated
Astuce de prime de bug : inscrivez-vous à Intigriti, une plateforme de prime de bug premium créée par des pirates informatiques, pour des pirates informatiques ! Rejoignez-nous sur https://go.intigriti.com/hacktricks aujourd'hui, et commencez à gagner des primes allant jusqu'à 100 000 $ !
ViewState sert de mécanisme par défaut dans ASP.NET pour maintenir les données de la page et des contrôles à travers les pages web. Lors du rendu du HTML d'une page, l'état actuel de la page et les valeurs à conserver 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 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 définis sur false.
Base64 + MAC (Message Authentication Code) activé :
L'activation du 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 ViewState.
Base64 + Chiffré :
Le chiffrement est appliqué lorsque l'attribut ViewStateEncryptionMode est défini sur true, assurant la confidentialité des données ViewState.
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 :
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.
Pour les versions inférieures à 4.5, si le MAC est activé mais le chiffrement ne l'est pas, une MachineKey est requise. La méthode pour identifier la MachineKey est appelée "Blacklist3r."
Pour les versions inférieures à 4.5, indépendamment de l'activation ou de la désactivation du MAC, si le chiffrement est activé, une MachineKey est nécessaire. Identifier la MachineKey est une tâche pour "Blacklist3r - Développement futur."
Pour les versions 4.5 et supérieures, toutes les combinaisons de MAC et de chiffrement (que les deux soient vrais, ou l'un vrai et l'autre faux) nécessitent une MachineKey. La MachineKey peut être identifiée en utilisant "Blacklist3r."
Il est également possible de désactiver complètement le ViewStateMAC en définissant la clé de registre AspNetEnforceViewStateMac sur zéro dans :
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
Les développeurs peuvent supprimer ViewState de devenir une partie d'une requête HTTP (l'utilisateur ne recevra pas ce cookie). On pourrait supposer que si ViewState n'est pas présent, leur implémentation est sécurisée contre toute vulnérabilité potentielle liée à 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 à l'aide de ysoserial, nous pourrons toujours atteindre une exécution de code comme indiqué dans le Cas 1.
Pour activer le MAC ViewState pour une page spécifique, nous devons apporter les modifications suivantes à un fichier aspx spécifique :
Nous pouvons également le faire pour l'application globale en le définissant dans le fichier web.config comme indiqué ci-dessous:
Comme le paramètre est protégé par MAC cette fois pour exécuter avec succès l'attaque, nous avons d'abord besoin de la clé utilisée.
Vous pouvez essayer d'utiliser Blacklist3r(AspDotNetWrapper.exe) pour trouver la clé utilisée.
Badsecrets est un autre outil qui peut identifier les 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 soit avec le viewstate et le générateur directement :
Ou, il peut se connecter directement à l'URL cible et essayer d'extraire le viewstate du HTML :
Pour rechercher des viewstates vulnérables à grande échelle, en conjonction avec l'énumération des sous-domaines, le module badsecrets BBOT peut être utilisé:
Si vous avez de la chance et que la clé est trouvée, vous pouvez procéder à l'attaque en utilisant YSoSerial.Net:
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:
Dans ce cas, on ne sait pas si le paramètre est protégé par un MAC. Ensuite, la valeur est probablement chiffrée et vous aurez besoin de la Machine Key pour chiffrer votre charge utile afin d'exploiter la vulnérabilité.
Dans ce cas, le module Blacklist3r est en cours de développement...
Avant .NET 4.5, ASP.NET peut accepter un paramètre ___VIEWSTATE_ non chiffré 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 on supprime ce paramètre et envoie la charge utile non chiffrée, elle sera quand même traitée.
Par conséquent, si les attaquants trouvent un moyen d'obtenir la Machinekey via une autre vulnérabilité comme la traversée de fichiers, la commande YSoSerial.Net utilisée dans le Cas 2, peut être utilisée pour effectuer une exécution de code à distance en exploitant la vulnérabilité de désérialisation de ViewState.
Supprimez le paramètre __VIEWSTATEENCRYPTED de la requête pour exploiter la vulnérabilité de désérialisation de ViewState, sinon une erreur de validation MAC ViewState sera renvoyée et l'exploitation échouera.
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.
Alternativement, cela peut être fait en spécifiant l'option ci-dessous à l'intérieur du paramètre machineKey du fichier web.config.
Comme dans le cas précédent, la valeur est chiffrée. Ainsi, 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 :
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):
Une fois une clé de machine valide identifiée, la prochaine étape consiste à générer une charge utile sérialisée en utilisant YSoSerial.Net
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'exploitation est démontré dans une preuve de concept (PoC) qui peut être trouvée dans 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 sur l'utilisation d'outils comme Blacklist3r pour identifier la MachineKey, vous pouvez consulter la PoC of Successful Exploitation fournie.
La propriété ViewStateUserKey peut être utilisée pour se 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:
Pour tous les cas de test, si la charge utile ViewState YSoSerial.Net fonctionne avec succès, le serveur répond avec une erreur interne 500 ayant un 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.
Consultez ici pour plus d'informations
Conseil de prime de bug: Inscrivez-vous sur Intigriti, une plateforme de prime de bug premium créée par des hackers, pour des hackers! Rejoignez-nous sur https://go.intigriti.com/hacktricks aujourd'hui, et commencez à gagner des primes allant jusqu'à 100 000 $!
