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 vulnérabilité de sécurité récemment découverte dans ASP.NET. Vous pouvez lire les détails ici.
Le problème réside dans la façon 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 demandes, 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 suffisamment le sujet de la sécurité/cryptographie pour savoir si c'est vraiment si grave.
Donc, 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 "padding Oracle". @ Sri a fourni une excellente explication sur ce que signifie ce type d'attaque. Voici une vidéo choquante sur le problème!
Concernant la gravité de cette vulnérabilité: oui, elle est en effet grave. Il permet à l'attaquant de connaître la clé machine d'une application. Ainsi, il peut faire des très indésirables des choses.
- 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 n'est pas en mesure 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.
- Il lui permet également de décrypter (et également de générer) les 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 de confidentialité, vous ne devriez pas le faire de toute façon!)
- Assez inattendu : Avec la connaissance de la clé machine, l'attaquant peut télécharger tout fichier arbitraire de 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 que j'ai obtenues 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 des données sensibles avec la configuration protégée
- tiliser des cookies HTTP uniquement
- Empêcher les attaques DoS
Maintenant, concentrons-nous sur cette question.
- Scott Guthrie a publié une entrée à ce sujet sur son blog
- ScottGu's FAQ article de blog 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 404s . (ScottGu a dit que la différenciation entre 404 et 500 est essentielle pour cette attaque.) Aussi, dans votre
Application_ErrorouError.aspxmettre du code qui fait un retard aléatoire. (Générez un nombre aléatoire et utilisez Thread.Sleep pour dormir aussi longtemps.) Cela empêchera 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. Il s'avère que ce n'est pas du tout recommandé .
Quelques autres réflexions
- Semble que pastout le monde pense que la solution de contournement est assez bonne.
Merci à tous ceux qui ont répondu à ma question. J'ai beaucoup appris non seulement sur ce problème, mais 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 2010-09-29]
Bulletin de sécurité Microsoft
KB Article avec référence au correctif
ScottG a des liens pour les téléchargements
[Mise à jour 2010-09-25]
Pendant que nous attendons le correctif, hier ScottGu postet an update sur la façon d'ajouter une étape supplémentaire pour protéger vos sites avec une règle URLScan personnalisée.
De plus, ajoutez un sommeil aléatoire dans la page d'erreur pour empêcher l'attaquant de chronométrer les réponses pour les informations d'attaque ajoutées.
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 à de nouvelles attaques.
Il est également sûr de définir customErrors mode="RemoteOnly", car cela redirigera les "vrais" clients. Seule la navigation depuis 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. Cela vous oblige à définir explicitement l'attribut defaultRedirect sur le <customErrors> section et assurez-vous 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 à partir de votre application Web. En règle générale, web.config est une cible et peut contenir des informations sensibles comme les informations de connexion dans une chaîne de connexion à la 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 saisisse. 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 http://www.Microsoft.com/technet/security/advisory/2416728.mspx . Plus précisément, la partie "Contournement" pour les détails de mise en œuvre sur ce problème.
Aussi quelques informations sur ScottGu's blog, y compris un script pour trouver des applications ASP.Net vulnérables sur votre serveur Web.
Pour une explication sur "Comprendre le remplissage des attaques Oracle", lisez @ sri's answer .
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 de la cryptographie sur le site Web ait un Oracle qui, une fois envoyé, le texte chiffré, non seulement déchiffrera le texte mais donnera à l'expéditeur un message indiquant si le remplissage du 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écryptage du site.
Pour que l'attaque fonctionne, les conditions suivantes doivent être remplies:
- Votre application doit donner un message d'erreur indiquant que le rembourrage n'est pas valide.
- Quelqu'un doit trafiquer vos cookies cryptés ou afficher l'état
Donc, si vous renvoyez des messages d'erreur lisibles par l'homme dans votre application comme "Quelque chose s'est mal passé, veuillez réessayer" alors vous devriez être en sécurité. La lecture un peu des commentaires sur l'article donne également des informations précieuses.
- Stocker un identifiant de session dans le cookie crypté
- Stockez les données réelles dans l'état de session (persisté dans une base de données)
- Ajoutez une attente aléatoire lorsque les informations utilisateur sont incorrectes avant de renvoyer l'erreur, de sorte que vous ne pouvez pas chronométrer
De cette façon, un cookie piraté 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é lors de la conférence Ekoparty, mais pour l'instant je ne suis pas trop inquiet de cette vulnérabilité.
Comprendre le remplissage des attaques Oracle
Supposons que votre application accepte une chaîne cryptée comme paramètre - que le paramètre soit un cookie, un paramètre d'URL ou autre chose est sans importance. Lorsque l'application essaie de le décoder, il y a 3 résultats possibles -
Résultat 1 : la chaîne chiffrée a été déchiffrée correctement et l'application a pu la comprendre. Signification, si la chaîne chiffrée était un numéro de compte à 10 chiffres, après le déchiffrement, l'application a trouvé quelque chose comme "1234567890" et non "abcd1213ef"
Résultat 2 : le remplissage était correct, mais après le déchiffrement, la chaîne obtenue était du 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 affichent un message comme "Numéro de compte non valide".
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 "Une erreur s'est produite".
Pour qu'une attaque Padding Oracle réussisse, l'attaquant doit être en mesure de faire plusieurs milliers de demandes, et doit être capable de classer la réponse dans l'un des 3 seaux 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 souhaite. Ce n'est qu'une question de temps.
Que peut-on faire pour l'empêcher?
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.
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. Cependant, ce n'est pas si simple - un attaquant peut discriminer en utilisant une sorte d'attaque temporelle.
Comme dernière ligne de défense, disposez d'un pare-feu d'application Web. L'attaque de remplissage 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'intercepter et de bloquer ces requêtes.
P.S. Une bonne explication de Padding Oracle Attacks peut être trouvée dans ce billet de blog . Avertissement: Ce n'est PAS mon blog.
D'après ce que j'ai lu jusqu'à présent ...
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 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">
En ce qui concerne les 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 et ce qui ne l'est pas, sur la façon dont vous lui faites confiance, sur le contrôle supplémentaire que vous pouvez faire (par exemple si vous voyez un changement sur l'ip , peut-être arrêter de lui faire confiance jusqu'à ce qu'il se reconnecte à partir de la page de sécurité).
Référence:
n 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 donner d'informations. J'ai écrit ici un moyen simple d'éviter que le remplissage ne soit invalide et de se connecter en même temps pour traquer les attaquants: CryptographicException: le remplissage n'est pas valide et ne peut pas être supprimé et la validation du MAC viewstate 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é!
Mise à jour 1.
J'ai téléchargé l'outil qui suppose que c'est trouver la clé et décrypter les données, et comme je le dis son piège sur le ci-dessus le code 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 la vue compressée 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 "Prevent Denial Of 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 qui en ait vraiment besoin pour ne pas donner d'informations sur l'erreur , et juste placez une page d'erreur personnalisée et si vous le souhaitez, vous pouvez simplement créer et un retard aléatoire sur cette page.
ne vidéo très intéressante sur cette question.
Donc, tout ce qui précède est plus de mesure pour plus de protections, mais pas 100% nécessaires pour ce problème particulier. Par exemple, utiliser le cookie ssl résout le problème de snif, ne pas mettre en cache les rôles dans les cookies, il est bon de ne pas envoyer et récupérer de gros cookies, et d'éviter que quelqu'un qui soit prêt à casser le code, pour simplement placer le rôle d'administrateur sur le cookie de lui.
Le viewstate suit sa juste une mesure de plus pour trouver une attaque.
Ajout des réponses de ScottGu tirées de la discussion à http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx
Est-ce que IHttpModule personnalisé au lieu de customErrors est affecté?
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 vers une page de recherche (pour les 404) ou vers une page d'erreur (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 404 et 500 erreurs. Toujours renvoyer le même code HTTP et les envoyer au même endroit est un moyen d'aider à le bloquer.
Notez que lorsque le correctif sera corrigé, vous n'aurez pas besoin de le faire (et vous pourrez revenir à l'ancien comportement). Mais pour le moment, je recommande de ne pas faire de différence entre les 404 et les 500 pour les clients.
Puis-je continuer à utiliser différentes erreurs 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 violer les principes décrits ci-dessus?
R: Non - jusqu'à ce que nous publions un correctif pour le vrai 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 de rechercher une différenciation entre 404 et 500 erreurs. Toujours renvoyer le même code HTTP et les envoyer au même endroit est un moyen d'aider à le bloquer.
Notez que lorsque le correctif sera corrigé, vous n'aurez pas besoin de le faire (et vous pourrez revenir à l'ancien comportement). Mais pour le moment, vous ne devez pas différencier les 404 et les 500 des 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é 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 dans le public repose sur une fonctionnalité dans 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 pouvez créer une clé, vous pouvez utiliser cette fonction 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 - jusque-là, la solution de contournement ci-dessus ferme le vecteur d'attaque.
EDIT: supplémentaire FAQ disponible dans le deuxième blog à http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-about -the-asp-net-security-vulnérabilité.aspx
OMI, il n'y a pas de prévention généralisée pour cela, elle doit être gérée au cas par cas:
http://www.onpreinit.com/2010/09/aspnet-vulnerability-workaround-flawed.html
Quelques liens importants:
- Avis de sécurité MS 2416728 (ce sont les informations officielles)
- Informations supplémentaires de l'équipe de recherche et de défense de MS
- Scott Gu: "Important: Vulnérabilité de sécurité ASP.NET" (2010-09-18)
[Pour répondre à l'aspect sérieux de cela (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 l'étendue des dommages à la durée de vie du processus de travail, bien sûr, pour une application occupée, cela pourrait être des jours (c'est-à-dire pas beaucoup de limite). Pendant ce temps, l'attaquant peut modifier (ou injecter) des valeurs dans ViewState et changer sa session.
Plus grave encore, si vous souhaitez que les sessions puissent s'étendre sur la durée de vie des processus de travail ou autoriser les batteries de serveurs Web (c'est-à-dire que toutes les instances de la batterie de serveurs 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 faire tourner les processus de travail s'ils fonctionnent depuis un certain temps).
[Modifier 2010-09-21: Ajout de liens vers le haut]
Je viens de publier mon avis complet sur ce sujet dans mon blog , après des recherches supplémentaires sur le problème. Je pense qu'il est important de clarifier pourquoi ils vont jusqu'à forger un cookie d'authentification.
Je veux juste clarifier certains faits:
- l'attaque ne vous permet pas d'obtenir directement la clé de l'ordinateur. Cela dit, c'est à peu près comme il l'avait fait, car cela permet de décrypter les messages et de modifier de nouveau/de crypter les nouveaux.
- la façon d'obtenir les clés réelles est d'utiliser leur capacité à modifier re/encrypt comme dans 1 et à obtenir le web.config. Malheureusement, il existe des raisons pour lesquelles certains mettent ces clés dans le fichier web.config au niveau du site (discussion différente), et dans l'exemple de vidéo, ils bénéficient de la valeur par défaut de DotnetNuke.
- pour obtenir le web.config, il indique qu'ils utilisent webresources.axd et/ou scriptresources.axd. Je pensais que cela ne fonctionnait qu'avec des ressources intégrées, mais il semble que ce ne soit tout simplement pas le cas.
- si l'application est MVC asp.net, 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 n'est pas clair pour moi 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 par erreur alors 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.
- le fournisseur d'adhésion asp.net met en cache les rôles dans les cookies, désactivez-le.
Environ 1, afaik les messages cryptés ne peuvent pas être 100% arbitraires à tolérer un petit 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 quelque chose envoyé au client comme étant inviolable.
Plus sur:
Je ne sais pas si le remplissage donne des résultats invalides par 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.
Le cookie d'authentification est signé et à partir des informations contenues dans le document, ils ne devraient pas être en mesure de générer un cookie signé s'ils n'obtiennent 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'ID de session dans le cookie, c'est aléatoire pour la session utilisateur, il devrait donc être reniflé d'un utilisateur avec le niveau de sécurité cible et craqué pendant que cette session est active. Même alors, si vous comptez sur l'authentification pour affecter/autoriser les opérations utilisateur, l'impact serait minime/cela dépendrait beaucoup de la session utilisée 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 Oracle?