<?xml version="1.0" encoding="utf-8"?>
<entry title="Détournement du nom de domaine eth.limo">
  <date>2026-04-20</date>
<content>
  <p>Le 18 avril, le <wikipedia name="Nom de domaine">nom de
  domaine</wikipedia> <computer>eth.limo</computer> a été victime d'un
  détournement (une attaque où le méchant prend le contrôle du nom et
  change les informations).</p>
  <p>Les détournements sont le deuxième plus gros problème de sécurité
  des <wikipedia name="Nom de domaine">noms de domaine</wikipedia>,
  avec les <wikipedia name="Attaque par déni de service">attaques par déni de service</wikipedia>. Des
  articles de bilan sur celui-ci ont été produits aussi bien par <link
  url="https://x.com/eth_limo/status/2045552916157563148">le titulaire
  du nom</link> (nom qui est utilisé en rapport avec <wikipedia
  name="Ethereum">la cryptomonnaie Ethereum</wikipedia>) que par <link
  url="https://easydns.com/blog/2026/04/18/we-screwed-up-and-we-own-it-the-eth-limo-shtshow-is-on-us/">le
  revendeur EasyDNS</link> (dont on notera la franchise « nous avons
  merdé »). On ne sait pas exactement comment s'est fait le
  détournement (l'article d'EasyDNS parle juste
  d'« <wikipedia name="Ingénierie sociale (sécurité de l'information)">ingénierie sociale</wikipedia>). Mais voyons les
  changements faits dans le <wikipedia name="Domain Name
  System">DNS</wikipedia>, et quelques leçons à tirer.</p>
  <p>Le domaine a été enregistré via <wikipedia xml:lang="en" name="EasyDNS">EasyDNS</wikipedia>,
  un revendeur du <wikipedia name="Bureau
  d'enregistrement">BE</wikipedia> <wikipedia>Tucows</wikipedia>. Il
  est hébergé sur <wikipedia name="Amazon Web Services">AWS</wikipedia>. Voici l'information
  obtenue via <wikipedia name="Registration Data Access
  Protocol">RDAP</wikipedia> :
  <code>
% rdap eth.limo
…
Nameserver: ns-814.awsdns-37.net
Nameserver: ns-1689.awsdns-19.co.uk
Nameserver: ns-48.awsdns-06.com
Nameserver: ns-1382.awsdns-44.org
Delegation Signed: yes
…
Last Changed: 2026-04-18T15:31:54.163Z
…
Role: registrar
Name: Tucows Domains Inc.
  </code>
  (Notez qu'on ne peut pas utiliser <wikipedia>whois</wikipedia>,
  celui-ci n'est plus obligatoire dans les <wikipedia name="Domaine de
  premier niveau">TLD</wikipedia> <wikipedia name="Internet
  Corporation for Assigned Names and Numbers">ICANN</wikipedia> et, en
  effet, <computer>.limo</computer> ne semble plus en avoir.)</p>
  <p>Enregistrés par <link local="dnsdb">DNSDB</link>, voici la
  délégation <wikipedia name="Domain Name System">DNS</wikipedia>
  normale de <computer>eth.limo</computer> :
  <code>
;;  bailiwick: limo.
;;      count: 1371
;; first seen in zone file: 2022-07-15 00:15:27 -0000
;;  last seen in zone file: 2026-04-19 00:11:22 -0000
eth.limo. IN NS ns-48.awsdns-06.com.
eth.limo. IN NS ns-814.awsdns-37.net.
eth.limo. IN NS ns-1382.awsdns-44.org.
eth.limo. IN NS ns-1689.awsdns-19.co.uk.
  </code>
  Et pendant le détournement (deux jeux de <link
  local="serveur-dns-faisant-autorite">serveurs de noms</link>
  utilisés, comme noté par le tweet du titulaire) :
  <code>
;;  bailiwick: limo.
;;      count: 495
;; first seen: 2026-04-18 06:31:38 -0000
;;  last seen: 2026-04-18 08:06:34 -0000
eth.limo. IN NS joan.ns.cloudflare.com.
eth.limo. IN NS garrett.ns.cloudflare.com.

;;  bailiwick: limo.
;;      count: 1363
;; first seen: 2026-04-18 08:06:57 -0000
;;  last seen: 2026-04-18 11:59:02 -0000
eth.limo. IN NS dns1.namecheaphosting.com.
eth.limo. IN NS dns2.namecheaphosting.com.
  </code>
  Il est amusant de constater que deux jours après, Cloudflare (et Namecheap)
  continuent à servir la mauvaise information :
  <code>
<![CDATA[
% dig @joan.ns.cloudflare.com. eth.limo NS
…
;; ANSWER SECTION:
eth.limo.		86400 IN NS garrett.ns.cloudflare.com.
eth.limo.		86400 IN NS joan.ns.cloudflare.com.
…
;; WHEN: Mon Apr 20 14:02:13 BST 2026
]]>	     
  </code>
  Qu'est-ce que le méchant a changé dans la zone ? Il a modifié
  l'<wikipedia name="Adresse IP">adresse IP</wikipedia>, pointant vers
  un hébergement Web chez Namecheap. On le voit aussi
  avec DNSDB :
  <code>
;;      count: 206
;; first seen: 2026-04-18 07:36:35 -0000
;;  last seen: 2026-04-18 11:50:19 -0000
eth.limo. IN A 162.213.253.76
  </code>
  Mais notez que les <link local="serveur-dns-faisant-autorite">serveurs
  faisant autorité</link> de Cloudflare et Namecheap continuent de
  servir la mauvaise info. Comparez avec la vraie :
  <code>
<![CDATA[    
% dig eth.limo A
…
;; ANSWER SECTION:
eth.limo.		60 IN A	35.71.142.77
eth.limo.		60 IN A	52.223.52.2
…
;; WHEN: Mon Apr 20 13:18:39 UTC 2026

% dig @dns1.namecheaphosting.com eth.limo A 
…
;; ANSWER SECTION:
eth.limo.		14400 IN A 162.213.253.76
…
;; WHEN: Mon Apr 20 13:19:06 UTC 2026
]]>
  </code>
  Et en mettant <computer>162.213.253.76 eth.limo</computer> dans son
  <computer>/etc/hosts</computer>, on peut voir le site « pirate »,
  qui n'a pas été supprimé. Il ressemble tout à fait au vrai, sauf
  qu'il n'a pas de <wikipedia name="HyperText Transfer Protocol
  Secure">HTTPS</wikipedia>. Puisqu'on parle de HTTPS, notons que
  l'attaquant ne semble pas avoir demandé de
  <wikipedia name="Certificat électronique">certificat</wikipedia> (il aurait pu). Le dernier
  certificat alloué date du 11 avril. C'est en tout cas ce qu'on voit
  en regardant les <wikipedia xml:lang="en" name="Certificate Transparency">journaux Certificate
  Transparency</wikipedia>.</p>
  <p>Le domaine était <wikipedia name="Domain Name System Security
  Extensions">signé</wikipedia> et l'attaquant, bêtement, n'a pas
  changé l'<wikipedia xml:lang="en" name="List of DNS record types" anchor="DS">enregistrement DS</wikipedia>, ce qui fait que
  tous les gens utilisant (à raison) un <link
  local="resolveur-dns">résolveur</link> validant n'ont pas pu voir le
  site pirate. (Personne ne semble avoir testé le domaine avec <link
  url="https://dnsviz.net/d/eth.limo/dnssec/">DNSviz</link> pendant le
  détournement mais les tests anciens montrent que le DS était là
  depuis bien avant.)</p>
  <p>Il ne semble pas (mais ce n'est pas visible de l'extérieur) que
  <computer>eth.limo</computer> était protégé par un verrou au
  <wikipedia name="Registre de noms de domaine">registre</wikipedia> (je ne sais pas si
  <computer>.limo</computer> a un tel service, l'équivalent du
  <foreign><link
  url="https://www.afnic.fr/produits-services/services-associes/fr-lock/">FR
  lock</link></foreign> de
  <computer><wikipedia>.fr</wikipedia></computer> ; Patrick Mevzek a
  cherché et n'a pas trouvé trace de ce service en
  <computer>.limo</computer><!-- https://framapiaf.org/@pmevzek/116437693439750124 https://www.icann.org/en/registry-agreements/details/limo -->). C'est pourtant une
  très bonne protection contre les détournements mais aucun des deux
  articles n'en parle.</p>
</content>
</entry>
