forked from quentin/quentin.dufour.io
Fix some typos
This commit is contained in:
parent
3bd504bed4
commit
22591b413c
1 changed files with 13 additions and 12 deletions
|
@ -2,8 +2,8 @@
|
|||
layout: post
|
||||
slug: h5ai_cve
|
||||
status: published
|
||||
title: Faille de sécurité dans h5ai
|
||||
description: Postmortem de l'attaque de mon serveur
|
||||
title: Postmortem : faille de sécurité dans h5ai
|
||||
description: Après l'attaque à la nigérienne, l'attaque à l'indonésienne.
|
||||
categories:
|
||||
- sys
|
||||
tags:
|
||||
|
@ -41,7 +41,7 @@ Par la même occasion on en apprend plus sur la faille de sécurité :
|
|||
|
||||
> Unrestricted file upload vulnerability in h5ai before 0.25.0 allows remote attackers to execute arbitrary code by uploading a file with an executable extension, then accessing it via a direct request to the file in the directory specified by the href parameter.
|
||||
|
||||
TL;DR : Sur certaines versions de h5ai il est possible d'envoyer des fichiers sur le serveur sans restriction qui seront ensuite interprété comme PHP.
|
||||
TL;DR : Sur certaines versions de h5ai il est possible d'envoyer des fichiers sur le serveur sans restriction. Fichiers qui seront ensuite interprétés par PHP.
|
||||
|
||||
Une faille basique, complètement bête. A aucun moment la fonction d'envoie est mentionnée sur h5ai.
|
||||
|
||||
|
@ -55,11 +55,11 @@ Pour ceux qui seraient intéressé par l'exploit, vous pouvez en trouver un sur
|
|||
|
||||
Le fichier we.php contient une interface, permettant de prendre le contrôle du serveur, et de nombreux outils. On citera, entre autres, la possibilité de naviguer dans les fichiers du serveur, d'executer des commandes, d'automatiser l'ajout d'un compte dans un Wordpress ou un Joomla, etc.
|
||||
|
||||
On notera que le code n'est pas directement en clair dans le fichier, il est compressé en gzip puis converti en base 64. L'ensemble est ensuite décodé puis passé dans un eval qui va interprété le code.
|
||||
On notera que le code n'est pas directement en clair dans le fichier, il est compressé en gzip puis converti en base 64. L'ensemble est ensuite décodé puis passé dans un eval qui va interpréter le code.
|
||||
|
||||
![Capture d'écran](/assets/images/posts/h5ai-we.png)
|
||||
|
||||
On remarquera que la "team" qui a réalisé ce logiciel est indonésienne est se nomme "D'MASTERPIECE".
|
||||
On remarquera que la "team" qui a réalisé ce logiciel est indonésienne et se nomme "D'MASTERPIECE".
|
||||
|
||||
## Le fichier pro_mailer.php
|
||||
|
||||
|
@ -69,7 +69,7 @@ Le fichier pro_mailer.php quant à lui n'est pas obfusqué. Il est d'ailleurs é
|
|||
|
||||
Son seul objectif est d'utiliser le serveur email de la cible pour envoyer des emails.
|
||||
|
||||
## Retour sur les étapes de l'attaque
|
||||
## Retour sur l'attaque
|
||||
|
||||
Afin d'accéder au serveur, nos pirates revendiquant le nom de "Dragon Net" ont exploité la faille de sécurité dans h5ai pour envoyé trois fichiers : index.html (leur revendication), we.php et pro_mailer.php.
|
||||
|
||||
|
@ -77,26 +77,27 @@ Ils ont ensuite utilisé we.php pour fouiller dans les fichiers du site et uploa
|
|||
|
||||
Ils se targuent de se contenter de publier leurs revendications. Et en effet, ils semblent n'avoir rien fait d'autre. Cependant, on peut supposer que leur intentions ne sont pas aussi louables qu'ils le prétendent : pourquoi ne pas avoir directement envoyé leur fichier index.html ? we.php et pro_mailer.php sont inutiles dans notre cas...
|
||||
|
||||
On notera d'ailleurs que la team ayant réalisé l'attaque n'est pas la même que celle qui a créé le fichier we.php ou encore pro_mailer.php. Il y a un marché pour tout...
|
||||
|
||||
Faute d'information supplémentaire je suppose qu'ils ont prévu ces fichiers "au cas où" ils aient besoin d'un serveur.
|
||||
|
||||
## Exploitation et possibilités
|
||||
|
||||
La faille de h5ai, par chance, n'a été exploitée que pour des revendications politiques/religieuses. Mais on peut imaginer bien pire...
|
||||
|
||||
Tout d'abord, actuellement tous mes sites web en PHP sur cette machine utilisent le même utilisateur PHP. On peut donc supposer qu'il aurait pu défacer ces sites webs, et la base de données qui va avec. Il était aussi possible de lancer des attaques DDoS.
|
||||
Tout d'abord, actuellement tous mes sites web en PHP sur cette machine utilisent le même utilisateur. On peut donc supposer qu'il aurait pu défacer ces sites webs, et la base de données qui va avec. Il était aussi possible de lancer des attaques DDoS depuis la machine, executer des programmes, etc.
|
||||
|
||||
Cependant, notre pirate n'avait pas d'accès root, il n'avait donc pas accès au reste du système... heureusement !
|
||||
|
||||
## Les mesures de sécurité
|
||||
|
||||
Cet épisode amène à des réflexions. Tout d'abord sur le choix de h5ai : comment une telle faille est arrivée dans ce logiciel. Son objectif n'a jamais été l'envoi de données !
|
||||
Cet épisode amène à des réflexions. Tout d'abord sur le choix de h5ai : comment une telle faille est arrivée dans ce logiciel. Son objectif n'a jamais été l'envoi de données ! Peut-on encore lui faire confiance ? Peu d'annonce à ce sujet, une description laconique sur le site officiel, pas grand chose sur git...
|
||||
|
||||
Deuxièmement, je me suis intéressé aux mises à jours des différents applications web de ma machine. Quelles sont les applications installées ? Sont-elles à jour ?
|
||||
|
||||
Enfin, le problème de PHP se pose : comment compartimenter les sites en plusieurs utilisateurs distincts ? Comment prévenir l'execution de scripts PHP ?
|
||||
Enfin, le problème de PHP se pose : comment compartimenter les sites en plusieurs utilisateurs distincts afin qu'un site compromis ne puisse pas atteindre les autres ? Comment prévenir l'execution de scripts PHP indésirable ?
|
||||
SELinux n'aurait pas forcément été d'une grande aide dans mon cas, même s'il peut être un rempart de plus, pour détecter ce genre d'actions frauduleuses.
|
||||
|
||||
SELinux n'aurait pas forcément été d'une grande aide dans mon cas, même s'il peut être un rempart de plus.
|
||||
|
||||
Aujourd'hui les containers sont à la mode (LXC, Docker, ...). L'utilisation de ces derniers pourraient être un gage de sécurité supplémentaire. En effet, le pirate resterait coincé dans le conteneur. De plus ces derniers sont censés être plus simple à mettre à jour.
|
||||
Aujourd'hui les containers sont à la mode (LXC, Docker, ...). L'utilisation de ces derniers pourraient être un gage de sécurité supplémentaire. En effet, le pirate resterait coincé dans le conteneur. De plus ces derniers sont censés être plus simple à mettre à jour. Mais leur sécurité n'est pas encore parfaite.
|
||||
|
||||
En tout cas, en terme de sécurité, il ne faut pas se reposer sur un rempart, car une faille de sécurité peut facilement le casser, mais sur plusieurs (container, utilisateurs distincts, SELinux et mises à jour fréquentes).
|
||||
|
|
Loading…
Reference in a new issue