Смотрю второй сезон «Кибердеревни» (рекомендую вам глянуть сериальчик, мне нравится) и до…

Смотрю второй сезон «Кибердеревни» (рекомендую вам глянуть сериальчик, мне нравится) и дошёл до четвертой серии, в которой «Ижевск Дайнемикс» массово отправляет своих роботов-уборщиков на утилизацию. Главный герой звонит папе-хакеру (шутки про кибердеда), тот со своими приятелями из санатория «взламывает» компанию и отменяет протокол — всё спрессовано в 25 минут комедии и веселого саундтрека. Там, конечно, использовали кучу разных узких терминов типа спуфинга, брутфорса и прочего, но это так, чтобы смотрелось аутентично (по крайней мере термины использовали реальные, хоть и не особо к месту)

Но давайте разберем, как в реальности происходят подобные взломы (сугубо в исследовательских и образовательных целях 🤝)

На самом деле подобные атаки проходят в несколько этапов. Это та самая классическая модель атаки, которую исследователи по IoT и робототехнике описывают годами. Вот и давайте разберемся, как это выглядит (исключительно по верхам), и как от этого защищаться

Сначала всегда происходит этап разведки (OSINT в том числе). Прежде чем приступить к взлому, злоумышленники собирают информацию: какие модели роботов используются; какие протоколы используются; какие открытые порты и API видны снаружи; какие DNS-записи и сертификаты у компании имеются; есть ли публичные репозитории (где забыли спрятать токены). Разведка даёт понимание того, как вообще начать атаку (через что) 💀

Дальше initial access. Это самые банальные вещи: стандартные пароли, необновлённые прошивки, уязвимости в API или мобильном приложении, утечки токенов, небезопасный OTA-процесс без подписи. Исторически именно такие бреши (слово то какое) позволяли Mirai и десяткам других ботнетов существовать в принципе

После доступа нужно закрепиться. Злоумышленник ставит устойчивый агент или крадёт учётки, ищет соседние устройства в той же сети или в той же облачной учётной записи, поднимает права. Тут уже важна архитектура: если роботы и административные сервисы живут в одной плоскости сети, то перескочить с одной машины на другую проще, чем кажется. Примеры с OT/SCADA показывают, что сочетание локального присутствия + целевой логики превращает информационный инцидент в физическую проблему 🧐

Затем C2 — командно-управляющая инфраструктура. Управлять флотом из сотен устройств удобно через централизованный канал (а не по SSH на каждого робота), зашифрованный или замаскированный трафик, распределённые прокси

И в итоге после вот этого всего уже устраиваем само шоу. Когда у нас по сути все готово. Чаще всего через легитимные функции устройства. Это основной момент: злоумышленник обычно не изобретает новые механизмы, а использует существующую функциональность. Когда мы уже и доступ получили, и закрепились, и подготовили все для управления — отправить нужные команды, и все. Это финальная точка атаки 🫡

Какие уязвимости чаще всего встречаются в исследованиях и кейсах? Прошивки без проверки подписи, слабые пароли и отсутствие MFA, небезопасные мобильные приложения и API (утечки токенов), отсутствие сетевой сегментации, задержка с патчингом и уязвимости в сторонних библиотеках

Соответственно, очевидно, что защищаемся через сегментацию сети и принцип наименьших привилегий; проверку подписи и целостности прошивок; безопасные OTA и защищённые каналы; MFA и ротацию ключей для облачных и админских учёток; мониторинг аномалий телеметрии и поведенческий IDS для устройств; готовые планы инцидент-реакции и «безопасные режимы», которые можно включить централизованно и которые минимизируют физический вред 🧠

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

P.S. Второй пост за выходные. Да я в ударе

#информационная_безопасность
#интернет_вещей