Elle est assez exhaustive, néanmoins l’archive contient en plus un script (Perl)  qui vous permettra de mettre à jour ces deux fichiers dans le temps.

Bonne rentrée !

Si vous souhaitez en réutiliser certaines, voici à titre d’information les termes de droits qui s’y attachent.

US : The owner remains in control of Copyright for images they post here.
Additionally, the owner of Copyright gives Copyright control to us for the purposes of letting other people view and dowload copies when the owner publishes content to this publicly accessible photo system on the web.
(It seem that this would be obvious to anyone publishing images on a site that has a web server designed to serve those images to the public, but not all people are intelligent enough to figure that out.)

FR : Le propriétaire conserve le controle des Droits sur les images postées [sur Defcon].

De plus, le propriétaire des droits confère le contrôle de ces droits [à Defcon] dans le but de permettre aux autres personnes de voir et télécharger des copies lorsque le propriétaire publie du contenu sur ce système de publication d’images sur le Web.

(il semble que ceci soit évident pour toute personne publiant des images sur un site ayant un serveur Web destiné à fournir des images au public, mais tout le monde n’est pas assez intelligent pour s’en rendre compte.)

1- 18 & Legal

“If Def Con was a girl.”

Design by Mar. Photo reference by Jody.

(JPEG 701.7kb , 1920 x 1200)

2- Her

“Love at first . A Photoshop compilation.”

Design by emtag.

(JPEG 412kb , 1920 x 1200)

3- DEF CON Boy

“A desktop wallpaper for DEF CON 18.”

Design by Oshu.

(PNG 464kb , 1920 x 1200)

4- Face of Hacking

“This piece is a piece that comments on the social engineered aspect of hacking. It is to say that hackers can be anyone or use anything.
There is no one face of hacking, and in that sense that is what makes it great.”

Design by Kristale Dominguez.

(JPEG 1016kb , 1920 x 1200)

5- Freedom

“My interpretation of the free software movement and the Defcon logo together.”

Design by Shadowbrain.

(PNG 1570kb , 1920 x 1200)

6- Natural Selection

“Technology is becoming so seamlessly integrated in to our every day lives that most people hardly know their dependance on it.
And in the end, only the fittest will survive. That’s why I attend Defcon — A Photoshop compilation.”

Design by emtag.

(note : beaucoup de technologies se cachent en réalité dans cette image)

(JPEG 1697kb , 1920 x 1200)

Nous verrons donc de quelle façon il fonctionne face au moteur de recherche de FaceBook, quels sont ses arguments et le teneur réelle des résultats qu’il renvoie.

Enfin nous essaierons de présenter quel risque peut apparaître vis à vis des comptes privés .

La mécanique du script est la suivante :

1. lire un fichier contenant des adresses web (URLs) au format “une adresse par ligne”, on l’appellera “infilename”
2. pour chaque adresse, parcourir le contenu de la page pour séparer les noms avec leur adresse de profil associée et les sous-répertoires contenant d’autres listes de noms
3. sauvegarder les noms+adresses de profils dans un fichier, c’est ce fichier qui est bien sur le but final
4. sauvegarder les sous-répertoires dans un autre fichier, qui pourra servir a collecter les noms si on relance le script en lui faisant lire ce nouveau fichier.

Constituer le fichier de départ

Le fichier de départ, que nous avons appelé “infilename”, est ce qu’on pourrait appeler le “vecteur d’initialisation” de cette mécanique de récolte. Que contient-il ?

La page du moteur de recherche de profils de FaceBook fonctionne comme un agenda classique, organisé d’abord à sa racine par “onglets” alphabétiques : des noms commençant par A jusqu’à Z, et 26 pages de noms en caractères non-latins (langues arabes, asiatiques, slaves etc.)

Comme chaque page ne peut afficher que 2000 noms maximum, dans chaque répertoire correspondant à une lettre on trouve un certain nombre de sous-répertoires qui classent encore les personnes par ordre alphabétique de leur noms de famille : dans les “A” par exemple, on trouve les sous-classements “Thierry Abeyer” jusqu’à “Tahar Abid”, puis “Tahar Abid” jusqu’à “Mohamed Aboudou” et ainsi de suite.

On l’aura compris, afin de constituer le tout premier fichier infilename il suffit de créer un fichier texte et d’y inscrire les 26 adresses correspondant à chacune des lettres de l’alphabet :

• http://www.facebook.com/directory/people/A
• http://www.facebook.com/directory/people/B
• http://www.facebook.com/directory/people/C
• (etc…)
• http://www.facebook.com/directory/people/Z

Lancer le script

Chaque script NSE contient trois parties (voir l’article sur les plugins Nmap), l’une d’elle étant la règle qui dit dans quelle condition lancer le script. Dans ce cas particulier, la règle est contournée de façon à lancer le script contre Facebook quelle que soit la cible donnée à Nmap (Google.com, ce que vous voulez):

hostrule = function()

return true

end

D’autre part comme on vient de le voir, il faut donner au script quelques arguments qui sont les noms de fichiers à utiliser :

• le fichier à lire infilename
• le fichier où sauver les résultats de noms
• le fichier où sauver les résultats de sous-répertoires à parcourir plus tard

Enfin, le script effectue ses requètes HTTP en se faisant passer pour un robot d’indexation de Google, ce qui est une façon simple de passer inaperçu en exploitant le fait que Facebook est trop heureux d’accueillir les spiders du moteur de recherche dans sa politique expansioniste :

local result = http.get_url(line, {header={“User-agent: Googlebot/2.1 (+http://www.google.com/bot.html)”}})

Au final la commande Nmap ressemblera à ceci :

Résultats

Au premier lancement bien sûr, le script ne renvoie qu’un fichier contenant des sous-répertoires. Il est évident que pour une lettre donnée et vu le nombre de personnes inscrites il est presque impossible d’avoir directement un nom.

Il faut donc relancer le script en lui donnant cette fois en argument pour le fichier de lecture infilename le fichier de sous-répertoires qu’il vient de créer lui-même.

Cette fois énromément de noms avec leur adresse de profil vont être collectés, quelques 170 millions à cause des doublons (personnes portant le même nom).

Beaucoup de nos lecteurs n’auront peut être pas téléchargé ce fameux fichier qui fait si peur, alors voici ce qu’on obtient :

Comme on le voit, les adresses collectées de cette façon pointent vers une page de résumé du profil qu’il est possible de consulter sans nécessairement posséder de compte sur Facebook.
Il n’y a pas d’informations sensibles telles que des numéros de téléphone cependant on peut voir la liste d’amis de la personne en question et c’est ce point qui fait polémique.

En effet, à partir de cette page on peut accéder alors aux profils de chacun des amis de la personne en question, que ceux-ci soient publics ou non. C’est dans ce dernier cas, lorsque le profil est censé être privé, que la question de la confidentialité sur FaceBook se pose.

Il n’est pas très difficile de modifier un peu le script de façon à ce qu’il prenne dans le fichier infilename les profils publics et que, partant de là, il aille aspirer les profils privés en passant par ceux des gens qui ont laissé le leur public.

A l’appui de cet article, il a mis à disposition en partage Torrent 2.8Go de données de profils disponibles publiquement. Comprennez par là qu’il s’agit de profils que leurs proriétaires ont choisis, dans leurs options de compte, de rendre publics.
A la fin de son article il va plus loin en expliquant qu’il est possible grace a ce script d’indexation et en suivant les “amis” des profils publics de base de façon récursive de pousser ce genre de collecte jusqu’à des profils qui peuvent ne pas être obligatioirement publics.

On commence à lire un peu tout et n’importe quoi au sujet de cette affaire et, pour bien connaitre le developpement du scanner Nmap et Ron Bowes  il m’a paru important de redéfinir quelques vérités sur ce qu’il s’est passé et la démarche dans laquelle ceci est arrivé.

Revenons à l’origine.
Nmap ainsi que Ncrack (un passwords cracker développé en parallèle) proposent des modules permettant d’attaquer par force brute (c’est à dire en essayant des combinaisons jusqu’à trouver la bonne) à l’aide de dictionnaires des services protégés par un login et un mot de passe.

Contrairement à la plupart des outils similaires (le lecteur non averti doit savoir qu’il en existe des tonnes sur Internet) qui pour constituer leurs dictionnaires d’attaque vont juste “copier” des dictionnaires linguistiques classiques afin d’être certains de couvrir tous les mots existant dans une langue, l’approche des équipes de développement de Nmap s’inscrit dans une idée très différente.
Il s’agit en effet non pas de couvrir tous les mots/noms/verbes possibles bêtement, mais d’analyser mathématiquement et de façon statistique les mots les plus utilisés sur Internet dans la création des comptes des utilisateurs.

La démarche pratique est au départ assez simple puisque comme matière première de recherche le principe consiste à récupérer les grandes bases de données de grands sites ou réseaux sociaux qui ont déjà été piratés par le passé : Myspace, Hotmail, RockYou, forums PHPBB… De cette façon les developpeurs travaillent sur une matière première “réelle”.

A partir de là et pour aboutir à des dictionnaires d’attaque crédibles, des statistiques et des comparaisons complexes sont établies de façon à pouvoir dire quel nom d’utilisateur ou quel mot de passe est le plus utilisé, de les classer par ordre d’apparition puis de définir le “plus petit dictionnaire représentant le plus grand pourcentage de comptes potentiels” sur une base de données générique.

“Générique”, c’est le mot-clé dans cette histoire, qui fait toute la difficulté de la chose : on se doute bien en effet que les login et mots de passe auront tendance à appartenir à un champ lexical bien particulier lorsqu’il s’agit d’un site très spécialisé (médecine, mécanique, astronomie, philosophie…). Il faut donc dans le cadre de l’étude du “meilleur dictionnaire possible” savoir en outre écarter les matières premières (ces fameuses base de données volées) trop spécifiques, trop “marquées”.

Bref, tout ceci est compliqué et necessite beaucoup de bases d’études.
Sur son blog, Ron publie un grand nombre de ces bases (qu’il n’a pas volées lui-même, il ne fait que centraliser ce qui existe déjà) ainsi que certaines des études statistiques qui sont menées par les développeurs de Nmap.

Cette explication peut paraitre un peu longue, mais elle est nécessaire pour expliquer pour quelle raison Ron, dans le cadre de ses études sur les fréquences d’apparition de certains noms, a utilisé la fonction de recherche officielle de Facebook en automatisant le processus de collecte.

Ce faisant, il s’est rendu compte qu’à l’image d’une pelote qu’on déroule par un bout de fil qu’il était possible d’aller de la même façon plus loin dans la collecte d’informations de profils que ce que Facebook met en avant publiquement.

Et comme il écrit ce qu’il fait comme beaucoup d’entre nous…il a fait de tout ça un article.

L’histoire prend depuis des proportions étranges : il ne faut pas oublier qu’il ne s’agit en définitive que d’informations très banales et surtout publiques, mises à disposition à dessein par les utilisateurs de Facebook.
Mais on a là tous les ingrédients d’un bon buzz comme les aiment les journaleux d’Internet : des “millions” de “comptes”, impliquant Facebook (nom sulfureux ces derniers mois qui fait souvent l’actu), le tout collecté par un “chercheur en sécurité”. Avec les bons mots, on crée la peur chez le quidam moyen et la peur, ca fait du pagerank et le pagerank, ca fait vendre.

Ron n’a pas cherché a se faire de “publicité” comme j’ai pu le lire, il a encore moins “piraté” quoi que ce soit. Il a juste fait son boulot de développeur indépendant et l’a publié.

C’est un peu comme si quelqu’un utilisait un script similaire pour parcourir le site de l’annuaire pagesjaunes.fr pour en sauvegarder les données publiques et mettait le fichier en ligne : what else ?

Pour se faire une idée ou mirrorer l’information, voici les liens :

• torrent : fbdata.torrent sur http://rs405.rapidshare.com/files/409692690/fbdata.torrent , http://thepiratebay.org/torrent/5722635/Facebook_directory_-_personal_details_for_100_million_users
• l’article d’origine (cache Google)
• les scripts de Ron permettant de générer cette recherche de profils
  • NSE pour Nmap : facebook.nse
  • Ruby : facebook.rb
• direct download :

http://hotfile.com/dl/58180613/b424710/facebook-f.last-withcount.txt.bz2.html
http://hotfile.com/dl/58180632/e160598/facebook-first.l-withcount.txt.bz2.html
http://hotfile.com/dl/58180642/9d6f4cc/facebook-firstnames-withcount.txt.bz2.html
http://hotfile.com/dl/58180649/9b4144d/facebook-lastnames-withcount.txt.bz2.html
http://hotfile.com/dl/58180822/5260779/facebook-names-original.txt.bz2.html
http://hotfile.com/dl/58180985/41862da/facebook-names-unique.txt.bz2.html
http://hotfile.com/dl/58181148/d2967b2/facebook-names-withcount.txt.bz2.html
http://hotfile.com/dl/58181816/179517c/facebook-urls.txt.bz2.html

Rapidement pour ressituer l’idée, imaginons que vous soyez sur nmap.org. Un ping sur ce domaine vous montre qu’il est rattaché à un serveur dont l’adresse IP est 74.207.254.18. Mais comme c’est souvent le cas, ce serveur n’héberge pas uniquement nmap.org : il fournis aussi d’autres sites ou services, auxquels sont rattachés d’autres noms de domaine. Par exemple dans notre cas : seclists.org, un célèbre miroir du Full Disclosure et autres Bugtracks.

Autre exemple, vous pouvez avoir fait héberger votre site web sur un serveur mutualisé. Ceci signifie que vous n’êtes pas le seul sur le serveur et que, même si vous avez prété une attention toute particulière à votre site, l’un des dizaines de sites autour de vous peut présenter une vulnérabilité remontant à des droits sur le serveur et par là en redescendant à des droits sur…vous. D’aucun pourrait avoir envie d’en savoir plus sur ses voisins, à commencer par connaitre leur nom.

Hostmap le permet, mais c’est un outil à part. Il parait donc utile d’offrir une possibilité d’information similaire directement dans votre scanner préféré : Nmap.

C’est l’objet du nouveau plugin NSE qui vous est présenté aujourd’hui en exclu sur ce blog : hostmap.nse
Sa méchanique est extrèmement simple puisqu’il s’appuie sur la base de données publique BFK.de (une réplication DNS passive). C’est là que s’arrète la similitude avec l’outil hostmap puisque celui-ci va plus loin avec d’autre techniques, notamment de force brute et de variations sur les noms de domaine (www.site.com, www2.site.com, www.site.org, etc…).
Cependant pour les besoins courants dans le cadre d’un scanner une telle base est plus que satisfaisante : rapide, et quasi exhaustive. Il faut garder en tête que le but d’un scanner n’est pas de *tout* faire en allant dans le détail, mais d’agir comme une sorte de “mission de reconnaissance” du réseau. Par la suite, il est évident qu’il faut toujours affiner avec des outils dédiés.

Dernier point intéressant à signaler au sujet de ce plugin, en fin de tâche il génère un fichier texte au format “un hote par ligne”, un format tellement répandu parmis les autres outils de sécurité que c’en est presque un standard. Ainsi vous pouvez directement utiliser les résultats dans un outils à côté, par exemple un scanner de vulnérabilités.

L’installation est simple comme toujours : récupérez le script hostmap.nse et allez le ranger dans le dossier “scripts” de votre installation de Nmap avec les autres.

• [dossier Nmap]\scripts sous Windows
• /usr/local/share/nmap/scripts/ ou /usr/share/nmap/scripts pour Linux