L’histoire commence par un trou de sécurité dans l’outil de CSM joomla que j’utilise sur certains sites. Ce bug permet à tout utilisateur sachant l’exploiter d’imposer une nouveau mot de passe à l’utilisateur administrateur du site pour faire simple. Le bug est identifié en version 1.5.x depuis le 1er Aout.
Un de mes sites a donc été attaqué vers le 14 Aout : un utilisateur a pris le contrôle d’un des site pour y poster son article sur son sentiment au sujet de la Russie.
Un second est passé sur le même site pour le fermer, tout en modifiant la message et ce ventant de ce magnifique acte de bravoure… A noté que n’importe quel gamin de 10 ans ayant connaissance de la procédure à suivre peut en faire autant … enfin !
La dernière attaque est d’hier (17 Aout) et m’aura permis de me rendre compte de la faille. Celle-ci, bien qu’utilisant le même procédé est beaucoup plus intéressante car mettant en œuvre une technique plus évoluée et ayant plus de conséquences sur mes sites.

Mon ami de Turquie est donc venu visiter l’un de mes site à partir d’une simple recherche google à partir de laquelle il identifie les site basés sur joomla et offrant la porte d’entrée adéquat. La méthode est simple, ingénieuse. Une fois entré, il profite des fonctionnalités de ce CSM permettant de modifier manuellement les templates pour injecter son propre code PHP à la place de celui du template par défaut. Il a ainsi plus placer une petit script PHP rigolo aux fonctionalités diverse : scan de fichiers avec sticky bit, recherche de fichiers, édition de fichiers, exécution de commande shell … Le tout heureusement limité au droits de l’utilisateur apache…. mais c’est déjà pas mal !
Au final, mon ami aura passé une dizaine de minutes, le temps d’installer sa tambouille puis de modifier tous les index.php de mes sites ouaib hébergés sur ce même serveur pour les remplacer par le sien, une bannière php statique se ventant de cet acte de piraterie à l’intérêt au combien inutile.
Vient alors le temps de la résolution et du retour à la normale … de quoi me remettre dans le bain apres 15j de vacances bien mérités… Toutes ses actions étant convenablement tracées dans les fichiers de log apache il restait à réaliser le retour en arrière puis à colmater les brèches. Je suis en général bien armé pour cela avec une batterie de backup… Mais lois de l’emmerdement maximal oblige, ceux-ci ne fonctionnaient plus depuis trop longtemps sur ce serveur pour être utilisable … bref une journée de galère pour une récupération complète, aux pertes près issues de mauvaises manipulations de ma part …

Au final, je tire quelques conclusions de cela:

• Je suis conforté sur les risques liés à l’usage de CMS qui nécessitent d’être à même de patcher à tout moment les sites ainsi construits. Cette manip n’étant pas évidente dès que la version en ligne est un peu trop ancienne ou que des éléments ont été modifiés suite à une adaptation du site. Un développement custom, même s’il possède des trous de sécurité ne sera victime que d’une attaque ciblée et non de ce type d’attaque hasardeuse
• L’utilisateur apache ne devrait pas avoir de droits d’écriture sur aucun des fichiers / répertoire ; seulement, avec tous les automatismes offerts par les site ouaib actuels (installation de modules, templates) il est difficile de réaliser cela sans se priver de certaines fonctionnalités. Je tire donc comme conclusion que l’usage d’un CMS, entre autre doit passer par une étude approfondie des droits à affecter à chaque fichiers/rep avant une monté en production.
  Je pense d’ailleurs que les CMS devraient intégrer des scripts de protection et de dé-protection des fichiers par exemple, ou prévoir que certaines opérations soient réalisées en sudo avec un autre utilisateur que apache. En tout cas, il vaut mieux désactiver des fonctionnalités que de perdre un site suite à un crack.
• Enfin il est vraiment nécessaire de vérifier ses backup à une fréquence suffisante … en vérifiant qu’ils puisse bien être décompressés et qu’ils sont donc utilisable.

Voici donc quelques pensés sur la forme suite à cette attaque … Sur le fond, je ne cesse de considérer qu’il n’y a aucun héroïsme à utiliser des failles trouvées par d’autres, pas plus que de taguer un mur, ça n’exprime rien de plus que lorsqu’un chien pisse sur un lampadaire et la première pluie emmènera tout avec elle. Le seul Hacker est celui qui trouve – invente la faille par la lecture du code ou l’analyse du protocole, il n’a pas besoin d’en faire l’illustration sur l’espace public pour que son travail soit reconnu.