Sensibilisation : Exploitation de vulnérabilités avancée 16 mai 2019

Sommaire Présentation & Actualités I. Présentation & Actualités Scénarios d’attaque Recommandations / Ressources Conclusion I. Présentation & Actualités

Présentation Ancien pentesteur Cédric BERTRAND Cedric.bertrand@sante.gouv.fr https://www.linkedin.com/in/c%C3%A9dric-bertrand-20627b139/ Ancien pentesteur Actuellement expert sécurité à l’Asip Santé Sécurité offensive (pentests, scans de vuln, audit de configuration, etc.) Sécurité défensive (durcissement, devsecops, analyse de malwares, incident de sécurité, surveillance et monitoring réseau, etc.) Participe à la cellule ACSS (Accompagnement Cyber-sécurité des Structures de Santé) Créateur / Porteur de l’expérimentation du service cyber-surveillance Certifications : OSCP Web Application Penetration Testing eXtreme Computer Hacking Forensic Investigator … Professeur à l’université Cyber-sécurité Analyse post-incident

Sommaire Présentation & Actualités Scénarios d’attaque Recommandations / Ressources II. Scénarios d’attaque

Scénarios d’attaque Résumé Scénario n°1 : Petits oublis des développeurs Scénario n°2 : Comment l’exploitation d’une vulnérabilité peut entrainer la compromission du SI (ou d’une de ses parties) Scénario n°3 : Retour sur une vulnérabilité critique encore très présente Scénario n°4 : Injection SQL difficile à détecter Prendre le contrôle d’un serveur par un code malicieux contenu dans une image

Scénario n° 1 Les développeurs sont nos amis… Il faut les aimer aussi…

Scénario n° 1 Les développeurs sont nos amis… Il faut les aimer aussi… Du risque de la (mauvaise) configuration des serveurs de versionning… Les serveurs de développement permettent aux développeurs de suivre et de gérer des codes-source. Ils permettent de modifier et de suivre les évolutions des fichiers. Il existe plusieurs logiciels de ce type : SVN, GIT, Mercury, etc. Parfois ils se retrouvent sur le site web… Publiquement accessibles ou pas… Ok mais est-ce que c’est grave ?

Scénario n° 1 Les développeurs sont nos amis… Il faut les aimer aussi… Impacts A minima prise de contrôle du serveur

Scénario n° 1 Les développeurs sont nos amis… Il faut les aimer aussi… Impacts Dans certains cas, possibilité de rebond sur d’autres serveurs / prise de contrôle totale du SI

Scénario n° 1 Les développeurs sont nos amis… Il faut les aimer aussi… Et on a pas parlé de github… Plateforme collaborative pour développeurs Le plus grand espace de stockage de travaux collaboratifs dans le monde Permet le partage de ses codes-source…

Scénario n° 1 Les développeurs sont nos amis… Il faut les aimer aussi… Et on a pas parlé de github… Mais l’enfer est pavé de bonnes intentions… Potentiel souci(s) de sécurité ?

Scénario n° 1 Les développeurs sont nos amis… Il faut les aimer aussi… Et on a pas parlé de github… Des fichiers de configuration, données sensibles, base de données peuvent être utilisés dans le projet… Et du coup accessibles au plus grand nombre…. Des outils pour rechercher automatiquement les données sensibles dans les repositories git

Scénario n° 1 Les développeurs sont nos amis… Il faut les aimer aussi… Et on a pas parlé de github…

Scénario n° 1 Les développeurs sont nos amis… Il faut les aimer aussi… Et on a pas parlé de github…

Scénario n° 1 Les développeurs sont nos amis… Il faut les aimer aussi…

Scénario n° 2 Du git au root

Scénario n° 2 Du git au root Résumé Présentation d’un cas réel Audit sur un domaine et ses sous-domaines associés (~80 domaines) Découverte d’un serveur avec : Présence d’un site web avec un cms de type wordpress Service de base de données accessible Présence d’un répertoire git Présence d’identifiants de connexion à la base de données Prise de contrôle à distance du serveur Récupération des identifiants de la base de données (répertoire git) Connexion à la base de données avec les identifiants obtenus Ajout d’un compte administrateur Connexion à l’interface d’administration du site web avec le compte administrateur créé Installation d’un script de contrôle à distance et prise de contrôle du serveur Mauvaise gestion des droits utilisateurs et absence de correctifs -> accès à l’ensemble aux informations confidentielles

Scénario n° 2 Du git au root Etape n°1 : découverte d’un répertoire git et récupération des informations associées

Scénario n° 2 Du git au root Etape n°2 : connexion au serveur de base de données avec les identifiants découverts et ajout d’un compte administrateur

Scénario n° 2 Du git au root Etape n°3 : connexion à l’interface d’administration du site web et installation d’un script de contrôle à distance

Scénario n° 2 Du git au root Etape n°4 : prise de contrôle à distance du serveur et accès à des informations confidentielles

Scénario n° 2 Du git au root Résumé Sous-estimation de la gravité des vulnérabilités et surtout des interconnexions entre les différents systèmes du SI : Une fois un mot de passe découvert, possibilité de les ré-utiliser sur d’autres serveurs Une fois l’accès à un système obtenu, possibilité de rebond vers d’autres systèmes Une fois l’accès à un système obtenu, possibilité d’accéder à des informations très sensibles (mauvaise gestion des habilitations / droits sur les fichiers)

Scénarios d’attaque Petits points techniques Lors de prise de contrôle du serveur, les attaquants cherchent à obtenir un accès au serveur Shell Ouverture d’une session sur le serveur Connexion de la machine de l’attaquant sur le serveur Reverse-shell Ouverture d’une session sur la machine de l’attaquant Connexion du serveur sur la machine de l’attaquant

Scénario n° 3 De la nécessité de contrôler les entrées utilisateurs

Scénario n° 3 De la nécessité de contrôler les entrées utilisateurs

Scénario n° 3 De la nécessité de contrôler les entrées utilisateurs Qu’est-ce que la désérialisation Définition C’est un mécanisme permettant d’écrire des données présentes en mémoire (un objet par exemple) dans un format de données binaires permettant alors de rendre persistants l’élément via un stockage disque, une transmission réseau ou autre. Sérialiser un objet = transformer en un tableau d’octets Sauvegarder un objet peut être intéressant si création d’objet en mémoire gourmande en temps et en mémoire (sérialisation bcp plus rapide que la recréation) Peut être aussi nécessaire pour les appels à distance (SOAP, CORBA, etc.) Tous les langages orientés objet disposent de librairies de sérialisation : pickle (python), boost (C++), java.io (java), etc.

Scénario n° 3 De la nécessité de contrôler les entrées utilisateurs Processus de sérialisation Structure d’un flux d’objet sérialisé est définie par une grammaire Flux commence toujours par le nombre magique 0xaced (r00 en code byte), puis le numéro de version 0x005), puis un octet représentant le type de contenu (ici 0x73 pour un objet normal) Bytecode : désigne un flux d'octets binaire au format d'une classe java. Habituellement résultat de la compilation d’un code-source

Scénario n° 3 De la nécessité de contrôler les entrées utilisateurs Processus de désérialisation Désérialiser un objet = créer un objet à partir d’un tableau d’octets Objet reconstruit via appel à la méthode readobject() sur une instance d’objectInputStream

Scénario n° 3 De la nécessité de contrôler les entrées utilisateurs Vulnérabilité dans la désérialisation des données Les processus de sérialisation et de désérialisation Java ne manipulent que des données et non du code code des méthodes n’est pas sérialisé Nécessité que la machine virtuelle Java (JVM) qui désérialise ait exactement les mêmes classes (la même description et le même identifiant de sérialisation) dans son classpath que la JVM qui sérialise Attaquant exploitant une vulnérabilité de désérialisation Java va chaîner des méthodes Java de classes présentes dans le classpath de la JVM Objectif de l’attaquant : exécuter une commande système depuis le CLASSPATH fournir une méthode permettant d’exécuter du code telle que « Runtime.exec() » afin que celle-ci soit exécutée suite à son passage vers la méthode « readObject() ». Problème : pas possible directement pour des raisons de contexte d’exécution. pas possible de passer Runtime.exec() » directement à la méthode « readObject() » Solution : faire passer l’objet désiré vers une multitude de classes sérialisables (gadget chain / enchainement de code) jusqu’à arriver à la méthode Runtime.exec

Scénario n° 3 De la nécessité de contrôler les entrées utilisateurs Vulnérabilité dans la désérialisation des données Gadget chain : combinaison de l’appel de différentes méthodes accessibles à l’application, dans le contexte de la fonction chargée de traiter les entrées envoyées par l’utilisateur. combinaison de méthodes variable d’une application à l’autre, voire d’un contexte d’exploitation à un autre Exemple : Apache Commons Spring …

Scénario n° 3 De la nécessité de contrôler les entrées utilisateurs Exemple de gadget chain pour Apache commons

Scénario n° 3 De la nécessité de contrôler les entrées utilisateurs Outils de génération automatisé Outil qui permet la génération d’une charge malveillante. Ensuite injection de son contenu dans le champ repéré plus tôt. En théorie, l’application devrait alors exécuter la commande spécifiée sur le serveur distant

Scénario n° 3 De la nécessité de contrôler les entrées utilisateurs Méthodologie d’attaque Analyse de l’application Observation des chaines de caractères commençant par « rO0 » soumises au sein d’un champ attendant une entrée utilisateur Chaine de caractères qui est la représentation en base64 d’un objet sérialisé en Java. Chaque chaine commençant par «rO0 » (qui correspond au bytecode Java « ac ed » ) est un objet sérialisé Si découverte de cette chaine de caractère avec une entrée utilisateur Génération d’une charge malveillante avec l’outil Injection de la charge Prière ? 

Scénario n° 3 De la nécessité de contrôler les entrées utilisateurs

Scénario n° 4 De l’aveuglement des outils de sécurité Quelques vulnérabilités difficiles à détecter Mettez à jour !

Scénario n° 4 De l’aveuglement des outils de sécurité Présentation du cas Exemple avec une injection sql dans le paramètre user_id

Scénario n° 4 De l’aveuglement des outils de sécurité Présentation du cas Rappel Injection SQL : attaque qui consiste à modifier une requête SQL et à y injecter des commandes

Scénario n° 4 De l’aveuglement des outils de sécurité Petit focus sur les injections SQL (détection) Plusieurs types d’injections SQL Error-based Blind

Scénario n° 4 De l’aveuglement des outils de sécurité OWASP Test

Scénario n° 4 De l’aveuglement des outils de sécurité OWASP Test

Scénario n° 4 De l’aveuglement des outils de sécurité OWASP Test Heu du coup tout va bien ?!

Scénario n° 4 De l’aveuglement des outils de sécurité OWASP Test Non !!!

Scénario n° 4 De l’aveuglement des outils de sécurité Petit focus sur les injections SQL Type d’injections « indétectables » Injection second order… https://www.youtube.com/watch?v=yIK2_MpH1SY https://bertwagner.com/2018/03/20/how-to-steal-data-using-a-second-order-sql-injection-attack/ https://members.elearnsecurity.com/course/modules/299#272 Points d’injection Valeur du paramètre Et nom du paramètre !

Scénario n° 4 De l’aveuglement des outils de sécurité OWASP Test Injection sql présente dans le nom du paramètre (et non la vauleur)

Scénario n° 4 De l’aveuglement des outils de sécurité Interface d’upload Contrôles bien réalisés sur les extensions et le type de fichiers

Scénario n° 4 De l’aveuglement des outils de sécurité Néanmoins… Exécution d’une commande système (RCE : Remote Command Execution ) à partir d’une image… ????

Scénario n° 4 De l’aveuglement des outils de sécurité ImageMagick Installé par défaut sur les distributions Linux

Scénario n° 4 De l’aveuglement des outils de sécurité CVE dans ImageMagick

Scénario n° 2 Les développeurs sont nos amis… Il faut les aimer aussi…

Sommaire Scénarios d’attaque R Présentation & Actualités III. Recommandations / Ressources

Scénario n° 1 & 2 Les développeurs sont nos amis… Il faut les aimer aussi… Recommandations (vérifier si répertoire dev accessible) Recherche d’informations sur github : Site:github.com <domain> Site:github.com intext:<domain> Recherche si répertoire git / svn : Site:<domain> intext:’Index of /,svn’ Site:<domain> intext:’Index of /.git’ Malheureusement pas suffisant… Scan de vulnérabilités nécessaire

Scénario n° 3 De la nécessité de contrôler les entrées utilisateurs Recommandations Filtrer en amont de l’utilisation de la bibliothèque les entrées utilisateurs. Vérifier le contenu d’un objet avant qu’il ne soit désérialisé Patcher les applications et les librairies Plugin OWASP Dependency Check Utiliser la bibliothèque SerialKiller bibliothèque va se placer en amont des méthodes « readObject() » afin de contrôler au préalable si un objet est utilisé par une classe dangereuse, via une liste noire ou blanche définie par l’utilisateur. Plus d’informations : https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Deserialization_Cheat_Sheet.md

Scénario n° 3 De la nécessité de contrôler les entrées utilisateurs Ressources Image ISO du challenge : https://lepouvoirclapratique.com/blog/2017/12/11/challenge-deserialisation-java/

Scénario n° 4 De l’aveuglement des outils de sécurité Recommandations Protection contre les injections SQL : Filtrage des caractères sur le nom du paramètre et valeur du paramètre Utiliser des requêtes préparées Plus d’informations ici : https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.md Mise à jour des outils sur la machine locale Installer les paquets unattended-upgrades apt-listchanges pour le déploiement automatique des correctifs de sécurité

Scénario n° 4 De l’aveuglement des outils de sécurité Ressources Url du challenge : http://ptl-1b4e9359-99930bb8.libcurl.so Explications vulnérabilités désérialisation : XMCO_actusecu n° 43

Questions