Piratage compte FTP

Bonsoir à tous,

Je m'excuse par avance, parce que je ne suis peut être pas dans la bonne rubrique, mais je n'ai pas trouvé où poser ma question, et comme la description contient le mot sécurité...

J'ai un problème avec un hébergement qui a subit deux intrusions en quelques jours et j'aurais besoin d'aide pour comprendre où se trouvent les failles et comment les corriger. Concrètement un pirate à déposé des dossiers et des fichiers destinés à du phishing. La première fois, c'était Paypal, et la seconde un paiement par visa.

Il s'agit d'un hébergement chez 1&1 sur un serveur privé. Le site est développé en PHP et connecté à une base MySQL. Il s'agit d'une boutique en ligne toute simple que j'ai entièrement développée qui contient notamment un formulaire d'upload pour des photos. Je le précise, parce que je me demande si le point d'accès ne se trouve pas ici.

La première fois, j'ai pu récupérer les fichiers (avec notamment un fichier PHP crypté et un fichier a.php.gif qui sont bien reconnus par Avast comme étant dangereux), mais j'ai eu du mal à les supprimer avec FileZilla (j'ai du me servir d'une fonction PHP avec unlink).

La seconde fois (c'est à dire il y a 20 minutes), je n'ai pas pu récupérer les fichiers, mais je les ai effacé de la même façon.

Je n'arrive pas à comprendre comment il a fait pour créer les dossiers et déposer les fichiers.

Le formulaire d'upload est disponible uniquement par l'administrateur du site, derrière une protection par session (Nom d'utilisateur / Mot de passe). Sur le FTP, j'ai un seul et unique répertoire dans lequel je place des images auquel j'ai donné les droits chmod 777. Lors de l'upload, je test les extensions de fichiers et je n'accepte que JPG, JPEG, PNG et GIF.

La première fois, le dossier et les fichiers était dans ce répertoire d'images.
La seconde fois, le pirate à modifier les droits d'un autre répertoire (au même niveau que le dossier images) et a copier un répertoire dedans.

La question c'est : comment fait il et surtout, comment me protéger pour éviter que ça se reproduise. Sachant que je suis responsable de ce qui se trouve sur le serveur, c'est moi qui trinque s'il y a fraude et plainte...

Heureusement, 1&1 m'envoie une alerte très rapidement après avoir détecté le problème...

Dans l'espoir que vous pourrez m'expliquer, je vous remercie par avance.
Je sais qu'on ne peut pas totalement se protéger des pirates, mais au moins si je peux corriger les failles.

Ton systeme d'authentification n'est visiblement pas efficace.
Si tu valide l'utilisateur dans une base de donnée, as-tu bien oeuvré contre les injections SQL ?

Ca fait des heures que je cherche.
J'ai analysé les logs et apparemment le pirate utilise un logiciel qui teste des nombreuses url pour trouver le formulaire d'identification de l'admin (on voit pleins d'url différentes testées à la même seconde).

Ensuite il a fait plein de tests avec des url en passant des paramètres afin d'afficher des infos dans les pages, je ne savais même pas que c'était possible. Il a réussit à trouver le nom des champs de mes tables en provoquant des erreurs (les requêtes en cause s'affichent à l'écran et je me rend compte que c'est une très mauvaise idée.)

Avec la requête ci-dessous par exemple, il a pu afficher les adresses e-mail de tous les utilisateurs, dans la page qui affiche normalement les produits (et qui n'est pas faite du tout pour afficher les adresses e-mail.

Code:

---

1 2	boutique.php?page=2&cat_id=-2+union+select+1,2,3,4,5,user_email,7,8,9+from+users--

---

Il a fait de même avec les mots de passe et il a ensuite pu accéder a l'interface d'admin. En fait apparemment, il peut afficher n'importe quelle info dans n'importe quelle page et je ne sais pas du tout comment me protéger de ça... c'est surement ce que tu appelle des injections SQL.

Ensuite, il doit aussi y avoir des failles dans le formulaire d'upload, parce qu'il a pu balancer des fichiers qui sont normalement interdits. Pour l'instant, je n'ai pas encore terminé d'analyser les logs, je n'en sais donc pas plus...

Mais c'est dingue ! Comment il fait pour afficher l'adresse e-mail dans la page des produits ? A la limite, envoyer des paramètres d'une façon bien précise pour modifier les requêtes, je peux comprendre, mais comment fait il pour afficher des données que je n'ai pas prévu d'afficher dans les pages ?

De la lecture :
http://php.developpez.com/faq/?page=mysql#mysql-escape

Je te remercie pour cette info.
J'utilise déjà la fonction mysql_real_escape_string() dans ma procédure de login.
Le problème ne semble pas venir de là. En fait le pirate possède les identifiants car il les a trouvé via la page produits grâce à la requête ci-dessous.

Code:

---

boutique.php?page=2&cat_id=-2+union+select+1,2,3,4,5,user_email,7,8,9+from+users--

---

Ce que je ne comprend pas, c'est comment on peut afficher l'adresse email et le mot de passe des utilisateurs dans une page qui est destinée à afficher des produits.

si ta requête est sujette aux injections, il est possible de lui faire retourner un champ à la place d'un autre.

Tiens, je n'avais jamais vu d'injection SQL à l'œuvre. Voilà donc le réel danger.

En première mesure, je te conseillerais de changer les droits d'accès du dossier, afin qu'il ne puisse plus y uploader de fichiers.

Dans ton script, tu as surement quelque part une ligne qui ressemble à ceci :

Code:

---

mysql_query("SELECT * FROM articles WHERE category = $_GET[cat_id]");

---

C'est là que le souci se trouve. Tu dois t'assurer que $_GET['cat_id'] soit sanitisé. Tu peux par exemple utiliser intval.

Code:

---

mysql_query('SELECT * FROM articles WHERE category = ' . intval($_GET[cat_id]));

---

Ça devrait résoudre le souci.

Aussi, désactive d'urgence l'affichage des erreurs :

Code:

---

error_reporting(0);

---

Et bien entendu, il faudra changer les identifiants et mots de passe. (sont-ils stockés en clair dans ta base de données ?)

Bonne chance dans ta lutte.

Merci Antoine par ta réponse détaillée.

C'est exactement ce que j'ai fait hier matin et depuis je n'ai pas eu d'autre problème. En vérifiant le type du paramètre cat_id, le type ne peux plus lancer sa requête pour afficher les infos. Il devrait donc être incapable de retrouver les nouveaux mots de passe (qui sont effectivement stockés en clair dans la bd. Dorénavant, j'adopterai peut être le sha256).

Cela dit, il faut aussi que j'arrive à trouver un jour la faille de mon formulaire d'upload. Je le redévelopperai peut être complètement, mais pour le moment, ce qui compte, que c'est que le pirate ne puisse plus y accéder.

Je vais attendre un peu avant de crier victoire, mais pour le moment tout se passe bien et je vous remercie de votre aide.