SSTIC 2019 - J2

Journey to a RTE-free X.509 parser

Un parser « safe » à coup de méthode formelle (ouch). X.509 c’est un format d’encodage des certificats en Type, Longueur, Valeur, avec une complexité horrible. C’est de vrais poupées russes, et c’est une source d’erreurs de programmation et donc de vulnérabilités. L’orateur détaille un exemple de vulnérabilité liée à X.509 lors de la vérification d’un certificat par une bootrom.

Un parseur X.509 « propre » c’est essentiel pour la sécurité, et très délicat à implémenter. Le C c’est vachement bien, il y a (encore) pas mal de dev C. Par contre c’est source d’erreurs fatales, alors on aimerait bien avoir du C99 propre, et pas de trucs exotiques à base de pointeurs de fonctions & cie. Pour la compilation, on vient utiliser des flags de compilation stricts pour limiter les erreurs.  Les orateurs se sont donc appuyés sur Frama-C, une plateforme de plugins d’analyse de code. A l’aide de commentaires on va venir spécifier des propriétés que Frama-C va vérifier.

Les orateurs ont passé autant de temps sur le dev que sur les annotations Frama-C, mais ils étaient débutants avec Frama-C, et avec un peu plus d’expérience ils iront plus vite par la suite. Pour la gestion des pointeurs de fonctions, le framework aide énormément le développeur pour valider la sûreté de leur emploi. La courbe d’apprentissage est loin d’être triviale.  Il manque aussi de la doc sur les idiomes de développement usuels pour faciliter le dev. Au début, les warnings sont compliqués à digérer, mais ça s’arrange après. Le développeur capitalise sur ses annotations, et il n’a pas à les modifier lorsqu’il patch son code (bon sauf s’il se foire sur ses annotations hein…). Les plugins Frama-C sont complémentaires les uns des autres, et on peut les activer au fur et a mesure du dev pour progressivement durcir et améliorer son code. Le code est disponible sur le Github de l’ANSSI.

DLL Game and auther mis-directions

Chargement de DLL Windows et cie. C’est souvent qu’on à des problèmes de chargement de DLL sous Windows, avec plein de réponses obscures sur des forums ou on vous dit de formatter/réinstaller. WinDBG est un debuggueur windows qui marche bien, mais il faut breaker sur tout les chargements de DLL, et c’est chiant. Alors un dev de Microsoft à créé Dependency Walker pour analyser ce genre de problèmes. L’outil à été developpé il y a 20 ans, mais il n’est pas vraiment supporté par Windows, et le loader NT à pas mal évolué.

L’orateur à donc redéveloppé l’outil pour analyser le chargement des DLL en comparant le binaire sur disque avec sa version exécutée. Le chargement de DLL sous Windows est très complexe (cf actes). Avec cet outil on peut analyser les dépendances de certains binaires qui charge des DLL qui n’existent pas sur le disque, et du coup en écrivant une DLL malveillante à cet endroit, on peut injecter du code arbitraire dans l’exécutable. Si cet exécutable est démarré par une tâche planifiée ou est lancé au démarrage de la machine, l’attaquant obtient une persistance sur la machine.

Mirage: un framework d’attaque BLE

Les orateurs ont créé un framework modulaire qui travaille au niveau radio pour implémenter des attaques BLE. Les frameworks disponibles en open source ne sont pas très adaptés pour réaliser des attaques BLE. Les communications BLE se font sur de multiples canaux avec un mécanisme de sauts de fréquence, du coup il faut que les devices se synchronisent pour les sauts de channels. Le framework intègre donc un ensemble de modules pour gérer les phases de connexion master/slave, le scan de devices, l’appairage, etc… Et bien entendu, des modules d’attaques pour faire du MitM, du Hijacking comme beetlejack de @virtualabs, et du sniffing BLE comme avec ubertooth ou beetlejack.

BGP et géométrie Riemmanienne

La surveillance de graphes, c’est pas simple, parce que les liens et les lieux représentent des éléments de nature diverse, mais ça permet de représenter des relations faibles voir incertaines. La surveillance de graphes consiste à observer un graphe dynamique et de décider si un changement local aboutira à un changement local. Les graphes sont extrêmement sensibles à un changement local, et ça peut affecter profondément sa topographie (plus proche chemin, communautés etc…).

Le spectre d’application de la surveillance de graphes est énorme, des réseaux sociaux à la génération de protéines en passant par la sécurité informatique.

L’orateur détaille en suite les bases de la géodésique et les théorèmes mathématiques applicables: courbure de ricci, théorème de poincaré, Gauss-bonnet, Gauss et sa fourmi. (T.T finalement la crypto c’est pas si dur…). L’ensemble de ces travaux mathématiques commencent à être appliqués dans le domaine informatique sur les graphes.

Rappel sur le problème de la brouette de Monge et du transport de charge d’un point A à un point B de façon optimale. Ce problème à été posé à Monge par Napoléon pour que les soldats ne soit pas épuisés par la tâche de déblaiement/remblaiement. Kantorevitch a adapté ce problème à la production et au transport optimal d’Obus. Ce problème est semblable au routage de paquets dans un réseau. Lorsqu’on applique Gauss-Bonnet à un graphe, on peut observer les changements de topologie des graphes à fort impact.

Sur internet, il y a entre 10k et 50k annonces de changement sur BGP par seconde ! L’intégralité d’internet est constituée de 60k à 150k noeuds. L’orateur a donc mis en place une infra d’intégration de feeds BGP qui vient créer des « snapshots » d’internet toutes les minutes sous la forme d’un graphe. Une fois le graphe obtenu, on peut calculer les courbures sur le graphe précédent et le graphe suivant, puis la différence entre les courbures. En observant la variation de ces différences, on peut mettre en œuvre un seuil de détection d’anomalies topographiques.

Lorsque Google s’est foiré sur une annonce BGP appellé leak, l’ensemble de l’internet est annoncé comme joignable depuis le réseau de Google et au départ de Google, du coup l’Internet s’est topologiquement rétréci. Si l’on compare la distribution des anomalies par rapport à Chi2, on se rend compte que tous les hijack BGP et les leaks sont en queue de distribution et complètement écartés par rapport à Chi2.

Lorsque l’on compare les plans de transport avant une anomalie et après une anomalie, on observe le transfert de la charge des paquets d’un chemin vers un autre. Bon quand on veut faire ça en temps réel avec un graphe de l’internet toute les minutes, il faut faire tout ces calculs en moins d’une minute… oubliez Python, l’orateur à testé et ça marche pas à cause du GIL. (bon et sinon ya Celery hein 😉 )

Lorsque l’on observe les variations topologiques BGP par rapport à la géopolitique, en prenant en exemple la Russie et l’Ukraine, on observe deux boules connectées, et la formation d’une petite boule qui progressivement migre de l’Ukraine à la Russie, puis s’y intègre. Actuellement on observe la formation d’une nouvelle boule qui s’extrait de l’Ukraine et qui correspond au Dombas, on peut donc s’attendre à quelque chose sur cette région dans l’avenir.

La recherche multidisciplinaire est un impératif en cybersécurité, car cela mélange géopolitique, informatique, mathématiques, etc…  et le domaine du suivis des graphes est très jeune.

GUSTAVE: Fuzzing de systèmes d’exploitation embarqué

L’objectif était d’étudier des OS embarqués tout petits, peu dynamiques et dont le comportement est défini à la compilation, avec des couches logicielles métier très spécifiques et avec des mécanismes de ségrégation mémoire très forts pour éviter qu’une application puisse en corrompre une autre.

Afin d’éviter l’analyse manuelle des syscall dans des OS aux fonctionnalités obscures, les orateurs se sont orienté sur du fuzzing piloté par la couverture de code. Pour se faire, les orateurs se sont orienté vers AFL. Le problème, c’est comment adapter AFL, sans le modifier, et éviter des dev spécifiques à l’OS. Pour éviter ces modifs, AFL croit qu’il fuzze Qemu. Les orateurs ont donc développé une couche intermédiaire via une board Qemu générique intégrant AFL. les fork sont ainsi simulé par snapshotting de la VM. Le TCG de Qemu n’a donc pas eu à être modifié, et donc on peut bénéficier des modules d’accélération matérielle pour les infra PPC et x86. Qemu a une API mémoire bien foutue qui permet de mettre à jour la bitmap AFL dans la cible. Comme AFL peut partir d’inputs random pour générer un PNG valide, les orateurs ont eu pour idée de fournir en entrée des syscall à AFL qui va le transformer en programme « malveillant ».  Pour détecter les timeout, les fins d’exécution ou les accès illégitimes, il faut jouer avec les breakpoints Qemu. Pour les accès mémoire, les orateurs ont développé un oracle pour détecter les accès mémoire illégitimes.

Dissection de l’hyperviseur VMWare

Quelle confiance peut-on avoir sur la virtualisation ? Le risque principal, c’est que l’isolation entre les machines est logique, et donc un VMEscape est possible. VMware offre de nombreuses fonctionnalité permettant d’améliorer l’ergonomie. D’un point de vue recherche de vulnérabilités, c’est une bonne cible. 

La virtualisation se met en oeuvre avec les extensions VT-x et utilisent des structures VMCS pour contrôler la transition entre le ring -1 de l’hyperviseur et le ring 0 virtualisé du guest. Le mécanisme backdoor de VMWare passe par des ports d’entrée-sortie spécifiques et qui ne nécessitent pas d’être ring0. Il n’y a donc pas de différenciation de l’origine de l’appel. RPCI sert à faire passer des messages du système invité vers l’hyperviseur. TCLO permet de faire des requêtes de l’hyperviseur vers le système invité. Ces commandes sont une cible privilégiée pour le fuzzing et la recherche de vulnérabilités type VMExit.

Le reverse-engineering de l’hyperviseur est complexe car il y a beaucoup de DLL, plein de chaînes de caractères dans les binaires, etc… Bon ça aide pas mal à la rétro, et par le biais des xrefs on peut repérer plus facilement les mécanismes non-documentés. On recherche ensuite des RPCI correspondantes, ce qui permet de trouver de nouvelles fonctions à fuzzer.

Dans l’hyperviseur il y a la VMDB qui fonctionne comme un système de fichiers et qui contient plein d’informations sur le système invité. Sous windows, on a deux processus: vmware-vmx.exe qui gère l’hyperviseur et vmware.exe qui gère l’interface graphique. La VMDB est au coeur des IPC entre ces deux composants. On peux donc mettre des breakpoints sur les readfile/writefile de la VMDB et observer les RPC.  Coté mode UNITY c’est l’host qui fait basculer le guest en communiquant avec les extensions tools via le protocole Backdoor.

Les orateurs ont ensuite mis en place du fuzzing sur ces RPCI pour provoquer des crash avec plus ou moins de succès. Du printf qui fait foirer l’hyperviseur au bug XPATH dans la Gui.

Watermarking Electro-magnétique

Comment insérer des marqueurs dans une cible non-coopérative ? On génère une perturbation qui va atteindre un système de stockage et reproduit par la cible pendant une durée plus ou moins longue. On obtient donc un canal caché pour stocker et transporter de l’information. En fonction des capacités du canal de com et du stockage, on peut envisager divers scénarios. 

Exemple de scénario de Watermarking: le tatouage de films projetés en séance permettant d’identifier dans quelle salle à été filmé le film. Autre exemple, avec un enregistrement audio, en repérant le bruit dans l’enregistrement généré par l’alimentation électrique, on peut en déterminer une signature caractéristique du lieu qui à alimenté électriquement l’enregistrement.

Le cas d’usage du présentateur vise le survol de drones. L’idée est d’insérer lors du vol un marqueur sensible qui va se retrouver dans les journaux de vol, et ainsi on va pouvoir lors de l’enquête déterminer si le drone à survolé la zone interdite ou non.

L’orateur à créé un Lab à l’aide d’un drone civil dépourvu d’hélices pour éviter qu’il ne s’envole (petit drone si tu n’a pas d’hélices…. bah tu peux pas voler).  Du coup on met le drone en mode vol nominal, et on injecte des perturbations EM, on regarde si ça fini quelque part dans un stockage et si ça impacte le profil de vol ou le rayonnement EM de la cible, et combien de temps il dure. Cette technique est très adhérente à la cible, ça fonctionne dans des conditions idéales, maintenant à voir ce que ça donne en vrai.

10 ans de challenge SSTIC…

Triste de la fin du challenge SecuriTech, Stéphane Duverger s’est dit que ça serait sympa d’avoir un challenge pendant le SSTIC. Il propose un mini CTF, mais le CO n’était pas chaud, et propose à la place un challenge Avant le SSTIC. A l’époque il fallait écrire une solution en 7j. 

Le challenge était une image de boot disquette basé sur le mode virtuel des 8086. A l’époque un truc qui servait a rien à part faire chier. Hélas au même moment IDA à sorti le support de BOCHS. Puis il y a eu les cadeaux dont le fameux trophée moche.

Le challenge SSTIC 2019

Le scénario était basé sur un pseudo-téléphone virtuel qui fonctionne dans Qemu et qui boot sur un arm-trusted-firmware avec iROM, BL1, BL2, Moniteur, Secure OS + edk2(BL33)+ Linux. C’était un boot chiffré avec uniquement l’iROM en clair, le Keystore non fourni. 

4 stages: analyse d’une trace de consommation de courant lors d’une exponentiation modulaire, un circuit logique piloté par bouton, une appli en DWARF2 et un Skipjack whiteboxé dans une VM répartie dans des niveaux d’exceptions. Le code du challenge est disponible sur Github.

Solution du challenge SSTIC.

Quand on trace avec numpy et matplotlib la consommation, on observe rapidement une zone de consommation forte, et quand on zoom, on observe deux patterns qui se répètent et qui correspondent aux bits de la clef à 1 ou 0. Le pattern match avec l’exponentiation rapide. (T.T)

On peut en suite booter la vm Qemu avec le secure element. Le schéma du secure element permet avec un découpage intelligent de re-générer le code en Python, et on est capable de déterminer les boutons pressés à partir du sha256. 

La 3ème étape est un fichier ELF arm64. L’orateur à utilisé Ghidra pour décompiler le code, et on retrouve une chaîne qui fait l’objet d’une comparaison. A l’exécution dans Qemu, la copie de chaîne n’est pas atteinte. Quand on exécute le binaire dans un environnement « sain » ça foire aussi mais différemment. Quand on regarde de plus près le fonctionnement de la gestion des exceptions qui se fait en DWARF. Ce langage est interprété, alors l’orateur l’a localisé, puis à extrait les 57M de lignes de codes. Une fois la clef trouvée, on tombe sur un autre binaire qui contient « /dev/sstic » dans ses strings. Avec STRACE sur le binaire, on voit 4 ioctls qui servent à communiquer avec un driver. Il faut donc reverser le driver (et c’est HARDCORE).

RUMP Sessions

Cette année c’est 3 minutes par speaker (ouch)

rump 1 – SSTIC

Le président du sstic à décidé de dissoudre le commité d’organisation de SSTIC et mettre un terme à la chianlie des gilets rouges, pour remplacer le régime gérontocratique par un régime fachiste. Raphael Rigot est élu président de l’association pour 3 ans. Remerciement aux anciens et futurs retraités: NicoB, Ben, Moutane et OlivierL. Retour sur la significations de la couverture du SSTIC. 

Les places cette année se sont vendue en 9 jours. La partie la plus chère c’est le Social Event, et le couvent des jacobins. 205k euros, sans sponsors et uniquement via la billetterie. Le budget du couvent à pris 11% par rapport à l’année dernière. 24500€ pour l’amphi, 1020€ pour la connexion pour le streaming, la config du VLAN pour 500€ et le transpalet pour les actes…. 28€

rump 2 – Pourquoi? – Pierre Capillon

Pourquoi la carte est déchirée ? pourquoi pas ! et pourquoi les couleurs correspondent pas ? parce qu’une carte c’est fait de plusieurs couches et que donc ça matche pas toujours. Côté streaming, la doc complète à été diffusée sur le blog du SSTIC.
Pourquoi ça clignote ? Il y a un convertisseur HDMI vers Ethernet qui passe sous les planches et les câbles sont dénudés et très tendus, du coup il y a des faux contacts, et comme la vidéo est en full HD ça se voit.

rump 3 – Le maillon faible – Patrice Auffret

Quelle est la machine la plus vulnérable sur Internet ? Par exemple celle qui a le plus de CVE dont le score est suppérieur à 7.5, exploitable à distance. Pas de test unitaire des CVE mais uniquement des vulns potentielles. Plus de 10, oui, plus de 20 encore, plus de 50 il y en a encore, plus de 100 ? Il y en a 2, une aux US, une en Suède. Du Apache 1.3, du PHP 4.4… est-ce un honeypot? en tout cas il est très crédible.

rump 4 – WMI attack tools: WMI Shell, WMImplant, Crackmapexec – Andrei Dumitrescu

Plugin Crackmapexec qui va vous changer la vie ? Comment extraire des choses si tous les protocoles sont bloqués sauf le 135 ? Bon ya WMI, on peut l’interroger et s’en servir pour exécuter des process mais on peut pas en récupérer la sortie. Sauf si on le stock dans la base WMI. L’orateur à donc créé un tool qui fait le café, bientôt dans le Github de Orange Cyberdefense. 

rump 5 – When a reverser does pentest… – Fabien Perigaud

D’habitude l’orateur fait du reverse d’habitude, mais là c’était un pentest sur Symphony, avec un module de payement qui fait appel à un binaire externe avec des paramètres contrôlés par l’attaquant, et la c’est comme dans un CTF. La fonction à un pov STRCPY tout pourri avec un Main qui termine par des exits, l’argument contrôlé est double-encodé Hex+UUEncode. Du coup en regardant plus loin il y a une vuln dans le binaire exploitable en ROP. On brute-force puis ça passe ! Le vendeur malgré un responsible disclosure n’a pas répondu à l’auteur. 

rump 6 – Thermomix: all your recipes are belong to us – Jean-michel Besnard

Le thermomix tourne sous linux, le truc vert qui contient les recettes c’est une clef USB chiffrée. Comme sa femme n’a pas voulu qu’il ouvre le thermomix pour chercher un port jtag, il a donc acheté la clef. La clef n’est pas chiffrée… Il y a peut-être un système de restoration ? et ouaip, il y a une vuln dans le tar, il y a plein de contraintes d’exploitation, mais on peut utiliser tcpsvd pour binder un shell. Quand on regarde le code DCP il sert pas a déchiffrer mais à vérifier si la clef est bonne… on récupère la clef hardcodée dans le kernel. On modifie les fichiers qui sont signés… Avec un raspi0 on fait un fake-usb et on peut patcher la recette du far breton.

IceBox

VM introspection basé sur FDP et Sandbagillity, et ils ont rajouté du code natif pour permettre le tracing en temps réel, des os helpers, etc… Multi-platforme, basé sur un virtualbox patché prêt à l’emploi, performant, et supporte windows 10 1809. Le code sur Github.

rump 7 – IDATag – Tag ta base – Arnaud Gatignol

Décalé ?

rump 8 – L’analyse statique et le testing a la volée pour les nul(l)s – Constantin Vurli

Les humains font tous des erreurs, alors on peut se monter une toolchain qui fait de l’analyse statique à la CI. Pour faire le pipeline de test sur gitlab/github, on monte un conteneur docker avec le tooling. Vous poussez ça sur un registry docker, et vous créez un CI avec un simple fichier.

rump 9 – Surimisp – Eric Leblond

Faire le lien entre Suricata et MISP. Suricata c’est plus qu’un NIDS, il peut par exemple générer des évènements en fonction de ce qu’il observe. Il n’est pas fait pour gérer des longues listes d’IOC. Une bonne source d’IOC c’est MISP. On récupère les IOC de MISP via https, et on crée une alerte format JSON avec les méta-données de Suricata. Le code est sur github.

rump 10 – scaffold

Une carte open-source open-hardware pour faire de l’évaluation de sécurité de circuits intégrés qui permet de faire de la mesure de consommation, du contrôle d’alim, des signaux de triggers, etc… avec une API Python pratique à utiliser avec une grosse doc.

rump 11 – Painless registry forensics with Regrippy – Simon Garrelou

Un outil de collecte des hives qui contiennent les clefs de registres. L’idée c’est d’aller récupérer ces infos avec regripper, mais c’est du PERL, et le dev est tout seul sur le projet. Du coup rewrite en Python du projet basé sur Python-registry. Le code est sur github et a été testé en réponse sur incident.

rump 12 – Mi casa es tu casa

Le risque du AirBNB et du couch-surfing. On vous file souvent un accès wifi et un pc en libre service, avec tous les mots de passes enregistrés ou la box de l’opérateur. Les accès des box opérateurs sont souvent les 3-6 derniers chiffres de la box. Si vous trouvez pas le password vous pouvez le resetter, mais ça efface la conf de la box parfois. Une fois la box récupérée, vous pouvez changer les DNS, ou faciliter l’accès via DynDNS, puis en ouvrant des ports, ou les interfaces d’admin à distance, voir configurer carrément du transfert d’appel !

rump 13 – La rhétorique et le serpent – Driikolu

Comment argumenter face à un utilisateur de Python 2 ? bah les mecs de python 2 aiment bien les print sans parenthèses et puis les strings c’est mieux. En Python 3 on peut utiliser des emoji !!! Bon vous avez une grosse baseline Python2 ? bah 98,9% des libs Python 2 sont compatibles Python 3…. Il n’y a pas de support Python 2 sur votre OS… si vous êtes sur du legacy, utilisez PERL

rump 14 – The hidden recorder into mstsc

RDP c’est plein de channels, dont des channels graphiques et es channels de compression. Il y avait déjà des artefacts mstsc extractibles avec un outil de l’ANSSI. Mais dans le binaire, il y a moyen d’activer un recorder en activant 2 clefs de registres. Ca génère du Calista, dont le décodage est implémenté dans FreeRDP du coup on peux décoder le flux enregistré.

rump 15 – Dexcalibur

Automatisation de reverse android avec Frida.re. La desobfuscation c’est une perte de temps quand on audite ou on reverse une app android. Du coup l’orateur à voulu automatiser tout ça. Faut poser des hooks d’un peu partout, c’est le bordel, on fait tout ça à la main cest chiant… Du coup l’orateur a fait une interface permettant de gérer la toolchain en NodeJS. L’outil est disponible sur Github (et il déchire !!!!)

rump 16 – Trop de théorie tue la pratique

Les étudiants manquent de pratique… parfois arrivés en bac+5 en master spécialisé sans savoir faire quelque chose sur un pc sans interface graphique. Du coup proposition pédago: faites leur monter un réseau de PME avec tous les services puis défoncez le a coup de lazagne, metasploit mimikatz, etc… pour leur apprendre la vie.

rump 17 – 

Dieharder est une succession de tests de PRNG successeur de Diehard par Marsaglia. PASS: le prng doit etre bon, FAIL c’est qu’il est à chié, WEAK c’est qu’il ne sait pas se prononcer mais ça pue… le problème avec /dev/urandom c’est que ça sort régulièrement des WEAK. Après questions sur des mailing list, personne ne répond.

rump 18 – L’émeute – Nicolas Ruff

Tchap est un système de messagerie interministérielle basé sur Riot qui implémente le protocole matrix. Hommage à Jérome Chappe. 1h après sa mise à disposition, une vulnérabilité à été découverte.

rump 19  – REsponsible disclosure GSMA

La GSMA c’est un ensemble de partenaires industriels qui bossent sur les réseaux mobiles. Ils ont lancé un programme de responsible disclosure pour les bug non-spécifiques à un opérateur ou a un matériel mais liés au protocole ou aux standards. Le process est trèèèès détaillé. Donc si vous avez des vulns à remonter n’hésitez pas.

rump 20 – IDATag – Tag ta base

Un outil de Reverse, plugin IDA publié par thalium sur github. Comment offrir une vue unifiée sur ida pour partager de l’information avec ses camarades reverseurs qui vont ouvrir votre IDB ? Eh bien faut utiliser IDATag. On peut ainsi tagguer les fonctions sur la vue fonction.

rump 21 – Les tests d’intrusion c’est vraiment trop difficile

Dans le milieu bancaire, il y a de la ségrégation réseau, des composants durcis, des mots de passes random, etc… heureusement qu’il y a des partages avec des n° de CB, ou des exports Keepass, ou un fichier Keepass avec un fichier .txt qui contient les mots de passes. Bon quand on fait du Web, ya du waf, ya des trusted type,  les entrées sont sécurisés. Heureusement lors des réunions d’initialisation, on nous dit qu’il y a des comptes user et admin, et en prime un super-admin dont le compte est filtré … ou pas. l’Intel CSME contient un outil ftpw64.

rump 22 – Visualisation pour l’investigation en cybersécurité – Malizen

Typiquement un prog de merde tourne un dimanche matin, et vous êtes appellés en réponse sur incident. On utilise snort et syslog pour avoir des infos avec un pic d’innactivité à 15h. Du coup a l’aide de divers outils de viz on fait l’investigation.

rump 23

Bon quand on fait de la sécurité, on doit se tenir au courant des vulns qui sortent, des news etc… et ça fait beaucoup d’information à digérer pour un défenseur…

rump 24 – CLIP OS 4

Non, ClipOS4 n’est pas mort, l’orateur à forké Clip OS 4, puis est parti du SDK de gentoo hardened pour créer un clip SDK bootstrap … modulo quelques bidouilles on à un SDK qui marche, qui sera releasé avec une image QCow et un CLIP4 qui boot

rump 25 – MAC Jammer

Rump non-streamée, pas de liveblogging donc 😀