- Travaillez-vous dans une entreprise de **cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
- **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
- **Partagez vos astuces de piratage en soumettant des PR au [dépôt hacktricks](https://github.com/carlospolop/hacktricks) et au [dépôt hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
**Le contenu de ce post a été extrait de** [**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/)
Il est normalement possible d'**exécuter du code sur un serveur web où un ViewState valide peut être forgé**. Cela peut être fait lorsque la fonctionnalité de **validation MAC** a été **désactivée** ou en connaissant :
* **La clé de validation et son algorithme** **avant** la version **4.5** de .NET Framework
* **La clé de validation, l'algorithme de validation, la clé de décryptage et l'algorithme de décryptage** dans la version 4.5 ou supérieure de .NET Framework
Afin de prévenir les attaques de manipulation, .NET Framework peut **signer et chiffrer** le ViewState qui a été sérialisé en utilisant la classe `LosFormatter`. Il vérifie ensuite la signature en utilisant le mécanisme de validation de code d'authentification de message (MAC). La classe `ObjectStateFormatter` effectue les tâches de signature, de chiffrement et de vérification. Les **clés requises pour effectuer le mécanisme de signature et/ou de chiffrement** peuvent être stockées dans la section `machineKey` des fichiers **`web.config`** (niveau d'application) ou **`machine.config`** (niveau de la machine). C'est généralement le cas lorsque plusieurs serveurs web sont utilisés pour servir la même application souvent derrière un équilibreur de charge dans une ferme web ou un cluster. Ce qui suit montre le format de la section `machineKey` dans un fichier de configuration d'une application ASP.NET qui utilise la version 2.0 ou supérieure de .NET Framework :
Il convient de noter que lorsqu'une section `machineKey` n'a pas été définie dans les fichiers de configuration ou lorsque les attributs `validationKey` et `decryptionKey` ont été définis sur `AutoGenerate`, **l'application génère les valeurs requises de manière dynamique** en fonction d'un secret cryptographique aléatoire. Les algorithmes peuvent également être sélectionnés automatiquement. Actuellement, dans la dernière version du framework .NET, l'algorithme de validation par défaut est `HMACSHA256` et l'algorithme de décryptage par défaut est `AES`. Voir [\[13\]](https://docs.microsoft.com/en-us/dotnet/api/system.web.configuration.machinekeysection) pour plus de détails.
Dans le passé, il était possible de **désactiver la validation MAC** simplement en définissant la propriété `enableViewStateMac` sur `False`. Microsoft a publié un correctif en septembre 2014 [\[3\]](https://devblogs.microsoft.com/aspnet/farewell-enableviewstatemac/) pour imposer la validation MAC en ignorant cette propriété dans toutes les versions du framework .NET. Bien que certains d'entre nous puissent croire que "_la validation MAC ViewState ne peut plus être désactivée_" [\[4\]](https://www.owasp.org/index.php/Anti\_CSRF\_Tokens\_ASP.NET), il est toujours possible de désactiver la fonctionnalité de validation MAC en définissant la clé de registre `AspNetEnforceViewStateMac` sur zéro dans:
Lorsque la validation MAC de ViewState a été **désactivée**, le projet [YSoSerial.Net](https://github.com/pwntester/ysoserial.net) peut être utilisé pour générer des charges utiles `LosFormatter` en tant que ViewState afin d'exécuter du code arbitraire sur le serveur.
Avant la version **4.5** du Framework .NET, le paramètre `__VIEWSTATE` pouvait être **crypté alors que la fonctionnalité de validation MAC était désactivée**. Il convient de noter que **la plupart des scanners** ne tentent pas d'envoyer un paramètre ViewState non crypté pour identifier cette vulnérabilité. Par conséquent, un **test manuel** est nécessaire pour vérifier si la validation MAC est désactivée lorsque le paramètre `__VIEWSTATE` a été crypté. Cela peut être vérifié en envoyant une courte chaîne aléatoire en base64 dans le paramètre `__VIEWSTATE`. L'URL suivante montre un exemple :
Si la page cible **répond avec une erreur, la fonctionnalité de validation MAC a été désactivée** sinon elle aurait supprimé le message d'erreur de validation MAC.\
Cependant, dans les scénarios où vous ne pouvez pas voir le message d'erreur, cette astuce ne fonctionnera pas.
Les scanners automatisés devraient utiliser une **charge utile qui provoque un court délai** côté serveur. Cela peut être réalisé en exécutant le code ASP.NET suivant, par exemple, pour créer un délai de 10 secondes :
Dans les anciennes versions (**antérieures à 4.5**), le Framework .NET utilise la propriété **`TemplateSourceDirectory`** [\[15\]](https://docs.microsoft.com/en-us/dotnet/api/system.web.ui.control.templatesourcedirectory) lors de la **signature** d'un objet sérialisé. Cependant, depuis la version **4.5**, il utilise les chaînes **`Purpose`** pour créer le hash. Ces deux mécanismes **requièrent le chemin cible à partir de la racine du répertoire de l'application** et le **nom de la page**. Ces paramètres peuvent être **extraits de l'URL**.
Les applications qui utilisent un **ancien framework** et qui imposent le chiffrement ViewState peuvent **encore accepter un ViewState signé sans chiffrement**. Cela signifie que **connaître la clé de validation et son algorithme est suffisant** pour exploiter un site web. Il semble que ViewState soit chiffré par défaut **depuis la version 4.5** même lorsque la propriété `viewStateEncryptionMode` a été définie sur `Never`. Cela signifie que dans les dernières versions du Framework .NET, la **clé de déchiffrement et son algorithme sont également requis** pour créer une charge utile.
Le ViewState ASP.NET contient une propriété appelée `ViewStateUserKey` [\[16\]](https://docs.microsoft.com/en-us/previous-versions/dotnet/articles/ms972969\(v=msdn.10\)) qui peut être utilisée pour atténuer les risques d'attaques de falsification de requêtes intersites (CSRF) [\[4\]](https://www.owasp.org/index.php/Anti\_CSRF\_Tokens\_ASP.NET). La valeur de la propriété **`ViewStateUserKey`** (lorsqu'elle n'est pas `null`**) est également utilisée pendant le processus de signature ViewState**. Bien que ne pas connaître la valeur de ce paramètre puisse arrêter notre attaque, **sa valeur peut souvent être trouvée dans les cookies ou dans un paramètre d'entrée caché** ([\[17\]](https://software-security.sans.org/developer-how-to/developer-guide-csrf) montre un exemple implémenté).
Dans YSoSerial.Net master et YSoSerial.Netv2, vous pouvez trouver un plugin ([**celui-ci**](https://github.com/pwntester/ysoserial.net/blob/master/ysoserial/Plugins/ViewStatePlugin.cs) et [**celui-ci**](https://github.com/pwntester/ysoserial.net/blob/v2/ysoserial/Plugins/ViewStatePlugin.cs)) pour exploiter cette technique lorsque toutes les informations sont connues.
Il utilise par défaut le gadget ActivitySurrogateSelector qui nécessite la compilation de la classe ExploitClass.cs dans le projet YSoSerial.Net. La charge utile ViewState peut également être **chiffrée** pour éviter les pare-feux applicatifs Web lorsque la valeur decryptionKey est connue :
**Note :** En raison de la nature des gadgets utilisés dans YSoSerial.Net, la page ASP.NET cible répond toujours avec une erreur même si une exploitation a été exécutée avec succès côté serveur.
Vous pouvez consulter [\[20\]](https://docs.microsoft.com/en-us/iis/get-started/planning-your-iis-architecture/understanding-sites-applications-and-virtual-directories-on-iis) si vous n'êtes pas familier avec les termes de répertoire virtuel et d'application dans IIS.
Si nous ne savions pas que "app2" était un nom d'application, nous pourrions utiliser **l'essai et l'erreur pour tester tous les noms de répertoires** dans l'URL un par un jusqu'à trouver un ViewState qui peut exécuter du code sur le serveur (peut-être en obtenant une demande DNS ou en causant un délai).
Dans ce cas, l'argument `--generator` peut être utilisé. L'argument `--isdebug` peut être utilisé pour vérifier si le plugin calcule également le même paramètre `__VIEWSTATEGENERATOR` lorsque les arguments `--path` et `--apppath` ont été fournis.
Pour exploiter les applications qui utilisent .NET Framework v4.0 ou inférieur, la branche YSoSerial.Net v2.0 [\[21\]](https://github.com/nccgroup/VulnerableDotNetHTTPRemoting/tree/master/ysoserial.net-v2) peut être utilisée (cela a été développé à l'origine dans le cadre d'une autre recherche [\[22\]](https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2019/march/finding-and-exploiting-.net-remoting-over-http-using-deserialisation/)). Cependant, ce projet ne prend en charge qu'un nombre limité de gadgets et nécessite également que la boîte cible ait .NET Framework 3.5 ou une version supérieure installée.
Il semble qu'Immunity Canvas supporte la création du paramètre ViewState lorsque les clés de validation et de chiffrement sont connues [\[29\]](https://vimeopro.com/user18478112/canvas/video/260982761). Les outils suivants ont également été publiés par coïncidence au moment où j'allais publier mon travail, ce qui était assez surprenant :
Je pense que ces outils ne **différencient actuellement pas entre les différentes versions de .NET** Framework et ciblent la cryptographie héritée. De plus, ils **n'utilisent pas le paramètre `ViewStateUserKey`** qui pourrait être utilisé pour arrêter les attaques CSRF.
Il est également possible d'envoyer le paramètre `__VIEWSTATE` dans l'URL via une requête GET. Le seul facteur limitant est la longueur de l'URL qui limite le type de gadgets qui peuvent être utilisés ici.
Comme mentionné précédemment, le paramètre `__VIEWSTATE` n'a pas besoin d'être chiffré lors de l'exploitation de .NET Framework 4.0 et inférieur (testé sur v2.0 à v4.0) même lorsque la propriété `ViewStateEncryptionMode` a été définie sur `Always`. ASP.NET décide si le ViewState a été chiffré ou non en trouvant le paramètre `__VIEWSTATEENCRYPTED` dans la requête (il n'a pas besoin d'avoir de valeur). Par conséquent, il est possible d'envoyer un ViewState non chiffré en supprimant le paramètre `__VIEWSTATEENCRYPTED` de la requête.
Cela signifie également que le changement de la clé de déchiffrement ou de son algorithme ne peut pas arrêter les attaques lorsque la clé de validation et son algorithme ont été volés.
Une page ASP.NET produit une erreur lorsqu'un paramètre `__VIEWSTATE` invalide est utilisé. Cependant, la page peut toujours recevoir ses entrées lorsque `Request.Form` est utilisé directement dans le code, par exemple en utilisant `Request.Form["txtMyInput"]` plutôt que `txtMyInput.Text`. **L'attaque CSRF peut être réalisée en supprimant le paramètre `__VIEWSTATE` de la requête ou en ajoutant le paramètre `__PREVIOUSPAGE` avec une valeur invalide**. Comme le paramètre `__PREVIOUSPAGE` est crypté et formaté en base64 par défaut, même la fourniture d'un seul caractère comme valeur devrait provoquer une erreur.
Lorsque le paramètre `__VIEWSTATEGENERATOR` est connu, il peut être utilisé pour les applications ASP.NET qui utilisent la version .NET Framework 4.0 ou inférieure afin de signer un objet sérialisé sans connaître le chemin d'application.
Il est possible de diviser le paramètre `__VIEWSTATE` en plusieurs parties lorsque la propriété **`MaxPageStateFieldLength`** a été définie sur une **valeur positive**. Sa valeur **par défaut** est **négative** et cela signifie que le paramètre **`__VIEWSTATE`** ne peut pas être divisé en plusieurs parties.
Le paramètre `__EVENTVALIDATION` et quelques autres paramètres sont également sérialisés de manière similaire au paramètre `__VIEWSTATE` et peuvent être ciblés de manière similaire. L'exploitation d'un problème de désérialisation via `__EVENTVALIDATION` est plus restreinte et nécessite :
La chaîne `Purpose` utilisée par .NET Framework 4.5 et supérieur pour créer une signature valide est différente en fonction du paramètre utilisé. Le tableau suivant montre les chaînes `Purpose` définies dans .NET Framework :
Lorsque le paramètre **`__PREVIOUSPAGE`** existe dans la requête avec des données **invalides**, l'**application** ne **désérialise pas** le paramètre **`__VIEWSTATE`**. Fournir le paramètre `__CALLBACKID` empêche ce comportement.
Comme expliqué précédemment, nous utilisons parfois des erreurs pour vérifier si un ViewState généré est valide. ASP.NET n'affiche pas l'erreur de validation MAC par défaut lorsqu'un paramètre `__VIEWSTATEGENERATOR` invalide est utilisé. Ce comportement change lorsque la propriété `ViewStateUserKey` est utilisée, car ASP.NET ne supprime plus les erreurs de validation MAC.
En plus de cela, les applications web ASP.NET peuvent ignorer les erreurs de validation MAC avec le paramètre suivant même lorsque la propriété `ViewStateUserKey` est utilisée :
Si les attaquants peuvent **modifier** le fichier **`web.config`** à la racine d'une application, ils peuvent **facilement exécuter du code** sur le serveur. Cependant, intégrer une porte dérobée furtive dans l'application pourrait être un bon choix pour un attaquant. Cela peut être fait en **désactivant la validation MAC** et en définissant la propriété `viewStateEncryptionMode` sur `Always`. Cela signifie que toutes les pages ASP.NET qui ne définissent pas la propriété `ViewStateEncryptionMode` sur `Auto` ou `Never` utilisent toujours des paramètres ViewState chiffrés. Cependant, comme les **ViewState n'utilisent pas la fonctionnalité de validation MAC, ils sont maintenant vulnérables à l'exécution de code à distance via la désérialisation de données non fiables**. L'exemple suivant montre cela:
Une autre option pour un site web autonome serait de définir la section `machineKey` avec des clés et des algorithmes arbitraires pour empêcher d'autres attaquants !
Il convient de noter que la définition de la propriété `EnableViewState` sur `False` ne permet pas d'arrêter cette attaque car le ViewState sera toujours analysé par ASP.NET.
- Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
- **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
- **Partagez vos astuces de piratage en soumettant des PR au [repo hacktricks](https://github.com/carlospolop/hacktricks) et au [repo hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
