Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

rootkit Jessie?

11 réponses
Avatar
maderios
Bonjour
J'obtiens ceci après avoir lancé Chkrootkit
Searching for Suckit rootkit... Warning:
/sbin/init INFECTED

/sbin/init est un lien symbolique
-> /lib/systemd/systemd

Rkhunter me donne des warnings pour /sbin /usr/sbin /bin /usr/bin
puis ne trouve aucun rootkit. Je ne sais pas quoi en penser...

--
Maderios


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/541AA6CC.6030907@gmail.com

10 réponses

1 2
Avatar
Serge SMEESTERS
Salut maderios,

On pourrait discuter pour savoir si c'est une bonne chose ou pas mais
le projet Debian à en effet décidé d'adopter systemd...
https://linuxfr.org/users/elessar/journaux/debian-adopte-systemd-comme-init -par-defaut

Sans pouvoir être catégorique, j'ai l'impression Chkrootkit devra it
être mis à jour...

À+,
Serge S.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/CAFeEpGDxtPS1qaV-G9aDuDjRGaQFZJSOE+bk1KzuyBk1gA+
Avatar
Francois Boisson
Le Thu, 18 Sep 2014 14:28:00 +0200
Francois Boisson a écrit:


suckit utilise des processus cachés. Essaye un truc genre

for i in $(seq 1 65536); do ls -l $i/cmdline; done 2> /dev/null | sed -e '1,
$s|^.* ([0-9]*)/cmdline$|ps -p 1 -o comm=|g' | sh




Flute
ps -p PID -o comm
ne fait pas d'erreurs si le processus n'existe pas. Enlève le -o comm= et tu
ne dois pas avoir deux lignes
PID TTY TIME CMD
qui se suivent.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
Francois Boisson
Le Thu, 18 Sep 2014 11:33:00 +0200
maderios a écrit:

Bonjour
J'obtiens ceci après avoir lancé Chkrootkit
Searching for Suckit rootkit... Warning:
/sbin/init INFECTED

/sbin/init est un lien symbolique
-> /lib/systemd/systemd




suckit utilise des processus cachés. Essaye un truc genre

for i in $(seq 1 65536); do ls -l $i/cmdline; done 2> /dev/null | sed -e '1,$s|^.* ([0-9]*)/cmdline$|ps -p 1 -o comm=|g' | sh

qui devrait ne pas afficher d'erreurs ou bien utilise mon paquet cacheproc ou un paquet
équivalent genre unhide.

François Boisson

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
maderios
On 09/18/2014 02:28 PM, Francois Boisson wrote:

J'obtiens ceci après avoir lancé Chkrootkit
Searching for Suckit rootkit... Warning:
/sbin/init INFECTED

/sbin/init est un lien symbolique
-> /lib/systemd/systemd




suckit utilise des processus cachés. Essaye un truc genre

for i in $(seq 1 65536); do ls -l $i/cmdline; done 2> /dev/null | sed -e '1,$s|^.* ([0-9]*)/cmdline$|ps -p 1 -o comm=|g' | sh

qui devrait ne pas afficher d'erreurs



Fait, Aucune erreur
ou bien utilise mon paquet cacheproc ou un paquet
équivalent genre unhide.

François Boisson



1° passe de unhide
unhide -v -m -d sys procall proc reverse brute reverse

Found HIDDEN PID: 30034
Cmdline: "<none>"
Executable: "<no link>"
"<none> ... maybe a transitory process"

2° passe
unhide -v -m -d sys procall proc reverse brute reverse
Rien de caché
Vu le nombre de doléances concernant ce sujet sur le net, j'aurais
tendance à laisser tomber mais.... . J'ai upgradé systemd Jessie à la
version Sid, pas de changement.

--
Maderios


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
Serge SMEESTERS
for i in $(seq 1 65536); do ls -l $i/cmdline; done 2> /dev/null | sed -e '1,$s|^.* ([0-9]*)/cmdline$|ps -p 1 -o comm=|g' | sh



Il me semble qu'il meanque /proc dans ta commande ↑ et aussi qu'un
find sera plus rapide...


J'ai donc exécuté la commande suivante :

find /proc/ -regex '/proc/[0-9]*/cmdline' 2>/dev/null | sed
'1,$s|^/proc/([0-9]*)/cmdline$|ps -p 1|g' | sh

et j'ai 3 lignes
PID TTY TIME CMD
qui se suivent !

Est-ce grave docteur ?

Qu'est-ce que cela signifie ?

À+,
Serge S.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/CAFeEpGCjYrOCCLor8S9=3OYe4Vn4B6jiR5cG-+rGi_39stMr+
Avatar
Serge SMEESTERS
J'ai donc exécuté la commande suivante :

find /proc/ -regex '/proc/[0-9]*/cmdline' 2>/dev/null | sed
'1,$s|^/proc/([0-9]*)/cmdline$|ps -p 1|g' | sh

et j'ai 3 lignes
PID TTY TIME CMD
qui se suivent !



Et c'est curieux, alors que je cherchais à trouver les PID, elles ont
finis par disparaître...
Serions-nous à ce point surveillé :)

À+,
Serge S.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/CAFeEpGB1njoxYJW_XZypHrw=y9FuZ=
Avatar
Sylvain L. Sauvage
Le jeudi 18 septembre 2014, 16:06:28 Serge SMEESTERS a écrit :
[… find /proc | sed | sh …]
Et c'est curieux, alors que je cherchais à trouver les PID,
elles ont finis par disparaître...
Serions-nous à ce point surveillé :)



Ce qui serait bien avant d’exécuter (et d’« optimiser ») une
commande donnée, ce serait d’essayer de la comprendre et, aussi,
d’en comprendre les limites.

Techniquement, la commande de François (qui doit être exà ©cutée
depuis /proc) :
— liste tous les fichiers cmdline (for + ls) ;
— récupère le pid et crée une commande ps avec c elui-ci (sed) ;
— exécute ces commandes.

Le but est de repérer les processus existant dans /proc mais
que ps ne verrait pas (erreur lors du ps pour le pid d’icelui).

Il y a plusieurs (petits) problèmes avec cette commande.

Déjà, effectivement, le seq n’est pas des plus rapi des (c’est
même très très lent un seq). Le find est sans doute un p eu
mieux. Un simple
cd /proc && ls -d [0-9]*
donne directement la liste des pids des processus en cours, sans
la lenteur d’un seq (ou d’un find).
D’ailleurs, on peut éviter le sed et le sh final :
cd /proc && ls -d [0-9]* | while read i; ps -p $i >/dev/null
|| echo $i ; done

Ensuite, puisqu’on ne cherche que les pids qui posent
problème, la sortie du ps ne nous intéresse pas vraiment. Ell e
est même plutôt gênante. Ce qui serait bien plus inté ressant,
c’est le cmdline du processus qui n’est pas vu par ps.

Enfin, et surtout, entre le moment où la liste des pids est
faite et le moment où le ps de chaque pid est exécuté, l e
processus en question a des chances d’avoir terminé. Donc le ps
sort en erreur alors que le processus était bénin (p.ex.,
surtout avec le seq, si le pid en question correspond à une de
nos propres commandes intermédiaires, comme un des ls). Le
système ne s’arrête pas de créer des processus q uand on se met à
les regarder…

Donc, pour ce genre de choses, il vaut mieux donner sa
confiance à un outil un peu mieux peaufiné (ce qui n’ empêche pas
non plus d’essayer de comprendre ce que l’outil fait).


Sinon, pour revenir au sujet premier, il semble simplement que
chkrootkit n’aime pas que /sbin/init soit un lien symbolique.
C’est le cas dans Debian pour pouvoir utiliser systemd, sysv-
init ou autre facilement. Et c’est le « ou autre » et
« facilement » qui peut faire peur à un chkrootkit†¦

--
Sylvain Sauvage

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
François Boisson
En fait, pour ceux que ça interesse, le paquet cacheproc est né sur cette
liste. Je vous suggère de lire
https://lists.debian.org/debian-user-french/2003/12/msg01134.html" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">https://lists.debian.org/debian-user-french/2003/12/msg01134.html
et
https://lists.debian.org/debian-user-french/2003/12/msg01427.html" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">https://lists.debian.org/debian-user-french/2003/12/msg01427.html
(lire les deux fils). Nostalgie pour certains surement.

François Boisson

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
François Boisson
Le Thu, 18 Sep 2014 16:59:39 +0200
"Sylvain L. Sauvage" a écrit:

Le jeudi 18 septembre 2014, 16:06:28 Serge SMEESTERS a écrit :
>[… find /proc | sed | sh …]
> Et c'est curieux, alors que je cherchais à trouver les PID,
> elles ont finis par disparaître...
> Serions-nous à ce point surveillé :)

Ce qui serait bien avant d’exécuter (et d’« optimiser ») une
commande donnée, ce serait d’essayer de la comprendre et, aussi,
d’en comprendre les limites.

Techniquement, la commande de François (qui doit être exécutée
depuis /proc) :
— liste tous les fichiers cmdline (for + ls) ;
— récupère le pid et crée une commande ps avec celui-ci (sed) ;
— exécute ces commandes.



[..]

Déjà, effectivement, le seq n’est pas des plus rapides (c’est
même très très lent un seq). Le find est sans doute un peu
mieux. Un simple
cd /proc && ls -d [0-9]*
donne directement la liste des pids des processus en cours, sans
la lenteur d’un seq (ou d’un find).
D’ailleurs, on peut éviter le sed et le sh final :
cd /proc && ls -d [0-9]* | while read i; ps -p $i >/dev/null
|| echo $i ; done



Suckit utilise une technique créant un processus créant un processus caché
dans /proc n'apparaissant pas dans un ls ou un find mais existant.

En clair

ls /proc/123

donne que dalle
mais

ls /proc/123/cmdline

donne un résultat.
ps se base sur les processus apparaissant dans /proc. Donc un processus PID
tel que /proc/$PID/cmdline existe mais non montré par ps -p $PID est caché.
C'est le fonctionnement de Suckit. Le $(seq 1 65535) est donc indispensable.
Voir le paquet cacheproc sur mon dépot

deb http://boisson.homeip.net/depot wheezy divers

(wheezy, squeeze, etc jusqu'à sarge)
Suckit cache aussi les fichiers d'extensions .sk?? par exemple .sk12 (à
vérifier, c'est de mémoire)

Maintenant le fonctionnement de Suckit a peut être changer. Il existe d'autres
façons de cacher des processus.

En regardant mieux, il existe unhide qui liste les processus cachés.

François Boisson

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
Sylvain L. Sauvage
[ Je lis la liste. Pas la peine de me répondre directement et de
mettre la liste en CC. ]

Le jeudi 18 septembre 2014, 17:50:01 François Boisson a écrit :
[…]
En clair

ls /proc/123

donne que dalle
mais

ls /proc/123/cmdline

donne un résultat.
ps se base sur les processus apparaissant dans /proc. Donc un
processus PID tel que /proc/$PID/cmdline existe mais non
montré par ps -p $PID est caché. C'est le fonctionnement de
Suckit. Le $(seq 1 65535) est donc indispensable.



Ok. Je pensais que ps récupérait sa liste autrement qu†™en
lisant /proc.
Comme quoi, il faut vraiment essayer de comprendre ce qu’une
commande veut faire avant de la tripoter ;o)
(Mais bon, si elle était mieux expliquée quand elle est donnà ©e,
hein ;oP )

[…]
En regardant mieux, il existe unhide qui liste les processus
cachés.



Oui. Je n’ai pas regardé ton programme mais en regardant
unhide.rb (la version Ruby de unhide), il y a plusieurs listes
de processus vérifiées :
— ceux qui ont un répertoire dans /proc ;
— ceux qui sont listés comme parent d’un autre (da ns
/proc/*/status) ;
— les sous-threads (/proc/*/tasks/*) ;
— ceux listés par ps.

Et ceux qui ont un répertoire dans /proc peuvent être testà ©s
différemment :
— existe dans le répertoire /proc (readdir /proc) ;
— essayer d’ouvrir le répertoire (opendir et chdir sur
/proc/$i) ;
— essayer de lire dans le répertoire (readlink de
/proc/$i/exe) ;
(et il vérifie qu’on a la même chose quand on utili se bien le
readlink de la libc (pour éviter un LD_PRELOAD…))

Bref, il vérifie que tout un tas de chemins arrivent bien à
Rome.

--
Sylvain Sauvage

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
1 2