Journal Détection de rootkit

Posté par  .
Étiquettes : aucune
0
1
oct.
2007
J'ai des soupçons sur une machine compromise. A priori, le mieux serait de passer rootkit hunter dessus à partir d'un live cd, mais y a t il des distributions spécialisées ? Et qu'en est il des mises à jour de la base de signatures ? Si vous avez d'autres pistes, n'hésitez pas.

  • # chkrootkit et knoppix STD

    Posté par  . Évalué à 10.

    Salut,

    Tu peux essayer de booter sur une knoppix std (http://www.s-t-d.org/tools.html), cette distribution inclue plein d'outils de sécurité. Ensuite tu peux utilisez chkrootkit qui est un bon détecteur de rootkit.
    Mieux vaut monter la partition en ro ou fait un dd de la partition avant le chkrootkit pour ne pas perturber une éventuelle analyse 'forensics' par la suite.

  • # chkrootkit

    Posté par  (site web personnel) . Évalué à 3.

    plus simple qu'une distrib : chkrootkit. Tu le charges là : http://www.chkrootkit.org/ (ou sur un des miroirs) tu le dézippes dans un répertoire et tu lances la commande chkrootkit en tant que root. Il examine ton système et te dit si tu es rootkité ou pas.

    \_o<

    • [^] # Re: chkrootkit

      Posté par  . Évalué à 2.

      En fait, qu'est ce qui différencie chkrootkit de rkhunter ?

    • [^] # Re: chkrootkit

      Posté par  . Évalué à 7.

      Euh... c'est moi où les rootkits ce n'est plus ce que c'était ?
      Non, parce que, même connecté en root, si ton système est vraiment compromis, je ne vois pas comment un outil tournant par dessus pourrait être certain de quoi que ce soit !
      Ou bien je me trompe et il existe une magie permettant de faire cela ?

      • [^] # Re: chkrootkit

        Posté par  . Évalué à 2.

        oui, chkrootkit est compilé en static, dans l'archive tu as les sources et un binaire qui ne depends pas (trop ?) de ton envirronement.

        ceci dit vaut mieux un live cd quand meme

        • [^] # Re: chkrootkit

          Posté par  . Évalué à 10.

          Même en statique, il serait étonnant que le binaire ne fasse pas appel aux fonctions du noyau, tout de même...
          Or, sauf erreur, ça devrait déjà être suffisant pour le tromper.

  • # Share and enjoy

    Posté par  . Évalué à 5.

    D'où te viennent ces soupçons ? M'enfin, c'est juste histoire d'alimenter un peu ma paranoïa...

    • [^] # Re: Share and enjoy

      Posté par  (site web personnel) . Évalué à 3.

      Ne t'inquiète pas tant que ça - quand bien même tu ne serais pas parano - ça ne veut pas dire qu'ils ne sont pas déjà après toi :D

    • [^] # Re: Share and enjoy

      Posté par  . Évalué à 4.

      Station de travail qui ne tourne normalement avec aucun service vers l'extérieur. Je travaillais dessus quand le détecteur de processus fous de KDE m'a dit que netstat consommait trop de CPU. Bien sûr, je n'utilisais pas netstat à ce moment là. J'ai éteint la machine et je vais commencer l'autopsie demain.

      • [^] # Re: Share and enjoy

        Posté par  . Évalué à 2.

        c'est quoi ce detecteur de processus fou? Il faut activer une option?

        • [^] # Re: Share and enjoy

          Posté par  . Évalué à 2.

          clic droit sur la barre des taches KDE, puis le menu "ajouter une applet au tableau de bord".

      • [^] # Re: Share and enjoy

        Posté par  (site web personnel) . Évalué à 2.

        Si tu utilisais FF ou Seamonkey ou un de ses avatars, c'est peut-être normal, ils utilisent netstat pour récupérer dieu sait quelle info et ils laissent trainer des zombies dans tous les coins (les cochons !).

        • [^] # Re: Share and enjoy

          Posté par  . Évalué à 2.

          Ohh... T'aurais un pointeur vers ce comportement ? Parce que bon, dans l'hypothèse où j'aurais été rootkité, ça m'étonnait franchement qu'un programme aussi trivial que le détecteur de processus fous (qui doit juste être une surcouche de top ou d'un truc de ce style) le détecte.

          • [^] # Re: Share and enjoy

            Posté par  . Évalué à 2.

            Bon à en croire le changelog d'Iceweasel (http://packages.debian.org/changelogs/pool/main/i/iceweasel/(...) ), toute trace d'utilisation de netstat devrait avoir disparu d'Iceweasel. Mais vu comment il semble avoir été retors, la bonne nouvelle c'est qu'il pourrait encore survivre dans un coin du binaire.

            Mais bon, comme il est officiellement mort, l'hypothèse du rootkit tient toujours la route...

            Problème (ou bonheur), mes tests de rootkit sur la bécane n'ont pour l'instant rien révélé d'anormal. Peut être s'orienter vers un script qui loggerait au cas où le processus firefox-bin appellerait netstat....

            • [^] # Re: Share and enjoy

              Posté par  (site web personnel) . Évalué à 1.

              > Peut être s'orienter vers un script qui loggerait

              Ou alors utiliser SELinux (que tu peux parametrer avec Debian Etch, sarge dispo mais plus de manips) pour logger ce qu'il se passe. La page qui va bien : http://wiki.debian.org/SELinux/Setup

              • [^] # Re: Share and enjoy

                Posté par  (site web personnel) . Évalué à 2.

                Sinon si tu compiles ton petit noyau avec amour, tu peux aussi ajouter GRSEC (http://grsecurity.net) que j'ai tendance a utiliser pour des serveurs exposes.

                Le projet est actif mais avec un peu de retard sur les patches. Faut dire que le mec est tout seul.

                • [^] # Re: Share and enjoy

                  Posté par  . Évalué à 1.

                  grsecurity-2.1.11-2.6.22.9-200709280630.patch September 28 2007 17:57:54

                  kernel 2.6.22.9 2007-09-26 18:10 UTC
                  kernel 2.6.23-rc9-git1 2007-10-02 19:01 UTC

                  pas si en retard que ça.

                  Je recommande aussi ce projet

  • # Security LiveCD

    Posté par  . Évalué à 3.

    Security Live CD est un live-cd orienté sécurité, c'est un dérivé de la Fedora 7.
    http://fedoraproject.org/wiki/LukeMacken/SecurityLiveCD

  • # les trucs classiques

    Posté par  (site web personnel) . Évalué à 10.

    - regarder last, lastb, ~/.bash_history etc.
    - chercher des process modifiés (ps modifié, netstat modifié, strings modifié et c.)
    - chercher des process invisibles (comparaison de ps avec /proc/)
    - chercher des dossier ".." ou ". " ou " ." ou "..." etc ( genre find / -type d -name ".*" )
    - vérifier que lsmod ne liste pas de module suspect
    - passer chkrootkit sur la machine vérolée ... parfois ca marche
    - passer chkrootkit & autres détecteurs sur un live cd...

  • # Une seule solution

    Posté par  (site web personnel) . Évalué à 3.

    Doutes de compromission? Réinstallation!

    • [^] # Re: Une seule solution

      Posté par  (site web personnel, Mastodon) . Évalué à 10.

      > Doutes de compromission? Réinstallation!

      Inutile si c'est pour réinstaller à l'identique et permettre que ça recommence...

      Il est indispensable d'essayer de comprendre d'où provient cette éventuelle intrusion, et quelles conséquences elle aurait pu avoir (par ex. sur les autres machines du réseau local).

      Et n'oubliez pas : compromis, chose due !

  • # Heuu...

    Posté par  . Évalué à 10.

    Pourquoi mettre ça en première page ??
    Le forum aurai très bien été. Et, au pire, la seconde pas, si tu voulais une réponse rapide.

    Mais certainement pas en première page. La prochaine fois, fait une dépêche :p

  • # Tu es mal...

    Posté par  . Évalué à 9.

    Parce que dans le dernier Misc, je crois, ça parle de nouveau rootkit.

    Des rootkits qui installe ta machine dans une machine virtuelle.
    Bref, tu es dans ta machine, et tu ne peux pas voir ce qu'il se passe
    autour de toi .

    Il y bien des solutions, vérifier les adresses mémoires retourné
    pour certaines adresse connue et courante, mais bon, les
    méchants rootkit peuvent te répondre ce que tu veux entendre !

    Tu peux verifier la place qu'il te reste exactement sur ton disque, etc...
    Mais encore une fois, le mechant rootkit qui dirige ta machine
    te repond ce que tu veux entendre !


    En fait, le seul moyen d'etre sur de la presence ou pas d'un rootkit,
    c'est d'installer Windows et d'ecouter un CD de musique de chez
    SonyMusic. La tu sera sur d'avoir un rootkit :)

    • [^] # Re: Tu es mal...

      Posté par  . Évalué à -1.

      Ah vi, et apparemment, même les liveCD ne sont pas épargné.

    • [^] # Re: Tu es mal...

      Posté par  . Évalué à 6.

      SonyMusic sapusépalibre. En plus, y a pas de version pour gnoulinusque !
      Installons plutôt un vrai GNU-Rootkit libre et multiplateforme... pourquoi pas emacs ?
      (ça te prend de la mémoire, ça te fait croire que tu es dans un OS, alors qu'il y a tout un système qui tourne autour... non vraiment, y a pas photo !)

    • [^] # Re: Tu es mal...

      Posté par  . Évalué à 7.

      En fait il y a un(des) moyen de detecter des VM rootkit : noter le nombre de cycles que mettent certaines instructions pour s'executer(une VM doit intercepter certaines instructions et les traiter specialement, et ca rajoute un tas de cycles) et comparer avec ce qui devrait etre le cas sans VM.

      Bien sur un VM rootkit peut essayer de deviner si c'est ce que tu es en train de faire, mais en codant ton truc bien comme il faut (pas un simple loop qui prend la valeur x fois), tu y arrives sans probleme.

    • [^] # Re: Tu es mal...

      Posté par  (site web personnel) . Évalué à 4.

      Mais non, il doit installer Oracle Matrix Edition, et ensuite, il va réussir à trouver Neo si il s'habille avec une combi en latex moulante.

    • [^] # Re: Tu es mal...

      Posté par  . Évalué à 4.

      L'article de MISC est sympa, fait peur, toussa.
      Mais bon d'après ce que j'ai compris pour l'instant ces rootkit new gen restent à un stade très expérimental.

      De plus si ton cpu n'a pas de capacité de virtualisation, ça veut dire que ton os rootkité tourne dans une vm logicielle et là c'est plus facile à tester.

    • [^] # Re: Tu es mal...

      Posté par  . Évalué à 4.

      En fait le rootkit ultime c'est la matrice, un peu.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.