Le pôle sécurité s’est rendu à l’édition 2018 de la BlackHat Europe qui s’est déroulée à Londres du 3 au 6 décembre au centre de congrès ExCel. Cet évènement est la version européenne de la célèbre BlackHat USA qui se tient également chaque année à Las Vegas. Ce que l’on retire de cet événement, c’est la qualité des conférences qui ont été proposées.
Nous avons eu la chance d’être présents le 5 et 6 décembre pour assister à pas moins de 7 conférences au total que nous allons vous présenter bien évidemment :).

No Free Charge Theorem 2.0: How to steal private information from a mobile device using a powerbank

Cette présentation nous a été faite par Riccardo Spolaor, docteur à l’université d’Oxford, UK.
L’objectif global de cette présentation était de nous présenter ses travaux sur l’exfiltration de donnée d’un téléphone en utilisant une station de recharge, ou un dispositif de batterie externe pour recharger un smartphone.

Riccardo commence sa présentation en dressant le constat suivant: l’ère où nous partions à la recherche d’une borne Wifi est résolue, aujourd’hui tout le monde possède un forfait avec un forfait internet presque illimité pour pas cher. Désormais, c’est la quête à la borne de recharge de nos smartphones.

En effet, les applications deviennent de plus en plus poussées et consomment donc plus de batterie.
Il en résulte la création de stations de recharge pour nos smartphones accessibles à tous.
Riccardo enchaîne ensuite sur un rapide rappel du standard USB et notamment les 4 pins présents sur le port, 2 pour les données et 2 pour l’énergie. Il en découle donc des protections existantes pour nos smartphones à savoir des câbles USB spécialement pour la recharge, ne possédant que les 2 pins d’énergie: les “préservatifs USB”.

Ensuite, Riccardo nous a présenté sa recherche sur le comportement du courant et de la tension lors de la recharge d’une batterie de smartphone en USB.
Ce qui est intéressant c’est que les courbes de tension et de courant indiquent un pattern. Au début de la charge, le courant monte progressivement jusqu’à atteindre une constante tandis qu’en fin de charge la tension est constante puis finit par tomber progressivement.
Une autre information intéressante, lorsque l’écran est allumé pendant la charge il en résulte un pic de courant. On observe le même phénomène lors d’un pic d’utilisation CPU.

On peut donc aisément produire un état booléen 0 ou 1 (courant faible et courant en pic) et du coup, on devine assez facilement la suite de l’attaque. Il suffirait à un attaquant d’installer une application frauduleuse sur le smartphone de sa victime pour en exfiltrer des secrets, à condition d’utiliser une power bank qui est capable de stocker les résultats envoyés par l’application.
Cette application peut être une application légitime couplée avec le programme de l’attaquant, qui s’occupe simplement de récupérer le secret, l’encoder en binaire et produire les pics de CPU permettant la diffusion de celui-ci. Si possible, l’application aurait également accès aux informations sur la batterie dans le but de connaître les informations suivantes:

• L’écran est-il éteint ?
• ADB est-il actif ?
• Le téléphone possède au moins 50% de batterie ?
• La powerbank malicieuse est-elle connectée ?

Riccardo présentera finalement les solutions existantes de power monitor qui coûtent environ 830$ et qui permettent de mesurer le courant. Et bien évidemment sa solution faite main basée sur un sensor et un arduino le tout avec un module GSM ou wifi voir même une carte SD (pour stocker les données ou les transmettre) pour seulement 17£.
Enfin, le présentateur finit par la recommandation principale pour se prémunir de ce genre d’attaques qui est tout simplement d’éteindre son téléphone lorsqu’on le recharge !

Real-time detection of attacks leveraging Domain Administrator privileges

La présentation a été réalisée par le Secure Information Society Research Group of the University of Tokyo (SiSOC) et avait pour but de nous expliquer deux méthodes de détection d’attaque sur un DC (Domain Controller) et plus généralement au sein d’une infrastructure de domaine Windows. La première étant la classique en se basant sur des signatures et la seconde, objet de leur recherche, grâce au machine learning.
La conférence nous refait une petite introduction sur le monde de l’AD (Active Directory) en nous indiquant que c’était la cible principale des attaquants.
L’objectif étant pour celui-ci de créer son “Golden Ticket Kerberos” dans le but de se faire passer pour un administrateur du domaine légitime, et donc, de ne pas lever d’alerte. En réalisant cette attaque, on devient quasi tout puissant sur le domaine.
Pour rappel, un Golden Ticket est un ticket TGT (Ticket Granting Service) légitime qui dure 10 ans et qui donne les droits administrateur. Il n’est pas nécessairement trivial de le détecter surtout si l’attaquant est admin du DC. Il n’y a aucune différence au niveau des droits conférés entre un administrateur légitime et un attaquant possédant un Golden Ticket.
L’université de Tokyo nous présente ensuite son produit qui se base à la fois sur les signatures et le machine learning en résumant l’avantage et inconvénient de chacun:

• Signatures: Ratio correct de détection, mais de nombreux faux positifs
• Machine learning: Ratio de détection bien plus élevé, mais requiert un apprentissage un peu chronophage

Leur outil se concentre sur le contrôleur de domaine et relate des évènements qui peuvent être suspicieux comme un compte qui va subitement gagner des privilèges par exemple.
Un focus sur chacune des méthodes avec un peu plus de détail nous a été proposé.

• Signature:
  • Des signatures d’exploit par exemple celui de la MS14-068
  • Des outils tels que net.exe ou whoami.exe voir tasklist.exe (même si ce n’est pas toujours pertinent)
  • Utilisation d’une ressource partagée
  • ST request sans requête TGT préalable
• Machine learning:
  • Besoin d’un apprentissage long pour diminuer les faux positifs
  • Idée de se baser sur les process (Creation, Operation attempted on a privileged object)
  • Utilisation du “one-hot” encoding
  • Utilisation de One-class SVM en tant qu’algorithme

Pour finir, l’interface de leur outil qui se base sur la stack ELK (Elasticsearch Logstash Kibana) pour la gestion des évènements et la remontée des alertes.
L’outil est disponible sur leur Github

Where 2 Worlds Collides: Bringing Mimikatz et al to Unix

Cette conférence nous a été présentée par Tim (Wadhwa) Brown responsable du laboratoire de recherche de CISCO (ex Portcullis). Cador de la sécurité il a plus de 150 CVE à son nom. Résultat de 9 mois de recherches (et toujours en cours).
Le constat mis en avant lors de cette présentation est qu’aucune des 2 parties (Unix et Windows) ne comprend l’impact potentiel de l’un sur l’autre et qu’Unix est un moyen de compromettre un AD dans le cadre d’un réseau interne multi OS.
Tim nous présente l’état de l’art de l’intégration de systèmes UNIX au sein d’un environnement AD

Vient ensuite la présentation de Vintela Authentication Service qui est un service qui permet à un environnement Unix de s’authentifier sur un AD Microsoft.
Pour ainsi dire, Tim nous explique que finalement la sécurité des environnements Windows n’a pas arrêté de progresser au fil du temps alors que la sécurité sous Unix se base toujours sur des concepts des années 70 à savoir les permissions unix (UIDs et GIDs).
D’ailleurs, chaque version de Windows intègre des mesures de sécurité supplémentaires

• Windows 8.1:
  • Mode d’admin restreint pour RDP
  • Protection LSA (Local Security Authority)
  • Groupe de sécurité pour utilisateurs protégés
  • TPM (Trusted Platform Module)
• Windows 10:
  • Isolation des credentials LSA

Il met en avant ses pistes de réflexion sur les problèmes de sécurité liés aux machines UNIX intégrés dans une AD:

• Souvent, les machines UNIX utilisent des applications qui souffrent de dettes techniques
• Les identifiants AD sont envoyés over SSH

Vient ensuite le détail de sa recherche sur plusieurs module de sécurité utilisés sous UNIX

SSSD: System Security Services Daemon

Outil open source lancé en root qui s’intègre avec SELinux, mais qui souffre de plusieurs attaques potentielles:

• Vol de hash depuis le file system
• Vol de hash / mot de passe depuis la mémoire
• Attaque sur le IPC (Inter Process Communication)

Il a quand même plusieurs CVE qui lui sont associés: 2018-10832 / 2017-12173 / 2013-0219

Vintela Authentication Service

Outil propriétaire lancé en “daemon”, mais qui ne drop pas un vrai UID 0 et ne s’intègre pas avec SELinux, mais qui souffre également de plusieurs attaques potentielles:

• Vol de hash depuis le file system
• Vol de hash / mot de passe depuis la mémoire
• Attaque sur le IPC (Inter Process Communication)

LDAP

Potentielles attaques:

• Vol de hash / mot de passe depuis la mémoire
• MiTM à cause d’une configuration erronée du forcing SSL
• Injection à cause d’une mauvaise validation de l’input

Kerberos

Potentielle attaque: Vol des tickets depuis le file system
A ce stade il nous présente finalement son outil “Linikataz” qui n’est évidement pas sans rappeler le nom de l’outil de Benjamin Deply (GentilKiwi) “Mimikatz”.
Celui-ci requiert évidemment les droits root sur la machine et permet de récupérer des hashs, des mots de passe et des tickets !
D’ailleurs il explique qu’il est possible de récupérer des hashs simplement en utilisant des commandes linux basiques telles que “find” et “cp” ! En revanche, les utiliser c’est une autre histoire …

• SSSD: Possible de récupérer les hashs directement et les envoyer à John de manière très simple

• Vintela: Se base sur une db SQLite, utilise des hashs sur mesure (sha256 + sel avec le UUID) qu’il a dû reverser à la main. Il en a donc profité pour écrire un parser John The Ripper

L’outil Linikatz est disponible sur Github 
Tom va finir sa présentation sur une liste de recommandations contre ce type d’attaque

Recommandations:

• Permissions:
  • Supprimer les privilèges inutiles
  • Ne pas laisser des sockets ouverts en écriture pour tout le monde
  • Ne pas laisser des métadonnées et configurations en lecture pour tout le monde
• Gestion de la mémoire:
  • Hardener ses binaires ! (Canaries, ASLR et sandboxing)
  • Protéger les zones sensibles (Restreindre ptrace(), utiliser un memset() pour nettoyer la mémoire après usage)
• Cryptographie:
  • Utiliser des comparaisons avec les constantes de temps ou encore rendre les comparaisons cryptographiques obscures
  • Utiliser KDF (Key Derivation Function) plutôt que les hashs pour stocker des identifiants (pensez à utiliser plusieurs itérations !)

Pour conclure, Tim revient sur ce que cette recherche lui a permis d’apprendre à savoir:

• Les hashs et mots de passe ne sont pas si bien protégés sous UNIX
• Les processus sont mal protégés
• Les relations de confiances sont mal comprises
• AD sur UNIX requiert un bon nombre d’outils pour parler avec le DC (pas juste Kerberos)
• RTFM !
• Besoin de plus de recherche sur le sujet !

Container Attack Surface Reduction Beyond Name Space Isolation

Cette présentation a été réalisée par trois chercheurs d’Accenture Security et relate les différents problèmes de sécurité rencontrés lors de l’utilisation de conteneur (Docker ou pas).
On commence par un récapitulatif de la différence entre une VM (Virtual Machine) et un conteneur à savoir qu’une VM est un système différent avec son propre kernel alors qu’un conteneur est un système qui partage le kernel avec son hôte.
Évidemment, toute image Docker se base sur une image dite “base” (par exemple Ubuntu ou Debian). Il en résulte assez rapidement un constat simple: les applications qui sont conteneurisées deviennent des gigantesques manoirs avec plein de portes d’entrée.
L’idée sera donc évidemment de réduire un maximum ses portes d’entrée jusqu’au strict minimum nécessaire à l’application.

Un conteneur doit exister pour un but précis et doit utiliser uniquement les binaires dont il a besoin. Voici le leitmotiv de ces chercheurs d’Accenture. Et pour répondre à ce besoin précis, ils ont créé une application qui permet de générer une image Docker optimisée.
Ils procèdent en deux phases:

• Déterminer les composants requis pendant l’exécution de l’application
• Générer une image BMB (Bare Minimum Binaries)

Après une démo réussie, on nous présentera les résultats de leur image générée !

Cela permet de mettre en avant quelques soucis par rapport aux scanneurs de vulnérabilités sur les images Docker (comme Clair de CoreOS par exemple). En effet, ceux-ci se basent sur les entrées dans les gestionnaires de paquets et ils comparent les versions avec les CVE.
Par conséquent, un simple changement dans le nom d’un fichier contourne la détection. La solution proposée est la création d’une politique de liste blanche de fichiers autorisés: les MAC (Mandatory Access Control) policies.
Cependant, supprimer les fichiers qui ne sont pas utilisés ne permet pas de se prémunir des attaques par ROPchain, puisqu’on se sert du code utilisé par l’application directement.
Lors d’un appel à une API Windows les programmes n’utilisent évidemment pas toutes les fonctions présentes pourtant elles sont toutes importées et donc utilisables !
L’idée de nos chercheurs est donc d’importer uniquement les fonctions nécessaires et “non dangereuses” d’un point de vue sécurité.

Jour 1 BlackHat London 2018 : fin

Et c’est ainsi que s’achèvera notre première journée à la BlackHat. On aura eu des présentations couvrant de multiples sujets toutes aussi intéressants les uns que les autres. Nous avons été agréablement surpris par le niveau technique de certaines conférences.
BlackHat London 2018 : Jour 2

En apprendre plus :

• Initiation à la sécurité