Une fuite DNS peut se produire en dehors du tunnel VPN sur Android

 (mullvad.net)
2 points par GN⁺ 2024-05-04 | 1 commentaires | Partager sur WhatsApp

Une fuite DNS peut se produire en dehors du tunnel VPN sur Android

Vérification d'une fuite DNS multiple

  • Une possibilité de fuites DNS multiples a récemment été découverte sur Android
  • Le problème provient d'un bug propre à Android et ne touche que certaines applications
  • Le 22 avril, un lundi, cela a été signalé comme fuite DNS par un utilisateur Reddit
    • Un utilisateur a constaté une fuite DNS lorsqu'il désactivait puis réactivait le VPN avec l'option « Bloquer les connexions sans VPN » activée
  • Une enquête interne a été lancée immédiatement, ce qui a permis de confirmer le problème
  • L'investigation a révélé plusieurs scénarios supplémentaires pouvant provoquer des fuites DNS

Constat

Scénarios identifiés pouvant entraîner une fuite du trafic DNS sur Android :

  • Lorsque le VPN est activé alors qu'aucun serveur DNS n'est configuré
  • Pendant une courte période, lorsque l'application VPN reconstruit le tunnel ou se retrouve arrêtée/plantée de manière forcée

La fuite semble être limitée aux appels directs à la fonction C getaddrinfo :

  • Dans les scénarios listés ci-dessus, les applications qui utilisent cette méthode de résolution de noms de domaine peuvent provoquer des fuites
  • Aucune fuite n'a été observée dans les applications qui n'utilisent que des API Android telles que DnsResolver
  • Le navigateur Chrome est un exemple d'application susceptible d'utiliser directement getaddrinfo

Les points ci-dessus s'appliquent quel que soit l'état d'Always-on VPN et de Block connections without VPN:

  • Puisqu'il ne s'agit pas d'un comportement attendu du système, il doit être corrigé en amont de l'OS

La fuite a été confirmée sur plusieurs versions d'Android, Android 14 inclus (la plus récente)

Améliorations

L'application actuelle ne configure pas de serveur DNS lorsqu'elle passe en mode bloqué :

  • Si l'application ne parvient pas à configurer le tunnel d'une manière réversible, elle bascule en mode bloqué
  • Dans cet état, le trafic cesse de sortir du périphérique
  • Cependant, comme aucun serveur DNS n'est alors configuré, la fuite DNS décrite ci-dessus peut se produire
  • Un serveur DNS factice sera temporairement configuré pour contourner le bug de l'OS
  • Une version incluant ce correctif devrait arriver prochainement

Il est plus difficile pour l'application de réduire la fuite lors d'une reconnexion du tunnel :

  • Une solution est toujours en cours de recherche
  • Nous pouvons limiter le nombre de reconstructions de tunnel, mais nous pensons qu'il n'est pas possible, pour l'instant, d'empêcher complètement cette fuite

Il faut clairement dire qu'aucune application VPN ne devrait avoir besoin de telles mesures de contournement :

  • Il n'est pas anormal qu'une application utilise getaddrinfo pour résoudre des noms de domaine
  • Au lieu de cela, c'est à l'OS de résoudre ce problème pour protéger tous les utilisateurs Android, quelle que soit l'application utilisée

Nous avons signalé le problème à Google avec une proposition d'amélioration, en espérant une correction rapide

Reproduction

Les étapes suivantes reproduisent le deuxième scénario ci-dessus, dans lequel l'utilisateur VPN modifie la configuration du tunnel (par exemple en changeant de serveur ou le serveur DNS) :

  • WireGuard est utilisé, car il s'agit de l'implémentation de référence des VPN Android
  • Il faut noter que la fuite pourra probablement être reproduite sur d'autres applications VPN Android
  • Chrome est utilisé pour déclencher la fuite, car il fait partie des applications confirmées à utiliser getaddrinfo

  1. Télécharger spam_get_requests.html

  2. Installer WireGuard et Chrome

  3. Importer wg1.conf et wg2.conf dans WireGuard

  4. Activer le tunnel wg1 dans WireGuard et autoriser la permission VPN

  5. Activer « Always-on VPN » et « Block connections without VPN » pour WireGuard dans les paramètres VPN d'Android

  6. Démarrer la capture de données sur le routeur avec tcpdump $ tcpdump -i <INTERFACE> host <IP of android device>

  7. Mettre WireGuard et Chrome en écran partagé côte à côte

  8. Ouvrir spam_get_requests.html dans Chrome et cliquer sur « Start »

  9. Dans WireGuard, basculer entre wg1 et wg2 jusqu'à ce qu'une fuite apparaisse à l'étape suivante

  10. Observer sur le routeur le trafic DNS suivant :

    11:50:27.816359 IP Pixel-Tablet.lan.53353 > OpenWrt.lan.53: 11200+ A? 307lf5rgn6-19282-11-50-27-519z.mullvad.test.lan. (65)
11:50:27.816359 IP Pixel-Tablet.lan.48267 > OpenWrt.lan.53: 44347+ A? 307lf5rgn6-19284-11-50-27-579z.mullvad.test.lan. (65) 
11:50:27.816396 IP Pixel-Tablet.lan.16747 > OpenWrt.lan.53: 44584+ A? 307lf5rgn6-19289-11-50-27-729z.mullvad.test. (61)
11:50:27.816458 IP OpenWrt.lan.53 > Pixel-Tablet.lan.53353: 11200 NXDomain 0/0/0 (65)
11:50:27.816476 IP Pixel-Tablet.lan.45727 > OpenWrt.lan.53: 40503+ A? 307lf5rgn6-19290-11-50-27-759z.mullvad.test. (61)
11:50:27.816542 IP OpenWrt.lan.53 > Pixel-Tablet.lan.48267: 44347 NXDomain 0/0/0 (65) 
11:50:27.816588 IP Pixel-Tablet.lan.43821 > OpenWrt.lan.53: 36295+ A? 307lf5rgn6-19291-11-50-27-789z.mullvad.test. (61)
11:50:27.816625 IP OpenWrt.lan.53 > Pixel-Tablet.lan.16747: 44584 NXDomain 0/0/0 (61)

Même si « Block connections without VPN » était activé, rien ne devrait sortir de l'appareil sauf le trafic chiffré WireGuard. Or, ici, on voit sortir du DNS en clair depuis l'appareil

Conclusion et recommandations

La fuite DNS peut impacter gravement la vie privée des utilisateurs, et être utilisée pour détecter leur emplacement approximatif ou déterminer les sites web et services qu'ils utilisent

Ces découvertes montrent une fois de plus que « Block connections without VPN » ne correspond ni à son nom (ni à sa documentation) et contient plusieurs défauts :

  • Une application peut encore faire fuir du trafic DNS sous les conditions mentionnées précédemment
  • Comme déjà rapporté, du trafic de vérification de connexion fuit également toujours

Selon votre modèle de menace, il peut être nécessaire d'éviter complètement l'utilisation d'Android pour les activités sensibles ou de prendre d'autres mesures d'atténuation pour empêcher ces fuites :

  • Assurez-vous de garder l'application à jour, car elle vise à atténuer partiellement ce problème

Avis de GN⁺

  • Ce problème est fondamentalement un bug de l'OS Android et Google doit le corriger rapidement. Il n'est pas souhaitable que tous les développeurs d'applications proposant des fonctions VPN aient à s'efforcer de résoudre ce problème.
  • Que l'option « Block connections without VPN » ne fonctionne pas selon sa documentation et qu'il y ait une fuite DNS représente un problème important pour les utilisateurs. L'un des principaux motifs d'utilisation d'un VPN est la protection de la vie privée, car une fuite DNS peut exposer l'historique de navigation de l'utilisateur.
  • On peut considérer qu'il reste utile de déployer des solutions de sécurité et de confidentialité supplémentaires en plus du VPN afin de prévenir les fuites non intentionnelles provoquées par l'OS, même si la sécurité de la technologie de tunneling VPN reste globale-ment élevée.
  • Du point de vue des développeurs d'applications, on peut contourner un bug de l'OS au niveau de l'application, mais une amélioration de l'OS semble nécessaire pour une correction durable.
  • Avec la montée en sophistication et en popularité des technologies VPN, ce type de problème de sécurité devient de plus en plus visible. Il semble donc nécessaire de poursuivre les audits de sécurité et les améliorations continues des fonctions réseau et VPN des OS mobiles

À lire aussi

1 commentaires

 
GN⁺ 2024-05-04
Avis de Hacker News
  • Mullvad a été salué pour la richesse des informations fournies, l’explication du problème, les solutions à court terme, les solutions potentielles et les points qui doivent être corrigés sur Android.
  • Selon le développeur de rethinkdns, le « paranoid networking » d’Android prévoit des exceptions pour les applications système et OEM, et la plupart des corrections de bugs ne modifieront pas cette hypothèse de base.
  • Android prend en charge la « transition transparente » entre deux appareils TUN, mais l’implémentation est difficile.
  • Android a depuis longtemps ce problème : même lorsqu’il n’essaie d’utiliser que le DNS interne, il bascule parfois vers les données cellulaires et utilise un DNS externe.
  • Avec Apple, la situation ne devrait probablement pas être meilleure par défaut, car un VPN « privacy » tente de proxifier tout le trafic.
  • Sur Android, il n’est pas possible de définir directement un serveur DNS IPv6, et ils changent chaque fois que le réseau Wi-Fi change.
  • Il est possible d’éviter les fuites de trafic en utilisant un pare-feu MikroTik pour bloquer tout trafic qui ne va pas vers l’adresse IP du serveur VPN.
  • Sans accès root, tout système est fondamentalement peu sûr, et Android et iOS sont risibles.
  • La configuration la plus sûre consiste à désactiver les données mobiles du téléphone et à utiliser un hotspot OpenWRT pour effectuer le VPN en amont.
  • Les fuites DNS peuvent exposer la localisation de navigation de l’utilisateur et même sa localisation réelle, ce qui neutralise l’objectif du VPN.
  • Sur iOS aussi, le trafic APNS fuit hors du VPN (à l’exception des VPN pris en charge par le système et installés via un profil de provisioning).
  • On se demande si ces « bugs » ne sont pas volontairement placés, car, compte tenu de la collaboration entre les grandes entreprises technologiques et les organismes de renseignement, il est difficile de croire que tant de bugs Android sont là « par hasard ».