Hack par upload fichier

Bonjour,
j'ai eu la mauvaise surprise de découvrir dans plusieurs répertoires de sites hébergés sur mon serveur que des fichiers y avait été insérés et des répertoires créé.

J'ai identifié et effacé les fichiers gun*.php qui contiennent des lignes de code destinés à hacker le serveur.

Néanmoins, il semble qu'il y en ai d'autres sous d'autres noms.

Dans ce cas comment puis-je faire pour identifier l'ensemble des fichiers appartenant à un utilisateur spécifique, www-data, car normalement l'ensemble des fichiers ont pour utilisateur le propriétaire du site. Or ces fichiers ont comme utulisateur www-data (apache)

J'ai effectué des tests avec chrootkit, et rkhunter et rien departiculier à signaler.

Pour info mon serveur et protéger par iptable et j'ai plusieurs logiciels de securite comme fail2ban, rkhunter...

Les sites qui ont été touché ont ete bati sur plusieurs framework (joomla, prestashop, interne) et il semble que ça soit la meme personne à l'origine (car fichier gun)donc je pense que ça peut venir d'une faille apache ou du serveur?

Je viens de faire une mise à jour d'apache, j'ai maintenant la version 2.2.9.

Mon serveur:
- Debian Lenny
- Virtualmin
- Apache 2.2.9

Merci d'avance pour votre aide et conseil afin d'éviter que ça se propage et identifier les sources du probleme.

Je reviens vers mon précédent message car il n'est peut etre pas assez clair.

En fait, je souhaiterai savoir comment est il possible d'uploader des fichiers sachant, que je n'ai aucun formulaire d'upload.

Comment ensuite est il possible en analysant les logs voir quels fichiers ont ete uploadé, en effet j'ai pas mal de fichiers log qui sont d'ailleurs trés gros, et je n'ai pas trouvé le fichier log qui me permet de détecter ces upload

Enfin pour effacer les fichiers uploaded, comment puis-je faire une recherche par proprietaires et si possible par date.

Si vous avez d'autres conseils, notamment comment se protéger contre ce genre d'attaques, je vous serez reconnaissant. J'ai découvert le script Crawlprotect, connaissez-vous ce script est il efficace?

Merci d'avance

Citation:

---

Envoyé par thibaut06

Je reviens vers mon précédent message car il n'est peut etre pas assez clair.

En fait, je souhaiterai savoir comment est il possible d'uploader des fichiers sachant, que je n'ai aucun formulaire d'upload.

Comment ensuite est il possible en analysant les logs voir quels fichiers ont ete uploadé, en effet j'ai pas mal de fichiers log qui sont d'ailleurs trés gros, et je n'ai pas trouvé le fichier log qui me permet de détecter ces upload

Enfin pour effacer les fichiers uploaded, comment puis-je faire une recherche par proprietaires et si possible par date.

Si vous avez d'autres conseils, notamment comment se protéger contre ce genre d'attaques, je vous serez reconnaissant. J'ai découvert le script Crawlprotect, connaissez-vous ce script est il efficace?

Merci d'avance

---

un hacker peut uploader des fichiers sur votre machine si les permissions des dossiers sont mal gérées et si une commande telle que "wget" est accessible par le compte sous lequel tourne le serveur Web.

En clair, il n'upload pas des fichiers, il provoque l'exécution de code shell via des pages, par exemple en PHP, qui ne parsent pas correctement leurs arguments, code shell qui lui va downloader les codes malicieux…

tu devrais aussi passer un nessus afin d'identifier les failles, les risques et surtout les correctifs à appliquer.

Ca devrai t'aider. (tiger également est un bon complément) pour identifier les failles

ensuite il y a une méthode pour limiter les risques qui est de faire comme ça :

Citation:

---

create a mount point:
mkdir /tmp/ramdisk0
# create a filesystem:
mke2fs /dev/ram0
# mount the ramdisk:
mount /dev/ram0 /tmp/ramdisk0


Example of how to use a RamDisk for a webserver.
Okay, here is an example of how to use 3 ramdisks for a webserver. Let us say you are 99% confident that your default installation of Apache for RedHat 6.0 won't use more than 9 megs for its cgi-scripts, html, and icons. Here is how to install one.
First, issue this command to move the real copy of the document root directory of your webserver to a different place. Also, make the directories to mount the ramdisks .
mv /home/httpd/ /home/httpd_real
mkdir /home/httpd
mkdir /home/httpd/cgi-bin
mkdir /home/httpd/html
mkdir /home/httpd/icons

Then, add these commands to the start procedure in your /etc/rc.d/init.d/httpd.init (or where ever the httpd gets started on your system):

### Make the ramdisk partitions
/sbin/mkfs -t ext2 /dev/ram0
/sbin/mkfs -t ext2 /dev/ram1
/sbin/mkfs -t ext2 /dev/ram2

### Mount the ramdisks to their appropriate places

mount /dev/ram0 /home/httpd/cgi-bin
mount /dev/ram1 /home/httpd/icons
mount /dev/ram2 /home/httpd/html

### Copying real directory to ramdisks (the
### data on the ramdisks is lost after a reboot)
tar -C /home/httpd_real -c . | tar -C /home/httpd -x

### After this you can start the web-server.


Comments

---

bien sur des taches cron rafraichissent de temps à autre pour forcer le ram disque à recharger le site réel dans le ramdisk, afin d'éliminer ce qui a pu être intégré de force. ce qui l'élimine à coup sur (comme ton cas)

mais cette protection n'empêche en rien de se proteger et en particulier si tu as une SGBD de te proteger contre les injections SQL diverses. et te tenir ta sécurité à jour !

si le site est trop grand pour la taille standard d'un ramdisk tu peux bien sur créer un LVM.

Code:

---

1 2 3 4 5 6

pvcreate /dev/ram5 /dev/ram6 /dev/ram7 /dev/ram8 vgcreate RD0 /dev/ram5 /dev/ram6 /dev/ram7 /dev/rama8 lvcreate -L 48 RD0 mke2fs /dev/mapper/RD0-lvol0 mount /dev/mapper/RD0-lvol0 /home/httpd/

---

Je te conseille de scanner ton serveur avec Acunetix web vulnerability scanner, très efficace ! specialisé dans les vulnerabilités Web.
Ton hacker est entré par l'une des applications qui sont installées sur ton serveur (Joomla etc ...) surement avec du XSS (Cross Site Scripting).
Une fois ton serveur scanné avec Acunetix et la faille reperée, met à jour l'application concernée.

Merci beaucoup pour vos réponses détaillées et pour les pistes évoqués.

Je vais dans un premier temps utilisé Nessus et Acunetix web vulnerability scanner comme vous me l'avez conseillé.

ps: J'attend que les tests soient terminés avant de passer le message en réglé

J'ai essayé d'utiliser les logiciels proposés concernant
- Nessus: j'ai un probleme pour acceder au serveur web, j'ai bine débloque le port mais rien n'y fait.
- Acunetix: j'ai essayé la version trial, il m'a donné des avertissements mais rien en rouge, donc c'est bizarre.

En cherchant ces logiciels, j'ai trouve le logiciel snort qui semble pas mal pour bloquer les attaques, le connaissez vous, ralentit'il le chargement des pages?

Dans l'un de vos message vous avez mentionné, l'user apache à surement accés à la commande wget, comment faire pour enlever cette permission?

merci d'avance

Citation:

---

Envoyé par thibaut06

J'ai essayé d'utiliser les logiciels proposés concernant
- Nessus: j'ai un probleme pour acceder au serveur web, j'ai bine débloque le port mais rien n'y fait.
- Acunetix: j'ai essayé la version trial, il m'a donné des avertissements mais rien en rouge, donc c'est bizarre.

En cherchant ces logiciels, j'ai trouve le logiciel snort qui semble pas mal pour bloquer les attaques, le connaissez vous, ralentit'il le chargement des pages?

Dans l'un de vos message vous avez mentionné, l'user apache à surement accés à la commande wget, comment faire pour enlever cette permission?

merci d'avance

---

la solution "bête et méchante" pour palier au plus urgent est de déplacer les binaires wget et curl dans des dossiers inhabituels qui ne sont pas dans le $PATH connu par le serveur web... (par exemple dans un dossier /home/USER/bin du USER que vous utilisez en SSH...)

(sous SELinux vous pourriez aussi enlever ces binaires de ceux exécutables par le serveur Web.. ou si vous utilisez un système qui supporte les ACLs étendus : enlever le droit d'exécution sur ces binaires par le serveur web :

Code:

---

1 2 3

chmod +a "www deny execute" /usr/bin/wget chmod +a "www deny execute" /usr/bin/curl

---

si www est le compte sous lequel tourne le serveur web...)

reste surtout à trouver quels sont vos dossiers dont les permissions sont erronées...


SNORT utilise un SGBD (mysql, postgresql, ...) pour ces opérations : la pénalité dépendra donc directement de la charge supplémentaire que votre serveur est prêt à encaisser dans ce domaine...

Merci pour votre réponse, je vais suivre la procédure, je me rend compte en consultant mes logs que des erreurs inhabituels ont liue sur apache

Invalid method in request \x80b\x01\x03\x01


Il semble que cela puisse venir de la.

Par contre, j'ai du mal à trouver les traces dans les logs des fichiers importés, quels logs dois-je consulter?

Merci d'avance

Citation:

---

Envoyé par thibaut06

Merci pour votre réponse, je vais suivre la procédure, je me rend compte en consultant mes logs que des erreurs inhabituels ont liue sur apache

Invalid method in request \x80b\x01\x03\x01


Il semble que cela puisse venir de la.

Par contre, j'ai du mal à trouver les traces dans les logs des fichiers importés, quels logs dois-je consulter?

Merci d'avance

---

"les logs des fichiers importés" ????

wget, curl ... n'ont pas de fichiers logs...

à quoi faites-vous allusion ?

Merci pour votre réactivité

Ma problématique est que mon serveur tourne depuis plus d'un an et n'a pas eu de problème de hack et seulement depuis 15 jours, je suis visé par des hackeurs qui ont pu uploadé des fichiers, et en analysant les fichiers on se rend comme que c'est afin de faire du phishing donc c'est inquietant.

Mon serveur est protégé avec iptable, rkhunter, fail2ban... et je fais en sorte que les logiciels soient constamment à jour.

Donc je cherche par tout les moyens d'identifier la faille qui a permis ces upload et trouver l'ensemble des fichiers pouvant être uploadé.

J'ai par mesure de sécurité enlevé les droits d'exécution sur wget comme vous me l'avez notifer.

Et je vais voir comment installer selinux sur debian lenny

Concernant les logs, je n'ai pas pu détecter ou/qui/comment on avait pu uploadé des fichers alors que les droits des dossiers ne le permettent pas et ce en utilisant apache.

Donc, a t'il un moyen d'avoir une trace sur ces upload?

s'ils ont utilisé wget, curl, ... ce sont des download pas des upload... et vous n'aurez aucun log...
mais çà c'est un détail sémantique...
le point principal c'est le "SI"...

êtes-vous certain que un accès FTP ou SSH n'a pu avoir lieu ? (faiblesse de mots de passe par exemple, accès par mot de passe au lieu de clés, ...)
(là il y a des logs... s'ils n'ont pas été effacés...)

est-ce que d'autres services tournent sur cette machine et qui peuvent servir de point d'entrée par un exploit d'un autre genre ?

concernant le ftp et ssh je pense pas car les fichiers avaient pour utilisateurs et groupes www-data donc apache.

Je vais analysé les logs ftp une nouvelle fois mais la derniere fois, en analysant proftp j'ai rien trouvé.

Concernant, les droits des dossiers dans lesquels ont ete uploadé les fichiers il y en a un qui était en 777, je sais que ce n'est pas recommandé du tout mais c'est mon dossier cache, donc pas beaucoup le choix.

Je viens d'installer aussi le script crawlprotect.

Merci encore pour votre aide, si je trouve de nouveaux éléments, je les ajouterai à ce post afin d'aider d'autres utilisateurs exposés à ce probléme.

Citation:

---

Envoyé par thibaut06

Concernant, les droits des dossiers dans lesquels ont ete uploadé les fichiers il y en a un qui était en 777, je sais que ce n'est pas recommandé du tout mais c'est mon dossier cache, donc pas beaucoup le choix.

---

c'est en effet une plaie commune de pas mal de produits OpenSource, genre CMS, e-Commerce...

les installations sont partout identiques et les hackers qui détectent quel produit est utilisé sur un site peuvent aller déduire les chemins relatifs des dossiers "ouverts"... (en général cache et upload... )

si vous utilisez ce genre de produits, regarder s'il est possible de changer le chemin "bien connu" de tous ces dossiers ouverts en écriture... via son fichier de configuration... si votre installation n'est plus "standard", cela sera déjà un petit peu plus compliqué pour les hackers...

Merci pour votre aide.

En effet, je vais continuer à renommer ces dossiers, et les mettre en surveillance.