[Upload] Execution d'un .png en tant que .php

Bonjour à tous,

Il m'arrive très rarement de poster, et encore moins pour de l'aide, mais là j'ai sincèrement besoin des lumières de quelqu'un d'autre.

En effet, j'administre un site de développement de jeux vidéos (http://www.gamemaker.fr/) et dû à une faille dans le CMS (CuteNews) que j'utilise (je suis en train d'en changer et de faire mon propre CMS) un hacker a pu installer un script php sur mon serveur, or je ne comprends pas où est la faille, et je ne peux donc pas la corriger.
Je suis sur un hébergement mutualisé proposé par Infomaniak.

En effet ce dernier a mis un code php dans un .png et a réussi à l'uploader au travers du système d'upload d'image. Ensuite, sûrement à partir de ce png, il a recréé ce fichier dans un autre dossier du serveur, où il l'a utilisé pour récupérer des données de ma bdd (c'est une bdd en flat file, c'est archaïque est un peu nul, mais ce système date de 2003, les utilisateurs sont stockés dans un .php avec un die au départ et on récupère les utilisateurs et leurs pass en lisant le fichier avec fopen & fread).

Le plus étrange est que le fichier qu'il a créé, sûrement depuis le .png, appartenait à l'utilisateur httpd (qui est donc Apache si je ne me trompe pas), alors qu'il est sensé appartenir à mon compte, car c'est ce qui arrive lorsqu'une page php que j'ai uploadé crée un fichier.

Ce fichier était une page php qui contenait des programmes en perl et qui servait à supprimer, ajouter etc. des fichiers, exécuter du php, voir le contenu des .php et plus encore.

Ma question, est donc, est il possible qu'il ait exécuté un .png comme étant un script php et surtout comment il l'a fait.

A savoir le fichier se nommait: cool.png.
J'ai lu que sur certain hebergements mutualisés, dont l'offre proposée par ovh, les fichiers du type: page.php.png étaient interprétés par du php, j'ai fait les tests sur mon serveur et ça n'est pas le cas.

Je voulais donc savoir si exécuter un .png par un interpreteur php était possible autrement, sinon c'est que la faille ne se trouve pas au niveau du système d'upload des images.

En vous remerciant par avance et en espérant avoir posté dans la bonne section.

Bonjour,

Il s'agit d'une défaillance du module d'upload: il se contente de filtrer les extensions et n'effectue aucune vérification du type de fichier.

Bonsoir,

En fait je suis parvenu à trouver la faille, le système d'upload ne fait déjà pas de vérification, mais ce qui m'interessait de savoir c'était comme il était parvenu à exécuter la page php depuis Cutenews, j'ai cherché dans le script d'affichage, et en voici la raison:

Dans cutenews à la base, le code n'est pas du tout protégé il prend le $_GET["template"] sans se soucier d'échapper d'éventuels caractères. Et cela ressemble à cela:

Code:

---

1 2 3

if(file_exists("$cutepath/data/${template}.tpl")){ require_once("$cutepath/data/${template}.tpl"); } else{ die("Error!<br>the template does not exists, note that templates are case sensetive and you must write the name exactly as it is"); }

---

On peut donc aisément appeller la page en question en faisant finir le code avec le caractère ascii 0:
cutenews/show_news.php?template=./upimages/imageavecduphp.png%00
(C'est une des failles que le hacker a utilisé)

Pour le corrigé, je n'ai pas trouvé de fonction du genre de mysql_real_escape_string, je n'ai fais qu'un remplacage minime:

Code:

---

1 2 3

$template = str_replace(chr(0), '', $template); if(file_exists("$cutepath/data/$template.tpl")){ require_once("$cutepath/data/$template.tpl"); } else{ die("Error!<br>the template does not exists, note that templates are case sensetive and you must write the name exactly as it is"); }

---

Je pense qu'une expression régulière serait plus logique et plus sûre, mais au moment où j'avais trouvé la solution je devais partir. Je corrige ça. ;)

Merci en tous cas pour l'info pour le système d'upload.