1 Fuite d'information des applications ASP.NET

Microsoft a publié cette semaine un bulletin de sécurité à propos d'une vulnérabilité non corrigée dans ASP.NET permettant le vol d'informations par des utilisateurs malveillants sur certaines applications ASP.NET. Parmi les informations pouvant être récupérées de façon illicite, on distingue les fichiers web.config qui contiennent souvent des données sensibles comme les informations de session et d'authentification, par exemple les identifiants pour accéder au serveur MS-SQL Server. Cette vulnérabilité permet aussi d'accéder à certaines données chiffrées envoyées aux clients, l'attaque est basée sur le principe des oracles cryptographiques, et prend donc un certain temps.

Un moyen de contournement pour se protéger de cette vulnérabilité est d'activer la balise <customErrors> et de configurer les applications pour toujours renvoyer la même page d'erreur, quelque soit la nature de l'erreur, en utilisant par exemple l'attribut defaultRedirect de la balise. Les moyens de contournement sont précisés dans le bulletin de sécurité Microsoft dont l'adresse est indiquée ci-dessous.

A noter que cette vulnérabilité est actuellement exploitée sur l'Internet.

Documentation

2 Mise à jour Adobe Flash Player

Cette semaine, une nouvelle version d'Adobe Flash Player a été publiée par l'éditeur. Cette mise à jour corrige la vulnérabilité qui a fait l'objet de l'alerte CERTA-2010-ALE-015. Pour rappel, cette faille permet l'exécution de code arbitraire à distance par une personne malintentionnée.

Cette vulnérabilité est exploitée sur l'Internet, le CERTA recommande donc de déployer rapidement ce correctif disponible pour toutes les plateformes supportées. Une mise à jour du lecteur de fichier PDF d'Adobe est prévue durant la semaine du 04 octobre, le lecteur reste donc pour l'instant vulnérable.

Documentation

3 Identification de machine via du code JavaScript

Cette semaine, a été publiée sur l'Internet la dernière version d'une API (Application Programming Interface) en JavaScript permettant la création de cookies particuliers rendant leur effacement difficile par un utilisateur non-averti. En effet, plutôt que d'utiliser les fonctions standards des navigateurs pour créer des cookies normaux, cette API propose d'engendrer un certains nombre de marqueurs spécifiques à différents endroits du navigateur afin de rendre plus persistante l'identification d'une machine. Ainsi, selon l'auteur, il est possible de poser des marqueurs :

  • dans le magasin de cookies standard ;
  • dans le Local Shared Objects qui sert à stocker les cookies pour les objets Flash ;
  • dans des images au format PNG créées à la volée par certaines fonctionnalités du langage HTML5 ;
  • dans les entrées de l'historique ;
  • lors du stockage des ETags HTTP ;
  • dans le conteneur userData d'Internet Explorer ;
  • dans différents magasins de stockage nécessaires au fonctionnement de HTML5 dans le navigateur : Session, Local, Global, Database.
Il est ainsi possible de rendre persistant un certain nombre de marqueurs ou cookies malgré les précautions de base qu'aurait pu prendre l'utilisateur du navigateur, et ce, entièrement à son insu.

Recommandations :

L'API détaillée ci-dessus est librement disponible en source ouverte sur l'Internet. Pour qu'elle fonctionne correctement sur le navigateur du client, il est toujours nécessaire que le navigateur support les JavaScripts et parfois le langage HTML5. Dans un contexte de confidentialité accrue, il conviendra donc, comme à l'habitude, de désactiver par défaut le support des codes JavaScript par le navigateur.

4 XSS sur Twitter, une régression grand public

Cette semaine un incident de sécurité touchant les utilisateurs du site social de microblogging Twitter a largement été médiatisé. Il s'agissait d'une vulnérabilité permettant une attaque en injection de code indirecte (Cf. Documentation). Ce qui est remarquable ici est que cette faille avait déjà été corrigée le mois dernier, il s'agit donc d'une régression. Dans le contexte du développement de logiciel, ce terme désigne un retour en arrière sur des corrections apportées. Il est souvent dû à une erreur de choix des versions des parties utilisées pour construire le produit dans sa globalité.

Cet incident met en avant le problème de l'évolution du niveau de confiance dans le temps. Que cela soit un site Internet ou une application, le cas de Twitter illustre bien que le niveau de sécurité peut fortement évoluer dans le temps. La confiance par défaut est donc à proscrire. Il convient de rester vigilant et attentif en toutes circonstances, et pour cela, il est important de bien connaître les sites ou logiciels utilisés afin de percevoir les changements.

Documentation

  • Définition provenant de securite-informatique.gouv.fr :

    Injection de code indirecte (Cross Site Scripting, CSS, XSS) : Activité malveillante qui consiste à injecter des données arbitraires dans le code de pages HTML. Un utilisateur malveillant peut faire afficher à un site web vulnérable un contenu agressif ; ce contenu peut rediriger l'utilisateur vers d'autres sites, ou transmettre des informations (jetons de sessions, aussi appelés cookies, etc) ou des droits.

  • Explications et excuses officielles de Twitter :
    http://blog.twitter.com/2010/09/all-about-onmouseover-incident.html
    

5 Un annonceur de publicités malveillantes

Le 19 et 20 septembre 2010, un grand nombre de sites Web malaisiens et indonésiens ont été listés comme potentiellement dangereux par Google, suite à la présence de code malveillant sur la plupart de leurs pages.

Le code malveillant se situait en fait dans les bandeaux publicitaires affichés à partir du serveur d'un fournisseur de bannières de publicité.

Le problème a pu être remonté à un annonceur particulier dont le serveur OpenX a été compromis, ce qui a permis à l'attaquant de placer le code malveillant au sein des bannières qui y sont hébergées. Celles-ci ont ensuite été transmises au fournisseur de publicité, puis intégrées de manière transparente sur les sites Web des clients.

Bien que ce type d'attaque ne soit pas nouveau, il est intéressant de noter ici le nombre de sites Web qu'il est possible de compromettre rapidement à partir d'une seule attaque réussie. Il convient bien évidemment d'être extrêmement vigilant lorsque du contenu extérieur est inséré automatiquement dans une page de son site.

Documentation

Rappel des publications émises

Dans la période du 13 septembre 2010 au 19 septembre 2010, le CERT-FR a émis les publications suivantes :


Durant la même période, les publications suivantes ont été mises à jour :