Académique Documents
Professionnel Documents
Culture Documents
Simon Marechal
1.1 Introduction
Les applications web sont déployées sur Internet de plus en plus massivement.
Des applications « clef en main » (Forum, blog, wiki) sont mises en places par
des utilisateurs non techniques de plus en plus nombreux. Parallèlement, les
applications web font de plus en plus l’objet d’alertes de sécurité. C’est dans ce
contexte que le premier Web-Worm a été écrit.
Le but de cet article est d’étudier les problématiques liées à la création d’un
Web-Worm, ainsi que de mettre en lumière les techniques propres à leur écriture,
en analysant un ver existant puis en créant pas à pas deux vers exploitant
des vulnérabilités de natures distinctes. D’autres types de Web-Worms seront
abordés et plusieurs moyens de défense seront décrits.
Cet article sera focalisé sur les applications web écrites dans un langage de
script interprété, excluant donc java.
2.1 Introduction
2.2 Fonctionnement
Infection Le ver teste la vulnérabilité sur le site distant en demandant une url
exécutant la commande suivante :
perl -e "open OUT,q(>’m1ho2of’) and print q(’ . markStr . ’)"
Ceci à pour effet de créer un fichier « m1ho2of » dans le répertoire courant
du script phpBB. Ce test lui permet de s’assurer que le système distant présente
certaines propriétés :
– Le script PHP vulnérable est exécuté par un utilisateur ayant des droits
de création de fichier dans le répertoire de phpBB, et donc certainement
un droit de modification sur les pages du site ;
– Un interpréteur perl est présent sur le serveur distant, et il peut être
exécuté par l’interpréteur PHP.
Il teste ensuite si ce fichier existe. Si ce test échoue, c’est à dire que le fichier
n’existe pas, il passe à une autre cible. En effet ce serait le signe que le serveur
distant ne peut pas être infecté pas Santy, soit parce qu’il ne présente pas la
vulnérabilité exploitée, soit parce qu’il ne peut pas créer de fichiers.
Si le fichier existe, vingt octets du code source du ver sont stockés dans la
variable $1. Le ver va se copier dans le fichier précédemment créé par blocs de
vingt caractères. Il doit donc réaliser de nombreuses requêtes pour se copier sur
une machine distante. Le but de cette manoeuvre doit être d’éviter les restrictions
sur la longueur des URLs imposées par certains serveurs web :
Actes du symposium SSTIC05 3
Charge utile Pour finir, le ver va rechercher les fichiers dont l’extension indique
une page web (php, html, ...) et va les remplacer par un message indiquant que
le site a été « défacé » ainsi que le numéro de génération.
3.1 Objectif
3.2 Spécifications
3.3 La portabilité
Pour que le ver soit portable, il faut que le ver puisse se reproduire en n’uti-
lisant que les ressources dont a besoin l’application cible pour fonctionner. En
pratique, il n’est pas possible de garantir la portabilité du ver. En effet, l’appli-
cation cible n’a pas besoin de se connecter vers d’autres serveurs Web alors que,
par définition, le ver doit pouvoir le faire pour se reproduire. Si les connections
sortantes sont filtrées, par exemple, le ver ne pourra pas se reproduire.
Contrairement à Santy, le ver étudié ne devra pas avoir à créer de fichiers, ni
à utiliser un interpréteur externe.
Le seul interpréteur disponible étant l’interpréteur PHP, le ver sera intégralement
écrit dans ce langage. Certaines commandes, qui fonctionnent par défaut sur la
plupart des installations de PHP, mais qui peuvent être désactivées, seront uti-
lisées dans le but de rendre plus simple à lire et plus compact le code source du
ver.
La vulnérabilité découverte est exploitable au moyen d’une requête GET, ce
qui signifie que le code source du ver devra être transféré dans l’URL. Il est
possible sans réduire la portabilité de stocker des informations dans la base de
données utilisée par l’application PHPBB, mais, par soucis de simplicité, cette
option de sera pas retenue. Le code source du ver devra donc être présent dans
son intégralité dans l’URL.
Le RFC 2616 concernant le protocole HTTP ne spécifie pas de limite de
taille pour les URLs. Internet Explorer accepte des URLs de taille maximale
2048 caractères. Il est raisonnable de penser que tous les serveurs Web acceptent
des URLs d’au moins 2048 caractères. Lorsque le code source du ver est placé
dans l’URL, il faut convertir presque tous les caractères spéciaux dans un format
particulier qui triple leur taille. Il faudra donc apporter une attention importante
à la taille du code source du ver.
Actes du symposium SSTIC05 5
Utiliser les informations présentes sur l’hôte Les vers E-Mail utilisent
cette méthode en explorant par exemple le carnet d’adresse de l’utilisateur. Ici,
des informations sur d’autres sites PHPBB ne seront pas disponibles en quantité
assez importantes. De plus, la complexité de l’algorithme de recherche est limitée
par les contraintes de tailles imposées par la longueur maximale d’une URL.
Cette méthode ne sera donc pas utilisée.
La Google API semble être un moyen simple et surtout efficace pour récupérer
des cibles pour le ver. Malheureusement, elle nécessite une authentification, et
surtout de l’argent pour réaliser un nombre important de requêtes. Il faudra
donc réaliser les requêtes « à la main », c’est à dire en réalisant des requêtes
HTTP de la même manière qu’un navigateur standard.
La principale limitation de cette solution est, comme l’a démontré Santy,
la possibilité qu’a le répertoire de filtrer les requêtes hostiles. Utiliser plusieurs
moteurs de recherche différents ne résout pas ce problème. Pour éviter le filtrage,
il existe deux méthodes distinctes :
– Réaliser des requêtes suffisamment générales pour que le moteur de re-
cherche, s’il veut les filtrer, doive renoncer à une grande partie de son tra-
fic. Malheureusement, il n’est pas simple de créer des requêtes génériques
et facilement exploitables.
– Utiliser des techniques inspirées des virus informatiques : le polymor-
phisme. Il suffirait alors de réaliser des requêtes suffisamment différentes
pour qu’elles ne soient pas filtrables par Google. Il serait par exemple
possible de collecter un certain nombre de mots sur la page en cours et de
rechercher toutes les pages où ils seraient tous présents. Une autre méthode
qui devrait être moins efficace serait de noyer la requête au milieu de plu-
sieurs mots omis lors de la recherche car trop communs (a, the, de, . . . ).
Le but de cet article n’étant pas la domination du monde, la méthode retenue
sera très simple est facilement filtrable par Google.
4.1 Objectif
Un ver exploitant une faille légèrement différente est décrit ci-dessous. Les
techniques utilisées sont identiques au ver précédent, sauf sur quelques points.
Actes du symposium SSTIC05 7
$modpath .= "modules/$name/".$mod_file.".php";
if (file_exists($modpath)) {
include($modpath);
4.3 Contraintes
En raison de la nature de la vulnérabilité, le ver ne pourra infecter que des
sites PHP-Nuke fonctionnant avec PHP 5, version encore peu déployée.
Par rapport au ver précédent, il existe une contrainte importante : un fichier
contenant le code hostile doit être présent sur un serveur FTP. Si ce serveur
FTP est stocké « en dur », deux problèmes vont survenir :
– Le serveur FTP ne sera pas capable de tenir la charge.
– Le serveur FTP peut être découvert très facilement et donc nettoyé, filtré
ou arrêté.
Sans le serveur FTP contenant le code du ver, celui-ci ne pourra plus se re-
produire. Il faut donc plusieurs serveurs. A moins de pouvoir insérer du code
hostile dans un projet massivement dupliqué[8], le ver lui même va devoir dupli-
quer son code sur des serveurs FTP. Plusieurs méthodes sont envisageables, les
deux plus simples étant :
8 Actes du symposium SSTIC05
5 Les vers
<?
//on remonte la limite de temps
set_time_limit(0);
//on récupère des résultats de la recherche Google
$a=implode(’’,file(
’http://www.google.com/search?q=%22Powered%20by%20phpBB%22&start=’
.rand(1,420)
));
5.3 Commentaires
Ces vers n’ont bien sûr jamais été testés dans des conditions réelles, il est donc
possible qu’ils ne soient pas parfaitement fonctionnels. Le processus permettant
de les injecter ne sera pas décrit. On remarquera que la logique de recherche
d’url valides est sous optimale et conduira à de très nombreux faux positifs,
ralentissant la propagation du ver.
Veille sécurité Les applications ciblées par des vers sont généralement bien
connues et répandues. En effet, une application de niche ne sera une bonne
cible pour un ver. Les failles qu’ils exploitent seront connues ou rapidement
corrigées. Le fait de se tenir informé sur les failles de sécurité pouvant impacter
ces applications Web sera généralement la méthode la plus efficace et la plus
économique pour s’en protéger.
De plus, une veille permettra d’identifier les applications pour lesquelles des
failles seraient souvent publiées.
Test d’intrusion Un test d’intrusion est parfois utile pour découvrir des vulnérabilités
qui ne seraient pas immédiatement apparentes lors d’un audit de code. C’est
également la solution la plus économique lorsque les sources de l’application ne
sont pas disponibles.
Filtrage des flux Le filtrage des flux va empêcher l’exploitation des vulnérabilités,
ou la propagation du ver. Il est conseillé de filtrer :
– Les flux entrants en réalisant une analyse au niveau applicatif. Si possible,
il est conseillé de réaliser un filtrage spécifique à l’application de sorte à
valider le format de toutes les entrées utilisateur ;
– Les flux sortants initiés par le serveur Web doivent être rejetés, pour
empêcher la duplication du ver.
10 Conclusion
Nous avons vu qu’il était relativement simple de créer un ver bien plus ef-
ficace que Santy.A. En raison de la faiblesse de certaines applications Web très
largement déployées, telles que celles qui sont présentées dans cet article, il est
à craindre que de nouveaux vers applicatifs apparaissent dans le futur. Ces vers
pourraient utiliser des techniques avancées qui les rendraient beaucoup plus dan-
gereux.
Pour se protéger, des solutions originales existent :
– La veille de sécurité. Elle permet de se tenir informé des menaces ainsi que
des éventels correctifs de sécurité ;
– Des tests de vulnérabilités récurrents. Ces tests permettent de suivre l’évolution
du niveau d’exposition aux risques en garantissant la bonne application des
correctifs de sécurité issus de la veille.
– Pour les tests sur l’application Web à partir d’Internet, des plates-
formes de tests automatisés existent et permettent de réaliser des tests
de vulnérabilités récurrents ;
Actes du symposium SSTIC05 13
– Pour les tests en interne, des CD-ROMS ou des boitiers réalisant des
scans automatiques sont disponibles.
– Des audits de code et des tests d’intrusion, permettant de découvrir les
vulnérabilités et de les corriger avant que la menace du ver ne se profile.
Références
1. Perl.Santy http://securityresponse.symantec.com/avcenter/venc/data/perl.
santy.html
2. PHPBB Viewtopic.PHP PHP Script Injection Vulnerability http://www.
securityfocus.com/bid/10701
3. phpBB.com : : Creating Communities http://www.phpbb.com/
4. Malware Directory - W32/Blaster.a http://www.virusbtn.com/resources/
malwareDirectory/variants/W32-Blaster.a.xml
5. Routing Worm : A Fast, Selective Attack Worm based on IP Address Information,
http://tennis.ecs.umass.edu/~czou/research/routingWorm-techreport.pdf
6. Malware Directory - W32/Bagle.a, http://www.virusbtn.com/resources/
malwareDirectory/variants/W32-Bagle.a.xml
7. phpNUKE.org, http://phpnuke.org/
8. Linux : Kernel « Back Door » Attempt, http://kerneltrap.org/node/1584
14 Actes du symposium SSTIC05