SecurityInsider
Le blog des experts sécurité Wavestone

CERT-Solucom : retour sur l'actualité de la semaine du 11 au 15 juillet


Comme chaque semaine, retrouvez notre revue d'actualité de la sphère cyber-sécurité. Cette compilation de brèves vous permettra d'alimenter les discussions des prochaines pauses cafés !

[Brève] Httpoxy : une vulnérabilité pour les applications fonctionnant en environnement CGI permettant à un attaquant de définir un proxy HTTP arbitraire côté serveur et ainsi d’intercepter les flux
Sources :
https://httpoxy.org/ https://blog.qualys.com/laws-of-vulnerabilities/2016/07/18/cgi-application-vulnerability-httpoxy-for-php-go-python-and-others

[Brève] Des chercheurs de la société Vectra découvrent une vulnérabilité sur Windows lié à la gestion des imprimantes et permettant l’exécution de code arbitraire sur le système
Le patch de sécurité MS16-087 corrige cette vulnérabilité.
Sources :
http://blog.vectranetworks.com/blog/microsoft-windows-printer-wateringhole-attack http://blog.vectranetworks.com/blog/the-new-vulnerability-that-creates-a-dangerous-watering-hole-in-your-network https://nakedsecurity.sophos.com/2016/07/14/pwned-by-your-printer-microsoft-patches-critical-printer-spooler-bug https://technet.microsoft.com/library/security/MS16-087

[Brève] Le département de la Santé et des Services sociaux des États-Unis (HHS) publie une procédure de prévention et réaction face aux attaques par rançongiciel (ransomware)
Ce document est publié en réponse aux multiples affaires de rançonnage de données de santé au sein d’hôpitaux américains, dont par exemple le Hollywood Presbyterian Medical Center qui avait dû payer 17 000$ en février 2016 pour retrouver les données de ses patients.
Sources :
http://www.hhs.gov/blog/2016/07/11/your-money-or-your-phi.html http://www.hhs.gov/sites/default/files/RansomwareFactSheet.pdf https://duo.com/blog/new-hipaa-guidance-on-ransomware-in-healthcare http://www.lefigaro.fr/secteur/high-tech/2016/02/16/32001-20160216ARTFIG00205-un-hopital-americain-paralyse-par-des-pirates-informatiques.php

[Brève] Ranscam, un rançongiciel qui détruit les fichiers
Ce nouveau malware utilise des techniques d’intimidation afin d’inciter les victimes à payer le plus rapidement possible la rançon sous peine de voir leurs fichiers disparaître. En réalité les fichiers de la victime sont supprimés dès la compromission du poste de travail et le paiement de la rançon ne permet pas de récupérer les fichiers disparus.
Sources :
http://blog.talosintel.com/2016/07/ranscam.html http://arstechnica.com/security/2016/07/posing-as-ransomware-windows-malware-just-deletes-victims-files/

[Brève] La société NCC Group publie un outil de réponse aux attaques par rançongiciel
Sources :
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2016/july/ransomware-how-vulnerable-is-your-system/ https://github.com/nccgroup/ransomware-simulator

[Brève] La société Qualys met à jour son guide de bonnes pratiques pour l’utilisation de SSL/TLS
Ce document [1][2] est à compléter avec l’outil « SSL Configuration Generator » [2] de Mozilla permettant de choisir simplement les algorithmes et protocoles de chiffrement à supporter pour les échanges SSL/TLS.
Sources :
[1] https://blog.qualys.com/ssllabs/2016/06/27/new-release-of-ssltls-deployment-best-practices [2] https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices [3] https://mozilla.github.io/server-side-tls/ssl-config-generator/

[Brève] Des versions piégées de l’application Pokemon GO pour Android diffusées sur Internet
L’application dont-tout-le-monde-parle-en-ce-moment basée sur la fameuse franchise de Nintendo n’étant pas disponible officiellement dans plusieurs pays européens, de nombreux utilisateurs ont donc pris l’initiative d’installer l’application à partir de sites tiers. Toutefois certaines versions accessibles sur internet sont malveillantes et installent une porte dérobée avant de contacter un C&C.
Sources :
https://blog.lookout.com/blog/2016/07/15/pokemon-go/ https://www.proofpoint.com/us/threat-insight/post/droidjack-uses-side-load-backdoored-pokemon-go-android-app

[Brève] Plus de 108 patchs de sécurité pour Android publiés début juillet 2016
Sources :
https://blog.lookout.com/blog/2016/07/07/july-android-security-bulletin/

[Brève] La société AV-TEST évalue la sécurité de 7 bracelets connectés
Sources :
https://www.grahamcluley.com/2016/07/fitness-trackers-falling-short-security-reveals-new-report/ https://www.av-test.org/en/news/news-single-view/seven-fitness-wristbands-and-the-apple-watch-in-a-security-check-2016/ https://www.av-test.org/fileadmin/pdf/avtest_2016-07_fitness_tracker_english.pdf

[Brève] La société PenTestPartners évalue la sécurité (exécrable) d’une caméra IP qualifiée « Secured by Design » par la police britannique
Sources :
https://www.pentestpartners.com/blog/home-security-camera-isnt-secure-spotcam-in-the-spotlight/ http://www.securedbydesign.com/

[Brève] La société SWIFT fait appel à BAE Systems et Fox-IT afin de renforcer ses équipes sécurité suite aux récentes attaques sur le réseau inter-bancaire
Sources :
http://www.reuters.com/article/us-swift-banks-cyber-idUSKCN0ZR18T

[Brève] Une vulnérabilité dans le produit OpenSSH permet à un attaquant d’énumérer les utilisateurs valides sur le système cible
Sources :
http://www.theregister.co.uk/2016/07/17/openssh_has_user_enumeration_bug/ http://seclists.org/fulldisclosure/2016/Jul/51

[Brève] 8 banques taiwanaises désactivent temporairement leurs Distributeurs Automatiques de Billets suite à la présence d’un malware ayant permis le vol de 3 millions de dollars
Sources :
http://www.straitstimes.com/asia/east-asia/thieves-steal-3-million-in-taiwan-atm-heist-with-help-of-malware

[Brève] Le PCI-DSS Council publie plusieurs guides et notes d’information à destination des PME pour la protection des informations de carte bancaire
Sources :
https://www.pcisecuritystandards.org/pci_security/small_merchant

[Brève] L'ANSSI devient partenaire Gold de l'Open Information Security Foundation et soutient le projet open-source de détection et prévention d’intrusion Suricata
Sources :
http://www.ssi.gouv.fr/actualite/lanssi-rejoint-lopen-information-security-foundation/

[Brève] 2 millions d’authentifiants des utilisateurs des forums d’Ubuntu fuitent suite à une attaque via une injection SQL
Sources :
https://threatpost.com/two-million-passwords-breached-in-ubuntu-hack/119335/ http://www.veracode.com/blog/2016/07/ubuntu-forums-hacked-%E2%80%93-how-secure-your-community

[Brève] Facebook démarre le déploiement du chiffrement bout à bout dans l’application Messenger
Sources :
http://newsroom.fb.com/news/2016/07/messenger-starts-testing-end-to-end-encryption-with-secret-conversations/

[Brève] Le projet CrypTech vise à fournir un HSM open-source
Sources :
http://etherealmind.com/response-cryptech-a-open-source-hsm/ https://www.helpnetsecurity.com/2016/07/19/open-source-hardware-cryptographic-module-sold-800/ https://cryptech.is/

[Brève] Le malware Keydnap vole les mots de passe stockés dans le trousseau de clé Mac OS X
Sources :
https://www.helpnetsecurity.com/2016/07/08/keydnap-osx-malware/

Xavier GERONDEAU

La sécurité de Windows 10 – Partie 2 : Device Guard

Afficher l'image d'origine

Après un premier article sur le "Virtual Secure Mode", nous continuons notre série d'articles sur Windows 10 avec un focus sur la fonctionnalité "Device Guard". Bonne lecture !

Présentation

Chaque jour, des milliers de nouveaux malwares apparaissent et il devient de plus en plus difficile de lutter contre ce flot de programmes malveillants avec, pour seules armes, des outils et méthodes traditionnelles comme la détection basée sur la signature.
C’est dans ce contexte que Microsoft a développé Device Guard, une fonctionnalité uniquement disponible sur Windows 10 Entreprise permettant de verrouiller des appareils afin qu’ils n’exécutent que des applications, scripts et pilotes approuvés. Une application approuvée est une application dite de confiance, dont le code est signé par des signataires de confiance. Ainsi, un programme non approuvé ne pourra tout simplement pas s’exécuter sur l’appareil.
Dans l’article précédent, nous parlions de Virtual Secure Mode qui permet de protéger le système en protégeant les processus et données critiques dans une partition virtuelle sécurisée. Device Guard utilise cette technologie afin d’isoler Code Integrity, le service permettant de vérifier l’intégrité du noyau Windows. Ainsi, un attaquant aura plus de mal à exécuter un code malveillant puisque celui-ci pourra être bloqué par Device Guard.

Fonctionnement

Aujourd’hui, les postes de travail évoluent sans cesse et de nouvelles applications s’ajoutent, se suppriment ou se mettent à jour régulièrement. Device Guard est plutôt conçu pour les postes maitrisés où l’environnement ne va pas changer aussi souvent qu’un poste classique. Ainsi ce sont les postes dits critiques ou sensibles, telles que les postes d’administration, qui sont visés par Device Guard.
Plus qu’un nouveau mécanisme de sécurité, Device Guard est un ensemble de fonctionnalités de sécurité matérielle et logicielle. C’est lorsque toutes ces fonctionnalités sont activées simultanément que Device Guard apporte le plus haut niveau de sécurité. La première est Hyper-V Code Integrity (HVCI), l’un des services de la sécurité basée sur la virtualisation. Il permet de s’assurer que seuls les drivers, exécutables et DLLs respectant la stratégie d’entreprise sont autorisés à se lancer.
Dès le démarrage de l’appareil, Hyper-V Code Integrity va vérifier l’ensemble de ce qui s’exécute sur celui-ci et en particulier contrôler les drivers qui se chargent en mémoire afin de n’autoriser que les drivers signés. Cette exécution anticipée dans le lancement de la machine a pour but d’empêcher les programmes malveillants de s’exécuter au démarrage de l’appareil.
Figure 1 : Architecture du système avec Device Guard
HVCI utilise la sécurité basée sur la virtualisation afin d’isoler Code Integrity, un contrôleur de signatures des pilotes et fichiers chargés en mémoire qui s’exécute avec le secure kernel, noyau sécurisé de la partition sécurisée du Virtual Secure Mode. Ce service permet d’améliorer la sécurité du système en validant l’intégrité d’un pilote ou d’un fichier chaque fois que celui-ci est chargé dans le noyau. De manière concrète, Code Integrity est chargé de confirmer que le code dans les pages est signé, ce qui va permettre au secure kernel de marquer les entrées dans l’EPT (Extended Page Tables), les pages mémoire du kernel, comme exécutables. Ainsi, les pages mémoire d’un code non signé comme celui d’un malware par exemple n’ont pas les droits d’écriture ni d’exécution (+WX), empêchant de facto la modification d’un code exécutable.
De plus, Device Guard met à disposition une fonctionnalité utilisant UEFI afin d’empêcher sa désactivation, par exemple par un attaquant ayant compromis le poste. Une fois cette fonctionnalité activée, il devient impossible de désactiver Device Guard de manière classique. Une variable UEFI protégée est créée afin de bloquer l’activation de celui-ci, et ce dès le démarrage de la machine. Afin de désactiver Device Guard, il va falloir supprimer cette variable UEFI, ce qui ne peut être fait que poste par poste, ou bien en utilisant un outil de déploiement bas-niveau comme « Management Engine » d’Intel.
Figure 2 : Processus de sécurisation Windows 10
Code Integrity va permettre l’exécution dans le kernel du code de confiance et des programmes approuvés dans l’environnement utilisateur. Pour cela, il s’appuie sur une stratégie appelée « Code Integrity Policy ». Cette stratégie est un fichier déployé sur les postes de travail qui référence les signataires de code de confiance. Ainsi, le code signé par un signataire référencé dans le Code Integrity Policy aura le droit de s’exécuter sans restriction. Il faut aussi savoir que Microsoft est automatiquement un signataire de confiance. Les applications provenant du Windows Store, par exemple, sont signées par Microsoft et ne sont donc pas bloquées par Device Guard. Pour bloquer des applications au cas par cas, il convient de se tourner vers AppLocker et de créer les règles spécifiques. D’une manière générale, Device Guard va faire le gros grain quand AppLocker va permettre d’affiner le filtrage du code autorisé à s’exécuter sur la machine.
Un Code Integrity Policy de référence peut être créé afin d’être déployé sur un nombre important de machines. Cette stratégie de référence est appelée « Golden Code Integrity Policy » et est créée à partir d’une machine de référence contenant les applications que l’entreprise souhaite inclure dans sa stratégie. L’administrateur peut lancer un scan du système à la recherche de tous les fichiers qui va permettre la création de la stratégie. On peut ainsi imaginer une entreprise créer sa « Golden Code Integrity Policy » à partir d’un master Windows 10.
Après avoir déployé la stratégie Code Integrity sur les machines, toutes les applications non signées par un signataire de confiance se verront refuser l’exécution sur la machine. Il reste néanmoins toujours possible de les inclure dans la stratégie d’entreprise. Ceci est possible grâce aux catalogues de fichiers. Les catalogues sont des fichiers au format .cat contenant des empreintes des fichiers approuvés, ils sont créés grâce à des commandes Powershell. Un catalogue ne référence que les empreintes de fichiers, il n’est pas suffisant à lui seul pour permettre aux applications non encore approuvées de s’exécuter sur le système. Afin de les autoriser, il va falloir signer ce catalogue avec un certificat appelé « Device Guard code signing certificate ». Ce dernier peut être acheté ou bien créé en utilisant une autorité de certification interne, selon une procédure fournie par Microsoft. Une fois le catalogue signé par ce certificat de signature, il faut le rajouter dans le Code Integrity Policy. C’est seulement à ce moment que le catalogue, et par extension, les empreintes  de fichiers qu’il contient, est considéré comme signé par un signataire de confiance
Si l’entreprise ne dispose pas d’une infrastructure de gestion des clés interne, il est possible de faire signer le fichier catalogue directement par Microsoft via l’application « Device Guard Signing Portal » et se trouvant sur le Windows Store for Business. Il est ensuite possible de télécharger le certificat pour l’ajouter à la stratégie Code Integrity existante.

Prérequis

Device Guard nécessite quelques prérequis permettant de fournir un haut niveau de sécurité :
  • Windows 10 Enterprise 64-bits
  • Le verrouillage de l’interpréteur de commandes UEFI et des options de la fonction Démarrage sécurisé.
  • Technologies de virtualisation matérielles (Intel VT-x ou AMD-V)
  • Technologie de gestion de mémoire virtualisée  IOMMU (VT-d, AMD-Vi, etc.) afin de gérer les accès mémoire vers le monde sécurisé
  • Les pilotes en mode noyau doivent être compatibles avec Code Integrity.
  • La puce TPM version 2.0 pour le stockage des secrets (informations d’identification).
Néanmoins, la sécurité basée sur la virtualisation peut être activée malgré certaines contraintes matérielles non respectées, la sécurité du système en sera par contre réduite.

Configuration

Les fichiers catalogues

Device Guard en mode appliqué nécessite que chaque application présente sur le système soit signée et approuvée par la stratégie d’intégrité du code. Les applications signées par Windows Store sont automatiquement approuvées par le système, mais si l’on souhaite exécuter d’autres applications, celles-ci doivent être signées avant l’application de la politique Device Guard.
Pour ce faire, Windows 10 propose un outil appelé « Inspecteur de package » qui effectue le suivi de l’installation et l’exécution des applications que l’on souhaite faire approuver, et met leurs empreintes dans un fichier catalogue.
Attention : pour créer un fichier catalogue, il faut s’assurer que la stratégie d’intégrité de code est exécutée en mode audit (Cf. La stratégie d’intégrité du code), car une fois la politique déployée, aucune application ne pourra s’exécuter sur le système, et donc être mise dans le catalogue.
Pour créer le fichier catalogue, il faut tout d’abord exécuter l’inspecteur de package pour capturer les empreintes de chaque fichier binaire des applications que l’on souhaite approuver :
PackageInspector.exe Start C :
Ensuite, il faut copier les supports d’installation des applications sur le lecteur C : (ou n’importe quel autre lecteur) puis les installer et démarrer afin de s’assurer que toutes les mises à jour du produit sont installées.
Une fois cette étape terminée, il faut arrêter l’analyse à l’issue de laquelle deux fichiers sont générés : le fichier catalogue .cat et le fichier de définition .cdf
PackageInspector.exe Stop C :
La dernière étape consiste à signer le fichier catalogue et le déployer afin qu’il soit approuvé par la stratégie d’intégrité du code. On suppose qu’avant cette étape nous avons acheté ou créé un certificat de signature qu’on utilisera pour signer les catalogues :
.\signtool.exe sign /debug /f dg-cert.pfx /fd sha256 /v $CatFileName
dg-cert.pfx est le nom du certificat et $CatFileName est la variable contenant le chemin vers le fichier catalogue créé.
Afin de déployer le fichier, il suffit de le copier à l’emplacement suivant : C:\Windows\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}

La stratégie d’intégrité du code

Il faut au départ activer la protection de l’intégrité du code basée sur la virtualisation et activer Code Integrity :
Figure 3 : Activation de la sécurité basée sur la virtualisation
On peut ensuite passer au scan des fichiers pour créer la stratégie Code Integrity de référence avec les commandes :
New-CIPolicy –level PcaCertificate –Fallback Hash –ScanPath C : -UserPEs –FilePath .\CIPolicy.xml 3>.\warning.txt
ConvertFrom-CIPolicy .\CIPolicy.xml .\CIPolicy.bin
Une fois la stratégie créée, il faut copier le fichier binaire « CIPolicy.bin » à l’emplacement C:\Windows\System32\CodeIntegrity et le déployer via la configuration ordinateur\Modèles d’administration\Système\Device Guard de la stratégie de groupe locale et copier le chemin d’accès:
Figure 4 : Déploiement de la stratégie d’intégrité du code
Il est également conseillé de soumettre la stratégie de code créée à un audit avant de la déployer. Cette étape permettra de surveiller les exceptions consignées dans le journal des évènements CodeIntegrity lorsque l’exécution des applications ne correspond pas à la stratégie de référence. Pour ce faire, il faut ouvrir l’observateur des évènements, à l’emplacement Journaux des applications et des services\Microsoft\CodeIntegrity\Opérationnel
Finalement, pour appliquer la stratégie créée et auditée, il suffit de supprimer l’option de règle en mode audit et redémarrer la machine:
Set-RuleOption -Option 3 –Delete .\CIPolicyv1.xml
ConvertFrom-CIPolicy .\CIPolicy.xml .\CIPolicy.bin
Restart-Computer

Pour vérifier que les options Device Guard sont disponibles et actives, on peut exécuter msinfo32.exe depuis une session PowerShell avec élévation de privilèges:
Figure 5 : Les options Device Guard actives dans les informations système

 Conclusion

Introduite par Microsoft, Device Guard est à ce jour la meilleure façon de protéger un système Windows 10 entreprise contre les menaces liées aux programmes malveillants et l’une des fonctionnalités majeures pour renforcer l’intégrité des systèmes logiciels et matériels. Toutefois, son déploiement ne se fait pas en un simple clic mais nécessite un certain nombre de configurations matérielles et logicielles, en plus des prérequis nécessaires pour le bon fonctionnement des applications, tels que la création et la signature des fichiers catalogues, choses qui demandent une bonne connaissance de l’environnement Windows. Il faut également noter la nécessité de mettre à jour les fichiers catalogues lors des mises à jour applicatives.

Références

Abderahmane HABAIEB & Imane BELHAOUS

Solucom devient... Wavestone !



Solucom et les activités européennes de Kurt Salmon donnent naissance à Wavestone, un nouvel acteur majeur du conseil.
Pour plus d'informations, rendez-vous sur notre site web : https://www.wavestone-advisors.com/fr/

Continuez à suivre l'actualité sécurité et les analyses de nos experts sur SecurityInsider !

Cet été, nous nous envolerons pour Las Vegas où nous participerons à l'édition 2016 des conférences BSides et DefCon. Restez connectés sur SecurityInsider et rendez-vous sur Twitter (@SecuInsider) pour ne rien louper de ces événements !

Compte-rendu du SSTIC 2016 - Jour 3


Et pour clore notre compte-rendu de l'édition 2016 du SSTIC, retour ci-dessous sur la 3ème et dernière journée ! Bonne lecture !
MacOS : System Integrity Protection
System Integrity Protection, abrégé SIP, est un mécanisme de sécurité spécifique à Mac OS X qui bloque l’accès en écriture – même pour l’utilisateur root – à des dossiers (/System, /bin, /sbin…), des liens symboliques (/etc, /tmp, /var), des processus système signés par Apple (accès à la mémoire du processus, débogage, analyse DTrace…), et restreint le chargement d’extensions noyau non signées. Dans cette présentation, Nicolas Ruff présente les différentes manières de contourner SIP. Jusqu’à OS X 10.10, il est possible de désactiver SIP via un argument de démarrage, ou d’exploiter le fait que la vérification de la signature est effectuée en espace utilisateur : recompiler la commande « kextload » depuis les sources publiques permet par exemple de faire accepter des signatures invalides. D’autre part, il existe une liste blanche d’extensions noyau acceptées sans signature, identifiées par leur condensat SHA1, qui est mise à jour silencieusement par Apple – sans pour autant être manipulable par un attaquant. Enfin, certaines applications légitimes (qui possèdent les bonnes autorisations) comme fsck_cs peuvent être détournées pour passer outre SIP, ce cas particulier ayant été corrigé dans OS X 10.11.5.
Nicolas a conclu en soulignant que si SIP essaye de transformer le modèle de permissions assignées à des utilisateurs vers un modèle de permissions assignées à des applications, ce modèle est complexe à implémenter et qu’il faut s’attendre à la découverte de nouveaux bugs permettant de contourner ses restrictions.
Java Card Session
Cette partie est constituée de deux présentations sur la sécurité des JavaCards, par Jean Dubreuil (Serma Safety and Security) sur une attaque au niveau logiciel puis une attaque combinée, et par Guillaume Bouffard et Julien Lancia (THALES Communications and Security) sur du fuzzing évolutionnaire qui a permis de trouver un buffer overflow et d’exécuter du code arbitraire sur une JavaCard.
Après un rappel sur l’omniprésence des Secure Elements, l’architecture des Java Cards a été détaillée : avant d’être installés sur la Java Card, les applets doivent être validés par le Byte Code Verifier (BCV) pour éviter notamment l’exécution de code malveillant ou d’instructions illégales (accès à des zones mémoire d’une autre application par exemple).
Jean Dubreuil a donc présenté une attaque logicielle exploitant un buffer overflow dans la JVM, qui permet le contournement du pare-feu entre les applications de la JavaCard et donc une élévation de privilèges. Sa deuxième attaque est une attaque combinée, utilisant une applet composée d’une partie « légale » et d’une partie « malveillante » jamais exécutée (l’applet est donc considérée comme « légale » par le BCV et acceptée sur la carte), et de l’injection de faute pour perturber l’exécution du programme. En concevant l’applet de manière astucieuse, il est possible de modifier l’adresse de retour grâce à l’injection de faute, permettant d’accéder et d’exécuter la partie « illégale » du programme. Cette deuxième attaque permet également de contourner le pare-feu et d’exécuter du code arbitraire.
La deuxième présentation s’est quant à elle focalisée sur une vulnérabilité dans le BCV et sur la méthode qui a permis de la découvrir. En utilisant un algorithme évolutionnaire pour muter le fichier CAP (Converted APplet, qui contient l’application), une faille dans le BCV a été découverte – et ce dès la seconde génération. Une vérification manquante dans une implémentation du BCV permet donc d’obtenir un accès complet en lecture et écriture sur la mémoire de la carte.
Noyaux Linux durcis
Yves-Alexis PEREZ a présenté le patch de durcissement Linux grsecurity, en expliquant en quoi il permettait d’obtenir une sécurité accrue pour le noyau et le système. Grsec est composé de PaX (contre les corruptions mémoire), de RBAC (contrôle d’accès basé sur des rôles) et d’autres éléments de durcissement, et il protège contre certaines vulnérabilités (use-after-free par exemple). En revanche, il reste peu déployé, notamment car il n’est pas inclus dans le noyau mainline, qu’il provoque des problèmes de compatibilité et de support et également une légère baisse des performances. Pour résoudre ce problème de difficulté d’installation et de maintenance, l’auteur a donc publié des outils permettant de recompiler facilement le noyau, et propose des adaptations pour un usage desktop (la configuration par défaut empêche par exemple d’utiliser le navigateur chromium).
Design de cryptographie white-box : et à la fin, c’est Kerckhoffs qui gagne
Charles Hubain et Philipe Teuwen, de Quarkslab, ont présenté les attaques de type « crypto white-box » où l’attaquant a un accès total sur le matériel et peut donc utiliser toutes les possibilités physiques et logiques pour en extraire les données sensibles. C’est par exemple le cas rencontré avec les DRM, ou le paiement mobile.
Les attaques académiques sur les modèles existants ont conduit à de nouveaux modèles, à leur tour cassés par des attaques académiques, ce qui a poussé les industries à garder leurs designs secrets en utilisant des techniques d’obfuscation pour augmenter le coût des attaques. Ces attaques peuvent néanmoins être remplacées par des techniques comme l’identification visuelle de l’algorithme cryptographique : en enregistrant toutes les instructions et les accès mémoire, que ce soit sur le code, la pile ou les données, et en les représentant en fonction du temps, l’algorithme peut être facilement et rapidement reconnu. Sur l’image ci-dessous, on peut par exemple reconnaître DES grâce à ses 16 rounds successifs.

Trace d’exécution logicielle d’une implémentation « white-box » de DES
Après avoir identifié l’algorithme, il est possible de récupérer la clé en utilisant une technique de Differential Power Analysis ! Cette technique est performante, mais d’autres techniques comme la Differential Fault Analysis permettent d’atteindre des résultats similaires voire encore meilleurs.
Les auteurs ont également publié 5 outils dédiés aux attaques side-channel sur le Github SideChannelMarvels : Tracer, Deadpool (automatisation d’attaques), Daredevil (Computation Power Analysis), JeanGrey (Differential Fault Analysis) et enfin Orka qui propose des images Docker de ces outils pour une utilisation simplifiée.
Windows Error Reporting
Aurélien Bordes a présenté le système de traitement des rapports d’erreur de Windows (WER – Windows Error Reporting), qui sont générés en cas d’exception, de freeze d’une application ou d’un crash système. Les rapports sont utilisés pour corriger les bugs des applications Windows, mais des éditeurs de logiciels reconnus peuvent également demander à recevoir les rapports relatifs à leurs propres produits. Ces rapports contiennent des métadonnées qui peuvent parfois contenir des informations sensibles, ce qui pousse certaines entreprises à utiliser un collecteur WER en interne. Un tel collecteur permet d’éviter la fuite de données, mais peut également être utilisé en cas d’investigation numérique (un crash peut indiquer l’exploitation d’une vulnérabilité).
En revanche, ces rapports sont parfois transmis en clair, en HTTP. Or, un serveur a la capacité de demander des informations supplémentaires au client qui rapporte le crash, ce qui implique la lecture de fichiers arbitraires et même l’exécution de commandes côté client. Les commandes étant exécutées dans le contexte de l’utilisateur possesseur du programme (administrateur en cas d’un crash noyau), un collecteur compromis pourrait prendre le contrôle des postes concernés par un crash ! La sécurisation du collecteur est donc cruciale : s’il est désigné collecteur d’un datacenter, il est au moins aussi sensible que l’élément le plus sensible du datacenter.
Aurélien a également publié une implémentation d’un collecteur en PHP, disponible sur son Github.
Bypassing DMA remapping with DMA
Benoît Morgan (LAAS-CNRS) a présenté une « attaque d’IOMMU » exploitant une vulnérabilité au sein du firmware et du driver d’IOMMU Intel pour Linux. La fonction Direct Memory Access (DMA) permet à des périphériques d’accéder à la mémoire principale indépendamment du CPU. Pour contrôler la légitimité des accès mémoire, les Input Output Memory Management Unit (IOMMU) effectuent une virtualisation de l’espace d’adressage grâce à une traduction d’adresse.
L’attaque présentée permet de prendre le contrôle complet de la mémoire, tout en préservant l’intégrité du code système. Ces IOMMU ne sont pas utilisées systématiquement par les OS pour effectuer du cloisonnement : désactivées par défaut sous Linux, non utilisées sous Windows… Un périphérique malveillant connecté sur le bus PCI peut donc prendre le contrôle complet du système.
Scapy en 15 minutes
Guillaume Valadon (ANSSI) a présenté les bases de Scapy, l’outil de manipulation de paquets réseau codé en Python et utilisable en ligne de console. Parmi les astuces également présentées, on pourra remarquer : .ls() permet de lister les propriétés d’un objet, .summary() pour afficher un résumé du paquet, ou .command() qui donne la commande à taper pour reproduire le même paquet. Plusieurs fonctions de visualisation ont également été présentées : .show() affiche le paquet couche par couche dans la console tandis que .ps_dump() l’affiche avec la position des champs, comme sur l’exemple ci-dessous.

D’autres fonctionnalités sont également utiles : répondeurs, automates (clients TCP, TFTP) équipés d’une fonction graph() pour en visualiser l’état, support du format X.509, et même signature de certificat pour faire de la génération de certificats à la volée.
Plaso & Timesketch
Romain Gayon, de l’équipe Réponse à Incidents de Google, a présenté Plaso et Timesketch, des outils d’assistance à l’investigation numérique (Digital Forensics).
Plaso est un ensemble d’outils écrits en Python, utilisés pour analyser tout ce qui contient des timestamps et générer des évènements normalisés (log2timeline.py), et pour trier et filtrer ces évènements (psort.py). Il est ensuite simple d’écrire son propre script d’analyse pour effectuer des investigations plus poussées. Plaso supporte un grand nombre de formats en entrée : images de disque (EWF, QCOW, Raw, VDI, VHD, VMDK), de volumes système (GPT, MBR, BitLocker...), de systèmes de fichiers, et gère également le déchiffrement, la catégorisation et l’annotation automatique, et même l’envoi de fichiers vers VirusTotal ou Viper.
Timesketch est utilisé pour gérer le workflow de la réponse à incident, de manière collaborative et centralisée. En l’alimentant avec Plaso, un analyste peut alors investiguer sur une timeline consolidée à partir de nombreuses sources, en ajoutant des commentaires, en visionnant le résultat de scripts d’analyse automatique, et en ajoutant des annotations pour faciliter la lecture.
Graphes de dépendances : Petit Poucet style
Dans cette présentation très rythmée de travaux de recherche du CEA, la problématique d’analyse automatisée de logiciels malveillants a été abordée sous la problématique : « comment retrouver la valeur d’une variable à un instant donné, en connaissant le code du logiciel ? ». Il faut alors remonter le flux d’exécution pour trouver qui participe à la valeur finale de la variable.
Pour répondre à cette question, la méthode manuelle sous IDA est inadaptée (lent et facile de faire des erreurs), et les outils automatisés comme Angr.io et Metasm soit fournissent un sur-ensemble de solutions, soit nécessitent une heuristique (lourd et peut oublier des solutions) pour gérer les boucles, soit ne récupèrent pas toutes les solutions. Les auteurs ont donc créé un nouvel algorithme capable de distinguer les chemins d’exécution pour n’étudier les boucles que le nombre de fois où c’est nécessaire, en évitant les chemins « équivalents en dépendance ».
Conférence de clôture
Pour cette dernière conférence, Khartikeyan Bhargavan a présenté sa vision sur la sécurité de TLS au travers des attaques découvertes au cours des dernières années. La question principale est la suivante : comment prouver que le protocole remplit bien ses objectifs de confidentialité et d’intégrité des données échangées ?
L’agilité cryptographique, qui permet de faire évoluer les « protocoles cryptographiques » de manière souple, est nécessaire pour conserver la sécurité sur le long terme. On citera par exemple la transition de SSLv3 vers TLS, de DH-768 vers Curve25519, ou de MD5 vers SHA-256. Cette agilité repose sur la capacité des parties prenantes à négocier le meilleur jeu de protocoles en fonction de leurs capacités respectives, mais les failles au niveau du protocole ou des implémentations les exposent aux « downgrade attacks » où un attaquant force l’utilisation d’un protocole obsolète pour espionner la communication ou altérer les données échangées. D’autres attaques sur SSL et TLS, au niveau protocolaire ou implémentation, existent également : SKIP et FREAK par exemple correspondent à une mauvaise implémentation de l’automate d’état de TLS, attaques qu’il est possible de trouver en fuzzant ces automates d’état.
Pour résoudre ces problèmes, il est possible de prouver les propriétés de sécurité d’un programme grâce à la vérification formelle. L’INRIA et Microsoft Research ont développé miTLS, une implémentation de TLS formellement vérifiée et développée en F#. Si miTLS est prouvée conforme au protocole, elle est en revanche toujours sujette aux failles protocolaires comme SLOTH ou Logjam (attaques par collision de transcript), d’ailleurs découvertes par l’équipe de Karthik.
Enfin, des failles cryptographiques peuvent rester cachées pendant de longues années : il est important de trouver et de se débarrasser de ces failles d’implémentation. Ici, Karthik rejoint Brad Spengler (conférence d’ouverture) : la sécurité ne s’atteint pas en corrigeant sans cesse des bugs, mais en intégrant la sécurité dès la conception, notamment en prouvant formellement les propriétés de sécurité aussi bien des protocoles cryptographiques que des implémentations. La première chose nécessaire pour atteindre ce but est simple : que les chercheurs en cryptographie et les concepteurs de protocole travaillent ensemble. TLS 1.3, encore en cours de conception, est une tentative d’appliquer ce modèle.

En conclusion, cette édition 2016 du SSTIC n’a pas déçu par la qualité et la variété des interventions. Nous ne pouvons qu’espérer une plus grande capacité l’an prochain ;)

Mickaël BERGEM

CERT-Solucom : retour sur l'actualité de la semaine du 4 juillet


Comme chaque semaine, retrouvez notre revue d'actualité de la sphère cyber-sécurité. Cette compilation de brèves vous permettra d'alimenter les discussions des prochaines pauses cafés !

[Brève] Une faille dans un processeur utilisé dans 60% des téléphones Android permet de cracker le chiffrement d’un téléphone
Une faille dans les processeurs de la marque Qualcomm pourrait permettre à un attaquant ayant un accès physique a un téléphone d’en déchiffrer entièrement la mémoire.
Sources :
https://threatpost.com/encryption-bypass-vulnerability-impacts-half-of-android-devices/119039/ Pour le détail : https://bits-please.blogspot.fr/2016/06/extracting-qualcomms-keymaster-keys.html

[Brève] Pourquoi votre “Smart Watch” peut révéler votre code de carte bancaire
Un chercheur démontre qu’il est possible de récupérer les codes pin saisis lors d’un paiement grâce aux gyroscopes et accéléromètres inclus dans les objets connectés.
Source :
http://spectrum.ieee.org/tech-talk/consumer-electronics/gadgets/your-smart-watch-can-spy-on-your-pin

[Brève] “LevelDropper” un malware qui root votre téléphone disponible sur le Google Play Store
Source :
https://blog.lookout.com/blog/2016/06/27/leveldropper/

[Brève] Un nouveau ransomware, 100% en JavaScript
Répondant au nom de RAA, ce ransomware ne télécharge pas de fichier mais réalise l’intégralité du chiffrement de vos fichiers en JavaScript.
Source :
https://nakedsecurity.sophos.com/2016/06/20/ransomware-thats-100-pure-javascript-no-download-required/

[Brève] Fuite d’une base de données de 2.2 millions de potentiels terroristes
Source :
https://nakedsecurity.sophos.com/2016/07/01/database-of-2-2m-suspected-terrorists-money-launderers-leaked-online/

[Brève] Des caméras de surveillance forment désormais des botnets
Les équipes sécurité de Sucuri ont découvert un botnet de 25 000 caméras de surveillance utilisé pour réaliser des attaques par DDoS.
Source :
https://blog.sucuri.net/2016/06/large-cctv-botnet-leveraged-ddos-attacks.html

[Brève] Le constructeur TP-LINK perd le contrôle de deux noms de domaines utilisés par ses routeurs
Source :
https://www.helpnetsecurity.com/2016/07/05/tp-link-config-domains/

[Brève] Les produits Symantec toujours vulnérables aux attaques découvertes par les chercheurs de Google
Ces vulnérabilités présentes dans la configuration par défaut ne nécessitent aucune interaction utilisateur et peuvent être déclenchées par la simple réception d’un mail.
Source :
http://www.theinquirer.net/inquirer/news/2464131/symantec-admits-it-wont-patch-catastrophic-security-flaws-until-mid-july

[Brève] Comment Google et Facebook pourraient bloquer les images extrémistes
Grâce à une nouvelle technologie de hashage, les géants du web pourraient obtenir la liste des hashs correspondant à des images extrémistes afin de les supprimer sans nécessiter d’action humaine.
Source :
https://nakedsecurity.sophos.com/2016/06/28/are-google-and-facebook-to-block-extremist-content-with-automatic-hashing/

[Brève] Aux US la douane veut les noms de vos comptes de réseaux sociaux
Ce nouveau champ qui apparaîtrait dans les formulaires d’entrée aux US serait optionnel et permettrait aux autorités de contacter plus facilement les voyageurs.
Source :
https://nakedsecurity.sophos.com/2016/06/29/us-customs-wants-your-social-media-account-details-when-travelling/

Xavier GERONDEAU

Compte-rendu du SSTIC 2016 - Jour 2


Dans le cadre de notre participation au SSTIC 2016, nous vous avions partagé en exclusivité le compte-rendu de notre 1ère journée.
On continue avec le compte-rendu de la 2ème journée, avec un joli programme en perspective !
N'hésitez pas à réagir.
Bonne lecture !
A first glance at the U2F protocol
Ce jeudi matin, Mickael Bergem a présenté avec Florian Maury une étude réalisée pendant son master et pour le compte de l’ANSSI, portant sur U2F – Universal Second Factor. U2F est un protocole d’authentification forte créé par la FIDO Alliance qui repose sur un token physique (ou logiciel) et communiquant en USB, en Bluetooth ou en NFC (pour les smartphones par exemple). Déjà disponible comme second facteur d’authentification sur les sites de Google, Github et Dropbox, il apporte des garanties de sécurité et une facilité d’utilisation supérieures aux solutions reposant sur l’envoi de codes par SMS ou la génération de codes TOTP (Time-based One-Time Passwords). Il permet notamment de se protéger contre les attaques par phishing, alors que les solutions précédentes sont inefficaces.
U2F intègre également une protection contre les attaques Man-In-The-Middle TLS, c’est-à-dire lorsque l’attaquant est directement sur le chemin réseau et est en mesure de présenter un certificat TLS accepté par le client (attaque difficile à réaliser). Pour cela, U2F repose actuellement sur une extension TLS nommée « TLS Channel ID », qui n’est implémentée que sur les serveurs de Google (dans leur librairie BoringSSL). En revanche, la vérification de cette attaque est volontairement désactivée, pour éviter de bloquer les clients utilisant un proxy TLS, le proxy agissant alors comme un MITM TLS. Cette protection avancée n’est donc pour le moment pas utilisable (non supportée ou non vérifiée), U2F restant néanmoins une solution simple et efficace comme second facteur d’authentification. Une comparaison avec l’utilisation de certificats TLS clients (authentification mutuelle) montre que cette dernière solution est à préférer dans les contextes sensibles (interface d’administration par exemple), bien que plus difficile d’utilisation.
How not to break LTE crypto
Benoît Michau et Christophe Devine (ANSSI) ont présenté une revue du modèle de sécurité en LTE (4G), ainsi que plusieurs vulnérabilités trouvées dans des modems 4G fabriqués par Qualcomm, Mediatek et Samsung. Certaines implémentations acceptaient jusqu’en 2013 le contrôle d’intégrité nul (EIA0) pour toutes les connexions, ce qui permet de faire de l’interception en utilisant une fausse base station LTE. Plus récemment, une attaque par analyse différentielle a permis d’extraire le secret partagé d’une carte SIM, permettant de déchiffrer toutes les communications passées ou présentes de l’utilisateur, car aucun mécanisme de Perfect Forward Secrecy n’est utilisé en LTE. D’autres vulnérabilités permettent de demander aux terminaux de communiquer sans chiffrement, permettant de récupérer l’APN et l’IMSI, ou encore de récupérer l’IMEI d’un terminal en utilisant un « bit de politesse » qui une fois passé à 1 désactive les vérifications (ce bit est censé n’avoir aucun effet, d’après la norme). On notera également l’apparition des mots « ordiphone » (pour smartphone) et… « biscuits de pile » (pour stacked cookies) dans cette présentation de l’ANSSI, qui a particulièrement fait réagir la sphère Twitter.

Méthodologie d’extraction de signatures issues des signaux AIS
Erwan Alincourt et Pierre-Michel Ricordel (IRENav / ANSSI) ont présenté leurs expérimentations pour détecter les signaux AIS forgés. AIS, pour Automatic Identification System est un système de suivi de la localisation des navires, permettant d’identifier et de suivre les navires, par la communication de leurs coordonnées GPS.
D’après les chiffres présentés, 1% des navires transmettent des fausses données, dont 44% sont des navires chinois : les falsifications sont triviales et ont par exemple permis à des navires iraniens de passer le blocus ou à des pêcheurs de sortir des zones de pêche autorisées sans être repérés. À l’aide d’adaptateurs RTL-SDR (par exemple, un simple tuner TNT) et d’une carte HackRF, les auteurs ont réalisé des acquisitions dans la rade de Brest, et ont analysé les caractéristiques des signaux recueillis (temps de montée et de descente de l’émetteur, temps avant et après modulation, corrélation entre puissance du signal et distance). Ces différentes informations leur ont permis d’identifier avec certitude un répéteur (connu) de signaux, situé à terre. Le maintien d’une base de connaissance et la vérification de la stabilité temporelle de l’empreinte des émetteurs peut permettre de détecter les faux émetteurs. Améliorer AIS en ajoutant une couche de sécurité est coûteux car cela nécessiterait de changer le protocole et les matériels, mais augmenter le coût de l’attaque en développant ces techniques de fingerprinting apparaît comme un axe de progression intéressant.
Comparaisons et attaques sur le protocole HTTP2
Dans cette présentation, Georges Bossert a d’abord rappelé que HTTP/2 est grandement basé sur SPDY, un protocole non standard développé par Google dont le but est de réduire la latence en utilisant une seule connexion TCP pour toutes les connexions HTTP à un même site. Il a ensuite détaillé une comparaison des piles protocolaires entre Apache, h2o, Tomcat et Nginx, pour mettre en évidence les différences d’implémentation de HTTP/2 entre ces serveurs web. Pour cela, Georges a construit un « vocabulaire d’entrée », identifié les cas limites (négation des MUST, SHOULD, MAY de la RFC) et lancé une inférence active de l’automate d’état de ces implémentations, grâce à LSTAR (L*, réimplémenté en Python pour l’occasion). En sortie, on obtient des graphes d’automates à état où il est possible de visualiser les différences et les écarts à la norme. Plusieurs utilisations peuvent être faites de ces graphes :
  Créer un « smart-fuzzer » en partant d’un état légitime grâce au graphe, puis en essayant de passer sur des états illégitimes : cette approche a permis de provoquer des crashs de nginx, apache, et deux « bugs sécurité » sur h2o par exemple ;
  Créer un outil de fingerprinting quand les traces sont différentes, permettant d’identifier l’implémentation : cette approche est concluante après 3 échanges ;
  Faire de l’évasion d’IDS (Intrusion Detection System), en exploitant le non-respect des spécifications pour échapper au contrôle de l’IDS, par exemple en utilisant le fait que nginx maintient la connexion après des erreurs fatales.
Les outils utilisés sont disponibles sur le Github de l’auteur.
Évolution des techniques d'attaques de circuits intégrés
Cette « conférence invitée » a été présentée par Olivier Thomas, CEO de Texplained, qui a expliqué de manière très intéressante les différentes attaques sur les circuits intégrés. Trois classes d’attaques sur les semi-conducteurs peuvent être identifiées :
  Les attaques non invasives consistent par exemple en l’utilisation de « VCC glitchs » (perturbation de l’alimentation) ou de « Clock glitchs » (perturbation du signal d’horloge). L’analyse de la consommation d’un circuit (Simple ou Differential Power Analysis) est également une technique non invasive, qui peut permettre de récupérer une clé privée par exemple.
  Les attaques semi-invasives nécessitent un accès direct au circuit intégré et un équipement plus important (et plus coûteux) et consistent principalement à faire de l’injection de faute à l’aide d’un laser de précision (« laser glitching » ou « laser fault injection »). En utilisant la bonne longueur d’onde (1064nm, infrarouge) le silicium est transparent pour le laser, qui peut directement accéder aux composants, et l’impulsion laser permet par exemple de déclencher un transistor sur commande. L’injection automatisée permet de « scanner » tout un circuit pour détecter les transistors provoquant un changement d’état particulier (par exemple, passage de la puce en mode administration, ou développement). Il est également possible d’utiliser le laser pour scanner la puce dans un premier temps, ce qui permet d’atteindre une plus grande précision dans les tirs. Enfin, il est possible de déterminer l’emplacement de l’horloge en localisant des « points de photoémission » (transition périodique). Ces attaques, lorsqu’elles sont ciblées, permettent par exemple de devenir « super-utilisateur » à coups de laser !
  Enfin, les attaques invasives sont généralement destructrices pour la puce, car elles consistent à retirer successivement les couches du circuit pour obtenir un plan précis de son architecture, en utilisant des produits chimiques (Chemicals only), des produits chimiques et une abrasion mécanique (Chemical Mechanical Polishing), ou encore un plasma qui vient arracher des électrons (Plasma Etcher). Sur certaines puces dites shielded, un maillage entoure toute la puce et déclenche une « autodestruction » logique (effacement de toutes les mémoires) lorsqu’une maille est sectionnée. Il faut alors ruser en passant entre les mailles pour poser des sondes (Microprobing), ou bien appliquer des « pansements » sur les mailles sectionnées pour empêcher la détection.
Différentes techniques d’obfuscation de la puce ont également été présentées, comme l’utilisation de Silicium non dopé (ROM), ou l’utilisation de faux liens. En revanche, ces techniques n’arrêtent pas Olivier Thomas, qui explique qu’il peut extraire une carte complète (22000 portes) en une semaine en utilisant le bon matériel et le bon logiciel. Il cite notammen,t le logiciel ARES, qui effectue de la reconnaissance automatique d’image sur les images des tranches de la puce. Le coût d’une attaque sur ces puces n’est donc pas si élevé qu’on ne l’imagine, surtout en sous-traitant certaines opérations au lieu d’acheter le matériel adéquat, et peut descendre à moins de 30 000€ par exemple. En fonction de la puce, un nombre réduit d’exemplaires est suffisant pour mener complètement l’attaque (50 exemplaires pour une puce en 22nm, 5 pour du 65nm).
En conclusion, ces attaques sur circuits imprimés – qui nécessitent certes de l’expérience, et un peu de matériel et d’argent – sont relativement accessibles, et peuvent être vite rentabilisées une fois que l’analyse a été faite une première fois, ce qui pose la question de la réévaluation de l’échelle des Critères Communs.
App vs Wild
Dans cette conférence, Stéphane Duverger (Airbus) explique comment protéger en confidentialité le code (chiffré et signé à l’origine) d’une application dans un environnement hostile,  ou compromis. En se basant sur Ramooflax, solution de virtualisation légère et libre présentée au SSTIC 2011, l’auteur choisit de virtualiser la mémoire physique pour pouvoir y stocker le code du programme déchiffré. La mémoire virtualisée est cloisonnée entre le système d’exécution complet (« VM RAM Origine » sur le schéma) et le code de l’application (stocké déchiffré, « VM RAM Secret » sur le schéma), tous deux disponibles à tout instant mais de manière exclusive : après vérification de l’intégrité de la RAM « Secret », les pages mémoires correspondantes sont passées en mode eXecute-only (grâce aux fonctions Intel EPT). Le code s’exécutant dans la partie « VM RAM Origine » ne peut donc pas accéder en lecture au code stocké déchiffré dans la « VM RAM Secret ». Le filtrage repose uniquement sur des considérations matérielles et ne dépend pas du système d’exploitation, bien que seuls les binaires ELF32 soient à ce jour supportés. Cette solution est encore en cours de développement mais pourrait permettre d’apporter un niveau de sécurité supplémentaire dans la protection en confidentialité du code d’applications.
Winbagility : débogage furtif et introspection de machine virtuelle
Nicolas Couffin, de la DGA MI (équipe IMPS), a présenté un outil permettant le débogage furtif de systèmes Windows. Dans le cas de l’étude d’un code malveillant, l’analyste a besoin d’éviter que le code ne détecte la modification de la machine virtuelle dans laquelle il est exécuté. Il n’est donc pas possible d’utiliser le débogueur de Microsoft (WinDbg). Dans l’objectif d’obtenir un environnement réaliste, il est nécessaire de conserver Patchguard activé, de ne pas être détecté par le logiciel malveillant, de pouvoir analyser de manière dynamique l’exécution du logiciel. L’auteur a ainsi présenté FDP, pour Fast Debugging Protocol, qui repose sur une modification de VirtualBox pour pouvoir interagir facilement avec le système invité. L’auteur a ensuite présenté un second outil, Winbagility, qui s’appuie sur FDP, et permet de poser des breakpoints hardware (des HardwareBreakpoints, des HyperBreakpoints, et même des HardHyperBreakpoints). Ses propriétés le rendent difficiles à détecter depuis le logiciel analysé, et en font un outil rare dédié à l’introspection furtive sous environnement Windows.
Déverrouillage d'Android en simulant un clavier/souris
Antoine Cervoise nous a ensuite présenté un outil permettant de « bruteforcer » les interfaces de verrouillage de terminaux Android, en simulant des entrées clavier ou souris sur le port On-the-Go (OTG) des téléphones. Pour cela, il a utilisé un Arduino pour simuler les entrées clavier/souris HID, piloté par un Raspberry Pi. Une webcam USB connectée au Raspberry Pi permet de détecter la réussite du déverrouillage du téléphone, en utilisant la librairie ImageMagick.
En utilisant les listes de codes PIN et codes de déverrouillage les plus fréquents, il a donc été possible de trouver le code valide en quelques heures, malgré les délais parfois obligatoires entre des tentatives échouées (à raison donc de 100 mots de passe en 20 minutes).
On peut noter que ces attaques ont permis de mettre en évidence des failles dans des téléphones Samsung, qui plantaient après un certain nombre de tentatives, en laissant l’écran déverrouillé pendant quelques secondes, avant de verrouiller le téléphone de nouveau.
Enfin, une autre technique décrite dans l’article permet d’améliorer les résultats : « la divination peut être utilisée notamment en analysant les traces de doigts sur le téléphone afin de réduire le nombre de codes possibles et de tester manuellement les possibilités restantes ».
The Metabrik Platform: Rapid Development of Reusable Security Tools
Patrice Auffret est l’auteur de The Metabrik Platform, un framework d’outils de sécurité (du pentest au forensic) associé à un shell et un « vrai » (l’auteur a insisté) langage de programmation, Perl. Metabrik utilise des « Briks » comme modules, dans la même veine que Metasploit. Ce projet permet d’automatiser un certain nombre de tâches, par exemple en chaînant des Briks pour atteindre un objectif plus rapidement. Les Briks sont hautement modulaires, et peuvent par exemple hériter d’une ou plusieurs autres Briks, ou être personnalisées et améliorées. En moins de 4 lignes dans Metabrik, il est donc possible de lancer une VM avec Virtualbox, de prendre un snapshot, d’exécuter un programme, puis de produire un fichier de différences sur l’état de la machine Windows. D’autre Briks permettent d’analyser simplement des fichiers et d’en extraire des données (par exemple, des métadonnées dans une image compressée). The Metabrik Platform est disponible et prêt à l’utilisation, avec plus de 200 Briks, sur le site https://www.metabrik.org/.
DYODE : Do Your Own DioDE, une diode open-source à moins de 200€ pour les réseaux industriels
Dans cette présentation, Arnaud Soullié (Solucom) a montré comment fabriquer une diode réseau, c’est-à-dire ne laissant passer les données que dans un seul sens. Cette diode a la particularité de coûter environ 200€ alors que les diodes disponibles dans le commerce ont souvent un prix bien plus élevé (et des performances également supérieures), et elle est donc par exemple adaptée aux systèmes industriels qui ont des besoins en performance relativement faibles. L’ensemble est constitué de deux Raspberry Pi pour les guichets d’entrée et de sorties, de convertisseurs Cuivre-Optique
À ce jour, 3 modes sont disponibles : le transfert de fichiers, le transfert de données Modbus, et le partage d’écran (sans interaction). Le code est disponible sur GitHub.
Nous reviendrons sur ce projet Solucom dans un article dédié.
Résultats et solution du challenge du SSTIC 2016
Comme chaque année, le SSTIC propose un challenge au public, constitué d’une série d’épreuves à résoudre. Parmi les épreuves de cette année, on notera entre autres : la présentation des épreuves au travers d’un RPG en Javascript, l’utilisation d’un secret partagé de Shamir pour reconstituer une clé, la rétro-ingénierie d’un programme TI-Basic (pour calculatrice), l’analyse de traces GSM et SMS depuis un enregistrement de SDR (Software Defined Radio), la rétro-ingénierie d’une archive sparse de 117To, d’un binaire Itanium (ia-64 bits), ou l’analyse d’une police TrueType.
Plusieurs outils open-source ont été améliorés par des participants du challenge. Les vainqueurs au classement rapidité sont Nicolas Iooss, Fabien Périgaud, et Eric Dangereux, au classement qualité : David Berard, Romain Carré, et Fabien Périgaud. Au classement ubiquité (solution pour toutes les épreuves) Fabien Périgaud est le seul classé. Ce dernier, présent dans les trois classements est également venu présenter une partie des solutions du challenge. Quelques chiffres enfin sur cette édition du challenge, qui a été téléchargé 2054 fois, et dont 100 participants ont validé le premier niveau, 45 le niveau 2 et 23 le niveau 3 (avec un seul participant accédant au classement ubiquité).
Rumps !
Un moment attendu au SSTIC est celui des rumps : des orateurs viennent présenter un sujet technique ou non, en 3 minutes montre en main, souvent de manière humoristique. Le public peut choisir d’accorder quelques dizaines de secondes supplémentaires aux orateurs en restant silencieux mais peut également choisir d’applaudir bruyamment pour précipiter la fin de la présentation, appuyée par un lance-missile USB pointé vers l’orateur et automatiquement armé au bout des 3 minutes. Petit florilège des différentes présentations :
  « Pourquoi c’est flou » (Pierre Capillon) a décrit le fonctionnement du système de vidéoprojection et de streaming en direct des conférences sur internet, et démontré l’art des organisateurs pour arranger les câbles réseau et les convertisseurs vidéo ;
  « Évolution de Fuddly depuis le SSTIC 2015 » (Eric Lacombe) a annoncé les améliorations apportées à son framework de fuzzing et de manipulation de données en Python, qui intègre des algorithmes de mutation automatisée, des attaques sur des piles réseau, et d’autres nouveautés intéressantes ;
  « Near Field Beers » par Fabien Périgaud a montré qu’il était trivial d’usurper une carte NFC pour boire gratuitement dans les bars utilisant des tireuses en libre-service, à l’aide d’un Proxmark3 ;
  « RAM & Disk EFI Dumper » par Solal Jacob, a partagé son expérience d’investigation numérique sur un ordinateur portable chiffré, en écrivant un dumper de RAM vers une clé USB, depuis lequel il est possible d’extraire les clés de chiffrement ;
  « Étude d’un disque lolifrant » par Julien Lenoir et Raphaël Rigo, a présenté l’insécurité d’un disque dur externe protégé par un code PIN, après reversing du microprocesseur du disque : à partir d’un ordinateur il est possible de demander le code PIN directement au disque dur, sans l’avoir déverrouillé, ce qui rend inutile cette protection ;
  « De la difficulté des communications sécurisées » par Guillaume Tessier, a décrit le protocole ZRTP (VoIP) et présenté des failles d’implémentation dans Linphone, application répandue de téléphonie sur IP ;
  « R2M2 » par Guillaume Valadon a présenté un outil composé de radare2 et de miasm2 pour faciliter l’analyse de code ;
  Dans « Comment ne plus avoir de pubs ? », Charles Hourtoule a présenté un outil pour augmenter artificiellement et gratuitement son nombre de followers ou de likes sur Twitter ;
  « Fighting malware like a boss » (Pierre Chifflier et Fabien Pichot) a présenté une méthode originale pour contrer les logiciels malveillants : leur faire croire qu’ils sont analysés par des outils classiques comme des antivirus ou des outils d’analyse dynamique ;
  « Amsterdam » par Eric Leblond, a présenté une infrastructure SELKS (ISO live avec Suricata, ElasticSearch, Kibana, Logstash, Scirius pour les jeux de signature) basée sur Docker (avec utilisation de docker-compose) pour monter un IDS facilement ;
  « AJPy » par Julien Legras a présenté une bibliothèque pour attaquer les flux AJP ;
  « Winning crap with Twitter API » a expliqué comment gagner des lots grâce à robot qui participe à des jeux-concours sur Twitter ;
  « IDMEF et IODEF » par Thomas Andrejak, a présenté les formats de remontée d’incidents de sécurité IDMEF et IODEF, ainsi que des librairies développées pour faciliter l’utilisation de ces formats ;
  « Vos empreintes sont-elles sûres ? » par Lucas Barthelemy et Léo Rannou à propos de l’usurpation des systèmes de reconnaissance digitale ;
   « libECC » par la team du projet Eurisko de l’ANSSI, a décrit la librairie développée « maison » avec des objectifs de compatibilité, de sécurité et d’agilité cryptologique ;
  « Manalyze » par Ivan Kwiatowski, est un analyseur statique pour exécutables PE ;
  « Analyse d’un Exploit Kit Angler » par Kevin Denis, a présenté une analyse d’un code Javascript obfusqué avec plusieurs niveaux d’encapsulation, qui affiche en réalité… une iframe ;
  « Just do it the hard way » (Mathieu Renard) a présenté avec un humour particulier les attaques hardware ;
  « You are not alone » de Aska, a présenté une série de citations des interlocuteurs des équipes sécurité côté « défense », particulièrement humoristique (« Mais vous ne voulez quand même pas qu’on suive toutes les CVE qui s’appliquent à notre produit ? ») ;
  « IVRE more » (Florent Monjalet) a présenté un outil de veille sur les réseaux extérieurs, auquel des modules de cartographie active et passive a été ajouté, dont les résultats sont représentés de manière visuelle ;
  Dans « Univershell et Attaque contre Android Face Unlock », Antoine Cervoise a présenté rapidement l’association Univershell (workshops sécurité) ainsi que la déclinaison de son attaque sur les motifs de déverrouillage de téléphone ;
  « Die hard » de Philippe Trébuchet, a présenté une attaque au niveau physique sur un dispositif « de désamorçage » en utilisant entre autres un BusPirate ;
  « Dynamically detecting smart XSS with evolutionary fuzzing methods and machine learning involving cyber algorithms - Quelques échecs de GreHack » a finalement présenté après une parenthèse humoristique un retour d’expérience sur l’organisation de la conférence GreHack.
Après cette journée très riche, les participants ont pu se retrouver lors du Social Event organisé dans le centre-ville de Rennes.
Mickaël BERGEM