Je m'appelle Rob Stackle, je suis consultant en sécurité de Phoenix, en Arizona, et je travaille principalement comme pentester. Je participe à des conférences DefCon depuis 1996, j'aime la photographie à haute altitude et ce week-end était le onzième anniversaire de notre mariage. Je tiens à remercier ma femme étonnante et compréhensive Linda, qui ne s'attendait pas à ce que ma participation à DefCon signifie que chaque année, je serai obligée de célébrer notre anniversaire de mariage à Vegas, ce que je suis vraiment désolé.
Je vais vous parler de plusieurs choses liées à la recherche sur laquelle j'ai travaillé au cours des dernières années. Ils sont unis par un thème commun - si vous ne surveillez pas votre trafic DNS et ne comprenez pas ce qui s'y passe, quand tout est en ordre, alors vous ne ferez probablement pas attention lorsque de mauvaises choses commenceront à lui arriver. J'ai "violé" le DNS pendant plusieurs années et cela a toujours été l'un de mes vecteurs d'attaque préférés. Vous pouvez dépenser une fortune pour renforcer le périmètre du réseau, mais si je peux contrôler l'un de vos appareils, croyez-moi, votre jeu est terminé.
L'absence de vulnérabilités sur le marché pour détecter les configurations incorrectes me donne toujours la possibilité de «mettre le pied dans la porte». Aujourd'hui, nous discuterons de divers sujets dans lesquels je parlerai de mes aventures avec DNS et de mes astuces sur les personnes liées au DNS.
Ces sujets sont consacrés à l'incompréhension du comportement du DNS par les utilisateurs finaux du réseau, je vais parler un peu des personnes qui n'ont pas enregistré leurs domaines et du piratage de domaine lui-même.
Lors des conférences Black Hat et DefCon en 2011, Artyom Daineberg a parlé de ce qu'il a appelé le beat squatting, ou «flipping a beat». Ceux qui ne connaissent pas cette étude, mais qui s'intéressent à ce problème dans le DNS des domaines populaires, peuvent télécharger le matériel de sa présentation en utilisant les liens fournis sur cette diapositive.
Page du projet /
Présentation vidéo /
DiapositivesLorsque j'ai lu l'annonce de son discours, publiée avant même le rapport sur Black Hat, je me suis immédiatement intéressé à la façon dont cela pouvait être utilisé à mes propres fins. Sans entrer dans les détails, je vais vous expliquer ce qu'est le battement accroupi, pourquoi cela se produit et ce qu'il affecte. Je vais vous montrer quelques exemples du risque de retourner accidentellement un peu en mémoire lorsque 1 passe à 0 et vice versa. Les diapositives suivantes montrent à quoi cela ressemble comme un exemple de ligne en mémoire qui affiche un nom de domaine.
Au milieu d'une telle ligne, l'unité se transforme en zéro. Artyom a enquêté sur le phénomène dans lequel une erreur d'un seul bit dans la bonne partie de la mémoire au bon moment a forcé le client à demander un nom de domaine complètement légitime mais incorrect.
Il y a eu beaucoup de discussions sur la probabilité et les causes d'une telle erreur, mais j'ai commencé à étudier toutes les façons qui permettent à cette erreur d'être utilisée à des fins malveillantes. Ainsi, le squattage DNS vous permet de déformer les noms de domaine, puis d'enregistrer ces «mauvais» domaines et de leur envoyer des demandes d'utilisateurs.
La diapositive suivante montre qu'à la suite d'un squattage du nom de domaine Google, lorsqu'un proton de haute énergie en mémoire "frappe" 1, ce qui signifie la lettre g, le transforme en 0, ce qui signifie la lettre f, et par conséquent, l'utilisateur est redirigé vers goofle.com .
Ainsi, votre navigateur vous redirigera complètement vers un autre site et se fera un plaisir de trouver la réponse pour vous. Dans le même temps, DNS SEC ne pourra en aucun cas vous aider, et en fait il y a très peu de possibilités pour empêcher cette erreur de manière complètement invisible, à l'exception de l'utilisation de la mémoire ECC, qui reconnaît et corrige automatiquement les erreurs de bit.
Cependant, ce type de mémoire n'est pas très courant, et même si vous avez utilisé ECC, il existe de nombreux endroits où le squattage de bits peut se produire et où la mémoire ECC n'est jamais utilisée, par exemple, dans une carte réseau ou dans le cache DRAM d'un disque dur.
Deineberg a décrit en détail les causes du problème, mais en général, on peut dire que des erreurs de mémoire se produisent, parfois elles endommagent la mémoire et parfois cela a un effet sur le DNS. Fondamentalement, le «retournement» d'un bit est dû à des dommages physiques à la mémoire, à une surchauffe, à des problèmes électriques, à une exposition à des rayonnements et même à des rayonnements cosmiques.
La présentation est interrompue par l'apparition sur la scène des organisateurs de DefCon, qui félicitent l'orateur et son épouse Linda, qui sont présents à la conférence pour la première fois, à l'occasion du onzième anniversaire de mariage. Robert les remercie pour les félicitations et continue la présentation.
Le rayonnement cosmique est un facteur extrêmement rare affectant l'accrochage des bits, mais la surchauffe est une cause très courante d'erreurs de mémoire. J'ai remarqué que les smartphones sont particulièrement vulnérables en raison des conditions de fonctionnement extrêmes auxquelles ils sont exposés. La surchauffe de la batterie du smartphone est un phénomène assez courant. La plupart des autres appareils ont un refroidissement, mais même ils parviennent à créer des conditions de fonctionnement difficiles.
Il n'y a pas si longtemps, Google a publié des informations sur le travail de ses centres de données. L'une des choses intéressantes que j'ai apprises était le message selon lequel, pour économiser de l'énergie, ils exploitent leurs centres de données dans des conditions que la plupart d'entre nous jugeraient déraisonnables. Si les centres de données typiques fonctionnent à une température maximale de 60 à 70 degrés Fahrenheit (15 à 20 ° C), les experts Google recommandent aux entreprises d'exploiter les centres de données à une température d'au moins 80 degrés (27 ° C) et un centre de données belge Google. exploité ses serveurs à une température de 95 degrés (35 ° C).
Légende: "J'ai entendu dire que cela nous faisait économiser de l'argent."
Intel et Microsoft affirment que leurs serveurs se comportent bien à des températures élevées, et Dell garantit que leurs serveurs fonctionneront à 115 degrés Fahrenheit (46 ° C). Je pense que c'est une mauvaise idée, car la température est le principal facteur assurant un fonctionnement stable de la mémoire, et les centres de données de Google fonctionnent à des températures de "feu".
J'ai commencé à étudier les avantages que cela pouvait apporter et les domaines les plus vulnérables au squattage de bits, c'est-à-dire que j'ai essayé de trouver les noms les plus fréquemment demandés pour augmenter la probabilité de rencontrer de telles erreurs. J'ai commencé à collecter les journaux DNS des grandes entreprises pour trouver les noms de domaine les plus courants et j'ai découvert que le nom le plus demandé était gstatic.com. Il s'agit de l'un des domaines que Google sert à fournir des informations statiques telles que les fichiers CSS, les images, JavaScript et XML.
J'ai écrit un script pour identifier d'éventuels «bouleversements» de bits dans ce nom de domaine gstatic.com, et j'ai obtenu une liste de toutes les variantes de ce nom au montant de 34 pièces. Cinq d'entre eux ont été utilisés à des fins légales, les 29 restants étaient disponibles, alors je les ai tous achetés.
J'ai immédiatement atteint la cible. Quelqu'un recherchait des images sur Google et le contenu de la demande lui a été retourné d'une manière ou d'une autre endommagé, car son navigateur m'a demandé de servir l'une des images de la demande. Je vois leur adresse IP, le nom déformé qu'ils ont demandé, la ressource qu'ils ont essayé de récupérer en utilisant cette image, la page liée à ce contenu et le client qui a été utilisé comme navigateur pour envoyer cette demande.
Sur la page, vous pouvez voir un artefact intéressant sous la forme d'une demande pour un nom spécifique Trisha Jones.
De plus, le nombre de demandes a augmenté, plus de noms déformés sont apparus, plus de demandes d'images et plus de liens vers la demande d'origine, à la suite de quoi j'ai collecté plus de 50000 demandes uniques, ce qui s'est avéré être un phénomène courant.
La diapositive montre une demande d'une image "photographiée" de l'actrice Selena Gomez, qui fait rire dans la salle.
Il arrive donc parfois que le battement accroupi arrive juste au bon moment pour répondre à l'une de vos demandes, et si cela ne se produit pas trop souvent, vous n'avez pas à vous inquiéter. Mais parfois, cela se produit au moment même où il y a une sauvegarde sur le disque dur, ce qui est déjà plus intéressant. Il est probable que le bit squatting se produise dans des conditions normales de fonctionnement de la mémoire, mais il est très probable que cela se produise principalement dans les centres de données avec une température de 95 degrés.
Maintenant, mes journaux sont remplis de bruit, je reçois chaque jour des demandes déformées en quantité telle que je ne peux pas les afficher manuellement.
Par conséquent, j'écris des scripts pour essayer de trouver les mêmes modèles de requête, et le plus grand que j'ai obtenu était beaucoup de requêtes de la même image pour le même nom de domaine déformé, et elles provenaient toutes de téléphones mobiles. J'ai reçu ces demandes toutes les quelques secondes, car tous ces téléphones ont essayé d'utiliser la page de recherche du site Web de Google et m'ont demandé de leur fournir une petite image du logo de la page d'origine.
J'ai trouvé un serveur Web de l'ensemble du cloud Google qui diffusait du contenu et déformait constamment le nom de domaine, pointant vers l'un de mes serveurs, où le logo portant ce nom se trouvait par accident, et les clients l'ont pris.
La diapositive montre comment le logo de la page de recherche Google sur l'écran d'un appareil mobile est remplacé par le logo Occupy, ce qui provoque un rire apprécié dans la salle.Pendant deux ans, des centaines de milliers de demandes pour ce logo sont arrivées sur ce serveur avec un nom DNS déformé, au lieu de celui que Google prévoyait d'utiliser. Puis un jour, ils se sont arrêtés, car Google a refusé de modifier le contenu des sites mobiles, et cette commande a été annulée.
J'ai donc continué à étudier les modèles de requête et essayé de trouver d'autres modèles. L'un d'eux est apparu régulièrement et a eu lieu de manière naturelle en «retournant un peu» la mémoire, et non pas à la suite d'une erreur de squattage de bits enregistrée.
J'ai reçu les demandes indiquées sur la diapositive suivante avec une fréquence d'une par heure. Ils ne semblaient pas familiers, ils utilisaient tous le client Google Feedfetcher, ils provenaient tous d'appareils sur le même réseau et toutes les demandes étaient liées à des fichiers XML. J'ai donc fouillé un peu et j'ai trouvé que Feedfetcher était le mécanisme que Google utilise pour capturer le contenu mis à jour pour iGoogle, et les adresses IP source étaient situées en Belgique.
Ces demandes concernent les propres serveurs de Google, qui sont utilisés pour recevoir du contenu mis à jour pour divers widgets qui personnalisent la page d'accueil iGoogle, un portail Internet personnel.
Chaque widget est un fichier XML qui définit le contenu, et Google m'a demandé de fournir ce contenu à mes serveurs de présentation (applaudissements et rires du public).
Par conséquent, je pensais que si Google voulait accidentellement du contenu de moi qui pourrait fournir à ses utilisateurs, il le recevrait. J'ai pris les fichiers XML sur lesquels Google m'a posé des questions et les ai divisés en parties. Comme vous pouvez le voir, il y a deux sections: un en-tête qui décrit le module et un bloc C de données emballées dans le code HTML CSS et JavaScript qui composent le widget.
J'ai donc juste changé le lien vers l'image d'arrière-plan, changé l'adresse de gstatic.com en grtatic.com, et laissé le reste inchangé, mis les fichiers XML dans la ligne d'où Feedfetcher les obtient, et j'ai attendu un peu.
Presque immédiatement après cela, Feedfetcher m'a demandé des fichiers XML, après quoi j'ai immédiatement commencé à recevoir des demandes de nombreuses adresses IP Google pour cette image d'arrière-plan.
Par conséquent, j'ai supprimé les fichiers XML que j'ai modifiés et j'ai attendu que les demandes s'arrêtent, mais pendant 35 jours consécutifs, 61 appareils m'ont posé des questions sur cette image chaque jour. Et plus intéressant encore, chacun de ces appareils était un client Virgin Media au Royaume-Uni.
Ce fichier Google XML a donc servi 61 personnes et au cours de l'année écoulée, 500 adresses IP Feedfetcher uniques m'ont demandé de fournir ces modules 15 000 fois. Je pouvais donc offrir à mes utilisateurs quelque chose de plus dangereux que de simplement remplacer l'image d'arrière-plan.
Voici quelques astuces supplémentaires que vous pouvez effectuer avec Google. Si vous ne le savez pas, Postini est le service de messagerie électronique, de sécurité Web et d’archivage des courriers électroniques de Google récent.
Ce service vous permet de changer votre DNS pour indiquer votre enregistrement MX dans leur domaine et faire votre domaine en changeant les 4 caractères MX avant psmtp.com. La chose la plus intéressante ici est que le domaine est si court que vous pouvez facilement enregistrer toutes les versions possibles du nom avec les bits «inversés». Un autre point intéressant est que de nombreuses entreprises indiquent leurs enregistrements MX pour un seul domaine et personne ne pensait que c'était une mauvaise idée.
Par conséquent, je n'ai enregistré que trois bits accroupis possibles pour ce domaine, et l'emploi de psmtp.com s'est avéré si important que les 4 diapositives suivantes montrent les demandes que j'ai reçues en seulement un mois.
Donc, si vous utilisez le courrier Postini, votre demande parviendra à un moment donné à mon serveur. Je ne pense pas que quiconque puisse dire que Google n'est pas sérieux au sujet de la sécurité Internet. Mais si quelqu'un se demandait à quels problèmes une surchauffe causant des erreurs de mémoire pouvait conduire, il pourrait se poser la question de considérer la possibilité d'une compensation pour de telles choses. Par conséquent, ne laissez pas vos noms de domaine être si courts, car cela affecte négativement votre entreprise, comme Postini, surtout si votre domaine est populaire.
Je recommande fortement aux gens d'appliquer une politique interne de gestion des noms de domaine qui leur permet de corriger les erreurs de distorsion des noms et de comprendre clairement comment de telles choses peuvent vous affecter. Si vous avez gstatic.com et un centre de données fonctionnant à une température de 95 degrés, vous voulez probablement vous assurer que toute erreur de squattage de bits ne permettra pas au client d'accéder à un réseau externe malveillant.
Soit dit en passant, parmi tous les domaines sur lesquels j'ai enquêté, la seule entreprise à avoir enregistré toutes les distorsions possibles de mon nom était Yahoo.
Dans la prochaine partie de la présentation, je vais démontrer le comportement du DNS, que beaucoup de gens ne semblent pas comprendre complètement.
Honnêtement, Microsoft a fait un très mauvais travail de documentation, d'autant plus que le comportement du DNS change souvent. Cela conduit à une mauvaise compréhension de ce qui se passe chez les utilisateurs finaux, d'autant plus qu'un tel comportement est souvent contradictoire.
Par conséquent, je commencerai par le fait que tout le monde doit comprendre comment les périphériques doivent se comporter lors de la requête DNS et à quoi s'attendre d'eux. Ensuite, je vais expliquer comment ce comportement devient imprévisible lors de l'utilisation des chemins de recherche de suffixe DNS, comment la documentation insuffisante affecte tout cela, et je terminerai par un bref aperçu des leçons qui peuvent être tirées de tout cela. Mais d'abord, je vais montrer à quel point il peut être dangereux pour un utilisateur final de mal comprendre ce qui se passe avec le DNS.
Ainsi, après avoir tapé
www.google.com dans la barre d'adresse de votre navigateur, votre ordinateur envoie une demande au serveur DNS local, et la tâche de trouver la chose dont vous avez besoin, de renvoyer la demande et de répondre lui est désormais attribuée. Le serveur local appelle le serveur racine pour accéder au serveur .com et le serveur racine l'envoie au serveur .com. Il vérifie si le serveur local est autorisé à recevoir des demandes sur google.com et l'envoie au serveur ns.google.com. Enfin, le serveur local reçoit une réponse avec l'adresse IP de la ressource dont vous avez besoin et vous l'envoie.
C'est le comportement DNS normal que tout le monde attend de lui. Tout le monde pense qu'il suffit d'envoyer simplement une demande de l'appareil à votre serveur DNS local pour qu'il fasse tout le travail, puis d'obtenir une réponse à votre demande. Mais tout le monde n'imagine pas que ce processus comporte de nombreuses étapes importantes.
Par exemple, votre appareil tente de trouver la réponse sur
www.google.com , mais l'ensemble du processus, qui nous a pris jusqu'à 8 diapositives, ne se produira que si vous saisissez exactement une telle adresse dans la barre de requête du navigateur -
www.google .com . Il s'agit du nom de domaine complet associé au DNS racine. Beaucoup de gens pensent que le nom de domaine complet se termine par un point, ce qui n'est pas vrai. La présence d'un point à la fin du nom complet est toujours supposée et, à cause de cela, des problèmes se produisent. Essayons d'imprimer 4 variantes du nom:
www.google.comgoogle.com
www
www.google.comdont chacun se comporte différemment en ce qui concerne le comportement DNS. Tout cela est personnalisable, mais généralement personne ne le fait.
Voyons ce qui se passe réellement dans de telles situations. Il existe plusieurs facteurs qui influencent la prise de décision du client avant de décider d'envoyer une requête DNS. Deux d'entre eux sont les chemins de recherche de suffixe et la dévolution DNS.
Les deux ont de nombreux paramètres personnalisables qui affectent leur comportement et se comportent différemment dans différentes versions de Windows et dans différents service packs.
C'est ainsi que la plupart des gens utiliseront le suffixe du chemin de recherche. Si votre entreprise s'appelle foo et que vous possédez le domaine foo.com et que le nom de l'annuaire actif est ad.foo.com, vous pouvez utiliser le suffixe des chemins de recherche ad.foo.com ou foo.com et le "pousser" dans la partie cliente de l'assemblage système ou dans stratégie de groupe.
Si l'un de vos clients essaie de résoudre le nom abrégé www, le comportement par défaut de Windows XP sera le suivant. D'abord, elle enverra une requête DNS le long du chemin
www.ad.foo.com , puis le long du chemin
www.foo.com et à la fin une requête NetBIOS suivra - juste www.
www.phx ,
www.phx , ,
www.phx.ad.foo.com ,
www.phx.foo.com . 15 , NetBIOS,
www.phx .
Windows, XP sp.3, DNS —
www.phx NetBIOS —
www.phx , , .
, , , , , . , , Microsoft DNS.
XP , Microsoft XP, DNS Windows DNS . , www, Windows , , , DHCP Active Directory.
www.phx.ad.foo.com , ,
www.ad.foo.com ,
www.foo.com , ,
www.com .
18:30
DEFCON 21. DNS . 2e partie, . Aimez-vous nos articles? ? ,
30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? ( RAID1 RAID10, 24 40GB DDR4).
VPS (KVM) E5-2650 v4 (6 cœurs) 10 Go DDR4 240 Go SSD 1 Gbit / s jusqu'en décembre gratuitement en payant pour une période de six mois, vous pouvez commander
ici .
Dell R730xd 2 fois moins cher?Nous avons seulement 2 x Intel Dodeca-Core Xeon E5-2650v4 128 Go DDR4 6x480 Go SSD 1 Gbps 100 TV à partir de 249 $ aux Pays-Bas et aux États-Unis! Pour en savoir plus sur la création d'un bâtiment d'infrastructure. classe utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?