1 Activité en cours
1.1 Incidents
Le CERTA a traité cette semaine de nombreux cas de défiguration. Pour la plupart d'entre eux, la faille exploitée était de type php include et concernait un module optionnel du logiciel de gestion de contenu Mambo. Les attaques de ce type sont rendues possibles par des erreurs de programmation. Quand il existe un correctif, il est conseillé de l'appliquer. Toutefois, il arrive parfois que les applications vulnérables n'aient pas de correctif car leur développement a été abandonné. Il reste possible de bloquer les attaques de type php include en modifiant la configuration php du serveur web (par exemple en désactivant la variable REGISTER_GLOBALS) mais ceci peut avoir des conséquences sur le bon fonctionnement des serveurs. Il est aussi nécessaire de filtrer au niveau du pare-feu les connexions sortantes issues du serveur Web mettant en œuvre Mambo.
1.2 Le nettoyage du code source des pages Web
Le CERTA a traité cette semaine un incident concernant un site Web. Au cours de l'analyse, il est apparu que le code source des pages Web contenaient des informations facilitant d'éventuelles attaques contre ce site.
Le code source des pages Web est une information qui est généralement accessible par toute personne qui peut visualiser la page dans le navigateur.
Cependant, ce même code peut contenir, outre les données nécessaires, des indications sur la mise en œuvre du site, souvent incorporées dans des zones de commentaires.
La sécurité par l'obscurité, qui consiste à tout cacher en estimant qu'il s'agit d'une mesure de sécurité suffisante, n'est souvent pas la meilleure solution. Mais, dans le cas présent, il est aussi important d'éviter de tendre un bâton aux personnes malveillantes...
Les outils de développement de site (par exemple les systèmes de gestion de contenu, ou CMS), ne sont pas toujours bien maintenus et/ou mis à jour. Le fait de ne pas communiquer de manière triviale dans les commentaires du code source des pages le produit utilisé revient donc à réduire les risques, ou du moins, à rendre plus difficile une action malveillante.
Il est important de vérifier que de telles informations n'apparaissent pas, et de signaler cette exigence aux développeurs du site.
2 Des vulnérabilités non corrigées concernant Microsoft Visual Studio
2.1 Présentation
Des vulnérabilités sont apparues cette semaine, concernant Microsoft Visual Studio, mais ne sont pas encore corrigées. Compte tenu de l'application visée et de la mise en œuvre de l'attaque, elles ne font pas l'objet d'une alerte, mais en voici les détails, dans l'attente d'un avis du CERTA qui annoncera la disponilibité des correctifs. Elles concernent des fichiers avec des extensions bien précises :
- les fichiers d'extension .RC, contenant diverses informations sur un projet de Visual Studio : un champ trop long dans le fichier pourrait provoquer un débordement de tampon. Une personne malveillante qui parviendrait à inciter un utilisateur à ouvri r un tel fichier pourrait exécuter des commandes arbitraires sur le système à l'insu de ce dernier ;
- les fichiers d'extension .CNT, contenant les informations sur les fichiers d'aide ( Help File Contents) : une corruption de la mémoire est possible, quand l'application interprète certaines lignes du fichier qui devraient être dans un format bien déterminé ( '%d%s' : 1 DescriptionDuContenu).
- les fichiers d'extension .HPJ, contenant des informations d'aide contextuelle associée à un projet Visual Studio : une variable du fichier ne serait pas correctement contrôlée. Une personne malveillante pourrait profiter de ce problème pour provoquer un débordement de la pile mémoire et exécuter du code arbitraire sur le système vu lnérable.
Les versions affectées par ces vulnérabilités sont les suivantes :
- Microsoft Help Workshop version 4.03.0002 ainsi que celles antérieures ;
- Microsoft Visual Studio 6.0 SP6 ;
- Microsoft Visual Studio 2003 (.NET).
2.2 Recommandations du CERTA
Dans l'attente d'un correctif, il est préférable :
- de manipuler des fichiers avec les extensions .RC, .CNT et .HPJ dans un environnement de confiance ;
- de filtrer éventuellement ces extensions de fichiers au niveau des passerelles de messagerie ;
- de contacter le CERTA s'il y a le moindre doute.
3 Du risque associé à certains services paradoxaux
On peut rencontrer sur l'Internet un certains nombre de sites proposant de vérifier pour le client d'un service s'il aurait été victime d'un vol d'identité. Cependant les méthodes employées sont souvent des plus douteuses. Le mode opératoire de ces sites pour une telle vérification consiste dans un premier temps à demander la saisie de l'identifiant qui aurait pu être dérobé.
Le site de vérification peut alors indiquer que cet identifiant a bien été dérobé et qu'il convient pour s'en assurer de donner en complément ses coordonnées bancaires...Le site promet alors de contacter la banque pour l'informer de cet état de fait.
Ce genre de pratique s'apparente plus à du phishing qu'à un réel service. Il est donc recommandé de proscrire l'usage de ce genre de sites.
4 Filtrage et syntaxe d'URL
4.1 Principes
Une URL est de la forme suivante, où les éléments entre crochets sont très souvent omis :
protocole://[utilisateur:[mot-de-passe]@]hote[:port]/chemin?requete#etiquette
Par exemple, sans utilisateur, ni port, ni étiquette :
http://www.premier-ministre.gouv.fr/fr/p.cfm?ref
La représentation est définie dans le standard RFC3986. En l'occurrence, celle de l'hôte peut être faite par adresse IP numérique ou par nom. Les nombreuses variantes, permises ou tolérées par les implémentations, peuvent être source d'inefficacité du filtrage d'URL.
A titre d'exemple, si l'hôte est désigné par une adresse IP numérique, des mises en œuvre autorisent la représentation avec 1 à 4 entiers, séparés par des points. Le dernier entier représente les derniers octets de l'adresse (sa taille est donc variable). Chaque entier peut lui-même être représenté en décimal, en octal, s'il commence par 0, ou en hexadécimal, s'il est précédé par 0x ou 0X. La représentation de ces entiers peut ne pas être uniforme.
Voici un exemple, avec l'adresse du site http://www.certa.gouv.fr et l'adresse IP utilisée à la date de parution de ce bulletin d'actualité :
- http://www.certa.ssi.gouv.fr/
- http://213.56.176.2/
- http://3577262082/
- http://0325.0070.0260.0002/
- http://0xD5.0x38.0xB0.0x02/
Il est également possible de faire des combinaisons de ces représentations.
Enfin, dans les noms d'hôtes, un caractère non ASCII peut être représenté en UTF-8 par une chaîne d'octets. Chacun de ces octets est inclus dans l'URL sous forme %HL ou H et L sont les caractères désignant les chiffres hexadécimaux de l'octet, comme %7B. La représentation IDNA (RFC3490) est recommandée pour les recherches DNS.
4.2 Recommandations
Compte tenu des remarques précédentes, il est important de :
- prendre le temps de vérifier le sens et la validité d'un lien présenté dans un courrier électronique ou d'une autre manière quelconque ;
- tester que la politique de filtrage d'URL considère ces différentes représentations, et que le filtre transforme les URL sous une forme canonique.
5 Vulnérabilité de certains téléphones portables Bluetooth
Cette semaine, plusieurs fabricants de téléphonie mobile ont communiqué sur des vulnérabilités de type déni de service affectant leurs produits équipés d'une interface Bluetooth. Ces vulnérabilités peuvent être exploitées à distance pour provoquer un déni de service. A ce jour, un code destiné à prouver l'exploitation de ces vulnérabilités est disponible sur l'Internet.
Le CERTA a eu l'occasion d'analyser et de tester certains de ces codes. L'attaque consiste à envoyer de façon ininterrompue un élément (fichier, contact, etc.) vers le profil Obex Push du périphérique vulnérable, qui se traduit par un consommation excessive des ressources de l'appareil. Cela provoque un déni de service de la pile Bluetooth et/ou de l'appareil. A la date de rédaction de ce document, la liste des périphériques vulnérables est limitée à 5 téléphones mobiles équipés d'une interface Bluetooth. Il s'agit de :
- Motorola MOTORAZR V3
- Sony Ericsson K700i
- Sony Ericsson W810i
- Nokia N70
- LG Chocolate KG800
Il est cependant fort probable que cette liste ne soit pas exhaustive.
5.1 Documentation
- Référence CVE CVE-2007-0521 :
http://nvd.nist.gov/nvd.cfm/?cvename=CVE-2007-0521
- Référence CVE CVE-2007-0522 :
http://nvd.nist.gov/nvd.cfm/?cvename=CVE-2007-0522
- Référence CVE CVE-2007-0523 :
http://nvd.nist.gov/nvd.cfm/?cvename=CVE-2007-0523
- Référence CVE CVE-2007-0524 :
http://nvd.nist.gov/nvd.cfm/?cvename=CVE-2007-0524
5.2 Recommandations
Les mises à jour sur les téléphones portables n'existent pas ou ne sont pas faciles à appliquer.
Le CERTA recommande donc vivement de vérifier que l'activité bluetooth est bien désactivée par défaut sur tout appareil commmuniquant. Quand une communication via cette technologie doit avoir lieu, elle doit se faire entre dispositifs jumelés (partageant un secret), et dans un enviromment de confiance. Les risques associés doivent être considérés.
6 La liste noire maintenue par Google
6.1 Présentation
A la date de publication de ce bulletin, le navigateur Mozilla Firefox 2 ainsi que la barre de navigation Google pour Firefox contiennent un module (Safebrowsing) permettant de vérifier que le site visualisé par l'internaute n'est pas présent dans une liste noire de Google. Si tel est le cas, un message d'avertissement prévient l'utilisateur des risques potentiels à visiter cette page. Afin de ne pas surcharger ces contrôles, Google maintient également une liste blanche de domaines qui sont censés ne pas héberger de sites frauduleux.
Le fait de pouvoir consulter cette liste noire apporte également l'intérêt de contrôler la présence ou non d'un site (ou d'une adresse y faisant référence) dans cette liste. Ainsi, le CERTA vérifie régulièrement dans ce genre de liste l'absence de sites relatifs à l'administration française.
D'autres sociétés, comme Microsoft, maintiennent également des listes noires et blanches utilisables par certains navigateurs comme Microsoft Internet Explorer 7.
Attention toutefois à ne pas accorder une trop grande confiance dans ces listes, elles ne sont pas exhaustives et chacun se doit de rester vigilant. Par ailleurs, la manière dont ces listes sont maintenues n'est pas toujours publique, et vérifiable.
6.2 Documentations
- Signaler une page de phishing chez Google :
http://www.google.com/safebrowsing/report_phish
- Signaler une erreur dans les alertes d'usurpation d'identité :
http://www.google.com/safebrowsing/report_error
7 Retour sur les récentes vulnérabilités CISCO
Cisco a publié cette semaine trois mises à jour distinctes, qui ont été présentées dans l'avis CERTA-2007-AVI-050.
Les éléments d'un réseau sont sensibles, et les vulnérabilités corrigées peuvent être exploitées pour provoquer un dysfonctionnement de ceux-ci, voir en prendre le contrôle total.
Le CERTA recommande donc vivement d'appliquer les mises à jour, et de surveiller avec attention le comportement des éléments CISCO vulnérables.
8 Le Month of Apple Bug : épisode 4
Voici, pour cette semaine, les vulnérabilités sur les produits Apple publiées par le projet « Month Of Apple Bugs » :
- une vulnérabilité dans le logiciel iChat et sa mise en œuvre du protocole AIM (AOL Instant Messaging) permettant de provoquer un déni de service ou l'exécution de code arbitraire sous certaines conditions ;
- des erreurs de conception dans un composant du panneau de configuration et dans l'agent de notification de Apple MacOS X permettant un utilisateur local d'élever ses privilèges ;
- une vulnérabilité dans l'application Apple QuickDraw et sa mise en œuvre des images au format PICT ;
- une erreur dans le système de mise à jour logiciel permettant d'effectuer un déni de service.
9 Interprétation de l'élément HTML TITLE par les navigateurs
Dans le standard HTML 4.0 (http://www.w3.org/TR/html4/html40.txt), il est dit que :
7.4.2 The TITLE element Titles may contain character entities (for accented characters, etc.), but may not contain other markup (including comments).
Il y a donc une imprécision, donc une interprétation différente selon les navigateurs.
Certains considèrent que les commentaires n'ont pas lieu d'être dans le champ TITLE, et prennent tout le contenu comme du texte, qui sera affiché. Cela inclut les balises de commentaires.
D'autres, en revanche, adoptent un comportement inattendu. Ils peuvent par exemple ignorer simplement les balises de commentaires, et interpréter d'autres balises comme <SCRIPT> au sein même du champ TITLE.
Certains filtres HTML bloquent les balises de script, mais ne vont pas vérifier si de telles balises se trouvent dans les champs commentaires. Dans ces conditions, une personne malveillante peut insérer un script dans un commentaire, se trouvant lui-même entre les balises <TITLE> et </TITLE>. Le script sera interprété par cette famille de navigateurs.
La politique de sécurité appliquée par les filtres HTML est alors contournée.
Dans le cas où des filtres sur le contenu HTML sont mis en place, il est important qu'ils vérifient correctement le contenu TITLE.
