Интернет вещей

В предыдущих частях мы обсуждали криптографию и безопасность сотовых сетей. В этой части мы обсудим интернет вещей (Internet of Things).

Что такое интернет вещей

Если посмотреть, что Wikipedia говорит о последней эволюции интернета под названием Internet Of Things (IoT), мы найдем формулировку примерно такого вида: "сеть физических объектов, устройств, транспортных средств, зданий и других предметов, оснащенных электроникой, программным обеспечением, сенсорами и сетевым подключением, которое позволяет этим объектам собирать данные и обмениваться ими". Звучит правдоподобно: Internet of Things — это сеть устройств. Сегодня подключено почти все: от бытовых устройств до промышленного оборудования. Они подключены, чтобы обмениваться данными.

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

Вдобавок нужно упомянуть количество таких устройств. В зависимости от исследования оценки варьируются от огромных до почти непостижимых. Например, IDC прогнозировала, что в 2025 году в мире будет около 42 миллиардов подключенных устройств. Такова площадка для этой части курса: гигантское количество не слишком умных устройств с интернет-соединением, основной задачей которых является обмен данными.

Звучит мрачно, и с точки зрения безопасности IoT действительно выглядит мрачно. Но помните: IoT — хорошая идея, и у нее есть место в мире. Например, промышленный IoT, где обмен данными для обслуживания и операционных целей делает промышленное оборудование более отзывчивым и полезным, а рабочую среду более безопасной. В сельском хозяйстве IoT используется для посадки, полива, сбора урожая и даже мониторинга почвы. В любом случае при реализации и развертывании любого умного устройства дома или в промышленности нужно соблюдать осторожность.

IoT далек от простой задачи для всех участников.

Экосистема IoT

Что с чем соединено и как? Изображение ниже показывает один возможный вариант экосистемы IoT. IoT-устройства подключаются к локальному хабу тем или иным способом. Это может быть что угодно: от Bluetooth и Wi-Fi до сотовой связи; среди более новых и интересных методов подключения есть протоколы вроде LoRa, Sigfox, NB-IoT и LTE-M. IoT-хаб или шлюз — это устройство, которое обслуживает устройства внутри одной локации, например дома. Иногда хаб отсутствует, и устройство подключается напрямую к облаку; обычно такие устройства используют сотовые соединения.

Из облака данные могут собираться для аналитики, которая обрабатывается в облаке или на некоторой IoT-платформе. Последняя сущность — удаленный пользователь, который использует панель управления, например мобильное приложение. Сюда входят смартфоны, планшеты, ПК и т. д.

Характеристики IoT

Далее мы рассмотрим некоторые характеристики, определяющие IoT. Эти характеристики разделены на две категории: устройство и сеть.

Ограничения с точки зрения устройства

Существует много видов устройств. Их можно разделить на две категории: мощные и маломощные. К мощным устройствам относятся, например, ноутбуки и смартфоны, а к маломощным — сами датчики и исполнительные устройства. Есть еще одна подкатегория — пассивные устройства. К ним относятся штрихкоды, RFID и NFC. Что именно считать устройством с ограниченными ресурсами? Популярное определение звучит примерно так: "устройство с ограниченными возможностями обработки и хранения, часто работающее от батарей". Ниже приведен список из RFC 7228. Устройство можно считать ограниченным, если один или несколько пунктов списка накладывают на него существенные ограничения.

• Максимальная сложность кода (ROM/Flash)
• Размер буферов состояния (RAM)
• Объем вычислений, возможный за определенный период времени (вычислительные возможности)
• Доступная энергия
• Пользовательский интерфейс и доступность при развертывании (задание ключей, обновление ПО)

Тот же документ также дает более подробную классификацию устройств, но для этой части курса нам достаточно такого уровня.

Ограничения сети

Как существует много видов устройств, так существует и много видов сетей. Самый распространенный способ связи — проводная связь, хотя для IoT-устройств она не так популярна, по крайней мере для небольших устройств. Беспроводная связь популярнее среди IoT-устройств. Ее можно разделить на методы дальнего, среднего и короткого радиуса. Сотовые сети вроде 4G и 5G относятся к дальнему радиусу. Средний радиус в основном включает Wi-Fi. Наконец, методы короткого радиуса, такие как Bluetooth, Zigbee и 6LoWPAN, наиболее полезны в персональных и домашних сетях.

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

Текущие сети могут иметь проблемы с задержкой, вызванные сложной маршрутизацией. Надежность сетей сильно различается, и отказы проявляются по-разному в разных сетях и местах. Даже полные сетевые сбои не так уж редки; иногда они могут быть вызваны атаками. Меньшие проблемы, наблюдаемые в сетях, варьируются от низкой пропускной способности до потери пакетов, фрагментации пакетов и асимметричных характеристик канала.

В интернете архитектурные схемы коммуникации в основном следовали традиционному клиент-серверному паттерну. Мы также видели появление peer-to-peer (P2P) паттернов, а сравнительно недавно — рост облачных подходов в коммуникационной архитектуре. IoT добавляет новый поворот к привычным схемам. Главное отличие - паттерн устройство-устройство (device-to-device, D2D), при котором устройства говорят напрямую с другими устройствами. В большинстве случаев такая коммуникация обрабатывается без IP с помощью протоколов вроде RFID, NFC, 6LowPAN (да, это IPv6, но с сильно сжатыми заголовками и без пограничного маршрутизатора не может взаимодействовать с IP), ZigBee и Bluetooth. Этот паттерн сильно полагается на безопасное сопряжение устройств, а безопасность в основном реализуется на канальном уровне. Облако может быть партнером по коммуникации для устройства. Однако в большинстве IoT-сценариев устройство не общается с облаком напрямую, а использует посредников вроде шлюза или смартфонов. Это можно рассматривать как расширение паттерна device-to-device: устройство сначала использует D2D-паттерн, а затем соединение перенаправляется в облако. Протоколы первого перехода обычно почти такие же, как для D2D, иногда с добавлением Wi-Fi. С точки зрения безопасности это сложнее. Как эффективно обеспечить сквозную безопасность (end-to-end security) от устройства через посредника к облаку? Помните, что само устройство и используемый метод связи могут быть ограничены по ресурсам, а соединение с облаком может требовать большей защиты. Для соединения с облаком часто используются протоколы вроде EAP, AAA и PANA для аутентификации доступа к сети. В некоторых случаях устройства общаются между собой в локальной сети. Это можно рассматривать как подслучай паттерна device-to-cloud через шлюз, но в этом паттерне устройства используют шлюз для коммуникации с другими устройствами в той же локальной сети. Иногда безопасность неразумно опускают или делают слабой на основании предположения, что трафик идет только в локальной сети, а главная защита заключается в аутентификации устройств. Если повезет, можно коммуницировать напрямую с облаком с устройства, которое, например, имеет сотовый радиомодуль и достаточно циклов CPU для корректной криптографии. Тогда можно легко использовать аутентификацию сетевого доступа и функции сквозной безопасности.

Защита IoT

Не так давно рассказ о том, что огромное количество IoT-устройств, например CCTV камер, атаковали провайдеров DNS-сервисов и сделали несколько известных сайтов недоступными, мог бы звучать как сюжет фильма. Это было вредоносное ПО Mirai в 2016 году, который находило IoT-устройства с сетевым подключением. Эффективность метода получения доступа к устройствам с использованием списка паролей по умолчанию должна настораживать. Да, он действительно использовал список из 60 распространенных паролей по умолчанию для распространения, и это было эффективно, потому что люди не меняли пароли. Устройства просто подключали и оставляли работать.

IoT растет все быстрее. Он меняет нашу жизнь невиданным образом: от рабочих мест до домов. С IoT можно делать много полезных вещей, но есть и обратная сторона. Все эти подключенные устройства очень интересны киберпреступникам. Они дают преступникам больше возможных векторов атак против нас. Кроме того, помните, что в вашем телефоне больше вычислительной мощности, чем в компьютерах эпохи Apollo. И это еще не говоря об объеме очень личных данных, которые вы носите с собой в телефоне. Для преступников это очень интересно. Нам нужно быстро решать эту проблему, пока не стало слишком поздно.

Почему IoT-устройства остаются незащищенными или с паролями по умолчанию? Возможно, их конфигурация сложна: настройка или обновление устройства без экрана может быть слишком трудной для большинства обычных пользователей, это та самая труднодостижимая удобная безопасность (usable security). Это может быть простая ошибка, или еще проще: владельцы устройств могут считать IoT-устройства неважными устройствами с ограниченными ресурсами, которые не содержат ничего значимого. Однако им стоит беспокоиться. Они должны понимать, что большое число IoT-устройств может создать огромный объем нежелательного трафика и вызвать Distributed Denial of Service (DDoS)-атаки. Кроме того, они должны понимать, что преступники могут рассматривать устройства как способ получить доступ к другим системам в сети, к которой подключены IoT-устройства, то есть использовать их как плацдарм для атаки. IoT-устройства могут быть незащищенными точками входа в сети. Дочитав до этого места, вы могли подумать, что все эти проблемы могут исходить только от пользователей, поскольку производители вообще не обсуждались. Нужно сказать, что многие производители IoT-устройств не являются экспертами по безопасности; некоторые лучше других, но обобщать нельзя. Если вы всю жизнь строили бытовые устройства и входите в IoT-бизнес с подключенным устройством, которое отправляет сообщения в сеть, вы можете не считать безопасность самым важным фактором. Вы можете думать о марже прибыли и т. д. С другой стороны, когда вы покупаете такое устройство, первый вопрос обычно не звучит как: "какие порты открыты и какие функции безопасности оно реализует". Вопросы, скорее всего, будут сосредоточены на результате работы устройства. Поэтому дело не только в пользователях: нам всем нужен стимул закладывать безопасность и требовать ее.

Какие существуют подходы к защите IoT-устройств

Безопасность должна быть встроенной частью жизненного цикла разработки как IoT-устройства, так и ПО, используемого вместе с ним. Как мы уже увидели, существует большое количество устройств с коммуникационными функциями, которых раньше у них не было. Эти устройства всегда подключены и используют однократную аутентификацию. Это отчасти понятно, если подумать: стали бы вы больше одного раза безопасно сопрягать и аутентифицировать лампы в доме, то есть не только во время установки? Вы просто хотите, чтобы они включались.

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

Сетевая безопасность IoT немного сложнее традиционной сетевой безопасности, потому что существует более широкий диапазон коммуникационных протоколов, стандартов и возможностей устройств, и все это создает существенные проблемы и дополнительную сложность. Ключевые функции здесь включают традиционные средства безопасности конечных устройств, такие как сбор, агрегация, мониторинг и нормализация данных от IoT-устройств. По причинам безопасности нужны прикладные отчеты и оповещения по конкретным действиям или аномалиям. Традиционные меры кибербезопасности использовали методы вроде антивирусного ПО и систем обнаружения вторжений. Эти системы, хотя и выглядят небольшими мерами, по-прежнему играют большую роль в общей безопасности. Нужно больше работать над обнаружением атак и вторжений, специфичных для IoT, которые не обнаруживаются традиционными решениями сетевой безопасности. Хотя традиционные меры эффективны при обнаружении известных атак, их неспособность обнаруживать zero-day-атаки является проблемой. Сейчас разработчики и исследователи таких приложений добавляют машинное обучение и искусственный интеллект для предиктивного моделирования, чтобы повысить точность обнаружения и, возможно, находить ранее неизвестные атаки. Однако часть этих возможностей все еще находится на ранней стадии.

REST API, часто используемые с IoT, предоставляют сервисы аутентификации и авторизации для перемещения данных между умными устройствами, бэкенд-системами и приложениями. Безопасность API критически важна для того, чтобы с API общались только авторизованные устройства и приложения. API также можно использовать для обнаружения потенциальных угроз против соответствующего API.

В анализе угроз IoT безопасно предполагать, что атакующий полностью контролирует коммуникации устройства. Атака может быть двух типов: атакующий может быть пассивным и подслушивать трафик или активным и отправлять, например, поддельные пакеты. Атакующий может находиться on-path или off-path. On-path-атакующий обычно считается Man-in-the-middle и активно вмешивается в текущую коммуникацию. Off-path-атакующий отправляет пакеты, содержащие поддельную информацию, например IP отправителя.

В предыдущей части серии курса мы обсуждали анализ угроз, но мало говорили о его ограничениях. Анализ угроз может дать хорошие требования, которые нужно учитывать при проектировании устройств; полезные документы можно найти в IETF, например State-of-the-Art and Challenges for the Internet of Things Security, draft-irtf-t2trg-iot-seccons-09 или RFC 3552: Guidelines for Writing RFC Text on Security Considerations. Однако они могут быть несколько теоретическими и оставлять место для интерпретации при реализации устройства или ПО. Где возникает интерпретация? Например, нужно решить, на каком уровне добавляется безопасность и какая именно безопасность используется; применять проверенные протоколы лучше, чем реализовывать собственные. Как обсуждалось ранее, анализ может быть сложным, и для IoT это тоже верно, поскольку IoT-система может содержать намного больше устройств, они ограничены по ресурсам и используют много разных способов коммуникации, открывая гораздо больше векторов атак.

Можем ли мы учиться на уже увиденных атаках

Мы дошли до этого места и поняли важность безопасности IoT. Мы также отметили, что традиционные меры безопасности работают в некоторой степени, но нужно и что-то новое. Что можно сделать для улучшения ситуации? Если смотреть на атаки, можно ли чему-то научиться? На первый взгляд в IoT-атаках не так много нового, и большинство атак, которые мы видели в последнее время, основаны на довольно базовых уязвимостях, например на использовании паролей по умолчанию, которые, кстати, обычно опубликованы на сайте производителя, то есть найти их не так сложно. Другие базовые ошибки, использованные некоторыми атаками, включают простые вещи вроде отсутствия шифрования в беспроводной связи или атак directory traversal против веб/FTP-серверов, где переданный путь не проверяется на разумность и запись идет в конфигурационные файлы и т. д.

Что насчет коммуникационных протоколов в IoT? Оценивается, что примерно 90% угроз для IoT направлены против коммуникационных сервисов, протоколов и сред передачи. Большая часть этих угроз общая с другими интернет-протоколами. Есть коммуникационные протоколы с механизмами безопасности, специально разработанными для IoT, и они могут помочь: например Message Queuing Telemetry Transport (MQTT) и Constrained Application Protocol (CoAP). Работа по стандартизации в основном была выполнена для CoAP (2014), а для MQTT она продолжается. Принятие этих протоколов стало популярным среди IoT-разработчиков.

В следующих разделах мы рассмотрим некоторые распространенные атаки. Начнем с физической атаки, которая очевидно требует доступа к физическому устройству. Затем кратко обсудим распространенные проблемы конфигурации, паролей и безопасности коммуникаций, а в конце поговорим об обновлениях ПО.

Что если устройство можно взять в руки?

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

Что считать физической атакой на компьютерную систему? Вот несколько примеров атак, которые были бы плохи для IoT: большинство умных устройств имеют какой-то отладочный или тестовый интерфейс, который можно использовать для коммуникации с устройством. Атакующий может попытаться прослушивать межшинные коммуникационные интерфейсы, такие как Inter-Integrated Circuit (I2C) или Serial Peripheral Interface (SPI), получить дампы с микросхем, используемых в устройстве, и извлечь, например, ключи. Более сложные атаки включают атаки на сбои (glitch attacks), где вы пытаетесь манипулировать тактовыми сигналами в микросхемах, поскольку современное цифровое оборудование работает на основе надежного тактового сигнала, синхронизирующего схемы. Если вмешаться в тактовый сигнал, можно заставить оборудование делать непредусмотренные вещи и побочным эффектом заставить его пропускать важные проверки. Атакующий может даже мониторить энергопотребление во время вычисления AES и выяснить секретный ключ (K. Meritt "Differential Power Analysis attacks on AES"). И наконец, физическая атака может быть намеренным физическим повреждением оборудования. Иногда атакующий может заставить системных администраторов срочно внедрить неаккуратное исправление и попасть внутрь во время хаоса.

Проблемы управления ключами

Шифрование данных при хранении и передаче между устройствами или облаком важно. Кроме того, важно использовать стандартные криптографические алгоритмы и не скатываться в безопасность через сокрытие (security by obscurity): лучше использовать корректно проверенные алгоритмы, чем что-то, о чем вы только слышали, что оно безопасно. Однако гетерогенная природа IoT-устройств — один из крупнейших ограничивающих факторов для использования стандартных процессов и протоколов. Кроме того, управление ключами становится проблемой: чтобы шифрование работало правильно, его должен сопровождать процесс управления жизненным циклом ключей от начала до конца. Может быть проще сделать что-то другое или пропустить этот шаг, но ошибка здесь приведет к проблемам. Например, персональная система освещения HUE просто вычисляла MD5-сумму от MAC-адреса лампочки и использовала ее как секретный токен для управления лампочками (статья Nitesh Dhanjani о безопасности HUE: материал). Другой пример: лампы LIFX как минимум использовали симметричное шифрование AES, но один и тот же ключ для всех лампочек (см. пост Alex Chapman на Context о реверс-инжиниринге лампочек: пост).

Управление жизненным циклом

Одна из самых интересных проблем безопасности IoT-устройств — управление жизненным циклом этих устройств. Просто представьте десятки миллиардов устройств, развернутых в реальном мире. Устройства имеют ограничения, ограничивающие их способность выполнять обычную криптографию с достаточно длинными ключами. Кроме того, устройства могут не иметь простого способа коммуницировать с пользователем. Теперь представьте, что после отправки десятков тысяч устройств производителем в них находят серьезную уязвимость. Есть ли хороший способ это исправить? Например, домашний шлюз Huawei использовал RomPager, у которого была уязвимость Misfortune Cookie (CVE-2014-9223). Разработчик веб-сервера выпустил исправление для устройства, но спустя годы проблема сохраняется, поскольку уязвимые устройства все еще существуют. Почему так? Одна причина может быть в том, что нет хорошего, простого и безопасного способа, с которым справится человек без профильного технического образования, загрузить новую прошивку, например на маршрутизатор. Что можно сделать? Одним решением может быть сетевой сервис, который мониторит устройства и выявляет уязвимые. Такое снятие сетевых отпечатков предлагалось и раньше; пример — DHCP fingerprinting, при котором DHCP-сервер запрашивает дополнительную информацию об устройстве. Что делать, когда вредоносные или уязвимые устройства найдены в сети, и как они могут сосуществовать с другими устройствами? Тренд, похоже, состоит в изоляции уязвимых устройств в разные VLAN. Это важная проблема, о ней много говорили, и, например, по крайней мере IETF начала работать над стандартным способом ее решения; см. charter рабочей группы IETF Security Area по этой теме.

Хорошие практики

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