Quels risques prenons-nous lors de l'installation du système «maison intelligente»? Celui qui pilote les ampoules et une bouilloire depuis l'application sur le smartphone, à l'intérieur du réseau local et à distance. Si la sécurité et la gestion des verrous sont liées à un système intelligent (comme dans le cas d'Amazon Key), alors il est clair lesquels. Sinon, alors théoriquement, il est possible d'imaginer le danger d'une panne logicielle d'une machine à café avec un incendie ultérieur. Mais il vaut mieux ne pas fantasmer, mais savoir avec certitude.
Des spécialistes de l'équipe ICS CERT de Kaspersky Lab ont décidé de réaliser un test sur le terrain de la maison intelligente d'un des employés de l'entreprise (
actualités ,
article de blog ,
article technique). Le piratage a réussi: la cafetière n'a pas souffert, mais il a été possible de prendre le contrôle du système, bien qu'avec quelques hypothèses (tout à fait réalistes) pendant l'expérience. L'une des conséquences désagréables de cette attaque a été la fuite de données personnelles: les coordonnées de la maison et, malheureusement, la géolocalisation du smartphone. Cependant, l'expérience s'est terminée sur une note positive: le fabricant du système de maison intelligente a réussi à éliminer les vulnérabilités.
Interprétation artistique des conséquences du piratageDans un article technique, beaucoup d'espace est consacré à des points relativement ennuyeux mais importants: ce qui n'a PAS réussi à pirater et comment le système de maison intelligente a été analysé pour détecter les vulnérabilités potentielles. Avant de commencer l'expérience, les chercheurs connaissaient déjà le fabricant du système. Il s'est avéré être
Fibaro , qui produit un assortiment de ses propres appareils pour une maison intelligente moderne, ainsi que l'intégration avec des appareils tiers. De plus, le propriétaire a donné un indice important - une adresse IP permanente pour accéder au panneau d'administration. Soit dit en passant, Fibaro lui-même ne recommande pas d'ouvrir l'accès au contrôleur via IP - uniquement via le système cloud. Dans cette expérience, cette échappatoire délibérément laissée par le propriétaire a joué un rôle.
Théoriquement, un tel système peut être attaqué dans trois directions principales: essayez de pirater le périphérique de contrôle d'une manière ou d'une autre, recherchez les vulnérabilités dans la partie cloud du service, ou attaquez les périphériques IoT connectés au contrôleur eux-mêmes. Dans ce dernier cas, il doit être proche d'eux, de sorte que les deux premières options semblent plus prometteuses.
L'étape suivante consiste à analyser le micrologiciel de l'appareil et WebAPI. Habituellement, sur une telle analyse, tout se termine et les nouvelles sortent dans le style "un mot de passe filaire est détecté dans l'appareil." Mais dans le cas de Fibaro, il n'y avait pas de trous de sécurité évidents. Mais des informations utiles ont été reçues sur l'implémentation d'une partie de la logique de contrôle en PHP. Sans autorisation, le contrôleur ne donne que le numéro de série de l'appareil, et pour pirater un morceau de fer, cette information est inutile. Mais, il s'est avéré que cela vous permet de pirater la partie cloud du service.
L'accès au cloud, à son tour, vous permet d'obtenir des sauvegardes de base de données SQLite contenant tous les paramètres de l'appareil sans autorisation et de télécharger les vôtres. Théoriquement, le contournement de l'autorisation a permis (avant de corriger la vulnérabilité) de télécharger des copies de sauvegarde de tous les utilisateurs du système cloud. L'analyse de la base réelle de l'appareil attaqué a permis d'accéder à des informations privées, y compris les coordonnées de la maison et du smartphone sur lequel l'application de contrôle est installée. C'est déjà un problème grave, car (avec certaines limitations), il vous permet de déterminer quand le propriétaire du système n'est pas à la maison.
En outre, la base de données contenait des informations complètes sur les appareils IoT connectés, ainsi qu'un mot de passe pour accéder aux paramètres, mais haché avec l'ajout de «sel». L'analyse du micrologiciel a montré que le «sel» n'est pas aléatoire, mais qu'il est fermement cousu dans l'appareil. Théoriquement, un mot de passe très simple peut être piraté, mais dans ce cas, cela n'a pas fonctionné. La base SQLite contenait également des mots de passe ouverts pour se connecter à d'autres appareils du réseau: si ces mots de passe coïncidaient avec le principal, le contrôleur pourrait également être facilement craqué.
Mais encore une fois, cela n'a pas fonctionné: le propriétaire du système connaissait les recommandations de sécurité de base et n'utilisait pas le même mot de passe pour différents appareils. J'ai donc dû appliquer l'ingénierie sociale. Une vulnérabilité dans le système cloud qui permet d'effectuer un certain nombre d'actions sans autorisation, ne connaissant que le numéro de série de l'appareil (qui est donné «gratuitement» s'il y a accès au panneau d'administration de l'extérieur), a rendu possible le scénario suivant. Une sauvegarde préparée de l'appareil dans lequel le script malveillant a été intégré a été téléchargée sur le «cloud». Un message sur la nécessité de «mettre à jour» l'appareil via les capacités régulières du système cloud a été envoyé au propriétaire (par e-mail et SMS).
Comme le propriétaire du système était au courant de l'expérience, il s'est immédiatement rendu compte que ce n'était pas un vrai patch. Mais en général, il s'agit d'un scénario très réel lorsqu'un utilisateur reçoit un message plausible via un canal de communication familier, donc une copie de sauvegarde a été installée. Un code malveillant a été exécuté avec des droits système en raison d'une erreur dans le code PHP entraînant l'exécution du script bash:
Ici, le paramètre défini par l'utilisateur (dans des conditions normales, même l'administrateur système n'a pas de privilèges de superutilisateur sur le périphérique) entre dans l'argument de la ligne de commande. Une vérification insuffisante des arguments nous a permis d'exécuter du code arbitraire avec les privilèges root et enfin d'obtenir un contrôle total sur le périphérique. En parallèle, la possibilité d'injection SQL a été trouvée, mais non utilisée:
Les chercheurs n'avaient pas l'intention de casser une cafetière dans une vraie maison, ils ont donc changé la mélodie du réveil en "bonjour". Les vulnérabilités mentionnées dans le système cloud et dans le code du contrôleur ont été corrigées. Pour des raisons évidentes, des méthodes spécifiques de contournement de la protection ne sont pas divulguées dans un article technique - afin d'éviter leur utilisation par de vrais attaquants sur des appareils qui n'ont pas encore été mis à jour. Mais dans cette expérience, ce qui est généralement laissé en dehors des gros titres est bien montré dans cette expérience: il existe de nombreuses façons d'enquêter sur la protection des appareils, dont la plupart se terminent par rien. Dans la réalité, le fabricant de l'appareil et son propriétaire ont pu éviter les erreurs de sécurité les plus simples, telles que les mots de passe intégrés et réutilisables. Néanmoins, un nombre suffisant de problèmes ont été identifiés qui pourraient entraîner au moins une fuite de données privées et, dans le pire des cas, contourner les systèmes de sécurité.
Avis de non-responsabilité: les opinions exprimées dans ce recueil ne coïncident pas toujours avec la position officielle de Kaspersky Lab. Chers rédacteurs recommandent généralement de traiter toute opinion avec un scepticisme sain.