Quelle est la gravité de cette nouvelle faille de sécurité ASP.NET et comment puis-je la contourner ?

Question

Je viens de lire sur le net qu'une faille de sécurité vient d'être découverte dans ASP.NET. Vous pouvez lire les détails ici.

Le problème réside dans la manière dont ASP.NET met en œuvre l'algorithme de chiffrement AES pour protéger l'intégrité des cookies que ces applications génèrent pour stocker des informations pendant sessions de l'utilisateur.

C'est un peu vague, mais voici une partie plus effrayante :

La première étape de l'attaque prend un quelques milliers de requêtes, mais une fois qu'elle réussit et que l'attaquant obtient les les clés secrètes, elle est totalement furtive. connaissances cryptographiques requises sont très basiques.

En somme, je ne suis pas assez familier avec le sujet de la sécurité/cryptograpie pour savoir si c'est vraiment si grave.

Alors, est-ce que tous les développeurs ASP.NET doivent craindre cette technique qui peut posséder n'importe quel site web ASP.NET en quelques secondes ou quoi ?

Comment ce problème affecte-t-il le développeur ASP.NET moyen ? Est-ce qu'il nous affecte tout court ? Dans la vie réelle, quelles sont les conséquences de cette vulnérabilité ? Et, enfin, existe-t-il une solution de contournement permettant d'éviter cette vulnérabilité ?

Merci pour vos réponses !

---

EDIT : Je vais résumer les réponses que j'ai reçues.

Il s'agit donc d'une attaque de type "padding oracle". @Sri a fourni une excellente explication sur ce que signifie ce type d'attaque. Voici une vidéo choquante à ce sujet !

Sur la gravité de cette vulnérabilité : Oui, c'est en effet sérieux. Il permet à l'attaquant de connaître la clé machine d'une application. Ainsi, il peut faire très des choses non désirées.

• En possession de la clé machine de l'application, l'attaquant peut décrypter les cookies d'authentification.
• Encore pire que ça, il peut générer des cookies d'authentification avec le nom d'un utilisateur quelconque. Ainsi, il peut apparaître comme n'importe qui sur le site. L'application est incapable de faire la différence entre vous et le pirate qui a généré un cookie d'authentification avec votre nom pour lui-même.
• Il lui permet également de décrypter (et aussi de générer) cookies de session bien qu'il ne soit pas aussi dangereux que le précédent.
• Pas si grave : il peut décrypter le ViewState crypté des pages. (Si vous utilisez ViewState pour stocker des données confidentielles, vous ne devriez pas le faire de toute façon).
• Tout à fait inattendu : Avec la connaissance de la clé de la machine, l'attaquant peut télécharger tout fichier arbitraire à partir de votre application web, même ceux qui ne peuvent normalement pas être téléchargés ! (Y compris Web.Config etc.)

Voici une série de bonnes pratiques que j'ai obtenues. Ne le fais pas. ne résout pas le problème mais contribue à améliorer la sécurité générale d'une application web.

• Vous pouvez crypter les données sensibles avec Protected Configuration
• Utiliser les cookies HTTP uniquement
• Prévenir les attaques DoS

Maintenant, concentrons-nous sur cette question.

• Scott Guthrie a publié un article à ce sujet sur son blog.
• Article de blog FAQ de ScottGu sur la vulnérabilité
• Mise à jour de ScottGu sur la vulnérabilité
• Microsoft a publié un avis de sécurité à ce sujet
• Comprendre la vulnérabilité
• Informations supplémentaires sur la vulnérabilité

La solution

• Activez customErrors et créez une page d'erreur unique à laquelle vous pouvez accéder. toutes les erreurs sont redirigés. Oui, même 404s . (ScottGu précise que la différenciation entre les 404 et les 500 est essentielle pour cette attaque). Aussi, dans votre Application_Error ou Error.aspx mettre du code qui fait un délai aléatoire. (Générez un nombre aléatoire et utilisez Thread.Sleep pour dormir pendant cette durée.) Ainsi, il sera impossible pour l'attaquant de déterminer ce qui s'est passé exactement sur votre serveur.
• Certaines personnes ont recommandé de revenir à 3DES. En théorie, si vous n'utilisez pas AES, vous ne rencontrez pas la faiblesse de sécurité de l'implémentation AES. Il s'avère que c'est pas du tout recommandé .

Quelques autres réflexions

• Il semble que no tout le monde pense que la solution de contournement est suffisante.

Merci à tous ceux qui ont répondu à ma question. J'ai beaucoup appris non seulement sur cette question, mais aussi sur la sécurité du Web en général. J'ai marqué la réponse de @Mikael comme acceptée, mais les autres réponses sont également très utiles.

Answer 1

Que dois-je faire pour me protéger ?

[Mise à jour 2010-09-29]

Bulletin de sécurité de Microsoft

Article de la KB avec référence à la correction

ScottGu a des liens pour les téléchargements

[Mise à jour 2010-09-25]

Pendant que nous attendons le correctif, hier, ScottGu postet une mise à jour sur la façon d'ajouter une étape supplémentaire pour protéger vos sites avec une règle URLScan personnalisée.

---

En gros, assurez-vous de fournir une page d'erreur personnalisée afin qu'un attaquant ne soit pas exposé aux erreurs internes de .Net, ce que vous devriez toujours faire en mode publication/production.

De plus, ajoutez un temps de sommeil aléatoire dans la page d'erreur pour empêcher l'attaquant de chronométrer les réponses pour des informations supplémentaires sur les attaques.

Dans web.config

<configuration>
 <location allowOverride="false">
   <system.web>
     <customErrors mode="On" defaultRedirect="~/error.html" />
   </system.web>
 </location>
</configuration>

Cela redirigera toute erreur vers une page personnalisée renvoyée avec un code d'état 200. De cette façon, un attaquant ne peut pas consulter le code d'erreur ou les informations relatives à l'erreur pour obtenir des informations nécessaires à d'autres attaques.

Il est également possible de définir customErrors mode="RemoteOnly" car cela redirigera les "vrais" clients. Seule la navigation à partir de localhost affichera des erreurs internes .Net.

L'important est de s'assurer que toutes les erreurs sont configurées pour renvoyer la même page d'erreur. Pour ce faire, vous devez définir explicitement l'option defaultRedirect de l'attribut <customErrors> et assurez-vous qu'aucun code d'état n'est défini.

Quel est l'enjeu ?

Si un attaquant parvient à utiliser l'exploit mentionné, il peut télécharger des fichiers internes à partir de votre application web. Généralement, le fichier web.config est une cible et peut contenir des informations sensibles comme des informations de connexion à une base de données, ou même un lien vers une base de données sql-express automatisée dont vous ne voulez pas que quelqu'un s'empare. Mais si vous suivez les meilleures pratiques, vous utilisez Configuration protégée pour crypter toutes les données sensibles dans votre web.config.

Liens vers des références

Lisez le commentaire officiel de Microsoft sur la vulnérabilité à l'adresse suivante http://www.microsoft.com/technet/security/advisory/2416728.mspx . En particulier, la partie "Solution de contournement" pour les détails de mise en œuvre de ce problème.

Vous trouverez également des informations sur ScottGu's blog, y compris un script pour trouver les applications ASP.Net vulnérables sur votre serveur web.

Pour une explication sur "Comprendre les attaques d'Oracle Padding", lire La réponse de @sri .

---

Commentaires sur l'article :

L'attaque que Rizzo et Duong ont mise en œuvre contre les applications ASP.NET nécessite que le crypto du site Web dispose d'un oracle qui, lorsqu'on lui envoie un texte chiffré, non seulement le déchiffre mais donner à l'expéditeur un message indiquant si le remplissage du texte chiffré est valide. .

Si le rembourrage n'est pas valide, le message d'erreur que l'expéditeur reçoit lui donnera des informations sur la façon dont le processus de décryptage du site fonctionne.

Pour que l'attaque fonctionne, les conditions suivantes doivent être remplies :

• Votre application doit afficher un message d'erreur indiquant que le remplissage n'est pas valide.
• Quelqu'un doit trafiquer vos cookies cryptés ou vos données d'affichage.

Ainsi, si vous renvoyez des messages d'erreur lisibles par l'homme dans votre application, par exemple "Quelque chose s'est mal passé, veuillez réessayer" alors vous devriez être en sécurité. Lire un peu les commentaires sur l'article donne également des informations précieuses.

• Stocker un identifiant de session dans le cookie crypté
• Stocker les données réelles dans l'état de session (persisté dans un db)
• Ajouter une attente aléatoire lorsque les informations de l'utilisateur sont erronées avant de renvoyer l'erreur, de sorte que vous ne pouvez pas la chronométrer.

Ainsi, un cookie détourné ne peut être utilisé que pour récupérer une session qui, très probablement, n'existe plus ou a été invalidée.

Il sera intéressant de voir ce qui sera réellement présenté lors de la conférence Ekoparty, mais pour l'instant, cette vulnérabilité ne m'inquiète pas trop.

Answer 2

Comprendre les attaques d'Oracle Padding

Supposons que votre application accepte une chaîne cryptée comme paramètre - que le paramètre soit un cookie, un paramètre url ou autre chose n'a aucune importance. Lorsque l'application essaie de la décoder, il y a 3 résultats possibles

1. Résultat 1 : La chaîne cryptée a été déchiffrée correctement, et l'application a pu lui donner un sens. Autrement dit, si la chaîne cryptée était un numéro de compte à 10 chiffres, après décryptage, l'application a trouvé quelque chose comme "1234567890" et non "abcd1213ef".

2. Résultat 2 : Le remplissage était correct, mais après décryptage, la chaîne obtenue était un charabia que l'appli ne pouvait pas comprendre. Par exemple, la chaîne décryptée était "abcd1213ef", mais l'application n'attendait que des chiffres. La plupart des applications affichent un message du type "Numéro de compte non valide".

3. Résultat 3 : Le remplissage était incorrect, et l'application a lancé une sorte de message d'erreur. La plupart des applications affichent un message générique du type "Some error occurred".

Pour qu'une attaque Padding Oracle réussisse, l'attaquant doit être en mesure de faire plusieurs milliers de requêtes, et doit être capable de classer la réponse dans l'une des 3 catégories ci-dessus sans erreur.

Si ces deux conditions sont réunies, l'attaquant peut éventuellement décrypter le message, puis le ré-encrypter avec ce qu'il souhaite. C'est juste une question de temps.

Que peut-on faire pour l'éviter ?

1. La chose la plus simple - tout ce qui est sensible ne devrait jamais être envoyé au client, crypté ou non crypté. Gardez-le sur le serveur.

2. Assurez-vous que le résultat 2 et le résultat 3 dans la liste ci-dessus apparaissent exactement les mêmes à l'attaquant. Il ne devrait y avoir aucun moyen de distinguer l'un de l'autre. Ce n'est cependant pas si simple : un attaquant peut faire la distinction en utilisant une sorte d'attaque de synchronisation.

3. En dernière ligne de défense, disposez d'un pare-feu pour applications Web. L'attaque de type "padding oracle" doit effectuer plusieurs requêtes qui se ressemblent presque (en changeant un bit à la fois), il devrait donc être possible pour un WAF d'attraper et de bloquer de telles requêtes.

P.S. Une bonne explication des attaques Oracle Padding se trouve dans cet article de blog . Avertissement : Ce n'est PAS mon blog.

Answer 3

De ce que j'ai lu jusqu'à maintenant...

L'attaque permet à quelqu'un de décrypter les cookies reniflés, qui peuvent contenir des données précieuses telles que des soldes bancaires

Ils ont besoin du cookie crypté d'un utilisateur qui s'est déjà connecté, sur n'importe quel compte. Ils ont également besoin de trouver des données dans les cookies - j'espère que les développeurs ne stockent pas de données critiques dans les cookies :). Et il y a un moyen que j'ai ci-dessous pour ne pas laisser asp.net stocker des données dans le cookie de connexion.

Comment quelqu'un peut-il obtenir le cookie d'un utilisateur qui est en ligne s'il ne met pas la main sur les données du navigateur ? Ou en reniflant le paquet IP ?

Une façon d'éviter cela est d'interdire le transport de cookies sans cryptage ssl.

<httpCookies httpOnlyCookies="true" requireSSL="true" />

Une autre mesure consiste à empêcher le stockage des rôles dans les cookies.

<roleManager enabled="true" cacheRolesInCookie="false">

Maintenant, en ce qui concerne les cookies qui ne sont pas sécurisés pour les pages normales, il faut réfléchir davantage à ce que vous laissez votre utilisateur faire et ne pas faire, à la façon dont vous lui faites confiance, aux contrôles supplémentaires que vous pouvez effectuer (par exemple, si vous voyez un changement d'adresse IP, vous pouvez arrêter de lui faire confiance jusqu'à ce qu'il se reconnecte à partir de la page de sécurité).

Référence :
Un pirate peut-il voler le cookie d'un utilisateur et se connecter avec ce nom sur un site web ?

Comment vérifier d'où viennent les attaques venir et ne pas rendre les informations. J'ai écrit ici un moyen simple d'empêcher le rembourrage est invalide et la journalisation en même temps pour traquer les attaquants : CryptographicException : Le rembourrage n'est pas valide et ne peut être supprimé et la validation du MAC viewstate a échoué

Le moyen de repérer l'attaquant est de vérifier que le rembourrage n'est pas valide. Avec une procédure simple, vous pouvez les traquer et les bloquer - ils ont besoin de quelques milliers d'appels sur votre page pour trouver la clé !

Mise à jour 1.

J'ai téléchargé l'outil qui doit trouver la clé et décrypter les données, et comme je l'ai dit, il est piégé sur le site de l'entreprise. Le code ci-dessus vérifie l'état de la vue . D'après mes tests, cet outil a encore beaucoup de choses à corriger, par exemple, il ne peut pas scanner l'état de la vue compressée telle qu'elle est et il se plante lors de mes tests.

Si quelqu'un essaie d'utiliser cet outil ou cette méthode, le code ci-dessus peut le repérer et vous pouvez le bloquer hors de votre page avec un code simple comme celui-ci "Prévenir le déni de service (DOS)" ou comme ce code pour prévenir le déni de service .

Mise à jour 2

Il semble, d'après ce que j'ai lu jusqu'à présent, que la seule chose qui est vraiment nécessaire est de ne pas donner d'information sur l'erreur. et juste placez une page d'erreur personnalisée et si vous le souhaitez, vous pouvez créer et un délai aléatoire à cette page.

une vidéo très intéressante sur cette question.

Ainsi, tout ce qui précède constitue une mesure supplémentaire pour plus de protections, mais n'est pas nécessaire à 100% pour ce problème particulier. Par exemple, l'utilisation de cookies SSL résout le problème du snif, le fait de ne pas mettre en cache les rôles dans les cookies permet de ne pas envoyer et recevoir de gros cookies, et pour éviter que quelqu'un qui a déjà craqué le code, il suffit de placer le rôle d'administrateur sur le cookie de cette personne.

La piste de l'état de vue est juste une mesure de plus pour trouver l'attaque.

Answer 4

Ici est la réponse de la SEP. Tout se résume à "utiliser une page d'erreur personnalisée" et vous ne donnerez aucun indice.

EDIT
Ici voici des informations plus détaillées de scottgu.

Answer 5

Ajout des réponses de ScottGu, extraites de la discussion à l'adresse suivante http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx

Le module IHttpModule personnalisé au lieu de customErrors est-il concerné ?

Q : Je n'ai pas d'élément déclaré dans mon web.config, j'ai plutôt un IHttpModule à l'intérieur de la section. Ce module enregistre l'erreur et redirige soit vers une page de recherche (pour les 404), soit vers une page d'erreur (pour les 500). Suis-je vulnérable ?

R : Je recommanderais de mettre temporairement à jour le module pour qu'il redirige toujours vers la page de recherche. L'une des façons dont cette attaque fonctionne est qu'elle cherche à différencier les erreurs 404 et 500. Le fait de toujours renvoyer le même code HTTP et de les envoyer au même endroit est une façon de contribuer à la bloquer.

Notez que lorsque le correctif sortira, vous n'aurez pas besoin de faire cela (et pourrez revenir à l'ancien comportement). Mais pour l'instant, je recommande aux clients de ne pas faire la différence entre 404 et 500.

Puis-je continuer à utiliser des erreurs différentes pour les erreurs 404 et 500 ?

Q : J'en déduis que nous pouvons toujours avoir une page 404 personnalisée définie en plus de la redirection par défaut sur erreur, sans violer les principes décrits ci-dessus ?

R : Non - jusqu'à ce que nous publiions un correctif, nous recommandons la solution de contournement ci-dessus qui homogénéise toutes les erreurs. L'une des façons dont cette attaque fonctionne est qu'elle cherche à différencier les erreurs 404 et 500. Le fait de renvoyer toujours le même code HTTP et de les envoyer au même endroit est une façon de contribuer à la bloquer.

Notez que lorsque le correctif sortira, vous n'aurez pas besoin de faire cela (et pourrez revenir à l'ancien comportement). Mais pour l'instant, vous ne devez pas faire la différence entre 404 et 500 pour les clients.

Comment cela permet-il d'exposer le web.config ?

Q : Comment cela permet-il d'exposer le web.config ? Cela semble permettre le décryptage de ViewState uniquement, existe-t-il une autre vulnérabilité connexe qui permet également la divulgation d'informations ? Existe-t-il un livre blanc qui détaille l'attaque pour une meilleure explication de ce qui se passe ?

R : L'attaque qui a été montrée au public repose sur une fonctionnalité d'ASP.NET qui permet de télécharger des fichiers (généralement javascript et css), et qui est sécurisée par une clé envoyée dans le cadre de la requête. Malheureusement, si vous êtes capable de forger une clé, vous pouvez utiliser cette fonctionnalité pour télécharger le fichier web.config d'une application (mais pas les fichiers en dehors de l'application). Nous publierons évidemment un correctif pour ce problème. En attendant, la solution de contournement ci-dessus permet de fermer le vecteur d'attaque.

EDIT : une FAQ supplémentaire est disponible dans le deuxième billet de blog à l'adresse suivante http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-about-the-asp-net-security-vulnerability.aspx