SecurityInsider
Le blog des experts sécurité Wavestone

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 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

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 hardware visant à 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 Hacking donné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 11 au 15 juillet


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Xavier GERONDEAU

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

Afficher l'image d'origine

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

Présentation

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

Fonctionnement

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

Prérequis

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

Configuration

Les fichiers catalogues

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

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

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

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

 Conclusion

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

Références

Abderahmane HABAIEB & Imane BELHAOUS

Solucom devient... Wavestone !



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

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

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

Compte-rendu du SSTIC 2016 - Jour 3


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

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

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

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

Mickaël BERGEM