L’une des dernières vulnérabilités des IP phones Cisco (CSCuc83860) a été longuement commentée sur le Web au travers de nombreux articles. Je vous recommande pour ma part d’écouter la conférence de l’auteur. Beaucoup se sont focalisés sur le fait qu’il était possible d’écouter des conversations. La chose en elle même n’a rien d’une nouveauté et revient à la pose d’un micro tant que l’accès physique est nécessaire. Une simple modernisation du concept en quelque sorte.
voir sa machine hackée est une opportunité
Je trouve cependant que cette analyse fait injure au chercheur qui a découvert les vulnérabilités utilisées pour arriver à ce résultat. En effet, la démonstration n’avait pour but que de montrer qu’il était possible de modifier le comportement d’origine du firmware. Cela laisse bien d’autres possibilités non exploitées et bizarrement non considérées. A la poubelle les grands dogmes sur l’inviolabilité et le durcissement constructeur.
Retour à la réalité. Ce n’est ni meilleur ni pire et, quelque part, cela est rassurant. Cette démonstration ouvrira peut être la voie à d’autres chercheurs qui aideront à sécuriser cet élément si important des solutions de communications. Non, le téléphone n’est pas mort et mieux vaut le voir sécurisé dès l’origine.
de quel type de vulnérabilité parle-t-on ?
Par ailleurs, il est intéressant de rappeler que les firmwares des téléphones Cisco semblent basés sur trois souches différentes (à priori, il s’agit de mes conclusions suite à la fréquentation de ces derniers). La liste des téléphones considérés comme vulnérables pointe sans aucun doute la version Cisco Native Unix comme celle posant problème.
Néanmoins, le manque de détail sur la vulnérabilité en elle-même ne permet pas de voir si ce sont les bases du système sous-jacent qui sont fondamentalement en cause, ou des composants Cisco qui pourraient être répliqués en plus modernisés sur les deux autres souches de firmwares.
Dans ce dernier cas, nous risquons de faire face à une nouvelle famille de vulnérabilités qui nous poursuivra pendant encore un certain temps… Autant dire qu’il vaudra mieux avoir un œil attentif sur les prochaines libérations de firmwares et essayer de lire entre les lignes des releases notes pour percevoir s’il y a quelque chose de commun.
à vulnérabilité complexe, réparation profonde ?
Quoiqu’il en soit, la durée nécessaire pour la publication de la correction définitive montre qu’il s’agit d’un incident sérieux et touchant l’architecture logique du système. Il y a tout de même de nombreux mots désagréables dans la présentation de l’auteur de cette vulnérabilité : syscall, kernell, arbitrary code execution… Inquiétant ? Dans un sens oui.
Cependant, la réflexion qui me vient est la suivante : la sophistication des vulnérabilités n’est-elle pas un signe de maturité ? En effet, nous sortons ici des traditionnels paquets SIP mal gérés ou des erreurs de développement Web pour toucher au cœur du système.
J’espère donc que nous aurons l’occasion de voir d’autres vulnérabilités de ce niveau. Même si elles nous compliquent la vie au niveau opérationnel (analyse, suivi, gestion de parc, etc.), elles seront le signe d’un réel durcissement, d’une maturité enfin trouvée pour les piles SIP et d’un niveau de confiance envers l’éditeur qui finalement (et paradoxalement) ne pourrait que remonter.
Bref, espérons que beaucoup de chercheurs de ce niveau se pencheront sur le cas de la téléphonie.
Cedric
crédit photo : © Mopic - Fotolia.com
Membre actif de la communauté sécurité d'orange Business Services, je suis aujourd'hui en charge, au sein de l'équipe marketing « sécurité », de la bonne prise en compte de la sécurité dans nos offres traitant des communications sur IP, et cela du mode cloud à l'intégré classique. Un large périmètre pour rencontrer des problématiques complexes sur le plan technique comme sur le plan organisationnel. Bref, un océan de motivation pour toute personne qui marche au challenge et à l'envie d'apprendre.