SSTIC 2017 - J2

Après une excellente journée hier, on est reparti dans un amphi blindé ! (wrapup j2 par @xme ici)

CrashOS : Recherche de vulnérabilités système dans les hyperviseurs — Anaïs Gantet

Travaux initiés par l’auteur de Ramouflax, et repris par l’orateur. En bref, la virtualisation c’est une technique permettant de faire fonctionner plusieurs OS sur un seul hardware à l’aide d’une couche logicielle: l’hyperviseur. Forcément, l’hyperviseur, c’est très très sensible, parce qu’un attaquant ayant compromis jusqu’à l’OS peut s’attaquer à l’Hyperviseur pour atteindre les autres OS guest.

L’approche choisie pour les tests consiste à construire une VM avec une configuration système atypique: absence de pagination etc… et de lancer des tests stimulant les fonctionnalités de l’hyperviseur (hypercall fuzzing ?). CrashOS est issue de ces travaux et fournis des options de configuration adaptés aux tests exécutés.

CrashOS à été utilisé sur Ramouflax, VMWare et Xen. Et parfois ça crash (ouille). Il est conçu à base de C et d’assembleur x86, et propose un système de configuration à base de macro C. Il gère les exceptions, l’accès à la mémoire physique, la communication avec les périphériques dont la mémoire vidéo qui peut être très sensible, ainsi qu’un support de paravirtualisation pour tester d’autres hyperviseurs.

On ne fait pas de fuzzing aveugle avec CrashOS, mais on restreint et on cible les actions & configuration qui sollicitent un mécanisme particulier de l’hyperviseur. Les parties sensibles de la virtualisation c’est l’exécution/émulation d’instructions sensibles, les traitement des périphériques, les traitements vidéo, la gestion de la mémoire.  Les tests de CrashOS combinent parfois certaines techniques.

Exemple avec l’écriture d’un GROS buffer de 64 octets sur le port série qui viens écraser des informations sur la configuration de la VM, provoquant le veautrage en règle de VMWare. Autre exemple: changement de privilèges en effectuant un far jump dans une zone de mémoire noyau depuis une zone mémoire userland. Ce test est basé sur une vulnérabilité XEN qui provoque une escalade de priv ring0. Les vérifications au niveau mémoire n’ont pas été faites correctement.

ProTIP: You Should Know What To Expect From Your Peripherals — Marion Daubignard, Yves-Alexis Perez

Un talk sur les périphériques PCIExpress et les problèmes de sécurité associés. Les périphériques PCIe concernent la carte graphique, la carte réseau etc… La délégation de périphérique permet une meilleur performance en déléguant la gestion des exceptions à un autre composant que le CPU/Noyau. Cette performance se fait grâce à l’économie des changements de contexte, etc… Dans le cas de cartes graphiques « cloud » où l’attaquant peut prendre le contrôle de ce qui s’exécute dans le périphérique, la question se pose de ce qu’il peut faire via ce périphérique « malveillant ».

PCIe n’est pas vraiment un « bus » au sens traditionnel mais un réseau avec des paquets et les périphériques peuvent discuter en « pair à pair ».  Les communications sont hiérarchisées: cpu vers périphériques, périphériques vers mémoire, périphérique à périphérique. Pour contrôler ces flux, il existe des outils, mais les techniques sont nombreuses, les specs sont floues et du coup les chances d’erreurs d’implémentation sont grandes. D’où l’Intérêt d’étudier ces flux et ces techniques de contrôle.

ProTIP est un outil pour calculer la connectivité réelle d’un composant à un autre. Pourquoi Prolog ? parcequ’en prolog on part d’une base de connaissance (un ensemble de prédicats), et à l’aide d’un moteur d’inférence, on viens « répondre » à des questions ou X est l’inconnue. Du coup, les règles de fonctionnement de PCIExpress ont été rentrés dans ProTIP qui va en suite générer une série de traces possibles qui va décrire comment un périphérique peut communiquer avec un autre.

Truc bizzare, sur PCIExpress, il existe une suite de configuration qui fait évoluer les identifiants des périphériques, c’est con parceque l’iommu repose sur les identifiants pour effecteur ses contrôles. Donc dans la roadmap de ProTIP, il y à la prise en compte de cette problématique.

From Academia to Real World: a Practical Guide to Hitag-2 RKE System Analysis — Chaouki Kasmi,José Lopes Esteves,Mathieu Renard,Ryad Benadjila

RKE, c’est le système d’ouverture de véhicule par transmission radio. C’est un protocole radio qui peut être attaqué de multiples façons, spoofing, brouillage, etc… RKE se veut moderne et implémente des mécanismes de sécurité comme un compteur anti-rejeux et un système d’identification crypto pour déverrouiller les portes et le moteur via l’ECU. Il existe plusieurs papiers académiques sur la sécurité de Hitag-2 RKE. Les orateurs se sont intéressés à la section cryptanalyse du papier, et à la mise en oeuvre pratique des attaques au niveau radio en s’appuyant sur GNUradio et GQRX.

Les orateurs détaillent leur approche de la rétro-conception du protocole radio à l’aide de ces outils.
En utilisant plusieurs clefs différentes, ils ont pu identifier les parties invariantes du protocole en enregistrant les communications issue d’actions similaires: bouton d’ouverture, etc…

Hitag-2 est un protocole de Phillips racheté par NXP et conçu fin 90. Le reverse-engineering matériel à été fait en 2007. Il s’agit d’un algorithme de chiffrement de flux (stream-cypher). L’algo à besoin de chauffer avant de produire du flux,  il faut en effet initialiser les états internes avec du random avant de l’utiliser pour communiquer. L’idée principale de la cryptanalyse consiste à réduire au maximum l’espace de recherche en se basant sur l’age du véhicule car une partie haute « privée » de la clef semblerait potentiellement incrémentale (bon c’est de la crypto, j’ai du mal :/ ). Les clefs vierges programmables contiennent une « clef par défaut » documentée avec un IV de 32 bits. En analysant les différences entre la clef programmable et des « vraies » clefs donnent des indications sur la difficultés de mise en oeuvre de l’attaque par corrélation décrite dans le papier.

Les orateurs présentent en uite des nouvelles attaques sur le protocole à coup de bruteforce léger illustrée en vidéo.  En bref: crypto pourrie maison = échec. Et quand on a des produits à durée de vie longue, c’est bien de pouvoir mettre à jour le couple Clef-ECU.

Conférence invitée: « De bas en haut : attaques sur la microarchitecture depuis un navigateur web » — Clémentine Maurice

Comment attaquer une micro-architecture depuis le navigateur web. C’est pas parce que l’architecture logicielle est sécurisée qu’on ne peut pas avoir de problèmes de sécurité à l’exécution. Les attaques matérielles type Side-Channel Attack nécessite un accès physique au matériel pour être réalisées. Autre fuite d’information; le partage de matériel entre deux systèmes type virtualisation. Les matériels partagés sont la mémoire, le cpu, les caches etc… Et l’oratrice va nous parler de SCA sur la DRAM.

Chaque chip de la mémoire est constitué d’un ensemble de « rows » de condensateurs qui sont accédés par row. En début de chip, il y a un « row buffer » qui permet d’accélérer les accès mémoire. Du coup quand on fait des timing attack sur les caches, en fonction d’ou on tape et comment, on a des temps d’accès différents. Tout ces timings se mesurent en nombre de cycles CPU. 

En accédant à des @ mémoire aléatoires, et en mesurant les timings, ont peut identifier le mapping des bank vis à vis des adresses mémoires. A partir de ce principe on peut reverser l’architecture de la DRAM. Drama: Dram addressing attacks: on ne cherche pas à savoir ce qu’il y a dans la mémoire, mais à connaitre les accès mémoires fait par les victimes pour en déduire le contenu. On peut utiliser ce principe pour faire des attaques par cannaux auxiliaires entre deux process logiciellement isolés genre deux VM. Autre attaque possible: un process qui espionne un autre à partir de ces informations.

Lorsque deux pages de deux process différents atterrissent dans un même « row », on peut jouer sur les timings pour savoir si la victime à accédé à ce « row », car si elle y a accédé, l’info est déjà dans le « row buffer » et du coup le temps d’accès est plus court. Avec ce principe, on peut keylogguer les frappes dans la barre d’addresse de firefox en espionnant les timing d’accès à la DRAM.  Bon en C c’est merdique, mais on peut le faire avec du JavaScript. Le JS c’est très sale, parceque le code est compilé en bytecode, et ensuite ça viens accéder à un buffer ou à été écrit le bytecode. Il faut donc identifier les instructions JS qui génère des accès & des écritures, ainsi que celles qui flush le cache JS ou qui permettent de mesurer des timings d’accès.

Les OS utilisent une optimisation pour les grosses pages mémoires qui facilitent la gestion de grosses pages mémoire, induisant des pagefaults détectables depuis le JS tout les 2Mo. On peut se baser là dessus pour déduire les 21 derniers bits de l’@ mémoire.

Pour mesurer le timing de la DRAM il faut flusher le cache pour ne jamais taper dedans. Pour flusher le cache, il faut faire des accès mémoire jusqu’à taper la zone mémoire en cache pour manipuler la politique de gestion du cache. Comment mesurer un timing à la nanoseconde près en JS ? La fonction qui donne la meilleur résolution c’est le performaneCounter. Le perfcounter à été arondis à 5µs pour éviter ce type d’attaques. Il existe beaucoup de différences entre les implémentations des navigateurs entre Ffx, chrome, IE et le Tor browser qui va jusqu’a 100ms d’arrondis. Première idée: faire une interpolation à partir de la fréquence d’incrément entre deux tics d’horloge. En jouant sur du padding, on peut détecter quand l’arrondis traverse le front d’horloge et on retrouve des mesures à la nanoseconde près.

Autre pb, faire un compteur qui ne bloque pas le thread. SetTimeout & cie, c’est pas assez précis. Avec les webworkers on à une résolution à la microseconde. Autre piste: les sharedArrayBuffer qui ne présentent pas d’overhead à l’accès, ce qui améliore la précision du compteur.

A l’aide de tout ces tricks, (compteur robuste + fonction de mesure) on peut mesurer des caches hit et des cache miss depuis JavaScript, ce qui permet d’implémenter des attaques SCA en JS.

Binacle: indexation « full-bin » de fichiers binaires — Guillaume Jeanne

Comment faire de l’indexation de façon efficace de fichiers binaires. L’indexation « full text » permet de faire correspondre les mots recherchés à leur emplacements ou ils sont présents. C’est présent dans tout plein de BDD serveur (et c’est coûteux).  L’idée c’est d’avoir la même chose pour rechercher des IP, des strings & cie présents dans des binaires. En gros comment obtenir tous les binaires/fichiers qui correspondent à une série de bits donnés. Le pb c’est que les indexes inversés reposent sur un découpage en « mots », mais dans un binaire, on a pas d’espaces. Du coup pour éviter ça on va utiliser des n-grams pour « découper » le binaire sans perdre trop de résolution. Le problème c’est que ya trop de N-gram, ce qui défonce les perfs de MySQL ou sa taille en fonction de la stratégie d’enregistrement. En utilisant une BDD « clef-valeur » on à le même problème, ça pète de partout: x10 sur la taille du stockage. Autre idée, utiliser des filtres de Bloom.  Le problème c’est que ça génère des collisions qui induisent des faux positifs qui appellent à vérification. C’est très utiliser pour l’accès en cache sur des très grosses BDD, des outils de DPI, des systèmes de cache. Du coup en jouant sur la taille du hash, et le nombre d’items on influe sur le nombre de collisions et donc on réduit le taux de faux-positifs. Pour la fonction de hashage, c’est murmurhash qui est utilisé pour sa performance.

L’outil est disponible ICI. Il est performant et permet très rapidement de matcher une chaîne hexa avec les binaires la contenant. Il peut machouiller un C:windows en 27min. On peut aussi claquer des scan Yara accéléré avec Binacle en récupérant les binaires concernés par les chaines fixes de la règle, puis en les passant à yarascan.  On économise ainsi pas mal de temps.

YaCo: Rétro-Ingénierie Collaborative — Benoît Amiaux,Frédéric Grelot,Jérémy Bouétard,Martin Tourneboeuf,Valerian Comiti

YaCo est un outil pour permettre à des instances IDA de propager l’information vers d’autres utilisateurs de façon instantanée. En gros deux utilisateurs travaillants sur une bdd locale IDA et utilisent un dépot git de synchro pour propager la documentation faite par chaque Reverser.

Le mécanisme des hooks d’IDA est buggué et incomplet, mais un contributeur anonyme à proposé un patch pour IDA pour pallier à ça. Les modifications sont sauvegardés dans un format XML, et les merges & rebase sont gérés au niveau du GIT. Quand il y a un pb de merge, une callback git est dispo pour gérer le problème programmatiquement.

l’outil est disponible ici.

Sibyl : function divination — Camille Mougey

Principe: identifier la fonction présente à une adresse donnée. Le problème des approches statiques, c’est qu’elle se basent sur une signature du cfg, et du coup ça peut facilement foirer. Du coup au lieu de se baser sur le cfg, l’analyse de la fonction va se baser sur les entrées et la sortie de la fonction pour l’identifier (comme le ferais un humain). Du coup pour identifier la fonction, on lui fournis dans une sandbox les paramètres typique d’une fonction donnée, et si ça fonctionne et que la sortie attendue est la bonne, c’est que c’est la bonne fonction. Sinon, ça crash ou ça rend des outputs divergents.

Bon le problème de cette approche, c’est qu’il peut y avoir beaucoup de crash, et des exécutions trèèèès longues. De plus un appel de fonction n’est pas suffisant pour l’identifier, il faut donc l’appeller plusieurs fois. (c’est du fingerprinting actif de fonction par comparaison des I/O).

Les tests Sibyl sont écrit en exprimant l’input à donner à la fonction, le passage des paramètres à la fonction (sauce MIASM), l’output attendu. Pour éviter les faux positifs il faut rajouter d’autres tests. Et du coup en 20 lignes de python/miams on peut identifier strlen() dans plein d’archis différentes.

L’idée de fond c’est de faire de l’apprentissage automatique à partir d’une librairie et de ses tests de non-régression. Ce qui permet à terme d’économiser énormément de temps de rétro.

l’outil est dispo ici

Breaking Samsung Galaxy Secure Boot through Download mode — Frédéric Basse

Oups, votre élection a été piratée… (Ou pas) — Martin Untersinger

Journaliste au Monde. Il y à eu beaucoup de piratages ces derniers temps, et ça a donné pas mal de travail à tout le monde. Du coup l’orateur vas nous apporter un éclairage journalistique sur ces sujets. Timeline rapide: en 2015 le piratage du DNC, annonce en 2016 du piratage, et début de la publication des documents.  La communication des états-unis en réaction au piratage est une grande première. En France ça a succité pas mal d’inquiétudes aussi, avec l’annulation du vote électronique pour les fançais à l’étranger, la mise en garde de l’ANSSI sur les piratages pour les législatives. Bref, pas mal de bruit. En Allemagne & Grande Bretagne aussi.

La publication de documents est une grande nouveauté, avec des tensions diplomatiques associés. Une nouvelle dimension prise par l’attribution qui deviens plus un choix politique qu’un fait basé sur des éléments techniques. Tout ceci crée des problèmes techniques pour les journalistes: comment vérifier la véracité de documents leaké qui ont été potentiellement altérés, modifiés ou pas et du coup déclarer « il y a des faux documents » ça ralentis les journalistes et ça requiert pas mal de prudence.

Suite à une perte de connectivité Internet en Allemagne, Merkel à déclaré que les Russes avait une forte capacité de frappe numérique, puis Deutch-Telecom à déclaré qu’il s’agissait en fait de Mirai. Le parti en-marche à fait une opération de com similaire ou ils se sont contenter de montrer aux journalistes un pov’ graph cloudflare avec un pic d’accès. Du coup le politique viens rajouter du bruit aux nouvelles techniques.

Bon les « conflits numériques » sont très difficiles à observer, et les journalistes ont du mal à accéder à de « bons » experts, du coup les journalistes peuvent se faire flouer par des éléments techniques plus ou moins valides. Le contexte géopolitque viens rajouter une couche de complexité à l’analyse journalistique.

Tout ceci est bien frustrant, car au final on à que peu d’éléments tangibles et indiscutables pour construire un fact-checking solide.

Challenge SSTIC

Un challenge construit autour d’un émulateur Open-RISC en JavaScript basé sur JOR1K, avec quelques features en plus comme le copier-coller ou un service SSH en websocket plus quelques bugfix. Des éléments de monitoring permettait de suivre la validation des épreuves au fil du temps, ce qui donne des jolis graph, et quelques FAIL de conception qui ont provoqué des ragequit.

Le fichier .ZIP soit-disant leaké par shadowbrokers est en fait une trace d’analyseur logique qu’on peut ouvrir avec sigrok (pas bien compris le nom :/ j’ai bon ?). Cette trace correspond à la programation d’une flash NAND.

Le serveur python ouvre un raw soket avec un filtre eBPF associé qui indique qu’il faut envoyer des paquets UDP sur le port 1337. eBPF peut remonter des informations via une page mémoire partagée. La crypto dans le serveur est basé sur une exponentiation modulaire à résoudre (ou à bruteforcer).

Riscy Zone émule une trusted-zone arm avec de la crypto par block. Ya plein de débug dans le JS et dans le binaire ce qui facilite l’analyse. ( pour plus de détails sur la solution c’est par ici)

(Out of Memory)

Rump Session

En plus du sulfator, un videur à été prévu pour dégager les speaker au bout de 3 minutes.
L’an prochain ça sera au couvent des jacobins, ça promet d’être un super site de 800 places.
39 soumissions, 24 retenues. Le message à retenir: SSTIC ne vit que grâce aux orateurs.

Tracking de bad-guy via Favico

Découverte sur pastebin: @xme crawl pastebin en continu à la recherche d’info, et conseils de s’intéresser aux infos de vos sociétés présente sur pastebin. Du coup en farfouillant, il a eu un hit sur un bout de code html ou l’on retrouve un lien vers le favico de son blog. Il semblerait que des script-kiddies ai repris une image de son blog qui en réduction ressemble au drapeau thaïlandais. En regardant le referer des accès à cette favico, @xme à pu sortir des stats sur les pages defacées par les skiddies thaï: durée de deface, fréquence etc…

sisyphe.io

Un moteur de recherche sur des données issue de portscan + banner, reverse dns, geoip, threatlists etc… une architecture distribuée de collecte, mais toutes les données sont stockées en local. Dans le portail on peut rentrer une IP, ou faire de la stat sur un port. En plus de shodan, l’OS Fingerprinting est plus poussé, avec des devs custom, pastebin est monitoré, et tout est corrélé.

Internet of Trash

Tous les équipements du quotidien qui finissent à la poubelle font le bonheur des dumpster divers. Des fois on trouve des routeurs avec une flash peu farouche avec un romFS  et des flèches en ascii art. Des pwd en clair, des comptes smtp gmail,..

Sécurité des télévisions connectés

Les smart-tv c’est la fusion d’un smartphone et d’une TV. Du coup leur déploiement peut s’avérer catastrophique pour la sécurité. Du coup la technique choisie c’est la TNT DVBT pour injecter des sous-titres & cie qui serons interpréta par votre TV sans votre permission. Il n’y a pas d’authentification ni de check d’intégrité dans les flux hbbTV. Du coup on peut afficher des trucs sur la tv, jouer sur le volume, prendre le contrôle de la sortie audio et vidéo avec 20 lignes de JavaScript.

Scapy Pipes

Créer des automates pour gérer des protocoles réseaux un peu compliqués. Scapy pipes, c’est des boites, avec des trucs en entrée, une sortie haute, une sortie basse et des triggers. Du coup la partie haute est décapsulée, et la partie basse est informative façon header-payload. A partir de ces boites, on peut construire des enchaînement de traitements avec des descriptions simples type A > B > C, et du coup créer grâce aux triggers des machines à états complexes. 

IDASuckLEss

Make IDA Great Again: Ida c’est plein de bugs et de features manquantes, quand au support qui fix pas les bugs, ou qui fait le sourd. Mais pendent ce temps ya toujours rien d’aussi bien. IDA reste le moins pire des outils. Soit on rage dans son coin, soit on fédère la rage dans un projet => IDASuckLess, un blog avec les bug IDA, les fix et les eventuelles réponses du support + les codes associés sur GitHub. http://rage.rump.beer/ 

BeeRumP

L’an dernier, l’orateur à pas eu sa place à SSTIC, du coup ce qui lui manquait c’était les rumps et la bière, alors il a monté une conf avec des rumps et de la bière. Et du coup il a proposé de refaire ça. 

Du PHP dans un png

Exemple d’un site vulnérable à une vulnérabilité d’Include PHP pas checké. Bon dans la vraie vie, on peut pas uploader de PHP ou de texte, mais on peut pousser des images. Cependant il y a pas mal de checks il faut donc placer le PHP dans un endroit « safe ». En plus l’image peut se faire re-sizer, du coup fin du commentaire ou du contenu de l’image. Du coup l’orateur à fait un outil qui gère le re-size et du coup c’est le re-size qui viens « générer » le PHP valide.

Applied machine learning

Est-il possible par machine learning de générer une soumission SSTIC acceptée. On construit un corpus à partir des actes latex qu’on convertis en ASCII, pour faire tourner ça on utilise le cloud google ou on peut dans les options avancés on peut avoir plein de giga de ram. Du coup on obtient des avis de sécurité maison, et des soumissions SSTIC qui parlent JavaCard. Mais comme ça ne génère pas de screenshots IDA ça peut pas être retenu.

Profiling linkedin à partir des pwd LinkedIn. 

Du coup pétage des pwd linkedin dispo publiquement. avec plus de 100M de hash, avec hashcat, des wordlists, des rules. Du coup coté pwd on à des classiques: 123456, soleil, password. Il s’agit d’un profil classique fan de Cyril Hanouna. Bon après on à des pwd un peu plus compliqué avec un ou deux caractères spéciaux. D’autres pensent être secure avec le mot password en leet. Ya des énervés avec des insultes comme pwd. Ces personnes souffrent de troubles comportementaux et ragent beaucoup. Ya des pervers aussi avec des « sucema…. ». Ya des tarés avec « …dechien » à tendance zoo. ya ceux qui sont confiants avec des « youwillneverfoundmypassword ». Les pwd safe tombent parcequ’ils ont fini dans une db en clair et sont repris dans les wordlists.

Pérénité des logiciels libres

Petit mot pour Arxsys qui n’a pas été suffisamment financé et du coup son soft open-source n’est plus maintenu. Il en va de même pour certains bouts du noyau linux ou certains softs. Du coup l’orateur à créé un site http://adopteunmake.com  pour adopter des projets open-source orphelins.

Présentation d’une feature de miasm

Façon talk sous hélium… avec le reverse d’un bios UEFI et l’import des structures via le plugin IDA Miasm qui va bien.

Free-OTP

Implémentation libre d’un 2FA. l’idée c’est de remplacer une solution très chère ou on a plus de licences. FreeRadius + OpenVPN + Google Authenticator, on mix le tout en ajoutant une interface qui va bien. Tout ceci est cablé avec l’AD, du coup l’utilisateur peut s’enrôler en local avec son smartphone. et comme certains voulaient pas utiliser leur smartphone, il a codé une version C#.

SELinux

L’orateur s’intéresse à la communauté SELinux ou des conf sont générées à partir de bouts de fichiers pour obtenir des politiques de sécurité adaptées à un soft donné. Du coup dans la branche master, l’orateur à trouvé des bugs dans les politiques SELinux. Clang qui sert à compiler les politiques SELinux peut identifier des bugs à la compile avec des warning qui sont pas tjs merdiques. Du coup SELinux c’est cool pour tester des outils d’analyse de code.

Fingerprint your HTTP/2 Stack

Fingerprinting d’une stack http2 du navigateur. Bon c’est clair les stack HTTP/2 sont pas toutes pareil et pas toutes conformes à la spec. Mais http2 c’est très compliqué, a cause de la compression etc, du multi-flux Bref c’est casse gueule. On peut extraire la machine à état d’un serveur (prez sstic de 2016). Le serveur http de fingerprinting force le navigateur à basculer sur le serveur http2 qui le fuzz et parcours la machine à état de la cible. En lisant la spec http2 et en greppant may ou should, l’orateur à créé des règles de test associés qui permettent de discriminer entre les implémentations.

Forensic traces

Les compromissions laissent plein de traces de partout, alors les pentesters peuvent tenter d’effacer leur traces, mais ya du logrotate, faut pas péter les file descriptor, faut pas les effacer, faut les éditer, et de les cat en live pour re-écrire les traces laissés. Du coup l’orateur à créé un soft nojail.py qui vient à la volée effacer/éditer les logs qui vont bien.

Metasm

Présentation d’un debugger basé sur Metasm => Cool !

USBWall

inputer & filtrer les devices usb associés aux sessions utilisateur. En gros l’orateur veut contrôler l’usage de clefs usb perso et smartphones sur son SI pour limiter la compromissions et garantir l’utilisation des clefs d’entreprise et non des clefs perso.

Hello World PDF

Bon, générer des pdfs c’est casse burne, du coup l’orateur à fait un code Python qui génère un « hello world » PDF valide. Tout est sur github.

Voitures contrôlables (ou pas)

Les systèmes d’ouverture de voiture peuvent parfois être des versions connectés chez divers constructeurs, ces voitures sont reliées à itnernet (r-link, on-star, etc…). Du coup il suffit d’attaquer les services qui communiquent avec ces voitures pour en prendre le contrôle. Exemple avec BMW Remote qui sert à ouvrir ou fermer la voiture au cas ou on ai oublié de la fermer, ou la rouvrir. Sauf qu’on peut jourr avec le chauffage, changer l’heure, verrouiller/déverrouiller, faire des appels de phares. Tout ça cause avec une API Rest avec une pseudo-authentification avec un token ré-utilisable. On peut donc causer librement avec la voiture. Potentiellement on peut peut-être faire des trucs plus dangereux.

MICSSTIC: abuser du micro HF du SSTIC. 

Les micros HF sont analogiques avec de la modulation de fréquence. Ce qui signifie que ces micro bavent sur l’extérieur et ça  peut être écouté de très loin. Autre phénomène intéressant, le « hot-mic » ou l’ingé son coupe la sortie amplifiée du micro, mais on peut capter quand même l’enregistrement.
Gnuradio propose une distri windows tout compilé sans efforts. Il faut identifier le signal et ya plus qu’a écouter.