Question:
Pourquoi mon adresse IP interne (privée) est-elle visible sur Internet?
Lova Andrian
2015-07-24 13:40:12 UTC
view on stackexchange narkive permalink

En visitant certains sites Web comme http://www.monip.org ou http://ip-api.com, j'obtiens le résultat suivant: 

  Votre adresse IP actuelle - IP: 197.158.xx - IP interne: 192.168.xx

Je comprends que je peux voir mon adresse IP publique (197.158.xx ). Ce que je n'arrive pas à comprendre, c'est pourquoi mon adresse IP interne est visible sur Internet ?

Ces sites Web ne semblent pas utiliser Plug-in Flash, applet Java ou autres scripts. Mon FAI effectue un NAT de mon adresse IP interne afin d'accéder à Internet: 

  Modem sans fil 3G [192.168.xx] -------- FAI [NAT à 197.158. xx] ------- Internet

Alors, comment est-il possible pour un site Web de voir mon adresse IP interne?

J'ai regardé le trafic réseau et remarqué la page générant des requêtes STUN. Il a généré des requêtes STUN à partir de mes deux adresses IP locales. La page affichait mes deux adresses IP locales même si les requêtes STUN ne fonctionnaient que pour l'une d'entre elles.
Ce qui est intéressant, c'est que seul ip-api.com donne mon adresse IP interne, pas monip.com. Pour moi en tout cas.
Il existe quelques extensions Chrome pour bloquer cela. Par exemple. [webrtc-leak-prevent] (https://chrome.google.com/webstore/detail/webrtc-leak-prevent/eiadekoaikejlgdbkbdfeijglgfdalml)
Parce que Mozilla & co ne [se soucient pas de votre vie privée] (https://bugzilla.mozilla.org/show_bug.cgi?id=959893). Ils préfèrent que Firefox agisse silencieusement comme un logiciel espion plutôt que de déranger l'utilisateur avec une invite.
@CodesInChaos Fait amusant! L'employé de Mozilla qui bloque les tentatives pour résoudre le problème, Eric Rescorla, a également travaillé avec la NSA sur leurs modifications "Extended Random" (porte dérobée) pour Dual Eliptic Curve, qui visaient à rendre les ordres de grandeur cryptographiques plus faciles à craquer.
@Boann N'a-t-il pas co-écrit environ chaque seconde RFC liée à TLS? Ainsi, les RFC liés à la NSA pourraient simplement être des sous-produits de son activité liée au TLS généralement élevée.
Sept réponses:
Christopher
2015-07-24 15:27:51 UTC
view on stackexchange narkive permalink

La source la plus probable de ces informations est l'implémentation WebRTC de votre navigateur.

Vous pouvez voir cela dans le code source d'ip-api. com.

De https://github.com/diafygi/webrtc-ips, qui fournit également une démo de cette technique:

Firefox et Chrome ont implémenté WebRTC qui permet de faire des requêtes aux serveurs STUN qui renverront les adresses IP locales et publiques pour l'utilisateur. Ces résultats de requête sont disponibles en javascript, vous pouvez donc désormais obtenir les adresses IP locales et publiques d'un utilisateur en javascript.

Il a été récemment noté que le New York Times utilisait cette technique pour aider à faire la distinction entre les vrais visiteurs et les robots (c'est-à-dire que si l'API WebRTC est disponible et renvoie des informations valides, il s'agit probablement d'un vrai navigateur).

Il y a quelques Chrome extensions qui prétendent bloquer cette API, mais elles ne semblent pas efficaces pour le moment. C'est peut-être parce qu'il n'y a pas encore de hooks dans le navigateur, comme GitHub README fait allusion à:

De plus, ces requêtes STUN sont effectuées en dehors de la procédure XMLHttpRequest normale, donc elles ne le sont pas visible dans la console développeur ou pouvant être bloqué par des plugins tels que AdBlockPlus ou Ghostery.

Merci d'avoir clarifié tout cela en publiant le code source.
C'est un triste état de choses que les fabricants de navigateurs pelletent tant de ces nouvelles API non testées dans les navigateurs sans se soucier des dommages à la vie privée.
La vraie question est, pourquoi voudriez-vous * jamais * cela dans un but légitime (autre que le dire à l'utilisateur, je suppose)?
@Schilcote VoIP dans le navigateur ou vidéoconférence? Mais la façon dont ils l'ont fait, sans aucun moyen de le désactiver, est effrayante.
[Désactiver WebRTC] (https://addons.mozilla.org/en-US/firefox/addon/happy-bonobo-disable-webrtc) est un module complémentaire de Firefox qui empêche les fuites IP LAN.
uBlock Origin bloque également cela avec succès.
La deuxième extension Chrome que vous avez liée semble fonctionner correctement pour moi.
C'est suffisant; aucune des extensions n'a fonctionné quand j'ai essayé. Mais j'utilise uMatrix, et cela bloque cela.
Y a-t-il des implications en matière de confidentialité pour un tiers connaissant votre adresse IP privée NATted? J'aurais pensé que cela aurait peu de sens pour quelqu'un en dehors de votre réseau.
@rakslice Plus de sécurité mais toujours https://miki.it/blog/2015/4/20/the-power-of-dns-rebinding-stealing-wifi-passwords-with-a-website/
Ainsi, la fuite de confidentialité est spécifiée dans un protocole, _et_ elle est également déjà utilisée par des sites Web du monde réel pour éventuellement refuser l'accès aux utilisateurs qui ont bloqué la fuite? Cela semble assez mauvais ...
@Schilcote - Certains services basés sur un abonnement - en particulier ceux accessibles via une sorte de proxy - pourraient trouver cela utile pour distinguer les utilisateurs simultanés individuels, bien que mon organisation utilise simplement des identifiants de session pour cela ... et si nous l'utilisions, nous serions francs à propos de ça
@Boann, ce n'est pas si mal. Il est censé y avoir une demande d'autorisation chaque fois que vous demandez ces informations, et seuls les sites HTTPS enregistreront votre choix. Donc, évidemment, il y a * a * été un peu pensé pour la confidentialité. Le problème est qu'il était possible de démarrer une partie de la requête WebRTC avant que vous ne demandiez UserMedia (où l'autorisation est demandée à l'utilisateur). Et WebRTC a certainement besoin de ces informations puisqu'il s'agit d'un protocole P2P et que les utilisateurs sont généralement derrière les NAT. Un bogue involontaire n'indique pas une absence totale de souci de sécurité.
ce site a détecté mon adresse IP privée et mon VPN également: http://whatismyip.byethost7.com/ en utilisant cette technique que vous avez mentionnée.
Je ne comprends pas pourquoi ils n'ont pas ajouté une autre fenêtre de confirmation pour cela.Tout comme le navigateur demande des notifications vidéo, microphone ou bureau.
r00t
2015-07-24 15:18:39 UTC
view on stackexchange narkive permalink

Une méthode courante pour obtenir l'adresse IP interne consiste à utiliser RTCPeerConnection dans JavaScript.

http://ip-api.com/ par exemple, appelle un javascript fonction nommée "gi" qui contient le code suivant: 

  ... o = window.RTCPeerConnection || window.mozRTCPeerConnection || window.webkitRTCPeerConnection, ...

Techniquement, cela se fait en définissant un callback sur la connexion RTC (objet o) avec "onicecandidate" et en obtenant l'attribut candidat.candidate de l'événement. Cela listera toutes les adresses IP locales de vos interfaces réseau.

Jetez un œil au Module: Get Internal IP WebRTC .

Le script JavaScript peut renvoyer ces informations à un serveur Internet, mais http://ip-api.com/, par exemple, ne fait que les afficher au client.

Adam Katz
2015-07-25 06:54:40 UTC
view on stackexchange narkive permalink

WebRTC n'est que l'une des nombreuses façons de découvrir les adresses IP LAN.

Il y a eu une belle présentation Black Hat 2012 sur ce sujet, appelée Menaces mixtes et JavaScript: un plan pour une compromission permanente du réseau, dans lequel Phil Purviance et Josh Brashars ont présenté une méthode automatisée pour rechercher et effacer votre routeur Wi-Fi domestique en un seul cliquez sur un site Web.

Blended Threats and JavaScript

Ce WebRTC était antérieur, ils devaient donc découvrir l'adresse IP de votre routeur d'une autre manière. Cela peut être fait avec des scanners JavaScript tels que jslanscanner, JSScan, JS-Recon, mais une simple (mais grande) collection d'objets intégrés qui devinez l'adresse du routeur (par exemple en incorporant une image de routeur attendue et en notant quand il se charge avec succès). Une fois que vous avez l'adresse, vous pouvez deviner le mot de passe (en commençant par la valeur par défaut attendue) en utilisant RouterPasswords.com ou même en contournant l'authentification via Routerpwn.com.

Comme preuve de concept, leur démonstration a découvert l'adresse IP du routeur, a recherché son mot de passe par défaut, s'est connecté et a installé automatiquement le micrologiciel de remplacement (DD-WRT). Une véritable attaque pourrait avoir un certain nombre de capacités malveillantes sur le nouveau micrologiciel et pourrait facilement le faire passer pour le système de routeur d'origine non modifié.

(Certes, cela identifie l'adresse IP LAN de votre routeur wifi domestique plutôt que votre adresse IP du LAN local, mais c'est assez proche et sans doute plus alarmant.)

Mark
2015-07-24 13:46:49 UTC
view on stackexchange narkive permalink

Il est fort probable que votre navigateur (ou votre FAI) envoie un en-tête X-Forwarded-For qui révèle votre adresse IP interne. Consultez un site comme celui-ci pour voir les en-têtes que vous envoyez.

Je n'aurais pas pensé que mon FAI aurait cette information non plus. Le navigateur est probablement correct.
Si ce sont eux qui font le NAT (ou, plus probablement dans votre cas, le mandataire), ils DOIVENT avoir ces informations afin de renvoyer la réponse du serveur.
J'ai testé les liens, et ce n'est pas ce qui se passe. Aucun en-tête «X-Forwarded-For» n'est envoyé, et le deuxième lien parvient toujours à trouver les adresses IP locales.
@Stephane, au Royaume-Uni, la plupart des ménages ont leur propre routeur, tout ce que le FAI attribue est l'adresse IP externe.
Ce n'est pas ainsi que fonctionne NAT. Vous confondez les concepts. -1
@LightnessRacesinOrbit, ce n'est pas ainsi que fonctionne NAT, mais je n'ai jamais dit NAT. Un proxy transparent ajoutera très bien les en-têtes.
kasperd
2015-07-24 16:43:39 UTC
view on stackexchange narkive permalink

Le premier de vos deux liens n'a pas fonctionné pour moi, mais le second a fonctionné. En visualisant le code JavaScript du deuxième lien, j'ai trouvé qu'il utilise window.RTCPeerConnection.

Tous les navigateurs ne prennent pas en charge RTCPeerConnection , mais dans ceux cela peut être utilisé pour identifier les adresses IP locales du navigateur. Cette réponse sur Stack Overflow donne un exemple de la façon dont l'API asynchrone de RTCPeerConnection peut être utilisée pour trouver une adresse IP locale.

Cela semble avoir beaucoup de chevauchement avec [une réponse publiée précédemment] (http://security.stackexchange.com/a/94788/971). Je me demande si la dernière phrase pourrait être plus utile en tant que modification de l'une des réponses existantes plutôt qu'une nouvelle réponse?
@D.W. À l'époque, je n'ai posté que trois réponses qui m'étaient visibles. Et aucun d'entre eux n'a mentionné RTCPeerConnection. Je ne sais pas pourquoi ces deux autres réponses ne m'ont pas été montrées à l'époque.
Cool! Problème du système, peut-être; qui sait. Quoi qu'il en soit, merci pour le lien vers SO; Bon produit.
kevino_17
2015-07-24 13:59:56 UTC
view on stackexchange narkive permalink

Il est probable que le site héberge du JavaScript qui s'exécute sur votre machine et qu'il détermine votre adresse interne et la met à l'écran.

Le serveur distant ne verra pas votre adresse interne et c'est peu probable à transmettre dans un en-tête HTTP.

Cela pourrait être correct. Mais comment le code javascript pourrait-il trouver l'adresse IP de l'hôte sur lequel il s'exécute?
Je crois que cette page particulière ne verra pas les adresses IP locales. Mais s'il est visible par javascript, alors n'importe quel site peut inclure du javascript qui le renverra au serveur.
@kasperd C'est possible via javascript, il y a une preuve de concept [ici] (http://net.ipcalf.com/)
Vous pouvez utiliser WebRTC en JavaScript pour ce faire. Une autre démo [ici] (https://diafygi.github.io/webrtc-ips/)
David Scholefield
2015-07-24 15:05:31 UTC
view on stackexchange narkive permalink

Le protocole TCP / IP sous-jacent ne divulguera pas votre adresse interne - il n'est pas utilisé pour le routage sur l'Internet public et n'est pas capturé / stocké dans les paquets de protocole eux-mêmes au niveau de la couche 3 car les paquets sont créés par votre routeur de périmètre. N'importe quel nombre de services ou de clients que vous exécutez peut divulguer cela dans la couche 7 dans les en-têtes, les bannières de service, etc.

Le moyen définitif de découvrir ce qui divulgue ces informations est pour utiliser un programme de vidage du trafic réseau sur votre réseau interne (comme WireShark ou tcpdump) et vérifier le contenu des paquets à la couche 7, c'est-à-dire la charge de données, et si l'adresse interne n'est pas enregistrée quelque part dans la charge de données par votre client, alors elle viendra probablement de votre routeur de périmètre (bien que cela soit peu probable) et vous devrez capturer le trafic réseau du côté Internet du routeur quelque part pour voir comment cela se passe.



ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...