Когда читаешь новости про недавно обнаруженные уязвимости или смотришь выступления на хакерских конференциях, то складывается впечатление, что сегодня все подключено к интернету и легко взламывается. Причем часто для взлома не требуется ни высокой квалификации, ни специализированного оборудования. Давайте выясним на практике, так ли это на самом деле!
Посмотреть вложение 7532
Миллиарды потенциальных целей
По данным Statista.com, объем рынка интернета вещей в 2017 году превысил миллиард долларов. Общее число подключенных к интернету устройств оценивается на текущий момент в 23 с лишним миллиарда с перспективой увеличения до 30 миллиардов к 2020 году. После этого аналитическое агентство 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 (Google Dorks) и специализированных поисковиков по интернету вещей:
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 <port> <IP>
Здесь —flood — режим отправки пакетов без ожидания ответа, ключ -S задает SYN-флаг, а -p — номер порта (по умолчанию он задан как 12345). Все! Как только вы нажмете Enter, ICMP-пакеты польются рекой на iSmartAlarm Cube. Сигнализация будет так увлечена бесконечными ответами на них, что не сработает при физическом вторжении (контроллер просто не успеет обработать данные от датчика движения за отведенное время). Более того, вернуть сигнализацию к жизни без перезагрузки и отключения от интернета не удастся ни удаленно, ни локально.
Если этого мало, то CVE-2017-7728 позволяет получить полный удаленный контроль над сигнализацией, поскольку в ней криво реализована аутентификация. Готовый PoC на Python лежит здесь — спасибо Илье Шнайдману. Плюс на месте появляется хороший шанс воспользоваться другой уязвимостью из указанной выше триады — CVE-2017-7729. iSmartAlarm позволяет перехватить ключ авторизации по локальной сети, поскольку он передается в открытом (незашифрованном) виде. Какая прелесть!
На момент написания PoC компания iSmartAlarm не предоставила ни официальных комментариев, ни патчей.
И снова про взлом камер
Подробный анализ уязвимостей IP-камер у нас уже был, поэтому разберем только свежий пример. В апреле 2018 года компания Locklin Networks провела аудит безопасности прошивки популярной сетевой камеры Momentum Axel 720P и с трудом удержалась от нецензурной брани в отчете.
У камеры было обнаружено множество зияющих брешей в системе безопасности:
все процессы запускаются от рута;
при физическом подключении к UART-порту консоль также становится доступна под рутом и без авторизации. Через нее легко прочитать файл ключа, хранящийся по дефолтному адресу /devinfo/Ozvision/key/<deviceid>.key;
пароли хранятся в /devinfo в формате SQLite без шифрования и читаются командой showKey;
логины и хеши паролей дополнительно читаются из консоли без авторизации командой cat /etc/passwd;
возможна локальная подмена прошивки с SD-карты безо всяких проверок;
возможна удаленная перезапись прошивки через DNS-Hijacking. Редактируем /etc/resolv.conf, прописываем туда наш DNS-сервер и подменяем на нем переход с firmware.momentum-cam.com на свой сайт с модифицированной прошивкой;
видео доступно из локальной сети через потоковый протокол реального времени (RTSP) и порт 554. Авторизация не требуется. Пример запроса: rtsp://<camera_ip>:554. Поток можно посмотреть через VLC Media Player;
в прошивке есть неизменяемые (hardcoded) сервисные аккаунты: root/EHLGVG и admin/EHLGVG.
В общем, взломать акселевские камеры сможет любой, кому это понадобится.
Выводы
Уязвимостей в IoT-девайсах действительно много, однако не все из них столь легко эксплуатировать, как в перечисленных выше примерах. Одни требуют физического подключения, нахождения рядом или в той же локальной сети. Использование других временно усложняется после опубликования деталей и до выхода официального патча.
С другой стороны, производители вовсе не спешат патчить прошивки и вообще признавать свои промахи. Поэтому легких целей всегда хватает. Составление их точного списка потребует гораздо больше усилий, чем разовое обращение к специализированным поисковикам. Львиная доля поисковой выдачи Shodan, Censys и ZoomEye не имеет отношения к легко взламываемым устройствам. Просто сетевой отклик многих узлов частично совпадает с запросом исследователей, ищущих подходящие цели.
О реальных масштабах распространенности потенциальных мишеней для ботнетов можно судить только после углубленного анализа поисковой выдачи и непосредственных проверок, которыми обычно пренебрегают.
Посмотреть вложение 7532
Миллиарды потенциальных целей
По данным Statista.com, объем рынка интернета вещей в 2017 году превысил миллиард долларов. Общее число подключенных к интернету устройств оценивается на текущий момент в 23 с лишним миллиарда с перспективой увеличения до 30 миллиардов к 2020 году. После этого аналитическое агентство 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 (Google Dorks) и специализированных поисковиков по интернету вещей:
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 <port> <IP>
Здесь —flood — режим отправки пакетов без ожидания ответа, ключ -S задает SYN-флаг, а -p — номер порта (по умолчанию он задан как 12345). Все! Как только вы нажмете Enter, ICMP-пакеты польются рекой на iSmartAlarm Cube. Сигнализация будет так увлечена бесконечными ответами на них, что не сработает при физическом вторжении (контроллер просто не успеет обработать данные от датчика движения за отведенное время). Более того, вернуть сигнализацию к жизни без перезагрузки и отключения от интернета не удастся ни удаленно, ни локально.
Если этого мало, то CVE-2017-7728 позволяет получить полный удаленный контроль над сигнализацией, поскольку в ней криво реализована аутентификация. Готовый PoC на Python лежит здесь — спасибо Илье Шнайдману. Плюс на месте появляется хороший шанс воспользоваться другой уязвимостью из указанной выше триады — CVE-2017-7729. iSmartAlarm позволяет перехватить ключ авторизации по локальной сети, поскольку он передается в открытом (незашифрованном) виде. Какая прелесть!
На момент написания PoC компания iSmartAlarm не предоставила ни официальных комментариев, ни патчей.
И снова про взлом камер
Подробный анализ уязвимостей IP-камер у нас уже был, поэтому разберем только свежий пример. В апреле 2018 года компания Locklin Networks провела аудит безопасности прошивки популярной сетевой камеры Momentum Axel 720P и с трудом удержалась от нецензурной брани в отчете.
У камеры было обнаружено множество зияющих брешей в системе безопасности:
все процессы запускаются от рута;
при физическом подключении к UART-порту консоль также становится доступна под рутом и без авторизации. Через нее легко прочитать файл ключа, хранящийся по дефолтному адресу /devinfo/Ozvision/key/<deviceid>.key;
пароли хранятся в /devinfo в формате SQLite без шифрования и читаются командой showKey;
логины и хеши паролей дополнительно читаются из консоли без авторизации командой cat /etc/passwd;
возможна локальная подмена прошивки с SD-карты безо всяких проверок;
возможна удаленная перезапись прошивки через DNS-Hijacking. Редактируем /etc/resolv.conf, прописываем туда наш DNS-сервер и подменяем на нем переход с firmware.momentum-cam.com на свой сайт с модифицированной прошивкой;
видео доступно из локальной сети через потоковый протокол реального времени (RTSP) и порт 554. Авторизация не требуется. Пример запроса: rtsp://<camera_ip>:554. Поток можно посмотреть через VLC Media Player;
в прошивке есть неизменяемые (hardcoded) сервисные аккаунты: root/EHLGVG и admin/EHLGVG.
В общем, взломать акселевские камеры сможет любой, кому это понадобится.
Выводы
Уязвимостей в IoT-девайсах действительно много, однако не все из них столь легко эксплуатировать, как в перечисленных выше примерах. Одни требуют физического подключения, нахождения рядом или в той же локальной сети. Использование других временно усложняется после опубликования деталей и до выхода официального патча.
С другой стороны, производители вовсе не спешат патчить прошивки и вообще признавать свои промахи. Поэтому легких целей всегда хватает. Составление их точного списка потребует гораздо больше усилий, чем разовое обращение к специализированным поисковикам. Львиная доля поисковой выдачи Shodan, Censys и ZoomEye не имеет отношения к легко взламываемым устройствам. Просто сетевой отклик многих узлов частично совпадает с запросом исследователей, ищущих подходящие цели.
О реальных масштабах распространенности потенциальных мишеней для ботнетов можно судить только после углубленного анализа поисковой выдачи и непосредственных проверок, которыми обычно пренебрегают.