Retour sur l'édition 2015 de la Black Hat Europe

Cette année encore, XMCO était partenaire de la conférence Black Hat Europe. Retour sur cette édition 2015.

A l’image des précédentes éditions, cette année, la BlackHat Europe a encore été l’occasion d’assister à des conférences particulièrement techniques , à la pointe du domaine, en plus de se dérouler dans un cadre particulièrement agréable : Amsterdam aux Pays-Bas.

Étant donné le nombre de présentations qui ont été données au cours des deux jours dédiés aux conférences, nous ne décrirons ici que les 5 présentations qui nous ont semblé les plus intéressantes. Les autres seront disponibles dans le prochain numéro de l’ActuSécu.

Jour 1

Keynote: What Got Us Here Wont Get Us There, par Haroon Meer

SLIDES

La keynote d’ouverture, présentée par Haroon Meer, avait pour but de faire le point sur l’état actuel de la sécurité, et surtout de comprendre comment a-t-on fait pour en arriver là.

La première raison évoquée est la complexité grandissante des systèmes. Bruce Schneier avait prédit cette situation en 1991 au sein d’un article sur son blog : Il va falloir s’habituer a être insecure dû à la complexité des systèmes grandissante . Par exemple, le kernel Linux est passé de 10 000 lignes de codes (en 1991) à plusieurs millions aujourd’hui. De même, si l’on souhaite réaliser un audit sur l’ensemble des éléments nous permettant de communiquer sur Internet (navigateur Internet, client mail,etc.) aujourd’hui, la tâche est devenue impossible. Nous sommes devenus esclaves de la complexité de nos systèmes.

À l’heure actuelle, la majorité des sociétés ne sont pas sécurisées ou dispose d’un niveau de sécurité datant des années 2000. Mais le plus grave est le fait que la majorité de ces sociétés ne le savent pas. Ces sociétés ont donc besoin d’appliquer les recommandations de base. Elles n’ont pas besoin de systèmes de protection avancée qui utilisent les derniers mots à la mode comme Threat Intelligence , ou Big Data . Les boîtiers magiques ne sont pas la solution. Ce ressenti a été effectivement confirmé par l’ensemble des consultants de sécurité que Haroon Meer a consulté.

Dans le célèbre livre What got us here wont get us there écrit par Marshall Goldsmith, l’auteur aborde une notion intéressante d’après Haroon Meer : il est important de dire ce qu’il ne faut pas faire, et pas seulement ce qu’il faut faire . De plus, afin que la sécurité soit acceptée au sein d’une société, il est nécessaire qu’elle ne soit pas un facteur bloquant ( enablers ). Les équipes de sécurité doivent accompagner les développeurs ainsi que la production afin de mettre en place de manière sécurisée leurs idées et projets. Dans le cas, où les équipes de sécurité imposent des règles restrictives ( disablers ), ces règles seront ignorées et contournées. Il est important que la sécurité, bien que contraignante, soit acceptée par l’ensemble des équipes (marketings, développeurs, système, etc.).

Le premier exemple est le cas le plus classique des tests d’intrusion. Les tests menés depuis des dizaines d’années ne font pas élever le niveau de sécurité globale des entreprises. La raison est simple, le format de ces tests ne reflète pas les cas d’intrusion réels. Le principal facteur dans une compromission interne est le facteur humain. Le seul moyen de se trouver dans ce type d’intrusion est de réaliser des tests d’intrusion en mode Red Team. Dans ce cas, pourquoi continue-t-on de réaliser des tests d’intrusion sur ces applications ? Parce que c’est facile à vendre et qu’ils délivrent un résultat binaire.

Un autre exemple est la qualification des attaques suivant le nombre de documents volés. Ce moyen n’est pas représentatif d’une attaque surtout concernant les APT. Le vol de certains documents clés est souvent plus important que le vol de millions d’informations utilisateurs. De plus, l’ironie est que souvent, la réponse face à ces attaques de grande envergure (comme Target ou Sony), est le mot Big Data …

Le dernier exemple, est que le monde de la sécurité se concentre trop souvent sur des faux problèmes :

• Public disclosure : mis à part à l’arrogance de certains chercheurs, pourquoi le projet Google Zero est-il autant détesté ?
• 0day : encore un faux débat dans la sécurité au quotidien. Aucun consultant en sécurité n’a jamais eu besoin d’utiliser un 0-day pour devenir administrateur du domaine lors d’un test d’intrusion interne.
• Conferences : qui se souvient vraiment des résultats présentés et pas seulement du titre de la présentation ?

En conclusion, il est important de se rendre compte que la situation actuelle est désastreuse. Si aucun changement n’est rapidement effectué, les conséquences pourraient être catastrophiques. Chacun doit commencer à faire de la vraie sécurité, et non pas quelque chose y ressemblant vaguement. en effet, cette pratique approximative n’a au final aucun impact sur la sécurité de l’entreprise. En particulier, il est peut-être temps que les personnes pratiquant la sécurité offensive tentent l’expérience du côté défensif.

Breaking Access Controls With Blekey, par Eric Evenchick & Mark Baseggio

Les chercheurs Eric Evenchick et Mark Baseggio ont présenté les faiblesses présentes dans la solution de contrôle des accès physique (badge) de la société HID. Ces boîtiers sont très répandus, et ce, partout dans le monde.

Tout d’abord, les contrôles d’accès reposent sur des technologies assez vieilles même ceux installés au sein des bâtiments récents. Les lecteurs de la société HID utilisent une interface Wiegand qui est utilisée depuis la mission Apollo. Une des vulnérabilités liée à l’utilisation de ce protocole est que les informations transitent au travers d’un canal non sécurisé (en clair).

Suivant le modèle utilisé, les badges disposent des informations d’authentification en clair ou chiffrées. Néanmoins, sur certains produits, le lecteur de carte embarque la clé de chiffrement symétrique (DES). La clé a donc été retrouvée, depuis, au sein du firmware.

Pour identifier un utilisateur, deux informations sont nécessaires :

• Un numéro de fabricant contenu sur 8 bits.
• Un numéro d’identification contenu sur 26 bits. De plus, sur certaines cartes, la clé d’authentification est imprimée sur la carte …

Avec toutes ces informations, un attaquant peut facilement recréer une carte car les informations sont stockées en clair ou peuvent être chiffrées à l’aide de la clé contenue dans le lecteur. Même si un attaquant ne disposait pas de la clé, depuis la loi universelle de la rétro-compatibilité , les lecteurs non chiffrés fonctionnent aussi.

Afin de sensibiliser leurs clients , les deux chercheurs ont construit la BLEKey, qui fait la taille d’une pièce de monnaie. Cette clé doit être intégrée au sein du lecteur. Ce petit élément est greffé sur l’interface Wiegand (sur les deux fils où transitent les informations d’authentification). Vidéo à l’appui, les chercheurs nous ont démontré qu’il était possible de l’installer en moins d’une minute.

Une fois la clé en place, un attaquant peut ainsi récupérer l’ensemble des cartes utilisées. Il peut ainsi créer une nouvelle carte puisque le chiffrement a été cassé. Il peut également ouvrir la porte à distance au travers d’un téléphone via Bluetooth, ou réaliser une attaque de type déni de service.

Un moyen pour contrer ces attaques est de limiter l’accès aux lecteurs. Par exemple, l’hôtel MGT à Las Vegas a encastré ses lecteurs afin qu’ils ne soient pas accessibles. Néanmoins, les chercheurs conseillent vivement de changer de fabricant et de se diriger vers du matériel plus sécurisé .

Silently Breaking ASLR In The Cloud, par Antonio Barresi, Kaveh Razavi, Mathias Payer & Thomas Gross

SLIDES – PAPER

Cette présentation technique avait pour objet d’exposer des vulnérabilités mémoire au sein de la fonctionnalité appelée  Memory Deduplication . Cette dernière est généralement employée au sein des hyperviseurs afin d’augmenter les performances. Elle permet de fusionner deux pages mémoire de deux VM différentes. L’hyperviseur regroupe les données de plusieurs VM au sein d’une même page mémoire.

En exploitant une vulnérabilité de conception, les chercheurs parviennent à déterminer l’adresse mémoire d’une dll (par exemple ntdll.dll) d’une autre VM contenue au sein de l’hyperviseur. Par ce biais, un attaquant est en mesure de tourner l’ASLR (génération aléatoire des adresses mémoires) au sein des différents systèmes d’exploitation. Cette vulnérabilité est une prouesse technique, mais ne représente pas un réel danger. Elle se résume à une simple fuite d’information. Néanmoins, ces informations peuvent être cruciales pour le développement d’un exploit. Les chercheurs ont développé un outil nommé CAIN afin d’exploiter cette faille. Une démo de l’outil a été réalisée au cours de la présentation.

L’attaque se décompose en 4 phases :

1. Calcul de l’heuristique : en fonction du système d’exploitation, et du serveur, les chercheurs calculent un temps de réponse seuil. Ce temps de réponse permet de déterminer, lors d’une écriture, si la page mémoire a été mergée ;
2. Création des pages mémoires : le chercheur va déterminer l’adresse de l’exécutable ou de dll dont il souhaite obtenir l’adresse. Il va ensuite générer la première page mémoire associée à la dll choisie. En effet, cette première page mémoire contient l’adresse de la dll (imagebase). L’attaquant va générer autant de pages mémoires que d’adresses possibles. Ceci représente 2^19 soit 524 288 possibilités ;
3. Test d’écriture au sein des pages mémoires : une fois l’ensemble des pages mémoires générées, l’attaquant va réaliser un test d’écriture au sein de ces dernières. Si le temps de réponse est supérieur à celui calculé lors de l’étape 1, la page mémoire est considérée comme ayant été fusionnée ;
4. Gérer le bruit : cette technique génère beaucoup de bruit. Il faut donc répéter l’étape 3 pour réduire le nombre de pages mémoire. Au bout de quelques itérations, il ne reste plus qu’une seule page mémoire. L’attaquant connaît ainsi la page mémoire de la dll.

Pour l’instant, il n’existe qu’une seule parade contre cette vulnérabilité : désactiver cette fonctionnalité de votre hyperviseur préféré :-).

Watching The Watchdog: Protecting Kerberos Authentication With Network Monitoring, par Tal Be’ery & Michael Cherny

 SLIDES – PAPER

Cette présentation a consisté en la réalisation d’un état de l’art sur les attaques affectant le protocole Kerberos utilisé par Windows.

Le protocole Kerberos est utilisé pour toute authentification sur le domaine. En effet, de nombreux échanges, au travers de ce protocole, sont réalisés lors de l’ouverture d’une session entre votre ordinateur et le contrôleur du domaine. Ce protocole est donc très intéressant pour un attaquant souhaitant prendre le contrôle de cette machine. À ce jour, il existe 4 attaques connues à l’encontre de ce protocole.

• L’attaque  Skeleton-Key

Cette attaque a été nommée par Dell Secureworks en 2015, lors de la découverte d’un malware (Skeleton-Key) qui avait infecté un contrôleur de domaine. Ce malware modifiait le comportement du contrôleur de domaine et ajoutait une clé secrète appelée Skeleton-Key, permettant à un attaquant de se connecter à n’importe quel serveur ou poste de travail relié au domaine. De plus, cette attaque est transparente pour l’utilisateur puisque ce dernier pourra toujours se connecter à l’aide de son ancien mot de passe. Si aucun des deux mots de passe (celui de l’utilisateur, ou la Skeleton-Key) n’est renseigné, l’authentification échoue.

Pour réaliser cette attaque, le malware va affaiblir l’algorithme de chiffrement (en RC4) utilisé lors des échanges des tickets Kerberos. En effet le protocole RC4 n’utilise aucun sel lors du processus de chiffrement des tickets Kerberos. Pour ce faire, il va installer un hook pour faire croire au contrôleur de domaine qu’aucune clé de chiffrement AES n’est disponible et ainsi forcer l’utilisation de l’algorithme RC4.

Cette attaque affecte uniquement les contrôleurs de domaine. L’exploitation de cette vulnérabilité ne nécessite pas l’installation de malwares supplémentaires sur les éléments ciblés.

• L’attaque  Golden Ticket

Cette attaque permet de garder un accès en tant qu’administrateur du domaine, même si l’ensemble des mots de passe du contrôleur du domaine a été changé. Pour ce faire, l’attaquant doit obtenir le hash du compte krbgt. En effet, les tickets TGT échangés sont signés à l’aide de cette clé. Ces tickets contiennent la PAC qui décrit l’ensemble des informations de sécurité de l’utilisateur (notamment les groupes auxquels il appartient).

L’attaque consiste donc à forger un ticket TGT avec une PAC choisie. Un attaquant obtenant un jour un accès au contrôleur de domaine pourra ainsi garder l’emprise sur ce dernier. C’est donc une vulnérabilité de conception et d’implémentation du protocole Kerberos. Aucune parade n’est à ce jour disponible.

• La vulnérabilité  MS14-068

Cette attaque a été identifiée en novembre 2014 par Kaspersky au sein du malware Duqu. Elle permet à un attaquant disposant des droits administrateurs local de créer un ticket TGT et ainsi devenir contrôleur du domaine. Cette vulnérabilité provenait d’une mauvaise implémentation de la vérification de la signature des tickets Kerberos. Un attaquant pouvait signer son ticket kerberos en utilisant un simple algorithme de hashage (comme md5), et ainsi ne pas utiliser de clé.

• La vulnérabilité  Diamond PAC

Cette attaque est similaire à celle du GoldenTicket. La différence réside dans le fait que l’attaquant ne forge pas un Ticket Kerberos complet, mais injecte sa PAC lors des échanges avec le contrôleur de domaine. Cette attaque est donc la plus discrète des 4.

Les deux chercheurs ont également présenté l’outil de détection nommé Microsoft Advanced Threat Analytics. Il intègre une détection de ces attaques au niveau réseau. En inspectant les échanges réseau, l’outil est capable de détecter si une de ces attaques est exploitée.

Jour 2

(In-)Security Of Backend-As-A-Service, par Siegfried Rasthofer & Steven Arzt

SLIDES – PAPER

Cette présentation avait pour vocation de mettre en évidence les problématiques de sécurité liées à l’utilisation d’un service de type Backend As A Service (BAAS). La plupart des start-ups visant ce secteur ont été créés en 2011, par exemple Parse, BAASBox ou Cloudmine. Néanmoins, les géants du web ont vite compris l’intérêt de ce marché et ont lancé leur propre service comme Amazon. Facebook a également racheté la société Parse pour 85 millions de dollars.

L’authentification à ces services repose sur 2 clés :

• Access_keyid :  sign request 
• Secret_key :  like a password

Le principal problème lié à l’utilisation de ce type de service est la mauvaise utilisation de ces clés d’authentification. Ceci s’explique par la complexité des documentations des API disponibles. En effet, ces 2 clés sont nécessaires pour identifier l’application auprès du BAAS. Les chercheurs Siegfried Rasthofer et Steven Arzt ont donc recherché la présence de ces clés au sein des applications Android disponibles. Afin de pouvoir analyser l’ensemble des applications Android, les chercheurs ont développé un outil. Il réalise 3 actions principales :

1. Identifier la présence des librairies de type BAAS (Amazon ou Parse)
2. Identifier les API utilisées (comme la méthode initalize() qui requiert la présence des 2 clés d’authentification)
3. Extraire les informations utiles depuis les méthodes des API utilisées. Afin d’obtenir de bons résultats et éviter les faux positifs, ils ont implémenté une méthode hybride qui combine l’analyse statique et dynamique. Cette technique nommée HARVESTER est détaillée au sein d’une thèse publiée (Harvesting Runtime Data in Android Applications for Identifying Malware and Enhancing Code Analysis).

Les résultats de l’étude sont assez impressionnants. Plus de 56 millions de données clientes ont été récoltées (photos, messages privés, sauvegardes, données de jeux, etc.). Ils ont également identifié 2 malwares bancaires qui réalisaient de l’interception SMS. Les développeurs stockaient au sein du BASS les prochaines cibles de leurs attaques.

Après leur découverte, les chercheurs ont contacté les différents fournisseurs de service afin qu’ils puissent prévenir les clients concernés. Le 18 mai 2015, ils ont donc communiqué les identifiants d’une centaine de clients. Les chercheurs ont ensuite revérifié 6 mois plus tard et, c’est avec surprise qu’ils ont constaté qu’aucun des développeurs n’avait enlevé les clés de leurs applications, et que, de nouvelles applications étaient concerné…

Pour réduire les dégâts en cas de divulgation de ces clés, les chercheurs préconisent de dériver des clés pour chaque application et chaque utilisateur. Par ailleurs, les chercheurs espèrent que les fournisseurs vont améliorer leur documentation afin que les développeurs ne commettent plus ces erreurs. De même, il préconise la mise en place d’alerte systématique visible par les développeurs et les utilisateurs basés sur divers critères de sécurité (par exemple lors de l’utilisation de la clé root). Il préconise également la mise en place d’une obligation légale pour les fournisseurs de Backend.

Bypassing Local Windows Authentication To Defeat Full Disk Encryption, par Ian Haken

SLIDES – PAPER

Lors du dernier patch (10 novembre 2015), Microsoft a corrigé une vulnérabilité liée à Kerberos (MS15-122 / CVE-2015-6095) affectant l’ensemble de ses systèmes d’exploitation (de Vista à Windows 10). En effet, le chercheur Ian Haken est parvenu à déverrouiller une station de travail, même si le disque dur de ce dernier est chiffré. La configuration du poste était un disque dur chiffré avec Bitlocker utilisant une puce TPM (élément hardware intégré au sein du poste qui va stocker la clé de chiffrement). Dans cette configuration, l’ensemble des attaques classiques de type sethc.exe n’est pas possible.

Pour comprendre cette vulnérabilité, il faut connaître les différentes étapes lors de l’authentification d’un utilisateur du domaine sur un poste :

1. Lorsque l’utilisateur renseigne son mot de passe, une demande de ticket Kerberos (TGT) est émise vers le contrôleur de domaine ;
2. Le contrôle de domaine crée un ticket Kerberos (Ticket TGT). Il est chiffré avec le mot de passe de l’utilisateur, puis renvoyé à l’utilisateur ;
3. Ce ticket est ensuite déchiffré par le poste utilisateur à l’aide du mot de passe qu’il vient de renseigner.

À ce stade, l’utilisateur obtient donc un Ticket Granting Ticket. Ce dernier sera utilisé lors de toute demande d’accès au lieu d’utiliser le mot de passe de l’utilisateur. Dans notre cas, l’utilisateur va émettre une nouvelle demande au contrôleur de domaine afin d’avoir accès à son poste :

1. L’utilisateur envoie une demande de Ticket Granting Service (TGS). Cette demande est signée à l’aide de la clé de chiffrement appelée machine key. Cette clé est générée lorsqu’un poste joint le domaine ;
2. Le contrôleur de domaine déchiffre la demande, à l’aide de la clé contenue au sein de l’Active Directory. En cas de validation, il renvoie un ticket TGS ;
3. Ce ticket TGS est ensuite vérifié par le poste. Si ce dernier est valide, la session de l’utilisateur est déverrouillée.

L’attaque consiste donc à simuler un contrôleur de domaine. Néanmoins, l’attaquant ne connait pas la clé de chiffrement du poste (machine key). Pour contourner cette restriction, l’attaquant va utiliser une fonctionnalité de Windows, introduite avec Windows XP, appelé MSCache. Ce mécanisme permet à un utilisateur ne pouvant pas contacter le domaine de pouvoir s’authentifier sur son poste. Par exemple, lorsqu’un utilisateur essaye de se connecter sur son poste lorsqu’il est en déplacement.

En effet, un cache est présent sur le poste. Il contient les entrées chiffrées, dont un hash de l’utilisateur réalisé à partir du nom d’utilisateur et son mot de passe. L’astuce est donc d’injecter, au sein de ce cache, une entrée avec un nouveau mot de passe. Pour ce faire, l’attaquant va simuler un contrôleur de domaine en créant une entrée utilisateur.

Pour exploiter cette vulnérabilité :

1. L’attaquant simule un Active Directory. Il ajoute, au sein de ce dernier, l’utilisateur avec lequel il souhaite s’identifier sur le poste. Il configure le compte avec un mot de passe arbitraire expiré puis la date d’expiration du mot de passe (par exemple 01/01/2001) ;
2. L’attaquant se connecte sur le poste en renseignant le mot de passe qu’il vient de configurer. Dû à la configuration de la date d’expiration, l’attaquant doit ainsi changer le mot de passe du compte ;
3. Une fois le changement effectué, un message s’affiche expliquant à l’utilisateur que son poste n’est pas connu du domaine. En effet, le poste n’a jamais joint le faux domaine que l’attaquant vient de créer. L’utilisateur ne peut donc pas obtenir de Ticket TGS lui autorisant à s’authentifier sur le poste ;
4. L’attaquant débranche l’ordinateur du réseau, et re-renseigne le mot de passe fictif du compte. L’attaquant est maintenant authentifié sur le poste.

Mais pourquoi l’attaquant a été authentifié sur le poste ? À la fin de la seconde étape, Windows injecte une entrée MSCache, sans vérifier que l’authentification a été validée. Le patch MS15-122 corrige cette erreur. Ainsi, l’entrée MSCache ne sera injectée que lorsque l’utilisateur sera  réellement  authentifié (obtention d’un ticket TGS valide).

Le chercheur recommande donc de sécuriser le chiffrement BitLocker en utilisant un code PIN ou un déverrouillage à l’aide d’une clé USB (certificat). Si ces mesures de sécurité sont appliquées, cette attaque n’est pas envisageable puisqu’il faudrait contourner cette première authentification.

Nous attendons avec impatience la prochaine édition de cette conférence. En attendant, rendez-vous dans le prochain numéro de l’ActuSécu pour un résumé complet et détaillé de cette conférence.