Un de mes sites a été la victime d’une puissante cyberattaque en provenance de Russie, heureusement sans conséquence.

Un site PHP entièrement fait maison

Ce site est la cible régulière de nombreuses attaques, et j’ai pris la mauvaise habitude de ne même plus y faire attention, en toute honnêteté. Néanmoins, comme certaines précautions ont été prises par le passé, je suis assez confiant dans les contre-mesures que j’ai mises en place, ce qui explique mon apparent laxisme à ce sujet. L’échec de cette attaque prouve d’ailleurs que je n’ai pas trop de raison de m’inquiéter. Cependant, au vue de la virulence de l’attaque, j’ai cru bon de devoir un peu la documenter, histoire d’analyser les techniques employées par ces goujats et puis aussi voir comment je peux encore améliorer mes défenses.

Ce site est un pur développement PHP de ma part, avec quelques bouts de Java essentiellement pour l’aspect cosmétique. Toutes les URL sont gérées par une fonction qui vérifie leur intégrité et me permet de détecter les éventuelles attaques ; cette fonction agit un peu à la manière d’un reverse-proxy. Pour ce faire, j’utilise la même technique utilisée par WordPress, à savoir un htaccess avec les directives suivantes :

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^(.*\.(zip|exe|rar|gz|tgz|bak|war|backup|dat))$ http://tartopom.com/ [L]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule> 

Vous noterez que j’expédie déjà au diable les casse-pieds qui essayent de télécharger des archives et autres joyeusetés que l’on a l’habitude de rencontrer lors de tentatives d’intrusion.

Après, une succession de strcmp() me permet d’orienter le site vers le bon traitement :

if(!strcmp($mi,"f1.php")) f1();
if(!strcmp($mi,"f2.php")) f2();
…

Finalement, je termine par un catchall qui m’indique souvent que l’on est en présence d’un vilain dont il faut parfois bannir l’IP. Typiquement, 5 URL bizarroïdes à la suite est un signe qui ne trompe que très rarement et qui trahit un début d’attaque.

Une cyberattaque avec Metasploit

L’attaque a duré une dizaine d’heures, avec des pauses de plusieurs minutes entre les différentes tentatives. Ce qui me laisse penser que je n’ai pas eu affaire à un script qui se déroule, mais bien à un hacker qui s’essaye à plusieurs méthodes. Cette personne a vraisemblablement utilisé le sinistre Metasploit. Je l’ai rapidement déduit, en m’apercevant que les types d’attaques me ramenaient souvent à plusieurs modules de ce tristement célèbre programme. Je pense aussi qu’il a utilisé quelques scripts tiers, n’ayant pas trouvé d’équivalence sous Metasploit. Le bon côté de la chose est qu’il m’a donné quelques pistes de réflexion pour améliorer encore plus la sécurité du site. Je sais que je peux désormais compter sur l’utilisation de plusieurs modules Metasploit pour un hardening encore plus fin.

Les méthodes de requêtes étaient composées principalement de GET et de POST pour lancer quelques scénarios. A noter aussi la présence de OPTIONS qui demande des informations sur les options de communication et aussi de PUT qui est un dérivé de POST. D’après mes logs, la méthode PUT est très rarement utilisée en temps normal.

Au total, j’ai décortiqué 140 attaques que j’ai mis dans un fichier Excel. Puis j’ai cherché un par un le détail de l’attaque. La plupart était grave avec des tentatives de RCE, de fuite de données et aussi d’élévation de privilèges.

J’ai été agréablement surpris de trouver dans la majorité des cas une CVE documentant la faille ; preuve quand même que la communauté Infosec fait toujours un travail aussi remarquable. Et même lorsqu’il n’existait pas de CVE, j’ai généralement pu trouver une documentation expliquant le problème. Ce cas s’est surtout présenté sur des programmes peu connus et parfois des modules WordPress. On peut aussi imaginer que l’URL utilisée lors de l’attaque était personnalisée, voir même codée, m’empêchant ainsi de trouver la documentation idoine.

Description des cyberattaques

Une bonne partie des attaques consistait à tenter d’accéder à une URL défendue et susceptible de présenter une faille en fonction du type de logiciel possiblement présent sur le serveur. On y trouve bon nombre de programmes de e-commerce comme Woocomerce, bien entendu des attaques à base d’injection SQL et sur d’autres bases de données telles que Mongo et même Oracle, des XSS sur des CMS comme Drupal et comme à l’accoutumée le célèbre WordPress. Pour ce dernier, ce n’est pas l’habituel brut force sur le wp-login.php qui a été utilisé et que j’observe par centaine tous les jours sur le présent blog ainsi que sur mon site professionnel, mais plutôt des attaques ciblant des modules spécifiques, tels que quiz-master, simple-file-list ou ait-csv.

J’ai pu également constaté un nombre important de tentatives à base de Java, de modules Apache et de PHP. C’est sur cette partie que j’ai particulièrement inspectée ce qui a été tenté. Le hacker a essayé de créer des sessions et envoyé aussi un certain nombre d’instructions en PHP. Exemple :

/index.php?a=fetch&content=%3C%3Fphp+file_put_contents%28%22monsite.php%22%2C%22%3C%3Fphp+echo+phpinfo%28%29%3B%22%29%3B

Il a également fait plusieurs POST sur des fichiers stratégiques tels que index.php, login.php, admin.php, etc. Heureusement tout ceci sans gravité. Cela m’a donné l’idée qu’il faudrait que je stocke également ces données dans mes logs afin d’étudier plus finement ce qu’il tente de faire.

J’ai aussi constaté un nombre important d’attaques REST sur d’éventuelles API présentes. Au vue du nombre toujours plus croissant de ce type d’application, il faut vraiment être très vigilant lorsque l’on propose ce type de port ; il s’agit d’une véritable porte d’entrée sur tout un système.

Des attaques sur des logiciels très connus m’ont fait froid dans le dos, surtout que certains sont justement des logiciels de sécurité ou des portails pour firewall ! Quelques exemples : Citrix, Oracle’s eBusiness, F5, Cisco Asa, SAP, Exchange, Trend Micro et le pompon : FortiOS et son VPN SSL !

J’ai aussi observé un nombre de tentatives sur de l’IOT et pas mal de caméras et de routeurs domestiques ; un peu trop à mon avis, et en plus l’une d’entre elle n’était pas très loin du routeur Wifi que j’utilise à la maison. Mais je pense plus à un hasard. Cette partie me convainc toujours plus qu’il y a un véritable problème de sécurité avec l’IOT et l’embarqué. Si le cœur de métier de ceux qui fabriquent les logiciels est justement le logiciel et donc ont tout intérêt à s’assurer de sa sécurité, dans l’IOT, le cœur de métier est beaucoup plus le matériel au détriment du logiciel qui l’habille. Sur ce type d’environnement, je vois trop souvent des GUI mal foutues, codées à la va vite, et bourrés de bugs. D’ailleurs, un client m’a même déjà sollicité pour une mission portant sur la sécurisation de tout son IOT. Révélateur, n’est-il pas ?

Autre exemple d’attaque que j’ai pu observer : les scénarios en plusieurs passes, généralement à base de POST mais pas seulement. L’attaque suivante à base de Radius copie le fichier des mots de passe (/etc/passwd) dans le fichier monsite.txt

 /manager/radius/server_ping.php?ip=127.0.0.1|cat%20/etc/passwd>../../monsite.txt&id=1

Puis il tente de le récupérer au moyen d’un simple GET :

 /monsite.txt

J’ai mis monsite.txt, mais en réalité, le nom est une pseudo signature MD5 qui identifie mon site de manière unique. En gros, c’est un paramètre, et je l’ai trouvé plusieurs fois dans mes logs sur des attaques similaires à base de scénario, notamment sur du WordPress comme cet autre exemple qui tente de charger via un POST un fichier signature appelé 1afreRe.php:

 /wp-content/plugins/ait-csv-import-export/admin/upload-handler.php

Qu’il tente ensuite de de récupérer :

/wp-content/uploads/1afreRe.php 

Cela peut complexifier un peu la détection, et les contre-mesures.

Russie et cyberattaques hors-bande

J’ai observé que plusieurs URL aboutissaient systématiquement à ce site Russe.

Il s’agit d’un site gouvernemental pour la protection civile, les situations d’urgence et l’élimination des conséquences des catastrophes naturelles. Après plusieurs recherches, je n’ai rien trouvé de probant sur ce site, qui est tout à fait légitime et ne présente aucun problème particulier (Hacking, blacklist, etc.) Ma conclusion est que l’un des formulaires de ce site a été également la victime d’une attaque similaire à celle que j’ai subie.

En ce qui concerne l’attaquant en lui même, il est clairement identifié grâce à son adresse IP. Il est originaire de Moscou, présent dans la plupart des listes noires qui recensent les activités dites « malignes » et lance de régulières attaques un peu partout dans le monde. D’ailleurs, en ce moment même il s’est de nouveau attaqué à mon site.

Pour terminer sur les attaques, le hacker a utilisé une méthode hors bande pour tester d’éventuelles vulnérabilités sur mon serveur. Les vulnérabilités hors bande, qui sont également appelées OOB pour Out-Of-Band, sont une série de moyens alternatifs qu’un attaquant utilise pour exploiter une vulnérabilité qui ne peut pas être détectée par une interaction HTTP traditionnelle. Pour ce faire, il a utilisé le programme Interactsh. Cette méthode est assez innovante, mais encore assez mal documentée, de ce que j’ai pu trouver.

Dans mon cas, il a essayé de lancer des wget directement sur ma machine et observé les résultats sur une machine distante.

En conclusion

En définitive, ce genre d’attaque sophistique est un excellent stress-test pour évaluer la robustesse d’un site web. Il vous oblige à vous mettre à jour sur certains petits problèmes qui vous auraient échappé, et en plus vous force à faire de la veille technologique sur de nouvelles méthodes d’intrusion.