Bonjour,
Depuis quelques jours, si comme moi vous passez votre vie derrière un écran,
une nouvelle très inquiétante circulait sur Internet disant que tout site web utilisant un framework tel qu'ASP.NET et donc DotNetNuke par extension, mais aussi JSP était exposé à une sérieuse vulnérabilité. En exploitant une technique connue depuis 2002 dite de l'Oracle, les frameworks utilisant un cryptage symètrique pour leurs données sensibles (mot de passe, View State, CAPTCHA, etc.) pourraient être décrypté assez facilement. Ceci, vous le devinez, expose quasiment tous les sites modernes de la planète !
Ces deux "soit disant" chercheurs en sécurité, ont voulu réserver la primeur des détails de leur découverte pour la conférence
ekoparty qui a eu lieu vendredi dernier à Buenos Aires. Je précise "soit disant" entre guillemets -
et ceci n'engage que moi - car il s'agit plutôt de deux petits connards à qui l'on devrait botter le cul sérieusement ! Tout expert réel en sécurité respecte une ethique professionnelle et fourni les données de ses recherches aux éditeurs de logiciels AVANT de les révéler au grand public ! Ceci permet d'éviter les fameux "Zero days" et d'exposer inutilement les utilisateurs aux risques de piratage. Pire, l'un de ces petits cons, a même indiqué sur Twiter qu'ils feraient la démonstration de la vulnérabilité d'ASP.NET sur ... DotNetNuke !!! Non seulement c'est ce qu'ils ont fait à la conférence, mais ils ont aussi publié une vidéo sur YouTube ainsi que des outils pour faciliter encore la tâche des pirates !
Evidement, Microsoft et tous les grands éditeurs y compris le team DotNetNuke ont sûrement passés une sale nuit ainsi qu'un très mauvais week-end. Pour ma part, j'ai eu quelques échanges avec Cathal Connolly en charge de la sécurité chez DotNetNuke Corp suite à son
premier blog ainsi que par courriel. Scott Guthrie de chez Microsoft a aussi publié un
billet sur son blog, suivi de
plusieurs autres alertes sur les différents sites relatif à la sécurité chez Microsoft.
Vous pouvez lire le
second blog de Cathal expliquant comment se protéger sur le site de DNN US. Il reprend globalement les informations du blog de Scott Guthrie avec quelques explications spécifiques à DNN pour déterminer facilement la version de votre framework .NET utilisé. Par ailleurs, Shaun Walker (le créateur de DNN) a lui aussi publié un
billet expliquant pourquoi le site US a été arrêté plusieurs heures afin de le protéger pour éviter que les données des comptes utilisateurs (entre autres) puissent être exposées. Soyez assuré que le team DNN travaille en étroite relation avec les équipes concernées chez Microsoft et que ces dernières préparent un correctif dont la disponibilité n'est pas encore annoncée. Dans les jours qui viennent, une version 5.5.1 de DNN corrigeant la vulnérabilité sera publiée sur Codeplex.
Pour les non Anglophones, voici les étapes à suivre pour protéger vos instances de DNN ainsi que toutes applications ASP.NET (y compris SharePoint) :
Spécifique DNN
- Connectez-vous en tant que host sur votre instance DNN.
- Allez dans le menu Hôte > Configuration.
- Dans la première section Paramètres de base > Informations sytème, notez le numéro du framework .NET utilisé.
Commun à toutes les applications ASP.NET
Pour les versions : 1.0, 1.1, 2.0 et 3.5 suivez la procédure 1 ci-après.
Pour les versions : 3.5 SP1et 4.0 suivez la procédure 2.
Commencez par arrêter votre site ! Le plus simple étant d'arrêter le service de publication web de Windows Server, ce qui aura pour effet d'arrêter tous les sites présents sur ce serveur. Alternativement, arrêter le site via IIS.
Procédure 1
- Ouvrir le fichier web.config qui se trouve à la racine du site.
- Rechercher la chaîne "customErrors".
- Vous devriez avoir la ligne suivante utilisé par défault :
<customErrors mode="RemoteOnly" />
- Remplacer celle-ci par la ligne suivante :
<customErrors mode="On" defaultRedirect="~/error.html" />
- Créer une simple page HTML conforme avec votre éditeur favori indiquant qu'une erreur est survenue sans plus de détail.
- Placer cette page à la racine de votre site.
- Redémarrer le service ou le site via IIS.
- Dormez tranquille, c'est tout !
Procédure 2
- Ouvrir le fichier web.config qui se trouve à la racine du site.
- Rechercher la chaîne "customErrors".
- Vous devriez avoir la ligne suivante utilisé par défault :
<customErrors mode="RemoteOnly" />
- Remplacer celle-ci par la ligne suivante :
<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/error.aspx" />
- Créer une simple page ASPX conforme avec votre éditeur favori indiquant qu'une erreur est survenue sans plus de détail. Un exemple de page plus défensive est disponible sur le blog de Scott Guthrie cité plus haut.
- Placer cette page à la racine de votre site.
- Redémarrer le service ou le site via IIS.
- Dormez tranquille, c'est tout !
Je continue de suivre cette affaire de très près et vous tiendrais informé des évolutions. En attendant, je vais aller me coucher car il est bien tôt !
Votre dévoué,
Gilles Le Pigocher