Все началось с комментария для СМИ про атаки на умные гирлянды. В рамках комментария мало, что можно сказать, а настоящему ковбою всегда есть, что сказать. Зря я что ли два года продвигал решения по защите промышленных сетей и АСУ ТП. Умные гирлянды - это подвид IoT, умного дома или умного офиса. А умный дом – это частный случай промышленной сети. Но это не точно! Отсюда вывод - проблемы безопасности промышленных сетей наследуются умным офисом, домом и умными гирляндами, в частности. Вообще любым умным девайсом. Поэтому я буду писать умный дом(не буду брать его в кавычки) и при этом буду иметь ввиду умный дом, умный офис, умные гирлянды и IoT, в принципе. На промышленные сети тоже можно натянуть.
Как устроен умный дом
Датчики, переключатели, лампочки, розетки, камеры, механизмы закрывания штор, кондиционирование, увлажнение воздуха - устройства умного дома. Работают по Wi-Fi или, если нужна энергоэффективность по протоколам Zigbee, Thread и т.д.
Шлюз - связующее звено для устройств.
Мобильное/Веб приложение - основное приложение для управления всем этим зоопарком. Сценарии, расписания, уведомления - все тут.
Облачный бэкенд, расположенный где-то, но очень часто на стороне производителя – ваш аккаунт, хранение данных, удаленный доступ к устройствам умного дома из приложения в вашем телефоне.
Что имеет смысл отметить. Тот, кто разрабатывает умный дом, обычно не сильно заморачивается кибербезопасностью. Потому что time-to-market и ограниченные ресурсы разработки. Это делается для масс маркета, за плюс-минус небольшой прайс, а значит из многих мест будут торчать нитки, как из китайского ширпотреба в 90-ые. Эта проблема характерна также для промышленных сетей, так как там безопасность исторически оставляли «на потом» под предлогом того, что наложенные средства будут мешать/тормозить/усложнять взаимодействие и могут привести к драматическим последствиям.
Проблемы умного дома
Если начать искать слабые места в умном доме, то список будет выглядеть так:
Бэкенд
Backend «умного дома» - дырявый как решето:
Один backend на все страны.
Слабая авторизация или есть варианты, как ее обойти.
Отсутствие rate limit.
ID устройства - просто последовательный номер.
Результат:
можно управлять чужими устройствами;
можно собрать базу устройств;
иногда - получить доступ к Wi-Fi данным.
Умные люди заморочились и провели большое исследование.
Для тех, кто не готов читать длинные pdf на английском
«Large-Scale Security Analysis of Real-World Backend Deployments Speaking IoT-Focused Protocols» — большое академическое исследование, в котором были проанализированы более 337 000 IoT-бэкендов, общающихся по типичным IoT-протоколам (MQTT, CoAP, XMPP).
Они обнаружили, что многие серверы backend:
раскрывают информацию, которая не должна быть видна третьим сторонам;
используют слабую или отсутствующую аутентификацию;
очень большая часть (~99.8 %) использует нешифрованный транспорт (без TLS);
CoAP-бэкенды уязвимы к DoS-атакам.
Пример 1 "CloudPets — утечка данных через уязвимый бекэнд (MongoDB без пароля)"
В 2017–м была взломана облачная инфраструктура интерактивных игрушек CloudPets, в результате чего более 820 000 аккаунтов и 2,2 млн голосовых записей были публично доступны.
Данные были хранились в незащищённой базе MongoDB, без пароля, что позволило сторонним исследователям скачать всё содержимое и даже заменить базу с требованием выкупа через Bitcoin-адрес.
Пример 2 "Eaton SecureConnect - уязвимость в облачной платформе"
В облачной платформе Eaton SecureConnect, которая используется для управления умными охранными сигнализациями через мобильное приложение, была найдена критическая уязвимость типа Insecure Direct Object Reference (IDOR). Уязвимость позволяла любому зарегистрироваться в качестве нового пользователя и назначить эту учетную запись любой другой группе пользователей, включая группу «root», которая имеет доступ ко всем интеллектуальным системам сигнализации, подключенным к облаку Eaton.
Мобильное/веб приложение
Тут стандартные проблемы веб и мобильных приложений:
API-ключи в чистом виде;
токены доступа;
эндпоинты backend-серверов;
слабые алгоритмы авторизации.
Пример 1 "Исследование «Beware of the App!» - реальные уязвимости приложений для IoT"
Что обнаружили:
Коммуникация между мобильным приложением и IoT-устройством часто не шифруется и не аутентифицируется. Это позволяет злоумышленнику перехватить или подделать команды управления устройством;
В анализе 96 популярных Wi-Fi-устройств 50% приложений использовали ненадёжное шифрование или вовсе его не применяли;
На основе анализа приложений исследователи создали PoC-эксплойты, которые позволяли отправлять произвольные команды устройствам без участия пользователя.
Пример 2 "Kaspersky case‑study: обход аутентификации "умного дома" в облаке"
В описанном кейсе взлома коммерческой smart home‑системы исследователи нашли, что мобильное приложение запрашивает конфигурационный архив по HTTP у облачного сервера, а идентификатором устройства служит только серийный номер.
Перебором серийных номеров и воспроизведением тех же HTTP‑запросов злоумышленник мог получать конфигурацию чужого «умного дома» и затем входить в веб‑интерфейс, получая возможность управлять светом, водой и в теории — дверными замками. Мобильное приложение в этой схеме — основной клиент облака, через который была выявлена логика запросов.
Устройства/датчики
Прошивки
жёстко зашитые пароли (admin/admin, 12345678);
debug-интерфейсы (UART, Telnet, FTP);
отсутствие шифрования вообще или TLS без проверки сертификата;
ключи API, одинаковые для всех устройств партии.
OTA - обновления прошивки
нет проверки подписи прошивки;
прошивка скачивается по HTTP;
URL жёстко прописан в коде;
сервер обновлений давно заброшен или уехал на китайский CDN.
Аппаратная защита:
нет Secure Boot,
нет TPM / Secure Element,
флеш читается напрямую.
Примеров более чем на всех языках
Пример 1 "Mirai / BrickerBot"
Mirai — один из самых известных примеров IoT-эксплойтов, где устройства захватывались через открытые сервисы, дефолтные креды и открытый доступ по сети. Это иллюстрация массовой эксплуатации облачного доступа и серверов управления IoT-устройствами.
Цепочка атаки на умный дом
Исходя из вышеперечисленного, можно предположить цепочку атаки:
0. Модель угроз
Атакующий сразу понимает:
устройство дешёвое,
обновляется плохо,
безопасность вторична.
1. Разведка
Цель: понять, что за устройство и как оно живёт.
Типовые действия:
поиск модели по FCC ID / маркировке;
изучение мобильного приложения (Google Play / App Store);
поиск прошивок на сайте производителя или в CDN;
Shodan / Censys по сигнатурам HTTP / MQTT;
GitHub с утёкшими SDK и примерами;
поиск открытых API:
поиск документации.
2. Первоначальный доступ
Вариантов обычно несколько, выбирают самый дешёвый по времени. Самые частые:
устройство в режиме setup без аутентификации;
дефолтный пароль;
BLE без нормального явного сопряжения;
открытый MQTT topic;
уязвимость в backend API.
3. Выполнение кода
Когда доступ получен, начинается веселье. Типовые пути:
загрузка кастомной прошивки (подпись не проверяется);
команда через API (exec, debug endpoint);
переполнение буфера в сервисе управления;
shell через Telnet / UART.
4. Закрепление
Чтобы продолжить после перезагрузки:
модификация автозапуска;
подмена OTA-URL;
внедрение backdoor-сервиса;
отключение обновлений производителя.
5. Повышение привилегий (не факт что потребуется)
Часто не требуется — root уже есть сразу. Но если нет:
уязвимости в BusyBox;
старое ядро Linux;
SUID-бинарники;
кривые права на /etc/init.d.
6. Связь с командным центром (C2)
Типовые каналы:
MQTT (идеально маскируется);
HTTPS к легитимному домену;
DNS tunneling;
WebSocket.
Почему в целом IoT — кайф для C2:
трафик «шумный» и неприметный,
cоединения постоянные,
IDS/IPS/NTA дома обычно отсутствует.
7. Горизонтальные перемещения
Если все в одной сети с остальными устройствами:
сканирование LAN;
попытки входа на роутер;
атаки на NAS / камеры / smart TV;
sniffing трафика.
Цель найти «интересное» вокруг умного устройства.
8. Целевое действие
Варианты зависят от мотивации:
Массовая:
DDoS;
прокси;
криптомайнинг (да, даже на гирлянде);
перепродажа ботнета.
Целевая атака:
доступ в домашнюю/корпоративную сеть;
кража учёток Wi-Fi;
дальнейшее проникновение.
Умный дом или умный офис - идеальный «первый шаг».
9. Зачистка следов
Обычно:
чистят логи;
маскируют трафик под легитимный;
отключают debug-вывод.
Но чаще даже не заморачиваются. Кто там будет форензить умную лампочку?
Вывод такой - для дома это может быть опасно, если у вас максимальный уровень умного дома, автоматизация и все такое. Частный дом, где куча всего завязано друг на друга плюс сигнализация. Более опасно, когда это используется в офисе. Потому что их принесут в офис, их подключают в корпоративный Wi-Fi. Никто не ведёт их инвентаризацию и, следовательно, SOC о них не знает. А потом: «Мы не понимаем, откуда трафик и почему утекли учётки».
Варианты защиты и реагирования.
Они есть. На самом деле для домашнего пользователя советовать что-то бессмысленно - мало кто будет заморачиваться сменой дефолтных паролей или созданием отдельного сегмента wi-fi и дальнейшей настройки фаервола. А те, кто готов заморочиться, им мои советы не нужны. Поэтому кто дочитал эту простыню - добро пожаловать подкат
Варианты защиты и реагирования
0. До покупки
Не покупать заведомо токсичный IoT/умный дом/умный офис или его части.
Что делать:
проверять, есть ли у производителя сайт и обновления;
смотреть дату последнего firmware update;
гуглить модель + security, vulnerability, CVE;
избегать no-name брендов с «cloud required».
Чего не делать:
«О, дёшево и красиво» ;
покупать устройства без офлайн-режима.
Если нет обновлений — устройство одноразовое.
1. Сеть — ломаем первоначальный доступ
Самый важный пункт. 80% защиты здесь.
Сегментация сети - отдельный Wi-Fi / VLAN для умного дома и никакого доступа из этого сегмента сети в основной.
2. Wi-Fi и пароли — ломаем первоначальный доступ ещё раз
Обязательно:
WPA2/WPA3, никаких «open»;
разный пароль для IoT Wi-Fi;
длинный пароль (20+ символов).
Никогда:
один Wi-Fi на всё;
пароль от Wi-Fi = пароль от роутера;
12345678, даже временно.
Да, атакующие любят «временно».
3. Облачные аккаунты — ломаем Backend атаки
Делать:
отдельная почта для IoT-аккаунтов;
уникальный пароль;
2FA, если есть (редкость, но вдруг).
Не делать:
логин через Google / Apple ID;
использовать рабочую почту.
4. Мобильное приложение — ломаем Выполнение кода
Делать:
устанавливать только официальное приложение;
не давать лишние разрешения (контакты? серьёзно?);
обновлять приложение.
Не делать:
APK «с форума»;
старые версии «потому что работает».
5. OTA и прошивки — ломаем Закрепление
включить автообновления;
проверять changelog (если есть);
раз в квартал вручную проверять наличие апдейтов(кто у себя дома периодически проверяет апдейты хотя бы роутера?).
6. Физический доступ — ломаем всё сразу
Для офиса:
не вешать устройства «где попало»;
не подключать через USB «для зарядки»;
закрытые розетки / шкафы.
не покупать устройства с открытым UART.
Физический доступ = root за 5 минут.
7. Firewall — ломаем C2
Даже простой роутер может многое. Минимум:
блокировать исходящие соединения IoT, кроме нужных;
запрет MQTT, если не используется;
DNS только через ваш resolver.
Продвинутый уровень:
разрешения по domain allowlist;
IDS/IPS (OpenWRT + Suricata).
8. Логи и наблюдаемость — ломаем целевое действие
Делать:
смотреть список устройств в роутере;
проверять неизвестные MAC / IP;
мониторить трафик (хотя бы объёмы).
Признаки, что пришла беда:
постоянные соединения в странные страны;
DNS-запросы с рандомными именами.
9. Организационное — ломаем человеческий фактор
Для офиса:
запрет самовольных IoT;
список разрешённых моделей;
ответственность: «принёс гирлянду — ты владелец риска».
Для дома:
правило: умное = подозрительное;
минимум устройств;
если не пользуешься — отключай.
