Qualys

Security CommunityLa communauté des experts sécuritéen savoir plus

SecurityVibesQualys Community

Left content

Quand le patch censé corriger la backdoor en ajoute une autre

auteur de l'article Jerome Saiz , dans la rubrique Menaces

Commentaires Commentaires fermés sur Quand le patch censé corriger la backdoor en ajoute une autre

En décembre dernier Eloi Vanderbeken, un expert sécurité de la société Synacktiv découvrait une porte dérobée dans le firmware de plusieurs modem-routeurs ADSL des fabricants Cisco, Linksys, NetGear et Diamond. Tous les modèles concernés ont pour point commun d’utiliser la même base technologique produite par le taïwanais Sercomm.

La backdoor permettait d’exécuter des commandes directement sur le routeur, sans authentification, via un port TCP non-standard ouvert en écoute (TCP/32764). Un attaquant pouvait ainsi, par exemple, activer l’interface d’administration à distance ou changer le mot de passe du routeur. Evidemment, l’affaire a fait grand bruit.

Récemment la société Sercomm a livré un nouveau firmware pour les modèles incriminés et la porte dérobée semblait avoir disparu. Mais Eloi Vanderbeken, curieux, s’est penché sur cette nouvelle version afin de contrôler si c’était bien le cas. Et il a rapidement constaté que si, effectivement, la porte dérobée ne répondait plus, le binaire chargé de la mettre en oeuvre existait toujours… et qu’il avait même été amélioré : en réalité des efforts particuliers avaient été faits pour dissimuler la backdoor.

Le binaire attend désormais des paquets d’un ethertype particulier (8888) et dans un format spécifique (type et payload particuliers) pour ouvrir la porte dérobée. Autrement dit un véritable effort a été fait pour éviter que cette backdoor ne puisse être scannée accidentellement en TCP. Mais elle est toujours là, prête à être réactivée par l’envoi de paquets Ethernet spécifiques (en tout cas sur le modèle Netgear DGN1000 testé par Vanderbeken. Elle semble cependant avoir disparue pour de bon sur le Cisco WAP4410N)

Eloi Vanderbeken en conclu qu’il s’agit d’une porte dérobée délibérée, ce que Sercomm ne confirme ni ne réfute : « Nous développons et fabriquons ces produits pour le compte de nos clients, et nous ne pouvons pas commenter les solutions de nos clients« , avance-t-on chez Sercomm France.

Il est à noter cependant que la portée de cette nouvelle backdoor a été considérablement réduite par rapport à la précédente : auparavant exploitable depuis Internet elle n’est désormais accessible que depuis le LAN ou par le fournisseur d’accès à Internet lui-même (car il faut être à un saut de distance du modem-routeur pour manipuler les paquets ethernet nécessaires à l’activation de la backdoor, ce qui est le cas du FAI).

Il semble raisonnable de penser qu’il s’agit ici avant tout d’un accès destiné au support technique, afin de permettre le dépannage ou le test à distance de l’équipement. « Je pense, sans pouvoir le prouver, qu’il s’agit d’une demande des constructeurs afin de se faciliter le support. Mais cela ne se justifie pas, car il existe pour cela d’autres méthodes qui ne mettent pas à mal la sécurité des utilisateurs » , explique Eloi Vanderbeken.

Dans l’hypothèse d’un simple accès de maintenance on comprend que la position de Sercomm était bien délicate : comment conserver l’accès à distance réclamé par ses clients tout en ne prêtant plus le flanc aux accusations de backdoor exploitable depuis Internet ? En en limitant l’accès au LAN (et indirectement au FAI, donc…), ce qui expliquerait la nature des modifications apportées par ce nouveau firmware. Plutôt que « d’ajouter » une nouvelle backdoor, ou la dissimuler, celles-ci viseraient alors surtout à en limiter l’accès.

Mais quoi qu’il en soit la porte dérobée est toujours présente et sa détection est largement plus complexe que la précédente, qui ne nécessitait qu’un simple scanner de port TCP/IP pour en révéler l’existence. Désormais, hormis pour les utilisateurs d’un modem DGN1000 pour lequel un PoC est disponible, Vanderbeken suggère de suivre la route (laborieuse !) qu’il a emprunté : extraire le firmware à l’aide de l’outil binwalk (sans oublier de le recompiler au préalable pour en supprimer le support de gzip qui semble poser un problème dans ce cas particulier…) et désassembler le binaire incriminé afin de confirmer la présence du code chargé d’ouvrir le port en écoute. Bref, ce n’est pas gagné pour le commun des mortels !

Mais au delà de la technique cette affaire pose évidemment la question de la confiance que l’on peut accorder aux firmwares embarqués dans les équipements réseau dont nous dépendons. En dehors de la parole des constructeurs, qu’est-ce qui prouve que les firmwares des équipements réseau installés dans l’entreprise ne contiennent pas de porte dérobée ? Ou, plus pudiquement, d’accès de maintenance dont on a « oublié » d’avertir l’utilisateur ? La question ne date pas d’hier mais elle demeure plus que jamais d’actualité. Après tout si un hacker isolé est en mesure de découvrir une telle porte dérobée à l’occasion des vacances scolaires, n’importe qui peut le faire.

Et si n’importe qui peut y parvenir, pourquoi l’entreprise ne le ferait-elle pas avant qu’un attaquant s’en charge pour elle ?

Il lui faudrait pour cela certainement confier la tâche à des experts externes, car ces codes sont moins accessibles que le commun des binaires : ils sont propriétaires, fermés et leur analyse exige l’extraction de nombreux éléments variés, la manipulation de systèmes de fichiers alternatifs tel SquashFS (pour cela binwalk est précieux !) et le désassemblage d’un ou plusieurs binaires spécifiques choisis dans le lot (à l’aide de l’incontournable IDA, évidemment !)

En outre cette tâche peut difficilement être automatisée : il semble vain d’utiliser par exemple des techniques d’analyse statistique du code ou de rechercher des structures communes permettant la connexion à un socket, tant les faux positifs seraient nombreux. « Mais on peut toujours chercher (automatiquement, ndlr) les binaires utilisant bind / socket et qui ne correspondent pas à des binaires « standards » bien que ça soit très simple à contourner. Mais cela donnerait peut-être une bonne base pour commencer à travailler si un binaire sort du lot… » , précise Eloi Vanderbeken.

Heureusement, même manuelle, la tâche n’est pas forcément insurmontable : dans le cas de la backdoor de Sercomm il n’aura fallu au hacker qu’une journée pour analyser le firmware et découvrir la porte dérobée. En comptant le temps passé à créer la présentation Powerpoint…

Cela peut malgré tout représenter un certain budget : si l’on estime le coût d’un (très) bon expert sécurité capable de faire du reverse engineering à 1500 euros HT par jour et le temps nécessaire à deux jours (afin de prendre en compte des firmwares potentiellement plus complexes que celui d’un modem Netgear), cela coûterait à l’entreprise environ 3000 € HT par équipement à faire analyser (et certes beaucoup plus dans le cas de systèmes complexes tel un routeur de coeur de réseau, par exemple).

Il reste ensuite à évaluer le nombre d’équipements réellement sensibles pour lesquels une backdoor exploitable à distance serait un risque important (pare-feu, VPN, accès distant, routeurs ?) pour être en mesure de mettre un prix face au risque. Dans bien des cas l’on parle a priori ici de quelques dizaines de milliers d’euros seulement.
En outre un tel audit aurait rarement besoin d’être réalisé à chaque mise à jour des firmwares. Mais il serait néanmoins très utile pour établir la confiance initiale…

Enfin, cerise sur le gâteau, la loi autorise même une telle pratique. Selon François Coupez, du cabinet Caprioli & Associés, « non seulement il n’y a pas de loi ou de jurisprudence concernant le reverse engineering de code réalisé à des fins d’audit par celui qui a le droit d’utiliser ledit code (et donc ledit matériel), mais c’est précisément l’inverse : l’article L. 122-6-1 III. du Code de la propriété intellectuelle précise en effet que cette décompilation est possible » . Mieux, même : toujours selon l’avocat la récente Loi de Programmation Militaire, pourtant si décriée par le tout-internet, a renforcé la liberté de l’utilisateur à analyser un code informatique en mentionnant spécifiquement la notion de sécurité. Le texte est d’ailleurs particulièrement clair à ce sujet :

« La personne ayant le droit d’utiliser le logiciel peut sans l’autorisation de l’auteur observer, étudier ou tester le fonctionnement ou la sécurité de ce logiciel afin de déterminer les idées et principes qui sont à la base de n’importe quel élément du logiciel lorsqu’elle effectue toute opération de chargement, d’affichage, d’exécution, de transmission ou de stockage du logiciel qu’elle est en droit d’effectuer »

Ainsi, « même si la licence du logiciel interdisait une telle décompilation, l’utilisateur licite de celui-ci pourrait se prévaloir de cet article de loi pour auditer le code à des fins de sécurité sans avoir à en référer à l’auteur » , rassure François Coupez.

Les firmwares sont un bastion d’opacité dans le SI de l’entreprise. Parce qu’ils sont peu visibles, peu accessibles et souvent complexes, peu d’entre elles ont identifié ce risque et ont pris les mesures nécessaires pour le couvrir. Mais avec la montée en puissance des attaques matérielles (lire par exemple à ce sujet l’infection de BIOS avec mise à l’abris dans un firmware) et dans le climat de suspicion ambiant, il semble étonnant que les firmwares n’attirent pas plus l’attention…

Plus d’informations :


Vous avez aimé cet article?

Cliquez sur le bouton J'AIME ou partagez le avec vos amis!

Notez L'article

Participez ou lancez la discussion!

Les commentaires sont fermés.

Catégories

Étiquettes

Archives

Ce site est une archive des messages à SecurityVibes de Septembre 2000 à Juillet 2014. S'il vous plaît visitez le Qualys Community pour les dernières nouvelles.