security

Service Hacktion - Notes attachées au balado S01E01 - Rattachage DNS en une fraction de seconde

noraj (Alexandre ZANNI)
, ,
🇫🇷
Saison Épisode
1 1

Introduction#

Balado (podcast)

  • Revue d'actualité
  • Creuser plus en profondeur un sujet
  • Entrevues (Interview)
  • etc.

Le nom#

Service Hacktion, pourquoi un tel nom ?

  • Je voulais hack dans le nom
  • En référence à la DGSE
    • "Le service Action (SA) est une unité militaire secrète française placée sous le commandement opérationnel de la direction des opérations (DO) de la direction générale de la Sécurité extérieure (DGSE)."
  • Les classiques hacktualité ou hackademie ont déjà été faits 40 fois
  • Je ne voulais pas reprendre tous les jeux de mots qui ont déjà été faits pour les conférences de sécurité ou les noms d'équipe de CTF

Le sujet - Rattachage DNS#

⚠️ Niveau avancé, sujet complexe ⚠️

Daniel Thatcher (@_danielthatcher) qui travaille pour l'entreprise Intruder.

C'est un chercheur en sécurité et un ancien ingénieur en test d'intrusion. Il partage son temps entre la recherche de nouvelles techniques de piratage d'applications web et le développement de produits (scanneur de vulnérabilité).

Article 1#

Contexte#

  • Ils ont des serveurs de prise de captures d'écran des sites web de leurs clients (gowitness)
  • Ils ont fait des TI sur les plateformes
  • gowitness suit les redirections HTTP pour prendre les captures d'écran
  • gowitness hébergé sur AWS, machine virtuelle EC2
  • gowitness avait accès au service de métadonnées interne à l'instance EC2 et donc avait la possibilité de récupéré les authentifiants AWS des différents rôles disponibles sur l'instance
  • Pour exploiter cela, il suffit de créer un site web qui redirige vers http://169.254.169.254/latest/meta-data/iam/security-credentials/
  • Remédiations :

Rappels : rattachage DNS#

  • Manipulation de nom de domaine (NDD)
  • À ne pas confondre avec l'usurpation de nom DNS (DNS spoofing) souvent utiliser pour contourner les restrictions de domaine (ex : hôte local)
    • Exemple : dans la limite, affichage flux RSS, SSRF
  • Depuis JavaScript impossible d'attaquer des machines sur le réseau autre que la machine qui héberge le script grâce à la SOP (Same Origin Policy)
  • TTL DNS très court pour empêcher la mise en cache
  • 1ière résolution : adresse IP du serveur hébergeant le script
  • Quand le script exécuté, une nouvelle requête DNS vers le NDD est faite
  • 2ième résolution : adresse IP interne ou ailleurs sur le réseau
  • Valide la SOP donc peut lire la réponse
  • Prérequis :
    • avec navigateur piloté
    • le serveur le valide pas l'en-tête Host
    • HTTP (pas HTTPS)
  • Exemple : hors bande, API, SSRF

Le rattachage DNS permet de contourner l'IMDSv2 d'AWS#

  • Exemple d'implémentation de l'exploitation et de l'exfiltration sur ZAP Proxy (Firefox piloté) (au lieu de gowitness (Chrome piloté))
    • Pour l'exfiltration, on doit attendre que la réponse DNS expire afin de pouvoir requêter vers l'IP publique
  • ZAP Proxy au lieu de gowitness à cause des faibles délais d'expiration et de la restriction contre les requêtes vers les réseaux privés (voir article 2)

Article 2#

Intro#

  • Quand IPv6 est disponible
  • Technique pour contourner la restriction sur les réseaux locaux appliquée à fetch() dans Chromium

Caches lents#

  • Technique classique d'inondation DNS : vider le cache du navigateur - en générant un grand nombre de recherches DNS pour remplir l'espace disponible dans le cache et en faisant en sorte que les entrées plus anciennes soient écartées avant d'avoir expiré - afin que le navigateur effectue une deuxième recherche du même nom d'hôte plus tôt.
  • Inconvénients de l'inondation DNS :
    • ~ 10 sec
    • Caches intermédiaires plus difficiles à vider que le cache du navigateur, ex : ~ 5 minutes pour systemd-resolved, ~ 30 minutes pour certains VPN
    • Difficile de forcer l'utilisateur à garder la page ouverte longtemps
  • Autre technique : multiples enregistrements A dans la même réponse pour le même domaine
    • Présentée à la BlackHat USA 2010 par Craig Heffner
    • Exploitée par Gerald Doussot and Roger Meyer dans Github - nccgroup/singularity en 2019
    • Les 2 enregistrements sont : une adresse IP publique contrôlée par l'attaquant et une adresse IP du serveur cible
    • Aléatoire, car ne fonctionne que si le navigateur communique avec le serveur public en premier
    • Le serveur web de l'attaquant doit bloquer le trafic provenant du navigateur de la victime, ce qui a pour effet de ramener le navigateur à envoyer toutes les futures demandes au serveur cible. Dans ce cas, JavaScript dans la page de l'attaquant pourra envoyer des requêtes à l'adresse IP cible sous la même origine
    • Contourne le problème de cache car 1 seule requête DNS mais fonctionne rarement en pratique car la majorité des navigateurs essayent de contacter l'adresse privée en premier

Dans Wireshark, l'auteur a remarqué que lors du chargement de sites web dans les navigateurs modernes, une requête A et une requête AAAA sont toutes deux envoyées, voyons voir ça ⬇️

Attaquer Safari : Retarder les réponses DNS#

  • Si accès à internet via IPv6 et utilisation de Safari
    • Safari envoi req. DNS A (IPv4) et AAAA (IPv6)
    • Safari priorise les adresses IP privées sur les publiques quand il y en a plusieurs
  • Si la réponse A ou AAAA est retardée
    • Safari n'attend pas de recevoir toutes les réponses
    • Safari envoi des req. HTTP dès la 1ière réponse DNS
    • Quand la réponse DNS différée est reçue, les adresses IP de cette réponse sont ajoutées au lot d'adresses IP que Safari peut utiliser pour les futures requêtes vers ce domaine
    • Donc si la première réponse reçue est publique que celle délayée est privée, Safari enverra la 1ière req. HTTP vers l'adresse IP publique jusqu'à ce que la réponse DNS délayé soit reçue, à ce moment-là, il enverra les req. vers l'IP privée
    • Pour l'exfiltration, on doit attendre que la réponse DNS expire afin de pouvoir requêter vers l'IP publique

Cf. scénario schéma

Attaquer Chrome : Utiliser la priorisation AAAA#

  • Comme Safari, Chrome priorise les adresses IP privées sur celles publiques
  • Mais Chrome priorise aussi les adresses IPv6 sur les IPv4 (plus de poids)
  • Priorité (+ haute vers + faible) :
    • IPv6 privée
    • IPv6 publique 💡
    • IPv4 privée 💡
    • IPv4 publique
  • IPv6 publique avant IPv4 privée
  • S'il y a une réinitialisation, de connexion, Chrome essaye une autre IP

Cf. scénario schéma

  • Mais Chrome bloque !
    • Contexte non sécurisé (HTTP) et accès une adresse IP privée
    • Implémentation partielle de PNA (Private Network Access) (brouillon pour un standard W3C)
      • 🇫🇷 ARP (Accès aux Réseaux Privés)

Contournement de l'Accès aux Réseaux Privés#

  • Les protections PNA empêchent les pages chargées par HTTP à partir de l'internet public d'adresser des requêtes aux réseaux privés
  • Dans Chrome, ces protections sont mises en œuvre pour les requêtes fetch(), mais pas encore pour les iFrames
  • On garde tout pareil sauf qu'on essaye d'accéder au secret via une iFrame au lieu d'un req. fetch()
  • La page dans l'iFrame a la même origine que la page racine, donc la page racine peut contrôler la DOM de la page dans l'iFrame
  • La page racine peut donc injecter un script qui fait une req. fetch() dans l'iFrame pour accéder à la cible et exfiltrer la donnée

Cf. scénario schéma

  • Astuce : si la cible est un navigateur piloté, introduire du délai de chargement pour l'iFrame pour que le navigateur considère que la page n'est pas complètement chargée jusqu'à ce que l'iFrame ait fini de charger afin de s'assurer que l'attaque ait le temps de s'exécuter
Partager