1. WebAssembly Reverse Engineering and Analysis


    WebAssembly est un standard d'assembleur pour une machine virtuelle stack-based conçue pour être facilement transformé en langage natif (assembleur). C'est l'équivalent du binaire pour le web. La compilation vers WASM peut se faire avec LLVM 6.0. L'implémentation de référence est disponible sur github. WASM est disponible sur tous les navigateurs majeurs du marché.

    Le minneur de bitcoin Coinhive dispose d'un shell en JS, mais le code du coeur est écrit en WASM. De plus les interpréteurs WASM souffre de nombreuses vulnérabilités. d'après les orateurs, WASM pourrais servir dans du bypass de WAF, ou pour du malvertising. WASM à des capacités d'obfuscation de code non-négligeable, et est assez désagréable à reverser. Pour désassembler WASM dans IDA, on peut utiliser le plugin IdaWasm.  WASM est parfois stocké dans un format intermédiaire le .WAT, un équivalent du PYC pour python.

    Red Teamer 2.0: Automating the C&C Setup process


    Comme l'a dit Eric en introduction, les red-teamer ressemble beaucoup à des attaquants type APT (avec moins de budget ?). Lors des prestations de red-team, l'opsec pour assurer la réussite de la misson est importante. Le problème c'est qu'il y a de nombreux outils de pentest à déployer et qu'ils ne sont pas tous simples à configurer sans faires d'erreurs.

    Pour l'architecture, l'orateur utilise AWS et utilise du domain fronting pour échapper aux protections côté client de type DLP. Utiliser des serveurs de mail sur une plateforme de cloud réputé facilite le passage au travers des filtres de réputation pour les campagnes de phishing.

    Le RAT est compilé dans une VM à la volée, et intègre le domaine de C&C qui pointera vers le reverse-proxy qui protège l'infrastructure de la red-team. Le déploiement des bucket S3 pour récupérer les résultats du phishing via Gophish simplifie la création d'une campagne de phishing.

    Côté OPSEC, il faut que le domaine de phishing ne pointe pas sur une IP qui appartiens à la red-team, au risque de la leaker dans la configuration TLS. L'entreprise doit être prête à répondre aux questions d'AWS lorsque la blue-team va déclancher des demandes de fermeture de service sur l'infra de phishing.

    Mirai: beyond the aftermath

    Mirai a généré de gros DDoS en s'appuyant sur des IoT vulnérables. Cela a permis de mettre la lumière sur un dette de sécurité conséquente. Après le leak du code source, on à observé des botnet qui protégeaient les IoT des intrusions, et des variantes du botnets. Le nombre de Botnets IoT est en constante augmentation en terme de nombre d'échantillons uniques. en 2016 Mirai représentais 3% des samples.

    L'orateur détaille en suite l'architecture et le fonctionnement de Mirai, et comment le botnet était rentabilisé en le louant par morceaux aux clients. A la release du code source de Mirai, les listes de login/pass ont été réutilisés dans  Aidra.  Hajime est un botnet qui viens sécuriser les IoT et qui laisse un message bienveillant sur les devices. Pour mesurer la ré-utilisation de code entre Mirai et les nouveaux samples, on peut utiliser BinDiff (ou minhash comme on l'a vu dans la prez malpedia). IoTReaper par exemple est composer d'une majorité du code de mirai, avec en plus de l'exploitation de vulnérabilités pour la propagation.

    Persirai/Http81 réutilise le mécanisme de scan de port de Mirai. Bashlite/gafgyt/qbot  recycle certaines fonctions de scan. HideNSeek recycle le mécanisme de configuration et les fonctions de gestion des connexions telnet. ADB.miner réutilise le portscan de Mirai pour trouver des ports de debug ADB ouverts, puis déploie un mineur monero.

    Les variantes mirai sont souvent packé par UPX avec un changement du magic pour empêcher l'unpacking automatique, il faut donc modifier ce magic sur le header du programme avant de le passer à l'unpacking.  OMG est une variante qui a transformé Mirai en service de proxy pour l’anonymisation des cybercriminels.

    HTTP Malware distinguishing features


    L'orateur explique les nombreuses différences entre une requête HTTP générée par un navigateur web, et celles généré par des bots qui viennent joindre leur serveur de C&C.  Il existe des papiers dans la littérature mais leurs travaux repose sur des jeux de donnés très petits. Du coup les orateurs ont mis en place un système de collecte et d'analyse des headers HTTP pour distinguer les navigateurs des bots.

    Pour générer le Dataset, ils ont crawler le top 500 Alexa avec des navigateurs pilotés par Selenium, et exécuté des malwares dans des sandbox et monitoré les requêtes HTTP à l'aide de StratosphereIPS. L'idée c'était de rechercher des erreurs faites par les cybercriminels dans la génération de leurs requêtes.

    Les éléments différentiants sont souvent des retours chariots absent, des virgules qui apparaissent à des endroits innapropriés, l'emploi de tabulation au lieu d'espaces, ou des espaces en trop. Ces petits détails ne sautent pas forcément aux yeux mais permettent de distinguer les bots des browsers. La version du protocole HTTP chez des malwares est souvent à 1.0, alors que les navigateurs déclarent du 1.1 sauf pour IE. Un grand nombre de malwares ont des caractères non-ascii dans le corps de la requête POST, et souvent le referer est manquant. La mesure d'entropie est aussi un bon indicateur d'obfuscation ou de chiffrement. Les bots ont tendance à requêter plus fréquement des IP+port là ou les navigateurs requêtent à 99,8% des noms de domaines (dans le dataset collecté ! ). Les bots ont aussi beaucoup moins de lignes dans les Headers, ils dépassent rarement les 6 headers, et la majorité tourne autour de 3 header.

    Parfois IE envoie un user-agent Firefox quant il rentre dans un mode de compatibilité particulier déclanché par le contenu de la page. Beaucoup de bots oublient le User-Agent dans les Headers. Bon parfois les navigateurs ne mettent pas de User-Agent dans des requêtes initiant des websocket.  Souvent le User-Agent des bots reprend le nom de la librairie, voir des informations sur le système infecté.

    Tracking actors with their WebInjects

    Les WebInjects sont des scrips injectés dans les navigateur de victimes infectés par des malwares bancaires et qui viennent modifier le comportement de l'application web pour cacher aux utilisateurs certaines informations de transferts ou bien récupérer des informations d'authentification. Les donnés volés par les WebInjects sont souvent gérés dans un panel à part.

    Certains cybercriminels se sont spécialisé dans les WebInjects et vendent des systèmes complets de gestion associé. Ils peuvent se vendre jusqu'a 800$. Yummba est un revendeur de WebInjects aisément identifiable avec un grand nombre de banques ciblés.  Tables est un WebInject au format Zeus et utilisé par pas mal de malwares bancaires dérivés de ce dernier.  inj_inj est en circulation depuis 2015 et se retrouve dans Gootkit, ISFB, ZeusPanda, Dridex, etc.. on retrouve souvent inj_inj comme variable dans l'injection.  LOB_ATS à été nommé d'après l'url du panel "/lob.php".

    Pour analyser de façon automatique les acteurs derrière les WebInjects, l'orateur à automatisé l'extraction des configurations & urls de C&C des WebInjects, puis est allé extraire les webinjects sur les C&C en émulant les clients, puis les a aggrégé par similarité & graphé dans graphDB.

    Triada: the past, the present and the (hopefully not existing) future

    Triada était un vieux trojan qui rootais les téléphones android, puis c'est devenu une backdoor au niveau système. Découvert en 2016 par Kaspersky, il utilisait de vieux exploits pour devenir root sur le système, et il droppais un binaire su protégé par mot de passe.

    Pour faire de la place, le malware gère un système de pondération pour virer les appli qui ne servent à rien et qui sont isolés, tout en laissant les applis systèmes ou importantes pour l'utilisateur. Le malware dans sa première version faisait de l'injection dans les navigateurs mobiles en utilisant ptrace et en chargeant un .so pour hooker certaines fonctions du navigateur.

    Bon comme Android est de plus en plus sécurisé, les cybercriminels derrière Triada n'ont plus eu de moyens de rooter le téléphone, et on donc changé de stratégie pour devenir une backdoor au niveau système en modifiant la fonction de log pour s'exécuter dans le contexte de l'application à chaque fois qu'elle y faisait appel.

    Une fois le reverse de Triada fait, les équipes de Google Play Protect sont passé à la protection des utilisateurs. Pour chaque constructeur, ils ont demandé une mise à jour système pour dégager la backdoor Triada.

    The snake keep reinventing itself.


    Turla est un groupe d'attaquant qui vise les diplomates et les militaires. Lors de l'opération Mosquito Turla, ils utilisait des faux installeurs téléchargés depuis admdownload.adobe.com, et ce malgrès que adobe n'ai pas été compromis. Lorsque la victime télécharge l'installeur, elle contiens un trojan, et des donnés de fingerprinting de l'utilisateur sont envoyés sur adobe.com. Il est probable qu'il s'agisse soit d'un Mitm ou alors d'un hijack BGP. A l'installation, la backdoor exfiltre les identifiants wifi.  Il est peu probable qu'il s'agisse d'un Mitm sur le réseau local. Il s'agirais plutôt d'un Mitm au niveau du fournisseur d'accès Internet.

    Turla utilise souvent du "string stacking" et XOR ses log. Ils utilisent aussi des outils open-source comme le dumper de mots de passe Quarks, Lazagne, Nirsoft et Mimikatz. Lorsqu'ils ont fini d'exploiter la machine infectée, ils font le ménage avec la backdoor Gazer. Ils préfèrent nettoyer tout plutôt que de risquer de voir leur dernière backdoor récupérée par une analyse forensic.

    En 2013, Turla à commencé à utiliser des commandes transmisses au format XML par e-mail. en 2016, les commandes sont chiffrés dans des pdf envoyé en pièce jointe aux victimes. L'installation se fait par le détournement d'objet COM. C'est assez vieux et bien documenté. Ils détournent aussi le protocole de gestion d'Outlook. Il n'est pas nécessaire d'être admin pour détourner un objet COM, et donc ils ont besoin de peu de privilèges pour s'installer. MAPI est un objet COM qui permet aux logiciels d'interragir avec les e-mails. La backdoor remplace olmapi32.dll qui sert à gérer ces fonctions. La backdoor rajoute des callback sur la boite de réception et la boite d'envoie pour intercepter l'ensemble des e-mails et les forwarder à l'attaquant. Les e-mails contenant les résultats des commandes sont envoyés en même temps que l'utilisateur envoie des e-mails. Les e-mails sont envoyés dans des boites e-mails gratuites. Toutes les métadonnés des e-mails en réception sont loggué par l'attaquant, et si l'e-mail contiens un PDF, la backdoor le récupère pour y rechercher une commande à exécuter.  Tous les messages liés à l'activité de la backdoor sont supprimés. La backdoor hook la fonction qui fait popper une fenêtre de notification pour les nouveaux e-mails et bloquer son affichage s'il s'agit d'un e-mail de l'attaquant. La backdoor est indifférente quand à l'origine de l'e-mail. Pour stopper l'infection il faut supprimer le malware, un takedown de l'e-mail de l'attaquant ne sert à rien. Turla est connu pour utiliser des algo exotiques. Toutes les valeurs significatives des algo ont été changés, et ils customisent les algo de chiffrement. Le problème c'est qu'en customisant MISTY1, ils ont introduit un bug qui fait qu'en mettant une valeur nulle pour l'IV, la clef dérivée est nulle. On peut donc crafter un pdf pour contrôler n'importe quelle backdoor.

    On peut bloquer le chargement de la backdoor à l'aide des mécanismes de sécurité de microsoft en venant bloquer le chargement d'une dll non signée par microsoft dans outlook.

    Actuellement, la backdoor 32bit n'est plus droppé, elle a été remplacé par le script de vol d'identifiants wifi, ou l'installation d'une backdoor jscript. Carbon est une backdoor de 2ème niveau avec des capacités avancés qui utilise des WordPress compromis comme C&C. Mosquito migre d'outils maison vers des outils sur étagère comme metasploit shellcode + meterpreter.

    How many mirai variants are there

    il y a plus de 116 branches de Mirail avec 21k samples dans la nature. Certaines branches de Mirai ont des noms qui proviennent du message d'install réussi renvoyé lors de son exécution. Certaines branches ont été nommés en utilisant le nom de familles de malwares célèbres. Pour classifier les variantes, les orateurs ont extrait les configurations et les  méthodes d'attaques des samples pour les corréler. L'analyse statique c'est faite avec IDA, et l'analyse dynamique avec Unicorn.








    0

    Ajouter un commentaire

  2. ça commence par du TLP Amber pour le premier talk ;)

    [Edit: le cr en anglais par @xme pour le 2ème jour ici ]

    Botception: a bot spreading scripts with bot capabilities

    Durans le monitoring du botnet Necurs, l'orateur à découvert une campagne d'installation d'un autre bot. Necurs est apparu en 2012,  et il a eu les plus grosses campagnes de spam à ce jour. Necurs est modulaire, avec un protocole de C&C pair à pair. Pour monitorer le botnet, les orateurs ont développé un client qui émule le protocole de Necurs. Chaque branche de Necurs est identifié par un secret partagé au niveau du protocole de C&C. Le panel est en PHP, et son chemin & nom varie d'une branche à l'autre.

    Lors d'une campagne, un e-mail était propagé avec un lien vers un fichier vbs. La propagation se faisait via un partage SMB que les orateurs on pu browser et ils y on récupéré toutes les campagnes préparés par le cybercriminel. Ils ont même reçu un message de sa part sous la forme d'un fichier dans le partage qui disait "fuck you!". Le C&C du script VBS était codé en dur dans le script, et communique avec un gate.php sur un serveur web en POST. En récupérant l'exécutable

    Le loader VBS était aussi disponible sur le marché noir. Après analyse du mécanisme de drop, ils sont tombé sur le RAT Flawed Ammyy. Une version modifiée issue du leak du code source.

    Stagecraft of malicious office document - a look at recent campaign

    La majorité des documents malicieux sont des .doc avec des macros, dont certaines contiennent des messages incitant à activer le contenu dynamique pour afficher les informations. Le scénario typique consiste en une campagne de spam avec un lien ou une pièce jointe. La macro télécharge et exécute le malware, qui procède à un fingerprint du système avant de dropper le RAT ou le malware de vol d'information. 

    Pour éviter l'affichage de messages d'erreur, un "On Error Resume Next" est utilisé dans le code. PowerShell sert à télécharger la dernière payload (le RAT ou le stealer). Le code powershell est souvent "chiffré". Une autre métode consiste à faire de l'obfuscation avec du junk code. pour l'évasion de sandbox, ils utilisent mshta.exe pour télécharger le second stage du malware.

    Une autre campagne utilisait le powershell sous forme de propriété contenue dans des formulaires vbs ou des textbox. l'obfuscation consiste en des caractères morts et un décalage des valeurs ascii de la chaîne de caractères. Une autre variante utilisait BITSAdmin pour télécharger le malware. Le code VB contenait beaucoup de boucles pour ralentir l'analyse.  Une autre variante stockait le script sous forme d'un .bat dans %APPDATA%, mais le doc ne fonctionnait pas avec office 2007.

    Souvent toutes ces campagnes comportent un grand nombre d'étapes et de vérifications pour éviter les sandboxes avec des mécanismes d'obfuscation ou de chiffrement très faibles.

    Hunting and detecting APTs using Sysmon and PowerShell logging

    @c_APT_ure [Edit: slides ]
    L'objectif derrière ces techniques de monitoring c'est de coller à la matrice Att&ck et aux règles sigma pour écrire des règles de détection indépendantes des SIEM. Pour exploiter les techniques de l'orateur, il faut avoir les fonctions de logging activés, une centralisation des logs, la dernière version de powershell. Sur 25k machines, ça génère 150Gb par jour de donnés, ce qui fait un beau volume à indexer.

    Quand on regarde les sources d'info à surveiller dans Att&ck, le cycle de vie du process ne peut être récupéré que depuis Sysmon. Crowdstrike à fait une heatmap de genre de monitoring. Les events WMI peuvent servir à la persistance. Mandiant & FireEye ont détaillé le fonctionnement de cette technique. Hexacorn à publié un article sur un ensemble de technique d'exécution au démarrage dont une à été utilisé par le groupe d'attaquant Strontium. L'orateur décrit les logs powershell qui correspondent à l'ajout de ces clefs de registres pour la persistance, et comment les extraire. PowerShell étant très utilisé par un grand nombre de cybercriminels dont des groupes d’attaquants. Le monitoring de powershell à été grandement couvert à BSides Washington par Sean Metcalf.

    Pour échapper au monitoring, certains attaquant copient l'exécutable powershell et le déplace dans un répertoire random avant de l'exécuter. Pour éviter les faux positifs, on peu par exemple rechercher "Description: PowerShell" et exclure ceux qui s'appellent powershell.exe. Autre exemple avec le stager d'Empire et comment le détecter.

    Autre technique: comment automatiser les screenshots avec PowerShell issu d'un blogpost d'un pentester qui s'est en suite retrouvé dans le code de plusieurs cybercriminels. L'outil powerpick utilise rundll32 pour exécuter du powershell.

    C'est pas le tout de chasser les trucs malveillants que l'on connait, il faut aussi pouvoir chasser ce qu'on ne connaît pas. On peut construire une whitelist de fonctions powershell les plus connues et exécutés par des scripts légitimes, et s'en servir pour filtrer tout ça et surveiller les fonctions les moins utilisés qui apparaîtraient éventuellement et investiguer à partir de là.

    Combattre le Cybercrime à la gendarmerie


    La difficulté pour la Gendarmerie, c'est de s'assurer que les équipes techniques ont suffisament de moyens et le soutien qui leur permet de rendre leur missions. L'autre soucis c'est le partage du Threat Intel, qui ne peut pas toujours être obtenu de manière adéquate si l'on considère les contraintes d'une procédure judiciaire (validité de la preuve, etc...). Les Gendarmes ne travaillent pas pour le gouvernement, mais pour la justice et la sécurité des personnes. C'est eux aussi qui mènent l'enquête sur la base de signalement individuels. Autre difficulté, traduire les éléments techniques en quelque-chose de compréhensible pour Mr tout le monde afin de les sensibiliser sur les nouvelles arnaques. La lutte contre la pédopornographie est aussi dans leurs mission, avec comme objectif principal de sauver les enfants victimes de ces trafics.

    En plus d'une unité structurée autour de nombreux experts, techniciens et gendarmes formés aux action forensics de base, la gendarmerie collabore activement avec la police, l'ANSSI, Europol et des partenaires internationaux comme le FBI. La vitesse de traitement du problème est crucial. Il faut sur la base du renseignement, être capable de mettre en oeuvre une solution judiciairement viable et techniquement valide tout en respectant des contraintes budgétaires inévitables.

    Traiter avec des criminels classique qui opèrent sur le darknet pour vendre leur marchandises n'est pas très simple. Etre capable de faire sauter son anonymat numérique n'est pas toujours simple, même s'ils ont du mal à justifier la provenance de leur argent, il n'ont pas d'éléments incriminent chez eux lorsque la perquisition tombe.  Il n'est pas possible d'inculper quelqu'un sur la base d'hypothèses, il faut des preuves acquises avec méthode. Transformer un tuyau reçu par un expert en une enquête fait partie des missions du C3N. Reprendre l'initiative sur les cybercriminels et anticiper les plaintes qui découlerons de leurs activités est un sacré challenge. Le Cybercrime est le crime le plus difficile à résoudre.

    Pour compenser le manque de techniciens et d'experts, la Gendarmerie peut recruter des experts et en faire des enquêteurs pour permettre aux enquêtes de fonctionner dans un environnement technique complexe.

    Everything about panda banker.

    Le malware est nommé panda à cause de l'anti-virus panda, et le titre panda dans le panel. l'autre nom c'est Zeus/Panda parcequ'il est basé sur le code source de Zeus.  Il y a eu 45 versions du malware jusqu’à ce jour. La version est stocké dans un DWord. Les api sont résolu par leur hash, technique classique d'anti-analyse. En version 2.2.9 les chaines de caractères sont chiffrés, et finissent par faire appel à une mécanique maison et différente de Zeus. De même les mécaniques de configuration ont lentement évolué de la version employé par Zeus à un système dédié à Panda.  Bien entendu, le malware fait appel à un mécanisme de DGA pour protéger son serveur de C&C. Comme de nombreux malwares, il est distribué & utilisé par plusieurs groupes de cybercriminels avec différentes activités.

    The dark side of the ForSSHe

    Windigo est une opération qui consistait à piper dans une session SSH un script perl qui collectais plein d'infos sur le serveur SSH. Perl est un peu obfusqué naturellement, mais c'est lisible par un être humain.  A partir de l'analyse du script PErl, ils ont recherché avec Yara des échantillons de malwares SSH. Ces backdoors SSH sont des versions patchés d'OpenSSH avec du vol d'identifiants de connexion intégré. Pour ce faire, les cybercriminels ont modifié les fonctions userauth_passd, ssh_askpass, try_challenge_response_auth, etc... qui servent à l'authentification de l'utilisateur.

    L'exfiltration des informations se fait sur du GET ou du POST sur le port 80 du serveur C&C, ou par du DNS, ou encore l'envoi d'un e-mail sur SMTP. Voir des protocoles maison sur udp ou tcp.

    Kamino par exemple vole les usernames & pass, les exfiltre avec la clef de session. L'opérateur peut se logguer comme root avec un password et une clef publique codée en dur. Kamino est apparemment lié aux groupes d'attaquants Carbanak et Darkleech.

    Kessel utilise une fonction de chargement de configuration qui appelle une tartine de fonctions. c'est une famille de backdoors très complexes. Il leak les identifiants et les fichiers de clefs privés, peut exfiltrer par de nombreux protocoles, utiliser un proxy. Il dispose d'une fonction de C&C via les champs TXT de DNS, et il peut créer un tunnel SSH à la demande. Il utilise RC4 pour le chiffrement avec des clefs ssh en dur.

    Bonadan réutilise le code d'Ondaron, une backdoor SSH publiquement disponible. Elle communique via un protocole UDP maison. Le mineur de bitcoin associé est pré-compilé sur le C&C, et correspond à l'OS de la victime.

    Pour piéger les attaquant, les orateurs ont mis en place un honeypot capable d'être suffisament interractif pour que les attaquants y déposent des échantillons récents.

    Borleias backdoor le client SSH, l'attaquant c'est connecté très rapidemnet après le leak des identifiants, via TOR. Il utilise OpenSSH sur Far-NEtbox, il es ttrès prudient quand à son éventuelle détection, et il nettoie l'historique après chaque connexion. Il effectue une reconnaissance en exfiltrant ssh, sshd et cron. La backdoor dispose d'un mécanisme anti-log et utilise RC4+ pour le chiffrement. Il chiffre ses rapports avec une clefs de session chiffré avec RSA.

    Chandrila est une backdoor ssh qui peut recevoir des commandes sous la forme de mots de passes. Si elle reçoit un premier mot de passe elle crée un shell. Si elle reçoit un second mot de passe, elle crée un reverse-shell.

    Pour échaper à ce type de backdoors, il vaut mieux utiliser l'authentification par clef, plutôt que du login/pass. Il vaut mieux désactiver le login root, et utiliser du 2FA. Vérifiez les sommes de contrôles de ssh & sshd. Linux est bel et bien une cible des cybercriminels, et ils mettent parfois beaucoup d'énergie pour éviter la détection sur les systèmes compromis. 


    Onyphe - uncovering darknet websites


    Onyphe est un "siem de l'internet" et fournis une API pour récupérer des infos aggrégés sur une IP. Si on peut coreller des informations sur le serveur web avec le serveur sur le darknet, on peut avoir une correllation forte. Pour la correllation, Onyphe utilise un langage de requête similaire à splunk.  Environ 3,3% des .onion sont démasquables.

    Living with Kodi and a hole in your network.


    Kodi est un player multi-média qui fonctionne à coup d'add-on pour lire des vidéos sur netflix, youtube, etc... Il faut être sûr de soit si l'on veut installer un plugin non-vérifié. Avec quelques fichiers, on peut créer une extension malicieuse qui exécute du python. Vu que l'install des plugins se fait en HTTP, un Man in the middle suffit pour piéger un Kodi.

    Why botnet spam is going down


    Depuis 2008, le nombre d'e-mails de spam descend. Le top du spam par pays, c'est l'inde, le vietnam et le mexique... c'est parceque c'est de plus en plus dur de faire tourner du malware sur des windows à jour, alors que dans ces pays... Il n'y a pas de meilleur moyen pour une machine que d'annoncer à coup de spam qu'elle est infectée.... Mais bien que le volume du spam est plus faible, le nombre de spam dans les inbox reste important. Les spammeurs se sont adaptés.

    3ve


    Un takedown sur 2k serveurs sur un botnet qui visait les datacenters. le bot incorpore pas mal de techniques pour éviter de se faire détecter. L'infection est surtout aux us et en allemagne, avec pas mal de serveurs sur toute l'europe.

    VTHunting


    un petit outil en python pour centraliser les rapports VT et les samples au travers de l'api VT, et envoyer les rapports via email, slack, telegram. Il est directement utilisable en CLI.

    Splunkup

    un outil pour importer des données de MISP dans Splunk, ou pousser des informations depuis splunk vers MISP.  On peut faire des recherche dans MISP, importer des IOC, créer des alertes dans splunk. Créer des events MISP.

    Anatomy of a Booter


    equalit.ie - le DDoS quand on a de la chance, c'est un pic de traffic sur le graph de bande passante, mais parfois c'est un site HS. Dans les logs on peut trouver par exemple des pingback wordpress qui servent au DDoS. Comme WP ajoute l'ip à l'origine de la demande de pingback dans le user-agent, il est possible d'identifier l'IP de l'attaquant, avec un répertoire ouvert contenant tous ses outils, et la liste de ses relais.

    mwdbv2


    malware database version 2. Quand on upload un sample sur mwdb v2, on peut récupérer la configuration du malare extraite. c'est automatisé et ça supporte plus de 70 familles de malwares.
    l'url: mwdb.cert.pl

    Tsurugi Linux


    Tsurugi est une distribution linux orienté DFIR et OSINT soutenue par OpenMinded et basé sur la dernière version d'Ubuntu 16.04 LTS. Turugi acquire est un mini-linux 32 bits conçu pour l'acquisition live. Bento est un windows de forensic maintenu par l'équipe Tsurugi.

    A kind of funny story


    (j'entend rien :( une histoire de chat sur twitter entre un dev de malware et quelqu'un de MalwaresBytes)

     Bitcoin supply chain attack.


    des hits sur un js modifié appellé statcounter.js. Une fois unpacké, on retrouve un js injecter depuis statconuter.com. Le site ciblé c'était gate.io. Dans le 2eme stage, le wallet de destination est remplacé par le wallet de l'attaquant. Un mec de Statcounter à posté qu'il avait installé ESET pour vérifier s'ils n'était pas compromis.


    We need your IP Space


    shadowserver est une association non-profit qui monitore les botnets et fait beaucoup de sinkholing. Ils partagent leurs infos avec les CERT et les forces de l'ordre gratuitement. Ils n'ont pas assez d'IP dans certains pays pour faire leur monitoring correctement.


    Evil maids are evil


    Quoi faire contre une attaque type evil maid ? vous pouvez utiliser les donnés SMART du hard drive. Par exemple on peut  monitorer le "power cycle count" qui compte le nombre de fois que le disque dur à été alumé. A chaque boot, s'il augmente que de 1, c'est qu'il n'a pas été booté entre temps. l'orateur à écrit un script sur son github.


    0

    Ajouter un commentaire

  3. C'est reparti pour une nouvelle BotConf à Toulouse... malgré quelques problèmes de transports en commun pour ceux qui ont participé aux workshops ;)

    [Edit: @xme à un compte-rendu en anglais ici ]

    Swimming in the Cryptonote Pools

    Un premier talk du CERT-EU.
    Sur BitCoin, on peut tracer l'ensemble des transactions d'un wallet à l'autre. Sur monero, il vous faut la clef privée du wallet pour tracer les transactions. 
    Il y a beaucoup de malwares qui minent des crypto-monnaies, et le font dans des pool de minage. L'orateur utilise des règles Yara pour récupérer les id des wallet car il s servent aussi à l'authentification des utilisateurs du pool. Le problème c'est que c'est souvent stocké en base64 dans les malwares, ce qui génère des faux positifs. Lorsque le malware est packé, l'orateur utilise retdec et snowman pour les unpacker avant d'y rechercher des informations sur les wallet.

    Les API des pools de mining ne sont pas très privacy by design, et du coup l'orateur peut récupérer les wallet des participants à une pool de minage en lui envoyant les adresses qu'il à trouvé.

    APT attack against the middle-east


    @CurlyCyber
    Description d'une attaque par apt-c-23. Tout commence avec un document piégé citant un article de news,  dont une partie du code est issu d'un code copier-collé depuis slack. Le C&C communique sur https, mais si jamais il n'y arrive pas, il y a une addresse de backup avec une URL encodée en base64 qui répond sur /api/devices/requests qui peut répondre une autre addresse de C&C.  Les fonctions des malwares de ce groupe font souvent référence à des personnages de big bang theory et autres séries télé.

    Dans les whois des noms de domaines les plus anciens, on retrouve des informations probablement fausses, mais cohérentes correspondant à une entreprise de de hosting à gaza. D'autres noms de domaines employé par ce groupe pointent sur d'autres entreprises de gaza.

    Code Cartographer's Diary

    L'orateur nous avais déjà présenté Malpedia l'an dernier. Il s'agit d'une suite de ce talk. L'objectif de malpedia, c'est d'avoir une collection de malwares triés, rangés dans les bon contextes, unpackés, avec des yara associés, etc... L'objectif c'est de pouvoir par exemple faire des associations entre les malwares lorsqu'ils ré-utilisent du code entre eux. Tout ceci pour permettre aux chercheur de mener des expérimentations sur ce dataset (machine learning, IA, etc...).  Le dataset se veut "petit" mais complet en nombre de familles de malwares.

    Petit retour sur les techniques de lookup d'API windows employés par les malwares présents dans malpédia: Import PE, Chargement dynamique par appel à GetProcAddress et hash d'API et plein de techniques d'obfuscations.  L'orateur présente en suite quelques statistiques sur l'usage de ces API extraites par ApiScout, leur distribution, leur fréquence, etc...

    Malpedia permet de servir de dataset à des techniques de mesure de similarité de code. L'orateur détaille le fonctionnement de MinHash et son usage pour la similarité entre malwares. En gros, il prend les n-gram des mnemoniques et quelques stats sur la fonction, les ballance dans minhash et compare avec une autre fonction.

    En faisant de la similarité multi-critères, l'orateur à essayé de comparer des familles de malwares. Le problème c'est qu'il se retrouve avec un gros blob de binaires collés, et plein de malwares éparpillés... cela s'explique par le fait que les malwares utilisent un grand nombre de librairies communes, ce qui fausse le clustering. Du coup en filtrant les libs connues des ensembles de fonctions, on obtiens des clusters par familles.

    Chess with Pyotr


    Storm Worm: botnet p2p, distribué par du spam. le c2 fonctionnait sur du EDonkey, et utilisait la dht de kademlia pour échanger des infos sous la forme de hash md4. ils utilisait xor pour "encoder" les échanges, mais ne comprennait pas vraiment le fonctionnement de ce protocole p2p. En empoisonnant le cache des bots, on peut faire un takeover sur le botnet et reprendre le contrôle.

    Waledac utilisait une architecture hybride avec du p2p et reposait sur les bots avec une ip publique pour servir de relais pour les bots derrière des NAT ou des firewalls. Les worker qui génèrent du spam, etc... était séparé des bots de contrôle qui bénéficiait d'une ip publique. Le problème d'un botnet p2p, c'est de bootstrapper et de trouver un pair auprès de qui récupérer la liste des pairs du botnet avec qui échanger. Chaque pair générais un certificat x509 auto-signé et une clef RSA de 1024 bits. Autre stratégie employés pour le bootstrap: des serveur fast-flux dns avec des reverse proxy.

    Kelihos est un botnet de spam, vol d'identifiants de connexion, ddos, de fraude au click, de proxy socks, vol de cryptomonnaies, et de "pay per install". la première version avait un mode debug intégré. Il tournait sur le port 80 par défaut, mais il était conçu pour fonctionner sur un autre port. Le port TCP était stocké sur 4 octets alors qu'un port s'encode seulement sur 2 octets, ce qui à servi aux orateurs pour attaquer le protocole du botnet et l'empoisonner.
    le dev de kelihos à été spotté à l'aide de traces laissés dans ses codes. Un download d'un jpeg sur son serveur perso lancé comme tâche de test sur l'ensemble du botnet. Ils ont retrouvé le code d'une partie du malware sur github de l'auteur. Pour le poisoning, ils ont bootstrappé, puis se sont fait insérer dans la peerlist. Les orateurs détaillent le fonctionnement des tâches planifiés sur le botnet, et le mécanisme de template pour les spams.

    Kelihos.B est une nouvelle version après le take-over. Apparu le 30 Novembre 2011, il restait des symboles de debug dedans, mais le code source n'était plus publique. Kelihos C à été takedown à la conf RSA, et la version D est sortie 20 minutes après. Les forces de l'ordre ont profité du fait que l'auteur du malware était en vacance en Espagne pour s'arranger avec les orateurs pour effectuer le takedown en même temps que l'arrestation.   

    Formbook

    @netsecurity1
    Formbook cible un grand nombre de navigateur mais aussi certains clients de chat. Il est vendu & loué par le développeur. L'auteur du malware fournissait des binaires customisé par client. Le panel est fourni à ceux qui louent le malware, s'il est acheté, les clients doivent l'héberger eux même. FormBook est dans le top10 de la sandbox any.run.

    Pour échapper aux analyses, Formbook obfusque ses chaînes en les construisant avec des mov sur la stack. Les api sont importé par hash, et utilise BZip2 & crc32 pour hasher les noms des fonctions. Il dispose de blacklist et ne s'execute pas si il découvre ces éléments sur le systèmes: noms de process, noms de dll présentes à l'exécution du programme, noms d'utilisateur lié à certaines sandboxes, etc...

    Les chaînes peuvent être déchiffrés avec MalwareHash. La table des imports est vide, FormBook importe les fonctions de plusieurs façons: par nom, par ordinal ou par hash. Formbook fait du process-hollowing sur explorer.exe pour migrer de processus, ce qui fait qu'il ressemble à un processus windows légitime. Pour le hooking de fonction dans les programmes ciblés par Formbook, il embarque un petit disassembleur pour écrire les inline hook aussi bien dans des process 32 que 64 bits. Pour récupérer les mots de passes enregistrés, FormBook récupère les bases sqlite de Firefox & Chrome. Pour protéger ses serveurs C&C, Formbook utilise des faux serveurs C&C qui sont contactés en même temps que le vrais serveur C&C.

    How much should you pay for your own Botnet

    L'orateur à mis en place des botnets de test pour valider des solutions anti-DDoS, il s'est donc demandé combien ça coûtais et si c'était abordable ou pas. Cette présentation ne tiens pas compte des problèmes légaux, et n'a pas pour vocation à décrire les techniques de DDoS. Le coût du botnet dépend du coût de l'infrastructure, et du coût en bande passante. Les deux étant facturé de façon fine sur les plateformes de cloud. Après prise en compte des variation de coût induite par les localisations géographique des serveurs loués, l'orateur à effectué son comparatif.  Il a ainsi pu générer un DDoS de 9TB pour moins de 900€

    Collecting particles from Neutrino Botnets

    Neutrino est un botnet très connu. Les orateurs nous raconte son histoire et ses modifications, de la première version sans obfuscation aux versions récentes, plus modulaires et embarquant des mécanismes d'obfuscation des appels aux API Windows. La version actuelle chiffre ses modules, et utilise une clef de registre Winlogon pour sa persistance.

    Neutrino est vendu à un grand nombre de cybercriminels, du coup il faut réussir à séparer les samples en groupes liés à chaque cybercriminel. L'identification d'une variante de neutrino se fait par les serveurs de C&C, sa version, son nom de bot, et son identifiant de build. La classification par build id se fait plutôt bien.

    Les orateurs présentent en suit différents clients du malware, avec leurs objectifs et les modules qu'ils utilisent pour commettre leur forfaits. Les webinjects sont très populaires pour le vol d'identifiants bancaires et la génération de transferts bancaires à l'insu des clients.

    Trickbot: The trick is on you !

    Trickbot est un trojan bancaire découvert en 2016, très similaire à Dyre. C'est un bot très modulaire, avec du webinject, du vol de mots de passe de clients mail, etc...  Le loader charge un module de coeur et une configuration qui  contiens une liste de fichiers de config supplémentaires et de modules associés à charger. La communication de Trickbot est basé sur un système de commandes. Il y a deux catégories de commandes: soit elle viens du client, soit elle viens du serveur de C&C. Lorsqu'il s'agit du client, on retrouve dans les urls les identifiants de campagne, de client, etc... Du coup les orateurs ont conçu un système de tracking des commandes lancés par les cybercriminels.  La majorité des opérateurs de Trickbot sont en Russie, et la majorité des cibles sont aux US.

    Automation and Structured Knowledge in Tactical threat intelligence.

    Les orateurs sont membre du GReAT de Kaspersky, et suivent plus de 100 groupes d'attaquants, ce qui génère un très gros volume d'informations techniques. Les incidents isolés au sein des clients de Kaspersky, sont souvent les symptomes d'actions de cybercriminels. Le renseignement sur la menace  est le produit d'un processus de transformation d'élément techniques observés en connaissances sur les malwares, les groupes d'attaquants, leurs méthodes, etc...

    Il faut d'abord transformer une expertise technique en un outil, c'est un peu la base de nombreux outils open-source. Le problème c'est de gérer la volumétrie monstrueuse d'échantillons de malwares à analyser. D'abord il faut bien cibler ce que l'on souhaite obtenir, déterminer les action à entreprendre, les subdiviser en tâches atomiques, puis déterminer la faisabilité de chacune. Par exemple, à la question "est-ce que ce sample est malicieux", on fait des vérifs VT, on lance PEiD, etc... on élimine les contradictions à coup d'IDA, et on prend une décision... le problème c'est que la partie IDA est difficile à automatiser "simplement". Du coup, il faut revoir ses attentes, éliminer ce qui n'est pas automatisable, et en faire une chaîne de traitement réalisable et adaptée.

    En Threat intel tactique, on utilise un grand nombre de modèles pour faciliter la visualisation de l'information et sa transmission à des personnes moins techniques. Arbres d'attaques, modèles d'adversaires, kill chain, sont les briques de bases pour construire ces modèles de threat intel. L'att&ck framework et autres outils du MITRE sont très utiles pour ce type de modélisations, et offrent un vocabulaire structuré associé. Comme c'est un langage structuré, qui s'adosse à des bases de donnés, on peut s'en servir dans la gestion des connaissances.

    Les arbres d'attaques sont assez agréables à lire, mais quand on met trop d'informations dedans, on à du mal à les interpréter s'ils sont généré automatiquement. En plus ils ne sont pas adapté à la visualisation des dépendances. La kill chain c'est linéaire, c'est agréable pour comprendre une séquence d'actions, mais ça n'est pas complet. Les graphs, c'est un super outil exploratoire, mais ça biaise l'analyse, car ça donne l'impression que deux éléments sont fortement liés alors que ce n'est pas toujours vrai.

    L'objectif des orateurs est de produire des connaissances exploitables et compréhensibles. Première idée: transformer les sorties de manalyzer et les traduires sur l'att&ck framework. En partant des matrices du MITRE, et en sélectionnant les techniques qui vont bien on peut retrouver les informations de mitigation, de détection. Sauf qu'en pratique, la correspondance entre l'Att&ck et les sorties d'un outil d'analyse n'est pas toujour bonne. De plus, pour un même échantillon, les résultats varient d'une sandbox à l'autre quand aux éléments de l'Att&ck remonté ne sont pas les mêmes.

    Le problème c'est que Att&ck modélise l'intention, et que cette intention peut prendre une infinité de variations observable par les outils d'analyse de malwares. Les orateurs ont donc mappé les sorties de manalyze avec la matrice du framework Att&ck pour faciliter l'analyse de ses sorties et leur mise en relation automatique avec les informations de détection et de mitigation décrites dans le framework.




    0

    Ajouter un commentaire

  4. Enhancing network slice security via Artificial Intelligence: challenges and solutions

    La base de la sécurisation d'un réseau, c'est sa compartimentation par fonctions logiques afin de réduire les capacités de mouvement d'un attaquant. Dans le cadre des réseaux 5G, il faut pouvoir assurer les inter-dépendances entre les services tout en maximisant ce découpage. La complexité inhérente aux architectures de service 5G complexifie grandement cette tâche. L'intelligence artificielle offre des oportunités de solutions pour la gestion de ces découpages réseau et leur monitoring. 

    Détection d'anomalies pour l'aide au hunting

    L'activité de hunting consiste à rechercher des traces d'intrusion dans les logs d'un système pour déclencher des investigations complémentaires sur les systèmes. L'objectif des orateur est d'aider l'analyste à prioriser ses investigations en mettant en lumière les éléments les plus anormaux. Les orateurs ont utilisé des forêts d'isolation et des auto-encodeurs sur une trentaine de métriques extraite de logs de proxy web. 

    Les auto-encodeur sont des réseaux de neurones utilisés pour la compression d'images dans les moteurs de recherche, dont le fonctionnement peut être appliqué à la détection d'anomalies. Bien que no-supervisé, l'auto-encodeur nécessite une phase d’apprentissage ou il va compresser et décompresser le vecteur de propriétés en entrée et fournir 

    La forêt d'isolation partitionne l'espace des valeurs possible pour l'ensemble des propriétés observés, et va définir des hyper-plans permettant de découper en divers ensembles ces propriétés. Les anomalies se retrouvent très rapidement isolés par ces hyper-plans. 

    Les implémentations se sont faite sur un cluster Spark, et les donnés sont extraite du collecteur de logs Splunk. Côté performance, il faut 15min pour digérer 6h de logs. 


    Aide à la classification des événements remontés à un SOC.


    Un SoC travaille en deux temps, un temps à chaud de détection et de confinement de la menace, et un temps à froid d'amélioration de la sécurité. Les activités d'un SoC sont très répétitives, et offrent la part belle à l'automatisation d'un très grand nombre de tâches. L'IA permet d'automatiser l'aide à la décision et de concentrer l'attention de l'expert en l'assistant dans le tri entre événements malveillants et bénins. 

    Pour l'automatisation, on essaye de faire mieux que pile ou face. Du random forest donne un taux de détection de 62%, mais on aimerais pouvoir injecter des savoir-faires dans l'algorithme. En jouant sur les hyper-paramètres de l'algo on pousse le taux de détection à 69%. à force d'itérations, on améliore le modèle de détection et la qualité des donnés analysés. Cette démarche se fait en associant les experts du SoC et les data-scientists. 


    SCA par apprentissage machine


    L'objectif d'une attaque par SCA est d'extraire la clef cryptographique d'un composant electronique par l'observation de divers canaux auxiliaires tels que la consommation électrique, le champ magnétique local, etc...  Lors des phases de chiffrement et de déchiffrement, le composant émet un rayonnement électromagnétique porteur d'informations liés aux valeurs de la clef. 

    Lorsque l'attaquant à l'équipement à disposition, il va pouvoir maîtriser les donnés de chiffrement fournies au composant. Il est donc envisageable d'employer un réseau de neurones pour l'entrainer sur ces donnés et lui apprendre à extraire la clef du composant. 

    Pour ce faire, les expérimentation se sont basés sur le jeu de donnés ASCAD fourni par l'ANSSI. L'attaque porte sur un micro-controleur avr atmega 8515 embarquant une implémentation durcie d'AES. L'IA requiert souvent des gros jeux de donnés pour bien fonctionner. Du coup les orateurs ont généré un second jeu de donnés. 




    0

    Ajouter un commentaire

  5. Automatisation du processus d’apprentissage pour la détection d'intrusion

    Les travaux présentés ont pour jeu de donnés le NSL-KDD, un dataset enregistré en 1998 par la darpa sur un LAN simulé de l'air-force. Afin d'améliorer l'aprentissage des classes d'attaques présentes dans le dataset, l'orateur à répliqué les donnés correspondant aux classes existantes. La génération de ce sur-échantillonage est combiné au meilleur algo de sous-echantillonage afin d'obtenir des jeux de donnés d'aprentissage "gonflés". L'objectif étant en suite d'obtenir des modèles optimisés pour la détection de chaque classe d'attaque.

    Une fois les jeux de donnés générés, dix algos de machine learning vont être entraînés afin de comparer leur performances. Pour optimiser l'aprentissage, les orateurs ont utilisé de l'aprentissage par ensemble afin d'obtenir le meilleur de chaque algo. Quand on compare les résultats des différents algorithmes, on observe que les MLP ont des performances bien meilleures que les algos de machine learning "traditionnels"

    Intelligent Thresholding


    Etude sur des produits de détection anomaly-based qui cherchent à détecter les comportements déviants par rapport à une référence de base issue d'une phase d'aprentissage. Ces solutions sont très fortes pour générer un score (de 0 à 1 ) associé à l'élément anormal remonté. On peut légitimement se poser la question de la signification de ce score, et la valeur à donner au seuil de "détection". Ce seuil de détection peut être fixé à la main [1](ou au doigt mouillé), et nécessite parfois une expertise fine du produit (ou un plus gros doigt ?). L'autre possibilité, c'est de fixer ce seuil de façon probabiliste.

    Ce choix du seuil de détection par rapport à la distribution des valeurs de détection généré par l'algo pour chaque donnée peut se faire de différentes façons. On peu découper le dataset en deux partie, les 99% "normales" et le 1% le plus extrème, ou encore en employant la théorie des valeurs extrèmes  Cette méthode permet d'extraire des donnés la portion la plus anormale. (c'est mieux qu'un doigt mouillé...). Cet algo à le bon goût d'etre utilisable de façon incrémentale, et donc de venir faire varier le seuil de détection en fonction de l'évolution des observations.

    Le jeu de donnés, c'est important, du coup en plus du NSL-KDD, l'orateur à travaillé avec les donnés issue de MawiLab pour tester comment se comporte son aproche de choix de seuil par EVT. La solution fonctionne pour n'importe quel algo fournissant un score de détection, et ne nécessite aucune expertise particulière. On construit donc de façon probabiliste et systématique un seuil de détection qu'on va mettre à jour dans le temps.

    Applicabilité de la classification binaire pour détecter les attaques par accès mémoire sur les IoT

    Bon les IoT, c'est cheap, pas très puissant et pas pensé pour la sécurité, avec une durée de vie programmée d'une dizaine d'annés. Côté attaques, c'est pas les possibilités qui manquent. Pour préparer une attaque IoT, il faut comprendre le fonctionnement de l'objet connecté. L'une des stratégies d'attaques c'est d'aller dumper la ou les mémoires de l'objet pour obtenir le firmware et les secrets embarqués dans ce dernier.

    Pour se protéger de ces attaques, il est envisageable d'embarquer des fonctions de détection de ces attaques pour que l'IoT se défende en cas d'accès mémoire illégitime [1]. Les options défensives que l'on peut embarquer dans ces IoT sont très limités de par la nature des ressources matérielles disponibles sur ce type d'équipements. En monitorant les types d'accès mémoire effectués, et les addresses, l'orateur à généré des jeux de donnés d'accès mémoires représentant différentes techniques de dump mémoire. Du fait des ressources limités, les algorithmes choisis sont très "simples" et ne reposent pas sur des réseaux de neurones trop coûteux pour fonctionner sur un IoT.  Ils se contente de séparer les accès mémoires entre ceux correspondant à des attaques vs ceux correspondant à un fonctionnement normal de l'IoT (d'ou la classification binaire, en deux classes). Après benchmark, un classifier à base de filtres bayésiens sort du lot.

    Revue des IDS basés sur le Machine Learning dans le contexte des ICS

    L'orateur rappel comment fonctionne un écosystème ICS avec ses contraintes temps réel. Rappels en suite sur le fonctionnement des IDS et leur positionnement sur le SI. Les informations de monitoring qui vont alimenter l'IDS comportemental peuvent être captés sur la partie contrôle commande et permettent de modéliser le fonctionnement normal du processus industriel. Ce comportement normal peut-être appris ou bien exprimé à l'aide d'un langage spécialisé. Lorsque le comportement normal se fait par apprentissage, la condition clef c'est la qualité des donnés.  Sur la base de ces éléments, l'orateur dresse un état de l'art et l'adéquation ou non des solutions publiés face au contraintes des environements ICS.

    Application du machine learning pour la détection d'attaque sur les ICS

    Un système industriel échange un grand nombre de variables qu'il lit ou écrit via un protocole métier sur des contrôleurs ou des sondes physiques. Le mécanisme de détection présenté va se baser sur ces donnés observés pour identifier les attaque au sein de ce flot d'échanges. Les expérimentations se sont faite sur un jeu de donnés issue de SWaT, qui contiens du traffic normal et des attaques.

    Protection contre les attaque par fuzzing

    ChuckyJava est une variante pour le langage java de chucky-ng, un fuzzer qui génère des cas de test à partir du source. L'objectif étant de découvrir les bugs & vulnérabilités du système testé. L'orateur à donc testé 5 applications Java avec son outil.

    CNN with data augmentation against jitter-based countermeasures

    En cryptanalise classique, on compare souvent le clair et le chiffrer pour tenter de découvrir des informations sur la clef. Lorqu'on réalise une évaluation d'un produit cryptographique matériel, on recherche ces fuites d'information sur le composant électronique. Pour se faire, on lui fait traiter un grand nombre de messages en clair, et on observe sa consommation électrique. Les pics de consomation peuvent être correllés avec les valeurs des bits de la clef et faire fuiter la clef. Pour repérer ces fuites, l'orateur utilise un réseau de neurones convolutif (CNN).  L'avantage de cette approche, c'est que le CNN est résistant à certaines transformations que pourrait opérer le concepteur du composant de façon défensive.

    CBWAR - Classification de Binaires Windows via Apprentissage par Renforcement.


    L'apprentissage par renforcement est un algo d'aprentissage semi-supervisé utilisé notamment par AlphaGo. L'analyse des binaire se fait sur la base de l'analyse des syscall issu d'une exécution du malware dans cuckoo-sandbox.

    RNNs pour la sécurisation du code PIN

    Les réseaux de neurones récurrents sont utilisé dans la reconnaissance de l'écriture d'un individu. Il est possible de façon similaire de reconnaitre les tracés de chiffres sur un mobile. L'orateur c'est donc intéressé à une technique de mesure de similarité entre les tracés de chiffres par un utilisateur pour remplacer le traditionnel code pin dessiné sur smartphone. En utilisant un RNN utilisant uniquement les coordonnés du doigt sur l'écran, le système réussi à identifier un usurpateur (bon pin, pas le bon geste) dans 90% des cas, et reconnait les utilisateurs légitimes dans 98% des cas.

    Application of distributed computing & machine-learning technologies to cybersecurity

    Le coût du cybercrime est élevé pour la société, et s'est accru de 20% entre 2017 et 2018. Le projet Shield financé par l'union européenne vise à founir des solutions opensource pour déployer des solutions de sécurité virtualisés dans un cloud. L'acquisition de donnés de sécurité se fait par le déploiements de senseurs sur une infra virtualisés. Une fois les donnés collectés, ils utilisent Hadoop & Spark pour les analyser. Le machine learning sert à la détection des comportement anormaux.

    Reconnaissance automatique d'un menace cyber dans le contexte du naval de défense

    les navires embarquent un grand nombre de composants informatiques, sont fortement connectés et inter-connectés, et leur sécurisation est un défi. Les navires modernes fonctionnent avec un équipage de plus en plus restreint, et embarquent rarement un expert sécurité. Il faut prendre en compte la sécurité dans l'ensemble du cycle de vie du navire, de sa conception à son utilisation. l'analysee de l'ensemble des donnés générés par le navire se fait en deux temps, un premier à bords avec une analyse en temps réel sur une puissance de calcul limité, un second à terre avec des capacités de calcul beaucoup plus importantes, mais avec des contraintes de confidentialité des donnés plus importante.







    0

    Ajouter un commentaire

  6. Apports de l'IA à l'analyse de risque

    Bon, l'analyse de risque, c'est pas simple, source d'erreurs, et parfois fastidieux. Alors mettre une IA pour automatiser ces analyses, pourquoi pas. Lorsqu'on effectue une analyse de risque, on cherche à prendre des decisions qui réduisent l'impact et la vraissemblance des attaques. L'analyse de risque migre de la gestion du risque à la gestion du cycle de vie de la sécurité. Ces processus de sécurité tels que définis par l'iso 15288 sont autant de points ou l'intelligence artificielle peut s'appliquer.

    On peu aussi envisager l'IA comme une source de risques, permettant la mise en place d'attaques jusqu'alors complexes à réaliser (comme la génération d'empreintes digitales pour tromper les scanners biométriques: https://arxiv.org/pdf/1705.07386.pdf ).

    Retour d'expérience sur le Machine Learning appliqué à la sécurité

    (suite(s) du sujet déjà présenté à SSTIC l'an dernier)
    Les étapes à envisager pour pouvoir mettre en oeuvre du machine learning sont les suivantes: l'annotation des donnés, l'extraction d'attributs sur lesquels le machine learning va s'appuyer pour l'apprentissage. Le modèle d'aprentissage qui influe grandement sur les performances, et en fin la validation du modèle de détection.

    Les jeux de donnés sont très cruciaux pour la mise en oeuvre du machine learning. Ce travail d'annotation peut s'avérer très couteux et sensible dans le domaine de la sécurité informatique. Afin de réduire le coût de ces annotations, l'oratrice à mis au point une interface dédiée à la création de ces annotations.

    Autre enjeux, comprendre sur la base de quels éléments le modèle à pris la décision de signaler tel élément. Supprimer cet effet boite noire peut passer par l'emploi de modèles d'aprentissages plus simples que les réseaux convolutifs profonds. Les arbres de décisions ou les réseaux bayésiens sont un exemple d'algorithmes de machine learning "simples" et compréhensibles par un expert en sécurité.

    Attaques sur le Machine Learning

    Le machine learning peut être attaqué de diverses façons. Côté accessibilité, on peut mettre en déni de service le modèle ou l'empêcher de décider. Côté confidentialité, on peut extraire des informations de ces modèles (en extrayant les poids du réseau de neurone par exemple). On peut aussi attaquer la disponibilité en le trompant avec des donnés conçues spécifiquement pour. 

    La question du moment ou l'attaquant va mener son attaque est importante, car s'il interviens tôt dans le cycle de mise en oeuvre d'une IA, il peut par exemple empoisonner le jeu de donnés. Un empoisonnement des donnés peut avoir un impact fort sur les performances du modèle, quel que soit ce dernier. 

    Lorqu'on travaille sur un modèle existant, on peut extraire des informations de ce dernier, soit des donnés "moyennes" soit carrément des donnés complètes telles quelles sont au sein du modèle. Autre type d'attaque; altérer une donnée existante pour qu'elle match autre chose que ce qu'elle est. Le problème, c'est qu'une donnée "offensive" généré pour tromper un modèle, peut aussi avec une forte probatilité être transféré sur un autre modèle, autrement dit, le camouflage fonctionne pour divers modèles spécialisés pour reconnaître ces donnés.

    Si l'attaquant met la main sur une instance physique de votre IA, il peut mener des attaques physiques types SCA pour identifier les fonctions d'activations employés dans le modèle, d'en extraire des image, voir d'en réaliser une inversion de modèle complète.

    Skeptic: détection de comportement anormaux par machine learning

    La fraude en ligne est grandissante, et le nombre d'attaques sur les applications web est toujours aussi important. Les fraudeurs s'appuient souvent sur de la ré-utilisation d'identifiants fuités sur internet pour échapper aux modèles de détection "classiques". UBEA: User & Entity Behavior Analytic consiste à créer une "baseline" de comportement(s) normaux, afin de détecter les comportement annormaux qui dévieraient de cette ligne rouge apprise par le modèle.

    Skeptic se base sur des logs applicatifs issu du monitoring des applications à sécuriser, et des modules d'action qui permettent de verrouiller ou de "challenger" un utilisateur dont le comportement semblerais suspect. Les logs sont collectés sans avoir à modifier l'application, et l'apprentissage est non-supervisé. L'analyse des logs se fait au travers de multiples extracteurs de propritétés associés à des algorithmes de Machine Learning adaptés, et les scores issus de ces algo font l'objet d'une analyse multi-critères à la façon d'un système expert. Cette approche permet de "tuner" le score issu de l'analyse, et d'adapter le poids de telle ou tellle analyse sur le score final.

    La solution à été développée sur Spark avec une file de message Kafka,  et un ELK pour l'indexation et la visualisation des donnés pour la supervision et l'investigation.

    Retour d'expérience sur la détection d'un comportement hostile dans un réseau. 

    L'UEBA est une stratégie de détection comportementale qui peut générer son lot de faux positifs, et qui lorsqu'elle est mise en oeuvre avec des donnés d'entrainement potentiellement "teintés" d'une attaque peut avoir des résultats biaisés. Premier Poc sur la base d'un algorithme de forêts isolés non-supervisés pour détecter un scénario de spear-phishing sur un réseau d'entreprise. L'autre sur des auto-encodeurs pour détecter l'exécution d'un script bash malveillant sur un système linux.

    Robustesse des IA face à l'évasion de modèle

    Le modèle choisi pour "classifier" les donnés dépend de la richesse des donnés et de la complexité du modèle. Souvent, le modèle est complexe, et on préfère des réseaux convolutifs à la place de modèles linéaires simples. La formation de ces modèles dépend de la qualité des donnés d’apprentissage. Une attaque classique consiste par exemple à introduire une attaque dans le jeu de donnés d'aprentissage, ou d'habituer le système au comportement déviant s'il s'agit d'un modèle à aprentissage continu.  Autre attaque, l'évasion de modèle: il s'agit là de modifier la forme de l'attaque pour échapper aux critères de classification. C'est le cas typique du SPAM, ou l'attaquant essaye de faire passer son e-mail pour légitime en diluant les caractères sur lesquels l'algorithme prends ses décisions.  Autre exemple la génération d'une image altérés pour tromper la classification. Une bonne attaque par évasion de modèle consiste à limiter la perturbation apporté à l'information pour qu'elle échappe à la classification mais aussi à l'oeil humain.

    La transférabilité d'une attaque consiste à  la probabilité qu'une attaque réussie sur un modèle A fonctionne sur un autre modèle. L'orateur à travaillé sur des pdfs malveillants & sains et à généré des attaques pour des algo SVM & Random Forest.



    0

    Ajouter un commentaire

  7. Social facile, réveil difficile ;)

    Edit: retours & blogs du SSTIC sur:

    A practical guide to DPA

    Milenage est un algo qui sert à dériver les authentifiants dans les cartes SIM. C'est grâce à ca que le téléphone peut s'authentifier sur le réseau de l'opérateur. Si un attaquant peut faire cracher ses secrets à la puce, l'atteinte en confidentialité est énorme pour l'utilisateur. Pour ce faire on peut effectuer une analyse des variations de consomation sur certaines pattes de la puce à l'aide d'un oscilloscope. On identifie alors les phases d'exécution de l'algorithme. On part de traces de références qui ne sont pas toujours très propre car l'horloge de la carte n'est pas super précise. On doit alors ré-aligner les pics afin d'avoir une base de comparaison propre. Sur la base de l'hypothèse que la donnée influe sur la consommation. Il faut un très grand nombre de traces pour valider l'hypothèse. L'attaque se fait avec un oscilloscope a 400€, et des scripts python NumPy.

    Starve for Erlang cookies to gain remote code execution

    Rappels sur le fonctionnement de la vm Erlang, faite pour partager des messages entre les process tournant dans des vm séparées. Ces échanges se font sur TCP/IP. L'Epmd indique à la vm sur quel port un process écoute. Une authentification mutuelle se fait par un challenge-response basé sur le Cookie Erlang. Une fois le canal établi, des messages sérialisés sont échangés. Le problème c'est que ce canal n'est pas protégé en intégrité. RabbitMQ est facile à identifier avec nmap et le script epmd-info. Pour eJabberd, l'orateur à codé un script NSE spécifique. CouchDB n'expose pas de service par défaut. Les cookies Erlang font 20 lettres majuscules, ça ne se bruteforce pas comme ça. Sauf que la graine utilisée ne fait que 64bits. L'état interne du prng fait 36 bits ce qui rend la génération de cookie bruteforçable.

    Dans la conf RabbitMQ, le cookie_hash est un hash en base64 du cookie Erlang, facilement récupérable par bruteforce. La distribution des graines n'est pas cryptographiquement bonne sur RabbitMQ. L'intervale fait pas plus de 2^26bits, bah ça défonce.

    Une fois le cookie trouvé, on à une RCE sur la VM Erlang. Du coup la distribution Erlang doit être faite en utilisant SSL, et par défaut RabbitMQ n'est pas sécurisé. Pour se protéger, il faut mettre du TLS sur la distribution des messages, remplacer le cookie généré par le votre.

    HACL: une bibliothèque crypto formellement vérifiée

    (ouch) Bon, on ne peut pas tout vérifier avec du fuzzing sur une lib crypto, du coup les orateurs sont partis sur les approches formelles. Pour coder des fonctions crypto, on peut soit faire de l'ASM, soit faire du C, soit utiliser un langage avec preuve intégrée mais c'est pas performant. Les orateurs ont donc choisi de créer une nouvelle lib crypto écrite en F* (https://github.com/mitls/hacl-star). La lib est toute petite mais elle implémente l'API de NaCL et une suite TLS 1.3. Comme c'est du F* la preuve est "offerte". F* ça ressemble à OCaml avec des types plus riches et la possibilité d'ajouter des annotations pour exprimer ce qu'on espère que ça fera, et les backend de preuves viennent vérifier tout ça. Une fois le code F* propre, il faut générer du C clean. Pour se faire les orateurs ont choisi un sous-ensemble de F* nommé Low* et qui permet de générer un C prouvé. La compile de Low* vers C se fait par un compilateur C vérifié. Le code C à été validé à la main en // de la preuve automatique. Côté perfs ça poutre, mais en prime c'est passé par des méthodes formelles (j'suis en PLS là...).

    WireGuard: next generation secure network tunnel

    Jason Donenfeld - zx2c4 - Il voulait faire un VPN qui permet d'éviter tous les éceuils qu'on peut connaitre avec IPSeC, OpenVPN, etc... WireGuard est un vpn niveau 3 pour IPv4 & v6 conçu pour être builtin dans le kernel linux. Basé sur UDP pour passer les NAT et autre trucs, et qui utilise de la crypto classique & nouvelle, mais pas de truc trop exotiques. Le projet se veut super simple et auditable. L'échange de clefs est sorti du projet, mais son modèle d'authent est très similaire aux authorized_keys d'SSH. (https://www.wireguard.com/)

    WireGuard ne fait que 3771Loc, contrairement aux projets comme OpenVPN ou StrongSwan qui dépassent allègrement les 100kLoC. Ce qui simplifie grandement l'audit de code. WireGuard apparaît comme une interface traditionnelle, et tout ce qui marche "classiquement" avec une interface réseau classique marche avec WireGuard. Au lieu de galérer comme en IPSec avec une table de routage de la mort, l'orateur est parti sur l'utilisation simple d'une interface réseau "standard".

    Le routage se fait en fonction de la clef crypto associée à l'interface. Chaque pair dans le réseau wireguard est identifié par sa clef publique. On à donc une relation 1:1 entre l'IP dans le vpn et la clef associée à l'interface réseau. Côté client on peut choisir quels sont les réseau "atteignables" dans la conf. Le routage est fait dans la table du kernel linux.

    La création des clefs publique & privés se fait très simplement, et pour l'échange de clefs, on fait du copier-coller. Pour l'usage au quotidien, on peut utiliser des namespaces pour isoler les process du réseau et faire en sorte qu'il passent uniquement par Wireguard. Le fonctionnement de WireGuard est basé sur une machine à état avec des timeout, et l'évolution de cette machine se fait par les événements de réception de paquets. Concernant les suites cryptographiques, au lieu d'embarquer une tétrachié d'algo crypto, la suite est fixe, et si jamais un de ces algos casse, vous allez mettre à jour tout les noeuds, inutile de laisser des noeuds non-safe dans votre réseau. Le protocole à été vérifié à l'aide de l'outil Tamarin ( https://tamarin-prover.github.io/ ?) et assure toutes les propriétés de sécurité qu'on peut désirer sur un protocole d'échange crypto. (segfault: too much crypto).

    ça sent le SAPin

    Sécurité de SAP - devoteam & onapsis - SAP c'est un progiciel de gestion énooorme avec touplein de composants et de langages maisons ou pas. SAP c'est le leader mondial des ERP, et la boite existe depuis 46 ans. 72% des bières du monde sont produites par des entreprises utilisant SAP, c'est presque un OIV. L'application s'utilise au travers d'un client lourd appellé SAP Gui, qui cause avec un ABAP Dispatcher qui répartis la charge sur des WorkProcess qui causent avec la base de données. Et ça expose une tétrachié de services, du coup le Nmap il pique un peu.

    Le service SAP est identifié par 3 lettres,  les admins sont identifiés par le trigramme adm. l'ABAP est le langage de programmation de SAP et il est stocké dans la BDD. Un report c'est un programe ABAP. Une transaction, c'est un alias qui lance un ensemble de Report. Les services SAP tournent sur sidadm, il n'y a pas d'isolation de privilèges et si vous le pétez c'est game over. Le kernel SAP c'est un gros tas de binaires qui tournent sur l'OS. Le source ABAP dans la base de données pour s'abstraire des OS. Du coup tout le code du système SAP est accessible, donc auditable. L'installation d'un système SAP implique le déploiement d'un environnement de dev complet.

    Le SAP GS: Internet Graphics SErvices, est là pour générer des images, des graphiques, des fichiers zip, etc... Comme aucune CVE n'a été publiée sur le SAP IGS, les orateurs se sont dit que personne n'avait regardé.  Quand on joue sur l'interface graphique, on découvre sur l'os la création dans /tmp/ de "sap stream" avec touplein d'infos. ces streams sont passés à des binaires  non strippé, ce qui facilite la rétroconception. En rejouant des paquets IGS sur les ports qui vont bien ,on déclenche les binaires de traitement qui vont bien.

    Les orateurs ont développé pySAP a base de scapy, et du coup on peut crafter des paquets IGS pour aller déclancher les fonctions qui nous intéressent. Les orateurs ont aussi contribué à un plugin WireShark pour décoder du SAP-IGS.

    Une fonction à attiré l'attention des orateurs: ADM:INSTALL, en bouffant le code ABAP, ils ont découvert une fonction SAPMAP_INSTALL_SHAPEFILES qui vérifie si les shapefiles manquent à l'IGS et s'il faut les uploader. Bon coder de l'ABAP c'est galère, mais le debugger SAP vient à la rescousse des auditeurs. En jouant avec la fonction, ils ont trouvé un moyen de créer des fichiers arbitraires sans authentification => et paf la CVE.

    Dans les coulisses de la security team de debian

    Par un des membres de la team sécurité Debian, et qui va présenter comment ça se gère au quotidien les vulns dans Debian. L'équipe sécu compte 10 personnes dont 5 très actifs. Ils s'appuient sur les devs des paquets debian. Ils gèrent la release d'avis de sécurité et de packages de sécurité pour patcher les vulns pour la release stable. Ils regardent aussi comment durcir la distribution. Ils ne traitent pas la partie sécurité de l'infra Debian, comptes, etc.. ni la LTS.

    La communication avec l'équipe sécu se fait avec l'@ security@debian.org, ils ont aussi un irc. Ils ont un security-tracker qui permet de naviguer dans l'état de la distribution pour connaitre l'état courant de la sécurité de la distribution. (https://security-tracker.debian.org/). Ce tracker est un repo git ouvert, quand les vulns sont sous embargo, c'est géré sur un git privé. Une partie de la veille est automatisée pour collecter les CVE, les ajouter a la liste et vérifier si Debian est concerné ou non. (détails du process dans les slides).

    Les embargos, c'est pas tjs bien, parce que les patchs sont moins relus, il y a moins de monde à bosser dessus, alors l'équipe tente de limiter au maximum le traitement des vulns de ce type car c'est plus long.  Pour krak ça s'est très bien passé, ils ont pu remonter un env pour tester la validité des patchs sur hostapd & cie. Pour meltdown & spectre, l'équipe était pas dans l'embargo et n'a pas pu se préparer, du coup c'était galère.

    Conclusion: l'équipe ne gère que le maintien en condition de sécurité et la gestion du tracker, et toutes les vulnérabilités ne se valent pas, d'ou les différences de traitements.

    Hacking harness open-source

    L'anti-forensic, c'est un objectif des attaquants type APT que tente de simuler les RED Team. Quand on regarde les outils leaké de la NSA ils ont 4 framework d'effacement de traces. L'autre solution c'est de ne pas générer de logs. "le hacking c'est un concours de boulettes, celui qui en fait le moins à gagné". Exemple avec un shell sans TTY qui lag, source de nombreuses fautes de frappes. Ces problèmes ont été présenté par thegruq et expriment la nécessité d'avoir un "hacking harness" pour éviter ça. Démo de l'outil qui prévient le pentesteur lorsqu'il oublie de proxifier une commande.

    Le hacking harness, c'est un shell augmenté pour automatiser les tâches ordinaires du pentest, avec le comfort d'un TTY. C'est facile à scripter pour que chacun puisse adapter ses méthodes de travail au harness, plutôt que d'avoir à se conformer au workflow d'un autre.  Autre intérêt, toute l'intelligence est sur la machine du pentesteur/redteamer. La ligne de commande est gérée en local jusqu’à-ce que l'utilisateur fasse entrée pour l'envoyer au travers du shell. ( https://github.com/JusticeRage/FFM )

    DNS Single point of failure

    Un resolver DNS chez un FAI reçoit les requêtes DNS, et va en suite demander aux serveurs racines, mettre en cache les infos et voila. C'est le cas autoroute, et ça se passe bien parceque les serveurs racines contiennent toutes les infos. Dans la pratique, parfois, il n'y a pas toutes les informations nécessaires, et dans ce cas on rajoute de la glue. Sans glue, ça demande au resolver DNS de dérouler l'ensemble de la chaîne jusqu'a trouver le bon serveur DNS. Le soucis c'est que 99% des resolveurs n'utilisent pas la Glue, et du coup ça génère bcp de traffic. La bonne nouvelle c'est qu'actuellement, le nombre de serveurs qui contrôlent les TLD est assez compact et ça se passe bien. Bon la glue c'est pas forcément simple à maintenir, parce qu’il faut mettre à jour cette glue.

    Bon la délégation sans glue ça bouffe de la perf, et en prime ça pose un problème d'intégrité si les serveurs les plus fréquemment requêtés sont détournés. Du coup on peut se poser la question de quels serveurs sur ces chemins de résolutions représentent un point de passage obligé dans la résolution d'un grand nombre de noms de domaines.

    Des IP qui tombent c'est fréquent, DDoS, fausse manip, oups. Un préfixe réseau peut être mal annoncé et foutre le boxon, plus rarement les AS peuvent tomber. Autre élément de risque, quand un nom de domaine devient non-disponible à cause d'un DDoS, d'une zone tronquée, couac DNSSEC parce que c'est compliqué, de l'interruption administrative, bref. ça arrive !

    Là ou ça devient critique, c'est si un de ces événement surviens sur un serveur DNS qui s'avère être un SPOF, ou lorsqu'on à un effondrement par dépendances transitives. Bon parfois on peut avoir des dépendances circulaires, et ça peut mal finir.

    C'est galère à analyser à la main, du coup l'orateur à développé un outil nommé transdep ( github.com/X-Cli/transdep ) en Go et qui marche un peu comme un resolver. Il va aller crawler plein de donnés DNS pour construire ce graph de dépendances entre domaines.

    Tout nom de domaine est dépendant de ses parents, tout le reste est évitable. Quand on regarde bien, il y a un très grand nombre de noms de domaines qui dépendent d'élément "évitables" et qui sont donc exposés à un SPOF.

    Pour éviter ces problèmes, il faut suivre les bonnes pratiques du guide de l'ANSSI.

    0

    Ajouter un commentaire

  8. Audit de sécurité d'un environement Docker
    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...
    Machines virtuelles protégés
    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.
    Pycrate: outil d'audit de systèmes telecom
    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 !
    ProbeManager: Centralisation de gestion de sonde de détection d'intrusion
    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.
    Easy TLS for Everyone - Integrating LetsEncrypt at scale
    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
    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. 
    Hardening JavaCard Implementation
    (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)
    Conception du Challenge SSTIC
    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.
    Solution du Challenge SSTIC
    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. 
    RUMP Session
    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.
    SSTIC Quiz
    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.
    pourquoi c'est flou net
    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...
    Docker explorer
    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.
    Nordic made easy
    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.
    Le problème de l'IOT
    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, dis-moi qui est la poublelle ? - Onyphe
    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.
    LFI à Administrateur du Dom'
    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.
    Little bobby tables uses my website.
    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.
    Invite de commande pour la toile dans un langage souverain.
    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).
    Comment louper sa réponse à un CFP
    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é.
    Suricata et les moutons
    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.
    ipibackup: backup charger for your iphone
    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
    Représenter l'arborescence matérielle
    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 dans le monde.
    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.
    ARM_NOW
    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).
    sshpki.py
    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
    Smashing the func for SSTIC and profit
    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.
    Wookey: le retour du jeudi.
    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)
    modmobjam
    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)
    ...
    0

    Ajouter un commentaire

  9. C'est parti pour cette nouvelle édition du SSTIC, avec comme nouvautée cette année un amphi de 800 places dans le couvent des Jacobins. Les barbus & sweat à capuches sont venu en nombre, et je n'ai croisé que deux personnes en costard perdu dans l'assemblée.

    Keynote d'ouverture  - Halvar Flake

    2x speaker à SSTIC, Thomas Dullien "Halvar Flake" va nous faire une retrospective sur le reverse-engineering tiré de ses expériences. L'outillage à bien changé depuis ses débuts, et maintenant que ça fait 20 ans qu'Halvar utilise IDA, il se considère comme "vieux".
    IDA n'a pas des masses changé en 20 ans, et ça reste son outil préféré pour faire du reverse-engineering. Après 13 ans de RE, Halvar à fait un break de 6-7 ans pendant lequel il a managé des équipes de dev et de sécu. Il s'y est remis, et voila ce que ça fait:
    Beaucoup de choses ont évolué: les solveurs sont devenu utilisables pour générer des entrées pour des programmes, plein d'outils de RCE ont fait leur apparition: r2, frida, Angr... Bref il semblerait que plein de problèmes d'il y à quelques années soit résolus. Du coup reverser du C++ devrait être plus simple non ? Ben en fait, quand tu l'essayes sur des cas réels, bah ça marche pas (échec ?). Exemple avec MPENGINE.DLL dont il est difficile d'obtenir des traces de couverture. Le live debug sur les systèmes mobile sont galère à obtenir, etc...
    Pourquoi ça ne marche pas très bien ? Certaines raisons sont externes à la communauté du reverse, d'autres sont liés au fonctionnement de cette communauté. Les fournisseurs de plateformes (iOS, Android, etc...) sacrifient très vite la "débuggabilité" pour freiner le reverse à diverses fins de "sécurité" mais qui en fait privilégie les "gros" acteurs offensifs (gamma group, nsa, etc...) qui ont les moyens de les péter, là ou les défenseurs qui n'en ont pas les moyens sont à la traine.
    Exemple avec iOS, ou il faut mettre en place des hacks complètement débiles et coûteux pour pouvoir déboguer une application correctement. Souvent on conseille aux constructeurs de supprimer le JTAG, alors que l'attaque physique ne fait pas parti du threat-model. Du coup on perd en observabilité, et on ne peut pas mettre simplement en place des moyens d'analyse et d'investigation dans ces devices.
    Quand on augmente le seuil d'accès au debug sur un device, ont diminue la population capable de travailler sur sa sécurité, et du coup cela maintient la rentabilité des exploits pour les attaquants au long terme. Pour résumer: moins de hackers = un durcissement de la plateforme plus lent, ce qui fait le jeu des attaquants.
    Le time-to-market à forcé les developpeurs à "compresser" les temps de dev, déploiement & tests. Du coup il est fréquent qu'ils travaillent sur des devices pas finis, et pas très debuggables, ce qui complique le diagnostique des défauts de ces applications, et donc leur sécurité.
    Le marché pour des produits de reverse est très petit, et du coup permet à peine de soutenir correctement entre 12 et 60 ingénieurs dans le monde. Le coût "technique" de conception d'outils de reverse n'est pas récupéré par les ventes du fait de la petitesse du marché des outils de reverse, ce qui complique la rentabilité d'entreprises focalisés sur l'outillage du reverse-engineering. Sans compter que les reversers sont loin d'être de bon développeurs. Souvent des petits scripts tous-pourris écrits à la va-vite deviennent des outils utilisés sur le long terme à défaut d'autre chose. C'est cool de réussir des reverses complexes avec des outils de merde, mais quand on vieillit, on aimerait avoir des outils robustes et professionels. Le problème c'est que la communauté du reverse code pour terminer le taff, et ne prend pas le temps de penser à l'avenir et d'investir dedans. Par exemple, on ne fait pas attention à l'empreinte mémoire des scripts, ou encore à la capacité de distribuer ces calculs sur plusieurs noeuds.
    Côté logiciels, un grand nombre de frameworks ont des fonctionnalités similaires, mais ne couvrent pas touts vos besoins en reverse, et certains sont loin d'être stable ou efficaces au niveau cpu/mémoire. "On dirait la communauté JavaScript" tellement il y a de trucs fait en double ou en triple sur X frameworks. Sans compter qu'ils sont parfois développés à coup de deadlines de conférences. Sur le papier, beaucoup de problèmes ont été "résolus", mais en réalité, pour un travail quotidien, ces outils sont loin de tenir leur promesses.
    Côté publications: les résultats sont rarement reproductibles, les données ne sont pas disponibles, et la publication des sources n'est pas systématique. De plus à la lecture d'un papier on n'arrive plus à distinguer si l'auteur exagère, ou si le problème à bien été résolu correctement.
    Côté outillage, on n'a pas de distribution ou de framework stable orienté reverse engineering.
    L'outillage du reverse engineering est très focalisé sur le code source et la récupération de ce dernier, mais peu sur la compréhension de l'ensemble logiciel que constitue l'outil que l'on reverse.
    Fin des critiques, voici quelques propositions constructives: Il faut que les développeurs de plateformes logicielles/matérielles les rendent débuggables pour faciliter l'analyse. Il faudrait trouver un moyen d'échanger les données de reverse-engineering de façon standard pour qu'on puisse échanger les outils pour passer du binaire à l'assembleur, de l'assembleur au CFG, etc... Il faudrait des représentation intermédiaires standardisés adaptés au différentes données utilisées et générées par les outils de reverse. Ainsi, on pourrait passer "simplemement" d'un outil à l'autre sans avoir à re-développer tous les scripts & outils existants pour ce nouveau framework.  Une distribution Linux pour le reverse comme il en existe pour le pentest, sur laquelle on pourrait avoir tous les outils nécessaires & interopérables afin de faciliter l'échange d'outils sur cette base. Afin d'améliorer la fiabilité des outils de reverse, il faut des données sur lesquelles tester et valider le fonctionnement des outils de reverse.
    Les choses changes avec le Cloud, et maintenant n'importe quel logiciel n'est un tas de petits bouts de code qui tournent sur plein de machines un peu partout dans le monde. On est passé d'un monde ou les OS était fermés et non accessible à un monde et on déboguait sur un seul hôte. Maintenant le debug dans le cloud est un cauchemar car on à pas de "Cloud debugger" permettant de gérer un système si éclaté. L'éclatement des types d'infrastructures CPU/GPU/µC/FPGA présentent un sacré défi pour les outils de reverse. Sans compter qu'on aura peut-être dans le futur à reverser les poids des réseaux de neurones intégrés dans nos appareils pour comprendre ce que font ces composants spécialisés. Le hardware va se spécialiser, et on ne peut pas s'attendre à ce que ces composants soit bien documentés. Une vulnérabilité sur ce type de composants va être très compliqué à gérer pour les défenseurs (ex: spectre/meltdown ...).

    Backdooring your server though its BMC: the HPE iLO4 case

    Une présentation courte sur le ponçage du système iLO4 HP. C'est très répandu chez pas mal de fabriquants de serveurs sous la forme d'un chipset autonome et indépendant du système principal sur base ARM, avec sa propre RAM et sa propre interface réseau. Ce système démarre dès que le serveur est alimenté électriquement.  Souvent en pentest, ces iLO sont exposés sur les VLAN de production, et certains sont même en frontal sur internet. Un premier exploit leur permet d'aller récupérer des informations en mémoire sur le système managé par l'iLO et d'y écrire du code arbitrairement afin d'obtenir un shell via netcat sur le serveur principal. (https://recon.cx/2018/brussels/talks/subvert_server_bmc.html) Le service web de l'iLO fait l'objet de deux CVE depuis un an. Il fait un usage massif de scanf pour parser les headers HTTP (ça ne peut que bien se passer en C...). Il y a quelques buffer overflow dont un dans le header Connection qui permet d'écraser une variable permettant de bypasser l'authentification et d'accéder à l'API REST du iLO.
    A partir de cette RCE, les orateurs ont bossé sur le firmware iLO pour patcher le bootloader, pour en suite patcher le noyau et insérer une backdoor userland dans la flash de l'iLO. Le serveur web à été choisi comme cible pour installer la backdoor vu qu'il dispose de toute les primitives de communication, et qu'en plus il à un accès DMA à la mémoire de la machine principale.
    Pour installer la backdoor dans le système linux, il faut créer un thread dans le noyau, allouer de la mémoire pour le canal de com iLO <-> Linux, et mettre en place les primitives d'exécution des commandes reçus sur le buffer mémoire. Pour que la backdoor du serveur web fonctione, les orateurs ont du patcher un bug dans ce dernier.
    Comment faire pour savoir que son iLO est compromis ou pas ? bah tout simplement en utilisant la vuln pour aller dumper la flash du iLO, et comparer si les hash du firmware correspondent ou non à des serveurs connus.
    T-Brop - Taint-based Return Oriented Programming
    Dorat - Développement orienté sur la teinte.
    Petit retour sur l'exploitation d'une vulnérabilité type buffer overflow, avec les protection qu'il faut contourner en re-utiliser le code existant dans le binaire. Pour ce faire on va réutiliser des petits bouts de code aka gadgets, ces gadgets se terminent souvent par un ret (d'ou le ROP). Le DEP ça suffit pas, il faut aussi utiliser du CFI, etc... Bon quand il s'agit de chercher des gadgets, soit les outils vont faire des grep dans le programme (rp++), soit ils font ça en symbolique mais c'est super coûteux en temps(angrop). Afin d'optimiser ça, les orateurs proposent une approche hybride qui soit plus rapide que l'analyse symbolique, et plus expressif que les approches syntaxiques. Du coup on à un entre-deux moins performant que le syntaxique mais plus rapide que le symbolique. Avec RP++, on se galère à construire notre ropchain à la main en greppant les gadgets qu'on veut.. Avec angrop, il commence par râler parceque le binaire est trop gros, et du coup il passe en "fast mode" ou lorsque le gadget est trop compliqué, il le jette, et ça prend 15 min. T-Brop est un peu plus rapide (7min) et propose quelques gadgets intéressants basés sur rsp & esp, ou sur des données un peu au dessus de la pile.  Pour conclure, Angrop c'est bien pour les cas autoroutes, RP++ c'est pour les pro de la regexp, et T-Brop propose parfois des trucs chelou mais originaux.
    Comme indiqué dans le titre, T-Brop se base sur de la teinte pour gérer quel registre dépend de quel autre dans l'enchainement des gadgets. Cette influence se représente sous forme de matrices de dépendances pour chaque gadget. Pour savoir quel impact à l'enchainement de plusieur gadgets sur les registres, il suffit de faire un produit matriciel. En généralisant ce principe, il est possible d'identifier s'il est possible ou non d'influencer tel ou tel registre en enchainant un nombre arbitraire de gadgets, et quels registres il faut contrôler pour pouvoir utiliser la ropchain. L'implémentation se fait à base de python3 avec capstone + scipy + numpy. Le "throwaway script" et disponible sur github (https://github.com/DGA-MI-SSI/T-Brop)

    Certificate Transparency - Assurance Maladie

    Comment ce nouveau standard permet d'améliorer la veille face aux menaces. La certificate transparency vise à couvrir le risque d'une AC malveillante ou piraté qui signe un certificat sur un domaine wildcard pour lequel il n'a pas l'autorité. Du coup lorsqu'un MITM survient, le petit cadenas vert est tout de même présesent, et l'utilisateur se sent faussement en sécurité. C'est une initiative de Google repris par l'IETF qui force les AC à consigner les certificats qu'elle signe dans un registre ouvert à la consultation. Les navigateurs du coup vont venir contrôler la validité du certificat dans les journaux et viennent positionner une alerte à l'utilisateur si jamais le certificat présenté n'est pas dans les journaux des AC. A l'aide de la certificate transparency, l'assurance maladie à pu mettre en place un monitoring de l'ensemble des certificats émis. Ce qui permet d'identifier les tentatives de MITM, ou encore l'émission d'un certificat dans un sous-domaine sans passer par la DSI (code de monitoring dispo sur https://github.com/assurancemaladiesec ). En surveillant l'apparition de certificats pour des noms de domaines similaires ou proches de celui de l'organisation on peut voir venir les tentatives de phishing. C'est low-cost et efficace (merci à eux d'avoir publié leur outil)

    Signaux parasites comprométants

    Les orateurs sont des membre d'un labo de l'ANSSI qui bosse sur le TEMPEST. Dans les signaux radio sans fil, il y a les signaux volontairement émis (radio, wifi, bt, etc...), et les signaux radio émis à l'insu du système. Par exemple les écrans cathodique d’antan qui générait un rayonnement qui pouvait être décodé au loin à l'aide d'une antenne. Bon avant, c'était galère et il fallait du gros matos, maintenant avec la radiologicielle (SDR ftw), il faut un piti dongle avec une pitite antenne pour capter ces signaux. Bien que les cathodiques ont disparu, il y a pas mal de composant qui émettent à notre insu, nottament les câbles vidéo entre ordi & écran. Petite démo avec tempestsdr, outil radiologiciel pour recomposer ce type de signal, dont la principale difficulté d'utilisation réside dans sa compilation... Et du coup l'orateur intercepte le signal de son propre laptop de présentation. Le VGA décompose chaque couleur dans un fil, avec les pixels géré en fréquence, et l'intensité lumineuse en... intensité :) Pour le DVI, ils ont fait grosso-modo comme le VGA. Et pour HDMI, ils ont fait comme pour DVI... le son est transmis dans l'image à l'emplacement de la marge. Le signal parasite est généré lorsque l'intensité du signal change, et du coup à chaque pixel ça émet une onde radio. Plus la variation de potentiel est rapide, plus le rayonnement est fort. En VGA, ça va pas vite, donc les fronts sont plus mou, et le rayonnement est plus faible. En DVI, la fréquence est rapide, et les changement de fronts forts, du coup ça rayonne plus, et il ne reste plus que le blindage pour vous sauver. Le blindage doit être complet, s'il y a un trou, bah ça fuite, et votre écran avec. Le problème c'est que la qualité des cables est très variable, Si le capot métallique n'est pas connecté a la tresse métallique du cable bah c'est foutu. Les cables fournis par les constructeurs avec un équipement neuf sont plutôt bons car ils réspectent les normes, alors que les cables individuels sont plutôt mauvais.
    A l'usage, il faut privilégier le VGA ou le DisplayPort au HDMI ou au DVI, les murs en métal plutôt qu'en pierre... bref c'est pas facile :)

    Télévisions connectés: DVB-T et Sécurité

    En gros une télé connecté, c'est un ordinateura avec un tuner TNT. Ya tout dessus, wifi, bluetooth, réseau, usb, HDMI. Parfois ces télé sont moins chères que des écrans, et sont souvent déployés dans des salles de réunion en lieu et place d'un vidéoprojecteur ou d'un écran d'ordi. Chaque chaîne qui émet, peut dans une zone donnée de la transmission, distribuer une application ou des fichiers à la télé. La HbbTV utilise ce flux d'information pour récupérer le contenu de l'appli interactive, ou bien une URI pour aller chercher l'appli ou ses ressources. Une appli HbbTV est en fait une page HTML avec une api JS spécifique. Pour éviter l'injection arbitraire d'appli HbbTV, le consortium DVB à ajouté des mécanismes de signature. Reste à savoir comment c'est implémenté ? Bah pas bien, du coup l'attaquant peut "dé-signer" une appli, ne pas signer l'appli, etc... La gestion de la confiance dans la norme se base sur des chaines de certificats, dont le certificat racine peut être fournis soit par une autorité de certification, soit inclu dans le flux DVB sous la forme d'un manager-certificate (fail!). Une "protection" temporelle est en place sur la validation des certificats, mais elle est contournable par l'attaquant modulo un peu de patience en diffusant le manager-certificate jusqu'à ce que la télé l'accepte. (Il est possible sur certaines télé de désactiver les fonctions HbbTV).

    Three vulns, one plug - Acceis

    Tout est parti de prises connectés en promotion lors d'une visite au magasin de bricolage du coin. Les "smart" plug fonctionnent en wifi avec une technologie d'appairage "smart" pas basée sur WPS, et sans moyen d'entrer manuellement la clef wifi du réseau. La configuration se fait via une application android, ou on entre le mot de passe du wifi, et paf la prise se retrouve connectée au wifi et apparait. Lorsqu'on sniff le réseau et qu'on regarde ce qui s'échange à l'envoi des information de sécurité, on voit passer des paquets wifi complètement random. Les messages sont envoyés vers des IP au pif, et les messages de broadcast sont constitué d'une série de messages de taille fixe, puis des paquets de taille variable qui viennent encoder la clefs du wifi à enregistrer sur la prise. Bref un gros CESAR en side channel via la taille des paquets. Quand on regarde la doc du module wifi, on se rend compte qu'il écoute en UDP, et qu'il accepte des commandes AT qui permettent de faire tout ce qu'on veut avec le module wifi au niveau config. Sur le hard, on à deux port UART qui permettent de récupérer la clef du réseau wifi directement. On découvre dans la doc qu'un mec à implémenté WPS sur le module wifi, mais c'est pas activé. via l'UART l'orateur à mis au point un patch pour activer WPS avec un arduino.

    Escape room pour la sensibilisation à la sécurité informatique.

    L'objectif de l'escape room est d'apprendre aux joueurs les bons réflexes en sécurité informatique et comment se protéger des attaques d’ingénierie sociale courants. Deux scénarios sont proposé, l'un visant à sécuriser un environnement de travail, et à trouver l'attaquant à l'origine de l'attaque. L'autre consiste en trois participants dont l'objectif est de voler des documents à une entreprise fictive. Le scénario dure 1h, et de nombreux éléments sont disponibles pour éviter l'ennui.

    Hacking BLE - digital-security

    La technique de base du hacking hardware, c'est de prendre un analyseur logique, on choppe un uart, et hop on à un shell. Bon c'est pas toujours comme ça. En pratique, il faut un peu de méthode. Comprendre le fonctionnement est essentiel, par exemple sur une serrure connectée avec 18h d'autonomie implique forcément l'utilisation d'une technologie basse énergie. Côté hardware, quand on regarde, il n'y a pas de protections électriques contre les surtentions sur le port USB, ou d'élément de repérage de la position du rotor de la serrure. Du coup le logiciel ne sait pas dans quelle position est la serrure. Côté chipset, on identifie rapidement un module BLE, un pilote de moteur. Pour comprendre les interconnexions, on peut utiliser un multimetre, on peut aussi étudier la doc du composant. Une fois les ports JTAG/UART/SWD identifiés, on peut aller tenter de récupérer le firmware pour pouvoir analyser les µLogiciels présents. On peut aussi récupérer les firmwares au niveau réseau ou sur le smartphone lors d'une action de mise à jour. (le syndrome de l'écran noir frappe l'orateur ;( http://blog.eavs-groupe.com/guides-et-dossiers/guide-hdmi-comprendre-ledid-et-le-hdcp-pour-eviter-lecran-noir/ ). Quand on regarde le code, on découvre que la partie authentification de la serrure est complètement cassée. l'orateur présente un man in the middle bluetooth qui lui permet de capturer le jeton d'authentification, et de le rejouer à volonté.

    Wookey: usb devices strike back

    Conception d'une clefs USB sécurisé chiffrante capable de répondre à une menace type BadUSB. Le tout pas trop cher et partageable en open-hardware/open-source. Dans le cadre de la norme USB, c'est le périphérique qui déclare ses fonctionnalités à l'OS. Si le périphérique ment sur ses fonctionnalités, l'OS n'a que d'autres choix que de faire confiance à la clef, c'est le scénario BadUSB. Côté solutions libres, pas grand chose de correct. L'orateur veux se protéger aussi contre le vol de données à coup de crypto, il faut donc un SoC suffisament solide pour permettre leur mise en oeuvre de façon sûre. L'utilisation d'un secure-element pour stocker les clefs de chiffrement, un clavier/touchscreen indépendant de l'hôte pour la saisie du code pin, un slot µSD pour acceuillir le stockage, et deux ports USB. Le firmware de la clef contient un firmware de boot, et un firmware de backup en cas de pépin. Une partie est reservée pour des éléments de signature crypto, et un mécanisme de mise à jour déclenchable par pression d'un bouton physique. Bien entendu, le JTAG à été désactivé. Chaque module logiciel gérant chaque fonction de la clefs doit bien entendu être isolé des autres. Les orateurs sont donc parti sur un micro-noyau léger et conçu pour un µC dès fois qu'un des composants se fasse compromettre. Comme ils n'ont pas trouvé leur bonheur, ils ont codé le leur, il s'appelle Ewok, et gère les modules applicatifs de crypto, usb, code pin, secure-element. Comment isoler sans mmu ? bah on utilise la MPU pour définir des droits et des attributs sur des régions mémoire. A l'ordonancement, il va jouer sur la conf de la MPU pour n'autoriser que la zone mémoire de l'appli qui va bien, et les seuls registres dont elle à besoin pour fonctionner. Lors d'un switch d'appli, le µNoyau reconfigure les droits d'accès via la MPU pour permettre à la suivante de fonctionner. Pour sécuriser les syscall qui représentent la seule surface d'attaque entre le code des appli et le µNoyau, les orateurs ont utilisé Ada et SPARK. Ainsi, en fonction de la sensibilité ou pas de telle ou telle fonctionnalité, les orateurs ont choisi le langage adapté, du moins restrictif (le C), au plus contraint (SPARK).

    Dump de flash sur circuit imprimé

    Quand on veut récupérer le contenu d'une flash, traditionellement, on va se brancher sur les pattes de la puce qui vont bien, et hop, on dump. Mais dès fois on tombe sur une puce dont les pin sont SOUS la puce, il faut donc désouder la flash, puis avoir le bon adaptateur ou se fabriquer le sien. L'orateur à décidé de fabriquer le sien. Il faut en suite re-souder la flash sur l'adaptateur, et on peut en profiter.  Sur une flash au format BGA, dans le cas d'illustration, il n'y avait que 8 pin sur les 24 qui était utilisés. A coup de kicad on conçoit son PCB. Méthode chimique avec du toner, du perclo et zou. L'autre technique c'est d'utiliser une CNC pour découper les pistes directement dans le cuivre, puis on ajoute une pâte isolante verte caractéristique, et hop on peut l'utiliser. Pour la soudure BGA à la main, il faut mettre chaque bille au microscope, et c'est très galère. On ressoude en suite la puce à l'air chaud.  Pour l'attaque hardware, on peut microsouder la chip "adaptée" sur le device d'origine. Il faut donc compter 1200€ pour les deux techniques, et un coût par pcb qui est lui négligeable. Si le BGA est grand, genre 64 billes, c'est l'enfer, du coup l'orateur est passé sur une CNC laser pour gagner en précision.
    1

    Afficher les commentaires

  10. RTF


    Le format rtf reprend les principes de html pour la mise en forme, avec un système de 'balisage' imbriqué, mais avec des accolades.  Plusieurs techniques d'obfuscation sont possibles pour virer les espaces, imbriquer a mort des propriétés, ou l'insertion de propriétés mortes.

    PWS


    Les password stealer sont vieux en terme de concept, mais très efficaces. Ce qu'ils volent le plus sont contenu dans les navigateurs web et les logiciels de messagerie. Ils sont autonomes, ne fournissent pas d'interactivité a l'attaquant (contrairement aux rats) et embarquent souvent un keylogger.
    Les stealers sont nombreux sur le marché noir et sont codés en .NET. Facile a utiliser, ils sont populaires chez les script kiddies. En plus il y a beaucoup de vidéos youtube qui expliquent leur usage.

    Nyetya et MeDoc

    Retour sur l'incident qui a touché l'ukraine et les entreprises qui avaient des filiales la bas. Talos fait de la threat intel, de l'analyse de malware etc....
    L'analyse a commencé avec un coup de fil disant que l'ukraine était tombé. Medoc s'est fait compromettre par leur site web, et leur appli .NET disposait d'un mécanisme de mise a jour qui a été utilisé pour propager un malware.
    Le malware nyetya vole les mots de passes, se propage via eternalblue et eternalromance, et chiffre le disque.

    Le vol de mots de passes se fait avec un mimikatz repacké.
     

    Math, gpu and dns : cracking locky seeds without samples.


    Les ransomwares sont un fléau, et une technique 'simple' et efficace pour les cybercriminels pour extorquer de l'argent aux victimes sous forme de bitcoins.
    Locky utilise un nom de domaine généré algoritmiquement - un DGA - a partir d'une  graine. Si on a la graine, on peut connaitre l'adresse du c&c a un moment donné. Le dns est calculé avec une fonction de hash. D'ou l'utilisation de cartes graphiques pour bruteforcer la graine.

    Hunting for attackers


    Une présentation sur les techniques employés pour les mouvements latéraux par les attaquants et les méthodes de détection utilisables en se basant sur les event logs. Les éléments du talk sont ici.

    Necurs Deliver


     Un retour sur les campagnes de spam ballancés par le botnet Necurs.  

    Think outside of the sandbox

    Android offre une sacrée quantité de dispositifs de sécurité: SELinux, sandbox applicative, trusted boot, (k)aslr, seccomp, etc... Ce talk va parler de la sandbox applicative. La sandbox est la pour empécher un spyware d'accéder aux données des autres applications, de déposer d'autres applications, permettre de savoir quelle appli à fait quoi, restreindre les privilège. Bref, c'est un composant essentiel de l'architecture de sécurité Android. 

    Advanced Threat Hunting

    La threat intel tactique consiste à apprendre les TTP des attaquants, La threat-intel technique consiste à connaître les outils des attaquants. Le processus classique consiste à collecter des données, puis à les raffiner pour obtenir des informations, et à les analyser pour obtenir de la threat-intel. Quand on regarde la pyramid of pain de D. Bianco on voit bien que changer certains hash, certaines ips c'est plus facile que de changer d'outils ou de TTP. Trouver le pattern d'attaque d'un outil particulier peut être compliqué à détecter (cf le talk du jpcert). L'orateur partage donc les process qu'il utilise pour faire tourner une équipe de 10 personnes autour de la threat intel.  Exemple avec la production de règles yara, ou l'analyste peut perdre pas mal de temps sur plein de conneries comme des copies de données etc... Bon parfois on fait des modif pourrie sur les règles Yara, et ça remonte trop de merde. Du coup c'est bien d'utiliser un truc genre GIT, pour pouvoir faire GIT Blame et découvrir qui à fait quelle modif.




    0

    Ajouter un commentaire

Chargement en cours