Die Web-UI-Loginseite von Hanwha-Vision-Sicherheitskameras wurde mit einem GitHub-Admin-Token ausgeliefert

(hhh.hn)

1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen

In rund 30 Dateien der Web-Administrations-UI der Hanwha-Vision-Kamera-Firmware steckte derselbe GitHub-Token; dieser Token hatte Administratorrechte für Hunderte Repositories innerhalb der Organisation
Der fwupgrader der Firmware stellte einen hartcodierten AES-Schlüssel wieder her, indem er ihn mit einer statischen Tabelle per XOR verknüpfte, und entschlüsselte anschließend das Root-Dateisystem mit openssl; Schlüssel und IV wurden innerhalb derselben Modellfamilie gemeinsam verwendet
Weil eine Vite-Build-Variable auf das gesamte process.env gesetzt war, wurden die Umgebungsvariablen des CI-Jobs in das Build-Artefakt geschrieben; dadurch landeten auch GITHUB_NPM_TOKEN und mehrere interne Konfigurationen in der Kamera-Firmware
Rund 500 Firmware-Dateien wurden auf dieselbe Weise untersucht; 62 % ließen sich extrahieren. In den drei Firmware-Dateien, in denen ein GitHub-Token gefunden wurde, steckte jeweils derselbe Token
Hanwha hat den Token nach der Meldung innerhalb von 12 Stunden widerrufen. Eine Konfiguration, die die gesamte CI-Umgebung in Client-Artefakte einbettet, kann jedoch Zugangsdaten und Informationen zur internen Infrastruktur in Produkten offenlegen

Beschaffung der Firmware und erste Verschlüsselungsschicht

Die Website von Hanwha Vision stellt Firmware-Images je Kameramodell öffentlich bereit, sodass die Dateien heruntergeladen und analysiert werden konnten
Eine Untersuchung des Images mit binwalk fand ein separates Tarball mit KI-Komponenten für die Kamera sowie ein verschlüsseltes fwimage.tgz
Gemäß Matt Browns Analyse zur Entschlüsselung von Hanwha-Firmware wird ein Passwort verwendet, das HTW mit der Modellnummer kombiniert
- Beim untersuchten Ziel funktionierte HTWXNP-9300RW
In dem entpackten Tarball befand sich ein weiteres, auf andere Weise verschlüsseltes fwimage.tgz, sodass der bestehende Entschlüsselungsprozess nicht einfach wiederverwendet werden konnte

Rekonstruktion der Entschlüsselungsmethode aus `fwupgrader`

Das im äußeren Tarball enthaltene Binary fwupgrader wurde mit Ghidra und Claude Code analysiert, um das eigentliche Root-Dateisystem zu extrahieren
In fwupgrader war Obfuskation eingesetzt, um die Entschlüsselungsmethode zu verbergen
- Der AES-Schlüssel wird während der Ausführung neu zusammengesetzt, nachdem er per XOR mit einer kleinen statischen Schlüsseltabelle im Binary verknüpft wurde
- Der IV liegt im Binary im Klartext vor
- Auch Fragmente des openssl-Befehls sind auf dieselbe Weise per XOR obfuskiert

Der rekonstruierte Befehl hat folgende Form und verwendet SHA-256 sowie AES-256-CBC

openssl enc -md sha256 -aes-256-cbc -d \  
  -K <KEY> -iv <IV> -in <INPUT> -out <OUTPUT>

Schlüssel und IV waren hartcodiert und wurden innerhalb derselben Modellfamilie gemeinsam verwendet

KEY = dfa049bb922e63e2decc764af5628068e5b7a2662e479a615b14643e567579b0  
IV  = 53f926801b81454a4f889c9a390db6e6

In der Firmware enthaltener GitHub-Admin-Token

Beim Scannen des extrahierten Root-Dateisystems mit trufflehog wurde derselbe GitHub-Token in rund 30 Dateien mehrfach gefunden
Dieser Token hatte Administratorrechte für Hunderte Repositories in Hanwhas GitHub-Organisation

Die Kamera-UI wird mit Vite gebaut; eine Build-Variable war auf das gesamte process.env gesetzt, wodurch offenbar die komplette Umgebung des CI-Jobs in die Ergebnisdateien geschrieben wurde

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  
}

Mangels realer Kamera konnte nicht überprüft werden, ob dies zur Laufzeit tatsächlich wirksam war
- Es besteht die Möglichkeit, dass der Token an Nutzer übertragen wurde, die auf die Administrations-UI zugriffen
- Ebenso bleibt möglich, dass die Datei nur auf dem Datenträger vorhanden war und tatsächlich nicht ausgeliefert wurde

In der CI-Umgebung enthaltene DoD-Adressen

Zu den offengelegten Umgebungsvariablen gehörten auch IP-Adressen, die dem US-Verteidigungsministerium zugewiesen sind
- SWARM_MASTER_NFS_ADDRESS: 55.101.212.23
- OTEL_ELASTIC_URL: http://55.101.212.21:5601/<snip>;
- CIMIP: 55.101.211.213
Es ist nicht bestätigt, ob diese Adressen willkürlich für interne Dienste ohne Kommunikation nach außen verwendet wurden oder aus einer Beziehung zwischen Hanwha und dem US-Verteidigungsministerium stammen
Hanwha Vision ist ein Videoüberwachungsunternehmen, das als Samsung Techwin gegründet wurde, und eine Tochtergesellschaft der Hanwha Group
- Zu früheren Produkten zählen die selbstfahrende Haubitze K9 Thunder, das Munitionsversorgungsfahrzeug K10, Subsysteme für den K2 Black Panther sowie der Wachroboter SGR-A1
- Der SGR-A1 ist ein bewaffneter Wachroboter
Möglicherweise stellt Hanwhas zentrale Organisation das CI bereit, und entsprechende Variablen wurden aufgrund von Anforderungen der Tochtergesellschaft Hanwha Aerospace oder von Hanwha Defense USA geteilt; dies ist jedoch eine unbestätigte Vermutung

Untersuchung der gesamten Firmware

Um zu prüfen, ob es sich um einen zufälligen Einzelfall handelte oder ob weitere, unterschiedliche Tokens existierten, wurde die von der Hanwha-Website herunterladbare Kamera-Firmware gesammelt
Von rund 600 Kameras wurden für die Modelle, für die Firmware bereitgestellt wurde, etwa 500 Firmware-Dateien beschafft
Mit derselben Methode ließen sich 62 % extrahieren; warum der Rest fehlschlug, konnte nicht festgestellt werden
Firmware mit enthaltenem GitHub-Token gab es in 3 Fällen, und alle enthielten denselben Token

Meldung und Reaktion

An Hanwhas öffentlich angegebene Sicherheitsmelde-E-Mail wurden die minimal notwendigen Informationen übermittelt, um den Speicherort des Tokens zu identifizieren
Hanwha antwortete innerhalb von 12 Stunden nach der Meldung und widerrief den betreffenden Token
Dass ein GitHub-Token in Firmware enthalten war, war ein Fehler; die Annahme der Meldung und die Behebung erfolgten jedoch sehr schnell

1 Kommentare

GN⁺ 3 시간 전

Hacker-News-Kommentare

Gesucht werden White-Label-IP-Kameras oder fast Plug-and-Play-Produkte, die vom Hersteller unterstützt werden, bei denen sich bei Bedarf aber das rootfs entfernen lässt
Früher gab es nur teure Dev-Kits ohne Gehäuse, aber inzwischen scheint es Optionen wie GoodCam zu geben
- Auch ohne offene Firmware kommt man mit ONVIF in einem isolierten Netzwerk ziemlich nahe
  ONVIF-Kameras sind mit den meisten Network Video Recordern (NVR) kompatibel, und es gibt auch mehrere Open-Source-NVRs
  Wenn günstige PoE-Kameras nicht nach außen exponiert werden, ist die Sicherheit der Hersteller-Firmware weniger wichtig, aber VLANs und Netztrennung müssen sehr sorgfältig eingerichtet werden
- Zur Lösung dieses Problems wurde Wyrecam gebaut; es unterstützt den Ingenic T31 des Wyze v3
  Die Stabilität ist etwa auf dem Niveau von Apple HomeKit, also nicht besonders gut
- Bei Thingino ist die Liste unterstützter Kameras klar, und bei Modellen mit Unterstützung für SD-Karten-Flashen ist die Installation einfach
  Zwei Sonoff Slim Gen2 wurden ohne Probleme aktualisiert
- Bei einigen Kameras lässt sich die bestehende Firmware durch Thingino ersetzen, und auch die Liste unterstützter OpenIPC-Hardware ist einen Blick wert
- Die Shop-Seite scheint nicht zu funktionieren und zeigt Fehler wie Stránka nenalezena und There's been a glitch...
Das größere Problem scheint zu sein, dass in der Firmware IP-Adressen des US-Verteidigungsministeriums fest eingebrannt sind; das vermittelt den Eindruck, man solle koreanische Sicherheitsprodukte meiden
- Es könnte auch so ein Fall sein, dass ein Unternehmen den gesamten IP-Bereich des US-Verteidigungsministeriums blackholed und intern verwendet, aber selbst dann ist das sehr seltsam
- Offenbar hat auch die kanadische Marine bei einem großen Projekt kürzlich eine ähnliche Entscheidung getroffen: Suchergebnisse
- Das US-Verteidigungsministerium verfügt über einen so riesigen IP-Adressraum, dass eine zufällige Überschneidung durchaus möglich ist
- Dasselbe gilt für koreanische IoT-Produkte; die Sicherheitspraktiken der Produkte, mit denen man direkt zu tun hatte, waren absurd schlecht
- Auch Produkte aus dem eigenen Land sind oft wegen Sicherheitslücken und schlampigem Engineering ein einziges Chaos
Viele Anbieter verwenden gefährliche Standardwerte, kaputte Sicherheit und hartkodierte Werte
Selbst wenn Sicherheit nicht oberste Priorität hat, sollte es zumindest grundlegende Prüfungen wie einen Check auf hartkodierte Zugangsdaten geben
- Es ist schon ironisch, dass bei Sicherheitskameras Sicherheit keine Priorität ist
- In Betriebsmodellen, in denen die unerfahrensten und billigsten Kräfte die Arbeit erledigen, kann man nicht einmal Mindeststandard-Prüfungen erwarten
- Heutzutage muss man nur noch eine Funktion hinzufügen, die im Repository grundlegende Sicherheitsprüfungen durchführt, daher gibt es kaum noch Ausreden
Kameras in ein separates VLAN zu packen und den Internetzugang dieses VLANs vollständig zu blockieren, ist das Minimum
Früher zeigte sich, dass viele OBD-II-Dongles mit derselben MAC-Adresse ausgeliefert wurden, wodurch man auf sämtliche Informationen mehrerer Websites zugreifen konnte
Solche Probleme treten offenbar immer wieder auf, selbst wenn man sie vermeiden möchte
- Es ist fraglich, wie dieselbe MAC-Adresse zu vollständigen Zugriffsrechten führen konnte
  Wenn die Website eine vom Client gelieferte MAC-Adresse als Authentifizierungsmittel verwendet hat, ist das ein klassisches IoT-Sicherheitsversagen
Vielleicht sollte man Sicherheit aus dem Produktnamen streichen und es einfach Kamera nennen
Es stört, dass dieser Blog das Icon für externe Links falsch verwendet
- Der Selektor a[href*="://"]::after geht davon aus, dass interne Links relative Pfade wie href="/about" haben, aber diese Website verwendet auch für Navigationslinks absolute URLs wie [https://hhh.hn/about](https://hhh.hn/about), sodass bei allen Links ein Icon erscheint
  Das lässt sich beheben, indem man Links ausschließt, die mit der Website-Adresse beginnen: a[href*="://"]:not([href^="https://hhh.hn";])::after
Eine kürzlich gekaufte Innenraum-Stimmungsleuchte ließ sich ohne die zugehörige App nicht steuern
Nach dem Download der APK aus dem Google Store und der Analyse zeigte sich, dass Backend- und API-Schlüssel etwa für Shopify praktisch ungeschützt enthalten waren, auch wenn damit bisher noch nichts unternommen wurde
- Öffentliche Schlüssel gewähren oft keinen besonderen Zugriff
  Wer Sicherheit ernst nimmt, würde App Attest oder das entsprechende Google-Store-Äquivalent verwenden
- Es fällt kein plausibler Grund ein, warum eine Lampen-App Zugriff auf die Shopify-API brauchen sollte
  Allerdings überrascht das nicht, wenn man aus der Beratung von Shopify-Shops weiß, wie katastrophal die Codequalität bei billigen Beratern oder Designern oft ist
- Aus Sicherheitsgründen ist es besser, nur Smart-Geräte zu kaufen, die lokale Steuerung wie Zigbee oder Z-Wave unterstützen, auch wenn das optisch nicht immer die beste Wahl ist
- Wenn man solche Informationen veröffentlicht, könnte der Anbieter rechtlich dagegen vorgehen, was riskant ist
  Es gab einmal ein Unternehmen, das Forschende vor rechtlichen Folgen schützte, aber der Name fällt gerade nicht ein
- Da sich das Gerät letztlich auch ohne die App steuern lässt, wäre es wünschenswert, das Protokoll rückzuentwickeln und die Methode zu veröffentlichen
Wegen LLMs ist Code-Obfuskation praktisch wirkungslos geworden
Obfuskation sollte die Arbeit nur langweiliger und mühsamer machen, aber AI stört sich an solcher Mühe nicht
- Obfuskation war nur gegen oberflächliche Angreifer wirksam, die Langeweile nicht ertragen
  Staatliche Akteure oder kriminelle Hackergruppen nehmen diesen Aufwand ohne Weiteres in Kauf
- Positiv gesehen lassen sich mit kleinen lokalen LLMs selbst solche minderwertigen Codes leicht verbessern
Solche Systeme wurden schon auf einer US-Rüstungsmesse gesehen, daher ist es gut möglich, dass sie tatsächlich irgendwo im Einsatz sind