Принципы построения ботнета на базе IoT-устройств

Автор: MDSec

В августе компания @MDSecLabs выступала на конференции Manchester BSides с докладом «Breaking and Entering, Hacking Consumer Security Systems». Доклад был сделан на основе исследования проблем в IoT-устройствах, в основном имеющих отношение системам безопасности:  IP-камерах, видеорегистраторах (DVR), системах скрытого видеонаблюдения (CCTV) и защитных комплексах Smart Home Security. Главным образом, обсуждалась тема, посвященная тому, как уязвимости в подобных устройствах могут привести к созданию ботнетов. Недавно наше предсказание сбылось, когда произошла одна из крупнейших DDoS атак на сайт krebsonsecurity.com.  В исходном коде, появившимся на публике и, как предполагается, имеющим непосредственное отношение к функционированию ботнета, эксплуатировалась брешь, схожая с той, о которой говорилось в нашем докладе. 

Мы начали исследование в 2014 году, когда столкнулись с моделью DS-7204HWI-SH/A, широко известным видеорегистратором, разработанным компанией HikVision. Устройство функционирует на базе ОС Linux и Linux с прошивкой (на тот момент) V3.0.1 build140524. В последней версии прошивки найденные нами проблемы были исправлены.

Чтобы прикинуть, насколько распространены эти и схожие устройства мы ввели запрос «DNVRS-Webs» в поисковую систему Shodan. Результаты поиска недвусмысленно намекают, что подобные видеорегистраторы используются повсеместно и являются идеальными кандидатами на создание ботнета, схожего тому, который был создан на базе вредоноса Mirai.

Рисунок 1: Результат поискового запроса DNVRS-Webs в системе Shodan

Для доступа к устройству разработчики компании HikVision предусмотрели административный веб-интерфейс. Стандартный пароль – 12345, который можно поменять в процессе конфигурирования устройства.

Рисунок 3: Установка административного пароля

Поскольку в этой версии прошивки физический интерфейс поддерживает только цифровые пароли, с высокой степенью вероятности у огромного количества пользователей установлен цифровой пароль. Данный пароль используется для аутентификации через веб-интерфейс. Поскольку отсутствует функция автоматической блокировки учетной записи, пароль администратора можно подобрать методом прямого перебора. Как только доступ получен, сразу же можно подключить службу telnetd посредством запроса «/ISAPI/System/Network/telnetd». Поскольку пароль суперпользователя и администратора совпадают, тут же организуется интерактивная командная оболочка. Демонстрация атаки показана на видео ниже:

Код эксплоита, используемого в этой атаке, можно найти на странице MDSec githu. В этом устройстве было найдено еще несколько проблем, о которых рассказывается в полной версии доклада (см. видео в конце статьи).
При исследовании данного типа устройств всегда полезно иметь доступ к операционной системе в целях последующей и более глубокой оценки уровня безопасности. Если у вас есть физический доступ к этой модели видеорегистратора, можно легко получить доступ к командной оболочке через UART-порт. Пины, имеющие отношение к данному порту, показаны на рисунке ниже:

Рисунок 4: Пины, связанные с UART-портом

После подключение к UART-порту появится доступ к оболочке с правами гостевого пользователя. Пароль суперпользователя тот же самый, что и пароль администратора, установленный во время конфигурирования:

Рисунок 5: Получение доступа к оболочке с правами суперпользователя через UART-порт

Следующее устройство, о котором говорилось в докладе, - RISCO Agility, широко распространенная система тревожной сигнализации для защиты жилых и торговых помещений. В докладе данные устройства описывались с позиции уязвимости к атакам, связанным с перехватом и ретрансляцией, против плавающего кода (rolling code) в целях деактивации сигнализации для получения физического доступа к имуществу.

Видео демонстрация этой части доклада показана ниже:

Последнее устройство, описанное в нашем исследовании, - Motorola Scout 85 Connect, IP-камера, переделанная под несколько различных задач. Камера работает на базе BusyBox и Linux 2.6.32 на чипе ARMv5. Несмотря на то, что мы исследовали прошивку версии 17, большинство найденных проблем есть и в последней версии на момент написания статьи. О брешах сообщено компании-разработчику устройства.

Одна из наиболее очевидных проблем – отсутствие авторизации для доступа к административному интерфейсу. Функционал, доступный через этот интерфейс, варьируется от безобидного (например, физический поворот устройства), до более серьезного (например, обновление прошивки). Более того, мы обнаружили, что служба на  TCP-порту 51108 была связана с аудио выходом и может принимать 16 битный аудио моно WAV файл без аутентификации. Демонстрация того, как можно злоупотребить данной «возможностью» в шуточных целях, показана на видео ниже:

Код эксплоита находится на странице MDSec github.

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

Рисунок 6: Содержимое файла haserlupgrade.cgi

Как показано на рисунке выше, скрипт напрямую выдает содержимое аргумента uploadfile_name как параметр команды в операционной системе, что можно использовать для выполнения команд на устройстве от имени суперпользователя (см. видео ниже):

Найдя брешь, связанную с инъекцией, в целях более качественного реверс-инжиниринга мы приступили к поиску доступа к более функциональной отладочной платформе, анализируя аппаратную часть в надежде найти отладочную консоль.  Анализ показал, что устройство работает на базе системы Novoton N32926U1DN с процессором ARM926EJ-S. Изучив документацию разработчика, мы выяснили, что тестовые выводы 104 и 105 связаны с UART-портом:

Рисунок 7: Плата Novoton

Подключившись к отладочным пинам при помощи устройства JTAGulator, мы получили доступ к командной оболочке с правами суперпользователя:

Рисунок 8: Интерактивная командная оболочка

Вначале наше внимание привлекла служба msloader, которая предназначена для запуска всех остальных служб. Так как мы уже нашли уязвимость, связанную с инъекцией, то были уверены, что есть и другие бреши, и приступили к анализу бинарного файла msloader. Первая и наиболее многообещающая проблема оказалась в функции setupWifi(), предположительно, принимающей пользовательский параметр SSID, который затем соединяется с буфером. Результат объединения передавался в функцию system():

Рисунок 9: Часть функции setupWifi() (красными стрелками отмечены интересные места)

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

 GET /?action=command&command=setup_wireless_save&setup=1002001800100000000000YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYZZZZA HTTP/1.1

При тестировании этой службы важно, что соответствующих полей совпадали с длиной параметра SSID и пароля, как показано выше. Мониторинг консоли UART во время отсылки запроса выше спровоцирует исключение, похожее на следующее:

Рисунок 10: Исключение, возникающее при отсылке запроса

Эксплуатация уязвимости не представляет особых сложностей из-за отсутствия механизмов противодействия эксплоитам, заточенным под бинарный файл msloader:

Рисунок 11: Результаты тестирования на безопасность файла msloader

Более того, стек и куча доступны на выполнение, и мы можем просто перейти к шелл-коду после перехвата управления программным счетчиком.

При эксплуатации уязвимости обнаружилось, что управление регистром PC перехватывается после 176 байт, хотя у полезной нагрузки было ограничение в 180 байт. Сей факт означает, что размер шелл-кода ограничивается. Для решения этой проблемы мы написали шелл-код в режиме Thumb (режим, в котором используется сокращенная система команд) в целях более рационального использования места. Также выяснилось, что переполнение негативно влияет и на другие регистры до такой степени, что мы не можем найти регистр, указывающий шелл-коду, куда переходить. Данное влияние затрагивает указатель стека, требующий подстройки, чтобы наш шелл-код передал параметры в стек во время конфигурирования системного вызова. Из-за этой проблемы мы решили указать конкретный адрес местонахождения шелл-кода в стеке. Возможно, данное решение не идеально, но в реализации значительно легче.

Несмотря на то, что по теории эксплуатация бреши – относительно тривиальна, следует помнить о некоторых моментах. Во-первых, на устройстве используется защита ASLR, хотя и в консервативном режиме, что означает слабую рандомизацию стека и уязвимость к прямому перебору. Мы выяснили, что на практике требуется не более 20 попыток, а в большинстве случаев – не более 5. Самое главное заключается в том, что программная защита отслеживает неудачные попытки, поскольку происходит падение процесса msloader. При каждой неудаче устройство перезагружается. Во-вторых, полезная нагрузка не должна портить URL, поскольку происходит передача при помощи GET-запроса. Поэтому полезная нагрузка должна содержать такие символы, чтобы HTTP-запрос был корректным. Данное ограничение мы обошли при помощи кодирования URL. Кроме того, полезная нагрузка не должна содержать пустых байтов, иначе строка завершится раньше положенного. Чтобы обойти данное ограничение, мы сделали так, чтобы шелл-код был самомодифицирующимся и патчил пустые байты в нужных местах буфера при первом запуске. В-третьих, полезная нагрузка была повреждена в некоторых местах. Вместо решения этой проблемы, когда требовались бы дополнительные инструкции, мы изменили полезную нагрузку так, чтобы испорченные инструкции не влияли на шелл-код.

Эксплуатация проблемы в наглядной форме показана ниже. Код эксплоита находится на странице MDSec github.

В заключение мы продемонстрировали, насколько безопасность IoT-устройств несовершенна, по сравнению с мобильными и настольными системами. Во многих случаях в IoT-устройствах используются стандартные учетные записи, не используются методы противодействия эксплоитам, все службы запускаются от имени суперпользователя и зачастую содержатся бреши, связанные с инъекциями. Анализ ботнета Mirai показал, насколько распространены и легкодоступны подобные устройства для эксплуатации злоумышленниками. Мы предполагаем, что в будущем данная тенденция будет только развиваться.

Слайды нашей презентации можно найти здесь. Полная видео демонстрация показана ниже: