S.G.D.S.N
Agence nationale
de la sécurité des
systèmes d'information
Paris, le 21 mars 2008
N° CERTA-2008-ACT-012
Affaire suivie par: CERT-FR
le 21 mars 2008

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2008-12

Gestion du document

Référence CERTA-2008-ACT-012
Titre Bulletin d’actualité 2008-12
Date de la première version 21 mars 2008
Date de la dernière version 21 mars 2008
Source(s)
Pièce(s) jointe(s) Aucune(s)
Tableau 1: Gestion du document

Une gestion de version détaillée se trouve à la fin de ce document.

1 Incidents de la semaine

1.1 Le vol d’indentifiants bancaires

Cette semaine, le CERTA a contribué à la fermeture d’un site malveillant. Suite à la compromission d’un site légitime, les attaquants ont déposé une page servant de support à une tentative de vol de numéros de cartes bancaires. En effet, la page frauduleuse utilisait le logo d’un banque française afin de mettre en confiance les victimes.

Les victimes, qui étaient invitées à saisir leur informations bancaires , étaient dirigées vers cette page frauduleuse par le biais d’une annonce d’une fausse agence de casting.

Le CERTA rappelle que les services de paiements sécurisés des banques doivent se trouver sur leur site. Il convient donc de s’assurer de la validité et de la sécurité du site avant de saisir des informations personnelles ou bancaires.

4.1 Documentation

1.2 Pas de mise à jour : risque de compromission

Cette semaine le CERTA a traité un incident relatif à la compromission d’un site web. Ce site utilisait une version vulnérable du composant Ext_Calendar. Les attaquants ont profité de la vulnérabilité pour déposer un site bancaire frauduleux (phishing ou filoutage). Le CERTA recommande de suivre et d’appliquer les mises à jour conformément à la politique de sécurité du système d’information. Le CERTA rappelle également qu’il convient de désactiver les composants vulnérables ou inutilisés.

2 Logiciels libres et pilotes propriétaires

Un certain nombre de distributeurs fournissent maintenant des ordinateurs livrés en standard avec une distribution GNU/Linux préinstallée. Tout comme avec d’autres systèmes, il convient lorsque l’on fait l’aquisition de ce type de machines de s’intéresser à la sécurisation de ce type d’équipement. En effet, comme tout système d’exploitation, il doit en particulier être mis à jour.

Dans ce contexte, il est important de signaler que sur ce type de système le support du matériel sous-jacent peut se faireprincipalement de deux manières :

  • soit le périphérique est nativement supporté par le noyau ( « kernel » ) ou bien encore le fabriquant du périphérique a fourni un pilote dont la licence est compatible avec celle du noyau (GPL). Ceci est le cas idéal mais il conviendra de s’assurer que dans la deuxième hypothèse le pilote soit bien maintenu ;
  • soit le pilote associé au périphérique n’est distribué qu’en code fermé et utilise des versions précises pour chaque distribution ou noyau. C’est le cas notamment pour certaines cartes graphiques ou certains contrôleurs RAID. Le problème dans ce cas est que la mise à jour du système deviendra éventuellement dépendante de la publication d’une nouvelle version de ce pilote.

Dans le deuxième cas, il peut arriver que l’éditeur, ne fournissant pas de version compatible avec le système de mise à jour, « casse » purement et simplement le système gérant les mises à jour. A cause d’un simple pilote, toutes les corrections de failles ne fonctionnent alors plus.

Le propos n’est pas ici de débattre sur le bien fondé de l’utilisation de tel ou tel type de licence ou de méthode de diffusion de pilotes. Il convient plutôt d’être vigilant sur les pilotes ou logiciels livrés en dehors du système intégré de gestions des logiciels. Ceux-ci peuvent parfois provoquer des effets de bord désastreux en terme de sécurité et de mises à jour.

3 Incompatibilités possibles entre deux services concurrents

Il est important de bien contrôler les services actifs sur une machine. Certains d’entre eux peuvent, à l’insu de l’utilisateur, être incompatibles et provoquer le non-respect de la politique de sécurité.

A valeur d’exemple, prenons SNTP : il s’agit de la version simplifiée du protocole de synchronisation NTP (pour Network Time Protocol). Ce dernier est normalement destiné à des réseaux dont la précision de synchronisation ne descend pas sous l’ordre de la seconde. Cette méthode « allégée » est en particulier adaptée pour des systèmes embarqués ou des éléments terminaux qui ne serviraient pas eux-même de référence à d’autres systèmes.

SNTP utilise le même port de communication que NTP (123/UDP) pour atteindre le serveur, mais, à la différence de NTP, peut utiliser des ports source arbitraires non nuls, comme le signale le standard RFC 4330. En pratique, le port 123/UDP est régulièrement utilisé à la fois comme source et destination.

Certains éléments de réseau comme des routeurs peuvent avoir un processus NTP actif, même si aucune commande explicite pour l’utiliser n’est installée. Ainsi, dans certains éléments Cisco, le service peut se lancer insidieusement par une commande de configuration ntp logging, et ne s’interrompre que lors d’un prochain chargement ou démarrage de l’appareil.

Les deux clients NTP et SNTP peuvent alors se retrouver en concurrence pour interpréter une trame de réponse émise par un serveur. Le client NTP a de fortes chances d’être le plus prompt à intercepter la réponse, et prive ainsi le client SNTP de cette dernière.

Il est préférable d’avoir une synchronisation précise, mais cette concurrence entre les deux services peut entraîner que la politique choisie ne soit pas respectée. Si le service NTP n’a pas été correctement configuré, car non prévu, c’est la synchronisation complète qui peut être remise en jeu.

Il est donc important de :

  • vérifier avec soin la configuration voulue. Au niveau des routeurs, il est souvent possible de tester celle-ci : par exemple, sous Cisco, il existe les commandes debug ntp packet et debug sntp packet.
  • vérifier la cohérence entre les traces réseau et les informations retournées par le système et la configuration mise en place.

Documentation associée

4 Sortie du Service Pack 1 pour Windows Vista

Le 18 mars 2008 est sorti le premier Service Pack pour Microsoft Windows Vista. Il est disponible en cinq langues (allemand, anglais, espagnol, français et japonais) pour les versions 32 bits et 64 bits du système d’exploitation. Le contenu de cette mise à jour a été détaillé dans le bulletin CERTA-2007-ACT-049, lors de la sortie de la version release candidate.

L’utilisateur a le choix de l’installer via l’application Windows Update ou de le télécharger sur le site internet de Microsoft. Dans le premier cas il faut choisir les mises à jour facultatives. La mise à jour automatique ne se fera en effet qu’à partir de mi-avril.

Enfin, il apparaît que certaines personnes n’ont pour le moment pas accès au Service Pack via Windows Update et doivent obligatoirement télécharger la version autonome manuellement. Il s’agit notamment de personnes dont les machines ont des pilotes de périphériques incompatibles avec le service pack 1, et qui doivent être mis à jour. Une liste de ces pilotes est disponible en documentation (KB948343 en anglais).

4.1 Documentation

5 Attaques massives de type SQL Injection

5.1 Présentation des incidents cités dans la presse

Plusieurs articles ont récemment été publiés relatant qu’une grande quantité de sites Internet ont été victimes d’attaques de type SQL injection. Le schéma de ces attaques est le même que d’anciennes attaques de ce type et affecte le trio ASP, IIS, Microsoft SQL Server. Tout d’abord la personne malveillante cherche à déterminer si le site est vulnérable ou non. Pour cela elle envoie des requêtes d’injection classiques afin de tester les réactions du site. Il apparaît que la compromission se fait de différentes façons en fonction des réactions des serveurs. Selon les analyses publiées récemment, les premières requêtes envoyées se présentent de la forme suivante dans le journal des événements : 
AAAA-MM-JJ hh:mm:ss /repertoire/page.asp
        id=z%20ANd%20char(124)…
        HTTP/1.1 REFERER – – 200 0 17115 1171
AAAA-MM-JJ hh:mm:ss /repertoire/page.asp
        id=z%27%20ANd%20char(124)…
        … HTTP/1.1 REFERER – – 200 0 17115 562

Dans un navigateur, la requête prend la forme :

http://www.Le_Site.tld…/page.asp?id=z%20ANd%20char(124)…

Cette requête est encodée deux fois. Le premier encodage est pris en charge par IIS. Ce sont les jeux de caractères commençant par « % » comme %20 qui correspond au caractère « espace ». La seconde phase d’encodage se situe au niveau de SQL Server. On remarque que la requête utilise d’ailleurs des fonctions SQL. Après avoir retiré l’encodage, on obtient :

id=z ANd |user|=0
id=z ANd |user|=0 and  »=’
Grâce à une nouvelle requête, le message d’erreur reçu enretour permet d’obtenir de précieuses informations commel’utilisateur de l’application web. La requête en question est decette forme : 
AAAA-MM-JJ hh:mm:ss /repertoire/page.asp
        id=z%27%20ANd%20char(124)%2Buser%2Bchar(124)=0…
        …|Syntax_error_converting_the_nvarchar
        _value_’|IUSR_Server|’_to_a_column_of_data_type_int.
         … HTTP/1.1 REFERER – – 500 0 292 390

Après avoir décodé, on obtient cette requête :

id=z ANd |user|=0 and ‘%’=’

Il est parfois nécessaire d’envoyer une nouvelle requête afin d’avoir l’assurance que l’utilisateur possède les droits sysadmin. Enfin, une requête permettant la déclaration d’une variable est ensuite envoyée. Cette requête convertit une chaîne de caractères hexadécimale en une chaîne de type NVARCHAR puis tente d’exécuter cette dernière.

AAAA-MM-JJ hh:mm:ss /repertoire/page.asp
id=z;DECLARE%20@S%20NVARCHAR(4000);SET%20
        @S=CAST(0x440045004300…VARCHAR(4000));EXEC(@S);…
         HTTP/1.0 REFERER – – 200 0

Après décodage, on obtient cette requête :

DECLARE @S NVARCHAR(4000);
  SET @S=CAST(0x440045004300… AS NVARCHAR(4000));
        EXEC(@S);…

Le script inséré dans la base consiste en la déclaration de quelques variables, avant de parcourir l’ensemble des tables sysobjects syscolumns, qui contiennent l’ensemble des tables et colonnes de la base de données, à la recherche de type de champs pouvant contenir des données de type strings. Cela a pour conséquence l’ajout dans ces champs de liens vers un code JavaScript pointant vers un site malveillant.

5.2 Les recommandations du CERTA

  • Pour les développeurs :
    • mettre en place des contrôles permettant la vérification des variables dans les pages ASP ;
    • vérifier l’intégrité de la base de données ;
    • contrôler les flux entrant et sortant ;
    • surveiller les traces journaux à la recherche de requêtes particulières (mots-clés varchar, exec, etc.);
    • éviter de lancer les applications web avec un utilisateur ayant les droits sysadmin.
  • Pour les utilisateurs :
    • désactiver dans le navigateur l’exécution de code JavaScript, y compris sur des sites de confiance, lorsque cela n’est pas nécessaire ;
    • prévenir son correspondant en sécurité informatique, RSSI, en cas de comportements bizarres suite à une navigation ;
    • avoir impérativement son système à jour avant toute navigation ;
    • naviguer avec un compte utilisateur aux droits limités.

Documentation

6 CUPS – Common UNIX Printing System

Le CERTA a publié cette semaine un avis sur une vulnérabilité de CUPS (CERTA-AVI-2008-156).

CUPS, pour Common Unix Printing Systems, est un serveur d’impression, permettant à différents éléments ou machines de traiter et d’envoyer des tâches d’impression à l’imprimante associée.

Adapté sur plusieurs distributions Linux, CUPS est également utilisé comme le système d’impression par défaut sur Mac OS X d’Apple, qui en est également le propriétaire depuis 2007.

Ce logiciel est vulnérable à un dépassement de mémoire qui, sous certaines conditions, permet l’exécution de code arbitraire à distance. Il est installé par défaut, entre autres, sur Mac OS X, et l’interface de configuration est accessible à l’adresse http://localhost:631. Une des conditions nécessaires à l’exécution de code est qu’une imprimante partagée soit installée. Il semble cependant possible de contourner cette restriction en configurant CUPS, au détriment de l’utilisateur, et cela via une page web spécifiquement créée. Pour savoir si CUPS tourne sur la machine locale, il suffit de tester l’accès à un élément déterminant tel qu’une image, et cela via l’adresse de configuration.

Pour cela, un simple code JavaScript inséré dans une page permet d’effectuer un test. Il suffit par exemple de vérifier l’existence d’une image via l’interface CUPS.Si le test est positif, cela déclenche l’exécution d’une action JavaScript (onload). La page malveillante peut alors manipuler la configuration de CUPS à l’aide du code JavaScript.

Le CERTA recommande de mettre à jour les applications, et, comme il est souvent répété, de n’activer le JavaScript que ponctuellement, quand celui-ci est indispensable, et sur un site de confiance.

Par ailleurs, les services doivent être correctement configurés, et la navigation doit se faire par le biais d’un compte aux droits limités.

Documentation

Rappel des avis émis

Dans la période du 10 au 16 mars 2008, le CERT-FR a émis les publications suivantes :


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

Gestion détaillée du document

    le 21 mars 2008
    version initiale.