MITM as a Service 3G Edition by Bouygues, ou quand ton FAI bousille DNSSEC

Introduction

Pour avoir le support de DANE/TLSA sous Firefox, j’utilise depuis certain temps un addon nommé DNSSEC/TLSA Validator, qui permet en plus de vérifier la validité des signatures DNSSEC (sur les sites qui le supportent) en un coup d’œil. Si la signature est valide, les icônes clé (DNSSEC) et cadenas (HTTPS) apparaissent en vert, si elle erronée, l’icône de la clé apparaît en rouge et cadenas rouge ou gris (HTTP :// à la place du cadenas, en gris. HTTPS, cadenas rouge), comme dans les exemples suivants. Et si le serveur web visité ne supporte pas du tout DNSSEC, les 2 icônes sont en gris.
Un test avec le site dnssec-failed.org, dont la signature DNS est volontairement erronée, pour permettre aux sysadmin de faire des tests en rapport avec DNSSEC, nous donne le résultat attendu.
TLSA Validator: DNSSEC fail
Jusqu’à là, tout va bien, sauf qu’un jour, en utilisant une connexion 3G de Bouygues Telecom, je me suis rendu compte que j’avais un comportement bizarre au niveau de DNSSEC, pour à peu près tous les noms de domaines, j’ai les deux icônes en rouge (signature erronée) un peu partout, aussi bien sur les sites avec une bonne signature de DNSSEC (debian.org, freebsd.org… ) que des sites ne supportant pas du tout DNSSEC. J’ai décidé de faire les tests plus détaillés.

Voici l’exemple avec debian.org sur une connexion 3G Bouygues :
DNSSEC MITM: Bogus signature
Voici l’exemple avec debian.org sur une connexion fixe, en utilisant le résolveur DNS de Lorraine Data Network (LDN) pour être de ne pas tomber sur un autre DNS foireux :

J’ai découvert ça il y a plusieurs mois, mais c’est toujours valable, je viens de refaire des tests… De toute évidence, c’est pas normal, du coup, j’ai essayé d’en savoir plus.

Sortez le popcorn et mettez vous bien à l’aise…

Tout d’abord, on fait un dig pour demander l’enregistrement RRSIG, pour debian.org, puis pour dnssec-failed.org, d’abord avec la connexion 3G Bouygues, ensuite avec une connexion propre, dans les 2 cas en interrogeant le serveur DNS de LDN (parce que je sais qu’il supporte DNSSEC). Le résultat est intéressant…

– Connexion Bouygues 3G

Pour debian.org :

On utilise le +cdflag (Checking Disabled) pour dire au serveur DNS de donner le champs RRSIG sans vérifier la signature. Sans quoi, si la signature est erronée, on aura comme réponse status: SERVFAIL, et aucun champs DNS, même pas les IP. Or là, on pas du tout de champs RRSIG pour un nom de domaine qui a pourtant une signature valide…

Puis pour dnssec-failed.org :

Exactement le même résultat… or on sait que ce nom de domaine a une signature DNSSEC (volontairement erronée, mais existante), on devrait avoir un champs RRSIG car on a mis l’option +cdflag.

D’ailleurs, si vous avez l’habitude d’utiliser dig, vous avez remarqué que vers la fin de la réponse, il y a l’IP du serveur qui répond, et que ici, on a bien l’IP du serveur interrogé… Et pourtant j’insiste, le résolveur DNS interrogé supporte DNSSEC.

On refait les mêmes tests, sans l’option +cdflag, sur une connexion fixe, car on veut justement vérifier la validité de la signature.

– Connexion fixe

Pour debian.org :

Et là, on a une signature DNSSEC…

Puis pour dnssec-failed.org :

On a exactement le comportement attendu, à savoir le refus de résolution d’adresse avec le message d’erreur status: SERVFAIL. En refaisant ce dernier test avec l’option +cdflag, on aura les IP et le champs RRSIG (certes signature invalide mais visible quand même).

A ce stade, ça pue déjà pas mal le Man In The Middle, je soupçonne très fortement Bouygues d’utiliser des proxies, qui en plus de faire du MITM, modifient les adresses sources pour mentir, en mettant l’IP du serveur interrogé pour chaque requête, voire champs SERVER: 80.67.188.188#53 (80.67.188.188).

Mais non, tu vois la mal partout, il y a une autre explication !

J’en doute très fort, mais supposons qu’il y a une autre explication, et que je soit parano… Alors on refait des tests suivants sur la connexion Bouygues 3G, avec des IP prises au hasard.
Le test est simple, prendre une IP au hasard, supposer que c’est un résolveur DNS, et l’utiliser dans la commande dig, pour interroger le serveur correspondant… et ensuite faire un nmap sur cette IP pour voir ce que c’est comme serveur, et on peut même faire un whois, pour bien voir que ça n’appartient pas aux ranges Bouygues Telecom.

Tomber du premier coup sur un vrai résolveur DNS public, j’y crois pas trop mais j’ai quand même fait le test avec 5 ou 6 différentes en tout (les 3 tests, dig, nmap et whois pour chaque IP), avec toujours le même résultat que l’exemple suivant, Je met qu’un seul pour ne pas écrire un pavé. L’exemple en question concerne l’IP 138.2.4.6, prise vraiment au hasard, qui appartient au range d’Oracle. Les autres IP que j’ai testé appartiennent entre autre à Cogent, IANA et j’en passe… avec d’interroger le serveur avec dig sur la connexion Bouygues 3G, commençons par dissiper le doute, on le fait d’abord sur une connexion fixe, certes pas la plus neutre du monde, mais un peu plus propre que la 3G chez Bouygues.

Voilà, ça répond pas, car ce n’est pas un résolveur DNS public, voir pas un résolveur DNS du tout. Pourtant, le même test chez Bouygues donne… une réponse, très similaire au test réalisée plus haut, avec le résolveur de LDN.

Une réponse à une requête DNS en interrogeant un serveur qui ne fait pas de DNS, voir pas un serveur du tout (IP prise au hasard pour rappel), il y a qu’une explication, un proxy qui fait du Man-In-The-Middle, intercepte et traite tous les requêtes DNS, en mentant sur l’origine des paquets réponses (voire le champs ;; SERVER:)

J’y crois pas, pourquoi ils se seraient donner tout ce mal ?

Je vous épargne la sortie du whois, pour vérifier que ce range d’IP appartient bien à Oracle et non pas à Bouygues Telecom… c’est vérifiable depuis n’importe quelle connexion Internet. Par contre, la sortie de nmap, effectué sur le réseau 3G de Bouygues, est beaucoup plus intéressante… Avant d’aller plus loin, une précision, si vous essayer nmap -Pn 138.2.4.6 sur une connexion à peu près propre, sans proxy qui fait du MITM, vous aurez comme réponse All 1000 scanned ports on 138.2.4.6 are filtered, un serveur DNS (port 53) qui répond sur Internet, mais dont tous les 1000 1ers ports (1-1000) sont filtrés, c’est quand même curieux…

Sur une conenxion 3G Bouygues, ça donne ça…

Tour d’un coup, il y a plein de services qui tournent… Mais surtout, il y a un bon gros champs Service Info qui ne laisse aucun pas de doute sur le fait qu’on a bien à faire à proxy (pas si) transparent (que ça), appartenant à Bouygues Telecom

Et sur lequel il y a bien un serveur DNS prêt à intercepter vos requêtes, et à mentir sur les réponses, en cassant DNSSEC au passage…

Mais encore ?

On sait qu’il y a un DNS menteur, qui ne semble pas supporter DNSSEC (Le champs RRSIG dans les requêtes dig qui finit toujours chez Dave Null), mais on sait toujours pas pourquoi on reçoit des signatures erronés d’après DNSSEC/TLSA Validator… là pour le coup, j’ai pas une explication aussi complète, mais un début d’explication quand même…
Lors des requêtes DNS, soit avec dig +dnssec soit DNSSEC/TLSA Validator (j’ai pas determiné le moment exact), je reçois des paquets DNSKEY, contenant une clé publique, et issus avec comme IP source, plusieurs IP délirantes, appartenant à des ranges/entités différentes…
Wireshark: DNSKEY
Ici (agrandir la capture d’écran en cliquant dessus), c’est l’adresse IP l’université du Maryland, dont je n’ai jamais configuré un éventuel résolveur DNS public sur ma machine… Il y a également une IP du range de la Keio University. Je sais pas exactement ce que Bouygues Telecom fout, ni pourquoi j’ai clés DNSSEC qui semblent fausses, issue de serveurs que mon système n’a jamais interrogé, Mais encore une fois, ça sent l’injection de paquets avec l’adresse source forgée. En tout cas si quelqu’un à plus d’infos à ce sujet, ça m’intéresse…

Conclusion

Ça pue très fort, parce qu’on peut pas utilser le DNS qu’on veut. Quelque soit celui configuré sur el système, le proxy de Bouygues intercepte les requêtes DNS et y répond à la place du résolveur qu’on voulait interroger. Et je pense pas que Bouygues soit le seul à faire ce genre de magouilles. Si vous avez l’occasion de faire des tests sur des connexions agrumes télécom, SFR, ou encore Free, les retours m’intéressent. La seule solution que je vois, c’est de passer par un tunnel OpenVPN [1], dont le point de sortie doit se situer sur le même LAN, voire sur la même machine (de confiance) que le résolveur DNS qu’on utilise… il reste le problème de la requête première requête DNS pour établir la connexion VPN. Soit il faudra se connecter au VPN en spécifiant directement l’IP publique du serveur VPN, soit il faudra utiliser /etc/hosts (accès root évidemment nécessaire).

[1] Si c’est pas filtré, j’ai pas encore eu l’occasion de tester. Mais si jamais c’est filtré, on peut tenter de passer le flux VPN dans le port TCP 443, mais c’est sans garantie, et ça risque de créer de l’overhead au niveau de la bande passante/quantité de data utilisée (Il reste à vérifier si ce surplus reste dans la limite du raisonnable).

26 thoughts on “MITM as a Service 3G Edition by Bouygues, ou quand ton FAI bousille DNSSEC”

  1. Cadenas + clé en vert quand je consulte debian.org. L’ADSL free.fr ne trafique pas les requêtes DNS.
    Quand je consulte cette page, le cadenas et la clé sont affichés avec un sens interdit rouge. Cet article serait-il un faux ?
    🙂

    prêt à intercepter vous requêtes -> prêt à intercepter vos requêtes
    (il y en a d’autres, j’ai la flemme de les signaler). Peut-être que l’extension Grammalecte aiderait ?

    1. TuxFamily ne supporte pas DNSSEC/TLSA, tu devrais avoir des icônes grises normalement. Tu utilise quel DNS? celui du FAI?

      PS: Alors oui, si je me relis pas 15 fois, je laisse trainer beaucoup de faute, je repasserai sur l’article plus tard quand j’aurais du temps durant la semaine.

  2. Ton article est top, juste un peu de correction d’orthographe mon ami : -).

    Je pense que pourla 3G, les operateurs telco donnent une IP NATé. Je suis pas certain que IPv4 soit adaptable au mobile, c’est à dire te deplacer sans changer d’IP. En IPv6 on devrait plus avoir ce probleme. A voir du coté des pro reseau 3G.

    1. Merci
      Oui, en 3G c’est bien une IP NATée (Carrier-Grade NAT, du NAT à grande échelle) sur les mobiles, c’est des adresses en 10.x.y.z attribués aux machines clients. Par contre, résoudre le problème avec IPv6, j’y compte pas trop
      – J’ai jamais vu d’IPv6 en mobile (et les forfaits pro, je peux essayer, c’est trop cher)
      – Les devices mobiles (en fonction de l’OS et de la version) peuvent ne pas supporter, ou pas complètement IPv6
      – On peut aussi faire du NAT en IPv6, même si c’est stupide, il y en a qui le font…
      Ça m’étonnerai que les FAI refusent de passer en IPv6 pour les réseaux mobiles, pour continuer à abuser du CGNAT, avec les mêmes excuses pourries qui sortent quand ils font pas du IPv6 en ADSL/fibre “c’est complikay” et autre “c’est trop cher pour l’instant”

      Conclusion : La solution passe forcément par actions coté user, comme tenter d’utiliser un VPN. Faudra pas compter sur les FAI commerciaux pour arrêter de faire n’importe quoi… dommage, les FAI associatifs ne font que du Internet fixe, ça serai intéressant si on avait les moyens de faire de faire du Net sur mobile, pour justement éviter ce genre de magouilles.

      Oui, je compte repasser sur l’article plus tard dans la semaine pour corriger les fautes, je l’ai écrit un peu vite 🙂

  3. Salut,

    Un test ultra rapide sur une connexion 4G de free :

    dig @80.67.188.188 +dnssec +cdflag debian.org

    ; <> DiG 9.9.5-9+deb8u9-Debian <> @80.67.188.188 +dnssec +cdflag debian.org
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43193
    ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags: do; udp: 4096
    ;; QUESTION SECTION:
    ;debian.org. IN A

    ;; ANSWER SECTION:
    debian.org. 300 IN A 140.211.166.202
    debian.org. 300 IN A 128.31.0.62
    debian.org. 300 IN A 149.20.4.15
    debian.org. 300 IN A 130.89.148.14
    debian.org. 300 IN A 5.153.231.4
    debian.org. 300 IN RRSIG A 8 2 300 20170407103449 20170226093449 53598 debian.org. kk53o6XM+LLvxdZKgM2VFKlONt/C9ACaR0i/F9B5nstS0kwbo05BCl2M znIOvPd4cB9041Vct2Ni/jIeDsAg71kgXaZpWOZ5uJcmeMA9Im1lmrgY npXl/7FOFlyvUXleYmW5WyRzKocp1IrZwoyAQyG3Btgfuwf80zRrmgXE IP0rH9SKaDBSeCD1F3zSRJuzhK9yDHzdSKJ5ybBaUlCOAYXENEN4fH5m /Z4y/I7XGLoC89j9YqvoChCDclGwt4wB

    ;; Query time: 120 msec
    ;; SERVER: 80.67.188.188#53(80.67.188.188)
    ;; WHEN: Mon Feb 27 08:24:51 CET 2017
    ;; MSG SIZE rcvd: 353

    1. Donc t’as bien un champs RRSIG. Mais ça dit pas si c’est le résolveur de Free qui répond (et que du coup le DNSSEC est supporté) ou c’est bien le résolveur de LDN.

      Pour avoir un peu plus d’infos (mais sans que ce soit forcément une réponse définitive), tu peux éventuellement de comparer avec dig +dnssec debian.org, pour interroger directement le DNS par défaut de ton appareil mobile (donc celui de Free)

    1. Si t’as rien changé sur ton système GNU/Linux, tu devrais avoir dans ton /etc/resolv.conf quelque chose comme nameserver IP_de_tabox (et éventuellement d’autres lignes). Et il y a de grandes choses, voire 100% de chance pour que ta box soit configurée pour interroger les résolveurs DNS de Free. A peu près tous les FAI imposent plus ou moins leurs DNS par défaut.

      Je connais pas la Freebox mais dans l’interface tu peux probablement voir les IP qui sont configurées, et peut-être les changer. Mais il faut voir si les DNS sont effectivement changés ou si c’est toujours le résolveur du FAI qui répondra

      1. Je n’ai rien dans ma configuration.
        $ cat /etc/resolv.conf
        affiche :
        # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
        # DO NOT EDIT THIS FILE BY HAND — YOUR CHANGES WILL BE OVERWRITTEN
        nameserver 127.0.1.1

        Dans l’interface de ma freebox, j’ai la possibilité de paramétrer un nom de domaine donc d’activer un serveur DNS mais à part ça, je n’ai pas trouvé où sont paramétrés les DNS utilisés. Je suppose que ce sont les DNS de Free qui sont utilisés par défaut.

        1. Si, t’as nameserver 127.0.1.1, mais c’est bizarre, ça veut dire que t’as machine s’interroge elle même pour le DNS, c’est la conf à avoir quand t’as un résolveur DNS qui tourne sur ta machine. Du coup c’est un peu bizarre, mais effectivement je suppose que tu utilise les DNS de Free puisque c’est probablement la config par défaut de ta box

          1. Ce type dns se retrouve avec resolvconf+NetworkManager… Typique des ubuntu likes. Pour trouver le dns utilisé faut regarder dans les paramètres réseau. ☺

  4. J’ai apparemment un dnsmasq qui tourne mais il écoute une adresse 127.0.1.1 qui n’est pas dans mon réseau :

    $ ps aux|grep dns
    nobody 1346 0.0 0.0 52948 4200 ? S 21:51 0:00 /usr/sbin/dnsmasq –no-resolv –keep-in-foreground –no-hosts –bind-interfaces –pid-file=/var/run/NetworkManager/dnsmasq.pid –listen-address=127.0.1.1 –cache-size=0 –conf-file=/dev/null –proxy-dnssec –enable-dbus=org.freedesktop.NetworkManager.dnsmasq –conf-dir=/etc/NetworkManager/dnsmasq.d
    david 3529 0.0 0.1 361928 9096 ? Sl 22:03 0:00 /usr/lib/gvfs/gvfsd-dnssd –spawner :1.11 /org/gtk/gvfs/exec_spaw/13

    1. Oui, par convention pour pas avoir une tetrachiée d’IP différentes, on a décidé que le loopback, c’est 127.0.0.1, mais en fait, loopback va de 1270.0.1 à 127.255.255.254.

  5. A new Bouygues customer here. Just discovered that my unbound resolver stopped validating after the switch to Bouygues. Here’s something else for you to muse over:

    telnet debian.org 25

    Cheers and sorry for my French.

  6. $ telnet smtp.gmail.com 25
    Trying 66.102.1.108…
    Connected to smtp.gmail.com.
    Escape character is ‘^]’.
    220 smtp-proxy-2y.bouyguesbox.fr ESMTP Postfix
    quit
    221 2.0.0 Bye
    Connection closed by foreign host.

    1. port 25 “magic smtp” isn’t that bad… I doubt you were planning to send credentials without SSL and sending email from your phone over mobile data without credentials through a server other than your mobile operator is unlikely to be a great success. This automated redirect actually helps your email go out in this case 😉

      1. SPF n’a rien avoir avec Bouygues et leurs MITM… C’est un mécanisme de validation qui vérifie si l’adresse de l’expéditeur est légitime, ou si elle est forgée

  7. Bonjour,
    Soyez prudents avec vos nmap sur des adresses prises au hasard. De mémoire il me semble avoir lu, il y a un moment, un article qui disait que c’est pas trop bien vu par certains admins des serveurs questionnés. Cela peut dans certains cas, être considéré comme une “attaque”
    Merci pour cet article interessant

    1. Ça n’a rien d’une attaque, c’est juste demander au serveur « qui est-tu » pour savoir si le serveur attendu/légitime qui répond, ou c’est un proxy qui fait du MITM. Les admins qui considèrent ça comme “une attaque” devraient sérieusement à songer à changer de métier.

      D’ailleurs, ils ne voient pas les requêtes nmap dans leurs logs parce que les requêtes n’arrivent jamais aux serveurs en question, à cause proxy de Bouygues, qui redirige les requêtes vers des machines de Bouygues, qui semblent être derrière un NAT de Bouygues (le proxy fait NAT pour le résolveur DNS et éventuellement d’autres machines)

  8. Avec 4G Orange avec debian.org
    root@PC-Flubox:~# dig @80.67.188.188 +dnssec +cdflag debian.org

    ; <> DiG 9.10.3-P4-Ubuntu <> @80.67.188.188 +dnssec +cdflag debian.org
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10479
    ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags: do; udp: 4096
    ;; QUESTION SECTION:
    ;debian.org. IN A

    ;; ANSWER SECTION:
    debian.org. 273 IN A 128.31.0.62
    debian.org. 273 IN A 140.211.166.202
    debian.org. 273 IN A 130.89.148.14
    debian.org. 273 IN A 5.153.231.4
    debian.org. 273 IN A 149.20.4.15
    debian.org. 273 IN RRSIG A 8 2 300 20170712171726 20170602161726 53598 debian.org. akRwHRzqclshkrrhvEU+xCxYmRN2ukLDU9z3l7C/k/JrwkqfsH8Zq2lq Qju4/hkrKQfANwAv3SuKhNVVARYZXcaIYiQ27F56gmYFhJ0+y1ANjc2p qzeRKrSCzU4HdhU9Kp6ObFN7PamD7K7Et1sBUAfG8UJB26/qafovumIk yL8q9KqiqVZfK+ZlYul+1ywZJBkaf3uOWZbyTQjcgnhKQ0WEyE8pfXyc QmiGwzlnSkf5gXMO2nhotH+wtnrT4EOM

    ;; Query time: 79 msec
    ;; SERVER: 80.67.188.188#53(80.67.188.188)
    ;; WHEN: Mon Jun 05 12:00:40 DST 2017
    ;; MSG SIZE rcvd: 353

Leave a Reply

Your email address will not be published. Required fields are marked *