sstic

SSTIC 2015 - Jour 2

Un retour sur les nombreuses vulnérabilités SSL/TLS qui ont frappé ces 3 dernières années. Entre les problèmes dans l’automate chargé de contrôler la séquence de négociation TLS, ce n’est pas les problèmes qui manquent. Certains bugs TLS reviennent, par exemple, le GotoFail GnuTLS est identique au bug découvert dans OpenSSL en 2008. Quand on regarde les vulnérabilités sur les piles à état, on à l’impression que les développeurs font les mêmes erreurs aux mêmes endroits, et il est fort probable que la Spec n’aide pas à sa bonne implémentation. On manque aussi de tests négatifs, le fonctionnel prime sur les cas non-droits. Or, ces derniers sont cruciaux en sécurité, mais la complexité de l’implémentation de tels cas pose problème, et des projets comme FlexTLS peuvent peut-être aider sur ce point.

TLS 1.3 apporte pas mal de solutions pour éviter les problèmes précédemment rencontré, mais c’est un standard en cours de développement, et certaines propositions peuvent venir mettre à mal le modèle de sécurité de TLS au profit de la performance.

Les risques d’OpenFlow et du SDN

SDN: Software Defined Networking. Dans le routage traditionnel, le plan de contrôle est propagé via OSPF/BGP et à partir de ces informations, le routeur va déterminer sa table de routage. Le plan de transfert est la partie physique qui mappe les IP avec des interfaces physiques, et qui s’occupe de transférer les paquets ou il faut. Le SDN c’est un peu de tout… avec plein de principes marketing poussé par divers constructeurs. OpenFlow à pour principe de centraliser le plan de contrôle sur un serveur dédié, et de ne garder que le plan de transfert sur les routeurs. (la présentation est très claire !). Du coup les routeurs ne sont plus que des vulgaires switchs OpenFlow.

Pour pouvoir jouer avec OpenFlow, l’ANSSI à développé des modules Scapy (releasé dans le projet scapy !!).

TLS était obligatoire dans la norme, mais à été rendu optionnel dans une évolution de la norme, et les implémentations TLS openflow commencent à arriver depuis 2014 ! On peut se poser la question du cloisonnement des réseau vis à vis des spec d’OpenFlow avec des « fonctionnalités » d’administration du réseau depuis l’environnement de production !! Il est envisageable de DoSser le système OpenFlow en saturant de requête le contrôleur en injectant intelligemment des paquets sur les switchs. On peut jouer sur les contrôleurs, etc… Certains switchs redémarrent lorsqu’on lui envoie trop d’instructions trop vite, ce qui provoque un reboot du switch, qui se retrouve sans règles de routage. (L’orateur enchaîne les exemples de trucs foireux avec OpenFlow, et je vous invite à lire les actes avec attention).

4 millions d’échanges de clés par seconde

Cryptographie basée sur les réseaux. Jusqu’où peut on aller avec ce type de modèle cryptographique ? Ce paradigme cryptographique à apparemment de bonnes propriétés de performance, de simplicité et de sécurité (Lattice-based encryption). Mais le défaut, c’est la signature qui apparemment pose des problèmes. Les orateurs proposent de ne pas attendre le NIST et d’utiliser ce modèle cryptographique. HTTPS quand on veut avoir un bon niveau de sécurité, ça coute cher en perf du fait du mécanisme de négociation et d’échange de clefs. Pour gérer 70k connexions, il faut 6 core i7 au taquet, et plus on monte en taille de clef dans les algos, plus ça coûte cher ! Apparemment, l’approche basée sur les réseaux possède de bien meilleurs propriétés de performance, tout en garantissant un modèle de sécurité équivalent.

(Bon apparemment le « basé sur les réseaux » n’a rien à voir avec les réseaux de données… mais un machin mathématique avec des vecteurs. Personnellement, je n’ai pas les capacité d’ingérer autant d’information en crypto à ce débit. Je vous invite à lire les actes).

Du coup cette crypto se calcule avec des instructions SIMD très simples (les vecteurs aiment le SIMD ?), ce qui permet de faire des optimisations de la mort au niveau CPU. Du coup le second orateur nous explique les différents problèmes d’optimisation de compilation et leur impact sur la performance des implémentations cryptographiques. Du coup en regardant les optim GCC, on peut se rendre compte qu’on peut gratter en nombre d’instructions en utilisant des instructions SSE2 au lieu d’un petit paquet d’instructions simples.

Le bon algo, avec les bonnes optimisations de compilation qui vont bien et on fait de la grosse perfs malgrès le coût inhérent de la crypto.

VLC, BlurAy, DRM & Hadopi

Par le président de l’association Videolan. Association d’élèves de centrale paris, qui nous racontent les problèmes des débuts des années 90 ou les étudiants voulaient jouer à Doom, Pour ça il fallait un nouveau réseau. Pour l’obtenir ils ont monté un deal avec Bouygues sur un problème de transmission de vidéo par satellite. Ainsi naquis VidéoLan. VLC était très populaire car il permet de lire tout sans codec packs. VLC est cross-platform depuis son origine, ce qui à fait beaucoup pour sa popularité. C’est un projet associatif entièrement produit par des bénévoles qui font du pur Open-Source sans licence moisie.

Le multimédia est un chaos absolu, entre les codecs, les conteneurs les muxeurs démuxeurs avec des formats en mode poupées russes (mkv).

Les DRM posent problème aux soft open-sources, les brevets aussi. Les DRM c’est broken by design, puisqu’on file un fichier chiffré à l’utilisateur avec sa clef, en lui imposant de ne JAMAIS regarder la clef… Les DRM sont soit-disant fait pour protéger contre le piratage, mais en fait pour contrôler la chaîne de distribution, et que sans le bon tampon, le fabricant de lecteurs ne peut pas sortir son produit.

Contrairement au DVD, le Bluray contiens des vrais DRM et pas des blagues cryptographiques. Du coup les Bluray contiennent 4 techniques, dont une BD+ qui utilise une machine virtuelle dans laquelle le code du Bluray Disc va pouvoir tourner, Bref c’est balèze. AACS est en place depuis 2004 et n’a toujours pas été cassé. Il embarque un système de rotation de clefs qui fait que tout les mois certains lecteurs se font révoquer et ne sont plus capable de lire de nouveaux contenus. Chaque grand constructeur à une branche de l’arbre des clefs de déchiffrement. Le disque met à jour la blacklist des clefs du lecteur bluray. Les lecteurs bluray font du watermarking sur le flux audio, qui est conservé après reencodage et permettent de blacklister le lecteur ayant servit au Rip du bluray. La stratégie de LIBAACS consiste à collecter les clefs publiques fournies par des anonymes sur des pastebins & cie.

BD+ fonctionne de pair avec AACS, et c’est la grosse galère à re-implémenter.

Vient ensuite le volet juridique et ses problèmes, avec un dialogue de sourds avec la HADOPI, ou des non-réponses, sous fond d’échanges entre HADOPI, Sony et le conseil d’état leaké par WikiLeaks. (Très bonne présentation).

Analyse de sécurité de technologies propriétaires SCADA

Une grande partie des vulns SCADA ne sont pas du fait des protocoles industriels mais d’autres applications tierces intégrés dans le système industriel (SNMP, Web, etc…). Les orateurs se sont donc intéressé au reverse-engineering d’un protocole de communication entre le PLC et le système de contrôle. L’analyse réseau à permis de dégrossir la structure globale de paquet, Le reverse de l’IHM avec sa tartine de librairies à permis de découvrir le code en recherchant les constantes cryptographique dans les librairies. Ensuite une analyse de la sécurité du protocole à partir des informations obtenues par rétro-ingénierie. Une faiblesse dans les aléas servant à la génération de clefs induit un déterminisme dans la séquence de clef. Les orateurs ont donc mis en œuvre un bruteforce qui permet un MitM et donc de contrôler l’affichage et le PLC de façon indépendante.

L’autre angle d’attaque, consiste à analyser le firmware du PLC. Pour récupérer le firmware, les orateurs sont passé par le site du constructeur pour obtenir un firmware à pousser sur le PLC via son interface web. L’analyse du firmware compressé permet d’identifier un algo de compression type LZ trouvé sur WikiBooks. Au final, aucune vulnérabilité n’a été découverte dans le firmware, dont la sécurité à été très bien faite.

HbbTV

Les téléviseurs connectés (smart-tv), c’est une télé avec un OS dedans, qui peut aller sur le net avec un navigateur, et des capacités de lecture vidéo par le réseau. Quid de sa sécurité ? Petit panorama des sources d’attaques possibles: Attaques locales par le LAN, par l’Internet, via le serveur de mise à jour, via la boule locale ADSL (cf SSTIC 2014). Le flux de diffusion vidéo de la TNT peut éventuellement être un vecteur d’attaques, Du coup l’orateur à effectué une espèce de MitM sur le flux TV en envoyant un signal considéré plus fort que celui de l’émetteur légitime. A partir de là, on peut commencer à envisager d’injecter de l’information dans ce flux TV. Dans ce flux, il y a une URL d’application associé à chaque chaine, qui peut faire de l’Overlay sur votre TV. Dans cette page il y a du HTML et du JavaScript (YEAH!). Le scénario d’attaque consiste à injecter une URL qui contiens du JS qui génère une requête UPNP qui demande à votre box d’ouvrir les ports qui vont bien, permettant une prise de contrôle de la TV. Il semblerais que le respect de la SOP ne soit pas le même d’un constructeur à l’autre, et qu’en plus le « navigateur » ne soit pas le même pour traiter les pages HbbTV que celui utilisable depuis la télé. Du coup l’attaque est possible, et ça fonctionne.

Sécurité des cartes à puces

Mise en oeuvre d’une stratégie de Fuzzing sur des cartes à puces. Une carte à puce à un protocole de communication normalisé. Bon, quand on à pas beaucoup de sous, on utilise un Arduino au lieu d’acheter un zuper lecteur à 2000€. Du coup l’orateur à créé un client python qui communique avec un shield Arduino, et il utilise Sulley pour le fuzzing. Ce qui permet de découvrir des buffer overflow sur certaines cartes, qui sont plutôt tolérantes. L’orateur envisage d’étendre ses travaux aux cartes sans contacts.

Fuddly, Un framework de fuzzing et de manipulation de données

Le protocole est modélisé par un graph orienté acyclique. à partir de ce modèle, il est possible de faire de la génération de données, mais aussi d’injecter de la donnée à certains endroits du modèle. Les noeuds du graph servent à représenter les données du format qu’on souhaite représenter. Certains noeuds sont terminaux comme des délimiteurs ou des préambules. D’autres sont non-terminaux et se compose d’autres noeuds. Enfin certains sont des noeuds générateurs. Dans le modèle de fuddly il y à divers types de liens entre les noeuds. Des liens de parenté, de contrainte, etc… Tout ceci permet de prendre en compte les spécificités du protocole que l’on modélise. Chaque noeud peut embarquer de la conf, ou des meta-informations facilitant la manipulation du modèle ou la génération de données.

La manipulation des données (le fuzzing) se fait au travers de disrupteurs qui sont soit spécifique à un type de donnée (donc à un type de noeud). Le framework semble très riche, et prendre en compte pas mal de problèmes classiques du fuzzing, comme le monitoring de la cible, l’enchainement des transformations sur les données, l’automatisation des interactions avec la cible.

Fuddly est disponible ici

Avatar: un framework d’analyse dynamique de firmwares.

Les systèmes embarqués, c’est chiant à audité, on à pas la toolchain de compilation, ni les sources, ni de la doc, ni émulateur. Bref c’est la galère :(. Du coup si on veut utiliser les outils traditionnels de l’analyse de binaires PC on est mal.On sait émuler des processeurs, mais il y a aussi l’émulation des périphériques, dont la présence est obligatoire pour le bon fonctionnement du logiciel. Avatar à pour but de mettre en lien l’émulation du firmware et la virtualisation des périphériques. Pour ce faire, Avatar surveille les requêtes d’I/O dans l’émulateur, et avatar le transmet au hardware, le récupère et le renvoie à l’émulateur. Avatar fonctionnant au travers d’un lien de debug, il y a des problèmes de débit et des limite sur le nombre d’interruptions qu’il peut gérer sans saturer le lien de debug. Diverses stratégies ont été employé par l’Orateur pour contourner ces problèmes avec succès. (Awesome !)

Large Scale analysis of embedded system firmwares.

Une analalyse à grande échelle des firmwares de systèmes embarqués. Les systèmes embarqués sont partout, c’est le fameux IoT aussi bien que les systèmes industriels ou les routeurs. Bref c’est partout… Ces systèmes sont très hétérogènes, avec des systèmes d’exploitation divers, bref, c’est pas évident à analyser à grande échelle.
Pour faire des études de masse, il faut collecter un tas de firmwares, et il n’y a pas de collection publique de firmwares. Certains firmwares ne sont jamais disponibles sur le web, d’autres sont fournis pour mise à jour par les constructeurs, du coup, pour obtenir un max de firmwares, l’orateur à du aller à la pêche aux firmware en les extrayant via JTAG depuis la mémoire des systèmes embarqués analysés.

Certaines mises à jours ne sont pas vraiment des firmwares mais parfois des updates de config sous forme de texte. Du coup il faut réussir à identifier le firmware caché dans la super archive de mise à jour fournie par le constructeur. En prime c’est pas documenté, et il faut « deviner » comment tout ce bordel est agencé dans l’archive de mise à jour, et comment extraire le firmware en lui même.

L’orateur à comparé les outils entre eux, ils ont utilisé BAT (Binary Analysis Toolkit) et l’ont étendu pour l’adapter à leur besoins. Par exemple l’utilsation de carving comme en Forensic pour identifier les divers blobs binaires et identifier leur formats. L’identification de ces formats de fichiers et leur carving bouffe énormément de CPU, du coup ils ont du passer par le cloud pour effectuer ces tâches d’analyse.

Après dépaquetage de la zuper collection de firmwares, on se retrouve avec un gros tas de fichiers, sur lesquelles l’orateur à appliqué des techniques de clustering et de fuzzy-hashs pour voir s’ils contenaient des fichiers communs comme des clefs de chiffrements communes, des librairies connues et vulnérables. (le travail de l’orateur est en ligne !).

Du coup par analyse statique, ils ont trouvé un sacré tas de vulnérabilités dans ces firmares, comme des serveurs webs pourris ou avec des pages web moisies. L’orateur à réussi à émuler certains de ces firwares pour en suite lancer des outils d’analyse dynamique.

Bref plein de firmwares, plein de fichiers,et du coup plein de vulns à la clef !

Challenge SSTIC

Le challenge à eu un impact intéressant sur les téléchargement des émulateurs ST20 sur sourceforge… Le challenge à tenu une demi-semaine pour les plus rapides. Le challenge à été composé de plusieurs couches, avec pour contrainte de fonctionner entièrement offline. Il y a un premier niveau avec 4 couches « faciles », un niveau « exotique » avec du ST20, et un dernier niveau « agaçant » pour faire rager ceux qui croient avoir fini. Le grand gagnant du challenge, c’est ST20, puisqu’il est maintenant supporté dans Miasm2, Metasm, Hopper, et même un émulateur OCaml.

La solution la plus originale, c’est celle au format BD. La plus littéraire est écrite de façon épistolaire. Et la solution la plus pédagogique, c’est celle de Julien Perrot en HTML. Il y a une solution avec des one-liners, élégante et dégeulasse. Et une solution avec plein de chats !

Solution du Challenge SSTIC

Etape 1: le DuckyScript
On découvre un système FAT, avec un fichier duckyscript, qui permet de faire la relation avec une clef USB RubberDucky. Il existe un script spécial qui permet de décoder les frappes au clavier. Ce script génère un script PowerShell encodé en UTF-16

Etape 2: un stage OpenArena. Il y a dedans des textures cachés dans le niveau OpenArena, du coup il faut jouer pour obtenir les textures cachés, et trouver une salle secrete accessible via un rocket-jump au dessus de la lave contenant d’autres textures.

Etape 3: Paint.cap un dump pcap des mouvements de la souris et l’etat des boutons. ça se décode bien, et on obtiens une clef qui aide au déchiffrement.

Etape 4: JavaScript obfusqué non alpha-numérique. Il peut être desobfusqué avec JS Beautifier. En suite le JS utilise l’API WebCrypto. Les IV pour la crypto du JS sont dans le User-Agent, Il faut donc bruteforcer les plateformes.

Etape 5: On découvre un schéma d’architecture avec des transputer. des données de test avec un clair et du chiffré, et un blob à déchiffrer. L’architecture est vieille mais bien documentée. On peut analyser le langage de l’archi, émuler le code en boite noire, ou faire de l’exécution symbolique. L’orateur à choisi l’émulation. à l’aide du code de test, l’auteur à pu tester que son émulation fonctionne. En suite il faut mettre en oeuvre une attaque à texte clair connu pour obtenir la clef. L’émulation n’aide pas sur cette étape là finalement. Il faut donc analyser à la main la logique de fonctionnement pour découvrir le chiffrement par flot.

Etape 6: La stégano imbriquée, ou on à une image jpeg, qui contiens un tiff, qui contiens un gif… qui contiens l’image finale avec l’adresse de contact pour la résolution du challenge.

Rump Sessions

(vidéo)
S’inscrire à SSTIC, c’est très compliqué, et du coup certains essayent des techniques qui marchent pas: Tricher, Soudoyer les orgas, ça ne marche pas. Sinon intégrer la secte des orgas, ça marche mais c’est très très très dificile. Sinon il faut résoudre le challenge contenu dans les actes pour avoir une place réservée (mais pas payée) qui a déjà été résolu ! Résoudre le challenge SSTIC vous garantie une place réservée voir offerte si vous êtes parmis les premiers. Soumettre au SSTIC c’est un excellent moyen d’avoir sa place. La taille MAX (vous pouvez faire moins, 10 pages c’est bien). Le CP du SSTIC accepte les articles Longs (mais pas trop) avec place payée, et les articles Courts avec place réservée.

Donjons Dragons & Sécurité

(vidéo)
Un JDR pour sensibiliser les gens à la sécurité informatique. La sensibilisation par la technique est très mal comprise, et le serious gaming marche bien, et les gens ont de bons réflexes en sécurité physique. Le JDR se compose en deux équipe, une d’attaque, et une de défense. les défenseurs doivent respecter la loi, et la physique, et la disponibilité de la zone défendue. Les mesures physiques se traduisent bien en mesures de sécurité informatique. (Disponible ICI)

Le challenge auquel vous avez échappé

(vidéo)
Une stored XSS dans le wiki du challenge du SSTIC coté stats du user-agent. Bon faut préparer une payload, faire monter le user-agent dans les stats, après il faut inciter quelqu’un du SSTIC à venir sur la page vulnérable, en trollant sur twitter les orgas. Au final on obtiens le cookie de quelqu’un, mais seulement celui des créateurs du challenge, menant à la publication d’un faux challenge pour faire rager.

Rebus-parsifal

(vidéo)
Comment tester votre serveur TLS ? Bah comme c’est l’ANSSI, ils utilisent OCaml et Parsifal. Du coup Rebus peut faire le travail de collecte, et d’analyse des réponse par Parsifal. Rebus ça s’utilise simplement.

ça fait pshit

(vidéo)
L’historisation, c’est très important pour la sécurité défensive. L’idée c’est de rediriger les bruteforces SSH vers un honeypot qui s’appelle Pshit codé avec Paramiko qui log le tout dans JSON. Après on peut mapper ça dans des DashBoard Kibana.(Conf suricata bientôt à barcelone)

Obfuscateur QuarksLab

(vidéo)
L’obfuscation, c’est pas terrible, mais l’idéal c’est d’obtenir une boite noire parfaite. bah c’est pas encore ça mais on s’en approche grâce à la tabulation.

Le vrai coût de la sécurité – Phil Biondi

(vidéo)
les certificats auto-signés ça fait perdre un max de temps, ça bouffe en moyenne 22j dans une vie d’informaticien. Surtout quant on fait du WGET. Parceque ça bloque des outils, du coup Phil à créé un outil qui fait gagner du temps: yolo qui log toutes les actions pour la postérité et qui télécharge les trucs même si le certificat est foireux. Avec post sur twitter des conneries faites par les admins.

HQL – Hyperpasnet Query Language

(vidéo)
Une surcouche au SQL par hibernate qui est injectable. Jouer avec une injection HQL, c’est compliqué à exploité, très chiant et très long. HQL, c’est un parser qui fabrique du SQL, donc il doit y avoir moyen d’injecter quelque-chose dans ce parser pour y caler du SQL. Bah en fait un backslash et deux simples quotes permettent d’échapper au contrôle du parser HQL. Après ça donne une SQLi standard.

Collecte de clefs RSA sur GitHub

(vidéo)
Quand on télécharge 2M de clefs, on peu s’attendre à trouver des facteurs communs. Et en regardant les clefs dispo sur github, on trouve des PGCD avec des facteurs communs Super super faibles genre 2 ! Il y a peut-être un générateur de clefs foireuses dans la nature.

Misc – rédac chef recherche auteurs

(vidéo)
le rédac chef cherche un responsable pour l’exploit corner ou le pentest corner, et des auteurs pour un HS sur les red team (deadline mi-aout).

s(4)u for windows – Aurélien Bordes

(slides)
Pas de commande SU sous windows. On peut faire des choses avec RUNAS mais il faut le pwd de l’utilisateur. Ya PSExec pour le compte système, mais pour les autres comptes ça marche pas. S4U est apparu avec kerberos, et permet de faire de l’impersonation dans le cadre d’une authentification sous kerberos. il existe un s4u pour msv1_0 qui fonctionne et qui s’utilise très facilement. ça nécessite deux privilèges, et pas de secrets de leaké c’est très bien !

BreizhCTF

(vidéo)
Pas de CTF sur rennes, du coup @_SaxX_ à décidé d’en organiser un localement. Il s’agira d’un CTF mode Jeopardy OffLine sur 12h de compétition. c’est le 29 juin à l’Epitech Rennes.

Rump Incident Responce @h_miser

(vidéo)
Tracking d’incidents, bah ya pas de super outil pour faire ça, du coup les gars du cert SG ont créé un outil nommé FIR en django qui permet de suivre les incidents, faire du reporting, tout ça en GPL3 sur github.

Photorec

(vidéo)
Les tests du NIST pour les outils de file carving sont disponibles. Normalement, un outil de carving à pour but de faire gagner du temps à un être humain dans le cadre d’une analyse forensic. Petit comparatif, et du coup Photorec s’en tire aussi bien qu’un outil payant.

DFF

(vidéo)
Un outil Open-source d’investigation numérique. Après avoir trouvé un Nexus 4 qui trainait dans la gare, les auteurs de l’outils en profite pour en faire une démo.

HeuriSSTIC et repos git

(vidéo)
Que deviennent les outils releasé à SSTIC. Certains sont vivants, d’autres pas, et certains font leur retour.

TCP2Pipe

(vidéo)
Lors d’un pentest, l’orateur à utilisé les named-pipes pour tunneler une connexion tcp au travers d’un named pipe.

F*** me, I’m famous

(vidéo)
Les IOC de TV5 sont pas terrible, quelques vieux tools. certains sont des vieux malwares qui utilise ms-sql server comme C&C. après analyse, il semblerais qu’il s’agisse d’une attaque par APT28.

Youkeepass

(vidéo)
Beaucoup de gens utilisent KeePass, c’est pas funky, c’est en local et pas dans le cloud. Du coup pour être sur de rien paumé, l’orateur utilise les YoutubeID comme mot de passe. La distribution de l’entropie de ces YID est pas trop mal. bon par contre faut se souvenir de l’association vidéo – site web pour retrouver le mot de passe. Du coup l’orateur à créé une application web YouKeePass pour gérer les mots de passes associé aux vidéos.

Tinder in movies

(vidéo)
Géolocalisation Tinder sur l’amphi du SSTIC, on y retrouve Pappy. S’en suit une rump sur les codes présents dans les films. Par exemple, dans Kung Furry hackerman utilise du java pour remonter le temps. Dans IronMan 2, le méchant contrôle les armures avec un doctype HTML. Dans Hacker2015, ya juste un commentaire de merde. Et dans unthinkable, on arrête des bombes en plaçant des md dans excell.

IVRE, Il scan l’internet.

(vidéo)
IVRE: Instrument de Veille sur les Réseaux Exterieurs, qui a pour but de scanner la surface externe d’un SI. Du coup l’orateur à testé ça sur l’internet, et à trouvé des machines modbus sur le net. Il peut donner des statistiques intéressantes. On peut rechercher les services les plus ou les moins
présents. On trouve des interfaces SCADA, des éoliennes, des fermes etc… et c’est en ligne sur github

MIASM – Dependency Graph Serpi

(vidéo)
Slicing de binaire avec miasm, qui permet de remonter ce qui influe sur la valeur d’une variable, très pratique en reverse engineering. Ca fait des gros graph dans IDA, et du coup avec Miasm, ça viens colorer les noeuds comme il faut pour spotter les endroits qui influent sur la variable. Au passage Z3 viens résoudre l’équation éventuellement, et détermine les ranges de valeurs possible pour la variable analysée.

Sibyl

(vidéo)
De retour sur un scan IVRE, un firmware perdu sur un NFS exporté, codé en arm/mips/st20, c’est galère de reconnaitre les fonctions et leur prototype quand on reverse. Du coup pourquoi pas émuler la fonction en regardant les effets de bords ? Du coup avec Miasm et Sibyl, ça permet de reconnaitre des fonctions bien dégeux automatiquement. Et c’est dispo en ligne !

Le cloud maison à pas cher ?

(vidéo)
http://natisbad.org/nas-kernels plein de port de trucs sous Arm. Plein de NAS synology supportés, et d’autres NAS Pas cher. Bientôt un support crypto pour les proc des Netgear.

Application de chiffrement de SMS (suite)

(vidéo)
Nouvelle version de l’application de chiffrement cassée l’an dernier. La clef est désormais de 64bits, et la vulnérabilité de l’an dernier est toujours présente. Il faut 40s pour casser le chiffrement sur un i5 sur la 1ère clef, et plusieurs jours pour bruteforce la 2ème partie de la clef.

Jardin Entropique

26-28 juin sur Rennes, 3 jours de conf, ateliers et perfs sur des projets open-sources organisé par le hackerspace de Rennes.

SIEM

(vidéo)
Il n’y a pas de SIEM Open-Office, alors du coup, en se basant sur prélude, l’orateur en a créé un. C’est lent, mais on peut faire des macro, et les managers adorent ! Bon finalement une bonne IHM c’est pas si mal, et LibreOffice manque de lib graphiques pour ça…

NetZob

(vidéo)

Reverse d’un protocole en 3 minutes avec NetZob (c’est énorme !!!). On prend un .pcap, on le cale dans NetZob, et on reconstruit les messages. Une fois les messages reconstruit, ont obtiens un modèle des messages. On reconstruit en suite l’automate et on obtiens un modèle qui peut servir à faire du Fuzzing.

CSV

(vidéo)
La manipulation de gros fichiers CSV pose problème à certaines librairies de parsing CSV. Du coup l’orateur à créé un outil C++ très petit et très simple qui permet de faire des transformations sur les fichiers .csv. Insertion ou suppression de colones, selection de lignes ou de colones en fonction d’une regexp, bref simple et efficace. Encaisse des fichiers de plusieurs Go même gzippés. C’est disponible en ligne !

USBInspector

(vidéo)
Un outil d’analyse de communications USB. Il s’agit d’une board qui fait un MitM USB. Les deux parties USB communiquent entre elles au niveau Userland, du coup on peut utiliser du python. ça a permis par exemple de résoudre la partie 3 du challenge SSTIC par rejeu du .pcap. Avec une démo sans filets ni tests préalables !!! GG !!!!

Objets connectés – SynActiv

(vidéo)
Sniffage de bits en hard. Tests avec une poupée connectée qui peut s’utiliser hors ligne avec un smartphone. Mais l’orateur n’a pas de smartphone. 1ere étape, démonter la poupée. En fait dedans il n’y a rien du tout, juste un kit main libre, sans intelligence ni bits à sniffer, ni PIN pour sécuriser l’accès à la poupée. Dans l’application il y a une lise de « badwords » genre zoocopulatoire, carburateur à beaujolais etc… Pour exécuter l’application, l’orateur à utilisé Qemu et quelques outils android pour faire parler la poupée !

GreHack 2015

à Grenoble, sur le campus, http://grehack.fr/ . Le CFP est sorti, le twitter c’est @GrehackConf

Botconf 2015

En décembre, dans les locaux de Google. Le CFP court jusqu’au 15 Juillet. Le site de la conf ICI.