Cette semaine, des informations ont fait état d'une vulnérabilité critique dans le micrologiciel de certains appareils basés sur HiSilicon et utilisant un logiciel de Xiongmai, notamment des enregistreurs vidéo en réseau, des caméras IP et des enregistreurs vidéo numériques. HiSilicon est un fabricant de "systèmes sur puce" (ou SoC), et certains de ses produits sont destinés à être utilisés dans des équipements vidéo IP. La vulnérabilité a été découverte par Vladislav Yarmak, qui la qualifie de "porte dérobée". Son rapport explique comment les appareils activent un serveur telnet lorsqu'ils reçoivent un "coup secret" envoyé sur le port 9530/tcp. M. Yarmak a procédé à une rétro-ingénierie du micrologiciel et a découvert comment activer la porte dérobée.
À l'adresse Censys, notre ensemble de données étendu pour les entreprises, l'Universal Internet Data Set (UIDS), analyse le port 9530 depuis un certain temps et a trouvé 188 989 hôtes avec ce port ouvert, bien que la plupart d'entre eux soient des serveurs HTTP et d'autres protocoles bien connus, y compris SSH. Suite au rapport de Yarmak, nous avons effectué un balayage plus spécifique pour rechercher le service vulnérable de HiSilicon au niveau mondial. En utilisant l'infrastructure de balayage Censys , nous avons trouvé 9362 hôtes écoutant sur 9530/tcp qui utilisent le protocole HiSilicon.
Géographiquement, les deux pays les plus populaires pour ces appareils sont Taiwan et le Vietnam, suivis par le Brésil, la Turquie et d'autres pays.
Le port 9530 n'est qu'un des 1000 ports que nous analysons régulièrement, ce qui nous permet d'explorer les autres ports ouverts sur ces hôtes. Le service RTSP (protocole de diffusion en temps réel) sur 554/tcp domine, ce qui est normal pour un système de vidéo sur IP. Sur les 137 hôtes que nous avons analysés, 100 avaient le service RTSP à l'écoute sur le port 554, 50 avaient le service HTTP ouvert sur le port 80 et 17 avaient le port 9527 ouvert.
Autres vulnérabilités
M. Yarnak décrit comment les appareils utilisent un protocole défi-réponse pour activer la porte dérobée : le serveur envoie un numéro aléatoire à huit chiffres et demande au client de répondre avec ce numéro crypté à l'aide d'une clé prépartagée intégrée dans le micrologiciel.
En examinant un ensemble de valeurs "aléatoires" envoyées par les hôtes réactifs, nous avons remarqué qu'elles sont dominées par une seule valeur, plusieurs autres valeurs apparaissant également de manière répétée. Le graphique ci-dessous montre les dix valeurs les plus courantes, classées par fréquence - notez l'échelle logarithmique sur l'axe vertical :
Il est clair que ces valeurs ne sont même pas aléatoires ! La première barre montre que 8759 des 9362 valeurs "aléatoires" sont identiques.
Après enquête, il semble qu'il y ait deux familles distinctes d'hôtes, chacune présentant une faille intéressante dans le générateur de nombres pseudo-aléatoires (PRNG) :
- La plupart des hôtes semblent utiliser une graine codée en dur pour le PRNG, qui produit une séquence fixe, probablement redémarrée à chaque fois que l'appareil démarre. La grande majorité des appareils n'ayant jamais été sondés auparavant, ils utilisent tous la même valeur de défi. Un attaquant qui observerait la réponse correcte pour cette valeur pourrait la rejouer à tous les autres appareils qui sont dans le même état PRNG.
- Un plus petit nombre d'hôtes semblent utiliser un PRNG basé sur le temps qui est alimenté par le temps actuel, en secondes. Cela permet de rejouer les réponses aux défis d'un appareil aux autres dans un court intervalle de temps (plus d'une seconde, car les horloges ne sont pas toutes synchronisées).
Bien sûr, grâce aux failles déjà divulguées par Yarnak, les dispositifs peuvent être exploités sans tirer parti de ces vulnérabilités PRNG - la clé prépartagée utilisée pour créer les réponses aux défis est codée en dur dans le micrologiciel et facile à extraire. Il s'agit néanmoins d'un exemple intéressant de faiblesse en profondeur : une implémentation qui présente un très mauvais comportement en matière de sécurité, comme la présence d'une porte dérobée, est susceptible de présenter d'autres failles de sécurité importantes, qui pourraient indépendamment fournir aux attaquants un moyen d'entrer dans le système.
Les failles de sécurité telles que celles découvertes dans le système SoC de HiSilicon sont rarement isolées ; elles représentent généralement des failles systémiques dans la conception et la mise en œuvre de l'ingénierie. Il n'est pas certain que la faille trouvée ait été conçue comme une porte dérobée malveillante, mais le risque d'exploitation malveillante a certainement été aggravé par la négligence sous la forme d'informations d'identification codées en dur et d'une cryptographie défaillante. Malheureusement, les failles de ce type sont trop fréquentes dans les dispositifs embarqués et mettent en danger des millions de consommateurs et d'organisations.
Pour en savoir plus sur Censys et voir nos outils en action, rendez-vous sur www.censys.io, et suivez-nous sur @censysio.
