Annonce

Réduire
Aucune annonce.

Démarrage RAT / rootkit sur Linux

Réduire
X
  • Filtre
  • Heure
  • Afficher
Tout nettoyer
nouveaux messages

  • Démarrage RAT / rootkit sur Linux

    Bonjour,

    J'avais partagé un script permettant de prendre le contrôle à distance d'une distribution Desktop Ubuntu, Mint ou Debian avec une bonne probabilité de devenir root, sur une autre section de ce forum. J'avais mis le projet de coté faute de temps et de motivation. Un reste de perfectionisme me démangeant, je continue à travailler sur ma version bash de temps en temps pour arriver à en faire une version plus légère et aboutie en corrigeant les défauts constatés au fur et à mesure. A défaut de finir un truc "toutes options", je voulais finir un truc parfaitement fonctionnel voire modulable.

    J'appellerai ce script rootkit même si j'hésite avec l'appellation RAT, car son objectif reste tout de même de fournir et de maintenir un accès root via une backdoor à un attaquant à distance en réduisant au mieux sa "surface de détection" même si sa furtivité n'a évidemment rien à voir avec celle des rootkits en ring 0.

    Je suis assez proche d'une version que je pourrais considérer comme finie. J'ai pu retiré 25% de lignes de code et une partie d'options inutiles pour le script lui-même (qui sont devenues des options conservées et exécutées à distance et non plus contenues dans le script lui-même). La charge processeur a chuté drastiquement, ce qui rend enfin son fonctionnement peu notable voire carrément non significatif de ce coté là lorsqu'il "veille". Mon but lors de son écriture n'était pas d'en faire un outil d'accés permanent à un ordinateur cible, mais d'en faire un outil le plus furtif possible avec les contraintes de l'environnement et celles de mes compétences. Donc améliorer son indétectabilité au détriment de l'accessibilité à la cible, autrement dit favoriser la durée d'accés sur son imédiateté.

    Il passe sans souci les scans de rkhunter et chkrootkit puisqu'il fonctionne en ring 3 et l'analyse de ports en écoute ne donne rien puisqu'il n'en ouvre pas lorsqu'il veille. Il reste cependant un point que je souhaiterais fignoler concernant sa furtivité -relative- mais furtivité quand même sur une version bureau : c'est son mode de démarrage.

    Pour le moment, il utilise crontab, ce qui lui permet de s'installer sur toutes les distributions vulnérables. En revanche, je trouve crontab pas très "furtif". Je pensais ajouter cette dernière option : en fonction de la version Linux, soit créer un service "user" via /etc/systemd, ou via /etc/rc.local pour les versions antérieures.

    Q'en pensez-vous ? Je me base sur mon propre fonctionnement pour en déduire ces améliorations : j'irais plus facilement jeter un oeil sur crontab pour voir s'il y a un truc pas catholique que dans les services ou /etc/rc.local (que je n'ai personnellement plus). De plus, un utilisateur "lambda" sera plus à même d'aller bidouiller dans crontab pour faire démarrer des nouvelles applications que dans les services. Il suffit cependant de juste faire un "crontab -l" pour avoir accès à la ligne de démarrage du rootkit, ce qui rend sa détection statistiquement plus probable, alors que pour les services, c'est un poil plus compliqué et demande plus de compétences.

    J'essaie de paufiner le truc mais je suis bien conscient qu'un rootkit en ring 3, ça reste quelque chose de facilement détectable pour qui a les connaissances. Ceci dit, il a été conçu pour des distributions bureau et non pas serveurs, ce qui fait quand même une grosse différence (par exemple, des outils de sécurité comme apparmor ou grsecurity nempêche absolument pas ce rootkit de s'installer et de fonctionner, ce qui sera beaucoup plus délicat avec des rootkits en ring 0). Le but étant donc de réduire au maximum tous les signes à bas bruit de sa présence qui pourrait déclancher "sa chasse" et donc sa détection.

    Vos points de vue sont donc les bienvenus !
    Dernière modification par acloseone, 20 juillet 2018, 11h59.

  • #2
    Re-bonjour,

    Entre temps, j'en ai profité pour définir une solution donc je partage, si ça intéresse. Une fois que le premier script devient root, il installe un second script (qui contient environ 25% du premier auquel j'ai simplement retiré la partie nécessaire pour obtenir l'accès root, devenue inutile) puis il créé un service dans /etc/systemd/system pour le lancer automatiquement en root. Ca permet également de supprimer le premier script ainsi que son entrée de démarrage dans crontab. Ca permet au passage d'éliminer plusieurs problèmes : les anthentifications enregistrées dans /var/log/auth.log, les fichiers douteux dans le /home/utilisateur/ et l'entrée dans le crontab utilisateur.
    Dernière modification par acloseone, 07 novembre 2018, 15h17.

    Commentaire


    • #3
      Alors, j'ai essayé un peu de comprendre mais le premier problème est que la décompression de l'archive téléchargeable ici demande un mot de passe. Ce serait plus simple de le donner, non ?

      Ensuite, j'ai une suggestion à te faire : pourquoi ne pas publier ton code en clair avec toutes les explications qui vont bien ? Ce serait un gain de temps pour comprendre ton travail et cela te permettrait de poser tes idées de façon formelle. Ce dernier point a l'avantage de fortifier ton code (détection de bugs, d'incohérences, etc.) car en expliquant aux autres, on se contraint à mieux analyser ce qu'on fait soi-même.

      Commentaire


      • #4
        Alors oui, j'ai fait quelques modifs :

        1) Je me suis rendu compte que je sortais du cadre légal en publiant ce genre de choses. Et comme je n'ai pas une grande confiance dans la "justice" française, j'ai préféré revoir ma copie.

        2) Quand je l'ai publié, j'avais annoté l'ensemble des parties du script pour qu'il soit plus facilement lisible (il est peut-être un peu chiadé à lire mais ce n'est pas forcément facile à mesurer lorsqu'on l'a écrit soi-même), puis en le publiant sur divers forums de hacking et en analysant la population de ces divers forums, j'ai aussi décidé de le retirer : j'ai eu, comme qui dirait... un doute !

        3) Au départ, l'archive chiffrée (le prototype) ne devait pas être publiée. Je souhaitais le stocker et passer à autre chose jusqu'au jour où... je me serais décidé à en faire quelque chose, puis j'ai changé d'avis et j'ai décidé de publier une version plus avancée, avant de me rendre compte que... ce n'était pas non plus une bonne idée.

        PS : je vais probablement faire avancer le script de détection de démarrage (cf. plus haut), car je pense qu'il y a encore pas mal d'autres possibilités, dont insérer une ligne de code dans un des scripts système... mais il faut que je fouille encore un peu.
        Dernière modification par acloseone, 31 juillet 2018, 00h42.

        Commentaire


        • #5
          Bonjour,

          Ca faisait un petit bout de temps que je n'avais pas vraiment participé, mais je passe aux nouvelles.

          Je n'ai pas pu avancer sur des projets Windows (un projet pro m'a pas mal accaparé, et ça va continuer encore quelques temps). Cependant, j'ai pu faire encore avancer mon "machin" de prise de contrôle d'une distribution Linux. Finalement, j'ai bien trouvé une astuce pour qu'il soit persistant sans utiliser crontab ou les services... La solution n'est pas parfaite, mais elle a le mérite de fonctionner parfaitement, d'être plutôt furtive, et de ne pas forcément être attendu au tournant. Et ça marche même si je conserve le script en ring 3 sans utiliser d'autres outils lancés en root en tant que services.

          Du coup, j'en arrive à un point que je n'aurais pas imaginer en commençant le prototype : ça devient efficace. Ca commence à être vraiment furtif sur une distribution de bureau et pour un truc en ring 3. De plus, j'ai des pistes sérieuses pour les points restants : passer à travers les logs système et les programmes de gestion de fichiers. A ce moment là, je pense que j'aurais atteint plus ou moins la limite de que je pourrais faire en ring 3 (même s'il y a toujours de quoi faire, mais on va dire que sur un diagramme de pareto, le script serait dans la case "abus de perfectionnisme"), et si je devais faire mieux, ce serait en recommençant tout, mais en ring 0 (ce qui n'arrivera pas, je n'aurais pas que ça à faire, et ici, c'est plus que je me suis pris au jeu qu'autre chose).

          J'ai aussi revu ma "politique de divulgation" si je puis dire : je vais conserver tout ça archivé tant que c'est fonctionnel. J'essayerais de faire un gros tutoriel sur comment ça marche, ou un truc dans le genre, lorsque je déciderais de rendre tout ça public comme "outil pédagogique" (bon, ça vaut ce que ça vaut, mais ça peut toujours intéressé des personnes de voir comment ça fonctionne). Et de toutes façons, j'ai déjà commencé à mettre chaque version sur Github (en gist privé), ça sera donc disponible dans "l'état du moment t", le moment venu.

          Commentaire

          Chargement...
          X