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

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

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 ?

Impacts A minima prise de contrôle du serveur

Impacts Dans certains cas, possibilité de rebond sur d’autres serveurs / prise de contrôle totale du SI

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…

Et on a pas parlé de github… Mais l’enfer est pavé de bonnes intentions… Potentiel souci(s) de sécurité ?

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

Et on a pas parlé de github…

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

Etape n°1 : découverte d’un répertoire git et récupération des informations associées

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

Etape n°3 : connexion à l’interface d’administration du site web et installation d’un script de contrôle à distance

Etape n°4 : prise de contrôle à distance du serveur et accès à des informations confidentielles

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

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.

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

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

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

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 …

Exemple de gadget chain pour Apache commons

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

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° 4 De l’aveuglement des outils de sécurité
Quelques vulnérabilités difficiles à détecter Mettez à jour !

Présentation du cas Exemple avec une injection sql dans le paramètre user_id

Présentation du cas Rappel Injection SQL : attaque qui consiste à modifier une requête SQL et à y injecter des commandes

Petit focus sur les injections SQL (détection) Plusieurs types d’injections SQL Error-based Blind

OWASP Test

OWASP Test Heu du coup tout va bien ?!

OWASP Test Non !!!

Petit focus sur les injections SQL Type d’injections « indétectables » Injection second order… Points d’injection Valeur du paramètre Et nom du paramètre !

OWASP Test Injection sql présente dans le nom du paramètre (et non la vauleur)

Interface d’upload Contrôles bien réalisés sur les extensions et le type de fichiers

Néanmoins… Exécution d’une commande système (RCE : Remote Command Execution ) à partir d’une image… ????

ImageMagick Installé par défaut sur les distributions Linux

CVE dans ImageMagick

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

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 :

Ressources Image ISO du challenge :

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

Ressources Url du challenge : Explications vulnérabilités désérialisation : XMCO_actusecu n° 43

Questions

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

Présentations similaires

Présentation au sujet: "Sensibilisation : Exploitation de vulnérabilités avancée 16 mai 2019"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

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

Présentations similaires

Présentation au sujet: "Sensibilisation : Exploitation de vulnérabilités avancée 16 mai 2019"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back