Опасный IoT. Как найти уязвимые устройства и что мешает их взломать

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

Миллиарды потенциальных целей

По данным Statista.com, объем рынка интернета вещей в 2017 году превысил миллиард долларов. Общее число подключенных к интернету устройств оценивается на текущий момент в 30 с лишним миллиарда с перспективой увеличения до 40 миллиардов к 2021 году. После этого аналитическое агентство IHS Markit прогнозирует нелинейный рост до 125 миллиардов устройств к 2030 году. Такой объем производства вполне возможен, но уже сейчас ударные темпы выпуска IoT-устройств достигаются преимущественно за счет самых дешевых «китайских» девайсов, при разработке которых о безопасности думали в последнюю очередь.

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

• использование неизменяемых (hardcoded) и скрытых сервисных учетных данных;
• применение одинаковых либо легко предсказуемых ключей и ПИН-кодов;
• отсутствие проверки прав доступа при обращении к известной странице настроек (например, /settings.asp в обход /index.htm) или прямого вызова изображений и видеопотока IP-камеры (вроде /axis-cgi/jpg/image.cgi);
• некорректная обработка получаемых данных, вызывающая переполнение буфера. Как следствие, возможно выполнение произвольного кода при получении злонамеренно составленного TCP-пакета;
• принудительное переключение сервера на использование старых версий протоколов по запросу клиентского устройства (я старая глупая железка, давай со мной по-простому);
• десятки других типовых ошибок и намеренных ослаблений безопасности ради удобства конфигурирования неспециалистами (в том числе — удаленного и без надлежащей авторизации).

Как искать уязвимые IoT-девайсы

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

Кто-то пляшет от прошивки (точнее, тех диких ошибок, которые были обнаружены при ее анализе методами реверс-инжиниринга). Другие в качестве отличительного признака берут название производителя (его можно определить по первым трем октетам MAC-адреса) или версию ОС (большинство устройств сообщают ее в сетевом отклике, в том числе и роботам-паукам поисковиков). В любом случае для успешного поиска нам нужен некий отличительный признак уязвимого девайса, и хорошо бы найти несколько таких маркеров. Поэтому я предлагаю пойти следующим путем.

1. Обращаемся к базе уязвимостей — например, MITRE или Rapid7 и находим интересующие нас бреши у определенных IoT-девайсов. Наиболее гарантированными в плане использования будут уязвимости следующих типов:

• обнаруженные после того, как производитель прекратил поддержку устройства и выпуск патчей;
• обнаруженные недавно (для которых еще нет исправлений, либо большинство пользователей не успели исправления применить);
• архитектурные баги, плохо исправляемые софтверными патчами и редко устраняемые до конца — вроде уязвимости Spectre, существующей в нескольких разновидностях и актуальной до сих пор;
• влияющие сразу на несколько моделей и даже типов устройств (например, из-за общего компонента веб-интерфейса или уязвимости самого протокола коммуникации).

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

3. Составляем продвинутые поисковые запросы для Google и специализированных поисковиков по интернету вещей:

• Shodan,
• Censys,
• ZoomEye.

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

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

Дополнительный отсев недобросовестных исследователей мира IoT выполняют сами сервисы Shodan и Censys. Без регистрации они показывают только первые результаты поиска, ограничивают количество запросов в день и не позволяют их эффективно уточнять. Все самое интересное обычно начинается после первой сотни результатов, а то и дальше.

Поиск IoT-девайсов легко ускорить за счет скриптов. Например, RussianOtter Mult-API Network Scanner или GasMasK. Для их использования (как и для применения собственных скриптов) понадобится регистрация в Shodan и Censys.

4. Проверяем цели из поисковой выдачи и (при необходимости) просеиваем ее дополнительными запросами. Такая необходимость возникает практически всегда, поэтому для парсинга результатов часто используют скрипты. Например, вот такой от thesubtlety.

5. Подбираем инструментарий для подключения к найденным IoT-девайсам. В большинстве случаев будет достаточно браузера. Для управления камерами и DVR иногда потребуется поставить старую версию Java RE и специфический видеокодек. Часто бывают нужны Telnet- и SSH-клиенты. Реже потребуется софт от разработчика, например Cisco Smart Install Client.

6. В зависимости от того, как далеко ты намерен зайти, ограничиваемся сбором статистики или выполняем тестовое подключение и пробуем менять настройки. Последнее не рекомендуется делать, в том числе и потому, что ты с легкостью можешь нарваться на ловушку (honeypot). Интерполу тоже надо поднимать показатели раскрываемости преступлений в сфере ИБ, а не слишком осторожный исследователь — идеальная цель.

Приоритетные мишени

Нам было интересно узнать, что чаще всего становится мишенью в мире IoT. За комментарием мы обратились к специалисту по защите информационных систем компании GS-Labs Егору «Xarlan» Литвинову, чьи статьи ты уже наверняка читал.

— Егор, как ты считаешь, какие девайсы из интернета вещей сегодня имеют самые дырявые прошивки?

— Что значит «самая дырявая прошивка»? Та, в которой больше всего багов, или та, где есть всего один баг, но его эксплуатация может привести к фатальным последствиям? Наверное, тут поможет список OWASP Top 10 IoT Vulnerabilities. Он хоть и датирован 2014 годом, но смежный доклад про небезопасность мобильных приложений, звучавший на PHDays 2018, показывает, что очень не зря существует OWASP TOP 10.

— Можешь привести какие-нибудь недавние примеры?

— Из свежих примеров дырявости IoT — DNS rebinding — «сетевое устройство привязывают к вредоносному DNS-серверу и превращают его в точку входа в инфраструктуру жертвы». Ну и как результат — «интерактивная колонка Google Home позволяет злоумышленнику манипулировать ее настройками, сканировать Wi-Fi-сети, запускать установленные приложения и воспроизводить мультимедийный контент».

Или недавняя новость о том, как злоумышленники пытаются проэксплуатировать критическую уязвимость в маршрутизаторах D-Link, чтобы те в свою очередь пополнили ряды ботнета Satori.

— А какие IoT-девайсы взламывают чаще всего?

— Чаще всего взламывают те IoT-девайсы, которые наиболее распространены. Ярким примером может служить ботнет Mirai, который «ломал» IP-камеры и DVR-регистраторы. В каком-то смысле, думаю, он уже вошел в учебники истории по ИБ. Кстати, с IP-камерами связана и другая серьезная уязвимость. При определенном раскладе плохие парни могут получить полный контроль над IP-камерами фирмы Axis.

— Ну а кроме камер?

— Чтобы немного разбавить тему взлома IP-камер и роутеров, стоит сказать пару слов об атаке Z-Shave. Хорошим парням удалось откатить протокол шифрования S2 до уязвимой версии S0 (в случае протокола S0 был выбран сложнейший ключ шифрования в виде шестнадцати нулей) и далее эксплуатировать баги в протоколе S0. В результате чего «белые шляпы» сумели открыть смарт-замок Yale.

Но это как раз пример нетривиальной атаки. В общем случае сначала будут взламываться те устройства, которые используют «стандартные» протоколы передачи данных — Ethernet, Wi-Fi, Bluetooth. Уже потом под удар могут попасть гаджеты, работающие на различных RF-протоколах — ZigBee, LoRa, Z-Wave и других.

— Есть какие-то иные принципы выбора целей, кроме типа устройства?

— Другим критерием того, какие устройства наиболее вероятно станут мишенью, является применение однотипных ОС. Думаю, ни для кого не секрет, что в embedded зачастую используются облегченные вариации Linux. Потом уже идут другие встроенные ОС: FreeRTOS, ChibiOS, embOS и масса других RTOS. Вот и получается, что ботнеты (Mirai, Satori, Persirai и подобные) сначала будут атаковать то, что подключается по Ethernet/Wi-Fi и работает под Linux, и только потом в их прицел, возможно, попадут менее популярные варианты.

Разбор свежих уязвимостей

Перейдем к практике и разберем какой-нибудь пример взлома IoT сервисов подробнее. Из открытой базы данных MITRE мы узнали, что есть свежий набор взаимосвязанных уязвимостей:

• CVE-2018-11681;
• CVE-2018-11682;
• CVE-2018-11629.

Вместе они затрагивают десятки разных IoT-устройств, использующих протоколы RadioRA2или Homeworks QS в системах управления умным домом от Lutron electronics. У этих девайсов открыт порт 23 (Telnet) и прошиты скрытые сервисные аккаунты для предоставления клиентам удаленной поддержки. Пары логин/пароль выглядят так: lutron/integration или nwk/nwk2 — в зависимости от типа устройства и ревизии протокола.

Среди уязвимых хостов есть диммеры и выключатели освещения, а также элементы HVAC (отопление, вентиляция и кондиционирование). Теоретически их даже можно использовать как точку входа (если применяется единая система управления), чтобы добраться до более серьезных целей — охранных систем (сигнализации, электронных замков, автоматических ворот) и видеонаблюдения. Вот какие команды можно отправить им по Telnet.

Удаленное управление IoT-девайсами Lutron

Censys поддерживает геофильтры, да и пресс-релизы часто содержат данные, которые помогают определить физическое местоположение целей. Из этих двух источников мы узнаем, что устройства Lutron установлены на стадионе Уимблдон, в музее Гуггенхайма, в Тайбэйском международном финансовом центре, а также в десятках банков, больниц и даже в космическом центре им. Кеннеди близ мыса Канаверал.

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

Почему казалось? Да потому, что в реальности не все так просто. Обнаруживший эту уязвимость Давид «SadFud75» Кастро (David Castro) приводит красивый поисковый запрос для Censys: (metadata.product:Homeworks Processor) AND protocols.raw: "23/telnet". Сейчас по нему находится более двух тысяч лутроновских устройств с открытым портом 23 (совсем недавно их было больше семи тысяч). Сначала глаза разбегаются, а затем впадаешь в отчаяние. Ты пингуешь уже сто первый узел, но и он не принимает указанные пары логин/пароль. В чем же дело?

При всей подробности описания Давид Кастро ожидаемо умолчал об одной важной детали (на самом деле не об одной, но не будем спойлерить). По факту уязвимы только девайсы, подключенные через интеграционный протокол с ревизиями от M до Y… и то не все. Когда об уязвимости стало известно, то ее не смогли оперативно закрыть патчем, но дали рекомендации, как затруднить ее использование.

Метод противодействия оказался простым и довольно изящным. Поскольку нельзя одновременно установить более одного подключения с одним и тем же логином, владельцам посоветовали залогиниться под сервисными учетками и поддерживать коннект. Служба поддержки уже сделала это у большинства клиентов. Теперь, когда ты нашел уязвимый девайс и наивно пишешь в Telnet-клиенте login: lutron, в большинстве случаев получаешь сообщение login incorrect, хотя он вполне себе корректный.

Примечание для самых маленьких: в Linux обычно есть клиент Telnet, а если он еще не установлен, то это легко исправить командой sudo apt-get install telnet. В Windows проще воспользоваться portable-клиентом, например PuTTY.

Подключись, если сможешь

Мифология IoT

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

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

Так появляются перлы про «сотни миллионов уязвимых устройств» и «тысячи недобросовестных вендоров» на DEF CON и Black Hat, а потом эти страшилки подхватывают журналисты с легкого пинка антивирусных компаний и прочих разработчиков защитных систем. Напугать и предложить готовое решение со скидкой — классический метод повышения продаж.

Аналогичная ситуация складывается и с другими уязвимостями, которыми так пугали в последнее время. Из описания приведенной выше атаки Z-Shave мы узнаем, что она «потенциально затрагивает 2400+ производителей и свыше 100 миллионов IoT-девайсов — от умных лампочек до дверных замков». Складывается жуткая картина, в которой хакеры удаленно в пару кликов устраивают день открытых дверей и тотальный блэкаут. Однако в реальности ничего подобного не случалось. Почему?

Как обычно, дьявол кроется в деталях. Чтобы воспользоваться данной уязвимостью, удаленное подключение не годится. Нужно сварганить хакерский девайс и оказаться вместе с ним рядом с уязвимым устройством, чтобы перехватить его радиосигнал и вынудить ответным кодом перейти на старый небезопасный протокол. Ты полетишь в Сан-Диего со сниффером для Z-Wave, чтобы выключить кому-то свет в уборной? Рискнешь открыть один замок из двух-трех разных и нарваться на патруль (а то и пулю)?

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

Отключаем сигнализацию

Из-за скромных вычислительных ресурсов на IoT-девайсы крайне просто выполнить DoS-атаку. Банальный ICMP-флудинг парализует их, что в случае охранных систем не менее опасно, чем НСД. К примеру, домашняя/офисная сигнализация iSmartAlarm Cube содержит ряд уязвимостей (CVE-2017-7728, CVE-2017-7729, CVE-2017-7730), позволяющих удаленно заблокировать ее одной командой. Мы уже писали об этом в общих чертах, а сейчас разберем подробнее.

Не такой уж и smart девайс

Достаточно запустить утилиту hping3 (она есть в составе Kali Linux в разделе Information Gathering ? Live Host Identification) и набрать команду

  $ hping3 --flood -S -p   

Здесь --flood — режим отправки пакетов без ожидания ответа, ключ -S задает SYN-флаг, а -p — номер порта (по умолчанию он задан как 12345). Все! Как только ты нажмешь Enter, ICMP-пакеты польются рекой на iSmartAlarm Cube. Сигнализация будет так увлечена бесконечными ответами на них, что не сработает при физическом вторжении (контроллер просто не успеет обработать данные от датчика движения за отведенное время). Более того, вернуть сигнализацию к жизни без перезагрузки и отключения от интернета не удастся ни удаленно, ни локально.

Если этого мало, то CVE-2017-7728 позволяет получить полный удаленный контроль над сигнализацией, поскольку в ней криво реализована аутентификация. Готовый PoC на Python лежит здесь — спасибо Илье Шнайдману. Плюс на месте появляется хороший шанс воспользоваться другой уязвимостью из указанной выше триады — CVE-2017-7729. iSmartAlarm позволяет перехватить ключ авторизации по локальной сети, поскольку он передается в открытом (незашифрованном) виде. Какая прелесть!

На момент написания PoC компания iSmartAlarm не предоставила ни официальных комментариев, ни патчей.

И снова про камеры

В апреле 2018 года компания Locklin Networks провела аудит безопасности прошивки популярной сетевой камеры Momentum Axel 720P и с трудом удержалась от нецензурной брани в отчете.

У камеры было обнаружено множество зияющих брешей в системе безопасности:

• все процессы запускаются от рута;
• при физическом подключении к UART-порту консоль также становится доступна под рутом и без авторизации. Через нее легко прочитать файл ключа, хранящийся по дефолтному адресу /devinfo/Ozvision/key/.key;
• пароли хранятся в /devinfo в формате SQLite без шифрования и читаются командой showKey;
• логины и хеши паролей дополнительно читаются из консоли без авторизации командой cat /etc/passwd;
• возможна локальная подмена прошивки с SD-карты безо всяких проверок;
• возможна удаленная перезапись прошивки через DNS-Hijacking. Редактируем /etc/resolv.conf, прописываем туда наш DNS-сервер и подменяем на нем переход с firmware.momentum-cam.comна свой сайт с модифицированной прошивкой;
• видео доступно из локальной сети через потоковый протокол реального времени (RTSP) и порт 554. Авторизация не требуется. Пример запроса: rtsp://:554. Поток можно посмотреть через VLC Media Player;
• в прошивке есть неизменяемые (hardcoded) сервисные аккаунты: root/EHLGVG и admin/EHLGVG.

В общем, удачного тебе поиска акселевских камер!

Выводы

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

С другой стороны, производители вовсе не спешат патчить прошивки и вообще признавать свои промахи. Поэтому легких целей всегда хватает. Составление их точного списка потребует гораздо больше усилий, чем разовое обращение к специализированным поисковикам. Львиная доля поисковой выдачи Shodan, Censys и ZoomEye не имеет отношения к легко взламываемым устройствам. Просто сетевой отклик многих узлов частично совпадает с запросом исследователей, ищущих подходящие цели.

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

Источник: xakep.ru

Комментарии: