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

Je viens de lire sur le net une faille de sécurité récemment découverte dans ASP.NET. Vous pouvez lire les détails ici.

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

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

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

Dans l'ensemble, je ne connais pas assez le sujet de la sécurité / cryptographie pour savoir si c'est vraiment si grave.

Alors, tous les développeurs ASP.NET devraient-ils 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? Cela nous affecte-t-il du tout? Dans la vraie vie, quelles sont les conséquences de cette vulnérabilité? Et, enfin: existe-t-il une solution de contournement qui empêche cette vulnérabilité?

Merci pour vos réponses!

EDIT: Permettez-moi de résumer les réponses que j'ai reçues

Il s'agit donc essentiellement d'une attaque de type "oracle de remplissage". @Sri a fourni une excellente explication sur ce que signifie ce type d'attaque. Voici une vidéo choquante sur le problème!

A propos de la gravité de cette vulnérabilité: Oui, c'est vraiment grave. Il permet à l'attaquant de connaître la clé machine d'une application. Ainsi, il peut faire des choses très indésirables.

• En possession de la clé machine de l'application, l'attaquant peut décrypter les cookies d'authentification.
• Pire encore, il peut générer des cookies d'authentification avec le nom de n'importe quel utilisateur. Ainsi, il peut apparaître comme n'importe qui sur le site. L'application est incapable de faire la différence entre vous ou le pirate informatique qui a généré un cookie d'authentification avec votre nom pour lui-même.
• Cela lui permet également de décrypter (et également de générer) des cookies de session , bien que ce 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!)
• Assez inattendu : avec la connaissance de la clé de la machine, l'attaquant peut télécharger n'importe quel fichier arbitraire depuis votre application Web, même ceux qui ne peuvent normalement pas être téléchargés! (Y compris Web.Config , etc.)

Voici un tas de bonnes pratiques qui ne résolvent pas le problème mais aident à améliorer la sécurité générale d'une application Web.

• Vous pouvez crypter les données sensibles avec la configuration protégée
• Utiliser les cookies HTTP uniquement
• Empêcher les attaques DoS

Maintenant, concentrons-nous sur ce problème.

• Scott Guthrie a publié une entrée à 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 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 seule page d'erreur vers laquelle toutes les erreurs sont redirigées. Oui, même les 404 . (ScottGu a dit que la différenciation entre les 404 et les 500 est essentielle pour cette attaque.) Aussi, dans votre Application_Errorou Error.aspxmettez du code qui crée un retard aléatoire. (Générez un nombre aléatoire et utilisez Thread.Sleep pour dormir aussi longtemps.) Cela rendra impossible pour l'attaquant de décider ce qui s'est exactement passé 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é dans l'implémentation AES. En fait, ce n'est pas du tout recommandé .

Quelques autres pensées

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

Merci à tous ceux qui ont répondu à ma question. J'ai beaucoup appris non seulement sur ce problème, mais aussi sur la sécurité 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.

Que dois-je faire pour me protéger?

[Mise à jour du 29/09/2010]

Bulletin de sécurité Microsoft

Article de la base de connaissances faisant référence au correctif

ScottGu a des liens pour les téléchargements

[Mise à jour 2010-09-25]

En attendant le correctif, ScottGu a publié hier 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.

Ajoutez en outre un temps d'attente aléatoire dans la page d'erreur pour empêcher l'attaquant de chronométrer les réponses pour des informations d'attaque supplémentaires.

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 d'erreur pour obtenir les informations nécessaires à d'autres attaques.

Il est également sûr de le définir customErrors mode="RemoteOnly", car cela redirigera les «vrais» clients. Seule la navigation à partir de localhost affichera des erreurs .Net internes.

La partie importante est de s'assurer que toutes les erreurs sont configurées pour renvoyer la même page d'erreur. Cela vous oblige à définir explicitement l' defaultRedirectattribut sur la <customErrors>section et à vous assurer qu'aucun code par statut n'est défini.

Ce qui est en jeu?

Si un attaquant parvient à utiliser l'exploit mentionné, il peut télécharger des fichiers internes depuis votre application Web. En règle générale, web.config est une cible et peut contenir des informations sensibles telles que des informations de connexion dans une chaîne 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 se mette la main. Mais si vous suivez les meilleures pratiques, utilisez la configuration protégée pour crypter toutes les données sensibles de votre web.config.

Liens vers des références

Lisez le commentaire officiel de Microsoft sur la vulnérabilité à l' adresse http://www.microsoft.com/technet/security/advisory/2416728.mspx . Plus précisément, la partie «Contournement» pour les détails d'implémentation sur ce problème.

Aussi quelques informations sur le blog de ScottGu , y compris un script pour trouver des applications ASP.Net vulnérables sur votre serveur Web.

Pour une explication sur «Comprendre les attaques Oracle Padding», lisez la réponse de @ sri .

Commentaires sur l'article:

L'attaque que Rizzo et Duong ont implémentée contre les applications ASP.NET nécessite que l'implémentation cryptographique sur le site Web ait un oracle qui, lorsqu'il est envoyé, non seulement déchiffrera le texte, mais donnera à l'expéditeur un message indiquant si le remplissage dans le texte chiffré est valide .

Si le remplissage n'est pas valide, le message d'erreur que l'expéditeur reçoit lui donnera des informations sur le fonctionnement du processus de déchiffrement du site.

Pour que l'attaque fonctionne, ce qui suit doit être vrai:

• Votre application doit envoyer un message d'erreur indiquant que le remplissage n'est pas valide.
• Quelqu'un doit falsifier vos cookies cryptés ou viewstate

Donc, si vous renvoyez des messages d'erreur lisibles par l'homme dans votre application, comme "Un problème est survenu, veuillez réessayer", vous devriez être assez prudent. La lecture un peu des 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 (persistant dans une base de données)
• Ajoutez une attente aléatoire lorsque les informations utilisateur sont fausses avant de renvoyer l'erreur, vous ne pouvez donc pas la chronométrer

De cette façon, un cookie détourné ne peut être utilisé que pour récupérer une session qui n'est probablement plus présente ou invalidée.

Il sera intéressant de voir ce qui est réellement présenté à la conférence Ekoparty, mais pour le moment je ne suis pas trop inquiet de cette vulnérabilité.

Comprendre les attaques Oracle Padding

Supposons que votre application accepte une chaîne cryptée en tant que paramètre - que le paramètre soit un cookie, un paramètre d'url ou autre chose est indifférent. Lorsque l'application tente de le décoder, il y a 3 résultats possibles -

1. Résultat 1 : la chaîne cryptée a été décryptée correctement et l'application a pu en comprendre le sens. Cela signifie que si la chaîne cryptée était un numéro de compte à 10 chiffres, après le décryptage, l'application a trouvé quelque chose comme "1234567890" et non "abcd1213ef"

2. Résultat 2 : le remplissage était correct, mais après le déchiffrement, la chaîne obtenue était un charabia que l'application ne pouvait pas comprendre. Par exemple, la chaîne a été déchiffrée en "abcd1213ef", mais l'application n'attendait que des chiffres. La plupart des applications afficheront un message du type "Numéro de compte invalide".

3. Résultat 3 : le remplissage était incorrect et l'application a lancé une sorte de message d'erreur. La plupart des applications afficheront un message générique comme "Une erreur s'est produite".

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'un des 3 compartiments ci-dessus sans erreur.

Si ces deux conditions sont remplies, l'attaquant peut éventuellement déchiffrer le message, puis le rechiffrer avec ce qu'il veut. C'est juste une question de temps.

Que peut-on faire pour l'empêcher?

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

2. Assurez-vous que le résultat 2 et le résultat 3 de la liste ci-dessus sont exactement les mêmes pour l'attaquant. Il ne devrait y avoir aucun moyen de comprendre l'un de l'autre. Ce n'est pas si simple, cependant - un attaquant peut discriminer en utilisant une sorte d'attaque chronométrée.

3. Comme dernière ligne de défense, ayez un pare-feu d'application Web. L'attaque d'oracle de remplissage doit faire plusieurs requêtes qui semblent presque similaires (en changeant un bit à la fois), il devrait donc être possible pour un WAF d'attraper et de bloquer de telles requêtes.

PS Une bonne explication de Padding Oracle Attacks peut être trouvée dans ce billet de blog . Avertissement: Ce n'est PAS mon blog.

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

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

Ils ont besoin du cookie crypté d'un utilisateur déjà connecté, sur n'importe quel compte. Ils doivent également 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 en ligne s'il ne met pas la main sur les données du navigateur? Ou renifler le paquet IP?

Une façon d'éviter cela est de ne pas autoriser le transport des cookies sans cryptage SSL.

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

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

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

Maintenant, à propos des cookies qui ne sont pas sécurisés pour les pages régulières, cela nécessite un peu plus de réflexion sur ce que vous avez laissé votre utilisateur faire et ce qui ne l'est pas, comment vous lui faites confiance, quelle vérification supplémentaire vous pouvez faire (par exemple si vous voyez un changement sur l'ip , peut-être arrêter de lui faire confiance jusqu'à ce que vous vous reconnectiez depuis 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 et ne pas rendre d'informations. J'ai écrit ici un moyen simple d'éviter que le remplissage ne soit invalide et que la journalisation en même temps pour traquer les attaquants: CryptographicException: le remplissage est invalide et ne peut pas être supprimé et la validation de viewstate MAC a échoué

La façon de suivre l'attaquant est de vérifier que le remplissage n'est pas valide. Avec une procédure simple, vous pouvez les retrouver et les bloquer - ils ont besoin de quelques milliers d'appels sur votre page pour trouver la clé!

Mettre à jour 1.

J'ai téléchargé l'outil qui suppose qu'il trouve la clé et décrypte les données, et comme je le dis, son piège sur le code ci - dessus qui vérifie l'état de la vue . D'après mes tests, cet outil a beaucoup plus à corriger, par exemple ne peut pas analyser l'état de vue compressé tel quel et son crash sur mes tests.

Si quelqu'un essaie d'utiliser cet outil ou cette méthode, le code ci-dessus peut les retrouver et vous pouvez les bloquer hors de votre page avec un code simple comme celui-ci "Empêcher le déni de service (DOS)" , ou comme ce code pour empêcher le déni de service .

Mise à jour 2

D'après ce que j'ai lu jusqu'à présent, il semble que le seul pense qu'il en soit vraiment besoin pour ne pas donner d'informations sur l'erreur , et simplement placer une page d'erreur personnalisée et si vous le souhaitez, vous pouvez simplement créer un délai aléatoire vers cette page.

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

Donc, tout ce qui précède sa mesure plus pour plus de protections mais pas 100% nécessaire pour ce problème particulier. Par exemple, utiliser un cookie ssl consiste à résoudre le problème snif, à ne pas mettre en cache les rôles dans les cookies, il est bon de ne pas envoyer et de récupérer de gros cookies, et d'éviter que quelqu'un ait tout prêt à déchiffrer le code, de simplement placer le rôle d'administrateur sur le cookie de lui.

L'état de la vue suit sa juste une mesure supplémentaire pour trouver une attaque.

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

EDIT
Voici quelques informations plus détaillées de scottgu.

Ajout des réponses de ScottGu tirées de la discussion sur http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx

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

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

R: Je recommanderais de mettre à jour temporairement le module pour toujours rediriger vers la page de recherche. L'une des façons dont cette attaque fonctionne est de rechercher une différenciation entre les erreurs 404 et 500. Toujours renvoyer le même code HTTP et les envoyer au même endroit est un moyen de le bloquer.

Notez que lorsque le correctif sortira pour résoudre ce problème, vous n'aurez pas besoin de le faire (et pourrez revenir à l'ancien comportement). Mais pour le moment, je recommanderais de ne pas différencier les 404 et les 500 aux clients.

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

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

R: Non - jusqu'à ce que nous publions un correctif pour le correctif réel, 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 de rechercher une différenciation entre les erreurs 404 et 500. Toujours renvoyer le même code HTTP et les envoyer au même endroit est un moyen de le bloquer.

Notez que lorsque le correctif sortira pour résoudre ce problème, vous n'aurez pas besoin de le faire (et pourrez revenir à l'ancien comportement). Mais pour le moment, vous ne devriez pas faire la différence entre les 404 et les 500 pour les clients.

Comment cela permet-il l'exposition de web.config?

Q: Comment cela permet-il l'exposition de web.config? Cela semble permettre le décryptage de ViewState uniquement, existe-t-il une autre vulnérabilité liée 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é présenté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 avec une clé envoyée dans le cadre de la demande. Malheureusement, si vous êtes capable de falsifier 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 cela - jusqu'à ce que la solution de contournement ci-dessus ferme le vecteur d'attaque.

EDIT: FAQ supplémentaire disponible dans le deuxième article de blog à http://weblogs.asp.net/scottgu/archive/2010/09/20/frequent-asked-questions-about-the-asp-net-security-vulnerability.aspx

OMI, il n'y a pas de prévention générale pour cela, cela doit être traité au cas par cas:

http://www.onpreinit.com/2010/09/aspnet-vulnerability-workaround-flawed.html

Quelques liens significatifs:

• Avis de sécurité MS 2416728 (ce sont les informations officielles)
• Informations supplémentaires de l'équipe de recherche et de défense en matière de sécurité de MS
  • «Comprendre la vulnérabilité ASP.NET» (17/09/2010)
  • «Informations supplémentaires sur la vulnérabilité ASP.NET» (2010-09-20)
• Scott Gu: «Important: vulnérabilité de sécurité ASP.NET» (2010-09-18)

[Pour répondre à l'aspect sérieux de ceci (ce qui a été publié et les solutions de contournement sont couvertes par d'autres réponses).]

La clé attaquée est utilisée pour protéger à la fois l'état d'affichage et les cookies de session. Normalement, cette clé est générée en interne par ASP.NET avec chaque nouvelle instance de l'application Web. Cela limitera la portée des dommages à la durée de vie du processus de travail, bien sûr, pour une application chargée, cela pourrait prendre plusieurs jours (c'est-à-dire pas vraiment une limite). Pendant ce temps, l'attaquant peut modifier (ou injecter) des valeurs dans ViewState et changer sa session.

Encore plus sérieux si vous voulez que les sessions puissent s'étendre sur la durée de vie des processus de travail, ou autoriser les fermes Web (c'est-à-dire que toutes les instances de la batterie peuvent gérer n'importe quelle session utilisateur), la clé doit être codée en dur, cela se fait dans web.config:

[...]
  <system.web>
    <machineKey
        decryption="AES"
        validation="SHA1"
        decryptionKey="57726C59BA73E8A4E95E47F4BC9FB2DD"
        validationKey="158B6D89EE90A814874F1B3129ED00FB8FD34DD3"
      />

Ce sont, bien sûr, des clés nouvellement créées, j'utilise le PowerShell suivant pour accéder au générateur de nombres aléatoires cryptographiques Windows:

$rng = New-Object "System.Security.Cryptography.RNGCryptoServiceProvider"
$bytes = [Array]::CreateInstance([byte], 20)
$rng.GetBytes($bytes)
$bytes | ForEach-Object -begin { $s = "" } -process { $s = $s + ("{0:X2}" -f $_) } -end { $s}

(En utilisant une longueur de tableau de 20 pour la validation et 16 pour les clés de déchiffrement.)

En plus de modifier les pages d'erreur publiques pour ne pas divulguer l'erreur spécifique, il semblerait que le moment soit venu de modifier les clés ci-dessus (ou de cycle les processus de travail s'ils sont en cours d'exécution depuis un certain temps).

[Edit 2010-09-21: Ajout de liens vers le haut]

Je viens de publier mon point de vue complet sur ce sujet dans mon blog , après des recherches supplémentaires sur la question. Je pense qu'il est important de comprendre pourquoi ils vont jusqu'à forger un cookie d'authentification.

Je veux juste clarifier les faits:

1. l'attaque ne vous permet pas d'obtenir directement la clé de la machine. Cela dit, c'est à peu près comme cela avait été le cas, car il permet de décrypter les messages et de modifier / rechiffrer les nouveaux.
2. la façon dont obtenir les clés réelles est en utilisant leur capacité à modifier re / encrypt comme dans 1 et obtenir le web.config. Malheureusement, il y a des raisons pour lesquelles certains placent ces clés dans le web.config au niveau du site (discussion différente), et dans l'exemple de vidéo, ils bénéficient du fait que c'est la valeur par défaut de DotnetNuke.
3. pour obtenir le web.config tout là-bas indique qu'ils utilisent webresources.axd et / ou scriptresources.axd. Je pensais que cela fonctionnait uniquement avec des ressources intégrées, mais il semble que ce n'est tout simplement pas le cas.
4. si l'application est asp.net MVC, nous n'avons pas vraiment besoin de webresources.axd et / ou scriptresources.axd, donc ceux-ci peuvent être désactivés. Nous n'utilisons pas non plus viewstate. Cela dit, il m'est difficile de savoir si l'une des autres fonctionnalités asp.net donne des informations différentes avec la solution de contournement en place, c'est-à-dire que je ne sais pas si le remplissage donne des résultats invalides en erreur tandis que le remplissage valide entraîne un ticket d'authentification ignoré (je ne sais pas si c'est le cas ou non) ... la même analyse devrait s'appliquer au cookie de session.
5. Le fournisseur d'adhésion asp.net «met en cache» les rôles dans les cookies, désactivez cela.

Environ 1, afaik les messages cryptés ne peuvent pas être 100% arbitraires besoin de tolérer un minuscule morceau de déchets quelque part dans le message, car il y a 1 bloc dans le message qui décrypte la valeur qui ne peut pas être contrôlée.

Enfin, je voudrais dire que ce problème est le résultat du fait que ms ne suit pas ses propres instructions dans ce cas: une fonctionnalité repose sur le fait que quelque chose envoyé au client est inviolable.

Plus sur:

Je ne sais pas si le remplissage donne des résultats invalides en erreur lors du remplissage des résultats valides dans un ticket d'authentification ignoré (je ne sais pas si c'est le cas ou non) ... la même analyse devrait s'appliquer au cookie de session.

Le cookie d'authentification est signé et, à partir des informations contenues dans le papier, ils ne devraient pas être en mesure de générer un cookie signé s'ils n'atteignent pas les clés réelles (comme ils l'ont fait dans la vidéo avant de forger le cookie d'authentification).

Comme Aristos l'a mentionné, pour l'identifiant de session dans le cookie, c'est aléatoire pour la session utilisateur, il devrait donc être sniffé d'un utilisateur avec le niveau de sécurité cible et craqué pendant que cette session est active. Même dans ce cas, si vous comptez sur l'authentification pour attribuer / autoriser les opérations de l'utilisateur, l'impact serait minime / cela dépendrait beaucoup de l'utilisation de la session dans cette application.

Un correctif pour ce bogue a été publié sur Windows Update: http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx

Asp.Net MVC est également concerné par ce problème (tout comme Sharepoint, ...)

J'ai couvert le correctif pour MVC ici: ASP.NET MVC est-il vulnérable à l'attaque de remplissage d'oracle?