Une caméra de vidéosurveillance qui envoie les données à la mauvaise personne !

Sans surprise, voici une nouvelle histoire de bugs au niveau d’une “caméra de vidéosurveillance“, à peine deux semaines après notre précédent article.

NB : Comme nous l’avions noté à l’époque, les bons vieux bugs au niveau de webcams sont une chose, mais les vulnérabilités dans des systèmes de vidéosurveillance, sensés améliorer la sécurité en sont une autre.

La dernière fois, le problème était une combinaison de trois bugs différents, chacun d’entre eux plutôt inoffensif en les considérant séparément, mais qui pouvaient être assemblés pour aboutir à un exploit critique.

Au pire, ce trio de bugs, dans ce cas précis, aurait pu permettre à n’importe qui sur internet de pénétrer au sein de votre réseau à volonté, via l’un de vos équipements de sécurité.

Dans l’histoire d’aujourd’hui, cependant, les cybercriminels n’ont pas forcé l’accès à la caméra de vidéosurveillance et voler des données à partir de cette dernière.  Au lieu de cela, la caméra a uploadé délibérément une série de données, mais a choisi la mauvaise personne à qui les envoyer.

En fait, la personne à qui les données vidéo ont été envoyées par erreur …

… était un employé de la BBC, en week-end chez lui, en train de se reposer tranquillement.

Voici donc la fascinante histoire d’une fuite de données, lesquelles ont été envoyées directement au niveau de votre application !

Que s’est-il passé ?

Si vous pensez aux systèmes de sécurité disponibles à l’époque, vous vous demandez probablement quel était l’intérêt, pour une caméra de vidéosurveillance, de transmettre des données à une application.  Eh bien, de nos jours, les systèmes de surveillance ont beaucoup changé.

Les caméras de vidéosurveillance ne sont pas de simples équipements sans fil de nos jours, mais ils sont aussi souvent aussi sans logiciel et sans serveur !

A proprement parler, la caméra a besoin d’un serveur auquel se connecter, et ce dernier a besoin d’un logiciel spécifique pour gérer les uploads, mais le serveur et le logiciel peuvent être hébergés dans le cloud.

En tant que propriétaire de cette caméra de vidéosurveillance, vous n’avez plus besoin de configurer votre propre matériel ou logiciel.

En effet, vous n’avez besoin que de la caméra elle-même, d’une connexion internet et d’un navigateur web (ou d’une application de navigation sur votre téléphone) pour vous connecter au site web du fabriquant de la caméra en question.

Les serveurs du fabriquant se chargent de collecter les données, de les traiter à la recherche d’anomalies et d’envoyer des alertes à votre navigateur ou à votre téléphone si un événement suspect venait à se produire …

… et il faut juste espérer qu’ils n’envoient pas vos alertes à quelqu’un d’autre par erreur, comme cela s’est produit dans notre cas.

Qu’est ce qui n’a pas fonctionné ?

Selon la BBC, Swann a décrit l’erreur comme suit :

Une erreur humaine a permis à deux caméras d’être fabriquées avec la même clé de sécurité reprenant le standard bancaire, laquelle sécurise toutes les communications avec son propriétaire. Cela s’est produit après que [la famille] ait connecté la caméra jumelle à son réseau et ignoré l’avertissement qui disait : “la caméra est déjà jumelée avec un compte”, laissant alors la caméra en marche.

Cette explication est plausible, mais elle n’apporte aucune conclusion à cet incident, sous-entendant ainsi que le problème peut facilement se reproduire. En effet, est-il réaliste de demander à un humain de vérifier une clé cryptographique, telle que 3c8c0279­dd24f6d7­c07a00db­30767ec4, en la comparant à une liste de toutes les clés utilisées sur tous les appareils précédents ?

Supposons que la clé dont nous parlons ici soit une paire de clés publique/privée, permettant aux serveurs du fabriquant d’obtenir une copie de la clé publique afin de valider l’envoi de chaque bloc de données de la caméra, et cette dernière conserve la clé privée, devenant ainsi le seul et unique appareil pouvant signer du contenu avec cette clé.

Pourquoi ne pas permettre à la caméra de vidéosurveillance de générer une nouvelle paire de clés lors de sa première configuration (ou lors d’une réinitialisation usine), garantissant ainsi que la clé privée n’existe que sur la caméra en question et que la paire de clés soit toujours unique ?

Certes, il est facile de faire une erreur cryptographique lorsque vous programmez un objet connecté (IoT), dans le but de générer une nouvelle paire de clés aléatoires, car les nombres aléatoires peuvent être difficiles à générer avec un logiciel au niveau d’équipements intégrés.

Remarque : De nombreux générateurs de nombres pseudo-aléatoires reposent sur une combinaison de données variables telles que l’heure de la journée, le nombre de millisecondes écoulées depuis la mise sous tension de l’ordinateur ou la distance parcourue par la souris au cours des 30 dernières secondes, afin de réduire la prévisibilité de l’algorithme. Ce processus est connu dans le jargon informatique sous le nom d’entropie croissante. Sur les équipements intégrés, fraîchement déballés, il n’existe pas de souris à surveiller, et l’horloge commence toujours par afficher zéro (sur les systèmes Linux, le zéro signifie généralement minuit le 1er janvier 1970), et vous pouvez deviner en quelques secondes de quelle manière le logiciel d’installation initial générera les clés cryptographiques. Cela signifie que vous devez faire très attention à ne pas générer de l’”aléatoire prévisible” lors de la programmation cryptographique minimaliste du hardware.  

Néanmoins, avec un soin et une attention particulières, il est possible de s’assurer que chaque appareil que vous vendez sera automatiquement enregistré avec vos services cloud. Apple, par exemple, peut distinguer de manière filable tous ces iPhones les uns des autres, et ce même s’il en a vendu plus d’un milliard !

Cet incident peut-il se reproduire ?

La BBC a signalé un deuxième cas au Royaume-Uni, concernant un système de sécurité Swann envoyant les données d’un client à un autre, plus précisément un couple de Leicestershire, en Angleterre, qui a commencé à recevoir des images d’un pub qu’il ne connaissait pas !

De manière amusante (bien que cela prouve que même des images basiques et inoffensives peuvent nuire à votre vie privée), le couple a réussi à identifier le pub concerné !

Il s’est avéré que ce pub se situait près de chez eux, alors ils s’y sont rendus, et dans un esprit taquin, ont pris un selfie en utilisant la caméra du pub !

Great to meet the manager @newtownlinford and share our concerns that @swannsecurity remote access CCTV system is giving us images from his cameras in place of our own. Bizarre to be able to take a selfie using someone else’s CCTV camera pic.twitter.com/fTgmAVoPle

— The Obscure Brewer (@Battwave) 3 juin 2018

Quoi faire ?

Espérons que Swann parvienne à identifier les problèmes dans son workflow de fabrication rendant possible ce genre de “caméra sosie” …

… et les élimine.

À l’heure actuelle, l’entreprise ne semble pas très convaincante dans ses réponses à ce qui semble être est un problème inhabituel, voire troublant, de violation de données.

Billet inspiré de OMG! I just received someone else’s security camera footage!, sur Sophos nakedsecurity.