Eine Sicherheitskamera soll Risiken senken. Genau deshalb hat der Fall Hanwha Vision/Wisenet Sicherheitsleute aufhorchen lassen: Ein Forscher schreibt, dass ein Firmware-Image einen GitHub-Token in Dateien der Web-Login-Oberfläche enthielt.

Firmwarepaket einer Netzwerkkamera mit geschwärztem CI-Token im Security Scanner

Die sinnvolle Lesart ist nicht, dass alle Kameras kompromittiert sind. Laut Autor wurde der Token schnell widerrufen, und die geprüften öffentlichen Quellen belegen keine massenhafte Ausnutzung. Der praktische Punkt ist enger: Ein Embedded-Gerät kann ganz normale CI/CD- und Frontend-Fehler übernehmen, nur landen sie dann in Firmware, die Kunden installieren und lange behalten.

Der Originalbeitrag vom 24. Juli beschreibt, wie der Autor Hanwha-Firmware herunterlud, das Dateisystem extrahierte und einen Secret Scanner laufen ließ. TruffleHog habe eine GitHub-Credential in etwa 30 Dateien gefunden. Der Token habe Adminrechte auf Hunderte Repositories der GitHub-Organisation von Hanwha gehabt. Nach der Meldung habe Hanwha innerhalb von 12 Stunden geantwortet, dass der Token widerrufen wurde.

Eine offizielle Hanwha-Advisory mit betroffenen Modellen, Firmwareständen und exakten Berechtigungen fand ich nicht. Der Kontext ist trotzdem klar: Hanwha verkauft Netzwerkkameras und Videomanagement für Flughäfen, Banken, Rechenzentren, Städte, Behörden, Gesundheitswesen, Verkehr und Versorger. Ein Secret in Kamerafirmware ist deshalb nicht nur ein peinlicher Build-Fehler.

Wichtig ist der Weg in das Artefakt. Der Forscher verweist auf ein mit Vite gebautes Web-UI und eine Variable, die offenbar die Umgebung des CI-Jobs in Client-Dateien schrieb. Die Vite-Dokumentation sagt, dass Variablen mit VITE_ im Client-Bundle landen; andere sollten über diesen normalen Pfad nicht sichtbar werden. Das Problem lautet also nicht "Vite leakt Secrets", sondern schlecht kontrollierte Build-Grenzen.

Firmware macht solche Fehler langlebig. Ein Web-Bundle lässt sich neu deployen. Ein Firmware-Image liegt bei Herstellern, Distributoren, in NVR-Prozessen und auf Geräten oft jahrelang. Token-Revocation behebt das akute Credential-Problem, erklärt aber nicht, warum ein breites Secret überhaupt in das Release-Artefakt gelangte.

Betreiber von IP-Kameras sollten ruhig vorgehen. Modelle und Firmwarestände inventarisieren, Advisories prüfen, Updates kontrolliert einspielen. Wenn der Hersteller nichts veröffentlicht, beim Support nachfragen: betroffene Modelllinie, entfernte Embedded Credentials, rotierte Secrets.

Kameras gehören wie kleine fremdverwaltete Computer behandelt. Eigener VLAN oder isoliertes Netz, kein direkter Internetzugang ohne klaren Zweck, lokale Verwaltung über NVR oder Managementserver mit ONVIF/RTSP, Remote-Zugriff nur über einen kontrollierten Weg.

Auch Beschaffung muss andere Fragen stellen. Datenblätter erklären Auflösung und Nachtsicht. Sie erklären nicht, ob Firmware-Artefakte auf Secrets gescannt werden, ob Build-Umgebungen Allowlists nutzen, ob Tokens kurzlebig und eng berechtigt sind, ob Releases signiert werden und wie Disclosure funktioniert.

Hersteller brauchen langweilige Kontrollen: Quellbaum, Web-Bundle, entpacktes Rootfs und finales Firmwarearchiv scannen. Der Build muss stoppen, wenn Token, private Schlüssel oder interne Credentials auftauchen. Ein Frontend-Job braucht keinen organisationsweiten Token, nur weil es bequem ist.

Positiv ist die berichtete Reaktion: 12 Stunden bis zur Revocation. Das löscht den Fehler nicht, zeigt aber den Wert eines sichtbaren Security-Kontakts. Der Hacker-News-Thread mit rund 640 Punkten und 230 Kommentaren drehte sich schnell um Praxis: ONVIF, VLANs, blockierter WAN-Zugriff, lokaler NVR und Kameras als nicht vertrauenswürdige Endpunkte.

Die Lehre: Ein Sicherheitsprodukt bleibt Software. Firmware ist ein Release-Artefakt, das Web-UI ein Client-Bundle, der Updateprozess Teil der Supply Chain. Wenn diese Teile ein CI-Secret an Kunden ausliefern können, ist die Kamera keine passive Box mehr.