Je sais qu'il y a déjà quelques questions sur l'exploit Oracle Padding, mais aucun d'entre eux n'explique comment il télécharge le web.config. J'exécute quelques applications ASP .NET que j'ai déjà testées à l'aide de facteurs d'atténuation recommandés Microsoft, mais j'ai toujours peur que les gens puissent obtenir le web.config.
Quelqu'un peut-il s'il vous plaît expliquer comment ils le font ou fournissent même un lien vers un outil que je peux utiliser pour tester mon site. Je trouve que l'explication officielle de cette partie de l'attaque fait vraiment défaut.
L'attaque qui a été montrée dans le Public s'appuie sur une fonctionnalité de ASP.NET qui permet aux fichiers (typiquement JavaScript et CSS) à télécharger, et qui est sécurisé avec une clé que est envoyé dans le cadre de la demande. Malheureusement, si vous êtes capable de forger Une clé Vous pouvez utiliser cette fonctionnalité pour Téléchargez le fichier web.config d'un application (mais pas de fichiers en dehors de l'application).
6 Réponses :
"Un oracle dans le contexte de la cryptographie est un système qui procure des astuces que vous posez des questions." N'a rien à voir avec Oracle (le fabricant de logiciels). Oracle PR ne peut pas être trop heureux de la nomenclature ici ...
Ce message n'aide pas avec les détails sur web.config qui est ce que l'Asker veut savoir
Les gars - la réponse est qu'une fois qu'ils ont obtenu la machine à la machine, ils peuvent utiliser cette touche pour récupérer les fichiers à l'aide d'une autre fonctionnalité de ASP.NET
"Dans ASP.NET 3.5 Service Pack 1 et ASP.NET 4.0 Il existe une fonctionnalité utilisée pour servir des fichiers à partir de l'application. Cette fonctionnalité est normalement protégée par la clé de la machine. Toutefois, si la clé de la machine est compromise alors Cette fonctionnalité est compromise. Cela va directement sur ASP.NET et non IIS Les paramètres de sécurité de l'IIS ne s'appliquent pas. Une fois cette fonctionnalité compromise, alors l'attaquant peut télécharger des fichiers à partir de votre application - y compris le fichier web.config, qui contient souvent des mots de passe. < / p>
versions d'ASP.NET avant ASP.NET 3.5 SP1 ne possédez pas cette fonctionnalité, mais sont toujours vulnérables à l'attaque principale de la machine. "
(voir le message en bas d'ici: http://forums.asp.net /t/1603799.aspx de l'équipe ASP.NET)
Cette "fonctionnalité" semble être fournie par les fichiers webresource.axd et / ou scriptresource.axd.axd. Je n'ai pas vu de confirmation que la désactivation / l'élimination de ceux-ci fixera la question de la divulgation de fichiers Web.config, mais il semble probable. On dirait que l'attaque peut être en mesure de récupérer la clé de la machine, qui est la condition préalable à l'attaque de ces fichiers.
J'ai essayé d'utiliser l'approche webresource.axd avec les méthodes Clientscript et de ce que je peux dire, non seulement les fichiers que vous souhaitez servir de cette manière doivent être construits comme des ressources intégrées, mais vous devez Ajouter une déclaration dans l'assemblageInfo aussi. Si je ne fais rien de cela, comment cela fonctionne-t-il? Et comment obtient-il quelque chose de si critique que le web.config?
Ce blogpost est assez intéressant: http://www.gdssecurity.com/l/b/
a également lu ceci: Est-ce que cette nouvelle vulnérabilité de sécurité ASP.NET et comment puis-je contourner la solution?
afaik ça va comme ça:
Maintenant, autant que je sache, ceux-ci sont censés servir des ressources intégrées, mais je suppose que ce n'est pas le cas (Scott Gu a mentionné dans les commentaires de son poste, ce sont ceux utilisés dans l'attaque montrée). < / p>
Le message suivant peut être intéressant pour ce fil:
http: //blog.mindedsecurity. COM / 2010/10 / rupture-net-cryptage-with-ou-sans.html
FYI, un correctif de ce bogue a été publié sur Windows Update.
http://weblogs.asp.net/scotgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx
Eh bien, s'ils donnaient cette information, ce serait un peu dangereux!
Apparemment, c'est là-bas sur une vidéo mais je ne peux pas le trouver. L'information est déjà là pour le reste de l'exploit de toute façon.
Il n'est pas nécessaire de diffuser les informations via un site de questions-réponses publiques.
@redsquare Un peu d'un comportement d'autruche, tu ne penses pas?
@Anton Gogolev Pas du tout, ne pensez-vous pas qu'ils (Scott Gu et al) auraient publié cette information s'ils le souhaitaient dans le domaine public.
Tout ce que je cherche, c'est un moyen de tester si mon application est vulnérable. En tant qu'utilisateur de produit ASP.NET, je pense que c'est bien dans mes droits de pouvoir savoir si mon application est à risque et que je pense que la communauté des utilisateurs est le meilleur endroit pour poser et partager ces informations avec d'autres propriétaires de chantiers. Une personne qui veut utiliser l'exploit trouvera les informations, qu'il s'agisse de si ou non.
@Alex, le test serait d'essayer l'exploit - ils ne vont pas libérer comment faire cela. Il suffit de suivre le correctif «Temp '» telle qu'elle est détaillée dans son poste et attendez le correctif qui, en raison de la nature grave, devrait être assez rapide, j'espère!
@redsquare: Ce n'est pas assez bon. Et si vous avez exécuté un site de grande production ASP.NET, qui était peut-être aussi une entreprise que vous seriez d'accord.
@Cottsak - Qu'est-ce qui ne suffit pas, et comment dans votre sagesse supposez-vous que je n'exécute aucun "grand" sites asp.net!
"..Juste suivez la solution Temp." Pas assez bon! Ce correctif ne dit rien sur la façon d'empêcher le téléchargement web.config, ce que nous sommes tous aussi paniqués. Comment pouvez-vous penser que cela est satisfaisant?
@Cottsak - Errr Ne tirez pas sur le messager, allez vous plaindre à Scott Gu et à l'équipe ASP.NET. Je suppose que vous avez dirigé un grand site asp.net critique d'entreprise que vous n'appréciez pas les détails de la gestion de l'exploit posté ici?
Bien sûr je le ferais. Je peux donc prouver que je l'ai réparé. Pour moi, ce n'est pas assez que nous mettons en œuvre une "solution" mais plutôt prouver de manière concluante que nous avons "corrigé quelque chose".
@redsquare: Exploidit est déjà à l'état sauvage, et Solutions de contournement d'atténuation ont été postés - comment afficherait des détails d'exploitation? Les détails de l'OMHO pourraient être utiles afin de protéger davantage vos sites, 2) Évitez de faire certaines des mêmes erreurs dans votre propre code.
@Snemarch Comme je l'ai dit à l'autre Chap Moaning - Faites-vous au téléphone à Scott Gu et al ... Je ne travaille pas pour MS !!!
duplicatésible possible de