Gajus - Fotolia

Projet IT

Enquête sur un détournement de site Web

Nombreux sont les sites Web de petites organisations privées comme publiques qui ne profitent pas de l'entretien et de la surveillance dont ils auraient besoin. Alors un jour ou l'autre, c'est le piratage. Enquête sur l'un d'entre eux.

Valéry Rieß-Marchive
par
Publié le: 13 févr. 2018

Tout a commencé fin janvier, avec la réception d’un e-mail d’OVH : l’hébergeur faisait état de l’envoi de pourriels à partir d’un blog animé par Wordpress. Ses filtres les avaient repérés. L’examen des fichiers du blog a rapidement permis de confirmer une intrusion, voire plusieurs, et un détournement des ressources du serveur.

Un attaquant s’était infiltré dans l’espace d’hébergement le 27 décembre. Il avait alors déposé quatre fichiers PHP. L’un d’entre eux pouvait être utilisé pour envoyer des e-mails en profitant des fonctions ad hoc du langage de script. Deux autres – ou plutôt deux instances différentes du même code – pouvaient servir à déposer des fichiers sur l’espace d’hébergement. Le quatrième n’était autre qu’un remote shell, dérivé du bien connu Locus7s, lui-même dérivé du shell c100 : il donne un accès distant complet à l’espace d’hébergement, permettant d’y déposer, effacer ou modifier n’importe quel fichier.

Là, Vincent Nguyen, du Cert de Wavestone, relève que connaître « les droits avec lesquels le serveur Web tourne serait intéressant pour comprendre jusqu’où peut effectivement aller l’attaquant. Pour un serveur Web compromis avec peu de droits et cloisonné, ce sera moins grave que pour un serveur s’exécutant en root sur le système ».

D’autres « visites » ont eu lieu par la suite – impossible à ce stade de dire s’il s’agissait de personnes différentes, du même acteur, voire d’un même groupe acteur. Le 8 janvier, une nouvelle instance du code PHP permettant le téléversement de fichiers est ainsi déposée. Ce sera également le cas le 11 janvier. Mais ce jour-là, les intrus ont également modifié certains fichiers de Wordpress pour installer un mineur de crypto-deniers sur les pages du Blog : il ne s’agissait ni plus ni moins que de code javascript Coinhive masqué.

Cela ne s’arrête pas là : une dernière visite a eu lieu le 24 janvier, pour déposer deux instances d’un code PHP d’envoi d’e-mails. L’enquête montrera rapidement que c’est l’une d’entre elles qui a été utilisée de manière conséquente pour l’envoi des pourriels découverts par les filtres d’OVH.

La chasse aux indices

Mais comment les intrus sont-ils parvenus à s’infiltrer ? L’examen des journaux d’activité d’Apache, à l’aide de l’incontournable Scalp, écrit en Python, fait ressortir un nombre considérable de ce qui s’avère n’être que des faux positifs. Difficile de ne pas se laisser noyer. Néanmoins, au milieu de tout ce bruit fond se cachent aussi de très nombreuses tentatives d’attaque, par XSS, inclusion de fichiers locaux appel à des scripts inexistants, recherche de plug-ins pouvant présenter des vulnérabilités, etc. L’éventail est large.

Vincent Nguyen relève qu’il y a « en effet toujours un bruit de fond orchestré par de multiples robots scanneurs à la recherche de vulnérabilités applicatives, systèmes de gestion de contenus ou middleware obsolètes ».

Et en fait, les attaquants auraient tort de se priver : si Wordpress a été régulièrement mis à jour, on ne peut pas en dire autant de son socle… PHP en était resté là à une version 4.4. De l’archéologie rapporté à l’histoire du Web.

Thomas Chopitea, créateur de la plateforme de gestion du renseignement sur les menaces Yeti, et ancien du Cert de la Société Générale, souligne qu’il n’est « pas sûr que ça ait un rapport avec la compromission du site. Si les attaquants sont passés par un mot de passe faible ou bolé, ou par une extension vulnérable, la version de PHP n’a rien à voir ». Et justement, comme l’enquête le montrera plus loin, les intrus n’ont pas profité de vulnérabilités de PHP.

L’examen des journaux Apache fait ressortir plusieurs milliers de tentatives d’authentification sur Wordpress, entre décembre et janvier. Et à compter du 27 décembre au matin, certaines tentatives ont été couronnées de succès.

C’est là qu’il devient intéressant de faire le lien entre les dates et heure de création des fichiers PHP importuns avec les journaux d’Apache : ceux-ci confirment l’accès à l’interface d’administration de Wordpress par simple utilisation d’identifiants existants.

Ce qu’ont fait les attaquants

Le 27 décembre après-midi, en l’espace d’une heure, trois fichiers sont ainsi déposés à partir de trois adresses IP différentes – dont aucune n’était un nœud de sortie Tor à cette date. Au total, vingt-sept accès ont eu lieu sur la période étudiée, à chaque fois à partir d’une adresse différente. C’est systématiquement un navigateur Firefox 50 sous Windows 7 qui apparaît. Reste à savoir s’il est réel, relève Vincent Nguyen.

Dans la pratique, l’examen des journaux Apache indique que les attaquants n’ont utilisé que l’un des derniers scripts PHP déposés, et cela pour envoyer des pourriels. Au passage, Vincent Nguyen souligne que « les logs Apache ne montrent que les accès aux fichiers depuis Internet. En local, l’attaquant aurait très bien pu faire un $sh php fichierdepose.php, et ceci ne laisserait pas de traces dans les journaux Apache ». Et de suggérer d’examiner, si possible, le fichier d’historique du shell, voire la mémoire vive du serveur – s’il n’a pas été redémarré à la suite de la découverte des incidents –, et bien sûr des scripts PHP impliqués.

Les journaux d’Apache font toutefois ressortir que les assaillants ont accédé – ou tenté d’accéder – à ce script d’envoi de pourriels à partir de près de 5000 adresses IP en l’espace de quelques jours, entre la fin janvier et début février. Une fois nettoyée des adresses privées et des doublons, la liste contient toujours près de 4000 adresses IP différentes, accessibles publiquement sur Internet. Surprise, là, c’est systématiquement Firefox 56 sous Windows 10 qui apparaît comme navigateur.

Au total, 11 des 27 adresses IP observées pour l’accès à l’interface d’administration du blog renvoient à la Corée du Sud, trois à la Thaïlande, deux au Venezuela, autant aux Etats-Unis, au Japon et à l’Allemagne, une au Vietnam, à la Roumanie, à l’Italie, à l’Indonésie, à l’Espagne, et à l’Australie.

Shodan ne dispose pas d’information sur toutes ces adresses. Mais celles qui sont connues de lui présentent toutes un point commun : elles cachent des systèmes obsolètes et vulnérables.

Qui sont-ils ?

Pêle-mêle, on relèvera un service Dropbear en version 0.46, un service Ldap exposé sur Internet, des services RTSP, un système de help-desk animé par Tomcat/Coyote 1.1, ou encore un routeur sans fil annonçant une version non corrigée de son logiciel interne. De là imaginer que bon nombre de ces adresses cachent au moins un système compromis par un maliciels, il n’y a qu’un pas, rapide à franchir. Pour Vincent Nguyen, il apparaît de fait probable qu’il y ait là « un sacré nombre de robots ».

Aucune de toutes les adresses IP étudiées ne correspond à un nœud de sortie Tor. Les adresses IP utilisées pour l’envoi des pourriels se rapportent à une centaine de pays différents. Mais c’est la Corée du Sud qui arrive en tête de liste, avec plus d’un millier d’adresses IP uniques identifiées. Le Japon arrive en seconde position, loin devant les autres pays représentés.

Est-ce une surprise ? Pas vraiment. De fait, selon Kaspersky, c’est la Corée du Sud qui tient la première place, au dernier trimestre 2017, du podium du nombre de serveurs de commande et de contrôle installés. Autrement dit, le pays abrite, sans doute largement à son insu, un grand nombre de machines compromises exploitables par des tiers cyber-délinquants.

Et là encore, si Shodan ne référence que quelques-unes de ces milliers d’adresses, ce qu’il en connaît n’a rien de bien brillant. Et l’on ne se penchera pas sur toutes les adresses à partir desquelles ont été lancées des tentatives d’authentification avortées. Ce serait en ajouter un bon millier de plus.

Le tableau ainsi dépeint souligne l’insécurité latente qui règne sur Internet, grâce à quantité de systèmes vulnérables et qui peuvent, dès lors, être détournés. Une menace dont il est difficile d’avoir pleinement confiance tant que l’on n’est pas confronté concrètement à des chiffres qui donnent le tournis.

Thomas Chopitea le souligne d’ailleurs, « Wordpress est le CMS le plus utilisé au monde. Quel pourcentage est mis à jour régulièrement ? Quel pourcentage possède des extensions mises à jour régulièrement ? Quel pourcentage installe des plugins sans faire attention ? Combien de plugins ont des backdoors ? Combien de comptes "test" sont laissés à l'abandon ? La surface d'attaque est immense, et là, on ne parle que de Wordpress ».

Comment ont-ils réussi leur intrusion ?

Une fois toutes les altérations du site Web identifiées, il convient de procéder au nettoyage, mais aussi d’améliorer la posture de sécurité du site. Et pour cela, il faut comprendre comment les attaquants ont procédé.

Las, selon Thomas Chopitea, « pour la grande majorité des "propriétaires" de ces sites, cette demande de nettoyage et investigation est illusoire. Tous les jours, les gens mettent en ligne des blogs sur des hébergements gratuits pour les laisser à l'abandon après... »

Dans le cas présent, compte tenu du nombre de tentatives d’authentification observées, le plus probable est l’attaque en force brute, sur la base d’un dictionnaire. Il est possible que celui-ci ait été enrichi de mots de passe ayant échoué dans la nature à l’occasion de brèches antérieures. La réutilisation reste hélas une réalité.

Alors bien sûr, toutes les mises à jour disponibles ont été appliquées, y compris pour le socle sur lequel s’appuie Wordpress. L’éventail de plug-ins utilisés a été réduit au strict minimum afin de limiter la surface d’attaque.  Surtout, les mots de passe des comptes utilisateurs sensibles ont été modifiés.

Une extension a été ajoutée au passage pour forcer le recours à l’authentification à double facteur, en s’appuyant sur le service Authenticator de Google. Mais ces précautions n’épargneront pas l’administrateur du site Web concerné une surveillance régulière et vigilante.

De fait, Vincent Nguyen souligne que « réduire la surface d’attaque est une chose, mais on ne peut que la réduire – pas la supprimer ; de fait il est nécessaire de maintenir la chaîne applicative en condition de sécurité et de surveiller ces conditions de sécurité ». Ce qui passe par une gestion rigoureuse des correctifs et un monitoring au moins régulier, notamment alors « l’utilisation de plugins spécifiques pour produire des alertes en temps réel en cas d’attaque » ou encore la « mise en place d’un outil d’analyse des logs, Apache à minima ».

Pour approfondir sur Gestion de la sécurité (SIEM, SOAR, SOC)