Des arroseurs aux motos : Ce que nous avons piraté

En matière de cybersécurité, les tests sont essentiels. Nos pentesters simulent des attaques réelles afin d'identifier les points faibles avant que les criminels ne le fassent. En procédant à une rétro-ingénierie des systèmes et des produits, ils découvrent les failles critiques. Cela permet aux clients d'avoir les informations nécessaires pour résoudre les problèmes et réduire les risques.

Dans cet article, nous décomposons quatre projets en trois questions : Pourquoi l'avons-nous piraté ? Qu'avons-nous trouvé ? Quel a été l'impact ?

PROJET

Contrôleur d'arrosage avec support BLE et applications mobiles

préoccupations du client

Avec l'ajout de la prise en charge de Bluetooth Low Energy (BLE), les contrôleurs mis à jour du client ont été conçus pour permettre aux utilisateurs de contrôler le système à distance via des applications mobiles. Le client devait s'assurer que cette nouvelle connectivité n'introduisait pas de vulnérabilités, qui pourraient potentiellement exposer les appareils des clients à un accès non autorisé.

LA MISSION : POURQUOI NOUS L'AVONS PIRATÉE

Le client intégrait BLE dans son contrôleur d'arrosage IoT de nouvelle génération. BLE est une technologie courante dans les appareils IoT, mais c'est aussi une cible fréquente pour les pirates informatiques en raison de ses mauvaises configurations de sécurité.

Le client avait besoin de s'assurer que la nouvelle connectivité n'ouvrait pas aux attaquants des vecteurs d'attaque pour compromettre les appareils, manipuler les paramètres de l'arrosage ou obtenir un accès non autorisé aux réseaux d'utilisateurs. Notre objectif était de repérer rapidement toute faille de sécurité, afin de garantir que les maisons et les jardins des clients ne soient pas menacés par des cybermenaces.

L'ANALYSE : CE QUE NOUS AVONS TROUVÉ

Nous avons procédé à l'examen de la sécurité à l'aide de deux méthodologies :

• OWASP Top 10 pour les applications mobiles : Évaluation des vulnérabilités de l'application mobile, telles que le stockage de données non sécurisé, la protection insuffisante de la couche de transport et l'authentification inappropriée.
• Test IoT pour la configuration BLE : Examen de la mise en œuvre et de la configuration de BLE pour s'assurer qu'il n'y a pas d'erreurs de configuration courantes telles que l'absence d'authentification ou la transmission de données non cryptées.

AU COURS DES TESTS, NOUS AVONS DÉCOUVERT PLUSIEURS PROBLÈMES CRITIQUES

• Failles de conception dans le processus d'appairage BLE : La faiblesse des mécanismes d'appairage a facilité l'écoute ou l'interférence de la part d'attaquants potentiels.
• Vulnérabilités dans le traitement des données de l'application mobile : Les données sensibles étaient stockées sans chiffrement adéquat, ce qui permettait à un pirate ayant accès à l'appareil de les extraire et de les utiliser à mauvais escient.
• Commandes exposées de l'appareil : Plusieurs commandes BLE utilisées pour contrôler les paramètres de l'arrosage n'étaient pas correctement sécurisées, laissant place à des manipulations non autorisées.

EN REMÉDIANT À CES PROBLÈMES, LE CLIENT A PU

• Sécuriser le Processus d'appairage BLE, en veillant à ce que seuls les utilisateurs légitimes puissent contrôler l'appareil.
• mettre en œuvre des méthodes de stockage et de transmission sécurisées pour les informations sensibles dans les applications mobiles
• verrouiller les commandes de l'appareil, réduisant ainsi la probabilité d'une manipulation malveillante.

En conséquence, les contrôleurs d'arrosage du client pris en charge par BLE étaient non seulement plus sûrs, mais ils offraient également une tranquillité d'esprit aux utilisateurs finaux, qui pouvaient avoir confiance dans la robustesse de leurs systèmes intelligents face aux cybermenaces potentielles. Ces tests de sécurité proactifs ont permis au client d'aller sur le marché en toute confiance, transformant un risque potentiel en un avantage concurrentiel.

PROJET

Rétro-ingénierie du système de contrôle de l'allumage (ICS) d'une moto

PRÉOCCUPATIONS DU CLIENT

Le système de contrôle de l'allumage (ICS) de la moto gouverne la synchronisation de l'étincelle pour allumer le mélange air-carburant du moteur. Le client souhaitait savoir si le système pouvait faire l'objet d'une rétro-ingénierie afin de modifier les performances de la moto, par exemple en augmentant la puissance en ajustant le calage de l'étincelle ou en modifiant les limites de régime.

LA MISSION : POURQUOI NOUS L'AVONS PIRATÉ

Le système de contrôle de l'allumage de cette moto, une Suzuki Katana, faisait l'objet d'une étude en vue d'une éventuelle optimisation des performances. Le système était intégré dans un boîtier scellé et contrôlait la synchronisation des étincelles d'allumage par l'intermédiaire d'un microcontrôleur. Le client souhaitait procéder à une rétro-ingénierie du système afin de modifier les performances du moteur. L'objectif était d'en savoir plus sur l'ICS et de déterminer s'il pouvait être reprogrammé pour augmenter les performances sans compromettre la fiabilité.

LA DÉCOMPOSITION : CE QUE NOUS AVONS TROUVÉ

Nous avons abordé le processus d'ingénierie inverse de la manière suivante :

• Déconstruction du matériel : Nous avons tenté d'accéder physiquement à la carte de circuits imprimés du système de commande d'allumage scellé et de la sonder afin de comprendre son fonctionnement.
• Identification du microcontrôleur : Identification du microcontrôleur : identification du microcontrôleur qui gouverne le système, malgré les enjeux liés au scellement de protection, et recherche d'interfaces de débogage ou de reprogrammation.

AU COURS DES ESSAIS, NOUS AVONS DÉCOUVERT PLUSIEURS PROBLÈMES CRITIQUES

• Mécanisme de protection du scellant : Le système a été lourdement scellé avec des matériaux conçus pour décourager la rétro-ingénierie, ce qui a entraîné des dommages lorsque l'on a essayé d'accéder à la carte.
• Pas d'interface de débogage : Malgré des tests approfondis des interfaces potentielles, il n'y avait pas de méthode directe pour reprogrammer le microcontrôleur ou extraire le micrologiciel.
• Accessibilité limitée au micrologiciel : Le microcontrôleur utilisait une ROM masquée, ce qui signifie que le micrologiciel était codé en dur et ne pouvait être extrait sans recourir à des techniques avancées telles que le décapping.

EN REMÉDIANT À CES PROBLÈMES, LE CLIENT A PU

• Orienter l'approche vers les tests en boîte noire : En simulant les entrées et en mesurant les sorties (par exemple, la position de l'arbre à cames et le papillon des gaz), le client a réussi à déduire les algorithmes de calage de l'allumage.
• Construire un simulateur personnalisé : Le client a créé un système de microcontrôleur personnalisé pour imiter le comportement de l'ICS et explorer les possibilités de réglage des performances.

Le client a ainsi pu mieux comprendre comment l'ICS contrôlait les performances du moteur et a pu commencer à construire un nouveau système programmable pour améliorer la puissance et l'efficacité. Bien qu'une reprogrammation directe n'ait pas été possible, l'approche de la boîte noire a fourni des indications précieuses sur la manière de modifier le calage de l'allumage pour améliorer les performances.

PROJET

Sécurité des dispositifs médicaux

PRÉOCCUPATIONS DU CLIENT

Les dispositifs médicaux automatisés qui se connectent aux réseaux hospitaliers et aux services cloud présentent des défis uniques en matière de sécurité. Dans ce cas particulier, la cible était un système embarqué qui permettait au personnel de l'hôpital de s'authentifier sur des postes de travail au moyen de Bluetooth Low Energy qui effectuait une détection de présence active et un suivi de l'utilisateur. Le client craignait que des vulnérabilités potentielles ne permettent un contrôle non autorisé de l'appareil ou du poste de travail, la falsification des données ou l'exposition d'informations sensibles sur les patients. L'objectif était d'évaluer la résilience de l'appareil face aux cyberattaques et de garantir la conformité avec les réglementations du secteur.

LA MISSION : POURQUOI NOUS L'AVONS PIRATÉ

Bureau Veritas Cybersecurity a été chargé d'évaluer les logiciels, le matériel intégré, les connexions réseau et les pratiques de gestion des données de l'appareil médical. La mission consistait à identifier les failles de sécurité susceptibles d'être exploitées pour compromettre la sécurité des patients ou perturber les procédures médicales.

L'ANALYSE : CE QUE NOUS AVONS TROUVÉ

Notre évaluation de la sécurité a comporté les éléments suivants :

• Test de vulnérabilité du réseau : Évaluation des connexions aux réseaux de l'hôpital et du cloud pour détecter les faiblesses qui pourraient permettre un accès non autorisé.
• Analyse de l'intégrité des données : Évaluation de la manière dont les données des patients sont stockées et transmises, en mettant l'accent sur le cryptage et la prévention de la falsification.
• Simulation d'attaques matérielles : Ubertooth One et NRF51 ont été utilisés pour renifler le trafic BLE entre les composants cibles du matériel et de l'application du client. Gatttool a été utilisé pour découvrir, lire et écrire sur les caractéristiques BLE disponibles.
• Simulation du contrôle des appareils : Simulation de scénarios d'attaque potentiels pour vérifier si le contrôle à distance de l'appareil était possible.

les principales conclusions sont les suivantes

• Cryptage des données insuffisant : Il a été constaté que certaines transmissions de données n'étaient pas suffisamment protégées, ce qui présentait un risque d'interception et de falsification.
• Caractéristiques BLE non restreintes : Des paramètres Bluetooth Low Energy (BLE) non sécurisés ont rendu le suivi de proximité vulnérable à la manipulation, ce qui a permis une surveillance non autorisée de l'activité de l'utilisateur et une interférence avec les opérations prévues.
• Authentification défectueuse : Les interactions et les protocoles entre les composants n'étaient pas sûrs, ce qui aurait pu permettre une attaque par brouillage qui aurait contourné l'authentification du système.
• Attaques de type "Piggybacking" : Le MITM sur la connexion Bluetooth a permis de capturer les UUID, MAC et autres valeurs pour les ajouter à une autre application sans consentement.
• Chemins d'accès non autorisés : Des voies d'accès non autorisées ont été identifiées qui pourraient permettre à des attaquants de prendre le contrôle de l'appareil ou d'accéder aux données des patients.
• Lacunes réglementaires : Mise en évidence des domaines dans lesquels les mesures de sécurité ne sont pas conformes aux réglementations du secteur, ce qui a un impact sur la conformité.

EN REMÉDIANT À CES PROBLÈMES, LE CLIENT A PU

• Améliorer le cryptage des données : Mettre en œuvre des normes de cryptage complètes pour protéger les données des patients.
• Sécuriser l'accès au réseau : Fermer les voies d'accès non autorisées et renforcer les mesures d'authentification.
• Assurer la conformité : Alignez les protocoles de sécurité des dispositifs sur les normes de l'industrie afin de répondre aux exigences réglementaires.

Ces améliorations ont considérablement renforcé la sécurité et la fiabilité du dispositif médical, garantissant ainsi la sécurité des patients et la protection des données.

PROJET

Aspirateur robot

PRÉOCCUPATIONS DU CLIENT

Les aspirateurs robots connectés présentent des risques liés à l'exposition des données et à l'utilisation abusive des appareils. Dans ce cas, l'appareil utilisait le Bluetooth et des services basés sur le cloud, avec des fonctions de contrôle liées à une application mobile. Le fabricant souhaitait savoir si des pirates pouvaient utiliser le système à mauvais escient pour suivre les mouvements, manipuler les actions de l'appareil ou extraire des données sensibles. L'objectif était d'évaluer les risques techniques et d'identifier les points faibles de la conception.

LA MISSION : POURQUOI NOUS L'AVONS PIRATÉ

Il nous a été demandé d'examiner l'appareil à tous les niveaux : matériel, micrologiciel, applications mobiles, protocoles de communication et stockage local. La mission consistait à découvrir les problèmes susceptibles d'être exploités pour accéder aux données ou prendre le contrôle de l'appareil.

LA PANNE : CE QUE NOUS AVONS TROUVÉ

Notre équipe a utilisé plusieurs outils, des scripts personnalisés et des méthodes de test éprouvées pour examiner l'appareil.

Les principales activités ont été les suivantes

• Validation des microprogrammes et des mises à jour : Examen des procédures de mise à jour et vérification de l'absence d'utilisation abusive.
• Test de l'application mobile : Évaluation de la façon dont les utilisateurs interagissent avec l'appareil et recherche de fonctionnalités cachées ou non surveillées.
• Tests de communication : Examen de la manière dont les données sont envoyées entre l'appareil, l'application et les systèmes dorsaux.
• Examen du stockage des données : Examen de la manière dont les informations sont stockées localement et de l'endroit où elles le sont.

PRINCIPALES CONCLUSIONS

• Faible sécurité des communications : Certaines transmissions n'étaient pas bien protégées, ce qui a permis de capturer des données de localisation et des journaux de nettoyage.
• Risques liés à la mise à jour des microprogrammes : Le Processus de mise à jour manquait de vérifications de la signature digitale, ouvrant la porte à l'injection de micrologiciels altérés.
• Fonctions illimitées de l'application : Les failles de l'app mobile exposaient les fonctions de test internes et pouvaient permettre une utilisation abusive des fonctions de l'appareil.
• Risques d'accès à distance : Les attaquants pourraient exploiter ces problèmes pour contrôler l'aspirateur ou observer le comportement des utilisateurs.

EN REMÉDIANT À CES PROBLÈMES, LE CLIENT A PU

• Améliorer les contrôles d'accès dans l'application mobile afin de bloquer l'utilisation abusive des fonctions internes.
• combler les lacunes en matière de communication afin d'empêcher l'interception du trafic
• appliquer des modifications cryptographiques pour protéger les données stockées et transmises
• introduire une vérification rigoureuse pour les mises à jour du micrologiciel
• Ajoutez des mesures de protection contre l'utilisation abusive automatisée de l'application mobile.
• Former les équipes techniques aux pratiques de développement mobile et IoT sécurisées.

Ces actions ont aidé le fabricant à réduire les risques de manière générale et à obtenir une vision plus claire de la manière dont les attaquants pourraient approcher le système. Les résultats ont permis d'améliorer les produits à long terme et de renforcer la position des futurs appareils.