 Les collègues du concours Pomp Don ne me disent que les prétentateurs sont vraiment au top niveau. Il est nécessaire d'avoir fait beaucoup de travail en aval afin d'avoir des outils qui vous permettent de gagner sur le moment. Ils ont fait bien plus que travailler sur les outils qu'ils ont, mais l'intérêt majeur c'est qu'ils vont donner la leçon, la recette de la démarche qui leur a permis de développer tout ça. Bienvenue à Marc C. Leimi pour cette conférence. Bonjour à tous, merci d'être venus ce soir. Je vais commencer par remercier les organisateurs qui nous ont invité ici. C'est une mortier unique de partager nos expériences avec la communauté et je suis très content d'être là. Merci, j'espère que vous allez apprécier. Donc, qui sommes-nous? Je suis Marcus Gazadan, parfois Gazadan, ce qui est mon nom de famille. Avec moi, j'ai mon collègue Amy qui est aussi un bon ami. Ça fait très longtemps qu'on boise ensemble pour une entreprise qui s'appelle R2Systems qui fait de la recherche du développement en sécurité, du consulting. Et on fait en sorte de pousser l'éducation et les trainings en sécurité, ainsi qu'augmenter le niveau de conscience et de partager l'information. Donc, on veut partager notre approche sur comment s'y prend pour briser les logiciels très utilisés. Donc, en particulier, on voudrait parler d'une vulnébralité qu'on a introduite à R2Systems en 2017. Donc, on veut briser des idées fausses communes sur cette industrie, montrer nos propres observations, ainsi qu'offrir des conseils là où on peut. Donc, comment est-ce qu'on a commencé à rentrer dans cette range de travail? Donc, ce n'est pas un commentaire technique, c'est un commentaire non-technique sur le procédé de découverte des vulnérabilités 0D. Donc, il n'y a moins de magie que ce que vous pouvez réaliser et on est vraiment très ça. Donc, PONTOON, c'est une compétition organisée chaque année par Trend Micro et son initiative 0D. Donc, on invite là-bas les chercheurs, les meilleurs du monde pour développer des 0D et présenter des 0D contre les cibles les plus valables du monde. Donc, des broseurs des systèmes d'exploitation, des machines virtuelles, VMware, Xen, etc. Donc, on s'est dit que ce serait cool d'aller à PONTOON et de cibler des navigateurs. On a choisi Safari sur macOS, c'était nouveau, c'était mystérieux et ça nous permet d'éviter tout conflit d'intérêt. Donc, pour cette compétition, on a fait une RCE en un clic. Donc, l'engage de l'industrie, ce que ça veut dire, c'est qu'on est capables d'avoir un accès en route à distance sur MacBook si vous cliquez sur un lien. Il vous suffit de cliquer sur un lien, c'est un peu terrifiant. Il y en a beaucoup qui pourraient s'imaginer ne pas être susceptible de cliquer ou d'être la cible de Hampson-Age. Mais bon, c'est possible que vous vous retrouviez avec une attaque de l'homme du milieu et c'est un potentiel. Donc, là, c'est nous sur scène à démontrer notre tentative d'exploit sur la machine de compétition, juste un peu après que l'exploit soit exécuté. Donc, l'appellot, c'est la fichage d'une calculatrice et d'un shell en route. Donc, c'est une démonstration visuelle d'exécution de code. Et pour le plaisir, on a aussi choisi de faire changer le fond d'écran. Donc, ce qui est intéressant, c'est qu'on n'avait pas d'expérience préalable sur macOS ou sur Safari. On n'avait pas de MacBook au bureau, on a dû littéralement aller en HT1. Donc, du coup, vous voyez comment nous, comme en tant que chercheurs, on approche des nouvelles technologies inconnues. Donc, je vous ai promis que ce serait un tour qui ne serait pas technique. C'est principalement vrai parce que tous les détails de la chaîne d'exploit ont été postés en tant que six articles de box. Donc, c'est plutôt qu'on veut le rendre accessible à la plus large audience. Donc, les choses les plus techniques sont sur le blog et ce n'est pas un prêt réquit de le lire. Ne vous sentez pas mal de ne pas le lire. Donc, ceci étant dit, je vais vous présenter la première étape de ce que j'appelle le guide du Zero Day Engineering pour l'homme de la rue. Donc, la première étape pour attaquer des logiciels très communs. Donc, ce n'est pas une blague, c'est un jeu avec de larges enjeux. Donc, la première étape, c'est vraiment de définir vos attentes par rapport à ce qui vous attend. Donc, il se peut que vous soyez un expert en sécurité, un chercheur ou juste un enthousiaste. Et après un moment où vous aissez un peu, vous vous trouvez de l'intérêt, vous dites que ce serait intéressant d'aller casser la sécurité d'un navigateur internet. Et ça peut être intéressant de regarder dans les appareils de l'entreprise qui a le plus de succès financier de la génération. Et ils ont augmenté de manière continue leurs investissements en sécurité, matériel et logiciel. Et on voit de plus en plus d'articles qui disent qu'en contrepartie, ils sont davantage ciblés par les chercheurs en sécurité. Donc, gravir la montagne, ça ne va pas être simple. En tant qu'individu, c'est un peu du chacun pour soi. Dans un coin, vous avez des vendeurs qui pourraient avoir une expérience et un argent infini. Dans un autre coin, vous avez les autres usages de la sécurité, d'autres agents de menace. Et au milieu, ce que vous avez, c'est le code. Donc, il y a beaucoup d'obstacles, c'est pas drôle et ça va être de pire en pire. Donc, quand vous êtes un nouveau, que vous ne savez pas trop, quelle durée vous devez estimer quand vous vous lancez sur un projet de ce style. Donc, ceux d'entre vous qui sont familiers avec les CTF, en général, c'est des compétitions qui ont lu sur 36 à 48 heures, en général, sur le weekend. Donc, on en vient, on aime ce sport, on continue à y jouer. Mais ça prend combien de temps de développer une zéro day ? Ça peut être très variable. Des fois, vous avez de la chance. J'ai vu quelqu'un développer un bug de Chrome en deux jours. Dans certains cas, ça a pris deux semaines. Des fois, ça peut prendre un mois. Et des fois, ça peut prendre beaucoup plus de temps pour étudier une nouvelle cible. Donc, il faut prendre une échelle du mois, trois mois et demi, potentiellement, ou six mois pour certaines cibles. Le fait est que c'est quasiment impossible de dire combien de temps ça peut prendre. Et à la différence dans le challenge de CTF, il n'y a pas de limite supérieur à ce process d'ingénierie de zéro day. Il n'y a pas de garantie qu'il y a un bug qui vous permet de faire une zéro day dans le software que vous ciblez. Vous ne savez pas non plus ce que vous cherchez. Et vous travaillez sur des projets qui sont beaucoup, beaucoup plus grands que ce qu'une personne peut faire. On parle de millions de lignes de code. Et en général, un challenge de CTF, c'est quelques centaines de lignes de code en C. Donc, vous pouvez voir le doute et l'angoisse dans vos yeux, mais vous ne pouvez pas être trop dur avec vous. Vous devez juste garder à l'esprit que l'échec n'est pas improbable dans ce voyage-là. Donc, une fois que vous avez la fondation psychologique, l'étape d'après, c'est la reconnaissance. Donc, ce slide est un peu rigolote, mais même Metasploit vous rappelle de commencer par faire de la reconnaissance. Donc, dans le cadre de zéro day, la découverte de vulnérabilité dans des gros logiciels peut être une expérience assez intéressante. Donc, la question c'est, on va où ? Et c'est important d'avoir des connaissances de base sur la cible. Donc, cette partie du développement n'est pas souvent mentionnée, c'est pas très glamour. On voit pas de puzzle-blocks qui dit, oui, je suis resté à chercher sur Google pendant 8 heures des informations sur Safari. Donc, il faut compiler et passer en revue toutes les recherches préexistantes sur la cible que vous avez choisie. Donc, la réponse c'est chercher tout sur Google. Donc là, on cherche sur Google, on fait la liste des choses sur à peu près 5 pages, on clique, on marque, on lit tout. Et vous voyez, en bas de la page de Google, là où personne ne va, toutes les recherches liées, c'est intéressant. Faites au moins 2 ou 3 pages et téléchargez et sauvegardez en boucle marque tout ce qui peut sembler intéressant. Vous continuez à confaire ça, faire ça, faire ça encore et encore. Et Google et Google et Google de tout ce qui est potentiellement lié à la chose. Et donc, l'idée c'est de choper toute l'information, de comprendre tout ce que vous pouvez sur la cible. Même si c'est pas spécifique à Safari, par exemple le moteur V8, Chrome, Opera, quoi que ce soit qui vous semble lié. Le but c'est de construire sa bibliothèque de littérature en sécurité autour de votre cible et du système, de l'écosystème de la cible. Donc je veux que vous lisiez, mais je veux pas que vous vous forciez à tout comprendre. Le but de l'exercice c'est de construire davantage de concepts sur la cible, la sécurité et son architecture. À la fin de cette phase, vous devriez être capables de répondre ce genre de questions. Donc, à quoi sert le logiciel ? Comment est-il architecturé ? Est-ce que quelqu'un arrivera à me décrire l'architecture de WebKit ? Est-ce qu'il y a une sandbox ? Comment est-ce qu'on débug WebKit ? Comment est-ce que les développeurs de WebKit le débug ? Est-ce qu'il y a des Asus ? Est-ce qu'il y a des options spéciales ? Est-ce qu'il y a des composants qui sont connus pour être vulnérables ? Est-ce qu'il y a eu de la recherche ? Est-ce qu'il y a eu des write-up ? Donc quand on a reconnaissance et faite, la deuxième étape c'est la sélection de la cible. Techniquement, la cible c'est Apple Safari, mais on a quand même envie de réduire le champ de ce qui nous intéresse. Donc vous avez une visualisation arborescente du code source de WebKit, qui est le framework sur lequel Safari est basé. Donc c'est un moteur de browser web open source. Quand on trie par taille, chaque boîte c'est un fichier dans l'arbre d'rescence du code source de WebKit. Donc toutes les grosses boîtes c'est des répertoires et tous les petits carrés c'est des fichiers. Et le coloris. Donc le bleu c'est la complexité détectée maximum plus c'est bleu plus c'est détecté comme étant contexte. Comment est-ce qu'on part à la chasse pour devenir ambilité dans une base de code plus de 3 millions de sources de C++ ? C'est quelque chose que j'ai jamais fait, lire au review des 3 millions de lignes de code. Donc il faut réduire la largeur de ce qu'on va prendre en compte et se concentrer sur la profondeur plutôt que sur la largeur. C'est important quand on cible des cibles vraiment grosses. Donc là c'est pas un CTF, l'échelle est très grosse. Il faut vraiment être détaillé dans votre analyse donc réduisez vraiment votre champ. Donc notre reconnaissance et notre expérience passée nous a poussé à nous concentrer sur le moteur JavaScript qui est en orange sur l'écran. Donc les moteurs JavaScript sont souvent considérés comme des bugs extrêmement précis dans les browser. Mais il y en a de moins en moins vu que de plus en plus de gens nettoient le code et réduisent les failles. Donc on a réduit notre scope, on est à 350 000 lignes de C dans le répertoire JavaScript. Donc c'est le moteur JavaScript dans Webkit tel qu'utilisé par Safari sur macOS. Et spécifiquement pour réduire encore notre scope, on va se concentrer sur l'interface la plus haut niveau qui est le dossier runtime. Ça contient du code qui a une correspondance pratiquement un à un avec des concepts et des méthodes par exemple Array dot reverse ou Concat dans le navigateur. C'est très proche de ce que les auteurs de JavaScript sont familiers avec. Du coup ça nous ramène à environ 70 000 lignes de code. Quand on se préparait pour point de tome, on s'est dit ok on va trouver un bug dans un des fichiers dans ce répertoire. Et on va pas arrêter de chercher jusqu'à ce qu'on ait trouvé quelque chose. Donc si on recule d'un peu, on a commencé avec ça et on a réduit notre scope à la petite case verte. Donc voilà ça permet d'illustrer la manière dont on réduit le scope. C'était presque arbitraire. Il y a eu par le passé beaucoup de bugs dans ce répertoire runtime mais ça a été bien nettoyé les années passées. Mais c'est quand même ce qu'on a choisi. Donc en ayant passé plusieurs années à faire des retours entre l'attaque et la défense, j'ai reconnu un truc. Les mauvais composants c'est souvent long avant qu'ils s'améliorent. Donc pour sortir d'un bac à sable, on regarde un peu pendant la phase de reconnaissance. Qu'est-ce qui a déjà été fait ? Donc on a choisi de regarder Windows Server. Pour ceux qui savent pas, c'est un service système macOS qui tourne en route. Et on a trouvé 12 bugs de sécurité qui l'impliquent, qui ont déjà été reportés par le passé. Et ce composant est accessible à la sandbox de Safari. Et en particulier, on regarde le site web de ZDI. On peut regarder dans leur rapport. Et en particulier en 2016, il y a eu dix inhérabilités qui l'ont été remontées, qui utilisait une sortie de bac à sable pour une escalation de privilège. Et ça, c'est juste celles qui ont été remontées à ZDI en 2016. En 2017, il y en a eu quatre utilisées pour le même but. Et je pense que celles-là ont été toutes utilisées à Ponto On. En 2018, il y en a eu plus qu'une. Et donc vous pouvez voir qu'en trois ans où les gens tapent sur le même composant, tous les chercheurs tapent au même endroit et ils cherchent des bugs. Donc c'est intéressant. Ça met un peu de perspective. C'est vraiment difficile d'améliorer rapidement des mauvais composants. Il n'y a vraiment personne qui a envie de s'asseoir et de réécrire du mauvais code. Et les fournisseurs de logiciels ont très peur de régression quand ils mettent une mise à jour. Ils vont réécrire uniquement s'ils ont vraiment besoin. Donc en l'occurrence, quand on leur remonte une vulnérabilité. Du coup, comme vous pouvez voir, il y a pas mal de raisons pour le fait qu'on ait des composants avec des très mauvais niveaux de sécurité. Du coup, si vous voyez une cascade de bugs dans un composant, c'est probablement une bonne idée de continuer à regarder, parce qu'il y en a probablement d'autres pour les années à venir. Étape 3 Donc après avoir cherché, on peut enfin aller explorer en profondeur le code de notre choix. Donc c'est la chasse au bug. En tant que chercheur individuel de petites organisations, le plus difficile dans ce processus, c'est de découvrir ce qu'est une vulnérabilité. Donc ça peut varier en fonction des personnes, mais on n'a pas 100 millions de dollars à dépenser sur des foseurs, par exemple. On a juste un MacBook. Et du coup, c'est un peu comme chercher une aiguille dans une botte de foin. Bon, on a de l'expérience aussi dans le processus d'exploitation tranqutelle. Donc il y a deux stratégies pour trouver des vulnérabilités avec des avantages et des inconvénients ou deux. Et je n'ai pas envie de passer trop de temps sur les avantages et les inconvénients. Donc tout est listé ici. Pour summarize, le fosing, c'est souvent la manière par défaut, parce que ça passe à l'échelle et on trouve presque souvent des résultats. Donc vous verrez plus tard qu'on a fait du fosing sur les deux bugs qu'on a utilisés dans notre chaîne. En 2018, on peut encore trouver ça de manière assez triviale. L'autre stratégie, c'est la revue de code. C'est souvent beaucoup plus difficile, mais ça peut produire des bugs de haute qualité quand c'est bien fait. Donc si vous voulez juste vous y mettre, commandez simple, commencez à être le fosing et voyez où ça vous amène. Donc dans ce taux qu'on va se concentrer sur le fosing. Donc ça, c'est le dashboard d'un outil de fosing scalable qu'on a construit pour ce moteur JavaScript. Donc c'est un fésor de grammaire JavaScript basé sur l'outil d'armade de Mozilla. On a commencé à l'écrire qu'à partir du moment où on a trouvé les vulnérabilités qu'on voulait cibler. Donc ça vous montre un peu la simplicité pour arriver où on en est arrivé. Quelque chose qu'il est important de dire aux gens qui font du fosing, c'est que le fosing doit vraiment être traité comme une science sur ce genre de cible. Donc c'est vraiment nécessaire que vous quantifiez votre fosing et sa couverture. Faites passer en aveugle s'il vous plaît. Donc toutes les 15 minutes on a une mise à jour du pourcentage de code couvert par le foser. Un bon objectif c'est 60% de couverture. Donc c'est mis à jour toutes les 15 minutes. Et là on s'est vraiment concentré sur le dossier runtime. On a observé sur des nombreuses cibles plus ou moins exotiques que la plupart des bugs. Il faut vraiment les secouer dans les derniers pourcents difficiles à atteindre. Donc ça veut dire que quand vous essayez d'améliorer votre couverture, de générer des bons jeux de tests, vous allez atteindre ces 60% et regardez qu'est-ce qui manque toujours dans la couverture. Et c'est là où vous mettez à chercher encore plus profond et vous mettez à trouver beaucoup de bugs. Donc par exemple on s'est dit pourquoi ces boîtes grises sont encore là ? Pourquoi est-ce qu'on n'a jamais exécuté ce code dans les millions de jeux de tests qu'on a fait ? Et on va se rendre compte qu'il y a un cas limite un peu bizarre. Et on va modifier nos jeux de tests pour aller exercer ce code. Et donc des fois on s'installe, on pose le projecteur et on discute mais qu'est-ce qui se passe à cet endroit-là ? Donc ça c'est quelque chose qu'on a fait dans la chasse au bug pour Pound 2 Home. Et par delà le fait que ce soit un peu cliché ces mecs comme ça dans une salle sombre, c'est vraiment comme ça que ça s'est passé. C'est comme du rubber gawking entre collègues où on échange des idées, on confirme ou on infirme des théories. Ce qui nous amène à un autre conseil. Donc ça s'applique à la fois au debugging et à la gestion des cas limites. Si il arrive que vous ayez des doutes sur le code que vous lisiez, vous devriez vraiment vous mettre à utiliser des debuggers et de l'analyse dynamique. Ça peut avoir l'air compliqué et pénible de configurer ce debug. On se retrouve avec des énormes piles d'appels. Il faut vraiment vous vous rendez pas compte du niveau de contexte nécessaire pour découvrir ce genre de bug. Donc il faut vraiment le faire. Donc par exemple, là on a beaucoup utilisé RR pour trouver la cause initiale de la vulnérabilité qu'on a exploité. Donc il y a une res condition dans le garbage collector. Il y a vraiment peu de personnes qui auraient pu repérer ce bug en revue de code. Ça nécessite énormément de connaissances pour reconnaître que c'est une vulnérabilité. Donc on l'a trouvé par le fuzzing. Et on a utilisé le projet RR de Mozilla qui est merveilleux pour faire du voyage temporel dans le debugging, retourner en arrière. Donc ça c'est un exemple d'une pile d'appel. Donc ne serait-ce que utiliser un debugger pour dumper la pile d'appel de la fonction que vous auditez. Ça vous permet d'obtenir énormément d'informations sur les données manipulées, de quel endroit c'est appelé etc. Donc ça c'est une backtrace de gdb, de 40 ou 50 niveaux de profondeur. Très bien. Donc quelque chose que les novices ont souvent à l'esprit et qui est faux, c'est que le nouveau code est toujours meilleur et qu'il est toujours écrit par des gens vigilants. Et c'est faux. Et j'observe ça, année après année, du code de plein de producteurs. Yvan de gpz a fait du project zero, a fait ce blog post, génial. Donc il y a un an il a fait du fuzzing sur Webkit. Et il a trouvé pas mal de vulnérabilités. Il les a trouvés, il les a remontés, puis là Open Source est son fuzzer. Et cette année il a relancé son fuzzer, juste pour voir. Et il en a trouvé encore plus de 8, donc des use after free. Donc ce qui est sympa c'est que quand on regarde dans ces colonnes en rouge, c'est que la plupart des bugs ont été introduits dans les derniers 6 mois ou sont des régressions. Donc il y a souvent de nouvelles vulnérabilités qui sont introduites dans le code. Donc la plus grosse raison pour laquelle on considère du code récent comme dangereux, c'est qu'il n'a pas passé des années sur le marché, il n'a pas eu le temps de gagner en maturité, il n'a pas été testé aussi bien que le reste du code. Donc à chaque fois qu'un développeur pousse du code en stable et qu'on a un million d'utilisateurs qui comptent sur ce code, disons pour Chrome, mettons qu'il y a un million d'utilisateurs qui utilisent Chrome, ils se trouvent à faire du fuzzing sur Chrome et ils vont manifester des conditions bizarres qui ne sont pas dans vos jeux de tests, qui vont avoir des effets plus ou moins intéressants. Et du deuxième point, ça arrive souvent que le nouveau code brise des assumptions implicites qui sont faites à d'autres endroits du code. Donc mettons que le nouveau développeur écrive du nouveau code qui casse un paradigme qu'avait le développeur précédent du code. Donc peut-être qu'il ne comprend pas aussi bien que le précédent ou peut-être qu'il a juste fait une erreur et c'est quelque chose qui arrive assez très souvent. Donc un autre conseil, ça devrait être vraiment évident. Donc il y a beaucoup de gens qui essayent de taper, de faire entrer des données et qui font ça, qui sautent un peu dans le code sans vraiment savoir. Donc ce qu'il faut faire, c'est identifier les sources de données et vraiment suivre qu'est-ce qu'il passe la donnée, qu'est-ce qu'il écrit, qu'est-ce qu'il lit, qu'est-ce qu'il manipule. Donc faites ça simplement. Donc dans nos sorties de bac à sable, dans Windows Server, on a découvert qu'on avait toutes ces fonctions et on a lu ce blog, on a fait ce blog box. Il y a toutes ces fonctions qui permettent d'envoyer des données dans Windows Server. Donc il y en a à peu près à 600. Et ce qui est bien, c'est qu'elles sont toutes préfixées par underscore underscore X. Donc ces 600 points d'entrée vont parser la donnée qu'on leur donne en entrée. Donc si on fait un petit diagramme, il y a cet échange de données, ce tube de données entre le bac à sable de safari vers le composant Windows Server. Donc on s'est dit, essayons de nous mettre au milieu de ce pipe et de regarder ce qui passe. Donc on a utilisé l'outil open source Frida, qui est sur GitHub. On a mis ça au milieu. Et ça nous a permis de vraiment voir le flow de tous les messages qui passent qui sont envoyés au Windows Server de macOS depuis à peu près toutes les applications de macOS qui parlent à ce server qui est responsable à dessiner toutes les fenêtres sur le bureau. C'est un peu comme Explorer.exe sur Windows. Donc on voit tous ces données qui passent. On voit tous ces messages assez fous. Tous ces formats de messages uniques. Tous ces tampons de données qui sont utilisés. Et ça ne demande qu'à être faisé. Donc on s'est dit, OK, allons faiser. Je me souviens avoir pensé, peut-être qu'on peut implémenter AFL ou peut-être qu'on peut utiliser Adamsa pour tester les buffers ou si on se mettait à inverser des bits au hasard. Et on s'est mis à inverser des bits au hasard. Et Abar a fait un tweet à Propoi il y a quelques semaines sur cette expérience. Il a dit, en regardant à ma carrière de recherche de vulnérabilité et de sécurité, les plus gros erreurs ont toujours essayé d'être trop malins. Le succès se cache derrière la question quel est la chose la plus bête qui pourrait potentiellement fonctionner ? Donc c'est notre farm de fuzzing. Donc un seul MacBook Pro. Donc je ne sais pas si ça a marqué. J'en affiche juste quelques secondes. Je pose littéralement juste mon portefeuille sur la touch enter. Et on peut voir cette boîte qui s'affiche. Et notre fuzzer fonctionne et intervertit des octets dans le Windows Server. On peut voir que l'écran change de couleur, que ça commence à déconner, ça change les messages. Et cette boîte est censée vous afficher un indice de mot de passe. Mais en maintenant la touche enter enfoncée, tout ce trafic qui est généré en direction du Windows Server. Voilà. Et le fait est qu'à chaque fois qu'on fait cracher le Windows Server, ça nous ramène à l'écran de login. Donc dans les faits, on a du fuzzing juste en posant quelque chose sur la touch enter. Donc on a appelé cette image avec humour, Advanced Persistent Threat sur notre blog. Donc c'est un crash qu'on a eu en faisant du fuzzing dans les premières 24 heures de fuzzing. On a trouvé une tonne de crashes. On n'a même pas tout exploré. Il y en a probablement encore quelques-uns sur nos étagères. À chaque fois que vous ayez ce truc en rouge qui dit c'est bad access avec une adresse, c'est vraiment mauvais. C'est le bug qu'on a fini par utiliser pour sortir du bac à sable à Pontuam. Donc si vous voulez lire, c'est sur le blog. Donc il y en a qui ont peut-être vu dans le comics d'InfoSack sur tous ces gens qui essaient de faire des trucs vraiment très malins et cool. Et il y a des personnes qui se retrouvent coincées à essayer d'injecter tellement de samples de science qu'ils oublient les pommes en bas du pommier. Donc avec notre petit fuzzer tout simple, on a trouvé le bug assez rapidement. Donc encore une fausse idée. Seulement des experts en recherche avec des bons outils peuvent trouver des bugs. Donc ça peut être des outils sponsorisés par l'état des outils magiques, des outils de l'état de l'art, tout ça c'est pas faux. N'importe quel outil peut faire l'affaire. Donc notre observation, n'importe quel bug que vous trouvez rapidement peut aussi être facilement trouvé par d'autres personnes. Donc ce que ça signifie c'est que peu après qu'on ait fait notre poste de blog, on s'est rendu compte qu'un des autres compétiteurs avait aussi des problèmes pour exploiter ce problème. C'est un bug difficile à exploiter. Donc c'était une situation assez étrange et après-coup on a discuté sur Twitter. Avec un gars qui fera un talk demain sur les IPC de Chrome. Donc on discute sur Twitter et Ned a commencé et il y a aussi Niklas. Niklas dit, bon, il y a au moins 3 personnes qui ont trouvé ce bug de manière indépendante. Donc on n'est pas les seuls à avoir trouvé ce bug et on était tous à Pomp2Hom. Donc imaginez combien de personnes ont trouvé ces bugs et combien de personnes ont pu essayer de transformer ce bug en exploits, peut-être qu'ils ne sont pas nombreux. C'est assez difficile à dire. Et le bug est compliqué. Donc le problème, il y a d'autres chercheurs qui étaient au courant de ce bug. Donc si vous avez trouvé un bug rapidement, en particulier avec le fuzzing, on peut garantir que quelqu'un d'autre l'a déjà trouvé. Donc pour la section suivante, je laisse la parole à Amy qui va continuer. On vient de parler des techniques et des attentes à avoir quand vous cherchez le bug. Maintenant je vais vous parler à quoi vous attendre quand vous essayez d'exploiter les bugs que vous avez trouvés. Donc c'est l'étape du développement de l'exploit. Donc très bien, vous avez fait la partie difficile et vous avez trouvé un bug. Donc c'est peut-être dans un navigateur, c'est peut-être dans un serveur de fenêtre ou dans le noyau. Peu importe. Mais la question c'est comment faire le reste ? Comment est-ce que vous partez de la vulnérabilité à l'exécution de la calculatrice ? Le système d'exploitation à un niveau de complexité tellement élevé qu'il faut comprendre assez pour savoir comment fonctionne votre bug, c'est pas potentiellement suffisant pour comprendre comment faire un exploit. Donc avant de parler de votre bug, reculons et posons une discussion un peu différemment. Comment est-ce qu'en général on s'y prend pour écrire un exploit ? J'ai l'impression que beaucoup de personnes s'imaginent que quand on compare avec ce qu'on fait dans un CTF, c'est dans une autre catégorie. Si par exemple on vous donne un challenge dans un CTF d'exploit dans un browser, ça peut vous sembler être quelque chose d'impossible à faire si vous n'avez jamais fait ça avant. Donc comment faire pour changer cette préconception ? Ça peut sembler cliché mais selon moi la meilleure manière c'est l'exercice. Comment est-ce qu'on devient bon ? C'est par l'exercice et ça peut sembler cliché mais c'est vraiment très valable comme conseil. Et donc comment on fait ? Consommer tout ce qu'on peut sur la cible, tout lire, tout télécharger, essayer de lire, même si vous ne comprenez pas tout, parce que vous pourrez apprendre un truc et ça fait pas mal d'apprendre et essayer de comprendre au moins le plus possible. Ça va pas être facile, c'est des systèmes vraiment compliqués qu'on attaque et c'est beaucoup de travail de comprendre ces choses-là mais de plus en plus vous faites d'exploit, de plus en plus vous verrez comment le chemin à faire pour exploiter. Donc j'ai fait la partie navigateur de notre chaîne d'exploit. J'ai fait beaucoup d'exploits dans les navigateurs par le passé. Ce que j'ai trouvé c'est qu'il y a souvent une structure extrêmement similaire et des techniques similaires, des primitives assez similaires qui sont utilisés pour construire l'exploit et c'est une observation pour illustrer ça. Donc voilà un exemple. Donc à Pound to Home on a eu cet été Samuel Gross de Phoenix qui est probablement ici. Donc sa cible c'était aussi Safari. Mais son bug c'était dans le comparateur juste à temps qui convertit le JavaScript en code machine. Donc notre bug n'était pas du tout là, il était dans le garbage collector. Donc c'est des bugs différents. Mais le bug qu'il avait il était très fiable, il était très propre. Je vous recommande d'aller regarder en ligne. Il y a une très bonne ressource. Puis quelques mois après, à Pound to Home mobile, un autre événement, on a Forrest R.Q.S. une équipe formidable qui a réussi à apponner à peu près tout ce qu'ils ont eu sous les mains dont un iPhone. Donc les iPhones ça utilise Safari, donc ils avaient besoin d'un bug Safari et le bug qu'ils avaient était très similaire en structure au bug précédent de l'année. En tout cas en ce qui concerne la manière dont ça fonctionne et qu'est-ce qu'on peut faire avec. Donc maintenant vous pouvez exploiter ces deux bugs avec du code d'exploit très similaire, pratiquement de la même manière. Il y a quelques astuces parce qu'Apple a rajouté quelque chose depuis là. Mais le chemin entre la découverte du bug et l'exécution de code était très similaire. Et quelques mois après, il y a eu un CTF qui s'appelait WheelWorld CTF en Chine. Et comme le titre le suggère, ils avaient des challenges réalistes dont Safari. Et bien sûr, mon équipe était là et au milieu de la nuit, ils m'ont dit d'aller m'y coller. J'ai dit ok, ok, je vais regarder. Et c'était un bug de Just In Time et j'avais jamais regardé le moteur de JIT de Safari avant. Donc je n'avais pas beaucoup d'expérience préalable à faire ça, mais vu que j'ai passé le temps à lire tous les exploits publics, donc j'ai lu les exploits de tous les autres compétiteurs Point 1, tous les autres choses que les personnes ont fait sortir, toutes les civilliers, j'avais vu un bug extrêmement similaire par le passé et je savais comment l'exploiter. Du coup, j'étais capable de rapidement construire le chemin entre le bug et l'exécution de code et j'étais le premier à remporter le challenge et c'était vraiment cool. Qu'est-ce que ça veut dire ? Tous les bugs sont pas aussi faciles de transformer en exploit, mais c'est extrêmement valable d'avoir la connaissance sur les exploits passés si vous essayez de développer des nouveaux. Le JIS VulnDB par exemple, c'est un dépôt de bugs JavaScript et de complois d'exploits. Si vous faites l'effort d'aller fouiner un peu là-dedans, vous aurez une bonne compréhension du type de bug qu'on trouve assez régulièrement de nos jours et comment les exploiter. Mais il n'y a pas tellement de bugs publiés qui sont des exploits fonctionnels. Il n'y en a que quelques-un par an. Une fois que vous avez lu tout ça, qu'est-ce que vous faites si vous voulez en savoir plus ? Vous pouvez potentiellement essayer d'exploiter d'autres bugs par vous-même. Par exemple, j'aime bien Chrome parce qu'ils ont une jolie liste de toutes les vulnérabilités qui mettent à jour à chaque fois qu'ils font une mise à jour. On peut vraiment aller voir qu'est-ce qui n'allait pas dans le tracker de bugs. Regardez là par exemple tout en haut une écriture hors limite dans le moteur V8. Donc si vous cliquez, vous pouvez voir qu'est-ce que tel le bug et vous pouvez essayer d'écrire en exploit. Et à la fin, vous aurez une idée bien meilleure sur comment faire pour exploiter un bug vu que vous l'aurez fait par vous-même. C'est l'opportunité d'appliquer ce que vous avez appris. Donc la question c'est oui, j'ai plein d'autres choses à faire. J'ai un job à 100%, je suis à l'école. Est-ce que les CTF, ça suffit ? Bonne question. La question c'est à quel point les CTF peuvent vous aider dans ce genre d'exploit ? Je pense pas que ce soit le même mindset parce qu'il faut un mindset très adversarial. La plupart du temps, c'est le challenge de son pas représentatif de l'exploitation de vrais logiciels. Donc on a un tweet il y a quelques jours sur la libc... des libc... des challenges dans la libc. C'est souvent des choses très artificielles qui n'ont pas beaucoup de valeur dans le monde réel parce qu'ils sont extrêmement spécifiques. Donc il y a des gens qui connaissent ces challenges spécifiques qu'on voit souvent dans les CTF mais je pense pas que ce soit très valable. Il y a des CTF qui sont vraiment réalistes. Au moment où je parle, il y a le CTF du 35C3 avec 3 exploits de browser, il y a un challenge sur VirtualBox et c'est fou de voir les gens qui arrivent à résoudre ces challenges en si peu de temps. Donc c'est définitivement quelque chose dans lequel vous pouvez jeter un coup d'œil. Même si ce n'est pas ce qui va, ça va pas tout faire mais ça peut avoir le coup. Donc ces CTF sont bien sûr pour les gens qui ont envie de se mettre à du vrai travail de développement d'exploit. Mais ça peut faire peur au nouveau parce que tout à coup c'est votre premier CTF et on vous demande de faire un exploit sur Chrome mais vous êtes là, non mais qu'est-ce qui se passe ? Donc on a trouvé un bug et on a de l'expérience. Donc qu'est-ce qu'on fait ? Il faut qu'on ait de la chance parce que même si on a plein d'expériences, ce n'est pas forcément dire qu'on peut écrire l'exploit pour le bug. Donc un exploit javascript c'était assez beau, on savait à peu près comment faire depuis le départ mais notre exploit dans le bac à sable ne rentrait pas dans une jolie boîte que vous avez vu. Donc ça a pris beaucoup d'efforts. Donc c'est le bug qu'on a exploité pour le bac à sable. C'est un bug assez simple. C'est un problème avec un integer. Donc on a la varie d'index qui est signée et qui peut être négative. Donc normalement c'est positif mais si on lui donne moins 3 ça peut sortir de la zone mémoire et corrompre la mémoire. Donc c'est un bug vraiment simple. Ce n'est pas un truc complexe comme on a pu voir par le passé. Mais est-ce que ça veut dire que l'exploit est simple pour autant ? Regardons. Donc c'est beaucoup de code. Donc notre exploit pour ce bug a fini par faire quasiment 13 000 lignes. Donc c'est un peu fou. Et vous vous demandez probablement comment on en arrive là et je vais dire juste un truc. Soyez conscient que bien que vous ayez trouvé un bug soit simple. Ce ne veut pas dire que soit simple de le transformer en exploit, ça peut prendre beaucoup d'efforts. Mais soyez pas découragés si ça vous arrive. Ça veut juste dire que c'est l'heure d'aller dans les montagnes russes du développement d'exploit. Ce que ça veut dire, c'est qu'il y a beaucoup d'évaux et de bas dans ce processus. Et on doit monter dans la montagne rouge. C'est avec l'espoir qu'un jour peut-être on est notre exploit qui marche. Donc on a trouvé le bug. On a eu des idées assez bonnes. On avait déjà vu un bug exploité par King. On avait lu leur whitepaper. Et ils ont une bonne idée. Donc on s'est dit ça va marcher. Il faut juste vérifier que ce bit ne soit pas défini. On a vu des valeurs un peu bizarres et on s'est dit des fois il est pas 7. Mais on s'est rendu compte que ce bit était toujours à 1. Donc peut-être qu'on peut contourner ce problème et trouver un moyen de remettre ce bit à 0. Et oui, on peut le détruire, ça va fonctionner et ça va être cool. Et non, on s'est réalisé que ça cassait le reste de l'exploit. Donc, c'est aller-retour. C'est haut et c'est bas. Vous savez, des fois quand vous résolvez un problème, vous croyez que vous avez ce qu'il vous faut et puis vous vous rendez compte qu'il y a un autre problème qui apparaît. Donc c'est vraiment crémentale pour enlever tous les problèmes et obtenir quelque chose qui finit par fonctionner. Et donc tout ça, ça s'est passé en 60 minutes une nuit. Donc moi, j'étais à bout de souffle, j'étais là, tu te fous de ma gueule. Il y a 2 bugs qui nous sont tombés de sucre, rendu le bug initial plus difficile à trouver. Et c'était une expérience vraiment horrible. Mais je recommanderais quand même. Donc ces montagnes russes s'appliquent à tout le processus. Ce n'est pas juste à la phase du développement de l'exploit. Parce que vous avez ça quand vous trouvez des crashes qui n'y a pas d'unérabilité ou des crashes qui ne sont pas exploitable ou des exploits qui ne sont pas fiables. Et il faut vraiment pousser jusqu'à ce que par chance vous arriviez jusqu'au bout et que vous ayez un bel exploit qui fonctionne. Ok, on va dire qu'on a écrit notre exploit. C'est peut-être pas très très fiable mais ça fonctionne. J'arrive de temps en temps à exécuter du code. Donc maintenant, on va parler de la charge utile. Qu'est-ce que c'est ? C'est ce que vous voulez, ce que votre exploit fasse. Ça peut être ouvrir la calculatrice. Ça peut être lancer l'exploit de sortie de Bacassable. Ça peut être nettoyer le système après la fin de l'exploit. Ça veut dire, en fait, réparer le programme que vous exploitez. Donc dans les CTF, c'est pas quelque chose qu'on fait. En général, on fait juste un cat sur le flag et on s'en fout si le programme crash complètement parce qu'on a notre flag. Donc dans ce cas-là, on a le flag. Ça a cassé le programme mais on s'en fiche. Dans le monde réel, par contre, c'est un peu plus important. Qu'est-ce qui se passerait si votre exploit ne nettoyait pas ? Ça crash le browser en retournant à l'écran de login. C'est pas très propre. Si vous êtes à une conférence du style.to mais je pense qu'ils ne vont pas vous aimer si vous faites un truc du genre. C'est important d'essayer de retourner et de réparer tout ce que vous avez pu casser dans le système quand vous finissez. Donc quand vous exécutez votre charge utile vous allez souvent voir qu'une fois que vous arrivez à l'exécution du code vous envoyez une interruption 3 qui dit au programme de stopper par exemple. Vous avez réécrit dans votre exécution de code. La question c'est on ne veut pas mettre de l'assembleur directement et la question c'est comment est-ce qu'on veut faire pour avoir notre charge utile la mettre dans le système un endroit où Bacassab va nous laisser le mettre, puis le recharger comme bibliothèque et enfin l'exécuter et faire bomber le système. Donc vous avez assemblé vous avez tout, vous avez presque terminé, vous avez votre calculatrice donc ça c'est notre sortie de Bacassab qui affiche la calculatrice mais on n'a pas totalement terminé il faut faire encore un peu plus c'est la fiabilité de l'exploit on doit s'assurer que l'exploit soit aussi fiable que possible parce que si ça fonctionne qu'une fois sur 100 c'est pas très très bon. Pour point of order on a fini par un jeu de une moulinette qui nous permet de lancer plein de fois l'exploit et de vérifier à quelle fréquence il a fonctionné ou cassé et ça nous permet d'obtenir d'autres informations sur pas en combien de temps il a tourné et ça rendu beaucoup plus facile le travail iteratif et la correction des problèmes qu'on a rencontrés et donc améliorer la la qualité de l'exploit donc on s'est rendu compte que la plupart des problèmes venant du hip-groom donc c'est l'endroit où on essaie d'aligner la mémoire d'une manière avantageuse on pouvait pas faire grand chose à cet endroit là un autre truc c'est tester sur plusieurs appareils donc notre exploit javascript c'est une rescondition c'est un de l'apportance quand vous exécuter votre exploit donc vous voulez aussi potentiellement tester sur différentes versions du système d'exploitation parce que même si toutes sont vulnérables il y a peut-être des petits détails qui changent et vous devez peut-être vous adapter pour que ça fonctionne de manière fiable sur toutes les versions on a voulu tester sur la version beta de macOS en plus que la version actuellement en production pour éviter qu'Apple pousse une mise à jour enfin que si pousse une mise à jour jusqu'avant la compétition ça fonctionne toujours donc quand on a des adresses qui sont spécifiques au système d'exploitation il nous suffit de changer de changer ces variables dans le code et pour certains browser ça peut aussi avoir le coup de les tester sur des mobiles même si c'est pas votre cible initial parce que dans pas mal de cas le bug initial va aussi fonctionner s'appliquer sur le téléphone et ça peut être une cible cible zidière à laquelle vous pensiez pas au départ donc en général essayez de lancer votre exploit sur le plus de choses possible et ça va vous permettre d'augmenter votre fiabilité ok, dernière section donc j'aimerais pouvoir passer plus de temps sur cette section mais je pense que c'est une discussion assez importante à avoir donc notre dernière étape du guide pour l'homme de la rue c'est les responsabilités donc c'est critique vous avez écouté notre présentation vous nous avez vu faire sortir la clé squelette pour ce genre de choses on peut créer des erreurs dans les serveurs des gens, les browser, les machines des gens des problèmes de vie privé on peut faire du mal aux gens au système d'information des entreprises, des pays etc donc il faut faire très d'attention avec ça chaque personne dans cette dans cette salle si vous voulez prendre un conseil donc soyez conscient de ce dont vous rentrez et de l'effet que ça peut avoir sur les gens donc quelque chose de lié un petit rappel en 2016 je m'en souviens j'étais au travail il y a ce gros déni de service en tout cas aux états unis ça a fait tomber twitter, amazon, netflix, etc github et spotify je m'en souviens internet s'est mis à ramer dans tous les états unis c'est la carte des ruptures de charge internet c'était horrible à voir je me souviens les gens rebondissait faisaient des références qui c'était, ce que c'était des acteurs étatiques, toutes les discussions sur twitter une attaque sophistiquée et nouvelle bruce a suggéré que c'était la chine ou la russe, enfin un état nation et yes, ce blog post quelqu'un est en train d'apprendre comment faire tomber internet et puis quelques semaines après on s'est rendu compte que c'était juste le botanique mirai et donc des petits jeunes qui essayaient de faire des déni de service sur des serveurs minecraft donc ça fait peur j'ai beaucoup de respect pour les jeunes et leur talent mais les gens doivent vraiment avoir conscience les dommages qui peuvent être causés par ces choses donc mirai ils utilisait pas vraiment des héros d'ail, mais maintenant ils s'y sont mis mais à l'époque ils utilisaient juste un botanique aiotique et ça fait beaucoup beaucoup de dégâts et c'est difficile de reconnaître le pouvoir d'une zéro day jusqu'à ce que vous en ayez une en main et donc c'est la dernière étape quand vous avez réussi quand vous arrivez à la fin du guide vous réalisez la puissance de ce que vous avez entre les mains et s'il vous plaît soyez très prudent donc c'est tout ce qu'on a, c'est la conclusion donc voilà le sommaire si vous avez des questions, on va les prendre sinon si vous avez pas de temps, vous pouvez nous attraper et on a des stickers aussi super talk, merci beaucoup on n'a vraiment pas beaucoup de temps pour les questions si quelqu'un est très rapide il peut venir vers micro à l'avant on va gérer une question qui serait où les gars, après le talk on sera disponible et on a aussi des stickers à quel endroit donc à l'arrière de la salle parce qu'il y a un nouveau talk dans quelques instants donc pas de questions donc un tonnerre d'applaudissements