Камера безопасности должна снижать риск. Поэтому история с Hanwha Vision/Wisenet так зацепила специалистов: исследователь утверждает, что в прошивке камеры нашёл GitHub token в файлах, связанных с веб-интерфейсом входа.

Пакет прошивки сетевой камеры с отредактированным CI token, найденным security scanner

Правильный вывод здесь не в том, что "все камеры взломаны". По словам автора, token быстро отозвали, а проверенные публичные источники не подтверждают массовую эксплуатацию. Вывод практичнее: embedded device может унаследовать обычные ошибки web-разработки и CI/CD, а потом разнести их в firmware image, который клиенты ставят и годами не трогают.

Исходная публикация от 24 июля описывает разбор firmware Hanwha: скачивание образов, извлечение root filesystem и запуск secret scanner. Автор пишет, что TruffleHog нашёл GitHub credential примерно в 30 файлах, а token имел admin privileges к сотням репозиториев GitHub organization производителя. Он также пишет, что сообщил детали Hanwha и получил ответ за 12 часов: token revoked.

Это серьёзные утверждения, но это всё ещё утверждения исследователя. Официального advisory Hanwha с точным списком моделей, версий прошивки и scopes token найти не удалось. Зато официальный сайт Hanwha подтверждает масштаб контекста: компания продаёт network cameras, video management и AI-driven security для аэропортов, банков, дата-центров, городского видеонаблюдения, госструктур, транспорта, медицины и utilities. Поэтому секрет в firmware камеры — не просто неловкая ошибка сборки.

Механизм важнее сенсации. Автор связывает проблему с веб-UI на Vite и переменной, которая, по его словам, записала окружение CI job в client-side files. Документация Vite говорит аккуратно: переменные с префиксом VITE_ попадают в клиентский bundle, остальные при нормальной конфигурации не должны. Значит, проблема не в лозунге "Vite leaks secrets", а в том, что build rules, prefixes and environment injection становятся частью security boundary.

С firmware эта граница хуже видна. Публичный web bundle можно быстро пересобрать и выкатить. Firmware image камеры может лежать на сайте vendor, попадать в зеркала, дистрибьюторские архивы, процедуры обновления NVR и оставаться на устройствах годами. Если туда попал broad token, revocation закрывает срочный риск, но не отвечает на главный вопрос: почему build вообще позволил такому секрету попасть в release artifact.

Для владельцев IP-камер реакция должна быть спокойной. Сначала составьте inventory моделей и firmware versions. Проверьте vendor advisories и обновления. Обновляйте через нормальный change process. Если vendor молчит, спросите поддержку напрямую: затронута ли ваша линейка, удалены ли embedded credentials, ротированы ли secrets.

Дальше относитесь к камерам как к маленьким vendor-managed компьютерам, а не как к пассивным коробкам. Выносите их в отдельный VLAN или изолированную сеть. Закрывайте прямой интернет-доступ, если он не нужен. Лучше, когда камеры общаются локально с NVR или management server через ONVIF/RTSP, а удалённый просмотр идёт через контролируемый путь.

Поверните то, что контролируете: admin passwords, default accounts, доступ к management interface, outbound traffic. Если камера должна ходить к vendor за обновлениями, это должно быть описано. Если она стучится в неожиданные сети, это не фон, а повод для проверки.

Procurement тоже должен задавать другие вопросы. Datasheet рассказывает про разрешение, night vision и объектив. Он не говорит, сканирует ли vendor firmware artifacts на secrets, использует ли allowlist env variables, применяет ли short-lived and fine-grained tokens, подписывает ли release, как быстро отвечает на vulnerability disclosure.

Для vendor контроль должен быть скучным и автоматическим: scan source tree, built web bundle, unpacked rootfs and final firmware archive. Build должен падать, если в artifact появляется token, private key, webhook secret or internal credential. Frontend build job не должен получать organization-wide token просто потому, что так удобнее.

Хорошая часть истории — disclosure. Автор пишет, что Hanwha ответила в течение 12 часов и отозвала token. Это не отменяет ошибки сборки, но показывает ценность понятного security contact and response process. Худший сценарий выглядел бы иначе: валидный token, нет канала для сообщения, недели тишины.

HN-тред набрал около 640 points and 230 comments и быстро ушёл в практику: ONVIF setups, VLANs, blocked WAN, open firmware projects, self-hosted NVRs и вопрос, считать ли камеры недоверенными endpoints. Это правильный уровень тревоги. Не паника, а архитектура.

Главный урок: security product всё равно остаётся software product. Его firmware — release artifact. Web UI — client bundle. Update system — часть supply chain. Если эти части могут перенести секрет из CI в руки клиента, камера становится мостом между вашей физической безопасностью и чужой ошибкой сборки.