Kamera bezpieczeństwa ma zmniejszać ryzyko. Dlatego historia Hanwha Vision/Wisenet tak mocno odbiła się w środowisku security: badacz twierdzi, że obraz firmware zawierał token GitHub w plikach używanych przez stronę logowania kamery.

Pakiet firmware kamery sieciowej z zredagowanym tokenem CI wykrytym przez skaner

Wniosek nie brzmi: wszystkie kamery są przejęte. Według autora token szybko unieważniono, a sprawdzone publiczne źródła nie potwierdzają masowej eksploatacji. Wniosek praktyczny jest inny: urządzenie embedded może wynieść z pipeline'u te same błędy, które znamy z aplikacji webowych, a potem zapisać je w firmware instalowanym na lata.

Wpis z 24 lipca opisuje pobranie firmware Hanwha, wyciągnięcie filesystemu i skanowanie sekretów. Autor pisze, że TruffleHog znalazł credential GitHub powielony w około 30 plikach. Według niego token miał uprawnienia administratora do setek repozytoriów w organizacji Hanwha na GitHubie. Po zgłoszeniu Hanwha miała odpowiedzieć w ciągu 12 godzin, że token został revoked.

Nie znalazłem oficjalnego advisory Hanwha z listą modeli, wersji firmware i dokładnych uprawnień tokena. Kontekst jest jednak jasny: Hanwha sprzedaje kamery sieciowe i systemy wideo dla lotnisk, banków, data center, miast, administracji, ochrony zdrowia, transportu i utilities. Sekret w firmware takiej kamery nie jest drobną wpadką developerską.

Mechanizm jest ważny. Autor wskazuje na web UI budowany przez Vite i zmienną, która miała wpisać środowisko joba CI do plików klienta. Dokumentacja Vite mówi, że zmienne z prefiksem VITE_ trafiają do kodu klienta po bundlingu; inne nie powinny trafić tam normalną ścieżką. Problemem nie jest więc "Vite ujawnia sekrety", tylko brak kontroli nad granicą builda.

Firmware utrwala błąd. Bundle webowy można szybko poprawić i wdrożyć. Obraz firmware może leżeć u vendora, dystrybutorów, w procedurach NVR i na urządzeniach przez lata. Unieważnienie tokena rozwiązuje pilny problem credential, ale nie tłumaczy, czemu pipeline dopuścił szeroki sekret do release artifact.

Operatorzy kamer IP powinni działać spokojnie: zinwentaryzować modele i wersje firmware, sprawdzić advisories i aktualizacje, zapytać vendora o wpływ na konkretną linię produktów, usunięte embedded credentials i rotację sekretów.

Kamery traktujcie jak małe komputery zarządzane przez zewnętrznego dostawcę. Osobny VLAN albo izolowana sieć, brak bezpośredniego internetu bez konkretnej potrzeby, lokalny NVR lub serwer zarządzający przez ONVIF/RTSP i kontrolowana ścieżka zdalnego dostępu.

Zakupy też muszą pytać inaczej. Specyfikacja mówi o rozdzielczości i noktowizji. Nie mówi, czy vendor skanuje gotowe firmware pod kątem sekretów, czy używa allowlist dla zmiennych środowiskowych, czy tokeny są krótkotrwałe i minimalne, czy release jest podpisany i jak działa disclosure.

Po stronie producenta kontrola powinna być automatyczna: skan źródeł, web bundle, rozpakowany rootfs i finalne archiwum firmware. Build ma się zatrzymać, jeśli pojawi się token, private key albo internal credential. Frontend build job nie potrzebuje tokena do całej organizacji tylko dlatego, że tak było wygodniej.

Dobra część tej historii to reakcja: według badacza 12 godzin i token revoked. To nie kasuje błędu, ale pokazuje wartość widocznego kontaktu security. Wątek na Hacker News, około 640 points i 230 comments, szybko przeszedł do praktyki: ONVIF, VLAN, blokada WAN, własny NVR i traktowanie kamer jako nieufanych endpointów.

Lekcja jest prosta: produkt security nadal jest produktem software. Firmware jest release artifact, web UI jest client bundle, aktualizacje są częścią supply chain. Jeśli te elementy mogą przenieść sekret z CI do klienta, kamera nie jest pasywnym urządzeniem.