Annonce

Réduire
Aucune annonce.

Pour aller plus loin : Linux Rootkit

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

  • Pour aller plus loin : Linux Rootkit

    Bonjour,

    Bon, je pensais en avoir fini avec mon bidule sur Linux, mais je me rends compte que lorsque l'on a fini, on a envie d'aller plus loin pour voir ce qu'on peut encore faire pour parfaire le machin. Je ne vais pas revenir sur mon truc en bash pour devenir root sur Linux, je l'ai tellement paufiné et poli qu'il me faut des lunettes de soleil pour le regarder, obsessionnel compulsif que je suis (devenu) avec ces histoires de cybersécurité. Je commence même à voir des chats en double dans les escaliers, et Trinity qui me dit "penses-tu que c'était le même chat ?". Bref, passons... Je pense être arrivé à un point où j'aurais du mal à encore l'améliorer avec un bon ratio efficacité / lignes de code / ressources système / temps d'écriture.

    C'est marrant, il y a un point que j'ignorais jusqu'à présent, c'est le nombre de possibilités d'améliorer qui s'offrent au fur et à mesure qu'on fignole un truc. Ca devient exponentiel. C'est probablement ce qui fait que je n'ai pas laché le truc et que je continue à y réfléchir. Là, je suis en train de bricoler sur une interface attaquant en php, afin de pouvoir piloter un ordinateur cible depuis le navigateur Tor (TBB) avec un système d'incrémentation d'identifiant "victime" pour infecter et piloter séparemment plusieurs machines cibles. Je suppose que penser prendre le contrôle d'un ordinateur cible, c'est bien, le piloter sans laisser de trace, c'est encore mieux, donc arriver sur l'interface de pilotage depuis Tor en https (peu importe ce qu'on y met avant) ou un équivalent, me parait bien pour la furtivité de l'attaquant. Bref, ça devient n'importe quoi, je vais songer à aller voir mon médecin.

    Bon, beaucoup de blabla, voici les choses sérieuses. Plus globalement, j'envisage du coup d'aller plus loin et d'insérer ce premier script dans un vrai rootkit, soit un ensemble de programmes pour augmenter la propre furtivité de l'ensemble tout en maintenant un accés root (toujours en restant sur des machines de bureau). Je suis donc sur deux possibilités pour ça : le hook sur les librairies (donc en usermode) ou le hook via une LKM (donc en mode kernel).

    Voici mes points d'entrée, afin de me lancer et d'approfondir :

    http://turbochaos.blogspot.com/2013/...01-1-of-3.html
    https://ketansingh.net/overview-on-l...land-rootkits/
    https://0x00sec.org/t/hiding-with-a-linux-rootkit/4532
    https://github.com/jordan9001/superh...er/superhide.c

    Je ne suis pas sûr du meilleur compromis. Si j'ai bien saisi, par les librairies, on est quasiment sûr de pondre quelque chose de fonctionnel, et non dépendant de la version du kernel, que ce dernier soit en 32 ou 64 bits ? En d'autres termes, la portabilité entre distributions est plus grande qu'avec un LKM écrit pour certaines versions de noyaux et donc non fonctionnel sur d'autres ?

    Vos points de vue seront les bienvenus ! Merci d'avance !

  • #2
    Je prend le projet en cours à vrai dire, je le découvre même.
    Congrats pour le dur labeur de ton projet, mes connaissances en dev sont tellement limité que je viens de comprendre après plusieurs relectures ce que tu voulais faire.

    J'ai surtout retenu "devenir root sur linux", moi qui sort d'une privesc sur HTB bien tordue, j'aimerai bien en savoir plus sur ton prg.

    Après de mon point de vue de grand dev , j'aurai tendance à dire que pour ton projet, pour quelqu'un pour moi qui voudrait utiliser ton "rootkit" sur les machines que j'essaye de privesc, les librairies me semblent plus pratiques car non dépendantes de la version du kernel. (Si je dis une bêtise, ne pas hésiter à me le dire).

    Voila ma petite contribution à ton idée.

    F0ngic

    Commentaire


    • #3
      Merci pour ton message et ton point de vue.

      Moi aussi, mes connaissances en développement sont limitées à ce que j'ai pu faire jusque là (donc pas grand chose).

      Au départ, ce script devait se suffir à lui-même, et je pensais passer sur un autre sujet ensuite (qui n'a rien à voir avec l'informatique), mais comme je suis finalement sur les deux en parrallèle, ce premier projet continue à suivre son bonhomme de chemin. Et si je veux faire ça mieux, je dois alors considérer ce premier script non plus comme une fin en soi mais comme une pièce d'un ensemble plus grand. Celui-ci servant à devenir root, pour ensuite laisser sa place pour installer d'autres outils.

      J'ai donc commencé un second script qui doit fonctionner cette fois directement en root et non plus en mode user, et qui n'a donc que la fonction de backdoor et de keylogger, pour exécuter des commandes root à distance. Ceci aussi afin de protéger le premier script qui a vocation à être détruit une fois qu'il a fait son boulot pour éviter sa détection et sa récupération. Pour accompagner ce second script moins "stratégique", il faudrait des outils de furtivité pour faire ça bien, donc soit un LKM, mais ils semblent être très dépendants de la version du noyau, soit en hookant les librairies. Même si cette dernière possibilité est moins puissante, elle me semble à première vue être meilleure. Cet ensemble d'outils n'aurait pas vocation à pirater le président de la république ou les serveurs de l'Elysées, mais de faire aboutir à un truc cohérent et efficace sur une distribution de bureau. En gros, la cible hypothétique de ce truc serait la majorité des utilisateurs des distributions Linux "grand public", y compris ceux qui ont de bonnes connaissances en sécurité informatique, en laissant en dehors du modèle les pro ou assimilés. C'est simplement un projet intellectuel, pas un outil pour la CIA.

      C'est comme un jeu d'échec ou l'on joue des deux cotés en même temps en essayant d'être le meilleur de chaque coté. J'ajoue que le fin du fin serait de finir un ensemble parfaitement fonctionnel et de le tester in vivo.

      1) exploit pour pénétrer l'ordinateur
      2) exploit pour devenir root
      3) outils de contrôle à distance
      4) outils de furtivité pour rester indétecté sur l'ordinateur cible
      5) contrôle à distance non pistable

      J'ai les points 2, 3 et 5, ces deux derniers restant à fignoler. Il me reste donc le 4ème point à étudier et à mettre en place avant de finir un système fonctionnel et efficace. Le premier point étant évidemment le plus difficile, et de très très loin. Après, je ne me suis pas encore vraiment penché dessus donc ça peut occasionner des surprises. Mais je me doute que les méthodes conventionnelles efficaces sont à oublier (failles navigateur ou applicatives), sauf à tomber sur un exploit "grand public" dont une cible n'a pas encore fait le correctif ou a laisser trainé une porte plus fragile que les autres (comme Flash). S'il y a quelque chose à trouver, ça sera plus probablement du coté des méthodes de magiciens : le détournement d'attention et le social engineering.

      Un système informatique, ça ne se borde pas aux composants électroniques, aux données qui y sont traitées et aux boitiers qui contiennent tout ça. Ce sont aussi les utilisateurs. On peut balancer à tour de bras que la faille est souvent entre le clavier et la chaise pour dire qu'un système est sécurié, il n'empêche qu'un système informatique n'existe pas sans utilisateur entre un clavier et une chaise, et que personne n'est à l'abris d'une erreur. Juste personne. Donc considérer un système informatique sans considérer l'utilisateur pour prétendre que celui-ci est inviolable (le système informatique, pas l'utilisateur), c'est un non-sens qui ne vise qu'à vendre ou à vanter le système en question car ce système ne fonctionne pas pour lui-même. C'est comparer du théorique hors sol et de la pratique. Le jour ou un système informatique sera self-conscient et sera capable de déterminer avec précision si ce qu'un utilisateur lui balance est toxique ou pas pour lui, ce point sera discutable. Les antivirus et autres sont le prototype et l'IA en est l'horizon. Mais on n'en est pas encore là.

      Donc si j'arrive aussi loin (finir un ensemble cohérent) sans passer à un autre sujet (ça arrive), je me pencherais sur le premier point et j'essayerais de trouver des volontaires pour essayer de les pirater. Qu'on le veuille ou non, et c'est pour ça que j'ai un point de vue mitigé sur le "hacking grey", rien ne vaut les conditions réelles. Et le bon compromis, c'est de trouver des volontaires de confiance pour jouer le jeu. Par exemple, avec des règles du genre : 6 mois pour pirater et contrôler l'ordinateur d'un ou plusieurs des volontaires, avec prise de contrôle sans détection sur 1 mois, sans destruction ou vol de données évidemment (vol, ça veut aussi dire indiscrétion).

      Je sais, ça peut sembler bizarre comme jeu ou défi, mais c'est avec des trucs bizarres qu'on s'enrichit, pas en reproduisant des schémas sociaux normatifs ou normés dont on connait déjà le résultat.
      Dernière modification par acloseone, 02 septembre 2018, 12h58.

      Commentaire

      Chargement...
      X