Liens vers les comptes-rendus des autres jours :
- Hack.lu 2016 – première journée
- Hack.lu 2016 – deuxième journée
- Hack.lu 2016 – troisième journée
Jour 2
The Metabrik Platform: Rapid Development of Reusable Security Tools
Patrice Auffret alias GomoR a démarré cette 2ème journée de conférence en présentant son outil « Metabrik » développé en Perl.
Metabrik n’est pas un seulement un Pokémon mais un shell UNIX interactif facilitant le développement rapide de programmes via des briks (plus de 200 briks actuellement disponibles), tout en s’appuyant sur l’interpréteur perl afin de réaliser des tâches automatisées.
Cet outil a été conçu en suivant le principe du « Do it once » afin d’éviter toute répétition et de permettre de pallier les limitations des pipes shell UNIX.
Avec Metabrik tout devient une variable Perl et la dernière commande exécutée est stockée dans la variable « $RUN » pour utilisation ultérieure.
Patrice nous a enfin démontré la puissance de son outil en nous présentant la solution du challenge de Forensic « Trouvez le chat » de Root Me :
The Fantastic 4 … forensic domains: net, disk, mem, mal
David Durvaux et Christophe Vandeplas nous ont présenté dans cet atelier les procédures d’analyse Forensic via une roadmap sur 4 domaines d’analyse essentiels et baptisés les 4 fantastiques : réseau, disque, mémoire et code malveillant.
Le challenge « Locked Shields Cyber Exercise » organisé par le CCDCOE (Cooperative Cyber Defence Centre of Excellence) a servi de support à cet atelier dont le but était d’analyser l’ensemble des traces réseau et système afin de trouver l’origine de la compromission d’un serveur et ainsi d’éviter une guerre mondiale.
Tout au long de cet exercice nous avons identifié le trafic malveillant et la chronologie des évènements afin de récupérer l’ensemble des indicateurs de compromission (IOC) et de corréler ceux-ci aux autres actions réalisées par l’attaquant.
Pour ceux souhaitant se prêter à l’exercice, l’ensemble des cas d’étude peut être téléchargé sur le site suivant :
La présentation PowerPoint est également accessible à l’adresse suivante :
https://docs.google.com/presentation/d/1j1y97LUw9AHapfcFICVOZ3hGxaT6jYSwk_gm4iQjEnA/edit
Exploiting new default accounts in SAP systems
Joris van de Vis, consultant chez ERP-SEC, nous a présenté les défauts de configuration de la solution SAP.
Deux des plus importants vecteurs d’attaques ont plus particulièrement été exposés par Joris à savoir la présence de comptes par défaut et l’utilisation de la passerelle SAP RFC.
La liste des comptes SAP par défaut et publiquement connus est la suivante :
Joris nous a ensuite présenté tout une batterie de nouveaux comptes protégés par des mots de passe triviaux et ayant des permissions élevées :
Ces comptes sont créés par la solution de gestion de SAP (SOLMAN_SETUP) sur l’ensemble des systèmes satellites en fonction des scénarios activés.
En utilisant ces comptes il est alors possible d’accéder à des fonctionnalités intéressantes avec des privilèges élevés, et de réaliser les actions suivantes :
- Exécution de requêtes SQL natives
- Relai SMB
- Exécution de commandes système
- Création de nouveaux comptes SAP
- Récupération des condensats d’autres comptes SAP
Joris a poursuivi sa présentation en réalisant plusieurs démonstrations techniques permettant la compromission des serveurs SAP via différents vecteurs d’attaque.
La 1ère consistait à utiliser la « fonctionnalité » d’exécution de commande ABAP en appelant le programme « RSSAA_CALLEXTERN » :
Une fois cette interface lancée, il est possible de contourner la liste blanche des programmes autorisés en appelant directement des programmes arbitraires depuis le champ « PARAM » :
Note : Cette vulnérabilité a été corrigée dans les dernières versions du produit SAP.
La 2ème démonstration a permis de récupérer des condensats de mots de passe via l’utilisateur système SMDAGENT, capable d’exécuter des requêtes SQL afin d’extraire du contenu de la base de données :
Une fois ces condensats récupérés, ceux-ci peuvent être aisément cassés par force brute en utilisant l’outil Hashcat :
Joris nous a ensuite présenté dans sa 3ème démo un script python permettant la création d’un compte SAP via le protocole RFC :
Ceci est rendu possible via la fonction « SXPG_STEP_XPG_START », en exploitant la relation de confiance implicite avec la base de données, afin de créer un compte SAP avec les droits SAP_ALL sans que cette action ne soit journalisée.
Enfin, le module Metasploit « sap_soap_rfc_sxpg_command_exec » a été présenté dans une 4ème et dernière démonstration afin de récupérer un shell sur le serveur cible :
Joris a conclu sa présentation en nous recommandant d’utiliser l’outil développé par son entreprise afin de vérifier l’existence de comptes par défaut, ou encore d’utiliser la bibliothèque Python pysap, développée par Martin Gallon, afin de forger et envoyer des paquets pour les protocoles réseau suivants :
- SAP Network Interface (NI)
- SAP Diag
- SAP Enqueue
- SAP Router
- SAP Message Server (MS)
- SAP SNC
Pysap peut être téléchargée sur le dépôt Github suivant :
https://github.com/CoreSecurity/pysap
Enfin, il convient également d’appliquer les correctifs de sécurité et de supprimer l’utilisateur « SMD_ADMIN » pour les installations de SAP Solution Manager supérieures à la version 7.1 SP10.
badGPO – Using GPOs for Persistence and Lateral Movement
Yves Kraft et Immanuel Willi, deux consultants de Oneconsult nous ont présenté une technique de persistance via l’utilisation de GPO.
Cette technique ajoute une nouvelle stratégie de groupe via l’utilisation de WMI et l’exécution à distance de gpupdate.
Des recherches antérieures ont été menées par Sean Metcalf sur ce sujet et sont consultables sur son site.
A des fins de démonstration, Yves et Immanuel ont utilisé Empire, un Framework de post-exploitation souvent utilisé lors des missions de Red Team et pour lequel plusieurs modules tels que « set_gpo » et « get_gpo » ont été développés :
Pour ceux souhaitant utiliser ces différents modules, une pull request a été initiée en septembre dernier afin que ceux-ci soient ajoutés au dépôt officiel d’Empire :
Cette technique de persistance est intéressante puisqu’elle permet de joindre l’ensemble des serveurs d’un domaine Windows tout en utilisant des procédures standards de Microsoft, évitant ainsi la génération d’alertes et ainsi la détection par les SIEM.
Enfin les recommandations suivantes ont été proposées afin de se prémunir contre ce type d’attaque :
- Passer en revue toutes les stratégies de groupe implémentées
- Limiter le nombre d’administrateurs de domaine ainsi que leurs privilèges
- Restreindre l’utilisation des applications système via une liste blanche
- Mettre en place des systèmes de détection d’intrusion (IDS)
- Garder un système d’information sain
Credential Assessment: Mapping Privilege Escalation at Scale
Matt Weeks est revenu sur plusieurs compromissions ayant fait la une telles que l’attaque contre Target, Homedepot ou encore JPMorgan Chase afin d’en étudier leurs origines.
Un rapport sur l’attaque contre Target à d’ailleurs été publié et peut être consulté à l’adresse suivante :
https://aroundcyber.files.wordpress.com/2014/09/aorato-target-report.pdf
Une étude de cette attaque a également été menée par le comité sur le commerce, la science et le transport des États-Unis et présente les différentes phases généralement suivies par cette chaîne de compromission :
Matt a ensuite déploré le manque d’intérêt vis-à-vis de la phase de récupération d’identifiants de connexion qui est selon lui dans la plupart des cas à l’origine de l’ensemble de ces compromissions.
Il a ensuite présenté l’outil propriétaire Orkos développé par root9B permettant de collecter et d’analyser les identifiants réutilisables sur les différents serveurs d’un environnement Windows afin de réaliser une cartographie des chemins de compromission possibles :
Enfin, Matt a terminé sa présentation en listant les recommandations suivantes à appliquer afin de se prémunir contre ce type de compromission :
- Verrouiller les comptes d’administration locaux
- Remplacer l’utilisation des mots de passe par les cartes à puce utilisant une autorité de certification non connectée au réseau de l’entreprise
- Renouveler souvent le mot de passe associé au compte KRBTGT
- Implémenter une politique d’authentification permettant une ségrégation des comptes en limitant la cible et la source des ouvertures de sessions
When Crypto Fails
Petit retour d’expérience de la part de Yaniv Balmas et Ben Herzog pour cette présentation avec comme thème les erreurs d’implémentation de la cryptographie dans les logiciels malveillants.
Ils sont revenus sur plusieurs échecs d’implémentation de la cryptographie dans les virus et ransomwares comme Zeus, linux encoder, CryptoWall, Petya ou encore l’exploit kit Nuclear.
La 1ère classe d’erreur rencontrée a été baptisée la programmation voodoo. Une implémentation personnalisée de l’algorithme de chiffrement RC4 utilisée par Zeus rentre dans cette catégorie. Celle-ci ajoute une routine de transformation linéaire afin de prendre chaque octet du cryptogramme et réaliser un XOR avec l’octet suivant :
Bien que ce fragment de code n’augmente pas la sécurité de l’algorithme de chiffrement employé, celui-ci révèle le manque de confiance des auteurs du virus Zeus vis-à-vis des algorithmes de chiffrement existants.
Un autre exemple d’échec d’implémentation est l’emploi d’une mauvaise graine pour la génération des nombres aléatoires basée, dans le cas du virus « Linux Encoder », sur l’horodatage. Ceci rend ainsi facile la re-génération de la clé pour déchiffrer les fichiers.
Le ransomware CryptoWall souffre également d’une mauvaise implémentation qui, bien qu’utilisant l’algorithme de chiffrement RSA, génère la paire de clés privée/publique lors de l’infection, chiffre les fichiers avec la clé publique et transmet la clé privée au serveur. Or, la génération de la bi-clé s’effectuant côté client, la confidentialité de celle-ci peut être compromise. D’autant plus que l’exemple d’implémentation disponible sur le site MSDN, et utilisé par ce logiciel malveillant, force le stockage de cette clé privée en local et rend ainsi celle-ci persistante sur le système compromis.
Ils ont également présenté en exclusivité leur baromètre « SALSA-O-METER » permettant d’évaluer l’algorithme de chiffrement de flux maison basé sur Salsa20 et utilisé par le virus Petya pour le chiffrement du Master Boot Record (MBR) :
Après analyse, les erreurs suivantes ont été commises pour l’implémentation de la routine de chiffrement :
- La variable utilisée pour stocker le flux de 64 bits est une variable de type uint32_t donc codée sur 32 bits.
- Une constante n’a pas été modifiée pour adapter le code initialement prévu pour tourner sur une architecture 16 bits
- Une constante lors d’un shift sautant tous les 4 octets n’a pas été modifiée, réduisant ainsi la complexité de moitié puisque 2 octets sur 4 sont ignorés
- Une fonction « key_expand » est finalement utilisée et abaisse considérablement la taille de la clé, passant ainsi de 16 à 8 octets
Une attaque de type force brute sur les 8 caractères imprimables restants peut donc être réalisée aisément.
La présentation s’est terminée sur l’analyse de l’exploit kit Nuclear pour lequel les activités ont cessées suite à la publication de Checkpoint.
L’erreur commise par ce virus intervient dans la phase d’échange de la clé de désobfuscation en utilisant le protocole Diffie-Hellman. En effet, les variables des clients n’étant pas encodées en base64, une erreur est retournée lors de l’appel de la fonction « getGmp », responsable du décodage de cette valeur, et qui retourne donc zéro :
La suite du calcul reposant sur cette valeur, l’ensemble du code de chiffrement retourne zéro.
Yaniv et Ben ont enfin conclu la présentation en rappelant qu’il ne fallait pas jouer à l’apprenti sorcier avec la citation suivante :
If you consider cryptography to be a magic black box then either you don’t understand cryptography or it doesn’t understand you.
Hadoop safari : Hunting for vulnerabilities
Mehdi Braik et Thomas Debize nous ont présenté le niveau de sécurité de la solution de Big Data Hadoop.
Pour rappel, Hadoop est un framework open source écrit en Java et utilisé pour la création d’applications distribuées dont le traitement est basé sur un algorithme de type « MapReduce » :
Après une brève explication du fonctionnement interne d’Hadoop, Mehdi et Thomas nous ont détaillé les différents modèles de sécurité de ce dernier. Bien qu’utilisé par des grands noms comme Adobe, Yahoo! ou encore Ebay, aucun mécanisme d’authentification n’est imposé par défaut sur un cluster Hadoop. En effet, si le protocole Kerberos n’est pas activé, Hadoop ne réalise qu’une identification en se basant sur le nom d’utilisateur fourni par celui-ci et en vérifiant qu’il existe bien.
Ensuite, en ce qui concerne la gestion des autorisations ainsi que le processus d’audit, ceux-ci s’avèrent être complexes à mettre en place puisque chaque composant du cluster Hadoop à son propre modèle d’autorisation ; le système de fichier HDFS (Hadoop Distributed File System) supportant les permissions POSIX et les ACL depuis la version 2.5.
Enfin, aucun chiffrement n’est activé par défaut afin de protéger la confidentialité des données lors de leur transmission (in-transit) et leur stockage (at-rest). Cette option est cependant possible pour les installations utilisant le protocole Kerberos.
Thomas et Mehdi nous ont ensuite exposé la surface d’attaque offerte par ce genre d’installation ainsi que les techniques d’attaque de certains services tels que l’API REST WebHDFS ou encore l’interpréteur de commandes Hadoop.
Un outil nommé HDFSBrowser a même été développé afin de simplifier la tâche de récupération de données et l’exportation au format CSV :
De plus, la récupération d’un shell Meterpreter est facilement réalisable puisque le but d’Hadoop est de distribuer des tâches à exécuter :
Thomas a ensuite rappelé qu’un des inconvénients des systèmes distribués est qu’il n’est pas a priori possible de cibler précisément le serveur sur lequel nous souhaitons exécuter du code.
Enfin, plusieurs vulnérabilités sur des modules tiers ont été présentées comme l’énumération de comptes, les vulnérabilités XSS ou encore la consultation de fichiers de journalisation.
Pour conclure leur présentation, ils ont rappelé quelques recommandations à appliquer comme la mise en place du protocole Kerberos, la réduction de la surface d’attaque via les services exposés ainsi que l’application des correctifs de sécurité.
Hacking Social Gathering
Cette journée s’est terminée en beauté par le Social event.
Au menu de cette soirée, des sandwichs, de la bière et du vin à volonté ainsi que des présentations plus délirantes les unes que les autres. En effet, plusieurs personnes sont montées sur scène afin de présenter des supports sélectionnés aléatoirement sur internet.
Cette soirée a confirmé la qualité de l’accueil de l’ensemble du staff ainsi que l’accessibilité des personnes participant à cette conférence. Nous recommandons d’ailleurs vivement à ceux qui nous lisent de participer à la prochaine édition !
Annexes
Les différents supports de présentations seront bientôt disponibles à l’adresse suivante :
En attendant, voici quelques liens pour visionner les différentes conférences :
- Jour 2
- The Metabrik Platform: Rapid Development of Reusable Security Tools by Patrice Auffret
- 2016: The Infosec Crossroads
- Exploit generation and JavaScript analysis automation with WinDBG
- A Network of Sorrows: Small Adversaries and Small Allies by Quinn Norton
- Lightning Talk: Start-up Pitch: securityscorecard.io by Chris Meidinger
- Lightning Talk: Sisyphe, All IP Data In One Place by GomoR
- Lightning Talk: Start-up Pitch: redowl.com by Peter Heim
- Exploiting new default accounts in SAP systems by Joris Van De Vis
- badGPO – Using GPOs for Persistence and Lateral Movement
- Machine Duping: Pwning Deep Learning Systems by Clarence Chio
- Credential Assessment: Mapping Privilege Escalation at Scale by Matt Weeks
- When Crypto Fails ( Yaniv Balmas, Ben Herzog)
- Bootstrapping an Architectural Research Platform by Jacob I. Torrey
- Hadoop safari : Hunting for vulnerabilities by Mahdi Braik and Thomas Debize
