CERTA
|
CERTA Centre d'Expertise Gouvernemental de |
 |
|
Affaire suivie par : CERTA Objet : Bulletin d'actualité
2007-40
Gestion du documentUne gestion de version détaillée se trouve à la fin de ce document. Le bulletin d'actualité est disponible dans son intégralité et au format PDF à l'adresse suivante : http://www.certa.ssi.gouv.fr/site/CERTA-2007-ACT-040.pdf Un extrait du bulletin, ne reprenant que les articles de la semaine, se trouve en HTML à l'adresse suivante : http://www.certa.ssi.gouv.fr/site/CERTA-2007-ACT-040/ 1 Quand l'attaquant referme la porteCette semaine le CERTA a traité une compromission d'un serveur web qui hébergeait un site bancaire frauduleux (phishing). Lors du premier contact avec le propriétaire du site web, cette personne a informé le CERTA que ce genre de désagrément s'était produit régulièrement malgré le retrait systématique du contenu frauduleux. Le CERTA rappelle que lors d'un incident de sécurité, il faut éviter de supprimer des données qui pourraient être utiles à l'analyse ou à une éventuelle enquête judiciaire. Dans cet incident, l'analyse a mis en évidence que, dans un premier temps, l'attaquant a utilisé une faille dans le code PHP d'une page : une variable dont le contenu n'est pas suffisamment protégé. Une fois le contrôle de la machine obtenu et en y déposant des portes dérobées (PHP Shell), l'attaquant a lui même corrigé la page vulnérable. Sa correction n'était d'ailleurs pas dénuée d'humour car lors d'une tentative d'exploitation de la vulnérabilité la page affichait un message personnalisé de l'attaquant. Le langage PHP offre beaucoup de facilités qu'il convient d'utiliser avec précaution. L'une d'entre elles est l'inclusion de pages passées en paramètre dans l'adresse réticulaire (URL) lors de l'appel de la page. Ces variables doivent être limitées aux seules pages du site ou faire l'objet de contrôles sémantiques et syntaxiques. 1.1 documentation
2 Question de point de vueCette semaine, le CERTA a été informé par l'un de ses homologues européens de la présence d'un outil malveillant (malware) sur le site Internet d'une administration. Suite au contact avec cette administration, ce qui aurait put être une compromission plutôt classique d'un serveur web pour y déposer un virus, se révèle être beaucoup plus important. En effet, la victime, qui ne s'était pas aperçue de la présence du virus sur son serveur, a pris contact avec son hébergeur. Celui-ci lui a indiqué un comportant anormal de la machine depuis plusieurs jours. Selon la société d'hébergement, le serveur compromis tentait d'initier un volume important de connexions vers des pays étrangers. L'état actuel de l'analyse de cet incident ne permet pas d'identifier l'origine ni le but de ces connexions. Un serveur connecté à l'Internet est parfois accessible par plusieurs services. Inversement, il peut lui-même, si les règles de filtrage sortantes ne sont pas suffisamment rigoureuses, établir des connexions vers l'extérieur. Le CERTA insiste donc sur le fait que l'analyse de journaux applicatifs est une très bonne chose, mais n'est pas suffisante. Il faut considérer, dans le cadre d'une bonne vigilance, plusieurs types de journaux concernant différents services, différentes couches protocolaires, et éventuellement compléter par ceux d'autres systèmes périmétriques (pare-feu, serveur DNS, etc.). Il faut surveiller depuis plusieurs points de vue le système. 2.1 documentation
3 Les défigurations des pages Web difficilement visibles3.1 Défigurations non visibles ?Une définition de « défigurer » pourrait être « modifier l'aspect ». Il est courant d'utiliser ce terme pour une page Web, lorsque son apparence est modifiée. L'internaute visitant cette page ne voit pas ce qui est légitime. Par extension, (ou abus de langage selon certains), la défiguration d'un site Web peut également concerner toute modification du code source de la page. En réalité, il se mélange deux concepts différents :
Si l'une de ces finalités consiste à modifier, d'une manière quelconque, l'aspect visuel de la page Web, alors il s'agit bien d'une défiguration. Dans les autres cas, il y a bien une perte d'intégrité du code source de la page, mais les raisons sont différentes. Dans tous les cas, l'origine du problème reste l'injection de code, qui met en évidence un défaut de garantie de l'intégrité de la page, qu'il faut comprendre. Plusieurs cas ont été médiatisés cette semaine, et le CERTA a traité ces derniers mois de nombreux incidents liés à des injections de code ne modifiant pas l'aspect visuel, mais le code source. Le responsable d'un serveur Web doit connaître ces risques. 3.2 Les objectifsInjecter du code dans une page Web peut avoir plusieurs finalités, comme nous venons de le voir. En voici quelques-unes à valeur d'illustration :
3.3 Différentes manièresLes injections de code seront différentes en fonction des finalités, et elles peuvent évoluer. Celle que l'on rencontre souvent actuellement fait l'objet de nombreux articles dans les précédents bulletins d'actualité et concerne la balise HTML IFRAME. <_iframe src="http://wwww.monSiteTresMalveillant/... style="display:none"> </_iframe> Mais il est fait mention dans CERTA-2007-ACT-033 de la balise définissant les sections DIV :
<_DIV id=".." style="display:none">
<_a href="http://wwww.monSiteTresMalveillant/... </a>
</DIV>
Il est aussi possible d'ajouter directement un code Javascript :
<_SCRIPT language=javascript>
function MauvaiseIntension() {
alert("Mauvaises intensions en cours...");
</_SCRIPT>
Comme le bulletin CERTA-2007-ACT-035 l'évoque, il reste possible d'exploiter des fonctionnalités associées aux données de style (CSS), soit au niveau de la page HTML, soit dans l'un des fichiers de style associé. D'autres scénarii sont
imaginables pour mettre en 3.4 Les recommandations du CERTA3.5 De manière généralePlusieurs démarches peuvent être entreprises pour limiter les risques. En particulier :
3.6 Le filtrage au niveau d'une passerelleLes passerelles Web permettent normalement de faire un filtrage du contenu. Les proxys locaux comme privoxy offrent également une telle possibilité. Le filtrage est souvent effectué sous la forme d'expressions régulières, qui caractérisent des chaînes de caractères données. Dans l'hypothèse où les chaînes sont normalisées, l'application de ces expressions permet de générer des actions intéressantes. La chaîne suivante est un exemple permettant de filtrer les balises IFRAME. L'action peut alors être de supprimer, ou de modifier le cadre d'origine. Ici, elle est transformée pour pointer systématiquement sur une fenêtre du CERTA. Elle signifie que dans une chaîne de la forme "<iframe>...</iframe>", tous les caractères commençant à "src=" et finissant avant le "<" de "</iframe>" sont remplacés par la chaîne spécifiée.
FILTER: Remove all iframes from webpages
s|(<iframe.*)src=.*(</iframe)|$1src=http://www.certa.ssi.gouv.fr frameborder=1
width="200" height="180" scrolling="no"$2|igU
L'expression régulière peut ensuite être adaptée, ou plus précise. Elle peut, par exemple se préoccuper des champs "display:none", etc. Il faut cependant faire attention, car cette opération risque de modifier l'affichage de données utiles. Les expressions régulières permettent une grande souplesse de filtrage. L'objectif de cet article n'est pas de détailler les expressions régulières, mais d'insister sur le fait qu'elles existent, et sont souvent mises à disposition par les différentes passerelles. Elles peuvent ainsi permettre de filtrer des contenus potentiellement dangereux, avant qu'ils soient directement interprétés par le navigateur de l'utilisateur. 4 Les applications contenues sur une cléLe CERTA a publié en 2006 la note d'information CERTA-2006-INF-006. Elle aborde les risques associés aux supports de données amovibles USB (Universal Serial Bus). L'un des points-clés de cette publication est de montrer deux choses :
L'idée n'est pas ici d'écrire à nouveau cette note d'information, mais de montrer que les scénarios 1 et 2 existent bien, par deux exemples concrets d'actualité.
4.1 Un incident traité cette semaineLe CERTA a traité cette semaine un incident concernant une machine non connectée à l'Internet. Celle-ci a été compromise par un code malveillant qui a déposé deux keyloggers. Si ceux-ci ne pouvaient pas se connecter sur des sites distants pour envoyer des informations capturées, cet exemple montre néanmoins que les machines déconnectées de l'Internet ne sont pas pour autant protégées. Le vecteur de propagation de ce code malveillant semblait ainsi être un périphérique amovible et/ou un partage réseau. L'une de ses variantes se copie notamment sur des clés USB avec un fichier autorun.inf pour son exécution automatique sur un système Windows avec la fonctionnalité autorun activée. L'antivirus installé sur la machine n'a pas détecté les keyloggers présents, toutefois d'autres les détectent avec succès. Le type d'informations qui sont capturées puis envoyées peut différer selon le code :
Les codes de ce type ne sont pas toujours faciles à détecter. L'analyse régulière des fichiers journaux de connexions sortantes est souvent le meilleur moyen car ce type de programme va tenter d'envoyer les données collectées. De plus, ils peuvent parfois provoquer des comportements suspects sur la machine : par exemple, le code analysé cette semaine provoquait des doublons lors de frappes de certaines touches particulières du clavier. 4.2 Rappel concernant les supports de données amovibles USB (Universal Serial Bus)Sur différents sites, forum de discussions et listes de diffusion françaises, des personnes mentionnent parfois la possibilité d'installer et d'utiliser des applications préconstruites pour les périphériques de stockage de données USB (par exemple : une clé ou un disque dur amovible). La page d'un projet offrant de telles applications affiche plus de 200 applications à son catalogue, directement utilisables, une fois copiées sur un périphérique (elles sont compilées de manière statique). Cela inclut :
Cependant l'utilisation de ces applications présente des risques : l'utilisation de logiciels comme des navigateurs Internet ou des clients de messagerie implique le stockage de données personnelles sur le support. Une personne malveillante peut, lors de la connexion du périphérique sur une machine compromise, « aspirer » les données, parfois confidentielles comme :
Ces périphériques, de taille toujours plus réduites, peuvent aussi être facilement perdus ou dérobés. Enfin, les logiciels offerts impliquent également un grande confiance vis-à-vis du projet, car les codes source ne sont pas toujours disponibles, et les fichiers exécutables sont rarement analysés. Dans de nombreux incidents, la compromission du système est due à l'absence de mises à jour ou patchs correctifs. L'utilisation de ces support de stockage USB contenant des applications prêtes à l'emploi rend plus compliquée et incertaine la mise à jour de ces applications. La mise à jour dépend du projet tiers. Ainsi, dans celui mentionné, il apparaît que de nombreuses applications ne sont pas fournies dans leur version la plus récente. Ces applications obsolètes incluent un navigateur, une suite bureautique et des lecteurs multimédia. Le CERTA recommande donc de bien étudier toutes ces problématiques avant d'utiliser de telles solutions pour des périphériques de stockage USB. 5 Quelques anomalies DNSLe CERTA a reçu plusieurs courriels signalant le cas d'un site qui tenterait de se faire passer pour celui d'un éditeur et qui pourrait ainsi proposer des logiciels malveillants en lieu et place de ceux légitimes. Après analyse, il s'agirait plutôt d'une utilisation abusive d'une fonctionnalité DNS. L'objectif de cet article est d'expliquer cet abus. Le but du protocole DNS est d'établir un lien entre
le nom d'une machine et son adresse réseau (IP). Par
exemple l'adresse "www.certa.ssi.gouv.fr" correspond, à
la date de rédaction de ce document, à l'adresse
"213.56.176.2". Ces associations ne pouvant être
maintenues dans une unique base de données
partagée, le système a été
organisé selon une architecture arborescente. Les noms
représentent des feuilles ou des n Chaque n A chaque zone correspond une base ou les noms sont associés à une adresse physique, mais pas uniquement. En effet d'autres précisions peuvent y être associées, par exemple des informations pour le routage des courriels ou les alias. Un alias (CNAME) peut pointer sur le nom d'un hôte, dans la même zone ou une autre. Dans le cas des remontées faites au CERTA, le problème est donc le suivant : un utilisateur a enregistré son nom de domaine MonSiteMauvais en le définissant comme alias (ou CNAME) de www.MonEntreprise. L'utilisateur qui clique sur un lien d'une page vers MonSiteMauvais a la surprise de visualiser une page légitime du site www.MonEntreprise. Il ne s'agit pas d'un cas de filoutage, mais plutôt d'une tentative de nuire à l'image de la société, en faisant pointer plusieurs noms de machines (humoristiques ou agressifs) vers le site officiel www.MonEntreprise. On peut cependant imaginer que cette configuration DNS change, et dirige cette fois le nom MonSiteMauvais vers une page malveillante à une adresse donnée (champ A remplaçant champ CNAME dans la configuration DNS). La possibilité de se définir comme alias d'un autre nom hors de sa zone dépend des limitations imposées par les noms de domaines les plus hauts (Top Level Domain, « com », « fr », « org », ...). Des commandes comme « nslookup » ou « dig » permettent de voir qu'il ne s'agit que d'un alias. On voit que le nom canonique ( le nom « réel ») est associé à celui malveillant.
$dig MonSiteMauvais
(..)
;; ANSWER SECTION:
MonSiteMauvais TTL1 IN CNAME www.MonEntreprise
www.MonEntreprise TTL2 IN A W.X.Y.Z
(...)
|
|
||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
)
uvre les objectifs
cités dans le paragraphe précédent.
uds de l'arbre, et la structure des noms
représente un chemin dans l'arbre.
ud de l'arbre (domaine) a un nom
et contient une liste de noms de machines (hôtes) ou des
sous-n
uds (sous-domaines). Un ensemble de
domaines et de sous-domaines gérés au même
endroit est appelé une zone. Les sous-domaines peuvent
faire partis de la même zone que leur ascendant ou
être noeud d'une nouvelle zone.