CSP : à faire pour protéger son site Web

Cet article rappelle un problème de sécurité de SPIP (qui a entraîné la sortie de SPIP 2.0.9 ) et comment aider à réduire le risque que vos sites SPIP soient piratés à l’aide de failles similaires à l’avenir.

 Une coïncidence de vulnérabilités

Le 5 août, un de nos clients m’a fait parvenir une notification que Google avait détecté des logiciels malveillants sur leur site Web. Après un rapide coup d’œil sur le site, j’ai découvert que quelqu’un avait injecté un <iframe> dans le site - le titre d’une nouvelle, pour être précis. J’ai jeté un œil à l’interface d’administration et j’ai découvert que le titre de cette nouvelle contenait effectivement le code <iframe>. Au début, je pensais que c’était simplement une question pour un attaquant de deviner ou de voler un mot de passe, mais il n’y avait pas d’accès FTP pendant cette période et les seuls utilisateurs de SPIP avaient des mots de passe forts. C’est à ce moment que j’ai commencé à m’inquiéter.

J’ai pris une sauvegarde de l’ensemble du site via FTP et j’ai eu un rapide grep, mais je n’ai rien trouvé qui ait sensiblement changé. Tout ce qui est autre que le config/répertoire. D’une manière ou d’une autre, le site était passé de MySQL à SQlite2. Demander au bureau a clairement montré qu’aucun de nous ne ferait quelque chose d’aussi étrange (stocker des bases de données SQLite dans la racine Web est une chose assez étrange à faire en premier lieu !), Donc j’étais perplexe, surtout parce que cette base de données SQLite était pleine du contenu correct, à l’exception de l’insertion du code <iframe> dans un libellé.

J’ai sauté au téléphone vers la société d’hébergement et leur ai demandé de vérifier les journaux de leur serveur Web et leur excellent administrateur système a rapidement trouvé un tas d’accès à ./ecrire/ (l’interface d’administration SPIP) qui semblait étrange (en particulier avec tous les ..s et //s dans les GETparamètres), spécifiquementsr car ils sont venus d’Arabie Saoudite. Il a vidé ces entrées et me les a envoyées par e-mail (et réinitialisé chaque mot de passe associé au compte). Maintenant, j’avais quelque chose sur quoi travailler.

En filtrant les différents bruits que vous obtenez dans les fichiers journaux http (fichiers css, fichiers javascript, etc.), il était clair que quelque chose de vraiment étrange se passait. L’attaquant, quel qu’il soit, semblait exploiter un bug de fuite de chemin dans SPIP (tel qu’investigué par Pierre R., qui a terminé son stage avec nous la semaine dernière) : cela, combiné à un bug d’autorisation, permettait à quiconque de faire effectuer une sauvegarde par SPIP (et écrivez-le avec le nom de fichier choisi par l’attaquant et dans n’importe quel répertoire sur lequel le serveur peut écrire). Pour aggraver les choses, ils pourraient utiliser un autre trou de sécurité dans SPIP pour commencer une réinstallation et ils ont pu créer leur propre base de données SQLite et exécuter la procédure d’installation. Après avoir restauré la sauvegarde qu’ils ont déclenchée, il y avait très peu de moyens de dire que le site avait été piraté !

 Précautions d’exploitation

Ces défauts sont très graves et, bien que le correctif soit très court ( ce correctifmodifie quatre lignes de code dans trois fichiers), ce me semble indiquer un défaut de conception qui peut être observé dans de nombreuses applications Web : des morceaux de code sont responsables de leur propre validation d’entrée et de leur propre vérification d’authentification et / ou d’autorisation. Le problème est exacerbé par le fait que SPIP encourage les utilisateurs à l’installer avec une configuration non sécurisée. Tout le monde le dit ensemble : si l’application peut modifier son code, elle n’est pas sécurisée.

Empêcher le site d’être piraté est assez simple : tout ce que vous devez faire est d’empêcher SPIP de modifier config/et les fichiers et dossiers qu’il contient. C’est ça : juste chmod -R -w config/. Terminé !

Pour une meilleure sécurité, assurez-vous que ./config/ -et le contenu de celui-ci- ne sont pas la propriété de l’utilisateur serveur Web (généralement nobody, www-data ou similaire). Sinon, l’attaquant rusé pourra peut-être y exécuter un chmod et déclencher le bug d’origine. Si vous êtes paranoïaque comme moi, vous voudrez également ajouter un certain nombre de choses à votre configuration (au fichier .htaccess ) Apache :

Désactivez les index de répertoires automatiques ; ils ne font que divulguer des informations à un attaquant potentiel.
Désactivez l’ exécution PHP à l’ intérieur IMG/, local/et tmp/. Tout script dans ces répertoires va être include() édité et n’a pas besoin d’être directement exécutable.
Refuser tout accès à votre /répertoire tmp, soit avec Deny from all, soit en utilisant RewriteRules.
Pour les plus paranoïaques, vous pouvez essayer de :

Renommer spip.php , squelettes/et ecrire/pour réduire votre exposition aux attaques automatisées.
Supprimez l’inclusion des noms de produits et des numéros de version (en particulier, l’en- Composed-By:tête qui identifie la version SPIP et de tous les plugins installés).
Inutile de dire que je vais continuer à faire la plupart de ces choses sur mes sites SPIP, même après la sortie de la version 2.0.9 nouvellement sécurisée.

 Conclusion

Il y a plusieurs morales qui, je pense, peuvent être tirées de cette histoire :

Une application ne doit pas pouvoir modifier son propre code. S’il « en a besoin », il sera alors peu sûr.

Il y a diverses raisons pour lesquelles les développeurs de SPIP ne sont pas d’accord avec cela - et c’est, bien sûr, leur prérogative - mais, comme nous l’avons tous découvert la semaine dernière, cela les rend, ainsi que leurs utilisateurs, plus vulnérables.

Une application doit laisser la vérification de l’authentification ou de l’autorisation de l’utilisateur au code « action ». Le cadre de l’application doit exiger une authentification pour toutes les actions et une politique d’autorisation par défaut raisonnable. Cela devrait certainement permettre de contourner ces valeurs par défaut ; mais la valeur par défaut doit être sécurisée, pas non sécurisée. Il est plus facile d’autoriser ce qui est nécessaire que de nier ce qui ne l’est pas.

Cela a été un bon conseil depuis qu’il a été proposé par Saltzer et Schroeder dans leur article de 1974 sur la protection des informations dans les systèmes informatiques .

Une réponse rapide et efficace des développeurs peut transformer une catastrophe potentielle en un moment de bien-être. Pour ma part, je me sens un peu plus indulgent envers ce type de bogue lorsqu’il a été traité et résolu aussi rapidement qu’il l’était.

Cet article pourrait être lu comme une critique assez sévère de SPIP, mais ce n’est pas comme cela qu’il faut le prendre. Ce sont des classes de défauts assez courantes - validation d’entrée incorrecte et autorisation utilisateur inefficace - et peuvent être difficiles à corriger. La validation des entrées, en particulier, peut être un cauchemar d’encodage et de décodage de bogues et de vulnérabilités, avant même que vous ne puissiez commencer à penser aux règles de validation spécifiques à l’application.

Sur un plan complémentaire : les développeurs de SPIP ont fait un excellent travail pour trouver et résoudre le problème. Dans la journée suivant mon rapport initial, ils avaient publié SPIP 2.0.9 , un correctif pour les personnes qui ne veulent pas mettre à niveau et la mise-à-jour du script « écran de sécurité » (un script autonome qui bloque les exploits sans encore résoudre les problèmes). Bravo à l’équipe Bravo SPIP !