Ce qui s’est passé
Deux logiciels très utilisés pour faire fonctionner des sites et des applications web ont reçu des correctifs de sécurité importants. Les deux problèmes touchent HTTP/2 (une version récente du protocole qu’utilisent les navigateurs pour dialoguer avec un serveur web).
Apache HTTP Server : exécution de code à distance sans authentification
- La fondation Apache a corrigé une faille jugée critique dans la gestion de HTTP/2 de son serveur web Apache HTTP Server.
- Selon les informations rendues publiques, un attaquant non authentifié (qui n’a besoin d’aucun compte ni mot de passe) pourrait exécuter du code à distance. Concrètement, il pourrait faire faire au serveur ce qu’il veut.
- Les versions touchées vont de 2.4.55 à 2.4.70. Le correctif est inclus dans Apache 2.4.71.
Node.js : 16 failles corrigées, dont des bogues HTTP/2
- Le projet Node.js (plateforme qui fait tourner beaucoup d’applications web et d’API écrites en JavaScript) a publié des mises à jour qui corrigent 16 failles.
- Parmi elles, des bogues dans la gestion de HTTP/2 permettent de faire planter le serveur, ce qui rend le service indisponible.
- D’autres permettent de récupérer des données appartenant à d’autres connexions. En clair, un visiteur malveillant pourrait voir des informations destinées à un autre utilisateur.
- Les versions précises à installer pour chaque branche de Node.js figurent dans le bulletin de sécurité officiel du projet. Ce bulletin fait foi.
Pourquoi ça compte pour une PME
Ces failles visent des serveurs visibles sur Internet : votre site vitrine, votre boutique en ligne, votre portail client ou une application de prise de rendez-vous. Un attaquant n’a pas besoin de piéger un employé. Il lui suffit d’atteindre le serveur.
| Faille | Ce que risque l’entreprise | Niveau de risque |
|---|---|---|
| Apache 2.4.55 à 2.4.70 (HTTP/2) | Prise de contrôle du serveur, vol de données, installation d’un rançongiciel (logiciel qui chiffre vos fichiers pour exiger une rançon), point d’entrée vers le reste du réseau | Critique : à traiter en urgence |
| Node.js, bogues HTTP/2 (plantage) | Site ou application hors service, perte de ventes, clients frustrés | Élevé |
| Node.js, bogues HTTP/2 (fuite entre connexions) | Exposition de données de clients à d’autres personnes. Au Québec, cela peut constituer un incident de confidentialité au sens de la Loi 25. | Élevé |
Le vrai piège pour une PME, c’est souvent de ne pas savoir ce qui fait tourner son site. Il a pu être monté par une agence web, être confié à un hébergeur ou dépendre d’un fournisseur de logiciel. Si vous ne savez pas quel serveur, quelle version et qui fait les mises à jour, vous ne pouvez pas savoir si vous êtes exposé.
Comment se protéger
Priorité 1 : identifier ce qui est exposé (aujourd’hui)
- Dressez la liste de tout ce qui est accessible depuis Internet : sites, sous-domaines, portails, API, extranets, outils internes publiés.
- Pour chaque élément, notez qui l’administre : votre équipe TI, un infogérant, l’hébergeur ou l’agence web.
- Écrivez par courriel à vos fournisseurs et posez trois questions précises :
- « Notre site utilise-t-il Apache entre 2.4.55 et 2.4.70, ou Node.js ? »
- « HTTP/2 est-il activé ? »
- « À quelle date le correctif sera-t-il appliqué ? Pouvez-vous le confirmer par écrit ? »
Priorité 2 : vérifier les versions (si vous gérez vos serveurs)
Sur le serveur, ces commandes affichent la version installée :
# Apache (selon la distribution)
apachectl -v
httpd -v
apache2 -v
# Le module HTTP/2 est-il chargé ?
apachectl -M | grep -i http2
# Node.js
node -vDepuis l’extérieur, vous pouvez vérifier si votre site répond en HTTP/2 :
curl -sI --http2 https://votre-site.ca -o /dev/null -w '%{http_version}\n'
# "2" = HTTP/2 actif ; "1.1" = HTTP/2 non utiliséAttention : certaines distributions Linux (Debian, Ubuntu, Red Hat…) appliquent les correctifs de sécurité sans changer le numéro de version principal. Le bon réflexe est donc de consulter l’avis de sécurité de votre distribution. Le numéro affiché ne suffit pas pour conclure.
Priorité 3 : corriger
- Apache : passez à la version 2.4.71, ou au paquet corrigé fourni par votre distribution. Redémarrez ensuite le service.
- Node.js : installez la version corrigée de votre branche, indiquée dans le bulletin officiel de Node.js. Pensez aussi aux images Docker (conteneurs) et aux environnements d’hébergement gérés, qui embarquent souvent leur propre version de Node.js.
- Vérifiez après la mise à jour que le site fonctionne et que la nouvelle version est bien celle qui tourne.
Mesure temporaire si vous ne pouvez pas mettre à jour Apache tout de suite
Désactiver HTTP/2 retire la partie vulnérable. Le site continue de fonctionner en HTTP/1.1 (un peu moins performant, mais sûr dans ce contexte).
# Dans la configuration Apache, limiter les protocoles :
Protocols http/1.1
# Ou, sur Debian/Ubuntu, désactiver le module HTTP/2 :
sudo a2dismod http2
sudo systemctl restart apache2Il s’agit d’une mesure provisoire. Elle ne remplace pas le correctif. Prévoyez la mise à jour dans les jours qui suivent.
Priorité 4 : surveiller et réagir
- Surveillez les journaux du serveur web : redémarrages inattendus, plantages répétés, processus inconnus, fichiers récemment créés dans les dossiers du site.
- Si un serveur Apache vulnérable est resté exposé, traitez-le comme potentiellement compromis. Après la mise à jour, faites vérifier l’absence de traces d’intrusion.
- Si des données de clients ont pu fuiter, informez votre responsable de la protection des renseignements personnels. Celui-ci évaluera l’obligation de déclaration prévue par la Loi 25.
Cadrage ITIL : qui fait quoi
| Processus | Action | Responsable |
|---|---|---|
| Gestion des vulnérabilités | Inventaire des serveurs Apache et Node.js exposés, priorisation (Apache = critique) | TI interne ou infogérant |
| Changement urgent | Mise à jour vers Apache 2.4.71 et Node.js corrigé, ou désactivation de HTTP/2, avec un plan de retour arrière | Administrateur système, avec l’approbation du gestionnaire |
| Gestion des fournisseurs | Confirmation écrite de l’hébergeur ou de l’agence web | Responsable TI ou direction |
| Gestion des incidents | Analyse si des signes de compromission ou de fuite apparaissent | Équipe sécurité ou prestataire de réponse aux incidents |
La leçon durable : tenir un inventaire de vos actifs exposés
Chaque nouvelle faille sur un serveur web pose les mêmes questions : qu’avons-nous sur Internet, en quelle version, et qui le met à jour ? Un inventaire simple suffit pour répondre en quelques minutes au lieu de plusieurs jours. Une feuille de calcul tenue à jour peut faire l’affaire. Pour chaque actif, notez :
- Le nom de domaine ou l’adresse
- Le logiciel et sa version
- L’hébergeur
- Le contact technique
- La date de la dernière mise à jour
Mettez cet inventaire à jour à chaque nouveau projet web. Exigez aussi de vos fournisseurs, dans vos contrats, un délai d’application des correctifs critiques.
