Les attaquants potentiels peuvent-ils découvrir les adresses IPv6 et les noms AAAA?


26

Il est assez courant de recevoir chaque jour un nombre important de tentatives de piratage mineures en essayant des noms d'utilisateur / mots de passe communs pour des services comme SSH et SMTP. J'ai toujours supposé que ces tentatives utilisaient le "petit" espace d'adressage d'IPv4 pour deviner les adresses IP. Je remarque que je n'ai aucune tentative de piratage sur IPv6 malgré le fait que mon domaine ait des enregistrements de nom AAAA reflétant chaque enregistrement A Name et tous les services IPv4 sont également ouverts à IPv6.

En supposant un DNS public (route AWS 53) avec un sous-domaine obscur pointant vers un suffixe / 64 raisonnablement aléatoire; Les adresses et / ou sous-domaines IPv6 sont-ils détectables à distance sans essayer chaque adresse dans un préfixe / 64 bits ou chaque sous-domaine dans une très longue liste de noms communs?

Je suis bien sûr conscient que l'exploration du Web à la recherche de (sous) noms de domaine répertoriés est assez simple. Je suis également conscient que les machines du même sous-réseau peuvent utiliser NDP. Je suis plus intéressé à savoir si DNS ou les protocoles sous-jacents d'IPv6 permettent la découverte / la liste de domaines et d'adresses inconnus à distance.



1
Cela ressemble à la sécurité par l'obscurité ... Si votre seule ligne de défense utilise (soi-disant) des identifiants (supposément) difficiles à découvrir (noms ou adresses IP), vous pouvez vous attendre à être violé à un moment donné. Vous pouvez être relativement à l'abri des exploits génériques / des coups aléatoires, mais si vous devez vous défendre contre des attaques actives contre vous, cette ligne de défense se rompt. Il y a une tonne de façons possibles de découvrir des noms "obscurs", regardez geekflare.com/find-subdomains pour commencer
Patrick Mevzek

3
@patrick Si vous n'avez qu'une seule ligne de défense, vous obtenez une période de violation. Je ne veux toujours pas que mes portes verrouillées soient annoncées dans le monde entier
Philip Couling

2
Non. D'après ma propre conclusion, ce n'est pas ma seule ligne de sécurité. Je n'ai jamais suggéré le contraire.
Philip Couling

Réponses:


34

Les robots malveillants ne devinent plus les adresses IPv4. Ils les essaient tout simplement. Sur les systèmes modernes, cela peut prendre aussi peu que quelques heures.

Avec IPv6, ce n'est plus vraiment possible, comme vous l'avez supposé. L'espace d'adressage est tellement plus grand qu'il n'est même pas possible d'analyser par force brute un seul sous-réseau / 64 au cours d'une vie humaine.

Les bots devront faire preuve de plus de créativité s'ils veulent continuer à scanner à l'aveugle sur IPv6 comme sur IPv4, et les opérateurs de bots malveillants devront s'habituer à attendre beaucoup plus longtemps entre trouver des machines, sans parler des machines vulnérables.

Heureusement pour les méchants et malheureusement pour tout le monde, l'adoption d'IPv6 a été beaucoup plus lente qu'elle n'aurait dû. L'IPv6 a 23 ans mais n'a connu une adoption significative qu'au cours des cinq dernières années environ. Mais tout le monde maintient ses réseaux IPv4 actifs, et très peu d'hôtes sont uniquement IPv6, donc les opérateurs de robots malveillants ont été peu incités à faire le changement. Ils ne le feront probablement pas tant qu'il n'y aura pas d'abandon significatif d'IPv4, ce qui ne se produira probablement pas dans les cinq prochaines années.

Je m'attends à ce que les devinettes aveugles ne soient probablement pas productives pour les bots malveillants, lorsqu'ils passeront finalement à IPv6, ils devront donc passer à d'autres moyens, comme le forçage brutal des noms DNS ou le forçage brutal ciblé de petits sous-ensembles de chaque sous-réseau.

Par exemple, une configuration de serveur DHCPv6 commune donne des adresses ::100via via ::1ffpar défaut. C'est juste 256 adresses à essayer, sur un ensemble / 64. La reconfiguration du serveur DHCPv6 pour sélectionner des adresses dans une plage beaucoup plus large atténue ce problème.

Et l'utilisation d'adresses EUI-64 modifiées pour SLAAC réduit l'espace de recherche à 2 24 multiplié par le nombre d'OUI attribués. Bien qu'il s'agisse de plus de 100 milliards d'adresses, c'est bien moins de 2 64 . Les robots aléatoires ne prendront pas la peine de fouiller cet espace, mais les acteurs malveillants au niveau de l'État, pour des attaques ciblées, surtout s'ils peuvent faire des suppositions éclairées sur les cartes réseau qui pourraient être utilisées, pour réduire davantage l'espace de recherche. L'utilisation des adresses de confidentialité stables RFC 7217 pour SLAAC est facile (au moins sur les systèmes d'exploitation modernes qui la prennent en charge) et atténue ce risque.

La RFC 7707 décrit plusieurs autres façons dont la reconnaissance peut être effectuée dans les réseaux IPv6 pour localiser les adresses IPv6 et comment atténuer ces menaces.


De nombreux robots sont déjà TRÈS créatifs, et il existe probablement un énorme marché noir pour les meilleurs robots, probablement avec un accès groupé à leur réseau de robots pendant qu'ils y sont. Les bots qui ne sont pas créatifs doivent être facilement bloqués par n'importe quelle méthode avec laquelle vous bloquez les créatifs.
BeowulfNode42

1
La plupart de ce que je vois est la variété non créative de bot. Même si c'est la variété créative qui me tient éveillé la nuit. Heureusement, j'ai un client qui me paie pour perdre le sommeil. Cela dit, je n'ai pas encore vu de trafic de robots significatif sur IPv6, créatif ou non.
Michael Hampton

Oui, j'ai récemment remarqué que les tentatives de force de bruit s'étalent sur plusieurs mois (un nom d'utilisateur ou un mot de passe par jour) suggérant que chaque nom d'utilisateur ou mot de passe est essayé contre chaque serveur SSH public sur Internet (IPv4) avant de passer au nom d'utilisateur ou mot de passe suivant .
Philip Couling

8

J'ai constaté que de nombreux bots de nos jours ne devinaient pas, avec IPv4 ou IPv6. La sécurité par l'obscurité n'est pas du tout une sécurité. L'obscurité retarde / réduit simplement le nombre d'attaques pendant un certain temps, puis elle n'est plus pertinente.

Les pirates connaissent le nom de domaine de votre entreprise à partir de votre site Web ou de votre adresse e-mail, quelles adresses IP de serveur public vous publiez pour des choses comme les e-mails, les SPF, les serveurs Web, etc. les noms communs, comme www, mail, smtp, imap, pop, pop3, ns1, etc., puis grattez votre site Web pour toute donnée supplémentaire qu'ils peuvent trouver. Ils récupéreront dans leur magasin d'analyses précédentes vos noms DNS, vos adresses IP et les ports sur lesquels vous concentrer. Ils récupéreront également une liste de paires adresse e-mail / mot de passe de toutes les violations de données qu'ils peuvent trouver et essaieront toutes ces connexions, ainsi que quelques-unes supplémentaires avec les systèmes qu'ils pensent que vous utilisez sur vos ports. Ils vont même jusqu'à apprendre les noms et les rôles professionnels de votre personnel pour essayer d'exécuter une attaque d'ingénierie sociale. Notre filtre anti-spam est constamment bombardé de tentatives d'arnaqueurs prétendant être quelqu'un de la direction qui a besoin d'un virement bancaire urgent. Oh, ils apprennent également qui sont vos partenaires commerciaux et prétendent être eux, et vous font savoir que leurs coordonnées bancaires ont changé. Parfois, ils savent même quelles plateformes cloud vos partenaires commerciaux utilisent pour leur facturation.

Les criminels ont accès à des outils de Big Data tout comme tout le monde, et ils ont accumulé une quantité étonnamment énorme de données. Voir ce témoignage de certains professionnels de l'informatique au congrès américain https://www.troyhunt.com/heres-what-im-telling-us-congress-about-data-breaches/

En ce qui concerne les violations de données, si une entreprise perd quelque chose d'aussi apparemment inutile qu'un journal de serveur Web, cela contiendra les adresses IP v4 ou v6 de tous ceux qui ont utilisé ce serveur à ce moment-là et les pages auxquelles ils ont accédé.

En conclusion, aucune de ces méthodes ne nécessite qu'un attaquant devine quelle adresse IP vous utilisez, il le sait déjà.

Edit : Comme un peu d'exercice, j'ai passé toutes les 2 minutes à parcourir votre site (à partir de votre profil), à essayer l'un des outils d'analyse en ligne liés ailleurs ici, et un peu à regarder avec nslookup et à découvrir quelques choses à votre sujet . Je suppose que l'une des adresses obscures dont vous parlez implique

  • un nom de planète similaire à celui que vous publiez
  • freeddns
  • et une adresse IPv6 qui se termine par 2e85: eb7a
  • et il exécute ssh

Comme la plupart de vos autres adresses IPv6 publiées se terminent par :: 1. Ce n'est qu'à partir d'informations que vous publiez publiquement avec 1 petite supposition. Est-ce de l'IP que vous vouliez cacher?

Edit 2 : Un autre regard rapide, je vois que vous publiez votre adresse e-mail sur votre site Web. Vérification du site https://haveibeenpwned.com/ pour savoir quelles violations de données cette adresse a été détectée et quelles données sont disponibles sur le marché noir. Je vois que c'est dans les brèches

  • Adobe violation Octobre 2013: Données compromises: adresses e-mail, indices de mot de passe, mots de passe, noms d'utilisateur
  • MyFitnessPal: En février 2018 Données compromises: adresses e-mail, adresses IP, mots de passe, noms d'utilisateur
  • MySpace: environ 2008 Données compromises: adresses e-mail, mots de passe, noms d'utilisateur
  • PHP Freaks: En octobre 2015 Données compromises: dates de naissance, adresses e-mail, adresses IP, mots de passe, noms d'utilisateur, activité du site Web
  • QuinStreet: Vers la fin de 2015 Données compromises: dates de naissance, adresses e-mail, adresses IP, mots de passe, noms d'utilisateur, activité du site Web

En voyant si cette partie du nom d'utilisateur de l'adresse e-mail est utilisée par d'autres fournisseurs de messagerie populaires, je vois qu'il y a beaucoup plus de données. Ce serait une autre petite supposition qu'un bot pourrait faire. Si certaines d'entre elles sont en corrélation avec la partie qui est déjà connue de vous, le bot peut supposer que c'est tout ce que vous, il n'a pas à être certain, cela suffit probablement. Avec des données supplémentaires dans ces violations

  • Verifications.io: en février 2019 Données compromises: dates de naissance, adresses e-mail, employeurs, genres, emplacements géographiques, adresses IP, titres d'emploi, noms, numéros de téléphone, adresses physiques
  • River City Media Spam List En janvier 2017 Données compromises: adresses e-mail, adresses IP, noms, adresses physiques
  • Apollo: en juillet 2018, la startup de l'engagement commercial Données compromises: adresses e-mail, employeurs, emplacements géographiques, titres d'emploi, noms, numéros de téléphone, salutations, profils de réseaux sociaux
  • Entreprises B2B USA Mi-2017 Données compromises: adresses e-mail, employeurs, titres d'emploi, noms, numéros de téléphone, adresses physiques
  • Bitly: en mai 2014 Données compromises: adresses e-mail, mots de passe, noms d'utilisateur
  • Collection # 1 (non vérifiée): en janvier 2019, une grande collection de listes de bourrage d'informations d'identification (combinaisons d'adresses e-mail et de mots de passe utilisées pour détourner des comptes sur d'autres services) a été découverte en train d'être distribuée sur un forum de piratage populaire
  • Dropbox: mi-2012 Données compromises: adresses e-mail, mots de passe
  • Exploit.In (non vérifié): fin 2016, une énorme liste de paires d'adresses e-mail et de mots de passe est apparue dans une "liste combinée" appelée "Exploit.In"
  • HauteLook: Mi-2018 Données compromises: dates de naissance, adresses e-mail, genres, emplacements géographiques, noms, mots de passe
  • Pemiblanc (non vérifié): en avril 2018, une liste de bourrage d'informations d'identification contenant 111 millions d'adresses e-mail et de mots de passe connus sous le nom de Pemiblanc a été découverte sur un serveur français
  • ShareThis: En juillet 2018 Données compromises: dates de naissance, adresses e-mail, noms, mots de passe
  • Ticketfly: en mai 2018 Données compromises: adresses e-mail, noms, numéros de téléphone, adresses physiques

Pendant que le bot y est, il peut vérifier Facebook et il peut voir que l'une des pages Facebook avec votre nom a la même photo que sur votre site Web, et maintenant il en sait plus sur vous et vos amis. De plus, je suppose que le membre de la famille que vous citez est votre mère, qui indique "le nom de jeune fille de votre mère". Depuis Facebook, il peut également vérifier quel profil linkedin est le vôtre.

Il y a beaucoup plus d'informations en ligne sur nous que les gens ne le pensent. L'analyse des mégadonnées et de l'apprentissage automatique est réelle, elle est là maintenant et une grande partie des données qui ont été publiées ou divulguées en ligne peuvent être corrélées et utilisées. Ce que vous devez savoir, étant donné que vous indiquez que vous avez obtenu un baccalauréat en IA et en informatique en 2003-2007. Les choses ont parcouru un long chemin depuis lors, en particulier avec les progrès que Google publiait depuis la fin de votre diplôme. Les gens étant des gens, la plupart ne chercheront qu'à profiter de vous, certains utilisant les données de manière raisonnable et légale, mais d'autres les utiliseront de toutes les manières possibles.

Mon point avec tout cela est double, que nous publions plus d'informations que nous ne pensons en faire, et le but du DNS est de publier la conversion des noms en adresses IP.


6

Concernant les enregistrements AAAA:

Le DNS est traditionnellement non chiffré. Bien qu'il existe une famille de normes (DNSSEC) pour la signature DNS, le cryptage des enregistrements DNS a eu un processus de déploiement beaucoup plus aléatoire, et il est donc généralement plus sûr de supposer que n'importe quel MitM peut lire toutes vos requêtes DNS à moins que vous ne soyez allé hors de votre façon de configurer explicitement le DNS chiffré côté client. Vous sauriez si vous l'aviez fait parce que c'est tout à fait une épreuve .

(De plus, votre navigateur Web envoie probablement un SNI non chiffré dans la négociation TLS, après avoir résolu le domaine. Il n'est pas évident de savoir comment procéder pour boucher ce trou, car un VPN ou un Tor peut toujours être MitM'd entre la sortie nœud ou point de terminaison VPN et le serveur distant. Les bons employés de Cloudflare travaillent à résoudre ce problème pour de bon, mais ESNI dépendra également de la mise en œuvre du client, en particulier pour Chrome , si cela va vraiment décoller.)

Cependant, les attaques MitM peuvent ou non être un problème, selon votre modèle de menace. Plus important est le simple fait que les noms DNS sont destinés à être des informations publiques. De nombreuses personnes (moteurs de recherche, registraires DNS, etc.) collectent et publient les noms DNS pour des raisons entièrement bénignes. Les résolveurs DNS appliquent généralement des limites de débit, mais ces limites sont généralement assez généreuses, car elles sont destinées à arrêter les attaques DoS, et non l'énumération des sous-domaines. La création d'un certificat HTTPS implique souvent la publication du nom de domaine pour que tous puissent le voir, en fonction de l'autorité de certification ( Let's Encrypt le fait , et bien d'autres encore). En pratique, il est tout à fait impossible de garder un domaine ou un sous-domaine secret, car à peu près tout le monde suppose qu'il est public et ne fait aucun effort pour le cacher.

Donc, pour répondre à cette question:

Je suis plus intéressé à savoir si DNS ou les protocoles sous-jacents d'IPv6 permettent la découverte / la liste de domaines et d'adresses inconnus à distance.

Techniquement, non, ce n'est pas le cas. Mais cela n'a pas d'importance car une énorme quantité de technologie de couche supérieure suppose simplement que vos enregistrements DNS sont publics, donc ils le seront inévitablement.


1
SNI crypté est en cours de développement. Donnez-lui un an ou deux.
Michael Hampton

1
@MichaelHampton: Je crois que l'ESNI se produira. Mais étant donné les antécédents de l'industrie (DNSSEC, IPv6, DANE, ...), je suis un peu sceptique qu'un "un an ou deux" sera vraiment suffisant. Quoi qu'il en soit, nous verrons bien assez tôt.
Kevin

1
CloudFlare le pousse donc je parierai le plus tôt possible :)
Michael Hampton

Je me retrouve à vouloir dire "oui mais ..." à chacun de vos exemples spécifiques, mais c'est un très bon point que les noms DNS sont généralement supposés être des informations publiques. +1
Philip Couling
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.