Почему безопасность IoT — это катастрофа
В октябре 2016 года ботнет Mirai заразил 600 000 IoT-устройств (камеры, роутеры, DVR) и устроил DDoS-атаку на DNS-провайдер Dyn. Упали Twitter, Netflix, GitHub, Reddit — полинтернета. Причина: дефолтные пароли admin:admin на камерах видеонаблюдения.
С тех пор мало что изменилось. Исследование 2025 года показало: 57% IoT-устройств имеют критические уязвимости, 98% трафика между устройством и облаком передаётся без шифрования, у 83% устройств нет механизма безопасного обновления прошивки.
OWASP IoT Top-10 — это список 10 самых критичных уязвимостей IoT-устройств, составленный Open Worldwide Application Security Project. Последняя версия — 2018 года, но все 10 пунктов актуальны в 2026. Разберём каждый с примерами и рекомендациями.
I1: Weak, Guessable, or Hardcoded Passwords
Слабые, угадываемые или зашитые пароли
Проблема
Самая распространённая уязвимость IoT. Три формы:
- Дефолтные пароли:
admin/admin,root/root,admin/1234— устройство из коробки доступно любому - Hardcoded credentials: пароль зашит в прошивке и не может быть изменён. Извлекается реверсом бинарника за 5 минут
- Отсутствие brute-force защиты: нет ограничения на количество попыток — пароль подбирается за часы
Пример атаки
Mirai сканировал интернет на открытый Telnet (порт 23) и перебирал список из 62 пар логин/пароль, характерных для IoT-устройств. Среди них: root:xc3511, root:vizxv, admin:admin. Этого хватило для 600K устройств.
Как защитить
| Мера | Реализация |
|---|---|
| Уникальный пароль из коробки | Генерировать при производстве, печатать на наклейке |
| Принудительная смена при первом входе | Не давать доступ к функциям до смены |
| Запрет слабых паролей | Минимум 8 символов, проверка по словарю |
| Rate limiting | Блокировка после 5 неудачных попыток на 15 минут |
| Нет Telnet, SSH по ключам | Telnet передаёт пароль в открытом виде |
I2: Insecure Network Services
Небезопасные сетевые сервисы
Проблема
Устройство слушает на сетевых портах сервисы, которые не нужны для его работы, уязвимы или неправильно настроены:
- Открытый Telnet, FTP, UPnP
- Веб-интерфейс без HTTPS
- Debug-порты, оставленные в продакшен-прошивке (JTAG через сеть, GDB-сервер)
- MQTT-брокер без аутентификации
Пример атаки
В 2019 году исследователи обнаружили, что тысячи MQTT-брокеров промышленных IoT-систем доступны из интернета без пароля. Любой мог подписаться на топики и читать данные с датчиков — температуру, давление, статус оборудования. Или публиковать команды.
Как защитить
| Мера | Реализация |
|---|---|
| Минимум открытых портов | Только то, что нужно. nmap при каждом релизе |
| Нет debug-сервисов в продакшене | Условная компиляция: #ifdef DEBUG |
| Все соединения — TLS | Даже в локальной сети (mTLS для MQTT) |
| Firewall на устройстве | iptables/nftables для Linux, фильтрация в RTOS |
| UPnP отключён по умолчанию | UPnP — источник NAT-пробивок и атак |
I3: Insecure Ecosystem Interfaces
Небезопасные интерфейсы экосистемы
Проблема
IoT-устройство — часть экосистемы: мобильное приложение, облачный backend, веб-панель, API. Уязвимость в любом компоненте компрометирует всю систему:
- API без аутентификации или с предсказуемыми токенами
- Мобильное приложение хранит credentials в открытом виде
- Веб-панель с XSS/SQLI
- Облачный backend с IDOR (доступ к чужим устройствам по ID)
Пример атаки
В 2020 году исследователь обнаружил, что API умных замков одного производителя использовал последовательные числовые ID для устройств. Изменив ID в запросе, можно было открыть чужой замок. Классический IDOR.
Как защитить
| Компонент | Меры |
|---|---|
| API | OAuth 2.0, JWT с коротким TTL, rate limiting |
| Мобильное приложение | Certificate pinning, безопасное хранилище (Keychain/Keystore) |
| Веб-панель | CSP, CSRF-токены, параметризованные запросы |
| Облако | RBAC, аудит доступа, шифрование данных at rest |
| Все интерфейсы | Пентест перед каждым релизом |
I4: Lack of Secure Update Mechanism
Отсутствие безопасного механизма обновлений
Проблема
Устройство не может обновлять прошивку, или обновление небезопасно:
- Нет OTA-обновлений вообще (уязвимость навсегда)
- Обновление по HTTP без шифрования (MITM → подмена прошивки)
- Нет проверки подписи (любой может загрузить свою прошивку)
- Нет отката (битое обновление = кирпич)
Пример атаки
Атакующий в той же Wi-Fi сети перехватывает HTTP-запрос на обновление прошивки (MITM), подменяет бинарник на свой. Устройство ставит вредоносную прошивку, становится частью ботнета. Без проверки подписи устройство не может отличить легитимное обновление от поддельного.
Как защитить
| Мера | Реализация |
|---|---|
| Подпись прошивки | Ed25519 или ECDSA. Публичный ключ в bootloader |
| Безопасный загрузчик | MCUboot (Zephyr), ESP Secure Boot |
| A/B-схема обновлений | Две партиции: если новая не загрузилась — откат на старую |
| Шифрование канала | TLS 1.3 для скачивания, проверка сертификата сервера |
| Delta-обновления | Передавать только diff — экономия трафика для LPWAN |
| Принудительные обновления | Для критических CVE — обновлять без согласия пользователя |
I5: Use of Insecure or Outdated Components
Использование небезопасных или устаревших компонентов
Проблема
Прошивка содержит сторонние библиотеки с известными уязвимостями:
- OpenSSL 1.0.x с Heartbleed
- BusyBox с CVE в ash/wget
- Ядро Linux 3.x без патчей безопасности
- Старая версия lwIP/mbedTLS
Многие IoT-производители собирают прошивку один раз и никогда не обновляют зависимости. Устройство выходит на рынок с уязвимостями, которые были исправлены годы назад.
Как защитить
| Мера | Реализация |
|---|---|
| SBOM (Software Bill of Materials) | Список всех компонентов с версиями |
| CVE-мониторинг | Автоматический сканер (Yocto cve-check, Trivy, Grype) |
| Политика обновлений | Критические CVE — патч в течение 30 дней |
| Минимум зависимостей | Меньше кода = меньше поверхность атаки |
| Статический анализ | Coverity, CodeQL, PVS-Studio для C/C++ |
I6: Insufficient Privacy Protection
Недостаточная защита конфиденциальности
Проблема
Устройство собирает и передаёт персональные данные без необходимости или без защиты:
- Камера стримит видео в облако без шифрования
- Фитнес-трекер отправляет геолокацию в открытом виде
- Умная колонка записывает разговоры и хранит на сервере
- Данные пользователя доступны другим пользователям через API
Как защитить
| Мера | Реализация |
|---|---|
| Минимизация данных | Собирать только то, что нужно для функции |
| Шифрование at rest | AES-256 для хранения на устройстве и в облаке |
| Шифрование in transit | TLS 1.3 для всех каналов |
| Анонимизация | Не привязывать данные к пользователю, если не нужно |
| Согласие пользователя | Явный opt-in для сбора данных (GDPR, 152-ФЗ) |
| Право на удаление | API для удаления всех данных пользователя |
I7: Insecure Data Transfer and Storage
Небезопасная передача и хранение данных
Проблема
Данные передаются или хранятся без шифрования, с использованием слабых алгоритмов или с доступными ключами:
- MQTT без TLS (данные в открытом виде в Wi-Fi)
- Ключи шифрования зашиты в прошивке (одинаковые на всех устройствах)
- Логи с чувствительными данными на SD-карте без шифрования
- Токены в plaintext в EEPROM/Flash
Как защитить
| Мера | Реализация |
|---|---|
| TLS для всех соединений | Даже в локальной сети |
| Уникальные ключи на устройство | Генерировать при производстве, хранить в Secure Element |
| Secure Element / TEE | ATECC608, OPTIGA Trust, ARM TrustZone |
| Нет секретов в прошивке | Ключи — в Secure Element, не в Flash |
| Шифрование Flash | Полнодисковое шифрование (ESP Flash Encryption, STM32 PCROP) |
I8: Lack of Device Management
Отсутствие управления устройствами
Проблема
Нет возможности управлять парком устройств после развёртывания:
- Нет инвентаризации (сколько устройств, какие версии прошивок)
- Нет мониторинга (устройство упало — никто не знает)
- Нет удалённого доступа для диагностики
- Нет деактивации (украденное устройство продолжает работать)
- Нет сегментации (IoT-устройства в той же сети, что и корпоративные ПК)
Как защитить
| Мера | Реализация |
|---|---|
| Device registry | Централизованный реестр: ID, версия, статус, владелец |
| Мониторинг heartbeat | Устройство регулярно отчитывается; нет heartbeat → алерт |
| Remote access | Безопасный туннель (WireGuard, SSH) для диагностики |
| Деактивация | Возможность заблокировать устройство из облака |
| Сетевая сегментация | Отдельный VLAN для IoT, firewall между сегментами |
| Аудит логов | Кто, когда, что делал с устройством |
I9: Insecure Default Settings
Небезопасные настройки по умолчанию
Проблема
Устройство из коробки настроено небезопасно, и пользователь не меняет настройки:
- Открытый Wi-Fi точка доступа для первоначальной настройки (без пароля)
- Все функции включены (даже те, что не нужны пользователю)
- Debug-режим включён по умолчанию
- Шифрование отключено «для совместимости»
- Firewall отключён
Как защитить
| Мера | Реализация |
|---|---|
| Secure by default | Минимум функций включён, шифрование включено |
| Временная точка доступа | AP для настройки работает 5 минут, с паролем на наклейке |
| Нет debug в продакшене | Условная компиляция, fuse-бит для отключения JTAG |
| Hardening guide | Документация для администратора: что проверить после установки |
| Автоматический hardening | Устройство само проверяет настройки и предупреждает |
I10: Lack of Physical Hardening
Отсутствие физической защиты
Проблема
Атакующий с физическим доступом к устройству может:
- Считать прошивку через JTAG/SWD и извлечь ключи
- Подключиться к UART-консоли и получить root-shell
- Снять Flash-чип и прочитать данные
- Модифицировать прошивку и вернуть устройство обратно
Пример атаки
Исследователь покупает умную камеру, подключается к UART (4 контакта на плате), получает shell с root-правами, извлекает private key от облачного API. Этот ключ одинаковый на всех камерах этой модели. Теперь у атакующего доступ ко всем камерам.
Как защитить
| Мера | Реализация |
|---|---|
| Отключить JTAG/SWD в продакшене | OTP fuse bit (STM32 RDP Level 2, ESP32 eFuse) |
| Отключить UART-консоль | Или защитить паролем |
| Secure Boot | Проверка подписи при загрузке — модификация невозможна |
| Flash Encryption | Даже если считали — данные зашифрованы |
| Tamper detection | Датчик вскрытия корпуса → стирание ключей |
| Уникальные ключи | Компрометация одного устройства не компрометирует остальные |
Чеклист безопасности IoT-устройства
Сводная таблица — используйте при проектировании и code review:
| # | Категория | Проверка | Приоритет |
|---|---|---|---|
| 1 | Аутентификация | Уникальный пароль из коробки | Критический |
| 2 | Аутентификация | Нет hardcoded credentials в прошивке | Критический |
| 3 | Аутентификация | Rate limiting на все точки входа | Высокий |
| 4 | Сеть | Только необходимые порты открыты | Критический |
| 5 | Сеть | Все соединения через TLS 1.2+ | Критический |
| 6 | Сеть | MQTT/CoAP с аутентификацией | Высокий |
| 7 | Обновления | OTA с подписью прошивки | Критический |
| 8 | Обновления | A/B-схема с откатом | Высокий |
| 9 | Обновления | Secure Boot включён | Высокий |
| 10 | Компоненты | SBOM актуален, CVE-мониторинг | Высокий |
| 11 | Компоненты | Нет компонентов с известными CVE | Критический |
| 12 | Данные | Шифрование at rest и in transit | Высокий |
| 13 | Данные | Ключи в Secure Element, не в Flash | Высокий |
| 14 | Данные | Минимизация собираемых данных | Средний |
| 15 | Управление | Device registry и мониторинг | Средний |
| 16 | Управление | Возможность удалённой деактивации | Средний |
| 17 | Физическая | JTAG/SWD отключён в продакшене | Высокий |
| 18 | Физическая | Flash Encryption включена | Высокий |
| 19 | Настройки | Secure by default | Высокий |
| 20 | Настройки | Debug отключён в продакшене | Критический |
Итого
OWASP IoT Top-10 — это не теоретический список. Каждый пункт — реальные атаки, реальные ботнеты, реальные утечки данных. Большинство уязвимостей IoT — не сложные zero-day эксплоиты, а банальные ошибки: дефолтные пароли, отсутствие шифрования, забытый debug-порт.
Три самых важных действия, которые закрывают 80% рисков:
- Уникальные credentials на каждое устройство (не
admin:admin) - TLS везде — между устройством и облаком, между устройством и приложением
- Подписанные OTA-обновления с Secure Boot — чтобы закрывать уязвимости после выпуска
Стоимость внедрения этих мер на этапе проектирования — 5–10% от бюджета разработки. Стоимость устранения последствий взлома — несопоставимо больше.
Хотите убедиться, что ваше IoT-устройство безопасно? Мы делаем экспресс-аудит IoT-идеи за 25 000 ₽: архитектура, безопасность, протоколы, компоненты — за 5 рабочих дней. Или посмотрите наши услуги по IoT и embedded-разработке.