Sécurité des noms de domaine, l'exemple des cryptomonnaies

Étude de trois détournements de noms de domaine dans les six derniers mois, dans le monde des cryptomonnaies

Les cryptomonnaies sont certainement un sujet chaud aujourd'hui, notamment en raison de la hausse spectaculaire du Bitcoin en décembre 2017. Mais il n'y a pas que les gens honnêtes qui ont remarqué cette hausse. Des délinquants veulent aussi en profiter. Les techniques qu'ils utilisent pour attaquer les portefeuilles et voler de l'argent sont variables mais nous nous intéresserons ici uniquement aux détournements de noms de domaine.

Il faut noter qu'une des difficultés de la cybersécurité est l'absence de faits bruts sur les attaques, et l'absence d'analyses indépendantes. On ne sait de l'attaque que des vagues résumés, faits à partir de données publlques, ce qui ne suffit pas toujours. Les rapports de telle ou telle entreprise sur la cybersécurité ne sont pas mieux informés, et peuvent être influencés par les intérêts de l'entreprise, par exemple parce qu'elle vend des produits de sécurité. Les articles dans les médias sont donc à prendre avec beaucoup de précautions.

Ici, outre les articles publiés, on s'appuiera surtout sur DNSDB. DNSDB est une base de «passive DNS». Cette technique consiste à instrumenter un résolveur DNS de façon à ce qu'il transmette les réponses DNS qu'il a reçu. Ces réponses sont alors stockées dans une base de données, qu'on peut interroger. Cela permet de « remonter dans le temps » et de voir quelles étaient les réponses du DNS à un moment donnée. Par exemple, ici, DNSDB affiche les adresses IP successives de la machine qui sert de serveur whois à l'AFNIC (toutes les heures sont en UTC) :

;; first seen: 2014-03-10 17:25:41 -0000
;;  last seen: 2014-03-24 08:09:24 -0000
matrix.nic.fr. IN AAAA 2001:67c:2218:2::4:55

;; first seen: 2014-03-24 08:12:12 -0000
;;  last seen: 2017-11-14 10:57:47 -0000
matrix.nic.fr. IN AAAA 2001:67c:2218:30::15

;; first seen: 2017-11-14 09:58:45 -0000
;;  last seen: 2017-11-14 12:23:10 -0000
matrix.nic.fr. IN AAAA 2001:67c:2218:e::51:35

;; first seen: 2017-11-14 11:26:09 -0000
;;  last seen: 2018-01-26 09:16:11 -0000
matrix.nic.fr. IN AAAA 2001:67c:2218:1b::51:99

On voit quatre adresses IP différentes utilisées au cours du temps. (DNSDB indique pour chacune la première et la dernière apparition, la première et la dernière fois où les résolveurs utilisés par DNSDB ont vu cette réponse.)

Voyons maintenant les trois cas de détournement promis, en commençant par le plus récent.. (Notez que rien n'indique que les trois attaques aient été faites par le même groupe.) Blackwallet était (ils semblent avoir fermé, suite au détournement) un service de «portefeuille», c'est à dire d'hébergement de comptes en cryptomonnaies, en l'occurrence des lumens, la monnaie du réseau Stellar. Son nom de domaine, blackwallet.co, a été détourné le 13 janvier 2018. (Cf. article de Bleeping Computer et article de Security Affairs, ainsi que l'avertissement sur Reddit). Voici quels étaient les serveurs de noms du domaine, avant le détournement :

;; first seen: 2017-07-04 23:10:47 -0000
;;  last seen: 2018-01-13 17:40:15 -0000
blackwallet.co. IN NS ns1087.ui-dns.de.
blackwallet.co. IN NS ns1039.ui-dns.biz.
blackwallet.co. IN NS ns1069.ui-dns.com.
blackwallet.co. IN NS ns1102.ui-dns.org.

 Et voici pendant le détournement :

;; first seen: 2018-01-13 18:11:31 -0000
;;  last seen: 2018-01-14 01:04:35 -0000
blackwallet.co. IN NS adi.ns.cloudflare.com.
blackwallet.co. IN NS anirban.ns.cloudflare.com.

Notez qu'il a fallu plusieurs heures pour corriger le problème. Après correction, on revoyait à nouveau les bons serveurs :

;; first seen: 2018-01-14 01:44:31 -0000
;;  last seen: 2018-01-20 11:46:34 -0000
blackwallet.co. IN NS ns1100.ui-dns.de.
blackwallet.co. IN NS ns1046.ui-dns.org.
blackwallet.co. IN NS ns1096.ui-dns.biz.
blackwallet.co. IN NS ns1099.ui-dns.com.

On note qu'aujourd'hui, les serveurs de noms de Cloudflare, utiisés pendant le détournement, servent toujours les mauvaises données, comme on le voit ici avec le client DNS de déboguage dig :

% dig @adi.ns.cloudflare.com NS blackwallet.co.
; <<>> DiG 9.10.3-P4-Debian <<>> @adi.ns.cloudflare.com NS blackwallet.co.
...
;; ANSWER SECTION:
blackwallet.co.        86400 IN NS adi.ns.cloudflare.com.
blackwallet.co.        86400 IN NS anirban.ns.cloudflare.com.

;; Query time: 13 msec
;; SERVER: 2400:cb00:2049:1::adf5:3a38#53(2400:cb00:2049:1::adf5:3a38)
;; WHEN: Fri Jan 26 13:51:52 CET 2018
;; MSG SIZE  rcvd: 100

Une fois les serveurs de noms changés, le délinquant pouvait à loisir rediriger les visiteurs vers la destination de son choix. En l'occurrence, il redirigeait vers un site Web où un code Javascript malveillant détournait les lumens (l'argent).

Le serveur Web utilisé tourne toujours, ce qui permet de vérifier que HTTPS ne protégeait pas. Un «authentique» certificat s'y trouvait, créé par l'Autorité de Certification (AC) Comodo, pour *.blackwallet.co. Le vrai certificat est fait par une autre AC, Symantec, et ne couvre que www.blackwallet.co. Une fois qu'on contrôle un domaine, obtenir un certificat est facile, et c'est pour cela que les certificats ne protègent guère.

Un peu avant Noël, un autre détournement avait frappé EtherDelta,une plate-forme d'échanges d'ethers, la monnaie de la chaîne de blocs Ethereum (cf. l'article de Bleeping Computer)  :

;; first seen in zone file: 2017-06-10 16:02:22 -0000
;;  last seen in zone file: 2017-12-20 17:02:21 -0000
etherdelta.com. IN NS tom.ns.cloudflare.com.
etherdelta.com. IN NS dorthy.ns.cloudflare.com.

;; first seen: 2017-12-20 18:28:33 -0000
;;  last seen: 2017-12-20 21:54:06 -0000
etherdelta.com. IN NS ns1.shockhosting.net.
etherdelta.com. IN NS ns2.shockhosting.net.

;; first seen: 2017-12-20 21:55:29 -0000
;;  last seen: 2017-12-21 02:11:42 -0000
etherdelta.com. IN NS ns1.byet.org.
etherdelta.com. IN NS ns2.byet.org.
etherdelta.com. IN NS ns3.byet.org.
etherdelta.com. IN NS ns4.byet.org.

;; first seen: 2017-12-21 22:18:22 -0000
;;  last seen: 2018-01-21 08:55:36 -0000
etherdelta.com. IN NS asa.ns.cloudflare.com.
etherdelta.com. IN NS owen.ns.cloudflare.com.
 

On voit que les serveurs légitimes étaient chez Cloudflare, ils ont été changés, d'abord pour ceux en shockhosting.net, puis pour ceux en byet.org, avant d'être rétablis à la bonne valeur.

Le dernier cas de détournement est celui de ClassicEtherWallet, portefeuille pour des ethers, en juin 2017. (Voyez l'avertissement publié sur Reddit. et l'article de Bleeping Computer) Les serveurs de noms sont passés de ceux, légitimes, de 1&1 à ceux de Cloudflare, puis rétablis , mais chez un autre hébergeur :

;; first seen in zone file: 2016-07-25 16:31:09 -0000
;;  last seen in zone file: 2017-06-29 16:02:31 -0000
classicetherwallet.com. IN NS ns-us.1and1-dns.de.
classicetherwallet.com. IN NS ns-us.1and1-dns.us.
classicetherwallet.com. IN NS ns-us.1and1-dns.com.
classicetherwallet.com. IN NS ns-us.1and1-dns.org.

;; first seen in zone file: 2017-06-30 16:02:31 -0000
;;  last seen in zone file: 2017-06-30 16:02:31 -0000
classicetherwallet.com. IN NS jeff.ns.cloudflare.com.
classicetherwallet.com. IN NS dolly.ns.cloudflare.com.

;; first seen: 2017-06-30 18:53:30 -0000
;;  last seen: 2018-01-21 09:24:32 -0000
classicetherwallet.com. IN NS ns1085.ui-dns.de.
classicetherwallet.com. IN NS ns1022.ui-dns.com.
classicetherwallet.com. IN NS ns1059.ui-dns.biz.
classicetherwallet.com. IN NS ns1087.ui-dns.org.
 

Dans ces trois cas, que s'est-il passé derrière ce qu'on pouvait voir dans le DNS public ? Comment un tel détournement a-t-il été possible ? Sans informations internes, on ne peut évidemment pas le dire. Le fait que d'autres domaines du même Bureau d'Enregistrement (BE) ou du même registre n'aient apparemment pas été touchés semble indiquer que le détournement était spécifique à ces trois noms. Il s'agit probablement de modifications faites via le panneau de contrôle du BE (et pas de l'hébergeur DNS, puisque les serveurs de noms ont été changés). Pour cela, l'attaquant avait un choix de techniques courantes : mot de passe du client trop faible, mot de passe mal conservé (le fameux post-it collé sous le bureau), ingéniérie sociale («bonjour, c'est Natacha, je travaille au support de votre prestataire Internet [...] Il me semble qu'il y a un petit problème [...] Je vais me connecter. rappelez-moi le mot de passe, déjà ?»). De l'extérieur, on ne peut pas dire laquelle a été utilisée. («someone accessed my hosting provider account», dit le responsable de Blackwallet, sans plus de détails, et en confondant BE et hébergeur.)

Ce problème n'est pas spécifique aux noms de domaine. Mais il est aggravé par le fait que, trop souvent, les divers prestataires obligent les clients à avoit des comptes partagés : un seul compte,et donc un seul mot de passe pour gérer les domaines du client. Ces mots de passe partagés sont une grande source d'ennuis : il faut forcément les transmettre à d'autres (ce qui affaiblit la perception de l'importance du secret) et il faut penser à les changer quand quelqu'un quitte l'organisation (ce qui n'est pas toujours fait).

Quelles sont les solutions pour faire face à ce risque ? Il y en a plusieurs (la sécurité n'est jamais une chose simple), exposées dans les lectures suggérées à la fin de cet article. Disons que, dans les trois cas examinés ici, il aurait été bon de :

• avoir une meilleure sécurité des comptes (mots de passe forts, non partagés, non stockés sauf de manière sécurisée dans un gestionnaire de mots de passe),

• avoir une supervision du contenu de la zone DNS, pour être alerté tout de suite, au lieu d'attendre que Reddit n'annonce votre infortune à tout le monde,

• et surtout activer les systèmes de verrouillage comme le « .fr lock » cité plus loin.

Bien sûr, le problème n'est pas limité au monde très mouvant et délicat des cryptomonnaies. De telles attaques sont parfaitement possibles, et régulièrement effectuées, contre des noms de domaines d'autres catégories. Trois bonnes lectures recommandées à ce sujet : le dossier thématique de l'Afnic sur «Sécuriser la gestion des noms de domaine», un autre dossier thématique de l'Afnic sur la solution «.fr lock», et les bonnes pratiques de l'ANSSI sur la gestion de noms de domaines.