Retour sur leHACK 2019

XMCO a assisté à la 17e édition de la conférence leHACK qui s’est déroulée le 6 et 7 juillet derniers. Comme l’année précédente, la conférence a eu lieu à la Cité des Sciences et de l’industrie.

Cette année marque la première itération de l’événement en tant que « leHACK » (et non plus la Nuit du Hack).
En attendant le prochain numéro de l’Actu-Sécu, nous vous proposons de revenir sur quelques conférences qui nous ont marquées.

Phish & Profit – Jeremy Caron

Jérémy Caron est venu présenter quelques retours d’expériences de ses missions de phishing.

L’introduction met l’accent sur le fait que les êtres humains ont une mémoire sélective, ce qui baisse leur vigilance au cours du temps, si aucun rappel n’est fait. Il rappelle également que selon une étude de l’ENISA, le phishing est à l’origine de 90% des infections par malware et 72% des fuites de données. Ce type d’attaque repose sur la confiance naturelle dont font preuve les utilisateurs.

La première mission est une mission de Red Team dont l’objectif est d’aller le plus loin possible à partir d’un mail de phishing. Les auditeurs procèdent en premier lieu à une phase d’identification en sources ouvertes (OSINT). Pour ceci, le site « hunter.io » et des recherches Google ciblées (dorks) sont utilisés afin de construire une liste de cibles potentielles.

À partir de cette liste, les auditeurs ont mis en place un scénario de jeu-concours organisé par le comité d’entreprise et ont envoyé un mail en usurpant l’identité du comité d’entreprise pour inciter les utilisateurs à télécharger une charge malveillante.

De là, trois conseils ont été donnés :

  • Plus l’objet est court, plus l’e-mail a de chances d’être lu;
  • Éviter au maximum les mots et expressions « filtrés » (« Bravo vous avez gagné », « Félicitations !! »…);
  • Il est possible d’évaluer la réputation de ses mails avec des sites comme mail-tester.com.

La charge utilisée était un fichier Word avec macro (.docm). À l’activation des macros, une charge utile est téléchargée en arrière-plan et un formulaire d’inscription est affiché à l’utilisateur. Deux conseils supplémentaires ont été donnés par le consultant :

  • Ne jamais mettre la charge utile dans un mail,
  • Éviter à tout prix que la dernière étape soit visible par une solution de sandboxing

Pour cela, deux éléments ont été proposés :

  • Créer la charge à l’aide d’un code JavaScript;
  • Mettre un captcha.

Leur première tentative fut un échec, car le nom de domaine comitedentreprise-foo.com était bloqué par le proxy web (filtrage sur le nom de l’entreprise « foo »).

Une deuxième tentative a été effectuée avec le nom de domaine comitedentreprise-btp.com. Ce dernier fût bloqué par le serveur mail, car il n’avait pas une assez bonne réputation.

L’auditeur explique qu’il est possible de trouver des noms de domaines avec une bonne réputation qui viennent d’expirer via le site expireddomains.net.
Un troisième essai fut effectué avec bonne-reputation.com et cette fois-ci, le domaine fut bloqué, car le certificat était autosigné.

Cependant, une personne a entré ses informations personnelles sur le formulaire Word ce qui a permis aux auditeurs de tenter une attaque par vishing (phishing par téléphone).

Les auditeurs ont appelé la personne ayant rempli le formulaire en se faisant passer pour le support informatique. Le but était de lui faire croire qu’elle avait été victime d’une attaque de phishing et qu’il fallait lancer un exécutable pour retirer la menace. De cette manière le poste a été compromis.

La seconde mission a été effectuée à l’aide de l’outil Gophish et avait pour objectif de capturer un maximum d’identifiants, avec une cible de 10 000 personnes.

Le scénario reposait sur le fait que le client possédait un service de support informatique. Le but était de faire croire aux clients qu’ils avaient ouvert un ticket au support et qu’ils pouvaient suivre l’avancée de leur ticket en s’identifiant sur le site.

Ce scénario a réussi à récupérer près de 2000 identifiants. Cependant, la moitié des employés ont ouvert un ticket afin d’indiquer qu’ils n’avaient pas créé de nouveau ticket. Le prestataire de leur client était rémunéré au ticket traité, provoquant un effet de bord fortement indésirable…

La dernière mission était la plus complexe. Il fallait aller le plus loin possible en attaquant 10 personnes du support IT.
Il était connu que ces derniers utilisent macOS et Google Suite. L’auditeur avait alors 10 jours pour réaliser sa campagne avec aucune connaissance préalable sur ces environnements. L’antivirus n’était pas connu aux moments des tests, mais une capture d’écran postée sur les réseaux sociaux a permis de divulguer l’utilisation d’Avast.

La semaine avant l’audit, une vulnérabilité affectant GateKeeper avait été divulguée, ce dernier considérait les disques externes comme des localisations de confiance, donnant lieu à la chaîne de compromission suivante : une archive au format .zip contiendrait un lien symbolique vers un partage NFS, et ce partage contiendrait la charge malveillante.

Désormais, il fallait un scénario pour inciter les personnes du support à cliquer sur l’exécutable. Il a été choisi de faire passer l’archive pour une mise à jour du logiciel de gestion de parc. Cependant, un problème au niveau de la réputation du nom de domaine puis un problème de plantage du Mac on compliqué le scénario.

Une nouvelle tentative a été effectuée et a permis un taux de réussite de 20%.

La conférence s’est terminée sur les conseils suivants :

  • Une mise en garde a été faite contre le passive DNS. Mieux vaut éviter de réserver des sous-domaines sur le même domaine. Ces changements sont journalisés et il est possible pour les clients de savoir si ce domaine a servi dans d’autres types d’opérations de phishing. D’ailleurs, il est conseillé d’utiliser des services tels que Domains by Proxy pour pouvoir conserver son anonymat.
  • Les sites Github.io sont des sites statiques hébergés par GitHub. Ces derniers peuvent donc être intéressants pour piéger des développeurs.
  • Enfin les utilitaires Serveo et NGrok peuvent être utilisés pour exposer facilement des serveurs Web sur Internet.

Hacking 50 million users using 123456 – Himanshu Shamra, Aman Sachdev

Lors de cette conférence, Himanshu Shamra et Aman Sachdev ont présenté un retour d’expérience de Red Team qu’ils ont effectué pour un grand compte.

La conférence s’est présentée comme une compilation des failles les plus importantes retrouvées dans les divers applicatifs de l’entreprise.

Tout d’abord, sur l’environnement de préproduction, un jeu d’identifiants trivial a été identifié (demo/123456). Les auditeurs ont ainsi pu télécharger un webshell, prenant ainsi le contrôle du serveur et obtenant le code source de l’application web.

Ils ont pu réaliser une analyse du code et ont remarqué une erreur de logique. En effet, sur chaque page, une portion de code vérifie si l’utilisateur est authentifié et si ce n’est pas le cas, le redirige vers la page d’authentification. Cependant, il y manque la fonction `die` qui permet d’arrêter l’exécution du script. De ce fait, il était possible de réaliser des actions sur le serveur Web sans être authentifié.

Grâce à cette vulnérabilité, ils ont donc pu s’authentifier sur l’environnement de production et obtenir un invité de commandes à distance. Ils ont alors identifié un serveur de ticketing Redmine via le fichier /etc/hosts. Une nouvelle vulnérabilité a alors été découverte puisqu’il était possible d’explorer les différents tickets sans s’authentifier. Parmi eux, une demande de réinitialisation d’accès révélait le mot de passe par défaut utilisé : « Nomdel’entreprise@2016 ».

Les adresses email suivant un schéma classique, il a été possible d’accéder au compte Google de la personne ayant demandé la réinitialisation. Cependant, Google a su détecter une tentative d’authentification suspecte. Le test proposé pour lever le doute était d’indiquer la ville dans laquelle la personne se connecte d’habitude.

Pour retrouver cette information, ils ont effectué des recherches en sources ouvertes sur les employés (LinkedIn, Google, Pages Jaunes, Facebook…). Ils sont parvenus à retrouver la ville dans laquelle travaillait l’employé et ainsi réussi à s’authentifier. Ils avaient alors un accès complet au Drive, aux applications, ainsi qu’à la console d’administration. De là, d’autres informations de connexion ont été collectées dans les mails, telles que des informations sur l’architecture réseau et système, des identifiants VPN, etc…

D’autres applications ont également fait l’objet d’analyse :

  • Sur une interface MobileIron, il a été possible de réaliser une injection SQL conduisant à un contournement de l’authentification. À partir de cette interface, il était possible de récupérer toutes les informations sur les terminaux mobiles des employés : OS, applications, RAM utilisée, stockage, ainsi que la géolocalisation.
  • Sur une mire de paiement, si un nombre était mis dans le champ « Last Name », ce montant était demandé pour le paiement.
  • Concernant un serveur Jenkins, des fichiers de configurations divulguaient des identifiants.
  • Concernant l’utilisation de Buckets S3, certains n’étaient pas protégés. Près de 3 millions de données clientes ont été exfiltrées, dont des passeports et des permis de conduire.

Le talk s’est terminé sur les conseils suivants :

  • Activer l’authentification à plusieurs facteurs sur les clients mails
  • Ne jamais communiquer de mot de passe par mail
  • Ne jamais exécuter de service de base de données en tant qu’utilisateur root
  • Toujours vérifier la logique des processus métiers
  • Activer les mécanismes d’authentification sur Redis
  • Vider l’historique de commandes (history) après avoir tapé des mots de passe
  • Ne pas utiliser « entreprise@2016 » comme mot de passe.

Attacking & Defending AWS S3 Bucket – Sapna Singh

Dans ce talk, Sapna Singh revient sur les concepts majeurs derrière la sécurité des Buckets AWS S3.

Ces buckets sont des espaces de stockage présents dans le cloud que les entreprises peuvent louer. Leur sécurité est une responsabilité partagée :
Tout ce qui correspond à la sécurité du cloud est de la responsabilité d’Amazon et tout ce qui correspond à la sécurité des données contenues dans le cloud est de la responsabilité du client (ex: l’IAM).

Les raisons principales derrière les compromissions sont les suivantes :

  • Erreurs de configuration
  • Erreurs humaines
  • Nombre d’API trop élevé
  • Intégration d’un tiers
  • Manque de gouvernance
  • Manque de classification des données

La conférence développait un axe sur la gestion de risques, avec notamment une responsabilité mise sur le client. Les questions auxquelles ce dernier doit répondre sont « Quelles données sont à protéger ? Comment les stocker ? Doivent-elles être chiffrées ? Qui a accès aux données ? Quelles fonctionnalités de sécurité doivent être implémentées ? »

Un scénario d’attaque typique pour un Bucket S3 se déroule de la manière suivante :

  • Une phase de reconnaissance (afin de trouver les buckets)
  • Une phase de scan (afin de trouver une politique de sécurité un peu trop souple)
  • Une phase d’exploitation (à base de lecture, de téléchargement voire de suppression).

Tous les buckets suivent une convention de nommage spécifique et possèdent un nom unique:

  • http://nom.s3.<region>.amazonaws.com
  • http://nom.s3.amazonaws.com

Cette convention permet donc à un attaquant de trouver des buckets « ouverts » à l’aide de Google dorks spécifiques ou de l’interface de ligne de commande AWS. Cette dernière permet également de récupérer des informations sur un bucket.

Enfin, la conférence se concentrait sur les bonnes pratiques de sécurité.
Le premier conseil est de bloquer l’accès public aux buckets S3. Il est également possible de bloquer la création de nouvelles ACL publiques sur le bucket au niveau du compte afin d’éviter une exposition accidentelle.
Il existe également un mécanisme nommé presigned URL, permettant d’utiliser les permissions de l’utilisateur courant pour effectuer une action d’administration. Ceci peut être utile pour réaliser une tâche atomique.

Pour finir, la conférencière a donné les conseils suivants :

  • Vérifier l’exposition des buckets
  • Utiliser l’inventaire S3
  • Activer la suppression par authentification à plusieurs facteurs
  • Activer le versioning des buckets
  • Activer la journalisation des buckets

Enfin pour le monitoring, différentes solutions ont été proposées dont notamment :

  • AWS Cloud Trail
  • AWS Guard Duty
  • AWS Trusted Advisor
  • AWS Macie

 


Nous vous donnons rendez-vous dans le prochain numéro de l’ActuSécu pour un résumé complet et détaillé de cette édition !

Adrien Guinault

Découvrir d'autres articles

  • Conférences

    Retour sur WestDataFestival 2024

    Lire l'article
  • Conférences

    DORA et la résilience opérationnelle des fournisseurs

    Lire l'article
  • Conférences

    Retour sur la Black Hat Europe 2023

    Lire l'article