Routeurs SoHo troués by design

Actualités - Réseau - Posté on 27 Nov 2015 at 5:40 par cnis-mag
crédit : Ross Catrow

crédit : Ross Catrow

Cette semaine, c’est la fête des routeurs.

Déjà, la semaine passée, la publication de l’étude d’Andrei Costin, Aurélien Francillon et Apostolis Zarras (Eurecom, U de Bochum) avait jeté comme un doute sur le sérieux des fabricants de routeurs SoHo et périphériques de l’IoT. Cette fois, c’est au tour de Sec Consult de révéler que les équipementiers jouent au « couper-coller » de clefs SSH et de certificats SSL, cette pratique étant même commune à des appareils de marques différentes. C’est potentiellement la porte ouverte à toutes les intrusions et attaques distantes, ainsi qu’au vol d’information par « man in the middle ».

A l’origine de cette « communauté de certificats par défaut », les plateformes de développement fournies par les fabricants de composants, qui sont utilisés « tel que » par quasiment tous les producteurs de routeurs. Les impératifs de « time to market » fait le reste, poussant les équipes de développement à n’utiliser que les cotes « prêt à porter » fournis en OEM, sans y effectuer la moindre modification.

crédit : Jean-Etienne Minh-Duy Poirrier

crédit : Jean-Etienne Minh-Duy Poirrier

Sur un total de près de 4000 systèmes embarqués provenant des catalogues de 70 vendeurs, les « techniciens légistes » de Sec Consult ont recensé 580 clefs privées uniques, lesquelles, après une énergique campagne de scan sur Internet, ont permis de découvrir les clefs privées de plus de 9% des serveurs HTTPS rencontrés au fil du balayage (soit près de 3,2 millions de serveurs hôtes utilisant un total de 150 certificats) et les clefs de 6% des serveurs ssh accessibles (80 clefs, 900 000 services accessibles). Et l’étude de conclure qu’un peu moins de la moitié des 580 clefs privées récupérées était en service effectif avec accès sur le réseau public.

Tout aussi édifiantes sont les statistiques inter-marques. Ainsi, un certificat issu du SDK Broadcom a été retrouvé sur des équipements Actiontec, Aztech, Comtrend, Innatech, Linksys, Smart RG, Zhone et ZyXEL. Un autre, ayant pour origine un SDK Texas Instrument, était également partagé par des appareils Aztech, Bewan, Observa Telecom, NetComm Wireless, Zhone, ZTE et ZyXEL.

crédit : Matt J Newman

crédit : Matt J Newman

Dans quelle mesure de telles mauvaises pratiques peuvent-elles mettre en péril les usagers ? L’étude énumère une sinistre ribambelle de risques : « Impersonation, man-in-the-middle or passive decryption attacks ». Il s’agit toutefois d’une majorité de produits destinés à un marché grand public, présentant peu d’espérance de gain aux yeux d’éventuels truands. Ce peut être en revanche un risque de fuite d’informations lorsqu’une TPE est visée par un concurrent indélicat, ou servir de moyen d’intrusion et d’écoute pour un service de police cherchant à tracer l’activité de suspects déjà repérés. De toute manière, ces trous de sécurité ont de fortes chances d’appartenir à la catégorie des défauts persistants. Principalement en raison de la complexité des mesures de contournement (changer la clef SSH et le certificat X.509 de l’appareil… pas franchement une opération « grand public »), mais également parce que bon nombre de ces routeurs sont livrés par des opérateurs, dans le cadre d’un abonnement ADSL, avec des firmware verrouillés sur lequel l’usager n’a que très peu de pouvoir d’intervention. Sans compter le rythme de mise à jour des correctifs des FAI dont la réputation n’est pas le plus effréné …

Laisser une réponse