Des caméras de sécurité Hanwha Vision ont été expédiées avec un token administrateur GitHub inclus dans la page de connexion de l’interface web

 (hhh.hn)
1 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Environ 30 fichiers de l’interface web d’administration du firmware des caméras Hanwha Vision contenaient le même token GitHub, qui disposait de droits administrateur sur des centaines de dépôts de l’organisation
  • Le fwupgrader du firmware reconstituait une clé AES codée en dur en la combinant par XOR avec une table statique, puis déchiffrait le système de fichiers racine avec openssl ; la clé et l’IV étaient partagés par toute la même famille de modèles
  • Comme une variable de build Vite était configurée sur l’intégralité de process.env, les variables d’environnement du job CI ont été inscrites dans l’artefact final, ce qui a inclus GITHUB_NPM_TOKEN ainsi que plusieurs configurations internes dans le firmware de la caméra
  • En examinant environ 500 firmwares de la même manière, 62 % ont pu être extraits ; les 3 firmwares où un token GitHub a été trouvé contenaient tous le même token
  • Hanwha a révoqué le token en moins de 12 heures après le signalement, mais une configuration qui injecte tout l’environnement CI dans les artefacts clients peut exposer des identifiants et des informations sur l’infrastructure interne dans le produit

Obtention du firmware et première couche de chiffrement

  • Le site de Hanwha Vision publiait les images de firmware par modèle de caméra, ce qui permettait de télécharger les fichiers pour les analyser
  • L’examen de l’image avec binwalk a révélé une archive tar distincte contenant des composants IA pour la caméra, ainsi qu’un fwimage.tgz chiffré
  • En suivant l’analyse de Matt Brown sur le déchiffrement du firmware Hanwha, le mot de passe utilisé combinait HTW et le numéro de modèle
    • Dans l’échantillon analysé, HTWXNP-9300RW fonctionnait
  • À l’intérieur de la tarball extraite se trouvait un autre fwimage.tgz, chiffré différemment, si bien qu’il n’était pas possible de réutiliser telle quelle la procédure de déchiffrement existante

Reconstitution du procédé de déchiffrement dans fwupgrader

  • Le binaire fwupgrader inclus dans la tarball externe a été analysé avec Ghidra et Claude Code afin d’extraire le véritable système de fichiers racine
  • fwupgrader utilisait une obfuscation destinée à masquer le procédé de déchiffrement
    • La clé AES était reconstituée à l’exécution après XOR avec une petite table de clés statique présente dans le binaire
    • L’IV était présent en clair dans le binaire
    • Des fragments de commande openssl étaient également obfusqués par XOR de la même manière
  • La commande reconstituée avait la forme suivante, en utilisant SHA-256 et AES-256-CBC 
    openssl enc -md sha256 -aes-256-cbc -d \  
  -K <KEY> -iv <IV> -in <INPUT> -out <OUTPUT>
  • La clé et l’IV étaient codés en dur et partagés par la même famille de modèles 
    KEY = dfa049bb922e63e2decc764af5628068e5b7a2662e479a615b14643e567579b0  
IV  = 53f926801b81454a4f889c9a390db6e6

Token administrateur GitHub inclus dans le firmware

  • L’analyse du système de fichiers racine extrait avec trufflehog a révélé le même token GitHub en double dans environ 30 fichiers
  • Ce token disposait de droits administrateur sur des centaines de dépôts appartenant à l’organisation GitHub de Hanwha
  • L’interface de la caméra est construite avec Vite, et une variable de build était configurée sur l’ensemble de process.env, ce qui montre que tout l’environnement du job CI a été inscrit dans les fichiers générés 
    var W = {  
  DATAPORT: "9090",  
  GIT_LFS_SKIP_SMUDGE: "1",  
  npm_command: "run-script",  
  KUBERNETES_SERVICE_PORT_HTTPS: "443",  
  GITHUB_NPM_TOKEN: "<snip>:ghp_…REDACTED…",  
  npm_config_userconfig: "/home/docker/.npmrc",  
  // etc  
}
  • Faute d’avoir la caméra physique, il n’a pas été possible de vérifier le comportement réel
    • Le token a pu être transmis sur le réseau à tout utilisateur accédant à l’interface d’administration
    • Il reste aussi possible que les fichiers n’aient existé que sur le disque sans être effectivement servis

Adresses DoD présentes dans l’environnement CI

  • Parmi les variables d’environnement exposées figuraient aussi des adresses IP attribuées au département de la Défense des États-Unis
  • Il n’a pas été possible de déterminer s’il s’agissait d’adresses utilisées arbitrairement pour des services internes non connectés à l’extérieur, ou si elles découlaient d’une relation entre Hanwha et le département de la Défense des États-Unis
  • Hanwha Vision est une entreprise de vidéosurveillance fondée sous le nom de Samsung Techwin et une filiale du groupe Hanwha
    • Parmi ses anciens produits figurent l’obusier automoteur K9 Thunder, le véhicule blindé de ravitaillement en munitions K10, des sous-systèmes du K2 Black Panther et le robot de garde SGR-A1
    • Le SGR-A1 est un robot de garde armé
  • Il est aussi possible que le CI soit fourni par l’organisation centrale de Hanwha et que des variables associées aient été partagées à la demande de la filiale Hanwha Aerospace ou de Hanwha Defense USA, mais cela reste une spéculation non vérifiée

Analyse de l’ensemble des firmwares

  • Afin de vérifier s’il s’agissait d’un cas isolé ou s’il existait d’autres tokens différents, les firmwares de caméras téléchargeables depuis le site de Hanwha ont été collectés
  • Sur environ 600 caméras, environ 500 firmwares ont été récupérés pour les modèles où un firmware était disponible
  • En appliquant la même méthode, 62 % ont pu être extraits, sans que la cause des échecs sur le reste ait pu être déterminée
  • Seuls 3 firmwares contenaient un token GitHub, et ils incluaient tous le même token

Signalement et réponse

  • Le minimum d’informations permettant d’identifier l’emplacement du token a été envoyé à l’adresse publique de signalement sécurité de Hanwha
  • Hanwha a répondu en moins de 12 heures après le signalement et a révoqué le token concerné
  • L’inclusion d’un token GitHub dans le firmware était une erreur, mais la prise en compte du signalement et la résolution ont été très rapides

À lire aussi

1 commentaires

 
GN⁺ 3 시간 전
Avis sur Hacker News

  • Je cherche des caméras IP en marque blanche, prises en charge par le fabricant mais dont on peut retirer le rootfs si nécessaire, ou des produits quasi plug-and-play
    Avant, il n’y avait que des kits de développement coûteux, parfois même sans boîtier, mais il semble qu’il existe désormais des options comme GoodCam

    • Même sans firmware ouvert, on s’en approche beaucoup en utilisant ONVIF sur un réseau isolé
      Les caméras ONVIF sont compatibles avec la plupart des enregistreurs vidéo réseau (NVR), et il existe aussi plusieurs NVR open source
      Si l’on n’expose pas des caméras PoE bon marché à Internet, la sécurité du firmware du fabricant est moins critique, mais les VLAN et la segmentation réseau doivent être configurés très soigneusement
    • J’ai créé Wyrecam pour résoudre ce problème, avec prise en charge de l’Ingenic T31 de la Wyze v3
      La stabilité est comparable à Apple HomeKit, donc pas vraiment excellente
    • Thingino dispose d’une liste claire des caméras prises en charge, et l’installation est simple pour les modèles prenant en charge le flashage via carte SD
      J’ai mis à niveau deux Sonoff Slim Gen2 sans problème
    • Sur certaines caméras, il est possible de remplacer le firmware existant par Thingino, et la liste du matériel pris en charge par OpenIPC vaut aussi la peine d’être consultée
    • La page de la boutique semble ne pas fonctionner, avec les erreurs Stránka nenalezena et There's been a glitch...

  • Le fait que le firmware contienne en dur une adresse IP du département de la Défense des États-Unis semble être le problème le plus grave, et cela me donne envie d’éviter les produits de sécurité coréens

    • Certaines entreprises mettent en trou noir toute la plage IP du DoD américain et l’utilisent comme adressage interne, donc c’est peut-être ce cas-là, mais cela reste très étrange
    • La marine canadienne semble aussi avoir pris récemment une décision similaire dans le cadre d’un grand programme : résultats de recherche
    • Le DoD américain possède un espace d’adresses IP tellement vaste qu’un chevauchement accidentel est tout à fait possible
    • Il en va de même pour les produits IoT coréens, et les approches de sécurité des produits que j’ai manipulés directement étaient absurdes
    • Les produits nationaux aussi sont souvent catastrophiques, avec des failles de sécurité et une ingénierie bâclée

  • De nombreux fournisseurs utilisent des valeurs par défaut dangereuses, une sécurité cassée et des valeurs codées en dur
    Même si la sécurité n’est pas la priorité absolue, il faut au minimum effectuer des contrôles de base comme la détection d’identifiants codés en dur

    • Le fait même que la sécurité ne soit pas une priorité pour des caméras de sécurité est ironique
    • Dans un mode de fonctionnement où le travail est confié aux personnes les moins expérimentées et les moins chères, il est difficile d’attendre ne serait-ce que des contrôles minimaux
    • Aujourd’hui, il suffit d’ajouter au dépôt une fonctionnalité qui effectue des contrôles de sécurité de base, donc il n’y a quasiment plus d’excuse

  • Mettre les caméras dans un VLAN séparé et bloquer complètement l’accès Internet de ce VLAN est le minimum à faire

  • En vérifiant par le passé, j’ai constaté que de nombreux dongles OBD-II étaient livrés avec la même adresse MAC, ce qui permettait d’accéder à toutes les informations de plusieurs sites web
    Même si l’on veut éviter ce genre de problème, il finit toujours par se produire

    • Je me demande comment une adresse MAC identique a pu mener à un accès complet
      Si le site web utilisait l’adresse MAC fournie par le client comme moyen d’authentification, c’est un échec typique de sécurité IoT

  • Il vaudrait mieux retirer sécurité du nom du produit et les appeler simplement des caméras

  • Le mauvais usage de l’icône de lien externe sur ce blog m’agace

    • Le sélecteur a[href*="://"]::after suppose que les liens internes sont des chemins relatifs comme href="/about", mais ce site utilise aussi des URL absolues comme [https://hhh.hn/about](https://hhh.hn/about) pour les liens de navigation, ce qui ajoute une icône à tous les liens
      On peut corriger cela en excluant les liens qui commencent par l’adresse du site : a[href*="://"]:not([href^="https://hhh.hn";])::after

  • L’éclairage d’ambiance d’intérieur que j’ai acheté récemment ne pouvait pas être contrôlé sans son application dédiée
    En récupérant l’APK sur le Google Store et en l’analysant, j’ai vu que les clés API du backend et de Shopify, entre autres, y étaient en pratique présentes telles quelles, mais je ne m’en suis pas encore servi pour faire quoi que ce soit

    • Les clés publiques ne donnent souvent aucun accès particulier
      Un développeur soucieux de la sécurité utiliserait App Attest ou l’équivalent du Google Store
    • Je ne vois pas de raison valable pour qu’une application d’éclairage ait besoin d’un accès à l’API Shopify
      Cela dit, pour avoir conseillé des boutiques Shopify, la qualité du code fourni par des consultants ou designers bon marché est souvent désastreuse, donc ce n’est pas surprenant
    • Même si ce n’est pas toujours idéal pour l’esthétique, il est plus sûr de n’acheter que des appareils connectés permettant un contrôle local, comme Zigbee ou Z-Wave
    • Publier ce genre d’informations est risqué, car l’entreprise peut réagir juridiquement
      Il existait une société qui protégeait les chercheurs des conséquences juridiques, mais je ne me souviens plus de son nom
    • Puisqu’il est finalement possible de le contrôler sans application dédiée, j’aimerais que quelqu’un rétro-ingénierie le protocole et publie la méthode

  • À cause des LLM, l’obfuscation de code est devenue pratiquement inefficace
    L’obfuscation ne faisait que rendre le travail pénible, mais l’IA ne se soucie pas de cet effort

    • L’obfuscation n’a jamais été efficace que contre les attaquants occasionnels qui ne supportaient pas l’ennui
      Les organisations étatiques ou les groupes de cybercriminels acceptent largement cet effort
    • Vu positivement, même de petits LLM locaux permettent d’améliorer facilement ce code de mauvaise qualité

  • J’ai déjà vu ce genre de système dans un salon américain de l’industrie de défense, il y a donc de fortes chances qu’il soit effectivement utilisé quelque part