lundi 31 décembre 2012

Et bonne année!

Puisque la fin du monde n'a (une fois de plus) pas eu lieu, je vous souhaite une bonne année \o/
Pleine de bonnes vibes et d'exploit!

mardi 11 décembre 2012

Linux magazine décembre - mysql administration

J'ai écrit un article dans le Linux magazine 155 de décembre 2012 qui fait la couverture. Cet article parle d'administration de mysql. L'article fournit à l'aide d'un exemple concret la prise en main d'une base de données inconnues, son exploration, sa connexion (avec ou sans mot de passe), la recherche de docs, etc..

Ce blog va revenir sur deux points qui peuvent intéresser l'amateur de sécurité. Le premier explique comment sniffer efficacement des requêtes SQL, le second comment explorer une base uniquement avec des requêtes SELECT.

1/ Lorsque le réseau est utilisé pour interroger mysql, une requête tshark permet d'afficher toute les requêtes passées. C'est très utile lorsqu'une attaque échoue dans un environnement de test pour connaître la syntaxe précise de l'injection transmise à la base de données par le formulaire php:
tshark -i lo -R mysql.query -Tfields -e mysql.query

tshark va alors filtrer via -R uniquement les queries mysql, et n'afficher en sortie que ces queries. C'est très pratique pour comprendre pourquoi une requête forgée/encodée dans l'URL ne fonctionne pas.

2/ mysql permet d'explorer les bases à l'aide des commandes:

  • SHOW DATABASES
  • USE base puis
  • SHOW TABLES
  • DESCRIBE nom_de_la_table

Lorsque un attaquant dispose d'une injection SQL, il peut souvent réaliser des requêtes SELECT, mais pas de commandes SHOW. mysql fournit une base information_schema permettant de retrouver les résultats ci-dessus:

  • SELECT DISTINCT table_schema FROM information_schema.tables; va afficher les bases. 
  • SELECT table_name FROM information_schema.tables WHERE table_schema = 'base'; va lister les tables de la base 
  • SELECT column_name,column_type FROM information_schema.columns WHERE table_name = 'table'; va décrire les colonnes de la table.
Conclusion/

L'article complet couvre d'autres aspects, je vous invite à le lire dans le magazine.

vendredi 30 novembre 2012

Manipulons un peu cryptsetup sans cryptsetup

cryptsetup est l'outil en ligne de commande permettant de manipuler dm-crypt, le module de chiffrement du noyau linux.
Il permet de chiffrer et déchiffrer à la volée les informations destinées à être enregistrées/lues sur le disque dur.

Je propose une petite manipulation pour faire du cryptsetup sans cryptsetup. Il ne s'agit pas de cracking, puisque la clé doit être connue, il s'agit seulement d'expliquer un peu comment cela fonctionne.
J'utilise la version sans LUKS pour plus de facilité, mais la version avec LUKS fonctionne de la même manière, aux offsets près.

1/ Déchiffrement sans cryptsetup:
On crée un mapping, et on copie des données dedans:

kevin@slack:~$ dd if=/dev/zero of=img bs=1024k count=10
10+0 enregistrements lus
10+0 enregistrements écrits
10485760 octets (10 MB) copiés, 0,0307038 s, 342 MB/s
kevin@slack:~$ sudo losetup /dev/loop0 img 
kevin@slack:~$ sudo cryptsetup create -c aes-cbc-plain -s 128 x /dev/loop0
Entrez la phrase de passe :   ( abcd comme pass )
kevin@slack:~$ sudo dmsetup table --showkeys x
0 20480 crypt aes-cbc-plain 2e7e536fd487deaa943fda5522d917bd 0 7:0 0
kevin@slack:~$ printf 'abcd' | openssl dgst -ripemd160
2e7e536fd487deaa943fda5522d917bdb9011b7a
kevin@slack:~$
On met quelques données dans ce container. Je les écrit en dur, sans mettre de filesystem, puis on démonte le maping:
kevin:~# python -c "print 'A'*512 + 'B'*512 + 'Success' " > /dev/mapper/x
kevin@slack:~$ sudo cryptsetup remove x

Et le déchiffrement sans cryptsetup est aisé:
kevin@slack:~$ dd if=img of=part1 bs=512 count=1
kevin@slack:~$ dd if=img of=part2 bs=512 count=1 skip=1
kevin@slack:~$ dd if=img of=part3 bs=512 count=1 skip=2
kevin@slack:~$ openssl aes-128-cbc -nosalt -nopad -d -in part1 -K 2e7e536fd487deaa943fda5522d917bdb9011b7a -out clear1 -iv 0 -p
key=2E7E536FD487DEAA943FDA5522D917BD
iv =00000000000000000000000000000000
kevin@slack:~$ openssl aes-128-cbc -nosalt -nopad -d -in part2 -K 2e7e536fd487deaa943fda5522d917bdb9011b7a -out clear2 -iv 01 -p
key=2E7E536FD487DEAA943FDA5522D917BD
iv =01000000000000000000000000000000
kevin@slack:~$ openssl aes-128-cbc -nosalt -nopad -d -in part3 -K 2e7e536fd487deaa943fda5522d917bdb9011b7a -out clear3 -iv 02 -p
key=2E7E536FD487DEAA943FDA5522D917BD
iv =02000000000000000000000000000000
kevin@slack:~$ hexdump -C clear3 
00000000  53 75 63 63 65 73 73 0a  ad 5c 0c 69 bc 82 c5 9d  |Success..\.i....|

Attention aux IV qui croissent en relation avec le numéro de secteur.

2/ Création de volumes cryptsetup sans cryptsetup:
Pour créer un device depuis openssl, c'est le même principe:
kevin@slack:~$ python -c 'print ("A"*511)' > e1c
kevin@slack:~$ python -c 'print ("B"*511)' > e2c
kevin@slack:~$ python -c 'print ("C"*511)' > e3c
kevin@slack:~$ openssl aes-128-cbc -nosalt -nopad -e -in e1c -K 2e7e536fd487deaa943fda5522d917bdb9011b7a -out e1 -iv 0 -p
key=2E7E536FD487DEAA943FDA5522D917BD
iv =00000000000000000000000000000000
kevin@slack:~$ openssl aes-128-cbc -nosalt -nopad -e -in e2c -K 2e7e536fd487deaa943fda5522d917bdb9011b7a -out e2 -iv 01 -p
key=2E7E536FD487DEAA943FDA5522D917BD
iv =01000000000000000000000000000000
kevin@slack:~$ openssl aes-128-cbc -nosalt -nopad -e -in e3c -K 2e7e536fd487deaa943fda5522d917bdb9011b7a -out e3 -iv 02 -p
key=2E7E536FD487DEAA943FDA5522D917BD
iv =02000000000000000000000000000000
kevin@slack:~$ cat e1 e2 e3 > e-disk
kevin@slack:~$ sudo losetup /dev/loop1 e-disk 
kevin@slack:~$ sudo cryptsetup create -c aes-cbc-plain -s 128 x /dev/loop1
Entrez la phrase de passe :  ( "abcd" comme pass )
kevin@slack:~$ sudo hexdump -C /dev/mapper/x
00000000  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
*
000001f0  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 0a  |AAAAAAAAAAAAAAA.|
00000200  42 42 42 42 42 42 42 42  42 42 42 42 42 42 42 42  |BBBBBBBBBBBBBBBB|
*
000003f0  42 42 42 42 42 42 42 42  42 42 42 42 42 42 42 0a  |BBBBBBBBBBBBBBB.|
00000400  43 43 43 43 43 43 43 43  43 43 43 43 43 43 43 43  |CCCCCCCCCCCCCCCC|
*
000005f0  43 43 43 43 43 43 43 43  43 43 43 43 43 43 43 0a  |CCCCCCCCCCCCCCC.|
00000600

Enjoy.

mercredi 24 octobre 2012

Qui sauvera mon tripoux dans le cyberespace?

Ma grand mère avait hérité d'une recette de tripoux particulièrement savoureuse, ce qui m'amène à mon sujet d'aujourd'hui lié à cette fameuse cyberguerre dont tout le monde parle.

Au début d'internet il était admis que la sécurité informatique ne reposait que sur un socle défensif: antivirus, firewall, log, etc..
A lire différents blogs et communiqués aujourd'hui, on entend parler de plus en plus ouvertement de cyberguerre, de lutte offensive et du cyberespace comme nouveau champ de bataille. La transition s'est faite approximativement avec Stuxnet, lorsque le monde s'est rendu compte que l'informatique impalpable avait finalement les pieds très ancrés dans le monde physique. On est passé d'un discours purement défensif à un discours ouvertement offensif. Le défensif a montré ses limites, un général US disait à ce sujet que le temps de réponse est beaucoup trop court: "A piece of information can circumnavigate the globe in about 133-134 milliseconds, your decision space in cyber [is] half that". La fin de son discours est clairement tourné vers l'offensif: "Today, the offense clearly has the advantage, Get cyber legislation in there, bring industry and government together, and now we have the capability to say 'You don't want to attack us. We can stop it and there are other things that we can do to really make this hurt.".

On a pu voir dernièrement l'OTAN diffuser un draft qui souhaite légaliser la cyberguerre. Le but de ce document est d'appliquer/d'adapter au mieux les lois régissant la guerre conventionnelle au "cybermonde". Par exemple, qu'est ce qui peut être pris comme une intention belliqueuse, quelles répliques sont admises, etc.. 
Il reste toutefois un dernier point, communément partagé: A la différence du monde physique ou l'ennemi est visible et identifiable, contre qui tourner ses armées lorsque l'attaque vient d'Internet? The department has made significant advances in solving a problem that makes deterring cyber adversaries more complex: the difficulty of identifying the origins of that attack. Over the last two years, DoD has made significant investments in forensics to address this problem of attribution and we're seeing the returns on that investment. Potential aggressors should be aware that the United States has the capacity to locate them and to hold them accountable for their actions that may try to harm America. ". Ce point est vraiment nouveau dans le discours "cyberguerrier", il indique clairement que l'anonymat est en train de disparaître, ce qui implique entre autre qu'un APT ne pourra plus prospérer car on est capable d'en identifier l'auteur.

Mais allons un peu plus loin dans la réflexion. Les états sont donc de plus en plus sensibilisés aux questions d'attaques informatiques aussi bien destructives que disruptives ou aux intrusions. Les discours politiques visent à protéger les infrastructures publiques. On ne peut qu'anticiper que cette protection va s'étendre aux OIV (Organismes d’Intérêt Vitaux).

Ma grand-mère m'a légué la recette du tripoux que le monde entier envie. Devant la qualité de ce plat, j'ai décidé de monter une entreprise pour promouvoir ces saveurs inimitables. J'ai misé sur la vente par internet. Et un problème se pose avec mon usine de tripoux en conserve. Qui me protégera d'un acte de piratage ou d'une copie infâme? Un tripoux à bas prix pourrait voir le jour si on vole la propriété intellectuelle de ma recette. Un concurrent malveillant pourrait infecter mon usine pilotée par système scada afin d'accélérer la cadence de mes salières pour rendre mon tripoux impropre à la consommation (ma grand-mère me disait toujours: sans trop de sel et à feu doux!). Plusieurs attaques peuvent empêcher mon site web de vendre, depuis le (D)Dos en passant par la modification des commandes en ligne. Contre toutes ces attaques, je n'ai pas d'autre choix que de mettre de la sécurité classique (AV, firewall, patching policy, IDS, SIEM, etc..) qui bloquera les 80% des attaques basiques, mais qui n'empêcheront pas les drames décrits ci-dessus. L’État est capable de prendre des mesures pour protéger ses infrastructures, mais pour les miennes?

Jusqu'où la protection publique qui dispose d'une force de frappe conséquente ira pour protéger les acteurs privés qui sont en droit d'attendre cette protection? Cette question en recouvre d'autres:
-Dans quelle mesure les cyberattaques vont-elles modifier les pouvoirs de la police étatique vis à vis de l'Internet et par là même rogner sur les libertés d'Internet?
-La "police du net" restera t'elle longtemps l'apanage des sociétés privées alors que l'État est de plus en plus impliqué dans la protection de son cyberterritoire et de ses intérêts
-Est-ce la fin d'un Internet anonyme et sans frontières?

jeudi 4 octobre 2012

Etes vous les 20% ?

J'ai lu deux papiers dernièrement qui traitent un thème commun. Le premier est l'édito de MISC septembre-octobre dans lequel un paragraphe a retenu mon attention: "Un peu de réflexion et de bon sens permettrait déjà de régler nombre de problèmes. Par exemple, au lieu de déployer des anti-virus, IDS/IPS, WAF et autres outils de filtrage qui n'arrêtent que le bruit ambiant d'Internet, peut-être qu'analyser et comprendre les 20-30 failles critiques qui sortent par an suffirait à déployer une défense ciblée, adaptée à ces risques ? Encore faut-il être capable d'identifier ces 20-30 failles ...". Le second est un article de blog de Carnal Ownage  qui donne une piste de réflexion "We should stop trying so hard to stop the 80% of low sophistication attackers and focus on the 20% of attackers we really care about and who can really hurt us".

Le blog de Carnal0wnage est un peu plus disert que l'edito de MISC et donne des détails sur le contenu de ces pourcentages. Les 80% ont pour but des vols de numéros de sécu ou CB, de l'envoi de mail, de l'ajout de bandeaux publicitaires ou de defacer du site web. Leurs techniques sont des techniques massives, du scan au malware en utilisant des failles anciennes (appelées 1day). Le but des 20% est de voler de la propriété intellectuelle, d'obtenir des informations confidentielles afin de bénéficier d'une avance (législative, négociation, paris, etc..), pouvoir endommager des architectures physiques dans une optique de perte financière, décrédibiliser une entreprise et même de voler des codes sources afin de trouver des 0day ou de les modifier. Leurs techniques sont plus pointues et regroupent des 0day, du spear phishing, des APT, des AET (combo buzzword!), utilisent des certificats volées, implantent du malware dès la chaîne de construction et réussissent à exploiter les relations de confiance.

On observe effectivement une bonne dichotomie entre d'un côté des attaques de "masse" et de l'autre des attaques "ciblées". Apparemment, une bonne expérience[1] de la sécurité informatique permet d'éviter les scans massives et les 1days (finalement le trio infernal firewall/antivirus/IDS fonctionne un peu :) ) Attaques de masse => réponse standardisée. Pour ces 80%, normalement, pas de soucis, l'ANSSI vient même de créer un checkup à réaliser (ou pas).

Bien évidemment le problème est posé par les attaques ciblées. On sait très bien qu'un firewall ne bloque ni n'analyse un flux https sortant ou qu'un antivirus est aveugle devant un exploit préparé pour, qu'un social engineering efficace contourne beaucoup de protections. Alors, quelles solutions avons nous pour ces 20%? MISC conseille l'étude de ces failles pour en déduire une défense ciblée. Certes, mais laquelle, et en regard de quelle faille? CarnalOwnage propose une option offensive (?) ou une option d'augmentation des coûts pour l'attaquant (par des méthodes de SIEM semble t'il). Je reste dubitatif vis à vis de ces lignes de défense. L'offensif pourquoi pas, le mot cyberguerre commence à être employé de plus en plus souvent, mais contre quel ennemi? A l'opposé du champ de bataille ou l'ennemi est connu puisqu'en en face, qui attaquer lorsque l'ennemi est invisible? Tabler sur la peur? Je n'y crois pas. Les SIEM (ou assimilé) pour faire augmenter le coût de la réussite de l'attaque?  Est-ce possible d'estimer le coût qu'espère tirer l'attaquant de son action?

L'informatique et le réseau permet de relier des systèmes et des personnes afin qu'ils communiquent entre eux. Les attaquants tirent partie de ces personnes et communications. La sécurité veut empêcher tout ou partie de ces communications. Equation impossible?

[1] ou hygiène? :)

mardi 11 septembre 2012

Le chiffrement de disque sous linux: Second strike

1/ Introduction: la théorie
Toutes les distributions linux permettent depuis longtemps de chiffrer la racine du système afin d'améliorer la sécurité du système. Ce chiffrement se fait à l'aide de cryptsetup et dm-crypt, la documentation est abondante sur le sujet.

Cet article propose une étude des limites du chiffrement:
-L'humain: l'implémentation et l'utilisation
-Ecrasement de données
-Evil Maid
-Cold boot attack

2/ L'humain
Le plus gros problème de la crypto c'est qu'il est possible de se tromper mais que cela fonctionne tout de même: c'est juste non sécurisé.
2/A/ L'implémentation
le meilleur chiffrement du monde peut être anéanti si le programmeur l'a mal codé. Si le programmeur a bien travaillé, alors l'intégrateur peut se tromper également (n'est ce pas debian?).
Les algos par défaut peuvent également être mal choisis (ce n'est pas le cas avec cryptsetup).
Comme je l'ai montré dans un précédent article, un simple cat peut aussi réduire toute la sécurité à zéro. Une lecture des init de debian et slackware montrent que des choix efficaces ont été fait.
2/B/ L'utilisateur
Toute solution de chiffrement est vulnérable à au mauvais mot de passe. Il faut donc forcer l'utilisation de bon mots de passe. On peut imaginer des solutions hardwares ou des politiques strictes.
Il faut aussi se méfier de l'utilisateur malveillant qui peut dumper la clé maître de chiffrement du disque (dmsetup --showkeys), rendant caduque le remplacement des clés de slots par l'administrateur qui veut lui couper l'accès.
Heureusement, cryptsetup propose depuis la version 1.5.0 en expérimental un système de changement de clé maitre: http://code.google.com/p/cryptsetup/wiki/Cryptsetup150 (chercher cryptsetup-reencrypt dans la page)

3/ Protection anti-écrasement
Un autre de mes articles expliquait comment écraser des données choisies afin d'éviter le lancement au démarrage de contre mesures de protection. Il n'existe pas encore au niveau de dm-crypt un mécanisme de vérification d'intégrité. Toutefois, deux solutions sont envisageables:
3/A/ Le filesystem
Ext4 depuis la version 3.5 permet de calculer un CRC32 des données.
Si un écrasement à eu lieu, alors le fs est remonté en ro. Il devient donc possible de détecter si un écrasement (volontaire ou non) a eu lieu en testant en fin de boot si / est en rw.
3/B/ dm-verity
Une nouvelle couche device mapper a fait son apparition avec le noyau 3.4. Elle maintient un hash de tous les blocs et permet de les vérifier de manière fiable à l'aide d'un TPM.

4/ Protection anti Evil Maid
On le sait, même si l'intégralité du disque est chiffré, il reste toujours une petite partie en clair, servant à gérer le démarrage et demander la clé de déchiffrement. Un pirate pourrait modifier ce code en clair afin de logger le mot de passe quelque part.
4/A/ TPM
le noyau peut utiliser un TPM. Ce TPM permet de vérifier que le code en clair (MBR + noyau + initramfs) est bien celui d'origine et n'a pas été modifié.
La conférence que j'ai donné aux RMLL 2010 explique comment utiliser le TPM sous linux.
4/B/ If it walk like a duck, is it a duck?
Ma conférence était un poil incomplète. En effet, le setup laisse un léger trou qui peut se combler facilement. Lors du démarrage, les métriques du boot (MBR, noyau, initramfs) sont chargées dans le TPM. Ensuite, la racine est déchiffrée
via la clé scellée dans la partition /boot. Mais si je suis un pirate, je peux déplacer cette clé, changer l'intégralité du système linux et rebooter. Ainsi, je deviens root sur mon système et les métriques TPM sont correctement positionnées!! Je peux donc désceller aisément la clé scellée et lire/modifier les données du système initial.
Cela se corrige simplement en "brûlant" les métriques TPM en fin de boot en ajoutant de l'alea afin de les dévalider.

5/ Protection cold boot
Une autre attaque consiste à aller chercher les clés directement dans la mémoire vive. Ciblant plus linux, un travail d'étude intéressant peut se lire ici: http://events.ccc.de/camp/2007/Fahrplan/attachments/1300-Cryptokey_forensics_A.pdf
Je cite une partie: "The obvious conclusion that can be drawn is that key recovery is surprisingly easy. Once an attacker, in our case a forensic investigator, has gained access to an image of the memory the keys can be easily found, extracted and reused to gain access to the encrypted material."
La solution consiste donc à éviter que les clés soient présentes en mémoire vive. Deux projets me semblent intéressant.
5/1/ Frozencache
Le projet semble relativement mort. L'idée de base est de placer les clés dans le cache CPU. Lorsque la clé est dans le cache, les performances sont calamiteuses, mais comme le dit l'auteur, la clé n'a besoin d'y être que lors de la phase d'hibernation ou lorsque la machine a son screensaver de lancé.

5/2/ Tresor
 Ce projet n'est pas inclus
dans les sources officielles du kernel mais semble plus intéressant.
"Our solution takes advantage of Intel’s new AES-NI instruction set and exploits the x86 debug registers in a non-standard way, namely as cryptographic key storage. TRESOR is compatible with all modern Linux distributions, and its performance is on a par with that of standard AES implementations."

5/3/ Les clés OK, mais quid des données?
Il reste encore un léger problème avec ces implémentations. Les clés sont sauves d'une attaque coldboot, mais les données, elles, ne le sont pas. C'et mineur, mais il faudrait prévoir un mécanisme permettant de dropper tous les caches afin d'éviter qu'un attaquant lise le contenu de la RAM (le proc vm_drop_cache). On sait plutôt bien reconstruire le contenu d'une RAM linux, ainsi que les fichiers présents (volatilitux).

6/ Conclusion
Il s'agit actuellement d'un WIP (Work In Progress). Il me reste plusieurs setups à tester et des attaques à vérifier. J'espère avoir fait le tour des risques liés au chiffrement de disque et des moyens pour les limiter.

mardi 28 août 2012

Java CVE-2012-4681

Le dernier 0day à la mode touche toutes les versions 7 de java. Ce bug a une histoire intéressante. Je propose une analyse rapide de celui-ci.

UPDATE: un patch officiel est finalement sorti http://www.oracle.com/technetwork/topics/security/alert-cve-2012-4681-1835715.html

1/ La découverte
J'ai pris connaissance de ce bug via le blog de fireeye et un mail sur full-disclosure. Il est fait mention d'une attaque touchant tous les OS, tous les navigateurs supportant la version 7 de java, ce qui semble intéressant en soi.

2/ Un peu de technique
L'article de fireeye aidé d'un autre blog m'ont permis de remonter à la source de l'infection. Il s'agit d'une page web  http://ok.aa24.net/meeting/index.html (le nom résoud aujourd'hui vers 127.0.0.1).
La page web est constitué d'un script unique, sans aucune autre balise HTML laissant entendre que l'attaque est le fait d'un XSS, et est très obscurci:
La partie surlignée indique l'usage de Dadong JSXX 0.44. Il n'existe que peu d'informations sur cette lib de camouflage.
On trouve également plusieurs calculs mathématiques, meSjBJF7=Math.PI;sRjYnQL3=Math.tan; qui paraît il donnent du mal aux analyseurs antivirus car ils embarquent un moteur javascript, mais qui sont généralement incomplet, surtout sur les aspects mathématiques. Est-ce une méthode de protection supplémentaire?

Pour Dadong, il est à peu près impossible de décoder facilement le script. Un chercheur donne des pistes dans un article de blog. Pour pouvoir remplacer la fonction eval() par alert() il est obligatoire d'intuiter le chiffrement ce qui ne se fait pas sans effort.

Après décorticage, le but de ce script consiste à télécharger un binaire windows et une applet java, nommée avec un certain esprit d'à-propos "applet.jar". Le binaire windows est un simple dropper de RAT, je laisse ce point de côté (surtout que c'est le point le plus discuté sur les différents sites traitant du sujet). L'applet elle, est plus intéressant:
$ file applet.jar
applet.jar: Zip archive data, at least v1.0 to extract
$ unzip applet.jar
cve2012xxxx/
cve2012xxxx/Gondvv.class
cve2012xxxx/Gondzz.class

La présence de l'année 2012 dans le jar pourrait signifier d'une part que l'exploit date de cette année, et d'autre part que l'auteur savait qu'il serait découvert et référencé dans la base CVE avant la fin de l'année!

3/ La faille
En lisant différents codes d'exploit comme par exemple celui de pastie, on découvre la faille. Une fonction appelée judicieusement disableSecurity permet d'exécuter du code natif sans aucune restriction!
Comme lu sur un blog, cela ressemble à du code java standard, car ... c'est du code java standard! Et on comprend mieux l'étendue du désastre: toute machine sachant faire fonctionner est de facto vulnérable à cette faille, aussi bien linux, que mac, que Chrome ou Firefox. Ce n'est pas une histoire d'implémentation, ce n'est pas un bug, c'est une feature! (feature involontaire, mais feature tout de même)


Pour résumer: l'applet crée un contexte avec fullprivilege, sans SecurityManager (surprenant, mais rien d'anormal à ce niveau) et l'appelle. Logiquement java devrait réagir en l'interdisant (ce qui est le cas de java6) mais java7 l'autorise! Apparemment, un problème lors de la vérification des droits existe ce qui permet cette opération. L'auteur de la faille se retrouve donc directement dans un java sans aucune restriction et peut donc exécuter du code natif (le PoC donné sur pastie.org lance la calculatrice windows [1]).

EDIT 29/08: une très bonne explication sur le site d'immunity: http://immunityproducts.blogspot.fr/2012/08/java-0day-analysis-cve-2012-4681.html

4/ La déférlante
Le lendemain de la première publication (le 27 Août), metasploit a décidé de sortir un module fonctionnel. Et rapidement pour ceux qui doutaient encore on a eu la confirmation qu'il s'agit bien d'un bug java, toutes versions d'OS/navigateurs confondus puisque des confirmations de succès ont été lues. La démo en est très simple, cf ce post de blog.
Un second problème concerne la politique de mise à jour d'Oracle pour Java. On peut lire que le prochain cycle de patch ne sera pas lancé avant mi-octobre (!). Certains bloggeurs estiment qu'on aura droit pour une fois à un patch out-of-band.

Actuellement, un correctif toutà fait officieux est disponible sur le site de http://www.deependresearch.org/2012/08/java-7-0-day-vulnerability-information.html . Ce patch n'est toutefois pas librement téléchargeable (uniquement sur demande motivée par mail). Ils ne sont pas diffuseurs java et ne veulent prendre aucun risque sur l'usage de ce correctif.
Leur correctif (assez court) patche java/com/sun/beans/finder, en modifiant plusieurs fois:
return Class.forName(name, false, loader);
en
return checkAccess(Class.forName(name, false, loader));
et cette fonction checkAccess contient le commentaire suivant:
/**
* Check if the class may be accessed from the current access control
* context. If not, throw a {@link SecurityException}.
*
* @param clazz
*            Class to check
* @return the checked class
*/
Ce qui semble donner le comportement voulu.

5/ Et maintenant
Nous avons donc aujourd'hui un 0day dans la nature, très très facilement exploitable via metasploit sans autre solution que de désactiver java en attendant le bon vouloir d'Oracle pour produire un patch.

[1] comme lu sur un site web: "The PoC you sent me doesn't work, it only launch calc.exe" :-)

jeudi 23 août 2012

Sécurisé? Eh bien non.

Je lisais sur une mailing list qu'un gros problème en crypto, c'est qu'en cas de problème, cela fonctionne tout de même! C'est juste non sécurisé, mais personne ne s'en rend compte...

Étudiant en ce moment le chiffrement de disque sous linux, je propose un petit exercice pour s'en rendre compte. Sous linux, on utilise le frontend cryptsetup pour gérer la couche crypto:

# cryptsetup luksOpen /dev/sdb1 ciphered_sdb1
et la commande demande un mot de passe. S'il est correct, alors la clé maître de chiffrement du volume est libérée, permettant la lecture des données.

La documentation précise que l'on peut passer ce mot de passe via un pipe | unix, comme par exemple:
# echo $MDP | cryptsetup luksOpen /dev/sdb1 ciphered_sdb1
ou bien
# cat randomfile | cryptsetup luksOpen /dev/sdb1 ciphered_sdb1

Imaginons donc un setup qui va extraire un certain nombre d'octets depuis /dev/random et qui va s'en servir comme clé de chiffrement.

Ce setup n'offre qu'une faible garantie contre une attaque bruteforce!

La raison en est simple et est précisée dans la fin du man cryptsetup. En effet, le passage de données via un pipe s'arrête dès le premier \n rencontré. Ce qui signifie que si dans les premiers caractères du fichier un \n est présent, alors la force de la clé est simplement équivalente au nombre de caractères précédent le \n! Démonstration:

Tout d'abord génération d'un fichier aléatoire tiré depuis /dev/random et utilisation de celui-ci pour formater une partition luks:
root@slack:~# dd if=/dev/random of=rnd bs=16 count=1
0+1 enregistrements lus
0+1 enregistrements écrits
16 octets (16 B) copiés, 0,00016936 s, 94,5 kB/s
root@slack:~# cat rnd | cryptsetup luksFormat /dev/loop0
root@slack:~# cat rnd | cryptsetup luksOpen /dev/loop0 ciphered
root@slack:~# cryptsetup luksClose /dev/mapper/ciphered

A première vue, le setup semble correct: tout d'abord, la clé est tirée depuis un générateur de hasard correct. Ensuite, la clé fait 16 octets ce qui est suffisant pour contrer les bruteforce. On a vérifié que tout fonctionne, le volume peut s'ouvrir si on dispose bien du fichier de clé.

Mais il se trouve que la force de la clé est beaucoup plus faible que 16 octets! (et dû également à un certain nombre d'essai successifs de ma part pour obtenir un rnd voulu :) )

root@slack:~# hexdump rnd
00000000  ca 41 71 0a 51 ba 56 55  f7 13 fb d9 94 0e 5c 2f
00000010
root@slack:~# printf '\xca\x41\x71' > loose
root@slack:~# cat loose | cryptsetup luksOpen /dev/loop0 ciphered
root@slack:~# ls -l /dev/mapper/ciphered
lrwxrwxrwx 1 root root 7 août  23 21:19 /dev/mapper/ciphered -> ../dm-0
root@slack:~#

On constate que le fichier contient un 0a en 4e position, et que le volume s'ouvre uniquement avec la connaissance des trois précédents. Le système n'est donc absolument pas sécurisé malgré ce qu'il laissait imaginer puisqu'il est vulnérable à une attaque bruteforce. Pour éviter ce problème il faudrait s'assurer de ne jamais avoir de \n dans son fichier (ou d'utiliser l'option --key-file qui n'a pas ce problème, se référer à la page man partie: NOTES ON PASSWORD PROCESSING).

Comme indiqué en introduction il ne s'agit pas d'une attaque ou d'un scoop particulier, le but de cet article est simplement de montrer qu'un setup crypto qui fonctionne et qui paraît fiable ne l'est pas du tout.

mercredi 11 juillet 2012

RMLL Workshop reverse, writeup

Ce post de blog va donner diverses solutions aux challenges proposés par r00tBSD pendant le workshop reverse engineering des RMLL 2012. Les solutions aux exam1, exam2, exam3, exam4 sont expliquées.
Les binaires sont téléchargeables en suivant ce lien (500ko). Ce sont des binaires linux 32 bits standards. Les exams nécessitent de trouver le bon mot de passe, à la manière des keygenme classiques des challenges que l'on trouve sur internet.

1/ exam1 - cold start
Comme a dit le formateur, cet exercice n'est présent que pour vous éviter de finir à 0 points :-).
kevin@slack:~/binaries$ ./exam1
Usage: ./exam1 key
kevin@slack:~/binaries$ ./exam1 test
Bad key
kevin@slack:~/binaries$ strings exam1
 (je coupe un peu, et on observe enfin)
øÿuô
è\þÿÿY[ÉÃ
Usage: %s key
r56GoinQ
Bad key
Good key
ÿÿÿÿ
ÿÿÿÿ
(snip snip snip encore un peu...)
main
_init
kevin@slack:~/binaries$
Sans trop réfléchir on lit les strings et on tombe sur le Usage, puis une série de caractères qui ressemblent à une clé, et les deux messages "good key/bad key". Sans plus attendre:
kevin@slack:~/binaries$ ./exam1 r56GoinQ
Good key
kevin@slack:~/binaries$

[Une anecdote à ce sujet: j'ai fait un challenge ou la clé était 'printf'. Bien qu'elle soit sous les yeux, aussi clairement indiquée, on ne pense pas à l'essayer :) ]

2/ exam2 - les moteurs sont chauds
L'exam2 est basé sur le même principe sauf que lire le binaire avec strings ne donne aucune indication valable. Il faut trouver une autre solution.
2/A/ La solution rapide
Le programme ltrace permet de tracer l'appel aux librairies. Puisque l'on se doute qu'un strcmp est fait pour comparer la clé entrée au clavier de la clé valide on regarde:
kevin@slack:~/binaries$ ltrace ./exam2 toto
__libc_start_main(0x80484a4, 2, 0xbf88a804, 0x8048590, 0x8048580
strcmp("AFc6mcw", "toto")                        = -51
puts("Bad key"Bad key
)                                  = 8
+++ exited (status 0) +++
kevin@slack:~/binaries$
La solution crève les yeux.
kevin@slack:~/binaries$ ./exam2 AFc6mcw
Good key
kevin@slack:~/binaries$

2/B/ La solution du programmeur
Il existe une variable d'environnement LD_PRELOAD qui permet de surcharger l'appel des bibliothèques. Il suffit donc d'utiliser une bibliothèque qui détourne l'usage de strcmp pour en connaître ses arguments. Un man strcmp permet de connaître la structure de la fonction pour reprendre les mêmes arguments.
kevin@slack:~/binaries$ cat hijack.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int strcmp(const char *s1, const char *s2)
{
 printf(" String 1 = %s\n String 2 = %s\n ", s1, s2) ;
}
kevin@slack:~/binaries$ gcc -shared hijack.c -o hijack.so
kevin@slack:~/binaries$ LD_PRELOAD=$(pwd)/hijack.so ./exam2 toto
 String 1 = AFc6mcw
 String 2 = toto
 Bad key
kevin@slack:~/binaries$
La solution est bien évidemment identique. WIN.

3/ exam3 - on met les mains dans le cambouis
l'exam3 va obliger à regarder de l'assembleur dixit le formateur. On sort donc gdb, et l'analyse fastidieuse commence. Nous avons droit à une mini formation de la gui de metasm qui permet de résoudre très vite cet exercice. Pour cela on télécharge metasm à l'aide de hg
kevin@slack:~$ hg clone https://code.google.com/p/metasm
 (... snip)
kevin@slack:~$ cd metasm
kevin@slack:~/metasm$ export RUBYDIR=/home/kevin/metasm/
kevin@slack:~/metasm$ ruby samples/disassemble-gui.rb
On charge alors le fichier exam3 (menu file Open), on le désassemble à l'aide de la touche 'c', puis on appuye sur espace pour obtenir le graphe de fonctions, puis menu Actions->List fonctions, et on choisit le Main du programme. On obtient cela (cliquer sur l'image pour la voir en grand):
La lecture du binaire est plus aisée. Le premier bloc doit compter le nombre d'arguments. Le second bloc à gauche fait un strlen et si le résultat diffère de 9 part à la fonction loose (avec un nom pareil on se doute qu'il ne faut pas aller là-bas :) ), on sait donc déjà que le mot de passe doit faire 9 caractères première information.

Ensuite, on peut zoomer à l'aide de CTRL molette souris, et en vue d'avion on observe cela:
(oui les cadres sont blanc, je n'ai pas de police à la bonne taille apparemment).
On se doute donc immédiatement que le programme va comparer caractère après caractère la clé entrée par l'utilisateur.
Suivons donc les blocs pas à pas:
cmp al, 41h. 
cmp signifie comparer. En code hexa, 41 est le 'A'. Nous savons donc que le A est le premier des 9 caractères du mot de passe. 
Le bloc suivant est beaucoup moins clair, c'est sans doute lié à une optimisation compilateur (?)
On va finalement sortir gdb. Tout d'abord, pour connaître l'adresse de ce cmp, on clique dessus, puis on presse la barre espace, ce qui nous amène à:
où l'on lit donc l'adresse: 0x08048521.
Nous allons donc placer un breakpoint à cette adresse, et étudier les registres edx et eax à ce moment là:
kevin@slack:~/binaries$ gdb exam3
 (snip)
(gdb) b *0x08048521
Breakpoint 1 at 0x8048521
(gdb) run Aaaaaaaaa
Starting program: /home/kevin/binaries/exam3 Aaaaaaaaa

Breakpoint 1, 0x08048521 in main ()
(gdb) info registers
eax            0x44    68
ecx            0x4c504300    1280328448
edx            0x61    97
ebx            0xb7fc2ff4    -1208209420
esp            0xbffff0e0    0xbffff0e0
ebp            0xbffff0f8    0xbffff0f8
esi            0x0    0
edi            0x0    0
eip            0x8048521    0x8048521
eflags         0x206    [ PF IF ]
cs             0x73    115
ss             0x7b    123
ds             0x7b    123
es             0x7b    123
fs             0x0    0
gs             0x33    51
(gdb)
Nous devons lancer le programme avec une clé de 9 caractères débutant par un A majuscule sinon nous sortirons avant. Une fois breakpointé, nous consultons les registres: edx vaut 0x61, ce qui correspond au a minuscule. eax vaut 0x44 qui est le D majuscule. Le deuxième caractère du mot de passe est donc le D majuscule.

En progressant de la même manière, il est possible de retrouver les 8 premiers caractères de la clé. huit? que 8? Or nous savons qu'il en faut neuf!
Petite blague du formateur, il ne faut pas chercher un 9e caractère ou une instruction oubliée. En effet, ce programme ne vérifie que les 8 premiers caractères d'une clé qui en contient 9. Ce qui signifie que n'importe quelle caractère en 9 position est valide!
kevin@slack:~/binaries$ ./exam3 AD13=xhca
Good key
kevin@slack:~/binaries$ ./exam3 AD13=xhcb
Good key
kevin@slack:~/binaries$ ./exam3 AD13=xhc9
Good key
kevin@slack:~/binaries$

[info pratique: sous linux man ascii affiche le code ascii des caractères]

4/ exam4 - sortie de piste!!
Pour cet exercice, je pense que toute la salle s'est fait berner. On est chaud, on a le gdb dégainé, le metasm-gui ouvert, donc on regarde direct le programme. Sauf que là, on a deux surprises:
Tout d'abord un graphe pas très engageant, et ensuite une absence totale de fonction main...
La solution est à portée de main. Le programme est en fait packé, il faut le dépacker pour pouvoir l'analyser. Un simple hexdump donne une première idée, un strings confirme:
kevin@slack:~/binaries$ hexdump -C exam4 | head   
00000000  7f 45 4c 46 01 01 01 03  00 00 00 00 00 00 00 00  |.ELF............|
00000010  02 00 03 00 01 00 00 00  e0 dd c3 00 34 00 00 00  |........àÝÃ.4...|
00000020  00 00 00 00 00 00 00 00  34 00 20 00 02 00 28 00  |........4. ...(.|
00000030  00 00 00 00 01 00 00 00  00 00 00 00 00 10 c0 00  |..............À.|
00000040  00 10 c0 00 e0 d5 03 00  e0 d5 03 00 05 00 00 00  |..À.àÕ..àÕ......|
00000050  00 10 00 00 01 00 00 00  94 02 00 00 94 82 0c 08  |................|
00000060  94 82 0c 08 00 00 00 00  00 00 00 00 06 00 00 00  |................|
00000070  00 10 00 00 5f ac 1b b0  55 50 58 21 ff 07 0d 0c  |...._¬.°UPX!ÿ...|
00000080  00 00 00 00 2f d2 08 00  2f d2 08 00 f4 00 00 00  |..../Ò../Ò..ô...|
00000090  80 00 00 00 08 00 00 00  77 1f a4 f9 7f 45 4c 46  |........w.¤ù.ELF|
kevin@slack:~/binaries$ strings exam4 | grep UPX
°UPX!ÿ
UPX!
$Info: This file is packed with the UPX executable packer http://upx.sf.net $
$Id: UPX 3.07 Copyright (C) 1996-2010 the UPX Team. All Rights Reserved. $
ùUPX!u
UPX!
kevin@slack:~/binaries$
Une fois dépacké avec un coup de upx -d, le programme est quasiment celui de l'exam3.

5/ exam5 - explosion de moteur
Je n'ai pas fait cet exam, ni même tenté de le résoudre. Il fait crasher gdb, il fait planter metasm-gui, et selon le formateur seul edb debugger réussit à l'ouvrir après un temps très long. Peut-être un post de blog dans le futur :-)

Une explication de simple1 est à venir, étant un peu différent de ces keygenme.

mardi 10 juillet 2012

RMLL 2012 - jour 2.

1/  Utilisation malveillante des suivis de connexions - Eric Leblond
Pour pallier à la défection de Werner Koch qui devait effectuer une
présentation de Steed, le futur (ou le remplaçant) de PGP, Eric Leblond
redonne la conférence donnée au SSTIC 2012.
Ayant déjà été couvert par des live blogging du SSTIC, je repose
la clavier pour celle-ci.
La conférence est très intéressante, mais le projet STEED m'intéresse énormément. Dommage que Werner Koch n'ait pu se libérer.

2/ Browser ID - Jean-Yves Perrier
Cette conférence va traiter de Persona ou BrowserId et est présentée par un développeur mozilla. Mozilla n'est pas que Firefox, et est une fondation qui oeuvre à un web ouvert.
Il est de plus en plus obligatoire de posséder un login/pass pour pouvoir se connecter sur des sites webs. Ceci pose des problèmes de sécurité et quelques problématiques pratiques, browserId se propose de répondre à ces deux points.

Les pirates savent que les utilisateurs réemploient toujours le même mot de passe car il est difficile de mémoriser au delà de 4-5 mots de passes. Les campagnes de sensibilisation existent, mais ces méthodes continuent de prospérer.
Des modes centralisés existent, mais restent cantonnées à un navigateur alors qu'on surfe aujourd'hui depuis des navigateurs et devices différents (android, puis tablet, puis PC fixe, etc..). Persona essaye aussi de répondre à ce problème.
Facebook propose un système centralisé. De plus en plus de sites acceptent le login facebook par exemple. Toutefois cela permet à des sociétés de profiler très simplement les internautes. Persona essaye donc de proposer un login unique sans possibilité de traçabilité. OpenID répond à cette problématique de traçabilité, toutefois l'usage ne se répand pas en raison de son absence d'ergonomie, l'id ressemble pour l'utilisateur à un nom de domaine et pas vraiment à une identité. Persona va encore répondre à ce point.

Persona va donc essayer d'être bien évidemment sécurisé, simple, SSO, et lié à une identité. Mais la gestion des identités est également un procédé compliqué à mettre en oeuvre pour les sites webs. Dans toutes les bonnes pratiques il est indiqué que les mdp doivent être salés puis hachés, mais tous les sites ne le font pas. Et les sites doivent également protéger les utilisateurs contre eux mêmes (mdp trivial) ce qui est difficile à gérer techniquement. Un développeur de site web souhaite donc lui aussi un système simple sûr, respectant la vie privée, et compatible de partout.

La solution s'appelle Persona et se base sur le protocole BrowserID. BrowserID authentifie un utilisateur de manière sure et ne fait fuiter aucune information à des tiers. L'identité primaire se fait sur l'adresse e-mail en raison de la personnification de celle-ci, les utilisateurs savent généralement que l'adresse les représente. Les e-mails ont aussi l'avantage du pseudonymat :)

Trois acteurs sont au centre du système. Tout d'abord, l'utilisateur, puis le "relying party" (le site web sur lequel on se connecte par exemple), puis le provider qui va authentifier/identifier l'adresse mail. Tout d'abord, l'adresse mail doit avoir été enregistrée avec le provider d'identité (cette étape n'est à faire qu'une fois). Ensuite, une mécanique crypto se met en place pour identifier temporairement l'utilisateur sur le site.

Pour les développeurs, une effort de simplicité est fait puisqu'il faut ajouter une ligne d'include dans le code, un bouton (juste une image) et une fonction qui réagisse au clic sur le bouton. Côté code client, cela représente moins d'une quinzaine de ligne en jquery par exemple. Côté serveur il suffit d'une dizaine de lignes. L'avantage c'est surtout qu'en compromission du site web, aucun mot de passe ne peut être divulgué.

Pour la roadmap une beta va bientôt sortir. Tous les produits mozilla vont se mettre progressivement à l'utiliser (mozilla developper, bugzilla, etc..).La prochaine étape consiste à décentraliser le provider qui est browserid.org, afin d'autoriser n'importe quel serveur de mail à devenir provider. Toutefois un provider d'email ne pourra identifier que les mails de son domaine, seul browserid peut identifier n'importe quel domaine.

3/ Elections HELIOS - Stéphane Glondu
Je ne suivrai pas cette conférence, mettant les dernières modifications sur mes slides.

4/ L'accès à internet est un sport de combat - Kevin DENIS

RMLL 2012 - Workshop Reverse Engineering

RMLL Jour 2. La matinée débute par un atelier de reverse engineering proposé par rootBSD (Paul Rascagnères). L'atelier est composé d'une série de malwares à analyser. Pour la petite histoire, ces binaires sont ceux qui sont donnés lors des entretiens d'embauche de sa société (itrust.lu) .
Exercices classiques dans lequel il faut trouver un mot de passe à donner au binaire qui affiche Godd key or Bad key, ainsi qu'un algorithme de chiffrement/déchiffrement d'image png. On retrouve les outils donnés la veille pendant sa conférence (strings, ltrace, gdb).

L'atelier m'a permis de découvrir un outil: metasm. Metasm est une bibliothèque ruby facilitant l'analyse de malware. metasm est livré avec quelques outils utilisant cette bibliothèque dont une interface graphique qui permet d'afficher le graphe des fonctions. L'outil fait beaucoup d'autres choses, je vais aller me renseigner sur ce programme dont le seul défaut selon le formateur est la légèreté de la documentation (esprit de scapy es tu là? :) ).
Un autre outil à suivre est très peu connu et s'appelle edb debugger.
Le dernier exercice est un binaire qui fait crasher tous les debuggers. Typiquement l'int3 est trappée pour faire crasher gdb. Le binaire fait monter à 100% de CPU metasm sans fin, mais edb parvient, après un temps relativement long à charger le binaire. edb debugger.

Très bon workshop, bons exercices, très bonne pédagogie du formateur :-)

lundi 9 juillet 2012

RMLL (suite) - reverse engineering

Ce message est la suite de mon live blogging pour la première journée sécurité aux RMLL 2012.

5/ Reverse Engineering RootBSD
La conférence est captée en Audio Vidéo. Conférence présentée par r00tBSD aka Paul Rascagneres, mainteneur et auteur du projet malware.lu. malware.lu c'est 1.2Million de malwares et 800 utilisateurs, ainsi que des articles.

Cette présentation va montrer et décrire les outils libres utilisés pour faire du reverse, mais elle démarre par des rappels juridiques. Il semblerait que vis-à-vis de la loi française, le reverse de malware soit possible.
  • Les outils ltrace & strace: Ces outils donnent les syscalls utilisés par les binaires, mais ont toutefois le défaut de devoir lancer le binaire. Ces deux appels utilisent en fait ptrace. ptrace est lancé avant le binaire, lui donne la main et peut la reprendre à tout moment. ptrace permet vraiment de monitorer entièrement un binaire, il a notamment servi à reverser skype.
  • LD_PRELOAD: une variable d'environnement connue sous tous les unix, qui permet sous linux de donner des bibliothèques qui seront chargées en priorité (hook de librairie). Cela permet de surcharger les fonctions de librairies de l'OS. Cette méthode ne fonctionne pas sur les binaires setuid pour des raisons de sécurité.
  • SystemTap: développé par redhat, qui ressemble à dtrace de solaris. Il existe un grand nombre de sondes (réseaux, IO, etc..) et systemtap permet d'écrire des programmes qui s'appuyent sur les données de ces sondes. Sert aussi pour mesurer les perfs.
  • Wireshark: quelquefois le reverse est inutile, une simple trame réseau est suffisante.
  • Analyse de mémoire: généralement un binaire malveillant sur disque est compressé ou obfusqué et se déchiffre en mémoire. Dans une VM on peut lancer le malware, et dumper la RAM de la VM. L'analyse de dumps windows se fait avec volatility et volatilitux pour linux. Une live demo est montrée sur une machine windows. Puisque voloatility n'est pas lancé sur la machine cible, il est impossible pour le binaire malveillant de modifier les outils d'analyse.
La suite de la présentation est plus tourné vers l'assembleur, les non geeks et les personnes facilement impressionnables sont priés de quitter la salle :) Quatre outils vont être évoqués.

  • Cuckoo: cuckoo est une sandbox virtualbox qui logge tout ce qu'un binaire fait (fichiers, réseaux, Base de registre windows, etc) et  produit un rapport. En fin d'analyse, la VM est restaurée. L'analyse est automatique.
  • gdb et winegdb: le debugger le plus connu. gdb permet de mettre des points de pause (breakpoints), fonctionner en pas à pas, montrer le code assembleur et beaucoup d'autres choses. Une demo sur un binaire est présenté avec mode pas à pas et présentation des registres.
  • Virtualbox et gdb: lorsque gdb ne suffit pas, il est possible de l'utiliser avec virtual box. Le conférencier fait très fort en présentant l'analyse de Flame (un virus dont vous avez entendu parler). Le conférencier fait une bonne explication en indiquant comment utiliser Flame contre lui-même en lui faisant décoder chacune des chaînes obfusquées, tout ça sans même connaître le code de déchiffrement!
  • ripper metasm: il s'agit d'un wrapper permettant d'extraire une fonction d'un malware et de trouver les arguments qui lui sont passés. Ceci permet ensuite d'inclure cette fonction dans n'importe quel programme. Ceci es très utile lorsque des opérations d'obfuscation existent dans les malwares. Les phases d'analyse de ces fonctions étant fastidieuses autant demander au malware de faire le travail lui même :)
Mais l'analyse dynamique n'est pas le seul mode d'analyse car quelquefois les malwares détectent les environnements de debugs. Il faut donc effectuer des analyses statiques du code. metasm permet de faire de l'analyse statique. Une courte demo est faite, puisque tout ceci sera revu dans le workshop de mardi matin. Dans les questions est posé la question d'Ida. Le conférencier indique qu'Ida est encore au dessus des outils libres bien que metasm progresse bien.

Je ne ferais pas de suivi demain matin, étant au workshop reverse engineering.

RMLL2012 - Suricata - nmap v6 - NAXSI

Je suis aux RMLL 2012 en train de suivre le track sécurité. Voici un live blogging des trois premières conférences.

1/ Suricata Eric Leblond
Suricata est une sonde IDS/IPS. La conférence est présentée par Eric Leblond développeur de Suricata, contributeur netfilter et membre de la fondation suricata au sein de l'OISF (www.openinfosecfoundation.org , organisation "non-profit"). Suricata est né de la lourdeur des 400000 lignes de codes de Snort. Il a été décidé de réécrire une nouvelle lib d'analyse plutôt que de continuer à modifier Snort. La Fondation est financée à l'orgine par le gouvernement US, mais les décisions restent communautaires. Le but de l'OISF est d'obtenir de nouvelles technologies d'IDS: performances accrues, utilisation de l'accélération hardware et multi OS (linux BSD, windows). Les challengers sont BRO et Snort. (Et l'orateur précise que même si suricata dérive de Snort, il est bien plus performant que son aîné :) )

Dans les fonctionnalités, Suricata fait nativement de l'IPv6, multi-thread, sait monter à 40GBp/s, et reconnait les flux indépendamment des ports. Suricata reconnaît les modes captures classiques, pcap, AF_PACKET, PF_RING pour l'IDS. Concernant l'IPS NFQUEUE, et ipfw. Les sorties sont en fastlog, unified log, prelude. De manière très simplifiée, Suricata fait le lien entre ce qui se passe sur le réseau et l'ajout d'une ligne dans les logs. La configuration de Suricata se fait par des règles inspirées par la syntaxe de Snort.
Suricata possède une librairie HTTP (libHTP )dont le rôle est de parser facilement les flux HTTP qui représentent la grande majorité du trafic réseau. Un exemple donné présente un parsing permettant de bloquer le chat de facebook. Pour ce faire, Suricata sait reconstruire les flux afin de  les normaliser pour les parser en évitant les problèmes réseaux  (fragmentation, etc.. ) Suricata sait poser des variables, les incrémenter et faire des choix en relation à leurs valeurs.

La version 1.3 sortie le week-end précédent les RMLL (bravos aux développeurs, même s'il s'agit plus d'un hasard :) ) amène plusieurs nouveautés. Tout d'abord, la libHTP permet une axtraction des fichiers téléchargés. Ceci permet une analyse plus fine dans les règles. Par exemple prévenir lors du download d'un fichier exe windows, ou le stocker pour analyse ultérieure. L'extraction de fichiers est à ce jour limité à HTTP, même si le mail devrait être supporté. Ensuite, Suricata sait analyser les handshakes SSL à l'aide d'une base de code maison, openssl étant trop gros pour être audité. Le parser SSL vient de l'ANSSI (Pierre Chifflier). Les règles permettent de trier selon le DN ou l'ISSUER, bientôt le fingerprint du certificat, ou les tailles de clés. Le parser ne gère actuellement que le premier certificat de la chaîne SSL. Les certificats ne peuvent pas non plus encore être stockés à la manière de HTTP. Enfin, la 1.3 vient avec des perfs accrues, notamment dans le cas de multicores.

La conférence finit par la roadmap, dans laquelle vient l'IP et la DNS reputation, SCADA et le geoip. C'est un produit librement utilisable, il existe des liveCD, et
des infos, voir le site de suricata.

2/ nmap v6 Henri DOREAU
On ne présente plus nmap (15 ans déjà!) qui est un scanner de port dans lequel est ajouté un système de reconnaissance d'applications et d'OS. Il intègre aussi un moteur de script et des outils compagnons. La communauté est très vivante et remonte beaucoup de statistiques et de  scripts NSE (aujourd'hui plus de 400 scripts). nmap est aussi une star du cinéma ! le site contient la liste (longue) dans lequel nmap apparaît :).

Les scripts NSE sont des scripts LUA. 4 modes d'exécutions sont présent. Les prerules, qui est lancé avant le scan nmap, le service, lié au service, host, lié à l'host, et les postrules qui servent surtout à réaggréger les résultats. Un script a deux fonctions de base: la rule qui renvoie un booléen indiquant s'il doit se lancer ou non, et une action qui est lancée si le booléen est vrai. les scripts ont plusieurs bibliothèques permettant des renormalisations des résultats ou des modes d'affichages. NSE est monothread, avec différentes manières pour simuler du parrallélisme afin de faciliter la vie des scriptwriters. Les scripts sont écrits pour ne pas avoir de dépendances. Exemple:
nmap --script samba-vuln-cve-2012-1182 <target>
nmap --script "http-* and not brute" <target>
le site http://nmap.org/nsedoc listes les scripts actuels, par catégorie.

La seconde amélioration concerne IPv6. Toutes les fonctionnalités de nmap sont portées en IPv6 (si tant que ça ait du sens) et toutes les plateformes ont cette amélioration. Certains points ont été simples à porter, comme le scan TCP, d'autres ont du être entièrements réécrits comme la détection d'OS. IPv6 devient important et nmap a voulu le supporter, surtout par le fait que tous les OS majeurs sont dual stacks. Il existe des scripts de découvertes d'hôtes pour éviter de scanner des plages entières IPv6. Le passage a IPv6 a été l'occasion de plusieurs nettoyages de codes et améliorations.

Les autres améliorations concernent plusieurs points de moindres importances (en terme de nombre de slides :) ). Tout d'abord la plage des 1000 ports classiques a évolué suite aux remontées utilisateurs. Une autre amélioration concerne nping qui ressemble à hping2 en plus évolué. nmap signifie network mapper, mais il ne fait des cartes que depuis la version 6 :) Zenmap propose d'afficher une carte représentant les réseaux scannés (15 ans pour mériter son nom, bel effort de nmap :) ). Une autre grosse amélioration concerne le web, grâce au Gsoc. C'est une première implémentation, pas encore au niveau des scanners webs habituels, mais c'est un début..

La roadmap du produit concerne la lib HTTP qui doit évoluer (SPDY?). L'outil compagnon ncat doit aussi être revu. NSE va continuer d'évoluer pour être de plus en plus puissant, les outils compagnons devraient s'y voir adjoints. Une combinaison des scans IPv4 et IPv6 est à l'étude. Un travail est en cours pour scanner au travers de relais, ou SSH. Et NSE pourrait se voir adjoindre un Updater pour synchroniser l'ensemble des scripts, leur base évoluant très vite.

3/ NAXSI Didier CONCHAUDRON Sébastien BLOT
D'une part le web est partout. D'autre part, les vulnérabilités web existent en plus grand nombre. Ces failles touchent tout le monde, aussi bien les petits hébergeurs que les grosses compagnies. Ces failles modifient l'aspect du site jusqu'à l'exfiltration de données. On constate que le niveau moyen des développements webs n'est pas très bon, et cet état de fait persiste, d'où l'augementation des attaques. Les statistiques fournies montrent bien l'étendue du problème. La première cause de ces failles vient généralement de la faiblesse du code, ainsi que de la non connaissance des mécanismes de sécurité des
développeurs. (Je rappelle que la conférence est faite par une équipe de pentesteurs)

La solution classique consiste à corriger le code. Et lorsque le patch du code est impossible, il faut alors mettre un WAF. "WAF est à HTTP ce qu'un firewall à OSI layer2".

NAXSI vient d'une idée de Thibault Koechlin, de NBS systems. Le problème des WAF classiques sont le prix trop elevés pour les WAF commerciaux, et mod_security est trop faible en performances. Enfin, il faut du temps pour garder les signatures à jour. NAXSI est basé sur nginx, bonne performances, sans mise à jour (que de la reconfiguration).

NAXSI a un ruleset de base sur lesquelles seront construites les règles pour protéger un site. NAXSI contient 35 règles (SQLi, XSS, etc..) qui ont une pattern, un score, des matchs zones et un Id. Ce set réduit de règles et une naïveté dans les regexp (pas de reconstructions, pas de sessions, etc) permet de grandes perfs, mais oblige à un apprentissage pour une création de liste blanche. NAXSI a un très faible overhead en terme de perfs comparés à un nginx 'brut'. NAXSI fonctionne aussi seulement en mode IPS ou il logge uniquement les attaques.

NAXSI est connu pour avoir protégé le site de Charlie Hebdo alors qu'il était massivement attaqué. Cela lui a permis un test haute performance puisqu'à l'époque 80% du trafic était malveillant.

4/ Lemon LDAP Clément OUDOT.
Je ne suis pas cette conférence.

mardi 19 juin 2012

Classification des impacts des failles de sécurité

Catégoriser l'impact des failles de sécurité permet de les classifier rapidement afin de prendre des contre mesures. Cette catégorisation n'est pas évidente de premier abord tant il existe d'attaques et de failles différentes. De plus, l'impact d'une faille de sécurité dépend d'un grand nombre de paramètres exogènes. La classification des failles de sécurité peut donc aller du plus simple: "pwn" ou "pas pwn" au plus complexe ou chaque faille de sécurité est différente: depuis l'augmentation de ressources consommées à la lecture de deux octets de mémoire noyau ou de la diminution de l'espace de recherche pour les bruteforce jusqu'à l'impact financier chiffré ou la baisse d'une image de marque.

Pour extraire des impacts pragmatiques utilisables et réalistes, on peut partir des fondements de la sécurité informatique. Une faille de sécurité remettant en jeu un de ces fondements, on peut en tirer un impact. Idéalement, chaque faille de sécurité devrait n'appartenir qu'à un seul impact. Wikipedia donne une liste intéressante d'enjeux de la sécurité des SI.

Nous tirons donc les impacts suivants après un petit travail de classification d'un nombre conséquent de failles de sécurité:
  • Déni de service : Le service informatique n'est plus rendu. Le déni de service peut revêtir également un grand nombre de méthodes (DOS, DDOS, consommation de CPU par collision de hachés, remplissage de disque, etc..).
  • Falsification d'identité : Dans cette catégorie va se retrouver deux types de faille de sécurité. Tout d'abord les vols d'identités (vol de cookie, vol de credential, bruteforce...) puis les élévations de privilèges.
  • Compromission de données : On va retrouver ici un certain nombre d'altération de données. Tout d'abord la diffusion non autorisée de données, leur modification ou leur destruction. Ensuite, nous allons classer ici toute la partie crypto avec le cassage de code.
  • Exécution arbitraire de code : cette définition se passe presque d'explication. Peu importe le moyen utilisé (overflow, RFI, SQL injection, exécution locale ou remote...) l'exécution arbitraire de code par un attaquant sur un système à protéger est un impact à considérer.
  • Traçabilité / preuve : l'informatique est censée assurer une certaine traçabilité des traitements, ou de signature (et non répudiation). Nous allons retrouver ici les modifications de journaux ou les attaques sur les signature électronique (MD5 par exemple).
  • Équipements de sécurité : Nous allons classer dans cette famille d'impact les contournements des firewalls, des antivirus et des sondes (DPI/IDS/IPS).
Nous obtenons donc 6 impacts unitaires qui semblent recouvrir l'ensemble du spectre des failles de sécurité. 6 est un bon chiffre, ni trop pour éviter d'avoir des inventaires à la Prévert, ni trop peu pour être trop vague. Cette liste est bien évidemment discutable (si vous avez des remarques, je les accepte avec plaisir), mais avec ces 6 impacts je ne trouve pas de failles qui ne rentre pas dans cette définition.

mercredi 23 mai 2012

Acheter et vendre des exploits - part2

[EDIT 1/06/2012 ajout de 2 liens en conclusion]

Ce post est la suite du message http://exploitability.blogspot.fr/2012/05/acheter-et-vendre-des-exploits-part1.html. Ce second post va reparcourir les sept points soulevées par Charlie Miller en les adaptant à la situation actuelle.

1/ Valeur de l'exploit
Ce point particulier varie légèrement puisqu'une faille corrigée peut conserver de la valeur. On voit apparaître des failles demi-days qui sont des failles de sécurité patchées récemment. Selon le but de l'acheteur (cible localisée ou ratissage large), une exploitation fiable d'une faille corrigée peut avoir un interêt certain. A ce titre, on observe que la faille MS12-020 continue d'être la plus recherchée sur les modules metasploit, alors même que le patch existe, et que la faille n'a toujours pas été prouvée! Toujours chez metasploit, un programme d'achat de fiabilisation de failles de sécurités existe, prouvant ainsi qu'un patch publié n'enterre pas forcément la faille de sécurité associée.

2/ Prix de vente
Depuis 2007, quelques prix ont commencé à apparaître. Certains fiables, d'autres moins. Pour la fiabilité, il suffit de se référer aux programmes de bug bounty des éditeurs (une recherche google donne un grand nombre de sociétés offrant des bug bounty). Différents prix sont proposés:
Dans le moins fiable, il y a les prix du "marché noir". Une grille circule:
(tirée de l'article http://www.forbes.com/sites/andygreenberg/2012/03/23/shopping-for-zero-days-an-price-list-for-hackers-secret-software-exploits/ )
On retrouve peu ou prou les prix du pw2own contest (20000-60000$) et celui de Charlie Miller (80000$). Cette grille à un autre interêt, j'y reviendrai plus tard.

Enfin, il existe entre les deux les sociétés spécialisées (voir point 3/ ) et les prix sont soit absents, soit aux alentours de 10000$ la faille.

Ce qui saute aux yeux, c'est la disparité des tarifs (!). Les bounty sont complètements décorrélés des autres prix. Par exemple pour un bounty chrome à 3000$, on doit trouver une société spécialisée à 10000$, ou le pw2own à 20000 et enfin le marché noir à +80000$ (!).

Enfin, on lit beaucoup d'autres prix, pas toujours réalistes. VUPEN, à la suite de sa victoire au pwn2own indique vouloir conserver une faille Chrome et refuse même le prix de 60000$. Il ajoute qu'il conserverai cette faille même dans l'hypothèse ou Google lui proposerai 1 million de dollars! Plusieurs spéculations sur le prix délirant des failles ont démarré sur internet. Néanmoins Tavis Ormandy fait remarquer "It's common to see the shadier side of infosec exaggerate about big money deals, you can lookup actual revenue data at http://www.infogreffe.fr", ce qui signifie que Vupen surévalue le prix de vente de ses failles, car une faille à 1M lui fait presque 2 ans de chiffre d'affaire. [mais cela semble logique pour un vendeur de gonfler les tarifs :-) et il y a peut-être des clauses de confidentialités sur cette faille par ailleurs.. ]

3/ Trouver l'acheteur
Cela semble beaucoup plus facile qu'en 2007 pour les programmes bounty et les sociétés spécialisées. Je ne les listerai pas toutes ici, on peut en trouver un grand nombre sur ce lien (la liste date de 2009, cela a pu évoluer) ou celui-ci (qui contient aussi une bonne liste de bounty programs).
Pour le marché noir, c'est toujours aussi opaque, mais c'est aussi la définition du marché noir (on connait quelqu'un qui connait quelqu'un de fiable qui connait quelqu'un... :) ).
Il semble donc beaucoup plus simple aujourd'hui de vendre des failles de sécurité, en tout cas à bas prix.

4/ Vérification de l'acheteur
Charlie Miller souhaitait connaître les intentions de l'acheteur avant de vendre. Pour les bug bounty, pas de problèmes moraux à avoir. Pour les sociétés généralistes d'achats, il est fait mention de diffusion contrôlée, limitée, réservée aux spécialistes et chercheurs. Je ne sais pas jusqu'a quel degré de cynisme on peut le lire. Il s'agit généralement de sociétés vendant de l'outil cyber-offensif ou des prestations cyber-offensives. Je regarderai plutôt du côté des clients de ces sociétés, mais il n'y a aucune publicité à ce sujet. Vupen indique travailler avec des gouvernements entre autre.

5/ Démonstration de l'exploit
Actuellement, c'est un jeu de confiance. Pour les bounty ou les sociétés ayant pignon sur rue, c'est le chercheur qui doit fournir la preuve de sa faille avant toute négociation ultérieure. Pour le marché noir, étant opaque, pas d'autres infos. Par contre, il est fait mention d'un tiers de confiance qui met en relation des vendeurs et des acheteurs (moyennant pourcentage toutefois), bien qu'il faille lui fournir les preuves complètes d'un exploit. Il se fait joindre sur twitter et s'appelle thegrugq. Apparemment, il suffit de lui fournir un exploit, et il trouve un vendeur. Toutefois, je n'ai pas trouvé d'information fiable à ce sujet, uniquement des liens citant un autre lien "qui dit que", donc je ne garantirai pas la fiabilité de cette méthode. (d'ailleurs si quelqu'un à des infos fiables là-dessus...)

6/ Propriété intellectuelle de l'exploit
Quelques sociétés d'achat de failles font signer des NDA, mais comme le disait déjà Charlie Miller, il existe toujours pour le vendeur un moyen de vendre deux fois un exploit sans que cela ne soit prouvable par le premier ou le second acheteur. C'est une forme d'honnêteté de la part du vendeur. Parmi les sociétés qui achètent, on trouve d'ailleurs des exigences délirantes comme la fourniture de plusieurs pièces d'identités, plus des adresses postales et numéros de téléphones [Et là, c'est une question de paranoïa ou de cupidité sachant qu'avec tout ce qui est demandé la société peut facilement voler l'identité de ceux qui traitent avec eux...].

Conclusion/
Contrairement à 2007, il est aujourd'hui plus simple de vendre des exploits (à bas prix) à l'aide des bugs bounty. Les sociétés spécialisées ou le marché noir n'offrant pas suffisamment de garanties de sérénité au vendeur.
Le tableau montré plus haut est intéressant à plus d'un titre. La liste des exploits présentée fait immédiatement à une volonté offensive et ciblée. On cherche des failles dans pdf, doc (spear phishing), les navigateurs les plus courants, ou les systèmes (l'élévation de privilège je pense) ou les smartphones qui sont remplis d'informations personnelles à haute valeur (carnet d'adresses, appels émis et reçus, position géographique etc..). Cette liste semble à des antipodes des préoccupations d'un chercheur en sécurité de l'information. Elle semble plutôt construite sur des besoins d'espionnage, ce qui fait penser aux états. On sait que la guerre cyber va devenir de plus en plus importante jusqu'à imaginer des mécanismes de vente d'armes cyber aussi protégées que les armes chimiques ou nucléaire (Kaspersky, Cebit 2012). Comme le fait remarquer Ben Nagy sur une mailing list, vendre des exploits ne fait pas de vous un inconscient qui dégoupille une grenade au milieu d'une foule. Vendre un exploit aujourd'hui, c'est le fournir à un gouvernement qui va s'en servir à la manière d'un sniper dans un but précis et encadré [1] (on retrouve encore cet aspect sécurité informatique et gouvernements..).
Cela tend donc à signifier que la faille qui se vend aujourd'hui est forcément offensive, ciblée vers l'utilisateur final et achetée par les gouvernements. Pour le reste, s'il n'existe pas de bounty, publiez un CVE, ou sur full-disclosure, ça vous apportera au moins la gloire :-) Il est d'ailleurs possible de contacter secunia qui s'occupe de gérer toute la partie ennuyeuse (communication à l'éditeur concerné, prévention des différents CERT, numérotation CVE etc...) et qui conserve votre nom au crédit de la faille! Bon, la rémunération oscille entre rien du tout et un tee-shirt, mais c'est toujours un début :-)

[1] Je ne fais que résumer le propos de Ben Nagy, ce n'est pas une opinion personnelle.

[EDIT 01/06/2012] : Bruce Schneier revient sur le concept de marché de la vente de vulnérabilité : http://www.schneier.com/blog/archives/2012/06/the_vulnerabili.html et fournit un autre tableau qui est un sondage effectué en 2010 auprès des vendeurs de failles de sécurité http://unsecurityresearch.com/index.php?option=com_content&view=article&id=52&Itemid=57
Il ajoute qu'un des problèmes avec des prix d'achats trop élevés réside chez les éditeurs de logiciels. A +100k$ la faille, un programmeur pourrait laisser de manière intentionnelle un léger bug exploitable afin de le revendre sous le manteau un peu plus tard.

mercredi 9 mai 2012

Acheter et vendre des exploits - part1 2007

Il y a cinq ans Charlie Miller, un chercheur en sécurité informatique publiait un document expliquant les difficultés pour vendre un exploit. Ses arguments sont construits à partir de la vente de deux exploits en 2007, mis ils restent pertinents aujourd'hui. Cet article est écrit du point de vue d'un chercheur en sécurité qui veut vendre ses exploits, au meilleur prix. Les aspects éthiques, corrections de la faille ou diffusions de celle-ci, etc, ne l'intéressent pas. On peut le considérer comme un mercenaire de la vente de la faille, son discours "No more free bugs" (Cansecwest 2009) allant dans ce sens.

Lecture commentée de l'article de Charlie Miller.

1/ Valeur de l'exploit
Tout d'abord la valeur d'une faille dépend d'un paramètre entièrement indépendant du vendeur et du chercheur qui est sa publicité. En effet, une faille mise en vente peut voir son prix tomber à zéro le jour où elle est soit publique, soit patchée. La rapidité des négociations est donc un point primordial. Je suis d'accord avec lui, même s'il existe encore un laps de temps entre un exploit pleinement fonctionnel tenu secret, la divulgation d'une faille, son correctif et la diffusion du correctif (on parle bien aujourd'hui des demi-days).

2/ Prix de vente
Ensuite, le prix de vente est un jeu d'aveugles. Du fait de la nature de ce commerce, il est impossible de connaître un tarif honnête. Quelques tableaux de ventes existent sur internet, très flous, mais aucun cours légal n'existe. Je pense toutefois qu'un chercheur en sécurité peut estimer la valeur de sa faille. Et que la fiabilité de l'exploit est directement liée avec sa valeur. La faille de sudo n'a pas la même valeur selon la publication faite par l'auteur que celle retravaillée ensuite qui fonctionne plus largement, et qui bypasse divers mécanismes de sécurité.


3/ Trouver l'acheteur
Pour Charlie Miller, il n'existe pas de moyen simple de trouver un acheteur. Il a du ouvrir son propre agenda (il a a travaillé 5 ans à la NSA quand même) et appeler un peu au hasard ses contacts avant de trouver un intermédiaire qui pouvait le mettre en relation avec une agence gouvernementale intéressée par son exploit. Le risque pour lui était grand de tomber face à des charlatans (au mieux) ou des mafias (au pire). Pour moi, ce point a bien évolué. Il existe des entreprises ayant pignon sur rue achetant des exploits, ou des programmes d'achat de failles (Bug bountys chrome, firefox, etc..). Toutefois les prix sont bien différents[1].

4/ Vérification de l'acheteur
Les acheteurs étant par essence peu connus, il est difficile de leur faire confiance à priori. Et comme le vendeur est pris par le temps puisqu'il doit vendre avant que la faille soit redécouverte et que cet évènement peut se produire n'importe quand, le temps de vérifier les intentions de l'acheteur est bien maigre.

 5/ Démonstration de l'exploit
De plus, pour vendre l'exploit il faut démontrer son existence. Mais la simple évocation d'un exploit peut permettre à quelqu'un de le retrouver! Indiquer à un acheteur potentiel qu'une faille est en vente sans plus de précision n'aboutira pas. Et indiquer qu'on possède un buffer overflow sur wu-ftpd avant authentification permet à l'acheteur de manifester son interêt, mais est une information suffisate pour permettre à un attaquant suffisamment skillé de redécouvrir la faille, faisant immédiatement perdre le bénéfice de la vente!
En absence d'un tiers de confiance, soit l'acheteur paye sans voir, soit le vendeur donne l'exploit en espérant un chèque un peu plus tard. Mais comme le vendeur espère tirer le maximum de profit de son exploit, il doit donner des détails précis sur celui-ci! J'avais lu un découpage des hackers en 5 catégories:
  • Ceux qui trouvent des failles sur commande, sur n'importe quel logiciel. Au monde, il y en a très peu.
  • Ceux qui trouvent des failles par eux-mêmes. Il n'y en pas beaucoup non plus. (Charlie Miller en fait donc partie, selon lui)
  • Ceux qui peuvent trouver une faille lorsqu'on leur dit ou chercher ou lorsqu'ils on un exploit partiel, ou un patch. Ce sont d'eux que Charlie Miller a peur.
  • Ceux qui comprennent les enjeux liés par une faille de sécurité, sont capables de monter des PoC. Il y en a encore très peu. Ce sont eux les acheteurs pour Charlie Miller.
  • Et les autres. Ce sont eux qui préconisent de mettre un antivirus et un firewall personnel par exemple.
6/ La propriété intellectuelle de l'exploit
Dans ce jeu secret de vente d'exploit, le vendeur peut se faire doublement avoir. Tout d'abord, un acheteur intéressé peut refuser la vente à tout moment. Une des raisons du refus étant que l'acheteur, à l'aide des informations fournies par le vendeur, a retrouvé la faille et produit un exploit. A quoi bon payer dans ce
cas? Et l'acheteur peut faire un coup double en revendant à son tour l'exploit à un tiers! Ces négociations étant secrètes et toujours en l'absence de tiers de confiance, l'inventeur original n'a aucun moyen de faire valoir ses droits.

7/ Exclusivité de droits
Le point 6/ a immédiatement une position similaire du côté du vendeur. L'ensemble étant secret, le vendeur pourra toujours vendre son exploit à autant de parties souhaitées! Charlie Miller, pourtant intéressé par l'argent depuis le début se tient à une honnêteté stricte (ou tout du moins le laisse t'il entendre). Il conçoit que l'acheteur prend un risque en achetant l'exploit, mais il est prêt à céder les droits à un seul acheteur, bien qu'il sache très bien qu'un acheteur ne pourra jamais prouver que le vendeur ait vendu cet exploit à plusieurs personnes.

Charlie Miller propose ensuite diverses solutions pour vendre des exploits de manière sécurisée sur lesquelles je ne reviendrai pas, la principale étant d'avoir un tiers de confiance, mais comme il l'indique "Legal issues should be adressed".

Il relate ensuite comment avoir vendu deux exploits. Le premier touchant un démon linux courant, proposé 80000 dollars à une agence américaine (je suppose un acronyme à 3 lettres) qui lui a finalement été acheté 50000. Il est amer sur cette vente car il a estimé seulement après coup pouvoir démarrer les négociations bien au delà de 80000$. Et à 80000$ l'exploit, on comprend mieux son combat pour le "no more free bugs". Un article chez Sid de 2009 table sur un salaire annuel de 130000$ et des ventes d'exploits vers 10000$. L'article finit en disant "Quiconque pense vivre de ces trouvailles aura donc intérêt à sérieusement se creuser le citron pour sortir une douzaine de failles intéressantes, sous peine de devoir se diversifier sérieusement...". A 80000$, la problématique est différente et permet de passer quelques mois pour une faille[2].
Le second exploit est un semi-échec puisqu'un patch est sorti avant que la vente ne termine (12000$ pour un exploit sur powerpoint).

Je pense que Charlie Miller a raison sur les problématiques de vente d'exploit, mais qu'il oublie un point essentiel. Il oublie qu'il est Charlie Miller, chercheur en sécurité reconnu, auteur de plusieurs failles de sécurité, auditeur de conférences en sécurité, etc..
De fait, lorsqu'il propose à la vente un exploit, il peut toujours l'envoyer à l'acheteur sans trop de risques, surtout s'il s'agit d'une agence de sécurité américaine et ce, pour deux raisons.
La première étant qu'il a comme il le dit lui même la possibilité de mettre à zéro la valeur de cet exploit en contactant l'éditeur de sécurité. Cette force oblige l'acheteur à se manifester rapidement [3]. Il perd une vente, mais l'acheteur peut voir son investissement réduit à néant.
La seconde raison vient de la nature de l'acheteur. Lorsque vous êtes une grosse agence de sécurité nationale et qu'un auteur d'exploit reconnu comme Charlie Miller vient vous vendre quelque chose, vous ne pouvez pas le laisser repartir déçu sinon il ira vendre ses exploits à d'autres personnes (où d'autres gouvernements). Et de fait, je pense que l'acheteur n'achète pas qu'un exploit, il achète également la possibilité de continuer à collaborer! Pour cette raison, il aurait du être quasiment sûr d'être payé tôt ou tard.
Moralité: si vous êtes Charlie Miller, vous pouvez vendre des exploits sans trop de risques. Si vous êtes inconnu, diffusez les plutôt dans des conférences de sécurité afin de vous faire connaître pour pouvoir vendre les suivants sans risque :-)

Ce post étant un peu long, je le coupe en 2. La seconde partie va traiter de la vente d'exploit aujourd'hui en 2012.
...TO BE CONTINUED


[1] A titre d'exemple, le bounty max de Chrome valait 3133,70 dollars alors qu'une faille Chrome était estimée à +100000 dollars...
[2] D'un autre côté, Kostya Kortchinsky indique ne pas avoir plus de 5 jours à passer sur la pseudo faille du serveur TSE de microsoft.
[3] Même si la timeline de la vente est assez effrayante de ce point de vue. Proposée le 27 juillet, chèque reçu le 9 septembre. Cela laisse suffisamment de temps à l'acheteur d'utiliser l'exploit dans une campagne d'attaque ciblée avant de se rétracter ou de diffuser publiquement la faille.