Execution de scripts par www-data suite a segfault d'apache
14 réponses
cedric
Bonjour !
Nous avons une machine (tourant sous une debian potato patchée pour les
failles connues) qui vient de se faire compromettre. Un petit rigolo nous a
créé un répertoire /tmp/.../ et y a colé du warez, lancé un pti serveur
ftp, ainsi qu'un script qui tournait comme une brute pour tenter de changer
un mot de passe. Le tout avec l'utilisateur www-data.
On a fait le ménage mais on cherche à comprendre comme il a fait ca.
Il me semble qu'il n'a pas eu de shell (sinon il aurait tué son script qui
tentait vainement d'exploiter la faille ptrace, très repérable car
consommant tout le CPU disponible et une 30aine de process, pour rien).
Je pense donc que les logs n'ont pas été nettoyés.
Or ils ne révèlent pas grand chose, si ce n'est que deux heures avant qu'il
lance sont serveur ftp maison apache a segfaulté des dizaines de fois à
toute vitesse ; à part ca, rien de suspect.
D'où ma question : y a t-il une méthode connue pour uploader/exécuter des
scripts avec apache qui ne laisse pas de traces dans les logs à part une
série de segfault ?
Merci de vos idées.
(Note : je ne suis pas spécialiste de la question, comme vous l'aurez
remarqué)
D'où ma question : y a t-il une méthode connue pour uploader/exécuter des scripts avec apache qui ne laisse pas de traces dans les logs à part une série de segfault ?
Version d'apache? si < 1.3.28 des failles existent oui. Voir aussi s'il n'y à pas aussi de faille directement dans le site qu'héberge apache.
Que disent les logs apache (error et access log) aux moments des segfaults? tu devrais au moins avoir la "forme" des requetes que l'utilisateur à envoyé, son ip, etc...
Es tu sur qu'il n'a pas eu de shell? c'est pas parcequ'il a laissé un script tourné comme un fou qu'il n'a pas eu un accés shell à un moment.
Merci de vos idées.
(Note : je ne suis pas spécialiste de la question, comme vous l'aurez remarqué)
D'où ma question : y a t-il une méthode connue pour uploader/exécuter des
scripts avec apache qui ne laisse pas de traces dans les logs à part une
série de segfault ?
Version d'apache? si < 1.3.28 des failles existent oui.
Voir aussi s'il n'y à pas aussi de faille directement dans le site
qu'héberge apache.
Que disent les logs apache (error et access log) aux moments des segfaults?
tu devrais au moins avoir la "forme" des requetes que l'utilisateur à
envoyé, son ip, etc...
Es tu sur qu'il n'a pas eu de shell? c'est pas parcequ'il a laissé un script
tourné comme un fou qu'il n'a pas eu un accés shell à un moment.
Merci de vos idées.
(Note : je ne suis pas spécialiste de la question, comme vous l'aurez
remarqué)
D'où ma question : y a t-il une méthode connue pour uploader/exécuter des scripts avec apache qui ne laisse pas de traces dans les logs à part une série de segfault ?
Version d'apache? si < 1.3.28 des failles existent oui. Voir aussi s'il n'y à pas aussi de faille directement dans le site qu'héberge apache.
Que disent les logs apache (error et access log) aux moments des segfaults? tu devrais au moins avoir la "forme" des requetes que l'utilisateur à envoyé, son ip, etc...
Es tu sur qu'il n'a pas eu de shell? c'est pas parcequ'il a laissé un script tourné comme un fou qu'il n'a pas eu un accés shell à un moment.
Merci de vos idées.
(Note : je ne suis pas spécialiste de la question, comme vous l'aurez remarqué)
D'où ma question : y a t-il une méthode connue pour uploader/exécuter des scripts avec apache qui ne laisse pas de traces dans les logs à part une série de segfault ?
Quelles extensions sont installées avec apache ? perl, php ?
Si oui la compromission vient plus probablement de là.
D'où ma question : y a t-il une méthode connue pour uploader/exécuter
des scripts avec apache qui ne laisse pas de traces dans les logs à part
une série de segfault ?
Quelles extensions sont installées avec apache ? perl, php ?
Si oui la compromission vient plus probablement de là.
D'où ma question : y a t-il une méthode connue pour uploader/exécuter des scripts avec apache qui ne laisse pas de traces dans les logs à part une série de segfault ?
Quelles extensions sont installées avec apache ? perl, php ?
Si oui la compromission vient plus probablement de là.
Version d'apache? si < 1.3.28 des failles existent oui.
Server version: Apache/1.3.9 (Unix) Debian/GNU Server built: Oct 26 2002 08:09:02
Donc largement inférieur à 1.3.28. Les failles qui existent sont susceptibles de se comporter comme ca ? On va faire une mise à jour juste pour etre sur, mais j'aimerais bien savoir quand meme si c'est une faille apache... le gars à pu passer autrepart...
Voir aussi s'il n'y à pas aussi de faille directement dans le site qu'héberge apache.
Oui, peut etre, mais comme c'est immense j'aimerais savoir si ces segfaults ne sont pas la signature d'une faille apache archiconnue.
Que disent les logs apache (error et access log) aux moments des segfaults? tu devrais au moins avoir la "forme" des requetes que l'utilisateur à envoyé, son ip, etc...
dans error log, beaucoup de : [Mon Oct 20 15:46:13 2003] [notice] child pid 1038 exit signal Segmentation fault (11)
et de temps en temps, des : FATAL: emalloc(): Unable to allocate -1073743341 bytes
pendant ce temps, acces log contient des milliers d'accès à des centaines de pages différentes, qui semblent tout à fait normaux.
Es tu sur qu'il n'a pas eu de shell? c'est pas parcequ'il a laissé un script tourné comme un fou qu'il n'a pas eu un accés shell à un moment.
Non, je ne suis sur de rien, en fait, mais j'ai le sentiment que s'il avait eu un shell il aurait put faire les choses mieux (tuer ce script, effacer les segfaults dans error.log - www-data à les droit en écriture dessus), etc...
serge wrote:
Version d'apache? si < 1.3.28 des failles existent oui.
Server version: Apache/1.3.9 (Unix) Debian/GNU
Server built: Oct 26 2002 08:09:02
Donc largement inférieur à 1.3.28.
Les failles qui existent sont susceptibles de se comporter comme ca ?
On va faire une mise à jour juste pour etre sur, mais j'aimerais bien
savoir quand meme si c'est une faille apache... le gars à pu passer
autrepart...
Voir aussi s'il n'y à pas aussi de faille directement dans le site
qu'héberge apache.
Oui, peut etre, mais comme c'est immense j'aimerais savoir si ces segfaults
ne sont pas la signature d'une faille apache archiconnue.
Que disent les logs apache (error et access log) aux moments des
segfaults? tu devrais au moins avoir la "forme" des requetes que
l'utilisateur à envoyé, son ip, etc...
dans error log, beaucoup de :
[Mon Oct 20 15:46:13 2003] [notice] child pid 1038 exit signal Segmentation
fault (11)
et de temps en temps, des :
FATAL: emalloc(): Unable to allocate -1073743341 bytes
pendant ce temps, acces log contient des milliers d'accès à des centaines
de pages différentes, qui semblent tout à fait normaux.
Es tu sur qu'il n'a pas eu de shell? c'est pas parcequ'il a laissé un
script tourné comme un fou qu'il n'a pas eu un accés shell à un moment.
Non, je ne suis sur de rien, en fait, mais j'ai le sentiment que s'il avait
eu un shell il aurait put faire les choses mieux (tuer ce script, effacer
les segfaults dans error.log - www-data à les droit en écriture dessus),
etc...
Version d'apache? si < 1.3.28 des failles existent oui.
Server version: Apache/1.3.9 (Unix) Debian/GNU Server built: Oct 26 2002 08:09:02
Donc largement inférieur à 1.3.28. Les failles qui existent sont susceptibles de se comporter comme ca ? On va faire une mise à jour juste pour etre sur, mais j'aimerais bien savoir quand meme si c'est une faille apache... le gars à pu passer autrepart...
Voir aussi s'il n'y à pas aussi de faille directement dans le site qu'héberge apache.
Oui, peut etre, mais comme c'est immense j'aimerais savoir si ces segfaults ne sont pas la signature d'une faille apache archiconnue.
Que disent les logs apache (error et access log) aux moments des segfaults? tu devrais au moins avoir la "forme" des requetes que l'utilisateur à envoyé, son ip, etc...
dans error log, beaucoup de : [Mon Oct 20 15:46:13 2003] [notice] child pid 1038 exit signal Segmentation fault (11)
et de temps en temps, des : FATAL: emalloc(): Unable to allocate -1073743341 bytes
pendant ce temps, acces log contient des milliers d'accès à des centaines de pages différentes, qui semblent tout à fait normaux.
Es tu sur qu'il n'a pas eu de shell? c'est pas parcequ'il a laissé un script tourné comme un fou qu'il n'a pas eu un accés shell à un moment.
Non, je ne suis sur de rien, en fait, mais j'ai le sentiment que s'il avait eu un shell il aurait put faire les choses mieux (tuer ce script, effacer les segfaults dans error.log - www-data à les droit en écriture dessus), etc...
D'où ma question : y a t-il une méthode connue pour uploader/exécuter des scripts avec apache qui ne laisse pas de traces dans les logs à part une série de segfault ?
Quelles extensions sont installées avec apache ? perl, php ?
Les deux mon capitaine. Mais pas d'accès perl à l'heure supposée de l'attaque. A moins que lorsqu'un process segfault apache ne log pas l'accès dans accès log ? C'est bien possible et à mon avis c'est ce qui explique que mon acces.log a l'air si "normal".
Si c'est une faille dans un des scripts perl ou PHP, et que le gars s'est arrangé pour faire segfaulter le process à la fin pour que le log n'apparaisse pas, je vais pas m'amuser pour retrouver la faille, les sites hébergés sont nombreux et particulièrement pas marrants à lire.
D'où ma question : y a t-il une méthode connue pour uploader/exécuter
des scripts avec apache qui ne laisse pas de traces dans les logs à part
une série de segfault ?
Quelles extensions sont installées avec apache ? perl, php ?
Les deux mon capitaine. Mais pas d'accès perl à l'heure supposée de
l'attaque. A moins que lorsqu'un process segfault apache ne log pas l'accès
dans accès log ? C'est bien possible et à mon avis c'est ce qui explique
que mon acces.log a l'air si "normal".
Si c'est une faille dans un des scripts perl ou PHP, et que le gars s'est
arrangé pour faire segfaulter le process à la fin pour que le log
n'apparaisse pas, je vais pas m'amuser pour retrouver la faille, les sites
hébergés sont nombreux et particulièrement pas marrants à lire.
D'où ma question : y a t-il une méthode connue pour uploader/exécuter des scripts avec apache qui ne laisse pas de traces dans les logs à part une série de segfault ?
Quelles extensions sont installées avec apache ? perl, php ?
Les deux mon capitaine. Mais pas d'accès perl à l'heure supposée de l'attaque. A moins que lorsqu'un process segfault apache ne log pas l'accès dans accès log ? C'est bien possible et à mon avis c'est ce qui explique que mon acces.log a l'air si "normal".
Si c'est une faille dans un des scripts perl ou PHP, et que le gars s'est arrangé pour faire segfaulter le process à la fin pour que le log n'apparaisse pas, je vais pas m'amuser pour retrouver la faille, les sites hébergés sont nombreux et particulièrement pas marrants à lire.
Stephane Catteau
cedric nous disait récement dans fr.comp.securite <news:3f955eb4$0$13299$ :
serge wrote:
Server version: Apache/1.3.9 (Unix) Debian/GNU Server built: Oct 26 2002 08:09:02
Donc largement inférieur à 1.3.28.
Donc, tu peux partir du principe que tu as 19 failles sur ton serveur.
Les failles qui existent sont susceptibles de se comporter comme ca ?
Je n'ai plus la liste en tête, mais il me semble que cinq des failles permettent plus ou moins d'arriver à ce résultat.
On va faire une mise à jour juste pour etre sur,
Vous devriez en profiter pour prendre la bonne habitude de patcher à chaque fois, et pas seulement Apache.
mais j'aimerais bien savoir quand meme si c'est une faille apache... le gars à pu passer autrepart...
Vu les informations que tu as donné, il est passé par Apache.
Voir aussi s'il n'y à pas aussi de faille directement dans le site qu'héberge apache.
Oui, peut etre, mais comme c'est immense j'aimerais savoir si ces segfaults ne sont pas la signature d'une faille apache archiconnue.
Il n'y a pas à proprement parler de faille Apache "archiconnue", car elles sont rarement exploitables à long terme. Pour en savoir plus, il faudrait que tu passes en revue les alertes concernant les versions 1.3.9 jusqu'à 1.3.27.
-- "Si ceux qui disent du mal de moi savaient exactement ce que je pense d'eux , ils en diraient bien davantage." Sacha Guitry
cedric nous disait récement dans fr.comp.securite
<news:3f955eb4$0$13299$626a54ce@news.free.fr> :
serge wrote:
Server version: Apache/1.3.9 (Unix) Debian/GNU
Server built: Oct 26 2002 08:09:02
Donc largement inférieur à 1.3.28.
Donc, tu peux partir du principe que tu as 19 failles sur ton serveur.
Les failles qui existent sont susceptibles de se comporter comme
ca ?
Je n'ai plus la liste en tête, mais il me semble que cinq des failles
permettent plus ou moins d'arriver à ce résultat.
On va faire une mise à jour juste pour etre sur,
Vous devriez en profiter pour prendre la bonne habitude de patcher à
chaque fois, et pas seulement Apache.
mais j'aimerais bien savoir quand meme si c'est une faille apache...
le gars à pu passer autrepart...
Vu les informations que tu as donné, il est passé par Apache.
Voir aussi s'il n'y à pas aussi de faille directement dans le
site qu'héberge apache.
Oui, peut etre, mais comme c'est immense j'aimerais savoir si ces
segfaults ne sont pas la signature d'une faille apache archiconnue.
Il n'y a pas à proprement parler de faille Apache "archiconnue", car
elles sont rarement exploitables à long terme. Pour en savoir plus, il
faudrait que tu passes en revue les alertes concernant les versions
1.3.9 jusqu'à 1.3.27.
--
"Si ceux qui disent du mal de moi savaient exactement ce que je
pense d'eux , ils en diraient bien davantage."
Sacha Guitry
cedric nous disait récement dans fr.comp.securite <news:3f955eb4$0$13299$ :
serge wrote:
Server version: Apache/1.3.9 (Unix) Debian/GNU Server built: Oct 26 2002 08:09:02
Donc largement inférieur à 1.3.28.
Donc, tu peux partir du principe que tu as 19 failles sur ton serveur.
Les failles qui existent sont susceptibles de se comporter comme ca ?
Je n'ai plus la liste en tête, mais il me semble que cinq des failles permettent plus ou moins d'arriver à ce résultat.
On va faire une mise à jour juste pour etre sur,
Vous devriez en profiter pour prendre la bonne habitude de patcher à chaque fois, et pas seulement Apache.
mais j'aimerais bien savoir quand meme si c'est une faille apache... le gars à pu passer autrepart...
Vu les informations que tu as donné, il est passé par Apache.
Voir aussi s'il n'y à pas aussi de faille directement dans le site qu'héberge apache.
Oui, peut etre, mais comme c'est immense j'aimerais savoir si ces segfaults ne sont pas la signature d'une faille apache archiconnue.
Il n'y a pas à proprement parler de faille Apache "archiconnue", car elles sont rarement exploitables à long terme. Pour en savoir plus, il faudrait que tu passes en revue les alertes concernant les versions 1.3.9 jusqu'à 1.3.27.
-- "Si ceux qui disent du mal de moi savaient exactement ce que je pense d'eux , ils en diraient bien davantage." Sacha Guitry
JustMe
cedric wrote:
serge wrote:
Version d'apache? si < 1.3.28 des failles existent oui.
Server version: Apache/1.3.9 (Unix) Debian/GNU Server built: Oct 26 2002 08:09:02
Donc largement inférieur à 1.3.28. Les failles qui existent sont susceptibles de se comporter comme ca ? On va faire une mise à jour juste pour etre sur, mais j'aimerais bien savoir quand meme si c'est une faille apache... le gars à pu passer autrepart...
De toutes facon a present qu'il est rentré tu n'as plus qu'a refaire ta machine de A a Z :-(
Le premier truc que ce genre de gugusse installe c'est un rootkit qui va lui ouvrir une backdoor..
cedric wrote:
serge wrote:
Version d'apache? si < 1.3.28 des failles existent oui.
Server version: Apache/1.3.9 (Unix) Debian/GNU
Server built: Oct 26 2002 08:09:02
Donc largement inférieur à 1.3.28.
Les failles qui existent sont susceptibles de se comporter comme ca ?
On va faire une mise à jour juste pour etre sur, mais j'aimerais bien
savoir quand meme si c'est une faille apache... le gars à pu passer
autrepart...
De toutes facon a present qu'il est rentré tu n'as plus qu'a refaire ta
machine de A a Z :-(
Le premier truc que ce genre de gugusse installe c'est un rootkit qui va
lui ouvrir une backdoor..
Version d'apache? si < 1.3.28 des failles existent oui.
Server version: Apache/1.3.9 (Unix) Debian/GNU Server built: Oct 26 2002 08:09:02
Donc largement inférieur à 1.3.28. Les failles qui existent sont susceptibles de se comporter comme ca ? On va faire une mise à jour juste pour etre sur, mais j'aimerais bien savoir quand meme si c'est une faille apache... le gars à pu passer autrepart...
De toutes facon a present qu'il est rentré tu n'as plus qu'a refaire ta machine de A a Z :-(
Le premier truc que ce genre de gugusse installe c'est un rootkit qui va lui ouvrir une backdoor..
Fabien SPAGNOLO
"cedric" a écrit dans le message de news:3f953e4e$0$13299$ | | Merci de vos idées.
Es-tu certain que ton apache est à jour du point de vue des patchs ? S'il l'est alors il faut plutôt chercher effectivement du côté des CGI.
Si non alors le comportement que tu rencontres ressemble beaucoup à ceci que j'avais testé à l'époque :
Cet exploit très connu possède un mode brute-force qui permet de tester automatiquement tout un range de valeurs pour l'offset retour. Ca permet d'attaquer des serveurs dont on n'a pas connaissance a priori de l'offset et de l'alignement.
Comme apache dispose d'un processus principal et que les processus qui écoutent et traitent les connexions sont des processus forkés, le fait de passer un mauvais offset tue simplement le processus fils qui écoute la connexion, donc segfault. Apache recharge n processus fils lorsqu' un seuil est franchi (pour ne pas se retrouver avec trop peu de processus pour traiter un afflux de connexions entrantes) ce qui signifie que quelque soit le nombre de processus fils tués il y en aura toujours. Du coup le brute force est possible sauf que dans les logs apaches (les logs systèmes pas les logs d'accès) tu obtiens toute une série de segfault correspond aux essais de l'expoit. Je me souviens, même si c'était il y a longtemps, avoir vu cette série de segfaults.
Pour ce qui est du payload de l'expoit je ne me souviens plus de ce qu'il fait par défaut mais de toute façon c'est facile à changer pour lui faire faire un peu ce qu'on veut dans la limite des droits associés au process exploité.
-- Fabien SPAGNOLO
"cedric" <cedric@pimentech.net> a écrit dans le message de
news:3f953e4e$0$13299$626a54ce@news.free.fr...
|
| Merci de vos idées.
Es-tu certain que ton apache est à jour du point de vue des patchs ? S'il
l'est alors il faut plutôt chercher effectivement du côté des CGI.
Si non alors le comportement que tu rencontres ressemble beaucoup à ceci que
j'avais testé à l'époque :
Cet exploit très connu possède un mode brute-force qui permet de tester
automatiquement tout un range de valeurs pour l'offset retour. Ca permet
d'attaquer des serveurs dont on n'a pas connaissance a priori de l'offset et
de l'alignement.
Comme apache dispose d'un processus principal et que les processus qui
écoutent et traitent les connexions sont des processus forkés, le fait de
passer un mauvais offset tue simplement le processus fils qui écoute la
connexion, donc segfault. Apache recharge n processus fils lorsqu' un seuil
est franchi (pour ne pas se retrouver avec trop peu de processus pour
traiter un afflux de connexions entrantes) ce qui signifie que quelque soit
le nombre de processus fils tués il y en aura toujours. Du coup le brute
force est possible sauf que dans les logs apaches (les logs systèmes pas les
logs d'accès) tu obtiens toute une série de segfault correspond aux essais
de l'expoit. Je me souviens, même si c'était il y a longtemps, avoir vu
cette série de segfaults.
Pour ce qui est du payload de l'expoit je ne me souviens plus de ce qu'il
fait par défaut mais de toute façon c'est facile à changer pour lui faire
faire un peu ce qu'on veut dans la limite des droits associés au process
exploité.
Cet exploit très connu possède un mode brute-force qui permet de tester automatiquement tout un range de valeurs pour l'offset retour. Ca permet d'attaquer des serveurs dont on n'a pas connaissance a priori de l'offset et de l'alignement.
Comme apache dispose d'un processus principal et que les processus qui écoutent et traitent les connexions sont des processus forkés, le fait de passer un mauvais offset tue simplement le processus fils qui écoute la connexion, donc segfault. Apache recharge n processus fils lorsqu' un seuil est franchi (pour ne pas se retrouver avec trop peu de processus pour traiter un afflux de connexions entrantes) ce qui signifie que quelque soit le nombre de processus fils tués il y en aura toujours. Du coup le brute force est possible sauf que dans les logs apaches (les logs systèmes pas les logs d'accès) tu obtiens toute une série de segfault correspond aux essais de l'expoit. Je me souviens, même si c'était il y a longtemps, avoir vu cette série de segfaults.
Pour ce qui est du payload de l'expoit je ne me souviens plus de ce qu'il fait par défaut mais de toute façon c'est facile à changer pour lui faire faire un peu ce qu'on veut dans la limite des droits associés au process exploité.
-- Fabien SPAGNOLO
cedric
JustMe wrote:
Le premier truc que ce genre de gugusse installe c'est un rootkit qui va lui ouvrir une backdoor..
Non, s'il avait installé un rootkit son serveur ftp aurait été caché je pense. Là, il se l'est fait éclater au bout de quelques heures d'existence.
JustMe wrote:
Le premier truc que ce genre de gugusse installe c'est un rootkit qui va
lui ouvrir une backdoor..
Non, s'il avait installé un rootkit son serveur ftp aurait été caché je
pense. Là, il se l'est fait éclater au bout de quelques heures d'existence.
Si c'est une faille dans un des scripts perl ou PHP, et que le gars s'est arrangé pour faire segfaulter le process à la fin pour que le log n'apparaisse pas, je vais pas m'amuser pour retrouver la faille, les sites hébergés sont nombreux et particulièrement pas marrants à lire.
php et compilé en module ou en cgi ?
S'il est en module, une exploitation d'un bug php peut très bien faire segfaulter apache. Pour finir il faudrait avoir exactement ta version d'apache avec tous les paramètres de compilation, idem pour les extensions pour essayer d'y voir un peu plus clair.
Si c'est une faille dans un des scripts perl ou PHP, et que le gars s'est
arrangé pour faire segfaulter le process à la fin pour que le log
n'apparaisse pas, je vais pas m'amuser pour retrouver la faille, les sites
hébergés sont nombreux et particulièrement pas marrants à lire.
php et compilé en module ou en cgi ?
S'il est en module, une exploitation d'un bug php peut très bien faire
segfaulter apache. Pour finir il faudrait avoir exactement ta version
d'apache avec tous les paramètres de compilation, idem pour les extensions
pour essayer d'y voir un peu plus clair.
Si c'est une faille dans un des scripts perl ou PHP, et que le gars s'est arrangé pour faire segfaulter le process à la fin pour que le log n'apparaisse pas, je vais pas m'amuser pour retrouver la faille, les sites hébergés sont nombreux et particulièrement pas marrants à lire.
php et compilé en module ou en cgi ?
S'il est en module, une exploitation d'un bug php peut très bien faire segfaulter apache. Pour finir il faudrait avoir exactement ta version d'apache avec tous les paramètres de compilation, idem pour les extensions pour essayer d'y voir un peu plus clair.
