SSTIC 2020 - J1

Bon c’est parti pour une édition « streaming » du SSTIC 🙂 et c’est pas parce que tout est streamé que je vais me priver de le liveblogguer 😉

Pursuing Durable Safety for Systems Software

L’insécurité trouve souvent ses origines dans des langages peu sûrs comme C / C++ (php ?) etc… et malgré la progression de nos connaissances, le nombre de vulnérabilités découvertes dans les logiciels ne cesse d’augmenter. Peut-être parce qu’il est plus facile d’écrire du code non sûr que du code vulnérable. Bien sûr les techniques de confinement des vulnérabilités par les sandboxes et autres moyens de prévention de l’exploitation viennent durcir les systèmes. Le fuzzing, le SDLC, les moyens de compilation avec vérifications intégrés etc… tout ceci vient renforcer la qualité des logiciels, mais au détriment de la productivité des développeurs. Et comme la contrainte économique est forte sur les devs, si on ne rend pas la production de code sécurisé économiquement efficace, la partie est perdue.

De plus la complexité de l’assemblage des briques logicielles des applications modernes apportent un effet multiplicateur sur la surface d’attaque d’un logiciel.

Que peut-on faire lors de la construction de logiciels pour éliminer les vulnérabilités rapidement et à la source ? On peut rendre le code plus sûr à la création, mais ce n’est pas si simple. On peut s’appuyer sur des outils de vérification du code, mais c’est très dur à mettre en œuvre. On peut forcer l’emploi de fonctions ou classes sûres comme GSL::span, mais ça demande un effort supplémentaire de la part des devs. Et ce n’est pas la recherche qui manque sur le sujet, mais il n’y a pas beaucoup d’outils simple à mettre en œuvre pour les équipes de développement.

Une autre solution consisterait à faire migrer les devs vers des langages plus sûrs comme Rust, C#, etc… Le gros avantage c’est qu’on vient tuer des classes entières de vulnérabilités inhérente à C/C++. Ces langages fournissent des moyens de désactiver ces sécurités, mais du coup ça devient une action intentionnelle du développeur et c’est plus dur pour lui de produire du code vulnérable. Mais parfois pour du code noyau ce n’est pas toujours possible, on se retrouve alors à utiliser C/C++. La réécriture d’un code existant dans un langage plus sûr n’est pas simple, mais ça paye au long court.

L’approche hardware pour sécuriser le logiciel peut s’avérer intéressante. Le marquage mémoire [MTE] permet de se prémunir contre les manipulations de pointeurs en contrôlant la validité des pointeurs au niveau hardware. CHERI est une autre approche qui permet de se prémunir des accès non contrôlés à la mémoire provoqués par les erreurs de manipulation de pointeurs. Il s’agit d’une architecture hardware pour les pointeurs complètement nouvelle qui peut avoir un impact non négligeable sur les noyaux et les compilateurs pour être prise en compte.

La sécurité et la sûreté logicielle est un objectif à long terme nécessaire qui doit être traité par le collectif des développeurs & experts en sécurité, et les moyens sont là.

Pivoter tel Bernard, ou comment monitorer des attaquants négligents

Quand on traite un incident de sécurité ou une alerte virale chez un client quand on est éditeur d’anti-virus, on va chercher à en connaitre un maximum sur l’infrastructure qu’utilise l’attaquant. Pour ce faire on va traiter des IoC présentes dans le malware. Clefs de registres, adresses IP et autres variables peuvent ainsi être collectés et recherchés sur VirusTotal à l’aide d’une règle Yara pour trouver des variantes du malware. Comme beaucoup de devs les auteurs de malwares peuvent copier-coller github ou stackoverflow pour développer. Par exemple les éléments d’initialisation d’une fonction cryptographique peuvent être retrouvés sur Internet.

Les métadonnées PE contiennent des informations parfois utiles pour mettre en relation (pivoter pour les pro) un binaire avec d’autres. Exemple avec un attaquant qui utilisait des noms des mutex avec des noms uniques.

Les IPs et noms de domaines peuvent aussi servir à pivoter, mais il faut se méfier des infrastructures mutualisés qui peuvent être utilisées par différents groupes d’attaquants à des intervalles de temps différents. C’est quelque-chose dont les attaquants sont conscients et utilisent communément des hébergeurs peu regardants. Les certificats TLS, les métadonnées web, les relations DNS/IP etc… tout ces éléments techniques peuvent servir de pivot pour remonter à d’autres instances de l’infrastructure de l’attaquant.

En tant qu’éditeur d’AV, si la télémétrie est activée, l’éditeur va pouvoir collecter des méta-données sur les binaires, les connexions réseau etc, ce qui permet parfois d’identifier des campagnes d’attaques en cours chez des clients.

C’est l’ensemble de ces pivots et faisceaux d’indices qui va faire que l’éditeur attribuera à tel ou tel groupe l’activité de l’attaquant. Parfois les fonctionnalités du malware peuvent aider les analystes de l’éditeur d’AV. Exemple avec un malware qui utilise DropBox avec une clef d’API ré-utilisable par l’éditeur pour récupérer l’ensemble des fichiers déposés sur DropBox par l’attaquant. Dans ces fichiers l’analyste à pu récupérer une variante du malware qui utilise uniquement DropBox comme C&C.

Potentiellement l’attaquant va surveiller les publications des éditeurs et modifier ses TTP en conséquence pour échapper aux techniques de pivot publiés par les analystes.

Quand les bleus se prennent pour des chercheurs de vulnérabilités

Bon quand vous avez un SI et qu’on vous annonce une grosse vuln comme bluekeep, l’état de votre SI est inconnu. L’orateur fait donc un parallèle avec la physique quantique car le système se retrouve sûr et non sûr à la fois. En regardant ce qui se faisait dans la physique quantique l’orateur y dresse un parallèle. Pour lever le doute sur l’état du système il faut s’intéresser à la méthode de mesure qui permettra de lever le doute.

L’orateur c’est donc orienté vers ETW et à ajouté à Wireshark un plugin pour analyser les sessions ETW associés à RDP. Ensuite il est allé chercher dans les binaires la partie ETW les évènements pertinents liés à l’exploitation de la vulnérabilité. Pour ce faire il a écrit un plugin IDA.

Sécurité du réseau fixe d’un opérateur : focus sur les dénis de service

Chez un opérateur, on a plein de trucs qui tournent au niveau réseau… c’est une sacré infra, 12 millions de prises réseau pour les box de l’opérateur. Le cœur de réseau est un ensemble de routeur IP/MPLS sur lequel vont circuler les données des abonnées et qui est interconnecté avec les autres AS.

Du coup le déni de service c’est la menace majeure, que ça soit lié à un botnet ou à un coup de pelle d’une mamie georgienne. Bon les attaques yen a moins ces temps ci, mais elle sont beaucoup plus grosses en terme de volume.

Dans la famille des attaques DDoS, on a les attaques par amplification qui consistent à utiliser des protocoles qui pour un paquet grosso-modo en répondent plus d’un paquet et qui permettent d’envoyer les paquets vers une cible. Ces attaques sont connues et référencées par le CERT US. L’opérateur va donc chercher à réduire l’effet de ces attaques sans bloquer le trafic légitime. Les filtrages se font sur les routeurs de cœur de réseau ou on va pouvoir définir le protocole source de DDoS, et y affecter un débit max pour lisser la charge.

Les attaques dynamiques échappent à ces filtres d’atténuation. L’opérateur s’appuie sur des équipements qui fournissent du netflow vers une appliance qui analyse ces échantillons, et qui remontent ensuite des alertes et des signatures de trafics DDoS. Une fois les sources identifiées, l’opérateur peut blackholer la source de trafic, mettant un terme à l’attaque. Bon faut pas trop bourriner lors du filtrage histoire de pas casser du trafic légitime.

L’opérateur a mis en place toute une infrastructure pour activer/désactiver ces filtres automatiquement sur son infrastructure de cœur de réseau.

Blackbox Laser Fault Injection on a Secure Memory

Pour protéger des secrets en embarqué, on peut soit utiliser des Microcontroleurs, soit des secure-elements, soit des mémoires sécurisés tel que l’ATECC508A. C’est ce composant mémoire qui va être testé par l’orateur dans le cadre de l’évaluation des wallet hardware bitcoins. La puce à l’avantage d’offrir une surface d’attaque logicielle réduite, mais elle n’est pas protégée contre les attaques laser. Le silicium est transparent aux infrarouges, on peut donc en sortir une topologie par « transparence ». Quand on regarde une chip aux infrarouges, on peut parfois y trouver des photodiodes qui protègent contre les lasers en grillant la puce quand trop de lumière passe dedans. Ce type de protection est absente de la puce mémoire étudiée.

L’orateur détaille la structure mémoire de l’ATECC508A et les fichiers que l’orateur vas chercher à obtenir par attaque laser. L’orateur nous explique en suite les problématiques de mise en œuvre d’une attaque par laser sur la puce. Il faut bien « timer » son attaque pour injecter la faute au bon moment.

Pour faire l’attaque, il faut dégager la résine de la puce pour exposer le silicium en dégageant la plaque métallique de protection, puis on utilise une caméra infrarouge spécialisée pour voir l’intérieur du circuit. On test en suite des injections de faute en tirant des coups de laser sur la mémoire. Après plein de tentatives ratés, la clef n’a pas pu être extraite, par contre ils ont réussi à faire cracher le pin à la puce.

Un banc laser pour l’injection de fautes c’est pas donné, 200k€, mais il est envisageable de faire avec moins cher, avec potentiellement plus de ratés (la précision dans ce type d’attaque c’est important).

Utilisation de Chipsec pour valider la sécurité de plate-formes matérielles

Suite à un incident de sécurité lié à computrace sur des laptops Lenovo, l’ANSSI à mis en œuvre une procédure d’évaluation de la sécurité d’une plate-forme matérielle.

L’orateur détaille ensuite la vulnérabilité du flash SPI permettant d’écrire un bios malveillant. Cette attaque peut être stoppée par l’utilisation d’un bit BLE dans le BIOS empêchant la mise à jour. Cependant il existe d’autres vulnérabilités telles que Speedracer permettant de contourner cette protection. Il y a un grand nombre de vulnérabilités hardwares ou au niveau des micrologiciels permettant de backdoorer une plateforme matérielle.

Chipsec est une clef USB bootable exécutant un ensemble de tests de sécurité sur la plateforme matérielle pour vérifier sa bonne configuration ou non. Elle permet aussi la récupération de firmwares.

Inter-CESTI: Methodological and Technical Feedbacks on Hardware Devices Evaluations

Afin d’avoir des tests reproductibles et des résultats comparables il faut une méthodologie commune. Les critères communs ont un niveau d’attaquant variable, la ou sur une CSPN, le niveau est fixe.

La diversité des devices hardwares est assez énorme, ce qui complique la tâche pour réaliser une méthodologie commune car les fonctions peuvent être radicalement différentes. Du coup un challenge Inter-CESTI a pour but de mettre en place des attaques « cheap » sur une plateforme hardware donnée dans un temps limité.

Pour cette session, l’évaluation s’est faite sur Wookey, présenté à sstic en 2018. Pour challenger les CESTI, le plan de test à été demandé à l’avance, et on a laissé les CESTI hardware faire des attaques soft et inversement. Pour tester l’intégralité du produit, il faudrait plusieurs CSPN pour tout couvrir, du coup les périmètres différents ont été répartis entre tous les CESTI.

A l’issue du challenge, aucune vulnérabilité complète permettant de compromettre complètement l’une des fonctions de sécurité de wookey. Par contre des attaques hybrides ont été possibles en combinant un glitch sur un & logique et un buffer overflow. Le fait de croiser les approches Hard & Soft permet d’avoir une vision plus complète de l’impact des vulnérabilités.

L’agent qui parlait trop

Présentation rapide qui s’attarde sur l’analyse du composant SOLMAN (le SAP Solution Manager) permettant de contrôler tous les systèmes SAP interconnectés.

En résumé très rapide :

• Découverte de l’agent
• Arborescence des fichiers des applications avec des fichiers de configuration chiffrés
• Découverte des services de l’agent
• Découverte du SAP Secure Storage
• La clé dans le SAP Secure Storage contient la clé permettant de déchiffrer les fichiers de configuration
• La connexion entre l’agent et le serveur reste présent tant que le service tourne (le service P4)
• Le token change à chaque redémarrage de l’agent
• La clé est n’est pas un vrai token c’est un timestamp
• Il est donc facile de trouver le token
• En plus le GetProcessList est une API qui fournit l’heure de démarrage du process
• Le P4S est chiffré entre le SMD Agent et le serveur mais le P4 est autorisé en entrée de l’agent.
• Il y a une liste blanche pour l’exécution de commandes autorisé depuis le SMD Agent
• Mais en craftant directement la commande toutes les commandes sont autorisées

On fini par une démo et une liste de contre-mesures (déjà appliquer tous les patches liés à cette recherche).

Sécurité RDP : Interception d’authentification sur NLA avec CredSSPy

Retour sur le protocole CredSSP version 6, et tentatives d’attaques sur le celui-ci.

Le protocole RDP possède 3 modes :

• RDP Standard
• RDP TLS
• RDP Enhanced Security avec NLA

Le CredSSP commence par l’établissement d’un canal TLS. Pendant les étapes 5 et 6 le client et le serveur négocie le SSP (soit NTLM SSP, ou Kerberos).

On s’intéresse au NTLM SSP, la réponse contient le nom d’utilisateur, le nom de domaine et la clé de chiffrement de session.

Cette partie va un peu vite, le mieux c’est de regarder les schémas sur les slides.

1. Le serveur peut avoir besoin de s’authentifier auprès du DC si celui-ci ne connait pas les informations de l’utilisateur.
2. On n’a pas besoin du compte spécifique, juste d’un ordinateur dans le domaine pour récupérer la random session key.
3. Et en interceptant cette random session key il est possible de se positionner en man in the middle, pour récupérer les informations de compte de l’utilisateur.

De plus, il est possible de faire planter la négociation du SSP en effectuant un downgrade de Kerberos vers NTLM SSP en forgeant un paquet spécifique.

CANanalyze : a python framework for automotive protocols

On s’intéresse au protocole CAN qui est situé les véhicules, notamment sur ces 2 aspects :

• Vérifier que les services de Debug soient bien fermés
• Vérifier que les trames sensibles soient correctement filtrés par le FW

C’est ainsi que naît le framework CANAnalyze pour s’interfacer avec le protocole :

• Simple et compréhensible
• API
• Scripts fournis
• Compatibilité forte

Présentation de scripts permettant de simuler une gateway physique, virtuelle, etc. Via l’utilisation d’un script fourni, on peut scanner les services UDS, et donc via la verbosité du protocole savoir quels sont les services supportés par une ECU.

Le Framework est librement téléchargeable sur GitHub.