Exploiter un PHP avec un téléchargement de fichier .jpg
Je voudrais poser une question concernant le téléchargement classique d'une image et l'exécution d'un exploit de code php sur un site Web.
J'ai donc essayé d'exploiter un site Web que je suis censé pirater (il est configuré pour que nous essayions de le pirater)
La page Web nous permet de télécharger une image, et tout en changeant le type MIME à l'aide de TamperData est facile, la page Web vérifie apparemment si les derniers caractères du fichier sont '.jpg' ou '.jpeg' avant de laisser passer l'image.
Quel que soit l'emplacement du code PHP (j'ai juste essayé du code php, du code php collé à la fin du fichier image, du code php dans les en-têtes EXIF, etc.), le site Web montre simplement le fichier image lorsque je l'ouvre après le téléchargement (ou une erreur dans le cas d'un code php ordinaire enregistré au format .jpg), car l'extension est toujours jpg.
Donc, dans un tel cas, que faire pour exécuter le fichier en .php? (l'empoisonnement par morsure nulle ne fonctionne pas, pas plus que le téléchargement du code en tant que vuln.php.jpg ou vuln.php; .jpg. Les deux ne montrent que l'image)
Quel que soit l'emplacement du code PHP code [...], le site Web affiche simplement le fichier image lorsque je l'ouvre après le téléchargement
Oui, c'est comme ça que ça devrait être. Le serveur serait sérieusement vulnérable s'il interprétait les fichiers .jpg comme des fichiers .php en fonction du contenu au lieu de l'extension.
Donc, dans un tel cas, que faire pour exécuter le fichier en .php?
Sans une sorte de vulnérabilité dans le code lui-même, vous ne pouvez pas exécuter les fichiers image en tant que fichiers PHP, car tout serveur décent ne le permettrait pas.
Sans en savoir plus sur le code, nous ne pouvons pas faire plus que de deviner. S'il est censé être vulnérable à dessein, je suppose que le contrôle d'extension est probablement cassé.
Vous pourriez essayer:
.htaccess: la vérification d'extension peut interpréter ceci comme aucune extension, et cela peut convenir. Si le serveur analyse le fichier .htaccess, vous pouvez alors obtenir l'exécution de code avec des fichiers image viaAddType application/x-httpd-php .jpg.vuln.jpg.php: le chèque peut vérifier la première, pas la dernière extension.vuln.php5,vuln.php4,vuln.phtml, etc.: la vérification peut être une vérification de liste noire, pas une vérification de liste blanche, qui peut manquer certaines extensions qui peuvent être interprétées par le serveur comme des fichiers PHP. Vous pouvez facilement le tester avec un extension madeup commefoobar, si elle passe, c'est un filtre de liste noire.- LFI: Vous pouvez avoir un répertoire tel que
miscavec des sous-répertoiresuploadsetconfigs, où configs contient PHP et uploads contient le vous pouvez alors avoir du code tel queinclude "misc/" . $filename. Disons qu'il y a une vérification de la traversée du répertoire, donc cela devrait être du mauvais code, mais généralement toujours quelque peu sécurisé, non? Eh bien, les fichiers .jpg inclus sont analysés et exécutés comme n'importe quel autre fichier, et donc PHP à l'intérieur sera exécuté. Cet exemple est un peu exagéré, mais ce n'est pas complètement inconcevable que quelque chose comme ça peut exister.
tl; dr: Vous pouvez exécuter des fichiers jpg en tant que PHP via .htaccess ou via include. En outre, vous pouvez contourner la vérification de l'extension de fichier si elle n'est pas sécurisée.
Lorsque vous utilisez TamperData, certains serveurs ne fonctionnent pas. Mais utiliser exif editor fonctionnera bien.
.jpg sera remplacé par .php dans les en-têtes http ou la suite burp
Juste une pensée - tout en ne piratant pas vraiment le serveur, être en mesure de télécharger un fichier jpg avec des js auto-exécutables intégrés à partir de l'exif, ce qui peut alors causer un chaos sur la machine client, serait certainement un problème de sécurité du point de vue de l'utilisateur. voir: http://blog.trendmicro.com/trendlabs-security-intelligence/jpeg-files-used-for-targeted-attack-malware/