SSTIC 2018 - J2

Docker est un outil de virtualisation légère pour packager des applications et automatiser le cycle de dev / déploiement. Chaque brique applicative est un conteneur. Chaque conteneur dispose de l’ensemble des fichiers dont il dépend. Docker fonctionne sous windows & linux. Pour les Dev, les images docker sont des boites noires dans lesquelles tourne l’application. Ils ne maitrisent donc pas en profondeur la sécurité de leur environement d’exécution logiciel. Côté sécurisation cette présentation va se concentrer sur la partie qui fait tourner les images dockers et comment durcir l’environnement hôte.

Les conteneurs Docker sous Windows se basent sur les objets kernel JOBS qui offrent un équivalent des CGROUP sous Linux. On peut regarder l’arborescence du conteneur à l’aide de winobj. Chaque conteneur est dans un silo, et dans ces silos, on découvre le mécanisme d’isolation pour que les liens symboliques soit exécutés dans un contexte à part. Côté filesystem, le driver NTFS à été patché pour gérer l’isolation. Bon sinon plus bourrin, il y a l’utilisation d’Hyper-V pour isoler le conteneur, et là on à toutes les features Hyper-V d’isolation sous la main.

Pour l’audit d’un environement Docker, on va venir contrôler les interfaces réseau, les permissions sur le groupe docker, authentification mutuelle par certificats, etc… Si on ne le fait pas, on s’expose à une escalade de privilèges via Docker. Pour éviter les dénis de service, il est de bon ton de limiter la consomation des ressources via ulimit. Les namespaces doivent être passés en revue, particulièrement ceux qui permettent de faire des IPC, de faire du ptrace, etc… Pour faciliter l’audit des namespaces, les orateurs se sont outillé pour générer un graph en fonction de quel namespace est accessible à quel process. Pour les capabilities, il va falloir les réduire au max. on peut s’aider de l’outil pscap ou du de capable. En suite on utilise les commandes docker pour réduire ces capabilities. Lorsque le conteneur à accès à des ressources concrètes sur l’Hôte, il faut s’assurer que ces ressources ne permettent pas d’effectuer une élévation de privilèges vers l’Hôte. Les Windows Containers ne sont pas des conteneurs de sécurité, et n’isolent pas le code exécuté de l’Hôte. Il faut donc privilégier les Hyper-V Containers, plutôt que les Windows Server Containers.

Sous linux, un filtre seccomp est compilé, et du coup si l’on veut pouvoir l’auditer il faut le décompiler. Les orateurs ont bossé sur un vérificateur formel en Prolog qui prend en entrée un filtre seccomp et évalue si on peut ou pas effectuer certaines actions avec ce filtre.
Pour des conteneurs plus isolants, il est possible d’utiliser des Orchestrateurs qui reposent sur de la virtualisation, des KAtacontainers qui offrent un équivalent des Hyper-V containers sous windows, gVisor qui est un noyau en mode userland fait par Google, etc…

La littérature du domaine se concentre souvent sur la sortie par un attaquant d’une VM. Mais peu de choses sont fait pour protéger la VM d’un Hôte / sysadmin malveillant. Pas seulement l’admin de l’hyperviseur, mais aussi les admins réseau qui pourrais sniffer ce qui se passe entre les hyperviseurs, ou entre l’orchestrateur et l’hyperviseur. Du coup, il faut utiliser un hyperviseur non bidouillé, une séquence de boot sécurisée, une mémoire protégée, etc… Pour ce faire, on peut utiliser les mécanismes offerts par secureboot, le TPM afin qu’a chaque étape du boot, une vérification d’intégrité soit faite.

VMware à ajouté dans vSphere la possibilité de mettre en oeuvre un secureboot pour les VM ainsi que leur chiffrement, et la possibilité d’avoir un TPM Virtuel et de chiffrer les informations de migration à chaud transmises entre deux hyperviseurs. Les admins VMWare disposent d’outils crypto pour effectuer le déchiffrement de ces donnés. Lors de l’échange de clefs entre hyperviseurs, si l’attestation entre eux échoue, les clefs privés de déchiffrement sont quand même transmises et du coup n’importe quel admin d’un hyperviseur peut déchiffrer n’importe quelle VM.

Windows Server 2016 introduit la Guarded Fabric qui permet de créer des vm protégés « Shielded-VM ». La fonctionnalité Virtualisation Based Sécurity permet de démarer un « secure kernel » qui permet d’exécuter des applications signés dites « trustlet » et fournis un TPM virtuel. La communication entre le VTL/1 sécurisé et le VTL/0 non-sécurisé se fait via des « mailboxes » dans lesquelles les trusltlet vont pouvoir pousser des données à destination des applis VTL/0. Autre fonctionnalité le HGS: Host Guard Service, dont le travail sera de vérifier la bonne santé de l’hyperviseur. Par contre il va falloir chiffrer les données de la ShieldedVM sur disque à l’aide de LUKS ou Bitlocker, car seul l’intégrité de la chaîne de boot est assurée.

Pour protéger la mémoire des VM, Intel et AMD préparent des fonctionnalités Hardware dans les CPU pour chiffrer la mémoire.

Les coeurs de réseau Télécom, c’est plein de cartes avec plein de cables dans tout les sens avec des trucs propriétaires pas très auditables de parout (YAY! 🙁 ) et tout ça avec touplein d’ASN.1. ASN.1 c’est très très utilisé, dans les Télécom, l’Aéronautique, l’Automobile, les Biotech, le Spatial… ASN.1 défini des structures avec une syntaxe abstraite avec des moyens de sérialisation adapté à ces structures. Il n’y a pas grand chose pour jouer avec l’ASN.1, une bibliothèque en C, et une autre en Erlang, et l’orateur ne voulait pas faire de l’Erlang. Il existe beaucoup de libs d’encodage/décodage DER aveugle, mais bon bof.

Du coup l’orateur à codé un compilateur ASN.1 et un moteur d’encodage ASN.1 Les spec ASN.1 sont de qualité diverses, voir douteuses. Le compilateur génère un module python qui fait appel aux modules d’encodage/décodage adapté. Les modules d’encodage sont parfois très nazes comme BER, PER, ou aligné sur l’octet comme APER. (bonjour la qualité du code qui se base sur des specs aussi moisies).

A l’aide de Pycrate, l’orateur à pu bosser sur des interfaces type SS7/TCAP/MAP et d’aller jouer avec les limites de la norme ASN.1 sur certains équipements. https://github.com/ANSSI-FR/pycrate/ et il y a même un Wiki alors lisez le avant d’utiliser l’outil !

Maintenir des IDS, c’est du boulot, même dans un système simple. Du coup l’orateur à développé un outil pour gérer les mises à jour de ses sondes, l’automatisation de tâches d’admin des sondes, et mieux monitorer l’état de santé de ses sondes. Bien entendu, être capable de gérer le tas de règles déployés et ce qu’elle couvrent, mais aussi de venir les tester à l’aide d’un pcap.  ProbeManager à besoin d’accéder aux sondes en SSH pour travailler, et en option un accès à Internet pour récupérer les règles de détection. Suricata & Bro sont supportés, et bientôt OSSEC. ProbeManager est développé en Django et utilise Ansible. Il permet de gérer des Blacklists, de la réputation IP sur les alertes. On peut gérer diverses sources de signatures type MISP, Suricata afin de propager ces signatures sur les sondes de façon régulière et automatique.

Par un des membres de LetsEncrypt. Un talk sur les origines de LetsEncrypt et de son déploiement dans des grosses infrastructures. Tout le talk se base sur le guide d’intégration présent sur le site de LetsEncrypt.

Pour la protection de la vie privée des utilisateurs d’internet, il faut se débarasser des sites en HTTP. Ainsi, Chrome envisage d’afficher comme « non sûr » tout site qui ne sera pas en Https. LetsEncrypt à pour but de faire en sorte que 100% des sites internet disposent d’un certificat SSL Valide. Pour un sysadmin, on sait très bien que ça peut être très long d’obtenir et de déployer un certificat SSL sur un site. Du coup les gens de LetsEncrypt ont bossé sur l’automatisation de cette séquence d’obtention d’un Certificat SSL en moins d’1h. Pourquoi LetsEncrypt est gratuit, parceque l’introduction d’un payement dans un process génère plein de sources d’interruptions: CB de la boite renouvellée trop fréquement, problème de transferts de fonds, de payement, de compta etc… Pour offrir du SSL à des pages perso qui ne sont pas usuellements sécurisés par manque de compétence et de temps. Du coup en abaissant la barre technique du déploiement, 90% des demandes LetsEncrypt concernent des sites qui n’ont jamais eu HTTPS déployé.

Pour faire tourner LetsEncrypt, il y a un staff de 12 personnes dont 3 dev et 6 sysadmins, ce qui est très petit pour ce qu’ils font. Tout ça sur très peut de matos, et le soutien d’Akamai pour distributer les informations OCSP sur ses CDN qui absorbent 99% du traffic. le 1% restant reste assez énorme à gérer. 

Les PKI ne fonctionnent pas toujours pour protéger les gens, nottament parceque certaines autorités de certification peuvent se faire compromettre, ou sont peu regardantes quand aux certificats qu’elles émettent. (la certificate transparency est là pour ça).  LetsEncrypt s’est monté en 8 mois, et à passé les audits haut la main. Pour réussir cette gajeure, ils ont priorisé, et la perfection est l’ennemi de la réalisation effective des tâches. C’était dur à réaliser mais fun.

Pour alléger la charge de LetsEncrypt lorsqu’on sécurise un conteneur Docker avec LetsEncrypt, il faut faire attention à de pas déclencher la limite du nombre de requêtes par jour. Pour éviter ça il vaut mieux stocker le certificat et le ré-utiliser. Les preuves d’appartenance dans DNS et http servent à LetsEncrypt pour vérifier si vous êtes le propriétaire du domaine et du site web. Certains hébergeurs proposent des options pour mettre en place cette preuve DNS. Si votre DNS est lent, il vaut mieux passer sur HTTP, en mettant en place une redirection vers un serveur central ou vous déposerez votre preuve LetsEncrypt.
OCSP sert à vérifier la validité des certificats et leur révocation, du coup pour alléger la charge de LetsEncrypt, il faut mettre en place de l’agrafage OCSP, qui fournira une copie locale dont la validité est limitée dans le temps et qui sert de cache local sur le site pour vérifier la validité des certificats LetsEncrypt (ou autre) du parc.

Les certificats LetsEncrypt durent 90j, alors il vaut mieux les renouveler tout les 60j histoire d’avoir de la marge.

YaDiff
Outil de propagation de symboles. A chaque fois qu’un nouveau binaire arrive,  il faut se retaper la rétro de 0. Du coup pour pouvoir capitaliser le travail fait, les orateurs ont créé YaDiff pour propager les informations d’une base IDA vers l’autre, et capable de supporter des gros binaires, voir des firmware entiers. Pour ce faire, les orateurs ont développés deux algos, un assez classique et l’autre basé sur du machine learning.

Pour le premier algo, l’outil gère des fonctions, de basic block et des cross-refs. Pour identifier l’équivalence d’un objet avec un autre, les orateurs utilisent une signature basée sur les octets invariants. Pour propager les informations associés à ces objets, l’algo identifie quels sont les objets qui ont la même signature d’un binaire à l’autre. Cette association est sûre à 100% mais ne couvre pas tous les objets des deux binaires. En regardant les appelants des objets, il est probable qu’ils soit similaire même s’ils n’ont pas la même signature. On fait de même avec les appelés, jusqu’a ce qu’on ne trouve plus d’associations de similarité. Une fois ces associations établies, on propage les commentaires d’une base IDA à l’autre.

Pour le second algorithme, on identifie des propriétés correspondantes à chaque objet, ces propriétés caractéristiques constituerons un vecteur de features qui sera donné à mangé au machine learning. Les caractéristiques de la fonction sont par exemple la « forme » du graph de flot de contrôle, les statistiques sur les instructions qui la constitue, etc… Pour ajouter du contexte des appelés et appelants de la fonction, on ajoute au vecteur de fonctionnalité des statistiques sur les appelant et les appelés. Du coup ça génère un Gros vecteur de features, qui ne sont pas forcément évidents à comparer. Soit on compare chaque dimension et on définit une distance pour chaque composante du vecteur. Soit on se repose sur un réseau de neurone avec apprentissage supervisé en prenant en entrée un gros ensemble de fonctions dont on sait qu’elles sont similaires.

Pour le corpus d’apprentissage, les orateurs ont utilisé les dépôts Debian Jessie et Wheezie car ils représentent un grand nombre de binaires et de fonctions similaires et compilés dans diverses architectures & versions. Avant de faire bosser le réseau de neurones, il faut normaliser le vecteur pour que chaque donnée soit comprise entre 0 et 1.  Le réseau de neurones prend un vecteur de 950 features qui génère un vecteur de sortie sur 8 dimensions bien plus utilisable.

Pour l’apprentissage, les fonctions sont regroupés par leur nom, et pour chaque groupe de fonction, l’algo d’aprentissage prend deux fonctions « similaires » et une qui ne l’est pas, et on donne tout ça à manger au réseau.

Sandbagility est une sandbox basée sur Winbagility, outil déjà présenté au SSTIC (démo live
). Les malwares s’analysent de plusieurs façon, statiquement à coup d’IDA, d’en-têtes, de VT, de réputation, etc… pour l’analyse dynamique vous avez plein d’outils type sysinternals, des honeypots, des débogueurs. Quand il s’agit de passer à des gros volumes de bestioles, on apprécie l’automatisation de l’analyse. Cuckoo & autres sandboxes sont bien pratiques pour ça. Le problème c’est que la sandbox peut être détectée & évadée par le malware.

Une sandbox, c’est un outil qui isole le malware du système hôte pour éviter qu’il ne s’échappe. Au début c’était des librairies userland, puis des modules dans le kernel, et pour finir l’utilisation de la virtualisation. Le problème de la sandbox par hyperviseur, c’est qu’on est très loin de l’utilisateur, et on à du mal à retrouver les infos sur l’OS sous-jacent. LibVMI et volatility par exemple permettent d’obtenir des informations sur l’OS. La furtivité pose parfois problème comme avec cuckoo dont l’agent peut être détecté.

Pour ne pas avoir à refaire son hyperviseur, les orateurs ont utilisé Winbagility qui se base sur un protocole de debugging qui permet de manipuler la vm et d’aller chercher des informations dans sa mémoire.  Pour l’introspection de l’hôte, Sandbagility utilise les symboles de debug de Windows afin de donner un peu de sens aux objets retrouvés en mémoire. La solution est architecturée pour pouvoir supporter d’autes OS que Windows (mais c’est pas encore le cas), ou d’autres librairies d’instrumentation de VM comme LibVMI.

L’hyperviseur n’a aucune idée de ce qui se passe dans le Guest. Pour donner du sens à ce qui se passe, il faut Localiser le noyau Windows, puis identifier la RSDS_DEBUG_FORMAT pour identifier le bon .pdb contenant les symboles de debug du kernel. Une fois les symboles sous la main, on peut identifier quelle fonction est à quelle addresse. Pour savoir quel processus fait quelle action, soit on énumère tous les processus par les structures qui vont bien dans le kernel. Souvent les actions sous Windows se font à l’aide d’un HANDLE. Pour savoir quel fichiers sont actionnés par quel processus, les orateurs ont parcourus la table des handles du kernel. 

(la digestion va être difficile…)  Comment réaliser une JVM JavaCard durcie à l’aide des fonctionnalités des CPU. Pour obtenir une racine de confiance, il faut un composant sûr et robuste dans lequel on peut stocker un secret cryptographique qui permettra de signer/vérifier cryptographiquement l’intégrité de certaine parties ou tout le système de confiance.

La technologie JavaCard est basée sur la JVM qui tourne au sein d’une carte à puce. Il n’existe pas d’implémentation open-source, mais la majorité des plateformes JavaCard sont évaluées.

La machine virtuelle est souvent indépendante du composant sécurisé sur laquelle elle fonctionne, et le confinement est fait au niveau applicatif, ce qui à un coût en performance. Du coup les orateurs ont décidé de travailler sur cette JVM pour utiliser les mécanismes matériel de la carte à puce. L’Unité de Protection Mémoire se configure en mode privilégié, et permet de fixer des contraintes en lecture/écriture/exécution. Mais ces configurations sont limités à 8 régions mémoire, soit en gros 8 pages de MMU sur un CPU classique. On peut inclure une région dans une autre pour affiner l’isolation.

Les orateurs ont donc modifié une JVM pour l’adapter à l’utilisation de l’UMP, mais c’était pas simple… (plus d’info dans les actes)

Le scénario du challenge SSTIC se voulait réaliste, avec l’analyse d’un exploit Firefox, de la rétro WASM,  un malware à analyse et un C&C à exploiter pour terminer. Il y a eu quelque fails, par exemple le serveur durci avait un .authorized_keys accessible en écriture, alors certains on réussi à avoir un shell dessus. Certains participants ont exécuté l’agent malveillant, et du coup les organisateurs du challenge ont eu un shell avec certains participants.

Le challenge commence par une trace réseau avec plein de traffic web. Dans ce traffic web, on à des fichiers JavaScript et WASM (web assembly). Ce code JS charge des données depuis un site web avec un certificat d’origine russe. Le JS en question drop un binaire .f4ncyn0un0urs qui utilise un algo cryptographique avec un nom russe, et l’algo en question est vulnérable à une attaque crypto. L’implem AES est vulnérable, et la génération des nombres premiers aussi, du coup on peut récupérer la clef dans le PCAP initial. Le code malveillant sert de client ET de serveur, on peut donc procéder à l’analyse de la partie serveur à la recherche d’une vulnérabilité. Il y en a 3 dans le binaire, une à la réception du résultat d’une commande, une au ping avec un memcpy qui leak l’addresse de la pile, et un bug dans le routage des messages qui permet d’écrire 8 octets dans le programme.  L’allocateur mémoire étant basé sur une libc récente, on peut pas utiliser les vieux tricks d’exploitation. Il faut donc comprendre comment fonctionne l’allocation/ré-allocation pour réussir une écriture arbitraire, puis un ROP avec un ls et un cat re-implémenté à cause du durcissement du serveur. Le durcissement empêchait les execve, mais autorisait open et write, du coup l’orateur à pu obtenir un shell sur le serveur. 

Bon cette année, ya beaucoup, beaucoup de monde sur la scène pour les rumps session. (j’vais en chier….) Comme chaque année, les rumps se font en temps limité, 4 min / rump (c’est généreux), et le contrôle du temps se fait par un jury.

Un remake du burger quizz façon SSTIC. 39 soumissions dont 24 acceptés, le CO tient à remercier les soumissionnaires sans qui il n’y aurait pas de SSTIC. Une grosse partie du budget (70%) part effectivement dans le traiteur, le reste dans la location de la salle. Il a fallu 19 échanges pour décider de la fréquence de nettoyage des toilettes. Le SSTIC ne fait l’objet d’aucun sponsoring, et tient à le signaler. Le CO remercie SynActiv pour sa gestion d’incident en ayant fournis le smecta et l’immodium aux copains. 500 places sur les 800 sont partie en 8-9 min, le reste à été vendu en 3 mois. le CO remercie aussi le pharmacien qui reconnait les participants du SSTIC, et surtout aux auteurs sans qui il n’y aurait pas de conf.

Il y a deux ans, il y a eu une Rump sur le vidéoproj expliquant pourquoi c’est flou, avec la fameuse chaine d’adaptateurs VGA. Entre temps le CO à fait des recommandations aux auteurs sur la résolution des slides et leur taille. Mais les terminaux c’est pas terrible. Les orgas ont demandé les slides 5j avant, pour voir si les inserts du stream allait bien passer, et pour avoir un backup. Merci à tout ceux qui sont en régie pour assister les orgas avec le son, la lumière etc…

Quand un copain balance une image docker publique sur internet et la laisse traîner, il se fait poncer et il se met à miner des cryptomonnaies, ce qui coûte cher sur le Cloud. Vous vous retrouvez avec une image toute vide…  mais comme c’est un conteneur docker, bah ya plein de couches de FS en morceaux et dans le répertoire overlay bah c’est l’enfer pour le forensic. Du coup docker explorer vient vous aider à récupérer les infos et le filesystem du conteneur tel qu’il tournait. dans /tmp/ vous trouvez des trucs dégeux, un strings dessus et vous retrouvez le mineur de bitcoin fautif.

Suite d’outils pour identification et reverse des firmwares nordic semiconducteurs NRF5. Bon le reverse de ces firmwares c’est un peu spécial, heureusement ils fournissent un « soft device » qui expose des syscall et implémente une stack BLE proprio, ce qui permet d’obtenir les signatures des fonctions et d’en retrouver les symboles. Un premier script mange les firmwares pour construire une base de connaissance avec les symboles des fonctions qui vont bien pour les importer dans IDA. L’outil est sur le github de digital-security.

RTFM
RTFM est une association qui réuni du monde sur discord, dont l’objectif est de créer un event « select » à l’école 42 avec CTF & Conf, et des rencontres sur paris.

La mise à jour d’IOT basse puissance, c’est pas toujours tip-top mais c’est très utilisé dans l’industrie. (et on à pas la suite, l’intervenant c’est fait applaudir).

Mirai est un malware qui est à l’origine d’un des plus gros DDoS connu, qui reste très actif aujourdui, avec au moins 7 variantes online. Il a une empreinte très caractéristique, dont le n° de séquence TCP dépend de l’@ IP, il suffit de mettre en place un sniffer qui va bien, on peut les scanner et les identifier. depuis juin il y a 11k signatures détectés. Les pays les plus infectés sont le Mexique, la Chine et la Russie. Sur onyphe quand on regarde le scan d’une machine mirai, grâce à la corrélation pastebin, on retrouve cette adresse dans un listing ip/password depuis supprimé de pastebin.

Lors d’un pentest, ils ont trouvé une lfi sur une appli vulnérable, avec cette lfi ils ont récupéré quelques fichiers dont des condensats et des identifiants. En récupérant un backup de la BDD à partir d’un fichier de log. Plus simple en regardant les logs ils ont pu retrouver des GPO avec des group policy préférence, une vieille feature permettant de créer des comptes locaux, et ces fichiers peuvent être déchiffrés avec une clef de chez microsoft. Autre moyen, ils sont tombé sur un Tomcat open-bar qui gérait les flottes mobiles. Dans le fichier de conf récupéré via LFI il y avait des identifiants, dont le login/pass de l’administrateur de domaine encodé en b64. Pour prendre le contrôle de l’AD, bah RDP, ou via Outlook365 ou on peut déployer un binaire dans l’Outlook d’un utilisateur depuis l’appli web.

Comment se protéger des SQLi sur un vieux site tout pourri. Mais little bobby il peut pas se connecter si on fout un WAF. Autre technique, on déclare une nouvelle fonction qui vérifie si la requête est injectable ou pas et si elle l’est, refuser de l’exécuter. On peut en php remplacer une fonction standard par une fonction custom afin de sécuriser le mécanisme. Pour tester si il y a injection on peut utiliser un parser SQL pour observer si la requête générée split en plusieurs token ou pas.

WinDev est un AGL propriétaire français, pas forcément très sécurisé mais très très peu répandu. Et beaucoup d’applis sont faites en France avec cette solution, et c’est pas connu hors de France. /WDAdminWebXX0/ contient la console d’admin ou on peut déposer un webshell en WinDev ou il faut coder en français. Pour déposer le code sur le serveur il faut d’abord compiler en dynamicwebdev puis en AWP (le bordel….). Après avoir posé le webshell WinDev, bah c’est gagné (ça mériterait une prez complète).

1/ Louper la deadline, 2/ Teaser au lieu de proposer, 3/ Tout filer et faire confiance au CP, 4/ être une quiche en Latex, 5/ Louper le mail d’acceptation puis l’e-mail de rejet pour n’avoir pas répondu assez vite. 6/ Ne pas répondre à un CFP: 100% des personnes n’ayant pas soumis ont raté leur soumission. Bref tout ce que vous faites vaut le coup d’être partagé.

Avec Suricata on peut par exemple faire de la détection de login/pass en clair en éditant le Yaml de config de suricata. En rajoutant une regexp qui va bien, on peut aller extraire ces informations et les stocker dans un champ custom. Avec un poil de jq on peut ressortir les infos du JSON dont les fameux login/pass issue des logs.

BlueTeam – un métier Régulé, et du coup le régulateur à décidé de faire passer des red-team sur le SI. Exemples de fails: le malware en GO qu’on reverse a coup de Strings. Utiliser VT pour distribuer les souches de malware de la RedTeam. Tester son RAT sur un CNC perso, et du coup avec des retro-hunt en récupérant les souches, et hop une requête de takedown. Autre mauvaise idée, le typosquatting de la cible. Et comme la blueteam monitore les domaines similaires déposés, on peut spotter la redteam 1 mois avant. Et en pivotant avec du passive DNS, on peut retrouver les clients de la RedTeam.

Ya pas masse de solutions pour faire des backup de téléphone, soit c’est le cloud google, soit c’est des bouzes OEM. Coté Apple ya itunes mais bon bof. Sinon ya libimobiledevice qui fonctionne sous linux et permet de faire du backup/restore d’iPhone & ipad. Du coup avec un raspi0 on peut faire le backup automatique lorsqu’on branche le téléphone, et ça le recharge en même temps.  github -> ipibackup

tree/sysdevices | graphviz …. euh ? Bon les outils d’énum yen a plein, lspci, lsusb, etc, mais c’est un peu galère de trier tout ça. Hélas il existe des dock avec de l’USB-3 ou de l’USB-C et là, comment on fait pour trouver l’interface ethernet du dock dans lsusb ?  On voit que des bus pci et rien en USB. quand on fait lspci -t on voit débouler une tonne de bus pc et plein de bordel. Comment faire pour avoir quelque chose de plus clair ? Dans SysFS on à toutes les infos, du coup l’orateur à créé un script qui permet de générer un graph a partir des sorties lsusb, lspci et /sys. github/fishilico/home-files/….

La télévision numérique fait l’objet de plusieurs familles de standards, le DVB est très rependu en Europe, Asie, Afrique, alors qu’aux US c’est de l’ATSC, et la Chine et Cuba utilisent DTMB. Bref yen a de partout des standards, et ya pas que DVB dans la vie. Ces standards ont des fonctionnalités communes dont la mise à jour logicielle. Les standards prévoient bientôt des publicités ciblées, mais ce bordel ne fait pas l’objet d’audits de sécurité digne de ce nom, et cet écosystème est très peu ouverte d’un point de vue sécurité/vie-privée. Les normes sont dispo en ligne et sont ouvertes, c’est donc à vous de jouer pour les passer au crible.

Un outil de reverse pour exécuter un programme ARM (dispo sur github). pip install armnow et zou. pour la synchro, il y a une commande pour échanger des fichiers entre vm et host, et une autre pour ouvrir des ports qui vont bien vers le guest (bel outil qui mériterait plus de 4 min).

Un outil de gestion de pki de clefs SSH, c’est possible, mais avec ssh-keygen c’est pas facile. Du coup on génère une clefs qui sera la CA, et après on signe les clefs des users sans avoir a maj les authorized_keys. Les clefs dépendent d’un profil qui peut limiter leur usage dans le temps. On peut aussi gérer la révocation de clefs. github/reblaze/sshpki

Le fonctionnement entre un elf et une bibliothèque, bah c’est fait avec un strcmp. La norme dit qu’on peut nommer les fonction avec des trucs « safe » mais en fait, ça mange tout le range des caractères pour générer une fonction avec des escapes codes et obfusquer les fonctions de la lib, du coup on peut renommer les terminaux pour rigoler, mettre les fonctions en noir sur noir. Dans IDA ça fait bien de la merde aussi quand il mange ces fonctions zarbi.

Démo de la clefs Wookey en live.

Coffee plz
Habitué aux cafés gratuits avec des badges utilisant mifare classic. Ils ont utilisé mfoc pour dumper la clef, lire le contenu, etc… Bon ya quand même 3 zones sur 4 qui sont chiffrées. En allant sur le site du constructeur on récupère via un directory listing les outils de dev, et les listings clients avec leur n° de badges. Bon le firmware de la clef tourne sur un cortex m0, et l’algo crypto c’est xtea en 16 tournes. Seul l’UID est variable, le reste est fixe, ce qui permet par bruteforce de récupérer l’intégralité des données du badge. Le badge à en fait un backup, sur une des zones et la maj sur l’autre. Du coup ils peuvent flasher le montant qu’ils veulent.  (j’suis HS ya trop de rumps)

La suite de modmobmap pour faire du jamming (outil présenté a beerrump). Tool fait maison. Avant pour faire du jamming fallait des outils chinois spécifiques, mais le signal est pas glop, et on peut pas mettre une rogue base station, faut modifier le hardware, c’est chiant. Du coup a coup de SDR/Radiologicielle, on peut utiliser des trucs à pas cher comme des adalm-pluto ou des hackRF. Mais le problème c’est tjs la bande passante utilisable. Du coup il vaut mieux faire du « smart » jamming, en ciblant les channel a brouiller. Ca devrait être faisable avec l’osmofl2k, mais c’est pas gagné.

(plus de stream, plus de liveblogging)

…