Le DNS cible de toutes les attaques?

Le DNS (domain name system – voir l’article de Wikipédia) est ce service qui permet à votre ordinateur de faire le lien entre un nom de serveur et une adresse IP. Il permet aussi aujourd’hui de diffuser de plus en plus d’informations contribuant à la sécurité des domaines sur Internet. L’actualité de ce début d’année 2012 offre de nouvelles occasions d’en parler, abordons deux d’entre elles:

  • DNS Changer, un logiciel malveillant que l’on croyait maîtrisé, fait encore et toujours parler de lui et pourrait très bien empêcher certains d’entre nous de naviguer d’ici quelques jours ;
  • Une nouvelle vulnérabilité dite des "domaines fantômes" (Ghost domains) a été révélée récemment par des chercheurs, qui pourrait permettre à des domaines abandonnés ou fermés de continuer à survivre dans certaines portions de l’Internet et permettre des abus.

DNS Changer

Le 9 novembre 2011, le ministère de la justice américain annonce (voir l’histoire telle que la raconte le FBI) la réussite de son opération Ghost Click. Ainsi six résidents Estoniens ont été interpellés pour avoir géré une opération criminelle qui leur permettait d’escroquer des millions d’internautes et un certain nombre de sociétés gérant des campagnes publicitaires.

Une variante du cheval de Troie Zlob avait été créée, apparemment en 2006 ou un peu avant, pour modifier de façon massive la configuration DNS des victimes. La première version de ce cheval de Troie, appelé DNS Changer par la plupart des sociétés antivirus, modifiait la configuration des systèmes d’exploitation pour que la résolution des noms de domaine ne soit plus réalisée par les serveurs de noms de domaine du fournisseur d’accès de la victime, mais par une batterie de serveurs gérée par le groupe criminel. Une version ultérieure permettait même la modification de la configuration de certains routeurs locaux (les boîtiers que l’on installe chez soi pour permettre l’accès à plusieurs ordinateurs au travers de la même connexion Internet).

Les serveurs de noms de domaine contrôlés par le groupe criminel étaient sur les adresses IP suivantes:

  • 85.255.112.0 à 85.255.127.255
  • 67.210.0.0 à 67.210.15.255
  • 93.188.160.0 à 93.188.167.255
  • 77.67.83.0 à 77.67.83.255
  • 213.109.64.0 à 213.109.79.255
  • 64.28.176.0 à 64.28.191.255

Ainsi, le trafic légitime des utilisateurs était détourné vers des sites commerciaux associés à ces criminels, conduisant par exemple les victimes à effectuer des achats sur des sites illégitimes, ou bien l’ordinateur affichait des campagnes publicitaires non prévues. Cela leur permettait aussi d’empêcher les mises à jour de logiciels antivirus.

Le groupe criminel était à la tête d’une société qui avait pignon sur rue, Rove Digital (voir la synthèse réalisée par Trend Micro), elle-même ayant plusieurs filiales (Esthost, Estdomains, Cernel, UkrTelegroup,…) – j’ai déjà évoqué Estdomains dans un article précédent sur les hébergeurs malhonnêtes. Comme on peut le lire dans l’article de Trend Micro, leurs activités ne se limitaient pas aux DNS malveillants (commercialisation de faux antivirus notamment).

Des serveurs DNS remplacés par des serveurs sûrs, mais plus pour longtemps

Grâce à une décision judiciaire et l’assistance de sociétés spécialisées dans la sécurité informatique (regroupées dans le groupe de travail DCWG), l’ensemble de ces serveurs de noms de domaine ont été remplacés par des serveurs légitimes (gérés par ISC). L’avantage d’une telle solution est qu’elle n’a pas soudainement coupé des millions de personnes d’un accès normal à Internet. L’inconvénient est qu’elles ne se sont pas forcément rendues compte qu’elles étaient concernées.

Cette solution est à comparer à celle qu’ont employée les autorités néerlandaises lors du démantèlement du botnet Bredolab. Dans ce dernier cas, les victimes étaient redirigées, grâce à l’utilisation de fonctions intégrées dans le logiciel malveillant, vers une page Web les avertissant de la contamination:

Message de la police néerlandaise pour avertir les victimes du botnet Bredolab

Mais, dans les prochaines semaines, vraisemblablement le 8 mars, les serveurs gérés par le DCWG ne fonctionneront plus et les ordinateurs qui sont encore contaminés par ce logiciel malveillant ou qui ne sont pas complètement reconfigurés ne pourront plus accéder normalement à Internet, les serveurs DNS qu’ils utilisent n’étant plus accessibles. Il est donc important de vérifier qu’on n’est pas concerné.

Pour vous aider à faire cela, des serveurs Web ont été mis en place dans différentes parties du monde qui vous permettent de vérifier si vous pouvez être concerné. Ainsi le CERT-LEXSI a mis en place la semaine dernière un serveur http://www.dns-ok.fr/ qui doit vous afficher l’une des pages ci-dessous:

Tout va bien

Rien ne va plus

Si vous voulez aller plus loin et vérifier plus avant votre configuration, vous pouvez consulter ce document en anglais diffusé par le FBI (voir le PDF joint) et qui donne un peu plus de précisions sur les vérifications à effectuer. En pratique, il s’agit de vérifier que la configuration DNS de vos ordinateurs ou routeurs locaux ne pointe pas vers l’une des adresses IP listées plus haut dans l’article.

Vous trouverez d’autres ressources ici: http://www.dcwg.org/checkup.html et notamment une liste de serveurs de diagnostic par le Web ici: http://dns-ok.de/, http://dns-ok.be/, http://dns-ok.fi/, http://dns-ok.ax/, …

Que faire si vous pensez être concernés?

Les conseils sont ceux que l’on donne habituellement lors de la découverte d’une contamination virale informatique: sauvegardez vos données les plus sensibles, mettez à jour votre logiciel antivirus (après avoir réglé correctement votre configuration DNS) et lancez une procédure décontamination au démarrage si elle est disponible dans votre logiciel et n’oubliez pas de faire le ménage sur tous vos supports amovibles (clés USB) qui sont connus pour avoir été utilisés pour la diffusion de cette catégorie de logiciels malveillants. Vous trouverez d’autres conseils sur le blog Malekal.

Est-ce qu’il s’agissait d’un botnet ?

Oui. Il ne s’agit pas de la structure classique d’un botnet tel qu’on l’imagine habituellement (logiciel malveillant qui reçoit des commandes sur un serveur IRC ou en se connectant sur un serveur Web), mais il y a un bien une infrastructure de commande (les centaines de serveurs DNS de Rove Digital/Esthost), un langage de communication particulier au travers de ces serveurs DNS, et une prise de contrôle assez avancée du comportement de la machine des victimes. Cette organisation malveillante rentre donc bien dans la définition que nous donnons d’un botnet sur le wiki Botnets.fr.

C’est exactement ce que dit Trend Micro dans son article sur ce dossier. J’avais évoqué d’autres modes de commande originaux pour des botnets sur ce blog: des images ou des Google groups.

Les domaines fantômes

La vulnérabilité dite des ghost domains n’a aucun rapport avec l’opération Ghost Click que nous venons d’évoquer, mais elle concerne bien une faille dans les serveurs DNS, même si elle n’a pas d’impact immédiat pour la plupart des lecteurs de ce blog.

Des chercheurs chinois et américains (Jian Jiang, Jinjin Liang, Kang Li, Jun Li, Haixin Duan et Jianping Wu) ont ainsi mis en évidence, dans un article intitulé Ghost Domain Names: Revoked Yet Still Resolvable (voir le PDF), qu’il était possible de maintenir, dans la mémoire cache d’une grosse partie des serveurs DNS répartis sur la planète, la résolution d’un nom de domaine qui n’est normalement plus actif, longtemps après qu’il ait été révoqué.

En théorie, cela permet par exemple de maintenir en activité un système de commande et de contrôle d’un botnet longtemps après qu’il ait été mis hors service.

Principe de la vulnérabilité

Le principe décrit par les auteurs suppose d’interroger l’ensemble des serveurs DNS dans lesquels on cherche à maintenir l’information vivante, avec des requêtes qui provoquent une mise à jour. Pour ce faire:

  • si le nom de domaine que l’on cherche à protéger est fantome.com
  • que le serveur de nom de domaine principal de ce domaine est dns.fantome.com (pointant vers l’adresse IP x.y.z.t
  • on modifie le nom du serveur pour un autre, soit par exemple test.fantome.com (pointant toujours vers x.y.z.t)
  • et on interroge ensuite chacun des serveurs DNS attaqués pour qu’ils identifient test.fantome.com
  • comme ils ne connaissent pas test.fantome.com mais savent déjà résoudre les adresses du domaine fantome.com, ils se connectent sur x.y.z.t et se rendent alors compte qu’il a changé de nom et mettent à jour le serveur de nom de domaine pour fantome.com avec la valeur test.fantome.com et réinitialisent la valeur du TTL (time to live, voir Wikipédia), qui constitue en quelque sorte la date d’expiration de l’information dans le cache local du serveur DNS.

Ainsi, pour tous les serveurs qui sont vulnérables à cette attaque, si on les contacte au moins une fois par jour (ou juste un peu moins qu’un jour, si le TTL est configuré à 86400 secondes) pour provoquer une mise à jour, ils continueront de conserver l’information erronée, sans jamais vérifier auprès des registres de noms de domaine de plus haut niveau (voir Wikipédia).

Quel est le risque réel

Les chercheurs soulignent dans leur article qu’ils ont pu mesurer qu’une grande majorité des serveurs DNS sont concernés aujourd’hui par cette vulnérabilité. Et s’ils n’ont pas identifié une utilisation passée, ils ont pu montrer qu’elle fonctionnerait. L’un des scénarios qu’ils décrivent consisterait à cibler l’attaque contre des serveurs de noms de domaine d’un réseau donné. Des mises à jour sont en cours de déploiement dans différentes versions des serveurs DNS. Selon les spécialistes interrogés (voir l’article du Register), le risque n’est pas très grand étant donné que la vulnérabilité permet uniquement de maintenir en fonctionnement des domaines malicieux après leur disparition et non pas d’injecter des informations erronées sur des domaines légitimes existants (voilà quelques années, Dan Kaminsky mettait en lumière une faille beaucoup plus importante, en voir la synthèse chez Stéphane Bortzmeyer).

Conclusion

Internet fonctionne sur un ensemble de fonctions essentielles dont les serveurs DNS ou le protocole de routage BGP. Bien qu’ils soient relativement simples au départ, la complexité de l’Internet, la nécessité de diffuser et propager l’information rapidement les rend particulièrement vulnérables. Il est donc important de suivre leur sécurité du cœur de l’Internet jusque dans la mémoire de votre ordinateur.

Pour aller plus loin

J’ai déjà parlé du DNS dans plusieurs articles que vous pouvez retrouver ici:

D’autres articles sur les domaines fantômes:

Atelier de l’AFNIC sur les noms de domaines internationalisés

Le 10 février 2011 à Paris, l’AFNIC – Association française pour le nommage Internet en coopération, organisait un atelier d’étude sur les noms de domaines internationalisés. Ce fut l’occasion de faire le point sur les projets de l’AFNIC dans ce domaine et les différents enjeux que cela ne manquera pas de soulever pour l’ensemble des acteurs.

L’atelier a duré près de 4 heures et s’est déroulé en trois parties: d’abord une introduction sur le sujet par Stéphane Bortzmeyer, suivie de deux tables rondes. La première table ronde a permis d’évaluer les attentes de la communauté des utilisateurs, tandis que la seconde portait sur les aspects opérationnels du lancement de cette nouvelle capacité des noms de domaine en .fr.

Les noms de domaine internationalisés

Stéphane Bortzmeyer (@bortzmeyer, blog) a publié le diaporama de son introduction. Ce qu’il faut retenir selon moi est qu’on est en train de déployer progressivement (depuis la première moitié des années 2000), dans les infrastructures de gestion des noms de domaines, la possibilité d’utiliser des caractères autres que les lettres de l’alphabet latin de a à z et les chiffres de 0 à 9. Ainsi, on voit apparaître des sinogrammes, des caractères cyrilliques ou du sanscrit dans les URL:

  • http://президент.рф/ (site du président russe, on notera au passage le domaine de tête internationalisé aussi "рф" pour "fédération de russie" et en complément du ".ru" classique)
  • http://müller.de/ (93 caractères supplémentaires ont été rajoutés pour le domaine de tête .de de l’Allemagne, y compris le "ß")
  • ou bien en arabe http://وزارة-الأتصالات.مصر/ ou encore en coréen http://휴대폰.com/

Le domaine de tête européen ".eu" a ouvert la création de noms de domaines internationalisés dans les langues des 27 pays membres de l’Union Européenne en décembre 2009. Ainsi http://www.crimenumérique.eu/ redirige-t-il vers le présent blog :-)

Sur le plan technique, et normalement de façon transparente pour l’utilisateur, les différentes chaînes de caractères ne sont pas directement implémentées dans le protocole DNS mais sont transformées à nouveau en chaînes de caractères ASCII. Ainsi, le RFC 3490 prévoit un encodage "compatible ASCII" ou ACE des chaînes de caractères Unicode (voir l’article de Wikipédia sur le punycode et le RFC 3492). Un préfixe a été choisi en 2003 pour identifier ces noms de domaines internationalisés, il s’agit de "xn--". Ainsi http://www.crimenumérique.eu est-il représenté par http://www.xn--crimenumrique-ihb.eu.

Résumé de l’atelier

Voici quelques points clés que j’ai retenus de cet atelier:

  • L’AFNIC envisage de lancer les noms de domaines internationalisés pour le domaine de tête ".fr" d’ici la fin de l’année 2011;
  • La décision n’est pas encore prise sur les chaînes de caractères qui seront autorisées. Le débat a permis d’entendre plusieurs arguments pour ou contre la prise en charge – en plus des caractères diacritiques essentiels de la langue françaises, ceux des langues régionales, des langues parlées dans les pays européens voisins ou ceux des langues parlées en France de façon plus générale (comme l’arabe dialectal ou le chinois par exemple). Mon analyse personnelle est qu’il est vraisemblable que dans un premier temps l’ouverture se fera d’abord sur les caractères accentués classiques du français.
  • Il semble se dégager un consensus – en tous cas au cours de cet atelier – pour un lancement le plus simple possible, donc éventuellement sans période de "lever de soleil" et en tous cas de prendre au moins en compte les titulaires préalables des domaines "non accentués" pour l’attribution des nouveaux "avec accents". Mais la question n’est pas aussi simple qu’il y paraît, les accents apportant des nuances de sens parfois importantes (voir les exemples dans la présentation de Stéphane Bortzmeyer).
  • Les préoccupations des détenteurs de marques sont importantes, et si évidemment cette ouverture crée de nouvelles opportunités en termes de communication, il leur paraîtrait judicieux de ne pas faire débuter toutes les réformes en même temps (l’AFNIC confirmait aussi l’ouverture à venir, au profit des entreprises européennes et des personnes demeurant en Europe, du domaine de tête ".fr").
  • Deux notes techniques au passage: il restera des subtilités de la langue française qui ne pourront pas être prises en compte telles que certains caractères spéciaux comme les apostrophes ou les majuscules qui donnent parfois un sens différents aux mots en français (différence entre État et état), et si les noms de domaines prennent en compte les polices de caractères avancées, il n’existe pas encore de standard stabilisé pour la gestion de ces caractères dans la partie locale (avant l'"@") des adresses de courrier électronique.
  • Enfin, Cédric Manara (@cedricmanara, blog) met à disposition des internautes la présentation qu’il a faite et qui comporte une étude des litiges traités par l’UDRP sur des noms de domaines internationalisés.

Enjeux pour les enquêteurs

Les enjeux pour les enquêteurs (mais aussi évidemment, les experts judiciaires, les magistrats ou toutes les personnes qui réalisent des investigations numériques) sont multiples:

  • Bien entendu, il s’agit d’abord de se tenir informé de ces évolutions qui seront de plus en plus rencontrées (on peut aussi citer l’arrivée des adresses IP v6).
  • Ensuite, comme tout un chacun, ils seront confrontés à la non-adaptation des outils du quotidien (navigateurs Internet, logiciels de messagerie) ou des outils spécialisés (de nombreuses interfaces Web de whois ne sont pas encore correctement paramétrées).
  • Enfin, et surtout, cette évolution multiplie les possibilités d’erreurs, notamment lors de la retranscription des adresses. Ainsi, les témoignages des victimes, les copies d’écran, les fax etc. ne permettront pas toujours de distinguer plusieurs adresses semblables. En effet, même si les adeptes du phishing n’exploitent pas réellement les attaques par homographie (mots qui se ressemblent), le risque de confusions est réel. Même si cela est possible aujourd’hui lorsqu’on retranscrit la lettre "l" minuscule plutôt que le chiffre "1", les variations explosent. Et bien évidemment ce sera plus complexe pour un enquêteur français de recopier des idéogrammes chinois que pour un enquêteur chinois. La recommandation principale sera de favoriser soit les échanges électroniques (que ce soit avec les victimes ou avec les opérateurs auxquels on adresse questions ou réquisitions) et l’utilisation de la conversion en caractères ASCII (les chaînes commençant par "xn--").

En conclusion, je tiens à remercier l’AFNIC et les participants aux tables rondes pour cet atelier particulièrement instructif, qui m’a permis, même si je connaissais ce problème, d’avoir l’occasion d’y consacrer plusieurs heures de réflexion et d’échanges. Enfin, je ne peux que conseiller à mes lecteurs de continuer de se tenir informés de ces différentes évolutions qu’ils soient de simples utilisateurs et titulaires de noms de domaines ou des personnes chargées de missions d’investigation numérique. L’AFNIC devrait continuer la démarche de dialogue et d’information entreprise dans les mois à venir, avant le lancement effectif de cette nouvelle offre, mais n’oublions pas que c’est déjà aujourd’hui une réalité dans de nombreux domaines de tête et en particulier en Europe…

26C3 – Conférence du CCC à Berlin (3)

Troisième jour de cette conférence et la sélection que je vous en propose.

Mardi

Using OpenBSC for fuzzing of GSM handsets

Des noms de domaines enregistrés via proxy ou un service d’anonymisation

tldL’ICANN publiait le 1er octobre dernier un projet de rapport sur les noms de domaines enregistrés au travers d’un service d’intermédiation ou d’anonymisation. C’est un des sujets qui préoccupe souvent les enquêteurs et que j’ai d’ailleurs évoqué dans l’ouvrage que j’ai écrit avec Guillaume Desgens-Pasanau [1].

Dans l’étude présentée par l’ICANN – avec l’aide du NORC (National opinion research centre de l’Université de Chicago), un échantillon de 2400 noms de domaines a été sélectionné parmi les 5 plus grands TLDs (.com, .net, .org, .biz, .info). Il en ressort que 15 à 25 % des noms de domaine observés ont été enregistrés grâce un service permettant d’anonymiser les informations.

Selon les règles de l’ICANN, les bureaux d’enregistrement doivent recueillir et publier sur les serveurs Whois:

  • le nom de domaine,
  • les serveurs DNS associés,
  • les dates de création et d’expiration,
  • les informations de contact du propriétaire, techniques et administratives.

Deux types de services sont offerts:

  • un service de garantie de la vie privée (ou d’anonymisation, privacy en anglais) en masquant certaines informations de contact et en permettant l’utilisation d’une adresse de courrier électronique créée spécialement par le bureau d’enregistrement (il s’agit souvent d’une option payante offerte par le bureau d’enregistrement),
  • un service d’intermédiation (acquisition par proxy), où c’est un intermédiaire qui acquière le nom de domaine et en revend l’usage à l’utilisateur final. Ce sont alors les informations de contact de cet intermédiaire qui apparaissent sur les serveurs proxy.

Les résultats

Les résultats préliminaires sont intéressants. Ainsi, sur la base d’une échelle de 0 (improbable) à 3 (certain), l’utilisation d’un service d’anomyisation ou d’intermédiation est évaluée de la façon suivante:

  • (3) + (2) + (1) = 24,6 % de l’échantillon
  • (3) + (2) = 22,4 % de l’échantillon
  • (3) = 14,6% de l’échantillon

Dans ces cas-là, 85% semblent utiliser un service d’intermédiation et 15% un service d’anonymisation.

Des vérifications supplémentaires sont programmées par l’ICANN pour affiner ces résultats.

Conséquences

Il est particulièrement frustrant pour un enquêteur de consulter le whois d’un nom de domaine en cours d’investigation et de découvrir qu’aucune information n’est réellement utilisable. Il y a deux types de démarches qui sont rencontrées: la souci légitime de préserver sa vie privée et celui, plus questionnable mais finalement compréhensible, d’empêcher l’identification lorsqu’on commet des infractions grâce à l’utilisation du nom de domaine.

Si l’on cumule cela avec le fait que ces informations sont le plus souvent déclaratives et fausses ou que de toutes façons il sera impossible pour l’enquêteur d’obtenir une quelconque information complémentaire auprès du bureau d’enregistrement (parce qu’il ne répondra pas à la  requête de l’enquêteur ou bien que les autorités du pays concerné ne coopéreront pas), on comprend la difficulté du problème.

En France, la loi pour la confiance dans l’économie numérique et les règles mises en place par l’AFNIC pour les domaines qu’elle gère permettent d’avoir de biens meilleurs retours, tout en préservant si nécessaire la vie privée, mais ce n’est pas le cas dans l’ensemble des régions du monde. Il serait d’ailleurs intéressant de faire une étude semblable montrant le taux d’utilisation des services de proxy ou d’anonymisation dans les domaines rencontrés dans les enquêtes judiciaires… Une étude similaire parmi les domaines de premier niveau européens et en particulier le ".eu" serait tout aussi intéressante.

En tous cas, c’est déjà une bonne chose que l’ICANN commence à étudier ce phénomène, il sera plus intéressant de savoir si des solutions seront proposées pour permettre aux enquêtes judiciaires de se dérouler.

[1] L’identité à l’ère numérique, G. Desgens-Pasanau & E. Freyssinet, Dalloz, collection Présaje, ISBN 978-2247080618

Suivre

Recevez les nouvelles publications par mail.

Rejoignez 128 autres abonnés

%d bloggers like this: