ZF05 thoughts

L

a publication du 5e volume de Zero for 0wned mercredi matin a fait du bruit. Et pour cause. Après les rumeurs de 0day OpenSSH, la vague trollesque anti-sec sur FullDisclo ou encore une nouvelle compromission chez Matasano, c'est au tour d'une belle brochette de stars de passer au pilori, avec en particulier Kevin Mitnick et Dan Kaminsky.

Publication qui à mon sens tombe à point nommé pour illustrer par la pratique le dernier billet de Newsoft, en particulier sa dernière partie sur la dépendance aux tierces parties, ou mes réflexions sur la sous-traitance. Car dans au moins trois des cas épinglés, tout paraît bel et bien commencer par la compromission d'un tiers, typiquement la plate-forme d'hébergement...

Au-delà des bonnes pratiques communément admises et pas forcément appliquées, comme la gestion des mots de passe qu'on retrouve à foison dans ce document, l'hébergement d'un site web sur une plate-forme mutualisée est à lui-seul un risque majeur. Comme le montre le cas du site web InvisibleThingsLab citée rapidement dans la partie Pwnie Awards et sur lequel Joanna Rutkowska revient vaguement en post-scriptum de son dernier billet. Ou celui de Kevin Mitnick dont l'ex-hébergeur s'est apparemment fait compromettre. Ex, puisque Mitnick a finalement^[1] décidé de s'en trouver un nouveau. Est-ce que ça va prévenir une nouvelle intrusion ? Possible... Ou pas...

Idem pour Julien, dont le site s'est parait-il trouvé dans le tas suite à, lui aussi, la compromission de l'infrastructure de son hébergeur. Il ne m'appartient pas de donner de détails ici, mais ça peut quand même inspirer quelques commentaires. En particulier, il me semble que cette infrastructure devait quand même présenter des faiblesses architecturales, ne serait-ce que pour que la compromission de l'hébergement web permette d'accéder à la messagerie de l'intéressé... J'ai certes déjà vu des applis web avec des mots de passe de messagerie en dur dans des scripts PHP genre webmails pourries, mais pour autant que je sache, ce n'est pas le cas ici. Du coup, pour sauter comme ça des pages web au serveur de messagerie qui fournit les mailbox... D'où ma conclusion...

Évidemment ce blog ne déroge pas à la règle. Il est hébergé sur une plate-forme mutualisée entre pas mal d'utilisateurs. Rien à voir avec un hébergement "professionnel", il s'agit plus de partager une machine entre amis, mais ça reste du mutalisé quand même. Ce qui veut dire même en configurant mon site au petits oignons, en vérifiant un peu ce que je mets dessus et tout le toutim, je pourrais encore me faire pwner via le site d'un autre utilisateur du serveur. Ou via un accès SSH avec un mot de passe faible. Ou je ne sais quoi d'autre, sans même parler d'un 0day sur une application accessible...

Mais enfin, me direz-vous, z'avez qu'à mettre les droits qui vont bien et pis vala. Et ben oui, yapuka. Sauf que toutes les webroot doivent être accessibles en lecture au moins à www-data, forcément, c'est un service web. Que certaines parties doivent même autoriser l'écriture pour ceux qui ont des scripts d'upload. Et que la capacité de PHP à isoler les utilisateurs les uns des autres est tout simplement... calamiteuse. Typiquement, il n'existe apparemment pas de moyen de faire quelque chose d'aussi con que :

open_basedir ~/www/webroot/

Vous me direz, mais qu'est-ce que tu me racontes là ?! Si tu actives le safe mode, un script PHP d'un utilisateur ne peux accéder à des fichiers qui lui ne appartiennent pas. Effectivement. Sauf que vous avez des gens qui ont besoin de faire de l'upload de temps en temps. Ben oui, parce que comme votre process tourne en www-data, il écrit en www-data. Et donc quand vous voulez accéder aux fichiers qui ont été déposés par votre script, c'est le méga fail. À moins de coller le GID à www-data et de redescendre le check au niveau du GID. Ça limite certes la portée des scripts PHP en terme de lecture du système de fichiers, mais ça n'empêche pas les scripts d'un utilisateurs d'aller lire ceux des autres. C'est comme ça que naissent les fameux "directory traversal"...

De toute manière, PHP est un échec du point de vue sécurité. Déjà qu'il est difficile, voire impossible, à gérer avec les fonctionnalités offertes^[2], s'ajoutent à celà une tripotée de failles dont certaines ne seront probablement jamais corrigées. C'était d'ailleurs le point de départ du talk qu'a donné Stefan Esser à Syscan puis BlackHat. Il suffit de lire ses slides pour comprendre que même en ayant fait votre possible pour blinder votre installation, y compris au niveau du socle système, l'exploitation des-dites failles permet de ruiner complètement vos efforts.

Alors il faut s'y faire, à cette épée de Damoclès qui nous pendouille au-dessus de la tête. Un jour viendra où on se fera déchirer son site web, avec tout ce qui traînera à côté. Et que si ça n'est pas encore arrivé, c'est probablement plus par manque d'attention de la part de potentiels attaquants, que par les fruits d'un long travail de sécurisation...

Ceci étant, pour en revenir à ZF05, aussi plaisante que puisse être la lecture de ce texte rempli de jolis ASCII arts et plein d'humour corrosif, il m'inspire plusieurs choses. D'abord, il contient très peu d'information sur les méthodes utilisées pour les compromissions démontrées. En dehors des problèmes de mots de passe, pas grand chose. Nib, nada, queudal. C'est à la fois inquiétant pour certains, qui y trouvent de quoi donner crédit aux rumeurs galopantes, et rassurant pour d'autres qui se disent que les détails ne sont pas là parce qu'ils s'agirait d'attaques de faible niveau. Faut-il pencher dans un sens plutôt que dans l'autre. Humm...

Ensuite, que les configurations attaquées et l'ampleur de dégâts sont extrêmement variables. On va de la compromission totale d'une architecture dédiée et opérée personnellement dans le cas de Kaminsky, qui prend extrêmement cher pour le coup mais apparemment avec philosophie, à la simple lecture du contenu de la webroot, donc de données publiques, dans le cas de Joanna Rutkowska. Entre les deux, le reste, à divers degrés de sévérité.

Enfin, si j'arrive à comprendre ce que veut démontrer l'auteur dans sa démarche, il me semble aurait pu faire preuve d'un peu de discernement et de retenue dans ses révélations sans pour autant déformer son propos et ses effets fracassants. Je pense en particulier aux messages pour le moins personnels échangés par email, chat ou je ne sais quel moyen. Dans le cas de Kaminsky typiquement, on peut penser ce qu'on veut de lui et même le détester, il ne méritait certainement pas que des épisodes ambarassants de sa vie conjugale soient balancés sur la place publique. Réflexion qui s'appliquent évidemment à d'autres cas ici. Je ne sais pas vous, mais je trouve ça tellement inutile quand ça en devient terriblement méchant et donc un peu agaçant...

PS : Non, je n'ai pas mis de lien vers le document en question. Aucune raison particulière sinon qu'il est linké et mirroré à peu près partout, et surtout que je n'ai pas envie de participer directement à la diffusion des passages déplacés sus-mentionnés^[3]. De toute manière, je fais confiance à vos Google skillz pour le retrouver en deux temps trois mouvements ;)

PPS : Les Pwnie Awards 2009 sont en ligne. Zéro pointé sur mes propositions...

Notes

[1] Parce que ce n'est pas comme si c'était la première fois chez eux...

[2] Si on a quelque courage, on peut toujours l'exécuter comme CGI sous suexec, mais je ne crois pas que ce soit une si bonne idée...

[3] Ce qui veut également dire que les URL seront systématiquement retirée des commentaires lorsqu'elles pointeront dessus.