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

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

ScottGu a des liens pour les téléchargements

[Mise à jour 2010-09-25]

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

Assurez-vous de fournir une page d’erreur personnalisée afin qu’un attaquant ne soit pas exposé à des erreurs internes .Net, que vous devriez toujours utiliser en mode édition / production.

De plus, ajoutez un temps de repos aléatoire dans la page d’erreur pour empêcher l’attaquant de synchroniser les réponses pour obtenir des informations supplémentaires sur les attaques.

Dans web.config

Cela redirecta 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 prudent de définir customErrors mode="RemoteOnly" , car cela redirecta 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. Cela vous oblige à définir explicitement l’atsortingbut defaultRedirect sur la 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 à partir de votre application Web. En général, web.config est une cible et peut contenir des informations sensibles telles que les informations de connexion dans une chaîne de connexion à une firebase database, ou même un lien vers une firebase database sql-express automatique que vous ne voulez pas que quelqu’un récupère. Mais si vous suivez les meilleures pratiques, vous utilisez Protected Configuration pour chiffrer toutes les données sensibles de votre site web.config.

Liens aux 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 plus de détails sur l’implémentation de 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 de rembourrage”, 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 du site Web dispose d’un oracle qui, lorsqu’il est envoyé en texte chiffré, décrypte non seulement le texte mais envoie un message à l’expéditeur pour savoir si est valide

Si le remplissage est invalide, le message d’erreur reçu par l’expéditeur lui donnera des informations sur le fonctionnement du processus de déchiffrement du site.

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

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

Donc, si vous renvoyez des messages d’erreur lisibles par l’homme dans votre application, par exemple “Quelque chose ne va pas, veuillez réessayer”, alors vous devriez être en sécurité. Lire un peu sur les commentaires de 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 firebase database)
• Ajoutez une attente aléatoire lorsque les informations utilisateur sont incorrectes avant de renvoyer l’erreur, vous ne pouvez donc pas le 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 effectivement 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 chiffrée en tant que paramètre – que le paramètre soit un cookie ou un paramètre url ou autre chose. Lorsque l’application essaie de le décoder, trois résultats sont possibles –

1. Résultat 1 : la chaîne cryptée est décryptée correctement et l’application est capable de la comprendre. Signification, 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 du charabia que l’application ne pouvait pas comprendre. Par exemple, la chaîne décryptée en “abcd1213ef”, mais l’application n’attendait que des chiffres. La plupart des applications afficheront un message comme “Numéro de compte invalide”.

3. Résultat 3 : Le remplissage était incorrect et l’application a envoyé une sorte de message d’erreur. La plupart des applications afficheront un message générique comme “Une erreur est survenue”.

Pour qu’une attaque Oracle Padding réussisse, l’attaquant doit être capable de faire plusieurs milliers de requêtes et doit pouvoir classer la réponse dans l’une des 3 zones 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. C’est juste une question de temps.

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

1. Chose la plus simple – tout ce qui est sensible ne devrait 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 apparaissent exactement de la même manière que l’attaquant. Il ne devrait y avoir aucun moyen de comprendre l’un de l’autre. Ce n’est pas si simple qu’un attaquant peut discriminer en utilisant une sorte d’attaque de synchronisation.

3. En tant que dernière ligne de défense, disposez d’un pare-feu applicatif Web. L’attaque de l’oracle de remplissage a besoin de 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 se trouve dans cet article . Disclaimer: 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 qui a déjà été connecté, quel que soit le compte. Ils ont également besoin de trouver des données dans les cookies – J’espère que les développeurs ne stockent pas les 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?

Un moyen d’empêcher cela est de ne pas autoriser le transport des cookies sans cryptage SSL.

Une autre mesure consiste également à éviter de stocker des rôles dans les cookies.

Maintenant, en ce qui concerne les cookies qui ne sont pas sécurisés pour les pages régulières, il faut réfléchir davantage à ce que vous avez laissé à votre utilisateur et à sa manière, à la vérification supplémentaire que vous pouvez effectuer (par exemple, si l’IP change). , peut-être arrêtez de lui faire confiance jusqu’à ce que vous vous reconnectiez à 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 donner d’informations. J’ai écrit ici un moyen simple d’empêcher le remplissage est invalide et la journalisation en même temps pour traquer les pirates: CryptographicException: Padding est invalide et ne peut pas être supprimé et la validation du viewstate MAC a échoué

La manière 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 milliers d’appels sur votre page pour trouver la clé!

Mise à jour 1.

J’ai téléchargé l’outil qui suppose que l’on trouve la clé et décrypte les données, et comme je dis son piège sur le code ci – dessus, il vérifie l’état d’affichage . De mes tests, cet outil a beaucoup plus à corriger, par exemple ne peut pas parsingr l’état de vue compressé tel qu’il est et son plantage lors de mes tests.

Si quelqu’un essaie d’utiliser cet outil ou cette méthode, le code ci-dessus peut les suivre et vous pouvez les bloquer hors de votre page avec un code simple comme celui-ci “Prevent Denial Of Service (DOS)” de service

Mise à jour 2

Il semble de ce que j’ai lu jusqu’à présent que le seul pense que c’est vraiment nécessaire 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 et retarder cette page.

une vidéo très intéressante sur ce sujet.

Donc, tout ce qui précède est plus important pour plus de protections, mais pas pour 100%. Par exemple, pour utiliser le cookie ssl, résolvez le problème de snif, ne mettez pas en cache les rôles dans les cookies, il est préférable de ne pas envoyer et récupérer les gros cookies, et d’éviter le cookie de lui.

Le trackstate suit sa juste mesure pour trouver une attaque.

Voici la réponse de MS. Tout se résume à “utiliser une page d’erreur personnalisée” et vous ne dévoilerez aucun indice.

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

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

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

Q: Je n’ai pas d’élément déclaré dans mon fichier web.config, j’ai plutôt un IHttpModule dans 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 recommande de mettre à jour temporairement le module pour toujours redirect vers la page de recherche. Une des façons dont cette attaque fonctionne est celle de la différenciation entre les erreurs 404 et 500. Toujours retourner le même code HTTP et l’envoyer au même endroit est un moyen de le bloquer.

Notez que lorsque le correctif sort pour résoudre ce problème, vous n’aurez pas à le faire (et vous 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 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 publiions un correctif pour le correctif réel, nous recommandons la solution de contournement ci-dessus qui homogénéise toutes les erreurs. Une des façons dont cette attaque fonctionne est celle de la différenciation entre les erreurs 404 et 500. Toujours retourner le même code HTTP et l’envoyer au même endroit est un moyen de le bloquer.

Notez que lorsque le correctif sort pour résoudre ce problème, vous n’aurez pas à le faire (et vous pourrez revenir à l’ancien comportement). Mais pour l’instant, vous ne devez pas différencier 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échiffrement de ViewState uniquement, y a-t-il une autre vulnérabilité connexe qui permet également la divulgation d’informations? Y a-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é d’ASP.NET qui permet de télécharger des fichiers (généralement javascript et css), qui sont sécurisés avec une clé envoyée dans le cadre de la requête. Malheureusement, si vous parvenez à falsifier une clé, vous pouvez utiliser cette fonctionnalité pour télécharger le fichier web.config d’une application (mais pas les fichiers extérieurs à l’application). Nous publierons évidemment un patch pour cela – jusque-là, la solution ci-dessus ferme le vecteur d’attaque.

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

IMO, il n’y a pas de prévention transversale pour cela, elle doit être traitée au cas par cas:

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

Quelques liens significatifs:

• Avis de sécurité de MS 2416728 (il s’agit des informations officielles)
• Informations complémentaires de l’équipe de recherche et de défense de MS
  • “Comprendre la vulnérabilité ASP.NET” (2010-09-17)
  • “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 cette question (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 les cookies d’état de session et 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 scope 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.-à-d. Pas beaucoup de limite). Pendant ce temps, l’attaquant peut modifier (ou injecter) des valeurs dans ViewState et modifier 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 fermes Web (toutes les instances de la batterie pouvant gérer n’importe quelle session utilisateur), la clé doit être codée en dur dans web.config :

 [...]   

Ce sont, bien sûr, les nouvelles clés 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écryptage.)

En plus de modifier les pages d’erreurs publiques pour ne pas générer d’erreur spécifique, il semblerait opportun de modifier les clés ci-dessus (ou de modifier les processus de travail s’ils ont été exécutés pendant un certain temps).

[Modifier 2010-09-21: liens ajoutés en haut]

Je viens juste de poster mes commentaires sur mon blog , après des recherches supplémentaires sur la question. Je pense qu’il est important de savoir pourquoi ils vont jusqu’à forger un cookie.

Je veux juste obtenir des faits clairs:

1. l’attaque ne vous permet pas d’obtenir directement la clé de la machine. Cela dit, c’est un peu comme ça, car il permet de décrypter les messages et de modifier les nouveaux chiffrements.
2. La manière d’obtenir les clés réelles est d’utiliser leur capacité à modifier re / encrypt comme dans 1 et à obtenir le fichier web.config. Malheureusement, il y a 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, elles bénéficient de la valeur par défaut de DotnetNuke.
3. pour obtenir le fichier web.config, tout 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 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 étant dit, je ne sais pas si l’une des autres fonctionnalités d’asp.net donne des informations différentes avec la solution de contournement, c’est-à-dire que je ne sais pas si le remplissage donne des résultats incorrects. si c’est le cas ou non … la même parsing devrait s’appliquer au cookie de session.
5. Rôles des caches du fournisseur de membres asp.net dans les cookies, désactivez cette option.

Environ 1, les messages chiffrés ne doivent pas nécessairement être arbitraires à 100% pour tolérer un petit bout de papier quelque part dans le message, car il y a 1 bloc dans le message qui décrypte la valeur qui ne peut être contrôlée.

Enfin, je voudrais dire que cette question est le résultat de la non-observation de ses propres conseils dans ce cas: une fonctionnalité repose sur une information inviolable envoyée au client.

Plus sur:

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

Le cookie d’authentification est signé et, à partir des informations contenues dans le document, il ne devrait pas être en mesure de générer un cookie signé s’il ne parvient pas aux clés actuelles (comme dans la vidéo avant la création du cookie d’authentification).

Comme Aristos l’a mentionné, pour l’identifiant de session dans le cookie, cela est aléatoire pour la session utilisateur, il doit donc être détecté par 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 atsortingbuer / autoriser les opérations utilisateur, l’impact sera minime / cela dépend 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 d’Oracle?