Update (8 février 2009) : j'apprends que le site US de Kapersky y est passé aussi, sa base succombant aux coups d'une injection SQL...


Screenshot pwnage Nerim

Bon ben une machine de Nerim, ou du moins une partie non négligeable de son hébergement, se serait faite compromettre ? Ça arrive. On n'a aucune idée de l'ampleur des dégâts tellement il y a de méthodes pour parvenir à l'effet illustré ci-contre et qu'on peut encore constater sur pas mal de sites, alors que certains partent en 404 et d'autres sont apparemment revenus à la normale. Effet dûment accompagné d'une image de circonstance, d'une musique dont je vais cependant vous faire grâce, et d'un scrolling vertical d'un fort bel acabit. Le tout avec un pointeur vers un site qui n'est apparemment plus en ligne à l'heure où je rédige ces lignes.

Pour ceux qui ont du mal à lire les caractères du fait de la réduction de l'image, c'est à dire tout le monde, voici le texte[1]. Les parties en italiques ont été traduites de l'arabe par secdz.

HaCKeD By LiONS TeaM
Th!s S!T3 H4Ck3d By ErHaBi

.. :: ContacT :: .. 
.. :: ErHaBi HaCKeR :: ..  MSN: BzN@hotmail.com
.. :: FiRe HaCKeR:: ..  MSN: VLL@hotmail.com
.. :: ToNNiNO :: ..  MSN: AkO@HoTmAiL.CoM
.. :: DnYa AlWaLh:: ..  MSN: WaLhAno_911@hotmail.com
.. :: play with the best ... die like ather :: .. 

Dédicace à

NaJm-888
BaD_BoY
ASeeeR
DoN'T FoRgeT Our NamEs .. ( LIONS TeAm)
! We WiLL BaCk SooN DoN'T WoRRy !
see you !

Remets toi en cause et trouves la cause de la pénétration


Pour ce qui est de phpbb.com, la lecture du billet est très instructive. À la fois sur l'opportunisme de l'intrus et sur la démarche utilisée. Pour peu que cette histoire, qui n'a apparemment pas été démentie, se révèle vraie, c'est la lecture d'un exploit pour PHPlist qui aura tout déclenché. Phpbb.com utilisant ce logiciel pour gérer ses listes de diffusion, ce dernier a permis au pirate de faire ses premiers pas dans le système à l'aide d'un joli directory traversal permettant d'accéder à pléthore de fichiers arbitraires. Donc non, phpbb.com ne s'est pas fait pwner wia une faille PHPBB, mais via une application tierce...

En particulier, la lecture du fichier de configuration du serveur Apache et des logs d'erreur a permis à l'auteur du méfait de découvrir l'emplacement de l'installation de PHPBB sur le système de fichiers et en particulier le préfixe de nommage des fichiers d'avatars, lui permettant de les utiliser comme vecteur d'exécution pour de petits scripts lancés directement sur la machine. À partir de là, c'est un peu l'escalade, avec un attaquant qui, pas à pas, découvre de plus en plus d'informations et de capacité d'exécution. Je vous laisse découvrir la suite, qui n'a rien de techniquement extraordinaire certes, mais qui démontre assez bien comment s'enchaînent les actions et comment le château de cartes s'écroule au fur et à mesure de la progression de l'intrus.

On notera en particulier la récupération complète des bases utilisateurs et la publication des données qu'elles contiennent. En particulier, un peu moins de 30000 mots de passe stockés sous la forme d'un simple MD5 ont été crackés et diffusés. L'analyse faite par Robert Graham sur ces données est vraiment très intéressante à lire, je vous la recommande chaudement. On y apprend par exemple que 16% des mots de passe correspondent au prénom de l'utilisateur et 4% sont des variations du mot "password". Le mot de passe le plus fréquent est "123456" suivi de "password" et "phpbb". Deux tiers des mots de passe ont une longueur d'au plus 6 caractères, longueur qu'atteint la moitié d'entre eux. Seuls 5% des mots de passe dépassent les 8 caractères. Le même exercice, avec des jolis graphiques spécial manager, mais des chiffrent qui différent légèrement. Globalement, ces résultats pitoyables sont-ils surprenants ? Pas vraiment...

Maintenant, les personnes raisonnables se demanderont comment on peut se prémunir contre ce genre d'attaques. Dans un vieux billet, je revenais sur d'autres failles web classiques qui font mal. On est sur un cas du même tonneau ici, sauf qu'un bon gros directory traversal, c'est difficile à prévenir sans taper dans le code de l'application, ce qui veut dire trouver et corriger le bug, ou maîtriser l'hébergement de son site. Une méthode peut par exemple être d'essayer de limiter la portée des include à grand renfort de safe_mode_include_dir[2] par exemple, voire, pourquoi pas, de chrooter le serveur web. Pour autant, ce n'est pas bullet proof, même si ça limite la portée d'une exploitation réussie. En outre, de nombreuses applications sont tellement bien structurées, c'est à dire à peu près n'importe comment, ce qui rend l'utilisation de ce genre de directive largement inutile. Par contre, ça peut permettre d'éviter de se faire descendre un /etc/passwd, le fichier de configuration du serveur ou encore ses logs.

Ce qui ne rend pas l'application moins vulnérable ou exploitable, mais qui complique légèrement la vie de l'attaquant, comme on le verra si on se demande ce que devient la démarche décrite par l'attaquant de phphbb.com s'il n'était pas capable d'inclure un fichier en dehors de répertoires bien précis, ne serait-ce par exemple que la docroot...


Ces deux exemples montrent bien combien il est difficile de mettre en ligne des applications web de manière sécurisée. Entre les hébergements qui ne vous laisse pas assez de lattitude pour durcir la sécurité de votre site ou se montrent carrément laxistes par soucis de compatibilité, voire se font tout simplement compromettre leur infrastructure, et des applications potentiellement vulnérables sur lesquelles vous allez vous reposer, il y a de quoi se faire des cheveux blancs. En tout cas remettre plus la sécurité d'un site web à l'efficacité d'incantations vaudou qu'à de réelles compétences techniques...

Sinon, on peut aussi se dire qu'on maîtrise à peu près les choses, toucher du bois et espérer que...

Notes

[1] Les caractères arabes en moins, mais n'y voyez aucun racisme, c'est juste le jeu de caractères que j'utilise qui ne le permet pas.

[2] À noter que le safe mode va disparazître avec la version 6.0.0 de PHP.