Toute procédure d'accès à un service via login/pass, offre une sorte de "double sécurité" un utilisateur ayant un login valide, sans le pass, est bloqué. Il en va de même pour un utilisateur ayant un pass, sans login qui va avec, ce qui est quand même plus rare ;-). Dans le cas où un utilisateur a un login, sans pass, il peut se mettre à la recherche d'un pass. Le login est à la base de toutes attaque sur un service. Etudions comment on peut fragiliser cette procédure sur un système cible.

La gestion du système login/pass, lorsqu'un utilisateur essaye de se connecter varie selon 3 facteurs :

- le service

- le type de serveur

- le système d'exploitation, mais c'est plus rare. Nous allons voir ça après.

Nous n'allons pas voir quels serveur gèrent quoi et comment, cela prendrait trop de temps et ce n'est pas l'objet de l'article. Nous allons voir quels sont les différents cas de gestions des saisies logins/passes.

Ce système est efficace sur de nombreux serveurs, et de nom-breux services. Sur les systèmes M$ par exemple, c'est une tech-nique qui marche bien. Mais aussi sur d'autres nombreux systèmes UNIX, etc... Tout dépend de la configuration de la cible. Le but est simple : il consiste à essayer une série de pass, sur un login précis. Bien sur la possession d'un login valide est nécessaire. Nous verrons ultérieurement comment se pratique la devination de logins. En tout cas, ce système est efficace dans certains cas précis. Par exemple en cherchant un mot de passe de quatre ou cinq lettres, ce système peut être pratique. Par contre ne comptez pas sur lui pour un mot de passe de huit lettres. En revanche le brute-force ne se fait pas que sur le modèle : 1 login - n pass à tester. Il peut aussi se faire sur le modèle : n logins - 1 pass. Ce dernier modèle est utile si vous avez réussi à avoir une liste de logins, et que vous cherchez le compte d'un utilisateur qui aurait mis un password bidon du genre "passwd", "password", même rien, sur certains services, etc...

Ce système pourrait s'appeler "système d'identification à un seul niveau". En effet dans certains cas (routeurs par exemple), le système cible ne demande qu'un seul moyen de s'authentifier, soit au travers d'un login ("Enter the login :") qui joue le rôle de pass, soit au niveau d'un password ("Enter a password :"). Cela revient de toutes façons strictement à la même chose. En général ces systèmes garantissent au pirate que une fois le pass trouvé, il a accès directement à la gestion du service avec des droits d'administrateur. De plus c'est un faible niveau d'authentification, et donc de faible sécurité, surtout si le principe est brute-forçable. Pour que le problème soit bien explicite, sachez que l'exemple suivant est véridique :

- sur 10 systèmes d'une même entreprise, tous les systèmes étaient à niveau d'authentification unique, tous étaient brute-for-çables, et sur à peu près 4 des 10 systèmes, l'accès se faisaient uniquement par le mot de passe "admin" (très facilement devinable). Ainsi, 4 des 10 systèmes étaient piratables sans aucune difficulté, et tous les autres étaient brute-forçables.

La simplification des accès, par contrainte de temps et de confort, désagrège littéralement la sécurité des entreprises. De plus, par exemple, sous Windows, l'accès à des répertoires en partage ne se fait que par mot de passe. On est donc loin d'un système idéal de sécurité chez M$.

Ce système est redoutablement efficace, si il se base sur un système qui exige login + pass. Sinon il ne le sera qu'à moitié. Comme son nom l'indique, il consiste à laisser un temps prédéfini à l'utilisateur essayant de se connecter pour saisir les don-nées, après quoi il se fait déconnecter et l'oblige à se reconnecter pour recommencer des saisies. Ce système empêche des techniques de brutes-force simples, mais ne les bloque pas (avec des logiciels de brute-force plus développés qui se reconnecteraient automatiquement, le processus ne serait que ralenti). J'ai personnellement déjà vu des systèmes n'appliquant aucun timeout sur les saisies, et avec la procédure d'authentification à un niveau unique. Je vous raconte pas la joie des brutes-forcers. De plus cela faci-lite les attaques par DoS (imaginez un afflux permanents d'utilisateurs ne se déconnectant jamais, il risque d'y avoir problème un moment donné). A croire que des singes envahissent les bureaux et appuient n'importe comment sur les claviers quand les admins ont le dos tourné :).

D'autres systèmes, soucieux d'enrayer les attaques par brute-force, et sans appliquer de déconnections sur timeout (pas un timeout court en tout cas), gèrent astucieusement le système login/pass. En effet, si vous entrez un mauvais login/pass, le système mettra à chaque fois un peu plus de temps à vous reproposer de saisir les données. Cela est radical contre les brute-forcers : le système n'impose aucune limite de tentatives, aucun timeout, et à la fin les attentes pour avoir "la main", et pouvoir saisir les données sont exagérément longues, ce qui finit par rendre impossible toute attaque par brute-force. Je pense que ce système est bien plus efficace que tous les autres existants.

Je dis classique, mais en fait c'est loin d'être un classique. Ce système concerne les systèmes qui vous déconnectent dès que vous avez dépassé un nombre limité d'essais (3 ou 5 en géné-rals), sur un principe d'authentification à login + pass. Bien sur après le choix du login et du mot de passe influe énormément sur tout ce qui touche à l'accès au service par un pirate. Comme vu précédemment, celà n'empêche pas une attaque par brute-force.

Un système administré par une limite de 3 essais par mots de passe avec un timeout. En fait ce n'est pas le meilleur système, mais l'un des plus courant avec ce qui se fait de nos jours.

Je l'appelle "bidon" parce qu'il n'existe pas vraiment d'autres termes le concernant. Ce système aide les pirates sur la devination de logins. En effet le système d'authentification s'éta-blit bien à deux niveaux, mais le niveau où l'utilisateur doit saisir un login ne sert que de formalité. En effet, si vous entrez un mauvais login, il vous retournera une réponse type "mauvais login, réentrez un login" sans vous demander de pass. Quand le login est bon, il vous demande un pass. Ainsi éta-blir une liste de logins effectifs sur ce type de système relève d'un jeu d'enfant. Comment ça? Qui a dit : "ça existe po c'machin là" ? Si, si ! Je vous jure !

Nous pouvons voir que la fragilisation de ce processus concernant le login/pass peut déjà s'effectuer après étude du moyen d'authentification qu'impose la machine distante. Par FTP, le principe est toujours login + pass, avec des possibilités de brute-force ou de timeout selon les serveurs. Par HTTP, cela dépend de la manière dont sont configurés les scripts et accès de sécurités au répertoires. Etudier une manière dont un serveur est censé vous authentifier ne prend pas plus d'une minute ! Si cela vous prend plus de temps, choisissez : la corde ou le pistolet ? Après, il est nécessaire d'établir un ou plusieurs logins sur lesquels vous allez travailler. Avant de commencer toutes recherches, sachez que bien souvent des logins par défaut comme "admin" ou "root" pour des systèmes Linux, sont à essayer. de plus on a souvent d'autres logins comme : "Guest", "Administrator", "FTPadmin", etc. qui ne sont que de faibles dérivés de logins classiques. Voyons cependant, comment un pirate peut collecter les informations nécessaires à une attaque.

L'astuce est simple. Par exemple vous cherchez un accès à une boite d'administrateur sur un service mail, sans toute-fois connaître le login exact de la personne. En ayant juste son pseudo ou son nom & prénom, vous pouvez faire des essais mais le problème est que le service vous retournera des erreurs du genre : "Erreur : login ou mot de passe incorrect(s)". L'idée est de voir si il vous est possible de créer un comp-te sur ce service, et si oui, essayez de créer un compte avec des tests de logins qui pourraient être celui de la per-sonne visée. Vous essayez jusqu'à ce que le service marmonne quelquechose du genre : "Erreur : compte déjà existant pour ce login". Vous avez surement obtenu le login voulu. Vous n'avez plus qu'à vous concentrer sur le mot de passe, et même plus. Avec ce login vous pouvez envoyer des e-mails au compte, rechercher si il y a eut des échos sur les NewsGroups, essayer du Social Engineering (vous savez ce qui marche fort dans le SE ? C'est de se amener direc-tement à la boite qui gère les comptes pour demander le mot de passe, style "ingénu de l'informatique" qui sait pas qu'on peut faire une demande par mail, ou bien qui trouve n'importe quelle bonne excuse).

No comments. Ou : Hé stoplait le pimpim, passe moi tes logins password ! avec 12.000 variantes plus subtiles.

Parfois des machines d'entreprises font tourner des services SNMP sur leur machines. Sans nous étendre sur les spécifica- tions techniques du protocole, sachez que si le service est confi-guré "public" (community string = public), alors une foule d'informations est accessible par tous ! Et quand je dis une foule, c'est vraiment tout ! Des services logiciels à la configura-tion HardWare, en passant par tout ce qui est config réseau. En plus les machines sous NT diffusent (si il y a partage) les réper-toires mis en partage, et les logins utilisés (accounts). En fait c'est simple. Si SNMP tourne en "public" sur une machine dans une entreprise, c'est le coffre aux trésors des Pirates. Par contre si le service est configuré "private", vous n'aurez accès à rien.

Pour les machines sous windows faisant tourner un service Net-BIOS, le traditionnel "nbtstat -A host" vous révélera le nom de la machine, et avec un peu de chance, un nom de login.

Les services Whois (whois.org, register.com, etc.) fournissent foules d'informations sur les hosts enregistrés. Souvent on a des noms et prénoms qui peuvent fournir des idées à des logins. De plus les adresses fournies et différents moyens de contacts se prêtent fort à des attaques de SE.

cf 2.f

Ce sont des outils à ligne de commandes qui consultent les identifiants de sécurité NT (NT SID) à la recherche du nom d'utilisateur et vice-versa. Ils ne sont pas durs à trouver en téléchargement. Dès que le SID d'un host a été pris, grâce à "user2sid", les attaquants peuvent utiliser des numéros de SID connus pour retrouver les utilisateurs correspondants.

Finger peut fournir des informations comme la liste des uti-lisateurs connectés. Il en va de même pour rwho et rusers. Les lignes de commandes sont simples : "finger -l @host" ou "finger 0@192.168.202.34". Pour rwho, pareil : "rwho host", et pour rusers il est conseillé de mettre le commutateur '-l',"rusers -l host"

Grâce à des dispositifs de sécurité sortis tout droit des poubelles de McDonald, il est parfois possible, vous le savez, d'accéder au fichier etc/passwd d'un host FTP, en anonymous. Cette récupération joue un grand rôle dans la prédiction de login. Voyons par exemple un bout de etc/passwd récupéré sur ftp://ftp.cible.com

aidle:x:1009:102::/home/web/aidle:/bin/false

colyseum:x:1010:102::/home/web/colyseum:/bin/false

colysee:x:1011:102::/home/web/colysee:/bin/false

piou:x:1013:102::/home/web/piou:/bin/false

stef:x:1015:102::/home/web/stef:/bin/false

justice:x:1016:102::/home/web/justice:/bin/false

Plein de logins ça non? En fait c'est que des logins en début de ligne. De plus l'exploitation de failles dans les scripts cgi, ou autres, peuvent se montrer très utiles pour accéder à des listes de logins.

SMTP comprend deux commandes intégrées qui permettent le recensement des utilisateurs. "VRFY" confirme les noms d'utilisateurs valides, et "EXPN" signale les adresses effectives des alias et des listes de publipostage.

Ces informations sont précieuses aux pirates. De plus "EXPN" peut servir à la vérification de logins, le reste à d'éventuelles attaques de SE... par anonymous mail justement ;-).

Il en existe bien d'autres problèmes concernant les logins, relatifs à des services particuliers, des serveurs particuliers. Pour l'instant nous nous sommes intéressés à tout ce qui concernait la fragilisation des procédures d'authentification par login/pass en se concentrant sur l'aspect du login. Qu'en est-il du pass?

En réalité une collecte d'informations sur un éventuel password est loin d'être chose évidente. Voyons comment un pirate peut trouver un password.

Connue, l'attaque du brute-force permet de s'attaquer à un login en particulier en essayant une succession de mots de passes. Ou bien le contraire, comme vu en 2.a. Ce genre d'attaque s'effectue bien souvent par des programmes téléchargeables sur Internet.

Sans s'éterniser, n'oubliez pas qu'une attaque par Social Engineering ne se réalise par que par téléphone ou mail.

A vous de voir pour d'autres procédés. Il existe aussi les formulaires, technique lame, qui est cependant une forme

sous-aboutie du SE.

Les mots de passes classique du genre "admin", "1234", etc. sont encore utilisés sur de nombreux systèmes, comme vu dans l'exemple 2.b., et les noms prénoms ne sont pas à exclure. Les classiques ne sont à essayer que si vous n'avez pas de moyen de brute-forcer la cible.

La récupération contenant les fichiers de mots de passe (comme les fichiers de configuration de certains clients FTP), constitue un risque majeur pour une entreprise. Si les pirates peuvent s'emparer de ce genre de fichiers, un changement complet des mots de passe sera nécessaire. Ensui-te il faudra envisager de changer d'administrateur réseau, mais ça, c'est une autre histoire. Ces récupérations peuvent se faire par des trojans, des exploits, etc. Et même en local.

Les exploits peuvent permettre de contourner les passwords. Les exploits sont liés généralement au serveur ou à l'OS de la machine cible.

Le meilleur moyen de comprendre le principe est de fournir un exemple, qui peut arriver à un particulier. Dupont a un compte mail. Pour x raisons, Haxor prend possession de sa boite mail. Dupont qui est prudent n'a pas mis les mêmes passes pour sa boite mail, son compte ICQ, et son compte FTP. Cependant Haxor, hystérique et psychopathe, décide de se faire envoyer les pass du compte FTP et du compte ICQ de Dupont. Il change les passes des 3 services et attend la déconnection de Dupont pour se mettre à agir. Ainsi Dupont, dans son sommeil agité, car il vient de se faire pirater ne l'oublions pas, se fait en fait avoir. Haxor utilise tous ses comptes pour accéder aux autres comptes de ses collègues, grâce à la relation de confiance que Dupont a éta-blie avec eux.

Avec l'étude des techniques concernant les passwords, on aura fait le tour de la question concernant les moyens de fragiliser une procédure d'identification à double niveau. Merci de votre attention, et j'espère que, même si ce texte ne vous a rien appris, il vous aura permis de faire le point sur ce qui se faisait concernant cet aspect du piratage.