Autoblog d'Exploitability

Updating database... Please wait.

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.

Afin de promouvoir la norme HTML5, mozilla a publié un jeu n'utilisant que cette technologie : browserquest.
Le jeu ressemble à Zelda, et plusieurs références très geeks émaillent le jeu (Nyan cat, Portal, Star wars, Le seigneur des anneaux, Mario bros, Rickroll, etc..).

Le principe du jeu est simple, vous démarrez simple joueur avec une petite épée et au fur et à mesure de la progression, des armes plus puissantes peuvent être utilisées. Un mécanisme d'"achievement" est présent, vous récompensant de différentes réussites (se faire rickroller, tuer 50 ennemis, etc..). Je n'ai pas joué fort longtemps, mais la carte à l'air assez grande. Le problème dans ce genre de jeu, c'est que l'on commence assez faible et que le moindre ennemi vous achève en un tour de jeu ce qui est vite assez frustrant.

Dans le temps, les joueurs tentaient souvent de modifier les sauvegardes pour s'arroger des vies supplémentaires. Nous avons lu que le jeu autosauve les caractéristiques du joueur (HTML5 et Localstorage).
Créons un joueur appelé Palladin (oui, je fais original):


Fermons l'onglet du navigateur. Si je rouvre le navigateur on me propose bien de nouveau ce personnage:


Il est donc enregistré quelque part.

$ grep -rl Palladin .mozilla/firefox/
.mozilla/firefox/70willuz.default/webappsstore.sqlite

$ sqlite3 webappsstore.sqlite
SQLite version 3.7.5
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .table
webappsstore2
sqlite> .schema webappsstore2
CREATE TABLE webappsstore2 (scope TEXT, key TEXT, value TEXT, secure INTEGER, owner TEXT);
CREATE UNIQUE INDEX scope_key_index ON webappsstore2(scope, key);
sqlite> select scope from webappsstore2;
 (...)
gro.allizom.tseuqresworb.:http:80
sqlite> 

L'utilisateur averti comprend vite que le domaine se lit à l'envers, on lit bien browserquest.mozilla.org

sqlite> select value from webappsstore2 where scope='gro.allizom.tseuqresworb.:http:80';
{"hasAlreadyPlayed":true,"player":{"name":"Palladin","weapon":"sword1","armor":"clotharmor","image":"data:image/png;base64,iVBO (...) gg=="},"achievements":{"unlocked":[4],"ratCount":1,"skeletonCount":0,"totalKills":1,"totalDmg":24,"totalRevives":0}}

Il y a un an, la compagnie RSA annonçait qu'une partie de son infrastructure était sous le contrôle d'attaquants via une attaque de type APT (Advanced Persistent Threat). Le post de blog très technique de RSA (voir la 2e partie du message "anatomy of an attack") indiquait un spear phishing  associé à un 0day, puis un RAT qui a permis à un attaquant de se déplacer latéralement dans le réseau extrêmement rapidement avant d'exfiltrer les données. L'attaque a été rapide car RSA avait détecté la brèche, mais n'a malgré tout pas pu éviter le vol de données.

La compagnie command five a produit un rapport sur les canaux de communication utilisés par des APT d'un groupe de pirate qui utilise les mêmes systèmes et serveurs de commandes et contrôles. Parmi les compagnies citées nous retrouvons RSA. Le rapport confirme effectivement le post de blog à quelques détails près (apparemment le RAT pour RSA n'était pas poison ivy, mais murcy). Ce rapport permet d'éclairer certains points très intéressants sur le mode de fonctionnement et sur la détection des APT.

1/ L'installation du RAT
Rien de bien nouveau, nous retrouvons dans les cas exposés un RAT qui s'installe via du spear phishing et éventuellement un certificat valide volé dans certain cas. Les RAT n'ont rien de spécialement avancé puisque ce sont des outils que l'on trouve sur internet, certains d'entre eux existant en version commerciale (!) : X-shell par exemple ou Poison Ivy.

2/ Le contrôle des machines
Pour contrôler les machines, les ports et protocoles classiques sont utilisés: DNS puis du HTTP ou HTTPs. Les machines se connectent régulièrement sur les serveurs C&C et envoient de l'information.
Rien de très avancé non plus, depuis les réseaux RFC1918 il est plus simple à une machine d'un LAN de se connecter sur une machine à IP publique que l'inverse.

Certains noms de domaine sont choisis pour ressembler à des domaines connus, comme
*.windowupdate.com (il manque le 's' à windows) ou *.alyac.org (alyac est un outil de sécurité) afin de leurrer l'oeil non exercé d'un administrateur vérifiant ses logs.

Les protocoles sont basés sur du HTTP, c'est du GET ou du POST normal avec des données, ce qui signifie qu'un firewall ou un proxy applicatif laissera passer ces données.

3/ Comportement et détection de ces RAT
Commençons par le mauvais côté, celui ou il est difficile de se défendre.

• Révocation de certificats: Comme l'indique le rapport, certains certificats n'ont pas été révoqués pour ne pas pénaliser l'usage d'outils légitimes étant signés par celui-ci (!)
• Analyse antivirale: Bien qu'utilisant un nombre réduit de RAT, les attaquants n'hésitent pas à les recompiler, cela ayant comme effet de bord de rendre toute détection antivirale basée sur un hash du binaire inefficace (l'auteur du rapport conseille de faire un hash de certaines parties, le .rdata .text etc.. car elles sont souvent identiques).

Le bon côté c'est qu'il existe des moyens de détecter ces APT en raison de leur comportement. Ils existe deux types de défense à ces APT, tout d'abord celles qui existent déjà et dont les entreprises sont coupables de ne pas les avoir mises en oeuvre, et les défenses qui n'existent pas encore mais qui devraient être développées.

Défenses possibles:

• Les RAT appellent fréquemment leur serveur de C&C. Dans certains cas, le RAT appelle son C&C toutes les 8 seconds, ce qui représente +10000 appels par jour. Ce volume de connexions devrait être immédiatement détecté comme suspect et analysé.
• Certains RAT n'utilisent pas les DNS locaux, mais au contraire des serveurs DNS sur internet. Une politique de sécurité sur le firewall devrait empêcher ces résolutions d'être faites et alerter l'administrateur.
• Les auteurs de l'attaque continuent à utiliser des noms de domaines pour leurs C&C, même une fois que ces domaines sont blacklistés dans diverses listes. Bloquer ces listes apparaît donc comme un premier pas essentiel, mais surveiller les machines tentant de s'y connecter permet d'augmenter les chances de détection de malware.

 Défenses à créer:

• Les RAT appellent leur serveur de C&C à fréquence fixe, c'est à dire à intervalle régulier. Existe-t'il au monde une sonde IDPS qui sait indiquer les connexions régulières? Ce serait un des meilleurs moyens je pense de trouver des flux malveillants[1].
• Pour contourner les systèmes de blacklist DNS, certains RAT utilisent directement les IP pour joindre leur C&C. Existe t'il un mécanisme de suivi de connexion qui soit capable d'indiquer si une connexion vers une IP a été précédée d'une requête DNS? Cela serait également un mécanisme de surveillance efficace.

4/ Conclusion
EDIT: Pour résumer, nous pouvons considérer que l'entrée d'un attaquant dans un réseau est difficile à bloquer: spear phishing évolué, 0day (et inefficacité des certificats). Par contre, l'auteur de l'APT va chercher par la suite à se déplacer latéralement dans le réseau visé. C'est sans doute là qu'il est le plus vulnérable, du fait de ses fréquents allers-retours entre le C&C et les machins vulnérables.
Nous verrons peut-être un jour des malwares se déplacer à la manière de drone absolu sans aucun contact avec l'extérieur si ce n'est l'exfiltration des données finale. Ceux-là seront particulièrement difficile à bloquer. Mais un malware pourra t'il embarquer suffisamment d'intelligence?

[1] C'est d'ailleurs un problème mathématique amusant: Soit une distribution de noms associés à leur heure de résolution ['nom',heure]. Comment détecter dans cette distribution des évènements répétitifs?

Les RMLL sont un cycle non commercial de conférences, tables rondes et atelier pratiques autour du Logiciel Libre et de ses usages. Chaque année depuis 12 ans, un appel à conférences est envoyé et chacun peut proposer son sujet.

Je propose cette année un sujet qui traite de la liberté d'accès à Internet. Voici la soumission que j'ai faite aux RMLL:

---

L'envoi de paquets sur internet est un sport de combat. 

Hadopi, ACTA, filtrage, Internet limité, DPI, Révolution 2.0, neutralité du net... Le temps ou un accès internet consistait systématiquement en une adresse IP publique et ou le filtrage n'existait pas est révolu. En effet, la neutralité du net est remise en cause jusqu'à voir naître des lois sur le sujet, les FAI n'hésitent plus à filtrer ou brider internet et de plus en plus d'affaires d'écoutes et de détournements de trafic sont portées à l'attention du public.

Que signifie aujourd'hui un accès à internet?
Les atteintes à la liberté d'Internet peuvent être classées en trois catégories qui seront présentées en première partie. Cela concerne le filtrage par port, par IP ou par domaine, l'écoute des communications par un tiers et la censure des communications et documents. Ces trois failles utilisent souvent les mêmes techniques que sont les sondes firewalls et les sondes DPI (Deep Packet Inspection).
La seconde partie vise à présenter présenter ces techniques de suivi et coupure de connexions et de donner ensuite des méthodes pratiques afin de les contourner ou de les rendre aveugles.

1. Internet filtré, internet écouté, internet censuré!
Internet n'est pas que le web, mais le web est l'élément incoutournable d'internet. Les deux notions seront donc différenciées le cas échéant, mais il est généralement fait mention d'accès au web.
1. Le filtrage
• Le filtrage s'effectue par IP, par port ou par domaine DNS. Liste noire, liste blanche, limitations.
• Le filtrage est aisément détectable, une fois l'hypothèse de la panne écartée.
2. L'écoute
• Eventuellement indétectable!
• Le Deep Packet Inspection
• Quelques méthodes de détection des écoutes (sans garanties)
3. La censure
• Pas de blocage franc aisément détectable
• Souvent lié à l'écoute et/où à la géolocalisation
• Lois contre la neutralité d'internet
4. Points communs entre ces entorses à la liberté de l'accès internet
• On retouve des techniques de DPI
• Souvent placées sur les noeuds de sortie, FAI ou pays.
2. Retrouver un Internet libre ou 'Full Access'
1. Petit panorama des sondes DPI actuelles
• Jusqu'ou va le DPI? Quelle profondeur? A quel débit?
• Pour quels réseaux
-Internet IPv4 / IPv6
-Internet mobile/GSM

• Méthodes pour outrepasser le chiffrement
-Sa détection
-Son interdiction
-La non sécurité de SSL
2. Qu'est ce qu'un accès internet libre?
Définition de ce qu'est un accès internet "acceptable".

3. Les solutions
• Principes de contournement du filtrage: le tunnel
• Principes d'aveuglement de l'écoute: le chiffrement
• Principes de contournement de la censure: multiplicité des sources d'accès
• L'utilité d'une (ou plusieurs) machine(s) tierce(s) sous contrôle
• Ninja tricks
-tunnels
-evasion
-chiffrement
-special tricks

3. Conclusion

---

La réponse sera donnée courant avril.

Commentaires et questions bienvenus afin d'enrichir le débat.

Il y a quelques jours, je lisais le magazine MISC et une offre d'emploi a attiré mon attention. En effet, au milieu de cette annonce, une suite de caractères qui challenge le candidat "7Pp7W2Yr".

Ce challenge mène à quatre questions à résoudre et une nouvelle adresse mail où candidater. Sans doute que ceux qui utiliseront cette adresse mail plutôt que la générique de l'annonce auront plus de chances :-)

De plus en plus de sociétés proposent des challenges pour découvrir et recruter des candidats. Il faut bien avouer que c'est quand même plus sympathique que de devoir passer la barrière du DRH+secrétaire qui ont souvent le malheur de ne pas très bien connaître les skills de ingénieurs en sécurité. Au moins, un bon challenge permet vite de trier les candidats sur une base claire.

Je propose quelques sites de société ayant mis en place des challenges de recrutement (et que j'ai résolu pour certains \o/ ). Je vais essayer d'en parler sans trop spoiler.

• tetrane.com contient un challenge, plutôt un petit easter egg dont la solution est très simple si vous avez des connaissances en debug.
• Si vous avez lu MISC et l'annonce de winamax, vous devriez facilement trouver la page pastebin contenant le challenge (mais je spoile déjà un peu). Sur les quatres épreuves, seule la première est complètement tordue (et me semble introuvable sans un second hint à moins d'avoir une intuition qui dépasse l'imagination, mais c'est un avis personnel). 
• En anglais, il y a eu canyoucrackit qui est terminé, et dont toutes les solutions sont disponibles sur internet. L'idée est plutôt bonne, avec un enchaînement d'étapes bien tournées.
• Raytheon a également un bon challenge en trois fois deux étapes, pas très compliqué mais amusant (les portes yes/no notamment). Les solutions se trouvent sur internet, mais ça se résoud sans.
• Dans un autre domaine que la sécurité, facebook a un challenge de programmation. Vous avez un problème à résoudre, et vous avez le choix du langage. Vous tapez le code dans une page web, puis ça le compile (ou ça l'interprète) et ça envoie le problème. Si votre programme le résout, alors vous passez à l'étape suivante. 
• Le site 1.61803398874.com/ est un challenge dont le nom de domaine lui-même est à comprendre. Un second challenge est un programme à écrire, dont la man page est fournie, sous forme humoristique. Il faut écrire la man page du programme 'dog' qui est le meilleur ami de l'user.

La solution ne permet pas de douter de celle-ci. Enjoy.
[Et merci à N.R. pour raytheon et facebook]