IP Squatting appliqué au SPAM – Partie 2/2

4.4 Des blocs inutilisés (quoi que…)

Le comptage de grands nombres d’adresses se fait par multiple de 2^24 – soit environ 16,7 millions – qu’on appelle « /8s » (prononcé « slash eight »). Sur les 256 /8s, 168,7 sont annoncés et routés sur Internet ; 35,3 sont réservés ; 3,6 ne sont pas encore assignés. Il y a donc 48,3 /8s qui sont assignés, mais pas utilisés dans le routage public.

Fig. 1 : Répartition de l’utilisation des blocs d’adresses IP.


La majeure partie de ces adresses correspondent à des assignations historiques, désignées Legacy ou Early Registration Transfer (ERX). Des compagnies ou administrations se sont vues alloués des /8s entiers et continuent parfois de les utiliser pour leurs réseaux internes. D’autres blocs ont été assignés à des entités qui ont disparu, par fusion ou faillite, et dont personne n’a réclamé les assignations. Ces blocs ne peuvent pas être réassignés faute de cadre contractuel concernant l’assignation initiale.

Les RIR ont mené plusieurs campagnes afin de formaliser ces assignations historiques, mais la disparition de l’assignataire est un cas de figure qui empêche tout mouvement. Afin de remettre la main sur des blocs abandonnés, certains spammeurs ont organisé l’usurpation d’identités d’entreprises et/ou de leurs dirigeants afin d’obtenir des mises à jour des registres offrant la légitimité apparente des annonces de tels blocs [5].

Dans d’autres cas, plus nombreux, on voit simplement des préfixes apparaître dans la table de routage globale, derrière des AS n’ayant aucune légitimité apparente à les annoncer ou relayer. Une recherche ciblée à la suite de quelques incidents mineurs a par exemple révélé une grande quantité d’annonces illégitimes de l’AS43239 au cours de l’été 2014 [6].

Comment les spammeurs parviennent-ils à router ces blocs qui ne leur ont pas été assignés ?

5. (Complicité d’) Abus de confiance

Reprenons l’exposé depuis le début. Un spammeur a besoin d’adresses IP « propres » pour travailler. S’il obtient une assignation ou achète un bloc, celui-ci sera rapidement identifié par les services d’anti-spam. Sachant que le bloc sera blacklisté, peu d’opérateurs acceptent d’en louer aux spammeurs. Ces derniers n’ont donc qu’une solution : utiliser n’importe quel bloc – de préférence « disponible » (i.e. pas actuellement annoncé sur Internet) – sans en avoir la légitimité.

Pour pouvoir router ce bloc sur Internet, il faut qu’au moins un opérateur accepte de fournir un transit au spammeur, et que les annonces soient relayées et acceptées par les pairs et transits de cet opérateur. De deux choses l’une :

  • soit le spammeur parvient à abuser la confiance d’un registre afin de prendre le contrôle des enregistrements représentant le routage légitime du bloc d’adresses (via récupération d’un nom de domaine abandonné, pointé dans les enregistrements) ;
  • soit les opérateurs acceptent de fournir un transit au spammeur sans aucun contrôle de la légitimité des annonces.

Il est assez facile de berner les opérateurs faisant des contrôles de légitimité sur des IRR peu sûrs (par exemple avec RADb [7] qui ne fait pas de vérification avant d’accepter un nouvel enregistrement [8]).

Alors que la première approche repose essentiellement sur le social-engineering, la seconde consiste finalement à trouver un complice plus ou moins volontaire. Pour toucher un plus grand nombre de destinataires, il faut réunir plusieurs composants :

  • un hébergeur bulletproof, qui acceptera d’héberger un spammeur ;
  • cet hébergeur doit avoir de nombreux transitaires et peerings, configurés de façon aussi laxiste que possible, pour que les annonces remontent jusqu’à au moins un Tier1 ;
  • dès qu’un Tier1 reçoit et accepte l’annonce, alors la visibilité totale est quasiment garantie.

Notez que la plupart des contrôles se font en associant le numéro d’AS au bloc d’adresses annoncé. Si le spammeur usurpe les deux, et qu’un opérateur accepte une session avec un AS usurpé sans en avoir contrôlé la légitimité, alors la propagation est encore plus facile, car il n’y a pas de modification à effectuer dans les registres. Cela peut arriver dans deux cas : soit le transitaire est complice, soit le spammeur usurpe l’identité de l’assignataire de l’AS et des blocs d’adresses avec succès [9].

De même, si un réseau accepte de fournir un transit (Tier1 ou Tier2) à un réseau lui-même transitaire pour d’autres réseaux (Tier2), alors il pourrait vouloir s’assurer que les clients de son client (Tier3) sont réels et légitimes, car le Tier3 pourrait tout à fait configurer un routeur pour qu’il s’annonce comme étant l’AS d’origine légitime d’un préfixe usurpé. La vérification transitive (à travers plusieurs AS) est plus compliquée que si elle est effectuée dès le début (en edge), car elle implique la construction de filtres plus complexes et basés sur les déclarations des intermédiaires aux registres.


Le langage RPSL
C’est à un besoin de transparence que répond le langage RPSL (Routing Policy Specification Language – RFC2622) utilisé pour décrire les relations inter-AS au sein de certains registres. Deux problèmes se posent alors :

  •  l’information doit être la plus exhaustive possible ;
  • elle doit être maintenue à jour.

Comme cette information caractérise des relations diverses dont certaines sont d’ordre commercial, certains acteurs considèrent qu’il n’est pas souhaitable de les publier sur un registre opposable en vertu du secret des affaires.


Une fois le bloc annoncé, accepté et globalement joignable, alors l’envoi de SPAM peut commencer. Celui-ci peut durer de quelques minutes à quelques heures, en fonction de la réactivité des éditeurs de listes de blocage.

Une fois le SPAM envoyé, l’annonce est abandonnée et le préfixe sombre à nouveau dans l’oubli. Il est désormais terni par une mauvaise réputation dans les listes de blocage et ne devrait plus être utilisé avant l’expiration de ces enregistrements.

L’opération peut se poursuivre sur cette infrastructure en utilisant un autre bloc. Dans le cas « Telelatina » (AS15078), plus de 1000 blocs ont ainsi été utilisés entre juillet et septembre 2014 [10]. Le motif était alors très reconnaissable puisqu’environ 8 préfixes étaient annoncés simultanément, utilisés, puis retirés alors que d’autres étaient annoncés, et ce plusieurs dizaines de fois à des intervalles de 8 à 24h.

Fig. 2 : Annonce de blocs usurpés par Telelatina.

 

6. Victime collatérale, complicité ou simple chatouillis ?

Une constante est visible dans ces « attaques » : la confiance naturelle entre les opérateurs – induite par le fonctionnement même de BGP – est abusée par un des AS intermédiaires. Quelles actions sont envisageables ?

Les guillemets sont importants ici : il ne s’agit pas d’une attaque, car les usurpations ne perturbent pas – dans le cas de leur usage par les spammeurs, et tant que le bloc ciblé n’était pas utilisé – le fonctionnement d’Internet ou d’un des réseaux qui relayent les annonces.

Il n’y a pas non plus nécessairement de violation de clauses contractuelles, puisque les assignations des blocs d’adresses, les interconnexions entre opérateurs, et même le raccordement à certains points d’échanges ne sont pas forcement soumis à un contrat.

Enfin, il ne semble pas y avoir de crime ou délit défini en droit français ou américain qui puisse s’appliquer à l’utilisation illégitime d’un bloc d’adresses dormant. Seuls certains moyens d’y parvenir sont actuellement répréhensibles (fraude, faux et usage de faux, usurpation d’identité).

Internet repose tout entier sur des conventions, qu’elles soient établies de gré à gré pour les interconnexions ou sous une forme plus institutionnelle au travers de l’IETF ou du RIPE par exemple. Le non-respect des conventions ou Best Current Operationnal Practices, n’est pas fondamentalement répréhensible. Simplement mal vu par la communauté qui fait fonctionner le réseau.

À première vue, il n’y a donc pas d’autre recours qu’un traitement de l’anomalie par la communauté elle-même. La première réponse à un abus est la mise en place de filtres qui ne l’avaient pas été jusque-là, ou bien directement le de-peering (rupture unilatérale d’interconnexion).

La perte de confiance de la communauté à l’égard d’un complice – volontaire ou non – d’une campagne d’IP-squatting ne prendrait donc a priori pas d’autre forme qu’une méfiance finalement pas forcement malvenue.

Il n’en va pas de même lorsqu’une annonce intentionnellement frauduleuse perturbe le fonctionnement d’un réseau, par exemple en annonçant un bloc déjà utilisé ailleurs dans le réseau, mais une tolérance s’applique lorsque l’intention n’est pas manifeste. La plupart des pannes provoquées par des usurpations en BGP sont historiquement dues à des erreurs de configuration, pas à des attaques.

7. D’autres applications possibles

Un grand nombre de facteurs combinés permettent ce type de détournement. Pour résumer, citons les principaux :

  • faible qualité de certains registres, aggravée par la marchandisation des blocs d’adresses en période de pénurie ;
  • nature des interconnexions entre opérateurs, historiquement basée sur la confiance entre un nombre relativement limité d’acteurs ;
  • complexité opérationnelle d’un réseau d’opérateur dont la mise à jour d’un routeur entraîne généralement des interruptions de service ;
  • manque d’automatisation de ces réseaux, qui ne fonctionneraient de toute façon qu’avec des registres de bonne qualité ;
  • inertie des équipementiers qui vendent très cher des implémentations tardives, voire incomplètes, des moyens de contrôle.

L’IP-squatting est donc globalement aisé pour quiconque ayant accès à une ou plusieurs interconnexions de confiance (lire « laxiste »).

Lorsqu’il est temporaire, souvent faute de logs des annonces quotidiennes de la table routage globale, il est difficile à repérer a posteriori. Il apparaît clairement aux acteurs majeurs de la lutte contre le spam que cette pratique a le vent en poupe.

Une attaque bien construite (comme Pilosov et Kapela [11]) permet d’aller encore plus loin que le simple SPAM, en détournant le trafic à destination d’un bloc pour implémenter un MiTM à grande échelle. C’est de cette manière que pourraient s’opérer des campagnes d’espionnage industriel [12], car le chiffrement correct des mails est difficile si ce n’est impossible avec les systèmes de messagerie employés au sein des entreprises et institutions visées.


Sources d’information

  • BGP constitue un système global et distribué, un peu comme une blockchain primitive – mais naturellement amnésique. Afin d’étudier le fonctionnement du routage de l’ensemble d’Internet, et d’analyser certains abus protocolaires, plusieurs initiatives enregistrent, traitent et produisent des rapports sur la base des informations de routage.
  • RIPE Routing Information Service, plus précisément l’interface de consultation la plus pratique – https://stat.ripe.net/.
  • Le RIPE dispose de plusieurs collecteurs qui enregistrent et analysent les flux BGP à différents endroits du réseau. Les outils mis à disposition pour la recherche dans ces données historiques sont ceux utilisés pour afficher les graphiques de visibilité des préfixes dans le temps.
  • Geoff Huston (APNIC) – http://bgp.potaroo.net/.
  • Les rapports les plus connus sont le CIDR-Report (qui recense les désagrégations du routage) et le BGP Instability Report, qui listent les AS les plus actifs (lire instables). Ils sont postés chaque semaine sur NANOG.
  • Team Cymru (prononcer « Kumree ») – http://www.team-cymru.org/.
  • De nombreux outils et projets distincts, complémentaires aux précédents. Cymru fournit surtout des flux de blocs dits « bogons », susceptibles de contenir un grand nombre de blocs usurpés, afin de permettre aux opérateurs de les filtrer dynamiquement et ainsi endiguer ce vecteur de SPAM.

Jérôme NICOLLE (@chiwawa_42)
Ceriz – jerome@ceriz.fr

Arnaud FENIOUX (@afenioux)
France-IX – afenioux@franceix.net

Références

[0] RIPE NCC, IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region (a.k.a ripe-649), 23 juillet 2015, https://www.ripe.net/publications/docs/ripe-649
[1] Stéphane Bortzmeyer, La longue marche de la sécurité du routage Internet, 4 février 2012, http://www.bortzmeyer.org/securite-routage-bgp-rpki-roa.html
[2] Paul Hoffman – Internet Mail Consortium, Allowing Relaying in SMTP: A Series of Surveys, août 2002, https://www.imc.org/ube-relay.html
[3] Andree Toonk, Massive route leak causes Internet slowdown, 12 juin 2015, http://bgpmon.net/massive-route-leak-cause-internet-slowdown/
[4] Matthew Prince, The DDoS That Knocked Spamhaus Offline, 20 mars 2013, https://blog.cloudflare.com/the-ddos-that-knocked-spamhaus-offline-and-ho/
[5] The Spamhaus Team, Network Hijacking on the Rise, 26 septembre 2016, https://www.spamhaus.org/news/article/732/
[6] Rapport hijacking de préfixes : https://portal.bgpmon.net/data/43239Hijack.html
[7] Merit RADb : http://www.radb.net/
[8] Présentation de Andree Tonk au NANOG63 relatant d’exemples de hicak récents dont certains ont reposé sur la politique de Merit RADb : https://blog.apnic.net/2015/02/11/nanog-63-bgp-route-hijacks/
[9] Présentation d’un cas d’usurpation d’identité auprès d’un RIR : http://securityskeptic.typepad.com/the-security-skeptic/2011/06/asn-hijacking-attacks.html
[10] Détails des annonces BGP de l’AS15078 : https://stat.ripe.net/AS15078#tabId=routing
[11] Stéphane Bortzmeyer, La faille de sécurité BGP de 2008, 28 août 2008, http://www.bortzmeyer.org/faille-bgp-2008.html
[12] Exemples de redirection de trafic pouvant donner lieu à interceptions, http://research.dyn.com/2013/11/mitm-internet-hijacking/

Retrouvez cet article (et bien d’autres) dans MISC n°89, disponible sur la boutique et sur la plateforme de lecture en ligne Connect !

Laisser un commentaire