25 octobre 2019

Retour sur la Hack.lu – Jour 3

Who contains the containers

Par Ioana Andrada & Emilien

Cette conférence présentée par Ioana Andrada et Emilien Le Jamtel (CERT-EU) a pour objectif de montrer les dangers des technologies de conteneurisation lorsqu’elles ne sont pas maîtrisées par les administrateurs ou développeurs. Tout d’abord, ils ont commencé par rappeler l’extrême facilité de déployer des services à l’aide de cette technologie. Comme très souvent, qui rime avec « facile à déployer », rime avec « facile à compromettre ». En effet, dans le cas précis, un seul clic suffit pour être compromis !

Ensuite, afin d’amener à bien les explications techniques, ils ont rappelé les vulnérabilités les plus courantes récentes (CVE de 2019) et les configurations non sécurisées sur les technologies de conteneurs, ainsi que leur exploitation. La surface d’attaque de ces technologies peut se résumer à deux composants :

  • La technologie en elle-même (docker, rkt, etc.)
  • L’outil d’orchestration de conteneurs (kubernetes par exemple)

Le pire des scénarios pour les conteneurs est la possibilité pour un conteneur malveillant ou compromis de contourner la sécurité mise en place pour attaquer le système hôte. Cela est arrivé avec une vulnérabilité sur runC (CVE-2019-5736 : rupture du conteneur runc). Ce type de vulnérabilité est très critique, car permet de prendre le contrôle du système hôte et pourrait aboutir à la compromission d’autres serveurs atteignables via des mouvements latéraux.

Cependant, dans certaines situations, il est possible d’abuser des API qui peuvent être exposées sans authentification. Les API (2375/TCP et 2376/TCP) sont destinées à automatiser les tâches. Elles permettent notamment de démarrer, supprimer ou configurer les conteneurs ou le système hôte. Ainsi, une simple requête POST peut permettre de déployer et démarrer une image Docker. Les images sont automatiquement téléchargées sur Docker Hub (si l’image n’est pas présente localement).

Pour la consultation des conteneurs installés sur la machine ciblée, il suffit d’une requête GET (/pods) sur l’interface API du docker. L’étude menée par les deux présentateurs a ainsi consisté à développer un script permettant d’extraire les informations sur les conteneurs disponibles, afin de mettre en lumière ceux potentiellement « indésirables » :

Parmi ce qui a été identifié, plusieurs images ont été considérées comme malveillantes :

  • xmrig
  • zuulu2

La plupart des actions malveillantes effectuées et la réalisation de minage de cryptomonnaie (Monero).

Se pose alors la question de comment se protéger de ces images malveillantes. Pour cela, les auteurs préconisent les actions suivantes :

  • Utiliser uniquement des images signées
  • Valider la configuration système de l’image (mises à jour régulières des correctifs de sécurité)
  • Surveiller constamment les activités

Concernant l’hôte, il est recommandé également de :

  • Durcir son système
  • Mettre à jour le système avec les derniers correctifs de sécurité
  • Contrôler l’accès des utilisateurs
  • Auditer l’activité du conteneur

Surveiller l’activité du conteneur est essentiel pour identifier les incidents de sécurité et fournir des pistes d’audit. Les environnements conteneurisés nécessitent une journalisation sur plusieurs couches : l’hôte, l’orchestrateur de conteneurs et le conteneur lui-même.

Pour cela, il existe différents outils qui aident à surveiller l’environnement confiné :

  • L’API Docker (collecte la fonction de surveillance de base des conteneurs Docker)
  • Le conteneur conseiller (cAdvisor) – il s’agit d’un conteneur qui peut collecter, traiter, agréger et exporter des informations relatives à l’exécution de conteneurs
  • Prometheus (peut générer des alertes, en fonction des règles d’alerte appliquées aux données d’entrée)

Pour conclure, les services seront de plus en plus utilisés, car facilitent grandement la tâche de tout le monde. Néanmoins, il est important de garder en tête et de se préoccuper de l’impact potentiel de ces menaces, surtout lorsque ces services ne sont pas correctement configurés (configuration par défaut).

Piercing the Veil Server Side Request Forgery attacks on Internal Networks

Par Alyssa Herrera Perez

Alyssa a commencé sa présentation avec une introduction à l’activité de bug Bounty, il s’agit des programmes proposés par des éditeurs de logiciels ou des entreprises de services technologiques ou par des sociétés spécialisées.

Ces sociétés invitent les chercheurs, hackers et spécialistes de la cybersécurité du monde entier à découvrir des vulnérabilités sur tout ou partie de leurs logiciels/périmètre. À la clé : une récompense monétaire dont le montant évolue en fonction de la criticité de la vulnérabilité trouvée.

Ensuite, Alyssa a présenté une définition de la vulnérabilité SSRF : à partir d’une application web vulnérable, une SSRF permet d’interagir avec le serveur, afin d’en extraire des fichiers et de trouver ses autres services actifs. Cela ne s’arrête pas là. Il est également possible de scanner le réseau interne afin d’en cartographier les IP et Ports ouverts. Cela permet à un attaquant d’accès aux services et aux ressources internes sensibles.

Alyssa nous a présenté ensuite des éléments exploitables, à savoir :

  • Les services internes tels que Kubernetes, Redis…etc.
  • Les appels API sur les instances cloud

La deuxième partie de la présentation explique l’exploitation de cette vulnérabilité sur le département de la défense des États-Unis, la chercheuse a initié son travail par la recherche des produits vulnérables en utilisant les dorks, elle a ciblé les domaines militaires, l’exemple suivant a été utilisé dans sa recherche :

Inurl :secure/Dashboard.jspa        
Site :*.mil

La phase de reconnaissance en utilisant ces dorks a permis à la chercheuse de définir quelques domaines vulnérables sur des instances AWS, elle a expliqué que n’importe quelle instance AWS pouvait interroger une IP et recevoir des informations relatives à cette instance et même des informations de compte. Ses recherches lui a ensuite permis de lister les adresses IP et des informations sur les serveurs privés. Elle a pu détecter ensuite des erreurs permettant de confirmer la présence d’une vulnérabilité SSRF.

Selon Alyssa les éléments suivants ont permis la découverte et l’exploitation de la vulnérabilité :

  • La configuration faible des métadonnées d’instance AWS
  • L’absence de segmentation réseau
  • L’absence des patchs et des correctifs de sécurité pour les services

Enfin, pour conclure sa présentation, Alyssa a dressé la liste des remédiations afin de mitiger le risque relié à l’exploitation de la SSRF


Intro to dark arts (CTF Workshop)

Par Shruti Dixit, Geethna T K

Shruti Dixit et Geethna T K, deux étudiantes en ingénierie informatique nous présente un workshop sur les CTFs (Capture The Flag) afin d’avoir une introduction sur le sujet. Ces étudiantes font également partie d’une équipe indienne s’appelant TeamShakti réalisant des CTFs partout dans le monde, composé exclusivement de femmes.

Le workshop parle donc principalement des CTFs, de leur déroulement et de leurs subtilités. Ces compétitions de hackers ou le but est de récupérer des drapeaux s’organise partout dans le monde et sont populaires dans le milieu de la sécurité offensive.

Après une introduction de certaines notions essentielles nécessaire dans ce domaine, la plateforme de CTF est présentée avec les challenges :

Dans la capture d’écran ci-dessus, on peut observer la catégorie « Pwn ». Cette catégorie représente l’exploitation de binaire, qui a pour but de détourner l’utilisation d’un programme déjà compilé. Souvent, l’exploitation de ces binaires est faisable via des débordements de tampon ou « buffer overflow ».

Pour les plus à l’aise en mathématiques, il y avait également la partie cryptographie. Le but d’un challenge de ce type est généralement de déchiffrer un code afin de trouver le drapeau.

Enfin, il y avait une partie de « Reverse Engineering », ou rétro-ingénierie. Cette partie est sur l’analyse de binaire et constitue également une partie majeure des CTFs. Afin de pouvoir faire des challenges de cette catégorie, il faut connaître le langage assembleur. En effet, les binaires désassemblés sont présentés de cette manière sous le logiciel IDA :

Pour conclure, ce workshop est intéressant, car il permet de s’introduire à ce monde jugé difficile d’accès, et ce pour différents niveaux. Il est vrai que réaliser ce type de challenges demande quelques connaissances au préalable, mais cette session peut permettre aux intéressés de commencer des challenges techniques et qui sait, peut-être continuer dans un vrai CTF ?

Lien vers la présentation : https://bit.ly/35NhIOk  

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *