« Après le séisme PHP, une seule chose est claire : le risque zéro n’existe plus. »

Une course contre la montre

Mardi 20 octobre au soir, l’équipe PHP annonce des failles critiques, dont les correctifs sortiront le lendemain à 16 h. Comment Oxeva a pris de l’avance ?

Nous avons nos propres outils de veille et d’analyse développés en interne. Ils tournent uniquement sur nos serveurs et surveillent constamment notre infrastructure. Sur des sujets aussi sensibles, nous voulons contrôler précisément où sont les données.

Du coup, nous savions que quelque chose se préparait dès le mardi soir. Le mercredi, vers 10 h, nous connaissions à peu près le contenu des failles. Ça nous a donné six heures d’avance pour déployer un maximum de contre-mesures afin d’empêcher l’exploitation des failles, ou au minimum la rendre beaucoup plus complexe.

Concrètement, qu’est-ce qui a été fait ?

Les failles exploitaient une fonctionnalité activée par défaut dans PHP, mais quasiment inutilisée. Nous l’avons donc tout simplement désactivée chez tous nos clients. Nous avons aussi déployé des règles de pare-feu spécifiques pour enregistrer et bloquer les tentatives d’exploitation. Selon l’environnement, ça nous a pris entre quelques minutes et quelques heures, mais tout était verrouillé avant 16 h, l’heure de publication du correctif.

Une fois le patch sorti, nous sommes même allés au-delà des correctifs officiels, arrêtés à la version 8.2, en corrigeant également ces failles dans les versions 8.1, 8.0 et 7.4. Par prévention, nous avons aussi envoyé aux clients qui déploient eux-mêmes leurs applications la liste de ce qui était vulnérable chez eux.

« Nos clients nous paient aussi pour démêler le vrai du faux, pas pour appliquer une recette lue sur un forum obscur. »

Les clients ont-ils paniqué ?

Forcément… Dès 9 h le mercredi, une dizaine de messages inquiets sont arrivés au support. Nous avons réagi très vite en informant nos clients que nous étions en train d’agir. Cela a suffi à calmer les esprits.

Et à 16 h 02, certains clients nous écrivaient déjà : « Le correctif est sorti, vous l’appliquez quand ? » Sauf qu’en open source, le correctif doit encore être empaqueté, puis intégré dans chaque distribution. Comme nos contre-mesures étaient déjà en place, nous avons d’abord vérifié que le correctif officiel fonctionnait avant de le déployer chez tous nos clients. C’était chose faite dans les heures qui ont suivi.

Au final, y a-t-il eu de la casse ?

Non, pas à notre connaissance ! En revanche, il a fallu gérer les rumeurs. Sur des forums, on lisait par exemple qu’il suffisait de modifier telle ou telle option, comme désactiver la limite mémoire de PHP. Or l’enlever, c’était pire. Nos clients nous paient aussi pour démêler le vrai du faux, pas pour appliquer une recette lue sur un forum obscur.

Compliquer la tâche des attaquants

Tous les articles parlaient de failles critiques. Faut-il nuancer ?

Critiques, elles l’étaient, car une fois exploitées, elles donnaient les pleins pouvoirs sur le site. Mais elles étaient difficilement exploitables : il fallait de l’expertise et beaucoup de tentatives. Et justement, nos contre-mesures rendaient ces tentatives encore plus difficiles. Nous avions confiance dans la conception de notre défense, là aussi grâce aux outils développés en interne. Bien sûr, « difficilement exploitable » ne veut pas dire « pas exploitable du tout ».

«  Il faut changer notre façon de concevoir la sécurité. »

Ces alertes se multiplient-elles ?

Effectivement… Avant, une faille critique nous concernant arrivait tous les deux ou trois ans, et tout le monde se mettait sur le pont. Avec l’IA, le rythme s’emballe. Il y a quelques années, on recensait quelques dizaines de failles critiques par mois, tous logiciels et tous environnements confondus.

Aujourd’hui, un mois ordinaire en compte environ 600. Auparavant, il y avait une prime au défenseur. Désormais, c’est l’inverse. C’est pour ça qu’il faut changer notre façon de concevoir la sécurité. Avant, on bâtissait un château fort quasi imprenable, mais une fois à l’intérieur, toutes les portes étaient ouvertes. C’est terminé ça… Même avec la meilleure sécurité au monde, la probabilité qu’un attaquant parvienne à pénétrer un système connecté à internet n’est plus nulle. Donc on cloisonne tout, on surveille pour repérer vite l’intrus et on limite au maximum ce qu’il peut faire une fois dans le système.

Le début d’une nouvelle ère

Qu’est-ce que cela change pour les entreprises ?

Ces failles ont surtout piégé ceux qui s’hébergent seuls, sur un serveur dédié à petit prix. Le développeur de l’équipe sait normalement le gérer, mais pour peu qu’il ne soit pas disponible ou qu’il ne sache pas quoi faire, c’est la catastrophe. Même les professionnels peuvent avoir un temps de retard, alors que dire de ceux dont ce n’est pas le métier ? Chez Oxeva, ça fait longtemps que nous le disons : si votre activité repose sur votre hébergement, arrêtez de bricoler et de gérer tout seul dans votre coin. Faites-vous accompagner.

« Notre métier n’est plus d’empêcher l’exploitation des failles de sécurité, c’est d’augmenter leur complexité d’exploitation. »

L’infogérance coûte plus cher, c’est vrai. Mais pour une boutique en ligne ou un éditeur SaaS avec de gros enjeux économiques, une faille mal gérée peut engendrer d’énormes pertes.

Tout anticiper, est-ce possible ?

Non, on ne peut pas tout prévoir. En sécurité, il faut rester humble. Après le séisme PHP, une seule chose est claire :  le risque zéro n’existe plus. Beaucoup de gens du secteur partagent ce constat, mais personne n’ose le dire. L’hébergeur qui vous promet « chez moi, jamais de coupure » vous ment. Celui qui vous garantit « chez moi, votre site ne sera jamais piraté » vous ment aussi.

Il est temps de remettre les pieds sur terre et de partir du principe qu’un jour, un attaquant parviendra à exploiter une faille. Notre métier reste bien sûr d’empêcher l’exploitation des failles, mais il consiste aussi, de plus en plus, à limiter ce qu’un attaquant pourrait faire s’il y parvenait malgré tout. C’est pourquoi, le jour où ça arrive, nos clients sont parés : tout est cloisonné, nous avons les traces, les sauvegardes et les outils pour comprendre précisément ce qui s’est passé. C’est là que l’infogérance prend toute sa valeur.