Bonsoir à tous, après avoir écumé plusieurs documentations, ainsi que
plusieurs questions auprès de gens travaillant sur le kernel, un problème
reste sans réponse.
L'opération, qui a lieu au cours d'un pen test est la suivante :
1) Le système est installé neuf et à jour quelques heures avant
2) Un accès de type shell utilisateur standard a pu être obtenu
3) Après un nombre important de tests et d'opérations sur le systême, et
bien qu'ayant tjs les memes uid/gid/euid, je me retrouve dans la
possibilité d'utiliser la commande chown, et uniquement celle ci n'importe
où sur le système et dans les 2 sens.
4) je peux donc faire un chown toto.users de n'importe quel fichier afin de
le modifier (exemple : /etc/shadow) et refaire derrière un chown root.root
du fichier.
5) Après déconnexion du système puis reconnexion avec le même utilisateur,
cette opération est toujours possible.
6) Ce cas a pu n'être produit que 2 fois par votre serviteur, une fois sur
une Debian équipée d'un kernel 2.4.18, et une fois sur la dernière redhat.
7) Toutes les discussions que j'ai peu avoir avec des gens travaillant
autour de la sécurité du noyau, m'affirment, que, outre le fait que ce
comportement soit "quasi" impossible, cela ne devrait pas perdurer après
déconnexion/reconnexion de l'utilisateur
Ma question est simple : comment est ce possible, et de quel coté chercher ?
Pour information, de nombreux tests avaient été effectués sur la machine
avant de se retrouver dans cet état, notamment des outils de recherche de
type buffer overflow comme bfbtester ou divers exploits kernel (ptrace par
exemple) avec diverses modifications avaient été effectués avant. Je ne
sais pas à partir de quel moment est intervenu ce bug, puisque je m'en suis
rendu compte par hasard.
Ce que je veux dire, c'est que "réinstallé et mis à jour juste avant", ce n'est pas vraiment une garantie de l'absence de backdoor. Il faut déterminer la provenance des médias, vérifier l'intégrité des paquets, ...
Cette vérification là par contre, a été effectuée (mais pas par moi...), il reste bien sur la possibilité de sources backdoorés à un moment précis et dont la backdoor aurait été "activée" par erreur, mais cela me parait peu probable.
Tout est possible, même que des singes écrivent du Shakespear en tapant comme des idiots sur un clavier.
Possible oui, probable moins :)
Comme le disait Dominique Blas, sans reproduction possible, il sera quasiment impossible de tracer un éventuel problème. En tout cas, si tu as de nouveau sous la main ce type de machine "possédée", une sauvegarde intégrale (dont RAM, swap, ...) du système est à réaliser en vue d'analyse ultérieure !
Mon rôle dans cette histoire ne me permettait malheureusement pas d'effectuer une sauvegarde du système, j'ai cherché (mais peu faute de temps) à reproduire ce type de comportement sans succès pour l'instant.
Ce que je veux dire, c'est que "réinstallé et mis à jour juste avant",
ce n'est pas vraiment une garantie de l'absence de backdoor. Il faut
déterminer la provenance des médias, vérifier l'intégrité des paquets, ...
Cette vérification là par contre, a été effectuée (mais pas par moi...), il
reste bien sur la possibilité de sources backdoorés à un moment précis et
dont la backdoor aurait été "activée" par erreur, mais cela me parait peu
probable.
Tout est possible, même que des singes écrivent du Shakespear en tapant
comme des idiots sur un clavier.
Possible oui, probable moins :)
Comme le disait Dominique Blas, sans reproduction possible, il sera
quasiment impossible de tracer un éventuel problème. En tout cas, si tu
as de nouveau sous la main ce type de machine "possédée", une sauvegarde
intégrale (dont RAM, swap, ...) du système est à réaliser en vue
d'analyse ultérieure !
Mon rôle dans cette histoire ne me permettait malheureusement pas
d'effectuer une sauvegarde du système, j'ai cherché (mais peu faute de
temps) à reproduire ce type de comportement sans succès pour l'instant.
Ce que je veux dire, c'est que "réinstallé et mis à jour juste avant", ce n'est pas vraiment une garantie de l'absence de backdoor. Il faut déterminer la provenance des médias, vérifier l'intégrité des paquets, ...
Cette vérification là par contre, a été effectuée (mais pas par moi...), il reste bien sur la possibilité de sources backdoorés à un moment précis et dont la backdoor aurait été "activée" par erreur, mais cela me parait peu probable.
Tout est possible, même que des singes écrivent du Shakespear en tapant comme des idiots sur un clavier.
Possible oui, probable moins :)
Comme le disait Dominique Blas, sans reproduction possible, il sera quasiment impossible de tracer un éventuel problème. En tout cas, si tu as de nouveau sous la main ce type de machine "possédée", une sauvegarde intégrale (dont RAM, swap, ...) du système est à réaliser en vue d'analyse ultérieure !
Mon rôle dans cette histoire ne me permettait malheureusement pas d'effectuer une sauvegarde du système, j'ai cherché (mais peu faute de temps) à reproduire ce type de comportement sans succès pour l'instant.
Le 20-09-2005, à propos de Re: information securite kernel 2.4.x, Christophe Casalegno écrivait dans fr.comp.securite :
JKB wrote:
S'il s'agit de la même machine, voir du côté du disque dur, de la mémoire ou du cache processeur. J'ai déjà pu observer de telles joyeusetés (moi, c'était plutôt, root n'a plus le droit de modifier ses propres fichiers). Que disent dmesg et /var/log/auth.log (sur la debian) ?
Ce n'était pas "la même", cependant il est possible que certains composants étaient les mêmes. Je n'ai plus accès à ces machines, j'avais bien pensé à l'influence possible du matériel, sans toutefois trouver une piste réellement probante.
Ces manifestations qui te sont arrivées sont arrivées suite à des opérations particulières ?
Simplement des comportements folkloriques dus à des defauts de mémoire ou de proc. Pas d'opérations bizarres ou particulières, et le problème n'était pas reproductible. Un coup de memtest m'a permis de voir que la mémoire cache sur la carte mère était défectueuse.
Cordialement,
JKB
Le 20-09-2005, à propos de
Re: information securite kernel 2.4.x,
Christophe Casalegno écrivait dans fr.comp.securite :
JKB wrote:
S'il s'agit de la même machine, voir du côté du disque dur, de la mémoire
ou du cache processeur. J'ai déjà pu observer de telles joyeusetés (moi,
c'était plutôt, root n'a plus le droit de modifier ses propres fichiers).
Que disent dmesg et /var/log/auth.log (sur la debian) ?
Ce n'était pas "la même", cependant il est possible que certains composants
étaient les mêmes. Je n'ai plus accès à ces machines, j'avais bien pensé à
l'influence possible du matériel, sans toutefois trouver une piste
réellement probante.
Ces manifestations qui te sont arrivées sont arrivées suite à des opérations
particulières ?
Simplement des comportements folkloriques dus à des defauts de mémoire ou de
proc. Pas d'opérations bizarres ou particulières, et le problème n'était pas
reproductible. Un coup de memtest m'a permis de voir que la mémoire cache
sur la carte mère était défectueuse.
Le 20-09-2005, à propos de Re: information securite kernel 2.4.x, Christophe Casalegno écrivait dans fr.comp.securite :
JKB wrote:
S'il s'agit de la même machine, voir du côté du disque dur, de la mémoire ou du cache processeur. J'ai déjà pu observer de telles joyeusetés (moi, c'était plutôt, root n'a plus le droit de modifier ses propres fichiers). Que disent dmesg et /var/log/auth.log (sur la debian) ?
Ce n'était pas "la même", cependant il est possible que certains composants étaient les mêmes. Je n'ai plus accès à ces machines, j'avais bien pensé à l'influence possible du matériel, sans toutefois trouver une piste réellement probante.
Ces manifestations qui te sont arrivées sont arrivées suite à des opérations particulières ?
Simplement des comportements folkloriques dus à des defauts de mémoire ou de proc. Pas d'opérations bizarres ou particulières, et le problème n'était pas reproductible. Un coup de memtest m'a permis de voir que la mémoire cache sur la carte mère était défectueuse.
Cordialement,
JKB
Nicob
On Wed, 21 Sep 2005 09:07:23 +0000, Christophe Casalegno wrote:
Cela dit tous les gens avec qui j'ai pu en parler et qui travaillent autour du kernel m'ont dit que l'architecture du noyau était faite de telle manière, que, si cela se produisait, la déconnexion/reconnexion aurait du annuler cet "état".
Un reboot, je comprendrais, mais une déconnexion, je ne vois pas. Tant que le kernel en cours d'exécution n'est pas remplacé, il peut toujours attribuer des droits farfelus à tel UID ou à tel nom de process.
Mais je suis loin d'être un expert du noyau ...
Nicob
On Wed, 21 Sep 2005 09:07:23 +0000, Christophe Casalegno wrote:
Cela dit tous les gens avec qui j'ai pu en parler et qui travaillent autour
du kernel m'ont dit que l'architecture du noyau était faite de telle
manière, que, si cela se produisait, la déconnexion/reconnexion aurait du
annuler cet "état".
Un reboot, je comprendrais, mais une déconnexion, je ne vois pas. Tant
que le kernel en cours d'exécution n'est pas remplacé, il peut toujours
attribuer des droits farfelus à tel UID ou à tel nom de process.
On Wed, 21 Sep 2005 09:07:23 +0000, Christophe Casalegno wrote:
Cela dit tous les gens avec qui j'ai pu en parler et qui travaillent autour du kernel m'ont dit que l'architecture du noyau était faite de telle manière, que, si cela se produisait, la déconnexion/reconnexion aurait du annuler cet "état".
Un reboot, je comprendrais, mais une déconnexion, je ne vois pas. Tant que le kernel en cours d'exécution n'est pas remplacé, il peut toujours attribuer des droits farfelus à tel UID ou à tel nom de process.
Mais je suis loin d'être un expert du noyau ...
Nicob
Christophe Casalegno
Nicob wrote:
Un reboot, je comprendrais, mais une déconnexion, je ne vois pas. Tant que le kernel en cours d'exécution n'est pas remplacé, il peut toujours attribuer des droits farfelus à tel UID ou à tel nom de process.
Mais je suis loin d'être un expert du noyau ...
Je crois que c'est Phil, le dev de lids qui m'avait dit ca à l'époque, à vérifier :)
Un reboot, je comprendrais, mais une déconnexion, je ne vois pas. Tant
que le kernel en cours d'exécution n'est pas remplacé, il peut toujours
attribuer des droits farfelus à tel UID ou à tel nom de process.
Mais je suis loin d'être un expert du noyau ...
Je crois que c'est Phil, le dev de lids qui m'avait dit ca à l'époque, à
vérifier :)
Un reboot, je comprendrais, mais une déconnexion, je ne vois pas. Tant que le kernel en cours d'exécution n'est pas remplacé, il peut toujours attribuer des droits farfelus à tel UID ou à tel nom de process.
Mais je suis loin d'être un expert du noyau ...
Je crois que c'est Phil, le dev de lids qui m'avait dit ca à l'époque, à vérifier :)
Si c'était reproductible via une séquence que je connaitrais, je n'aurai pas eu besoin d'aide pour comprendre :), j'aurai effectué l'analyse moi même. Ben oui mais en dehors du cas où quelqu'un d'autre est parvenu au même
résultat de manière reproductible il y a peu de chance que l'on puisse t'aider si on ne peut reproduire.
Je n'y ai été confronté que 2 fois, dans les 2 cas, le seul "point commun", est le passage de presque tous les binaires du système à des outils de type bfbtester, dont chown, chmod et compagnie. Il serait intéressant, dans ce cas, de comparer
les MD5 des binaires par rapport à ceux d'origine.
Cela dit tous les gens avec qui j'ai pu en parler et qui travaillent autour du kernel m'ont dit que l'architecture du noyau était faite de telle manière, que, si cela se produisait, la déconnexion/reconnexion aurait du annuler cet "état". Je tiens à préciser que *seul* la commande chown était concernée, tout le reste, fonctionnait sans possibilité de donner des droits supplémentaires (exemple chmod) Mouais. Enfin, si c'est le noyau qui est << perturbé >> d'une manière ou
d'une autre, ce n'est pas une déconnexion qui y changera grand chose.
Pour ceux qui cherchent des possibilité d'intrusions reproductibles et non encore observées, je leur conseille plutot d'aller fouiller du coté du code des pilotes "exotiques", on y trouve parfois des trucs pas très sains :). Justement, et l'un de tes programmes testeur n'aurait pas installé un
LKM invisible activé par un chown modifié des fois ? :-)
db
--
Courriel : usenet blas net
[...]
Si c'était reproductible via une séquence que je connaitrais, je n'aurai pas
eu besoin d'aide pour comprendre :), j'aurai effectué l'analyse moi même.
Ben oui mais en dehors du cas où quelqu'un d'autre est parvenu au même
résultat de manière reproductible il y a peu de chance que l'on puisse
t'aider si on ne peut reproduire.
Je n'y ai été confronté que 2 fois, dans les 2 cas, le seul "point commun",
est le passage de presque tous les binaires du système à des outils de type
bfbtester, dont chown, chmod et compagnie.
Il serait intéressant, dans ce cas, de comparer
les MD5 des binaires par rapport à ceux d'origine.
Cela dit tous les gens avec qui j'ai pu en parler et qui travaillent autour
du kernel m'ont dit que l'architecture du noyau était faite de telle
manière, que, si cela se produisait, la déconnexion/reconnexion aurait du
annuler cet "état". Je tiens à préciser que *seul* la commande chown était
concernée, tout le reste, fonctionnait sans possibilité de donner des
droits supplémentaires (exemple chmod)
Mouais. Enfin, si c'est le noyau qui est << perturbé >> d'une manière ou
d'une autre, ce n'est pas une déconnexion qui y changera grand chose.
Pour ceux qui cherchent des possibilité d'intrusions reproductibles et non
encore observées, je leur conseille plutot d'aller fouiller du coté du code
des pilotes "exotiques", on y trouve parfois des trucs pas très sains :).
Justement, et l'un de tes programmes testeur n'aurait pas installé un
LKM invisible activé par un chown modifié des fois ? :-)
Si c'était reproductible via une séquence que je connaitrais, je n'aurai pas eu besoin d'aide pour comprendre :), j'aurai effectué l'analyse moi même. Ben oui mais en dehors du cas où quelqu'un d'autre est parvenu au même
résultat de manière reproductible il y a peu de chance que l'on puisse t'aider si on ne peut reproduire.
Je n'y ai été confronté que 2 fois, dans les 2 cas, le seul "point commun", est le passage de presque tous les binaires du système à des outils de type bfbtester, dont chown, chmod et compagnie. Il serait intéressant, dans ce cas, de comparer
les MD5 des binaires par rapport à ceux d'origine.
Cela dit tous les gens avec qui j'ai pu en parler et qui travaillent autour du kernel m'ont dit que l'architecture du noyau était faite de telle manière, que, si cela se produisait, la déconnexion/reconnexion aurait du annuler cet "état". Je tiens à préciser que *seul* la commande chown était concernée, tout le reste, fonctionnait sans possibilité de donner des droits supplémentaires (exemple chmod) Mouais. Enfin, si c'est le noyau qui est << perturbé >> d'une manière ou
d'une autre, ce n'est pas une déconnexion qui y changera grand chose.
Pour ceux qui cherchent des possibilité d'intrusions reproductibles et non encore observées, je leur conseille plutot d'aller fouiller du coté du code des pilotes "exotiques", on y trouve parfois des trucs pas très sains :). Justement, et l'un de tes programmes testeur n'aurait pas installé un
LKM invisible activé par un chown modifié des fois ? :-)
db
--
Courriel : usenet blas net
Christophe Casalegno
Dominique Blas wrote:
Pour ceux qui cherchent des possibilité d'intrusions reproductibles et non encore observées, je leur conseille plutot d'aller fouiller du coté du code des pilotes "exotiques", on y trouve parfois des trucs pas très sains :). Justement, et l'un de tes programmes testeur n'aurait pas installé un
LKM invisible activé par un chown modifié des fois ? :-)
N'ayant jamais vu un stylo bille, même après plusieurs années évoluer "spontannément" vers une forme plus évoluée, je ne pense pas que les outils évoluent tout seuls ;) dans tous les cas il faudrait pour installer ce LKM qu'ils aient réussi à rooter la machine :)
Pour ceux qui cherchent des possibilité d'intrusions reproductibles et
non encore observées, je leur conseille plutot d'aller fouiller du coté
du code des pilotes "exotiques", on y trouve parfois des trucs pas très
sains :).
Justement, et l'un de tes programmes testeur n'aurait pas installé un
LKM invisible activé par un chown modifié des fois ? :-)
N'ayant jamais vu un stylo bille, même après plusieurs années évoluer
"spontannément" vers une forme plus évoluée, je ne pense pas que les outils
évoluent tout seuls ;) dans tous les cas il faudrait pour installer ce LKM
qu'ils aient réussi à rooter la machine :)
Pour ceux qui cherchent des possibilité d'intrusions reproductibles et non encore observées, je leur conseille plutot d'aller fouiller du coté du code des pilotes "exotiques", on y trouve parfois des trucs pas très sains :). Justement, et l'un de tes programmes testeur n'aurait pas installé un
LKM invisible activé par un chown modifié des fois ? :-)
N'ayant jamais vu un stylo bille, même après plusieurs années évoluer "spontannément" vers une forme plus évoluée, je ne pense pas que les outils évoluent tout seuls ;) dans tous les cas il faudrait pour installer ce LKM qu'ils aient réussi à rooter la machine :)
