SavePearlHarbor

Operation CameraSwarm: как один набор инструментов добрался до 14 500 камер Dahua

—

от автора

admin

18 августа 2026 года исследователи Hunt.io опубликовали разбор Operation CameraSwarm. За 35 дней один оператор получил доступ более чем к 14 500 камерам Dahua. 

Источник здесь необычно подробный: исследователи нашли открытый HTTP-каталог самого оператора и забрали 2 616 файлов общим объёмом 407 МБ: исходники, журналы запусков, результаты сканирования и служебные скрипты. Затем находки сверили с собственной сетевой телеметрией.

Здесь не было какой-то одной волшебной уязвимости, которая открывала доступ ко всем 14 500 камерам. В одной кампании сошлись старые пароли, непропатченные прошивки и служебная P2P-инфраструктура. Каждый из этих рисков по отдельности известен уже давно. Но когда они собираются вместе…это превращается в конвейер.

Сейчас я занимаюсь разработкой программного обеспечения для IP-камер «Рувер», поэтому смотрю на эту историю немного с другой стороны. Когда каждый день работаешь с firmware, SDK, загрузчиком и механизмами обновления, быстро понимаешь, что камера —  это полноценная вычислительная система со своей цепочкой доверия. 

Дальше будет не страшилка про IoT, а разбор того, что действительно удалось подтвердить исследователям, какие выводы они сделали и что из этого можно проверить в собственных камерах.

Небольшой словарь, чтобы не путаться:

Firmware, или встроенное ПО — программа внутри камеры: загрузка, сеть, веб-интерфейс, кодирование видео, обновление и служебные протоколы.

SoC, system-on-chip — основная микросхема, в которой могут находиться процессор, видеокодек, контроллеры памяти и другие блоки. Не путать с SOC — центром мониторинга информационной безопасности, где люди и системы обрабатывают события и реагируют на инциденты.

SDK — комплект библиотек, заголовков, примеров и инструментов, на базе которого производитель или OEM-партнёр, выпускающий устройство под другой торговой маркой, собирает часть программной платформы.

P2P (в контексте камер) — механизм прямого или релейного удалённого соединения между приложением и устройством. Это не обязательно классическая полностью одноранговая сеть. На практике часто участвует центральная инфраструктура производителя.

NAT — преобразование сетевых адресов. Оно позволяет нескольким внутренним устройствам выходить в интернет через один внешний адрес, но само по себе не является системой аутентификации или контролем доверия.

Что именно нашли исследователи

По данным Hunt.io, оператор использовал три независимых пути:

  1. прямой подбор учётных данных на TCP/37777 — 12 324 уникальных адреса;

  2. обход аутентификации через CVE-2021-33044 и CVE-2021-33045 — 1 923 устройства;

  3. подключение через облачный P2P-релей по серийному номеру — 283 устройства.

Всего в отчёте говорится о более чем 14 530 скомпрометированных устройствах. Оператор сканировал сети по всему миру. Самая крупная ранняя выборка пришлась на сети Мексики и Вьетнама, а подтверждённые геолокации поздних запусков в основном концентрировались в России и Украине. Поэтому пересказывать эту историю как «атаку только на две страны» было бы неточно. 

Важно не делать поспешных выводов о том, кто стоял за атакой. В материалах нашли русскоязычные комментарии и ссылку на сообщество во «ВКонтакте», но Hunt.io не связывает операцию с конкретной группой или государством. Оператор также использовал инструменты как минимум шести других разработок. Поэтому сам факт использования этого кода ещё не говорит о его авторстве.  

Первый путь: никакой экзотики, просто масштаб

Основную массу результатов дал перебор учётных данных на фирменном протоколе управления, доступном через TCP/37777.

Сначала инструмент сканировал диапазоны адресов и определял модели устройств. Потом пробовал разные пары логина и пароля, делал снимок и отбрасывал тёмные или пустые кадры.

Интересная деталь: после пяти неудачных попыток он прекращал подбор, если учётная запись блокировалась. То есть это был не случайный скрипт «в лоб», а вполне аккуратный массовый инструмент.

Здесь вывод скучный, но от этого не менее неприятный: сложная уязвимость не требуется, если служебный порт смотрит в интернет, а пароль повторяется на сотнях объектов.

Hunt.io обнаружила одинаковые нестандартные пароли на нескольких независимых устройствах. Возможно, монтажник или интегратор использовал один шаблон при развёртывании. Но это только предположение, и утверждать, что за этим стоял конкретный подрядчик, нельзя.

Второй путь: CVE-2021-33044 и CVE-2021-33045

Обе уязвимости позволяют удалённо обойти аутентификацию на уязвимых устройствах Dahua. CVE — это публичный идентификатор уязвимости, а CVSS — система оценки её опасности. 

Производитель оценил обе проблемы в 8,1 балла по CVSS 3.x и выпустил исправления в 2021 году. В августе 2024 года CISA добавила обе записи в каталог Known Exploited Vulnerabilities (KEV) — это список уязвимостей, которые уже использовались в реальных атаках. 

CVE-2021-33044

В этом случае клиент представлялся аппаратным контроллером NetKeyboard. Уязвимая прошивка доверяла такому клиенту и не проверяла переданное поле пароля. В результате атакующий мог получить административный доступ без действующих учётных данных.

Подробнее об уязвимости: NVD — CVE-2021-33044; БДУ ФСТЭК — BDU:2026-12630, «Уязвимость механизма аутентификации веб-интерфейса микропрограммного обеспечения устройств Dahua, позволяющая нарушителю повысить свои привилегии».

CVE-2021-33045

Здесь прошивка доверяла адресу источника, который был указан в самом запросе, а не проверяла реальный адрес TCP-соединения. Атакующий указывал адрес 127.0.0.1, и камера воспринимала запрос как локальный и доверенный. 

Карточки: NVD — CVE-2021-33045; БДУ ФСТЭК — BDU:2026-12631, «Уязвимость механизма аутентификации Loopback микропрограммного обеспечения устройств Dahua, позволяющая нарушителю повысить свои привилегии».

БДУ здесь действительно можно считать российским источником по тем же уязвимостям: в карточках указаны соответствующие CVE. Но БДУ не заменяет NVD и уведомление по безопасности  производителя. Названия, даты включения, оценки и перечни затронутых моделей могут отличаться, поэтому для практической работы я бы проверял все три источника.

После обхода аутентификации инструмент создавал отдельную служебную учётную запись. По данным Hunt.io, она не зависела от пароля администратора, переживала смену пароля и на большинстве проверенных прошивок сохранялась после сброса к заводским настройкам. Здесь важно не расширять формулировку до «любой factory reset бесполезен»: отчёт описывает наблюдавшееся поведение конкретного инструмента и набора прошивок.  

И ещё одна деталь, полезная для любого аналитика. В инструментах оператора две техники были подписаны чужими CVE: CVE-2024-39943 относится к Rejetto HTTP File Server, а CVE-2025-31702 описывает другую, более узкую проблему Dahua. 

Hunt.io отдельно проверила эти обозначения и выяснила, что они не соответствовали описанию реальных атак. Хорошее напоминание: название каталога рядом с эксплойтом не является доказательством соответствия. CVE нужно сверять с карточкой, уведомлением по безопасности вендора и реальным условием эксплуатации. 

Третий путь: P2P-релей и устройство за NAT

Самая интересная часть CameraSwarm связана не с перебором паролей и не со старыми CVE. Оператор использовал облачный P2P-релей, чтобы подключаться к камерам удалённо. 

P2P нужен для того, чтобы пользователь мог подключиться к камере из приложения, даже если она находится за NAT, без белого IP-адреса и ручного проброса портов. Камера сама устанавливает исходящее соединение с инфраструктурой производителя, а приложение находит её по серийному номеру.  

С точки зрения владельца всё выглядит удобно: камера «не торчит» в интернете. С точки зрения модели угроз появляется второй периметр — облачный сервис, протокол поиска устройства, встроенные в клиент ключи и правила, по которым релей решает, кому разрешить туннель.

В восстановленном коде Hunt.io обнаружила одинаковые служебные данные доступа к релею, встроенные в клиенты Dahua. Инструмент перебирал серийные номера, находил активные устройства и пытался открыть туннель. 

В журнале самого оператора указано, что 89,4% найденных активных серийных номеров возвращали канал без запроса учётных данных устройства. Это не значит, что так можно подключиться к 89,4% всех камер Dahua. Процент относится только к той выборке серийных номеров, которую проверил оператор.

Вот почему фраза «камера за NAT, значит снаружи её не видно» больше не работает как гарантия. NAT скрывает её прямой адрес, но если устройство само устанавливает соединение с облачным сервисом, а тот позволяет открыть к нему канал без нормальной аутентификации, NAT уже не спасает. 

Камера — часть системы, а не одиночный endpoint

CameraSwarm хорошо показывает риски самого устройства, но реальная система видеонаблюдения шире: в ней есть облачная платформа, операторы, подрядчики, каналы обновления и физическая среда. Иногда слабое звено находится вообще не в прошивке камеры.

Verkada: когда облако становится слабым звеном

В марте 2021 года злоумышленник получил права Super Admin в платформе Verkada Command из-за уязвимости в сервере поддержки. Согласно жалобе FTC, такой доступ позволил ему подключиться к более чем 150 000 камер клиентов, просматривать часть потоков, выполнять удалённые команды и выгружать данные. 

Это был взлом не отдельной камеры, а самой системы управления, через которую были доступны тысячи устройств.

Из этого не следует, что облако само по себе хуже локальной системы. Наоборот, централизация даёт единое управление патчами, логи и возможность быстрее обнаруживать аномалии. Но при этом ошибка в привилегированной учётной записи, сервере поддержки или CI/CD-инфраструктуре может затронуть сразу большое количество устройств.

Поэтому чем больше камер подключено к одной платформе, тем важнее разделение ролей, MFA, аудит действий и изоляция служебных систем.

Московская ЕЦХД: когда риск уже внутри

В 2019 году журналисты в рамках расследования обнаружили, что доступ к московской системе видеонаблюдения продавался на чёрном рынке. В публикациях фигурировали около 170 000 камер, примерно 3 000 из которых были подключены к системе распознавания лиц. По версии журналистов, продавать доступ могли должностные лица, у которых уже был легальный доступ к системе. Это важная оговорка: речь идёт о данных журналистов, а не о судебно установленной вине конкретного сотрудника.

Здесь вопрос уже не в том, как подобрать пароль к камере, а в том, что может сделать пользователь, которому система уже доверяет. Для крупной централизованной инфраструктуры важны принцип наименьших привилегий, журналы доступа, контроль выгрузок, временные права и раздельное подтверждение чувствительных операций.

Когда чужая камера становится твоим разведчиком

Есть ещё один сценарий, который легко потерять при обсуждении CVE. Атакующему необязательно устанавливать собственную камеру. Иногда гораздо эффективнее получить доступ к уже существующей системе видеонаблюдения и использовать её против владельца.

В марте 2026 года Financial Times со ссылкой на действующих и бывших сотрудников израильских спецслужб сообщила, что разведка Израиля несколько лет имела доступ к сети дорожных камер Тегерана. По словам источников издания,  видеозаписи помогали следить за телохранителями и водителями высокопоставленных иранских чиновников, а также изучать их маршруты, графики дежурств, места проживания и расположения автомобилей.

что Израиль несколько лет имел доступ к сети дорожных камер Тегерана. По данным источников издания, видеозаписи помогали следить за телохранителями и водителями высокопоставленных иранских чиновников, а также изучать их маршруты, графики дежурств, места проживания и автомобили. 

Позднее Associated Press тоже сообщило, что Израиль использовал иранские уличные камеры для отслеживания целей. Система, которую создавали для контроля дорожного движения и наблюдения за городом, стала источником разведывательных данных для внешнего противника. 

Точный способ первоначального доступа публично не раскрыт. В открытых материалах нет достаточных оснований утверждать, что использовалась конкретная CVE, стандартный пароль, уязвимость P2P или ошибка определённого производителя. Подробности операции основаны в основном на анонимных источниках в разведывательном сообществе. Поэтому здесь правильнее говорить о данных журналистских расследований, а не о полностью опубликованном техническом отчёте.

Но с инженерной точки зрения сам сценарий вполне понятен. Камера может оставаться физически исправной, продолжать выполнять штатные функции и не вызывать подозрений у оператора. При этом копия видеопотока уже поступает третьей стороне и используется для построения маршрутов, выявления повторяющихся действий и определения местонахождения конкретных людей.

И вот здесь камера окончательно перестаёт быть просто сетевым endpoint с логином и паролем. Она становится разведывательным источником. Причём установленная IP-камера подключёна к питанию и обслуживается самой атакованной стороной.

Что делают государства: урок регуляторов

Регуляторы всё чаще оценивают не только найденную CVE, но и архитектуру доверия: кто контролирует обновление, облако, компоненты и возможность изменить программное состояние устройства завтра. Ограничения на использование определённого оборудования в таком случае не означают, что в нём обязательно есть закладка. Это один из способов снизить потенциальный риск.

Великобритания, 2022 год. Правительственным ведомствам предписали прекратить установку определённых китайских систем видеонаблюдения на чувствительных объектах, не подключать уже установленные устройства к основным сетям и рассмотреть их замену.

Австралия, 2023 год. Проведённый по запросам парламентария аудит обнаружил не менее 913 устройств Hikvision и Dahua более чем на 250 государственных объектах. Министерство обороны заявило, что найденное у него оборудование будет удалено.

Индия, 2025 год. Для интернет-подключённых моделей CCTV ввели обязательные испытания в государственных лабораториях. По данным Reuters, требования распространялись на модели, произведённые или импортированные после 9 апреля 2025 года, и включали проверку аппаратной и программной частей; официальный контур сертификации ведёт STQC.

Общий сдвиг хорошо формулируется одним вопросом: не только «есть ли у камеры известная уязвимость сейчас?», но и «кому мы доверяем право изменить её программное состояние завтра?»

Почему фаервол, VPN и IDS/IPS не закрывают вопрос автоматически

Фаервол полезен, если правила действительно ограничивают и входящие, и исходящие соединения камеры. Но он не поможет, если TCP/37777 опубликован наружу или камера может без ограничений устанавливать соединения с облачным релеем.

VPN позволяет не открывать интерфейс администрирования в интернет. Это хорошая мера, но сам по себе VPN не исправляет уязвимую прошивку и не блокирует P2P-канал, если камера продолжает устанавливать его самостоятельно.

IDS помогает обнаруживать подозрительный трафик, а IPS может  автоматически его блокировать. Обе системы полезны только при наличии телеметрии и правил для реальных протоколов камер. Если трафик релея зашифрован и выглядит как разрешённое исходящее соединение, одной сигнатуры может оказаться недостаточно.

Иными словами, средства периметра остаются нужны. Просто камера стала самостоятельным сетевым узлом со своей ОС, учётными записями, облаком и жизненным циклом обновлений. Защищать её как «пассивный датчик» уже поздно.

Что проверить в своём парке камер

1. Сделать нормальную инвентаризацию

Для каждого устройства нужны как минимум: производитель, точная модель, аппаратная ревизия, серийный номер, SoC, версия и дата сборки прошивки, используемый SDK или платформа, включённые P2P/облачные сервисы, дата окончания поддержки.

Одного бренда недостаточно. Один и тот же SDK и механизм удалённого доступа может использоваться в нескольких линейках и OEM-ребрендах.

2. Убрать прямую публикацию служебных портов

Не стоит открывать наружу веб-интерфейс, RTSP-потоки, ONVIF и фирменные порты управления. Для администрирования лучше использовать VPN с многофакторной аутентификацией и отдельный бастионный узел. Доступ VMS/NVR, систем управления видео и сетевых видеорегистраторов, к камерам нужно разрешать только по необходимым адресам и портам. 

3. Проверить исходящие соединения

Можно взять тестовую камеру, изолировать её от остальной сети и посмотреть, куда она подключается после сброса, первичной настройки, привязки к приложению и обновления. Для этого можно записывать DNS-запросы и сетевые сессии. 

После этого проще понять, какие направления действительно нужны. Неиспользуемые P2P и облачные функции лучше отключить и затем проверить это на уровне сети, а не только положением переключателя.

4. Сегментировать видеонаблюдение

Камеры не должны иметь свободный доступ к пользовательской сети или интернету. Разрешить стоит только необходимые связи: VMS/NVR, NTP, DNS, локальный репозиторий обновлений и средства мониторинга. Управляющий доступ отделить от медиатрафика, если архитектура и оборудование это позволяют.

5. Управлять прошивками как программным обеспечением

Нужен реестр версий, проверка образов, тестовая группа устройств, план отката и понятный процесс обновления.

После выхода бюллетеня безопасности важно не только установить патч, но и проверить, сколько камер действительно обновилось. Для CVE-2021-33044 и CVE-2021-33045 лучше сверяться с перечнем затронутых моделей и исправленных сборок в бюллетене Dahua, а не только с версией, которую показывает сторонний сканер.

6. Искать не только старые версии, но и следы закрепления

Стоит проверить список локальных пользователей, неизвестные сервисные учётные записи, изменения конфигурации, аномальные входы и исходящие соединения.

Если есть признаки компрометации, одного сброса может быть недостаточно: лучше изолировать устройство, сохранить данные для расследования, установить заведомо доверенный образ прошивки и сменить связанные пароли, в том числе учётные данные, которыми камера подключается к NVR или VMS.

7. Подключить наблюдаемость

События аутентификации и административных изменений можно отправлять в SIEM или SOC. Также стоит контролировать появление TCP/37777 на внешнем периметре, отслеживать новые домены и адреса релеев и обращать внимание на необычные исходящие сессии.

IDS/IPS стоит дополнять анализом потоков и базовым профилем поведения устройств.

8. Зафиксировать требования к поставщику

В техническом задании полезно требовать публичные security advisories, сроки выпуска исправлений, подписанную прошивку, описание механизма secure boot, перечень внешних сервисов и доменов, возможность полного отключения P2P, срок поддержки модели и процесс уведомления об окончании поддержки. 

Хорошим дополнением будет SBOM, то есть список программных компонентов, и понятный способ сопоставить CVE с конкретными сборками.

Российские решения: где контроль, а где иллюзия?

Нет, российская камера не становится безопасной автоматически. Страна происхождения сама по себе не закрывает слабый пароль, ошибку аутентификации, непропатченный компонент или небезопасный облачный релей.

Но локальная разработка может дать реальное преимущество, если производитель действительно контролирует исходный код, сборочную систему, ключи подписи, загрузчик, сервер обновлений и выпуск патчей. Ключевое слово здесь «контролирует», а не «брендирует». 

Поэтому я бы оценивал не шильдик, а проверяемую цепочку:

  • кто разработал прошивку и на каких SDK и компонентах она собрана;

  • кто может воспроизвести сборку, исправить ошибку и подписать обновление;

  • какие внешние сервисы обязательны для работы и можно ли отключить P2P;

  • можно ли эксплуатировать систему полностью в изолированном контуре;

  • как быстро новые уведомление по безопасности  превращается в проверенный патч на реальном объекте.

У отечественного решения есть шанс сократить неконтролируемые зависимости. Но если внутри остаются непрозрачный SDK, внешний P2P-сервис и отсутствует процесс обновлений, меняется происхождение риска, а не сама модель риска.

Как мы смотрим на это в «Рувере»

Для нас это не абстрактная дискуссия. В «Рувере» мы регулярно отслеживаем ключевые публичные источники: Security Advisory производителей и upstream-поставщиков, CVE и NVD, каталог CISA KEV, БДУ ФСТЭК, сообщения CERT и НКЦКИ. Формулировка «мониторим всё» звучит красиво, но в инженерной работе важнее понятное покрытие источников и отсутствие разрыва между обнаружением и исправлением.

В практической работе это означает:

  • сопоставить публикацию с конкретной моделью, версией прошивки, SoC, SDK и сторонними библиотеками;

  • проверить, достижим ли уязвимый код в нашей сборке и при каких настройках;

  • подготовить компенсирующие меры или исправление и провести регрессионное тестирование;

  • довести обновление до эксплуатации и не потерять его на последнем келометре.

Подробнее о том, почему готовой прошивки оказалось недостаточно и как мы пришли к собственной разработке, я писал в отдельном материале на Habr.

Это долгосрочная работа: реестр компонентов, мониторинг, ключи подписи, сборочная инфраструктура, тестирование и поддержка должны жить столько же, сколько сама модель камеры. Иначе «контроль платформы» быстро превращается в разовую декларацию.

Отечественные уязвимости тоже существуют

Импортозамещение не отменяет CVE. Показательный пример вне камер, РЕД ОС. Производитель ведёт публичный раздел с уязвимостями и обновлениями безопасности, описывает затронутые пакеты и рекомендует устанавливать исправления.

Само наличие уязвимостей не говорит о том, что продукт плохой. Уязвимости находят в любых крупных программных системах. Качество процесса видно по другому: есть ли инвентаризация компонентов, насколько быстро команда определяет затронутые сборки, выпускает исправление, сообщает о риске и поддерживает обновление на объектах.

Что в итоге показывает CameraSwarm

Operation CameraSwarm не связана с какой-то одной катастрофической ошибкой. Всё получилось из нескольких вполне обычных проблем: 

  • открытый служебный порт;

  • повторяющиеся пароли;

  • прошивки без исправлений 2021 года;

  • служебная облачная инфраструктура;

  • массово одинаковая программная платформа.

Самый полезный вывод для владельца системы видеонаблюдения звучит так: камера должна учитываться не как периферийное устройство, а как полноценный компьютер с собственной цепочкой доверия.

И да, фаервол всё ещё нужен. Просто настоящий периметр теперь проходит не по границе локальной сети, а через прошивку, облако, сборочную систему, поставщика и процесс обновлений. Если хотя бы один из этих элементов никто не контролирует, там и появляется слепое пятно.

Вместо финальной точки

А как у вас организован контроль над критическими системами? Знаете ли вы, на каких платформах построены ваши камеры и контроллеры, какие внешние сервисы им нужны и когда в последний раз обновлялась прошивка?

Буду рад обсудить это в комментариях, особенно реальные процессы мониторинга уязвимостей и обновления больших парков камер.

Источники

ссылка на оригинал статьи https://habr.com/ru/articles/1079662/