Failles de sécurité sur les modems SFR/Numericable

Au départ, je cherchais à désactiver automatiquement le WiFi de mon modem la nuit. Comme il y a une interface web d’administration du modem, j’ai essayé de scripter les opérations sur cette interface.

C’est en développant ce script que j’ai découvert plusieurs failles de sécurité dans cette interface d’administration. Dans certaines conditions, cela permettait à n’importe qui sur Internet de voir et modifier tous les paramètres du modem. Les failles les plus critiques ont maintenant été corrigées par SFR/Numericable.

Sommaire

Modems affectés

Le FAI SFR/Numericable fournit un modem à chaque abonné câble. Actuellement (à ma connaissance), ils fournissent en France 3 modèles câble :
– modem de marque Netgear (offre iStart)
– modem de marque Castlenet (offre iStart)
– modems « LaBox » (autres offres)

Les failles que je vais décrire concernaient tous ces modems (sauf a priori le Castlenet, je n’ai pas pu vérifier).

Le modem comporte une interface d’administration, accessible en local à l’adresse http://monmodem/

Elle permet de gérer tous les paramètres du modem : configuration du réseau local (y compris serveurs DNS), WiFi, DLNA, téléphonie, sécurité etc. Son accès est sécurisé par un login/mot de passe (admin/password par défaut, modifiable par l’utilisateur).

Il est également possible d’autoriser l’accès à cette interface d’administration depuis l’extérieur (sur le port 8080 par défaut). Dans ce cas, la portée des failles ci-dessous était beaucoup plus grave. Heureusement, cette option n’est pas activée par défaut.

Failles découvertes

Première faille : l’authentification n’était pas vérifiée sur les requêtes HTTP en mode POST, mais uniquement sur celles en mode GET

Conséquence : il était possible de modifier les paramètres du modem sans connaître le login/mot de passe.

Je m’en suis rendu compte parce que mon script de désactivation du WiFi fonctionnait, alors que je n’avais pas encore codé l’authentification…

Exemple : la requête HTTP ci-dessous permettait (sur un modem NetGear) de modifier le mot de passe d’administration à distance du modem (et donc, ensuite d’accéder à tout, librement) :

curl --data "NumNetgearRmEnable=0x01&NumNetgearRmPassword=monmotdepasse&NumNetgearRmPortNumber=8080&NumNetgearRmResetDefaults=0&NumNetgearRemoteUserLevel=1&NumNetgearRmResetDefaultsFlag=0" http://x.x.x.x:port/goform/Numsecurite_pb2_accesdistance

Si l’administration à distance était activée, cette faille était exploitable depuis l’extérieur.

Et il n’y avait pas forcément besoin d’utiliser la ligne de commande pour l’exploiter : un simple navigateur suffisait, en ouvrant une page HTML qui générait ce type de requête.

Cela ouvrait la voie à des attaques par scan des adresses IP du FAI (pour ceux qui auraient activé l’administration à distance), ou à du fishing pour les autres.

Cette faille a été corrigée par SFR/Numericable, apparemment en ajoutant un paramètre dans l’URL de chaque requête (id=xxx). Il semble s’agir d’un « jeton » à usage unique, dont la valeur est apparemment générée aléatoirement sur chaque requête GET, et contrôlée dans la requête POST qui suit. Une sorte de « session » qui ne dure qu’entre les 2 requêtes : pas très académique mais probablement efficace.

Seconde faille : l’authentification semble gérée par adresse IP du client (et non par un jeton de session en cookie ou dans l’url)

Conséquence : à partir du moment où quelqu’un s’est authentifié, toutes les requêtes venant de la même adresse IP sont acceptées sans demande de login/mdp.

Exemple : si vous partagez une même adresse IP avec plusieurs utilisateurs (via un proxy HTTP, ou simplement via un serveur NAT), et que vous êtes authentifié sur l’interface d’administration du modem, tous les autres utilisateurs derrière ce proxy ou NAT peuvent ensuite y accéder sans s’authentifier, en mettant l’adresse http://x.x.x.x:port/Numreseau.htm. Ils ont un accès complet, en lecture et écriture.

SFR/Numericable a décidé de ne pas corriger cette faille, pour des raisons de complexité technique.

Troisième faille : si certains paramètres étaient omis dans une requête HTTP en mode POST, cela faisait redémarrer le modem

Conséquence : possibilité simple de faire du déni de service.

Exemple : La requête ci-dessous faisait planter et redémarrer le modem :

curl --data "NumNetgearRmResetDefaults=0&NumNetgearRemoteUserLevel=1&NumNetgearRmResetDefaultsFlag=0" http://x.x.x.x:port/goform/Numsecurite_pb2_accesdistance

SFR/Numericable a a priori corrigé cette faille. En tous cas, la correction de la première faille (avec le paramètre « id ») limite fortement sa portée.

Quatrième faille : pas de chiffrement SSL de l’interface d’administration

Ce n’est pas à proprement parler une faille, mais l’absence d’une fonctionnalité de sécurité importante. Ce n’est pas un scoop : n’importe qui peut le constater en se connectant à l’interface d’administration.

En effet, que ce soit en réseau local ou depuis l’extérieur (si activé), le login/mdp d’administration passe en clair sur le réseau, et peut donc être intercepté (en Wifi, notamment).

SFR/Numericable a décidé de ne pas corriger cette faille, en expliquant la complexité technique et de gestion des certificats SSL pour qu’ils soient acceptés par les navigateurs. C’est vrai. Mais pourtant Free l’a fait sur ses Freebox Revolution et mini 4K, en utilisant les certificats (gratuits, et acceptés par défaut par tous les navigateurs pas trop vieux) de Let’s Encrypt.

D’où viennent ces failles?

Évidemment, je n’ai pas accès au code source. Je ne peux donc faire que des suppositions, et il est possible que je me trompe.

On peut supposer que l’interface web a été développée avec des outils bas niveau, sans framework web. La faille du reboot me laisse à penser que l’interface d’administration tourne dans le même processus que le firmware du modem.

Dommage quand on sait que n’importe quel langage de programmation orienté web (type PHP) ou framework (même en C) aurait largement simplifié et sécurisé le développement. Notamment, une gestion très classique de la session utilisateur (gérée par tout framework web, que ce soit via un cookie ou via un identifiant passé en paramètre) aurait évité les 2 premières failles.

On peut supposer que des limitations techniques (ex : RAM disponible, taille maximum du firmware, puissance du CPU etc) aient expliqué ce choix dans les premières versions de l’interface d’administration.

Mais, sur les modems récents, cet argument ne tient plus. Il est probable (mais ce n’est qu’une supposition) que SFR/Numericable ait préféré reconduire l’interface d’administration existante, plutôt que d’en refaire une pour les nouveaux modems. Avoir une seule interface pour tous les modems simplifie probablement par mal de choses pour eux (documentation, support, maintenance etc).

A l’exception de la faille n°2, il ne s’agit a priori pas de bugs (erreur d’un développeur), mais de règles de sécurité pas implémentées du tout : gestion propre de la session utilisateur, chiffrement SSL, séparation de l’interface et du firmware dans des processus séparés. Peut-être le résultat d’un compromis entre le risque, les contraintes techniques de la plateforme et/ou les coûts de développement/maintenance. Peut-être même que ce n’est pas SFR/Numericable qui a fait ces choix, mais un fournisseur ou sous-traitant.

Communication des failles à SFR/Numericable

J’aborde ce sujet dans un second article.

18 réflexions sur « Failles de sécurité sur les modems SFR/Numericable »

  1. Si l’option d’administration à distance est désactivée (et elle l’est me semble-t-il par défaut) on a pas de problème de sécurité à priori ?

    Sinon dans le doute je ne préfère ne pas laisser ces options d’admin externe activées, je préfère avoir une machine (sécurisée) dans le LAN joignable depuis l’extérieur et ensuite rebondir par celle-ci pour joindre l’interface de la Box au besoin.

    1. Oui, l’administration a distance n’est heureusement pas activée par défaut.
      Si on ne l’active pas, cela limite beaucoup la portée des failles restantes puisqu’elles ne sont exploitables que sur le réseau local.

  2. Je confirme pour la 2, une fois logué c’est bien l’IP qui fait office de « session ». Autrement dit il est très facile de demander à une personne ayant le mdp de se connecter pour ensuite utiliser la même IP… pour deviner la bonne IP il suffit de balayer le subnet, ce qui prendra que quelques secondes.

    Concernant les équipements Netgear je ne sais pas dans quelle mesure on trouve du code de NC ou de Netgear… car dans ce cas ce serait Netgear qui aurait corrigé le bug (présent chez d’autres FAI ?) puis repackagé pour NC…

    En tout cas la démarche avec Zataz était la bonne :)

  3. Bonjour,

    J’ai une box sfr/numéricâble récente et à priori le SSL est activé sur l’interface d’administration.

    Mais du coup il est impossible d’ouvrir le port 443 sur la box, j’ai testé plusieurs fois sur différentes IP locales et même en DMZ et rien y fait. Le port 443 semble pris par l’interface web de la box alors que sur une box plus ancienne, le SSL n’y est pas et le port s’ouvre correctement en ajoutant une règle dans le NAT…

    Auriez-vous une idée de comment arrêter le SSL pour l’interface d’administration ?

    Par avance merci…

    1. Intéressant : ça voudrait donc dire que certaines box permettent de faire du HTTPS (probablement les plus récentes), et pas d’autres.
      Effectivement, si le port 443 est déjà utilisé par l’interface d’administration à distance, il n’est plus disponible pour autre chose.

      Sur la box que j’ai pu tester (qui ne fait pas de HTTPS), on peut choisir le port d’écoute (dans Sécurité -> Paramètres avancés -> Accès à distance). On peut aussi y désactiver complètement l’administration à distance, ce qui est une solution radicale (ça n’empêche bien sûr pas l’administration depuis le réseau local).
      Mais je n’ai pas accès à une box plus récente pour savoir ce qui y serait différent

  4. bonjour
    une question j ai la box sfr nv6
    j’aimerai pouvoir activer ou désactiver le filtrage mac pour mes enfants lorsque je suis au travail
    bien sur j y ai bien accès via mon téléphone lorsque je suis chez moi mais au travail je n’y ai plus accès , j’ai utilisé une adresse ddns.net ,configuré dans la box qui se met bien à jour , mais toujours pas accès à mon interface box , existe t il une solution s’il vous plait ?
    marie
    cordialement

    1. Il vaudrait probablement mieux contacter le support de votre fournisseur d’accès, ou poster votre question sur un forum dédié à cela.

  5. Bonjour,

    je ne suis pas un spécialiste réseau mais peut-être accepterez vous de m’ aider ou me renseigner.
    Voilà mon problème : je ne peux plus accéder à l’ interface modem de mon modem (192.168.0.1)numericable « la Box ». Ou plus exactement j’ ai un message un peu flippant qui me dit : « votre connexion n’ est pas privée….il se peut que des pirates soit en train de dérober des informations sur le site 192.168.0.1…NET::ERR_CERT_AUTHORITY_INVALID » venant de google si je suis sur chrome, ou encore « Le certificat de sécurité de ce site web présente problème….Cela signifie que quelqu’un essaye de vous induire en erreur ou de voler les informations que vous envoyez au serveur. Vous devez fermer ce site immédiatement. » quand je suis sur le navigateur microsoft edge.
    En recherchant des infos sur le net je tombe sur votre article fort interessant, et me voilà à vous demander de l’ aide. Je voulais faire des opérations très simple comme utiliser le radar wifi pour changer de canal ou ouvrir un port…..Le sav numericable n’ a pas d’ idée sur le problème……et me propose d’amener ma box dans un magasin à des bornes de chez moi…..ce qui me gène un peu étant donné que je n’ ai aucun autre problème.
    Du coup je flippe un peu et je n’ ose pas accéder au site malgré l’ option présente d’ y accéder malgré tout. Qu’ en est il exactement ? Puis je y accéder malgré tout sans crainte ? C’ est le seul site qui me renvoi ces message à l’ accès….aucun problème sur aucun autre site.J’ai essayer en désactivant avast mais rien n’ y fait….
    D’ avance merci pour votre aide et votre attention , désolé pour le pavé (surement un peu maladroit dans les explications…mais je ne suis pas un expert).
    Christophe

    1. Le problème est sûrement dû au fait que le navigateur effectue maintenant une vérification de validité du certificat embarqué dans la Box et comme se sont généralement des certificats auto-signés il est pas content.

      1. Je constate la même chose depuis que j’ai changé de modem en passant chez RED by SFR (modem Sagem F@st 3284 DC).
        Je suppose qu’ils ont (en partie) pris en compte la quatrième faille que je signalais, en activant du chiffrement HTTPS sur l’interface d’administration.
        Sauf que, comme le dit Dodutils, le certificat qu’ils ont mis en place n’est pas accepté nativement par les navigateurs, ce qui génère cet avertissement.

        D’autres personnes constatent la même chose : http://communaute.red-by-sfr.fr/t5/RED-Fibre-au-quotidien/Acc%C3%A8s-au-modem-non-s%C3%A9curis%C3%A9/m-p/80025

        Pour Christophe, vous pouvez probablement accepter l’exception de sécurité dans votre navigateur. C’est ce que j’ai fait. C’est vrai qu’il y a un risque d’attaque MITM, sur le principe. Mais c’est toujours mieux que de ne pas avoir de HTTPS du tout. Et puis, a-t-on le choix? Si on ne l’accepte pas, on n’accède pas à l’interface d’administration.
        En tous cas, ça n’est probablement pas un problème matériel : pas la peine de ramener la box.

        Si je trouve un moment, ça mériterait un autre article parce que le certificat SSL et l’algorithme de chiffrement sont parmi les moins efficaces que j’ai eu l’occasion de voir : note de 3.3/10 d’après l’extension Firefox SSleuth, contre 9 ou 10/10 pour la plupart des sites web

    2. C sans danger (en local), c pour pousser à la consommation les éditeurs de sites webs de certificats SSL forts chères qui sont une rentes extrèmements juteuses pour la finance …

  6. Bonjour,

    un grand merci pour vos lumières.
    Je vais accéder à l’ interface malgré tout, donc…….
    Je veux simplement comme dit plus tôt, utiliser le radar wifi pour voir quels canaux sont encombrés, l’ immeuble que j’ habite étant (apparement) bourrés de réseaux wifi……
    Je voulais aussi ouvrir des ports pour mon gamin qui ne peut pas jouer a son GTA5 en ligne, sans avoir des déconnexions et autres erreurs réseaux sur sa console, mais apparement les joueurs de ce jeu étant chez numericable ont quasi tous ce problème bizarre….. De plus je doute de l’ utilité de mon action la console utilisant l’ UPNP….
    Voilà pour la petite histoire….:D
    Merci encore pour votre aide.

    1. Pour un particulier, se connecter à sa box sur son IP privée depuis la connexion internet ne pose aucun problème même en HTTP donc le fait que le navigateur ne soit « pas cotent » ne pose vraiment aucun soucis tu peux te balader sur ta box sans risque.

Répondre à mossroy Annuler la réponse

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *