Валентин Холмогоров - PRO вирусы. Версия 4.0

Изучение логов ханипотов (специально созданных серверов — «приманок»), с помощью которых специалисты по информационной безопасности анализируют распространение троянов для «интернета вещей» в живой природе, показывает следующий путь их доставки на целевое устройство. Обычно атакующие соединяются с привлекшим их внимание устройством по протоколу SSH или Telnet, подбирают пароль по словарю и в случае успешной авторизации отключают утилиту iptables, чтобы заблокировать работу файрвола. Дальше им остается только отыскать открытую на запись папку, сохранить в нее нужное приложение, соответствующее архитектуре устройства, и запустить его.

В арсенале атакующих обычно имеются готовые файлы малвари под различные архитектуры: ARM, MIPS, SPARC, M68K, SuperH, PowerPC, SH-4 и прочие типы железа. На некоторых девайсах можно организовать автозагрузку трояна, просто отредактировав файл /etc/rc.local . Периодически проверять, работает ли нужный процесс, и при необходимости перезапускать его можно, например, с использованием /etc/cron.minutely . Поскольку многие пользователи умных устройств не утруждают себя сменой дефолтных логинов и паролей, словарь для брутфорса (подбора пароля) в большинстве случаев выглядит весьма тривиально. Вот наиболее популярные логины и пароли для взлома девайсов по протоколу SSH.

Также при бруте по SSH очень часто используются такие логины, как ubnt, user, oracle, bin, support, postgres. А вот наиболее популярные сочетания логинов и паролей для взлома девайсов по протоколу Telnet:

Эта табличка наглядно демонстрирует, что по Telnet злодеи традиционно пытались авторизоваться в админке различных камер видеонаблюдения, таких как Anko, TP-Link, Dahua или CNB. Кроме того, для перебора паролей по этому протоколу очень часто берут широко используемые логины вроде admin, test и telnet.

Однако технологии не стоят на месте, и с определенного момента вирусописатели взялись за автоматизацию процедуры взлома. Так, если трояна удалось запустить в скомпрометированной системе, он может попытаться вытащить из различных источников вроде файла ssh/known_hosts или bash_history сведения о хостах, к которым устройство ранее получало доступ, и попытаться взломать их. Другие трояны поступают гораздо проще: генерируют диапазон IP-адресов и в цикле пытаются постучаться на стандартные для SSH и Telnet порты. Плюс такого подхода заключается в его относительной простоте, недостаток — в значительном объеме создаваемого паразитного трафика.

Примерно три года назад в ассортименте малвари для умных устройств было не менее десятка разных модификаций троянов Fgt, Mrblack, Mirai, разнообразных флудеров и DDoS-ботов. Однако после того как исходники Mirai в сентябре 2016 года оказались в свободном доступе на сайте hackforums.com, бесчисленные клоны этого трояна практически вытеснили с рынка остальных конкурентов. BrickBot, Sora, Wicked, Omni, Owari — все это вариации на тему Mirai с дополнениями все новых и новых соавторов.

По данным исследователей Сэма Эдвардса и Иоанниса Профетиса из Rapidity Networks, в 2016 году троянец Linux. Mirai заразил более 380 тысяч умных устройств по всему миру, став причиной множества нашумевших DDoS-атак. После того как исходники этого трояна были выложены в паблик, изучением принципов его работы тут же заинтересовались не только специалисты по информационной безопасности, но и тысячи анонимных вирусописателей.

Сам по себе исходный код Mirai тоже имеет ряд заимствований из других источников и во многом базируется на архитектуре одного из DDoS-ботов, распространявшихся весной 2016 года. Этот бот, в свою очередь, имеет схожие черты с троянами семейства Fgt, известного аж с 2014 года, — оттуда была явно скопирована функция флуда и генератор псевдослучайных данных для заполнения пакетов, отсылаемых на атакуемые хосты. Такое «перекрестное опыление», в целом характерное для разработчиков open source софта для Linux, по всей видимости, прижилось и в среде ориентирующихся на эту платформу вирусописателей. Все ранние версии Mirai для разных аппаратных архитектур были статически скомпилированы и использовали стандартную библиотеку uClibc.so , предназначенную для встраиваемых систем на базе uCLinux.

При запуске троян выделял область памяти, в которую загружал необходимый для его работы конфиг. Некоторые конфигурационные строки хранились в зашифрованном виде в самом файле ELF и перед загрузкой в память расшифровывались. В частности, таким образом передавался адрес и порт управляющего сервера, User-Agent и другие параметры HTP-запросов. Отсюда становится понятен способ, с помощью которого исследователи определили адрес командного центра этого ботнета. Еще одна примечательная функция ранних версий Mirai — способность трояна в отдельном потоке убивать работающие процессы других конкурирующих ботов, читая в непрерывном цикле содержимое папки /proc/ . Список названий процессов хранился в конфиге. А вот в обработчике конфига авторы Mirai допустили небольшую ошибку: список процессов читался блоками по 2048 байт, после чего поиск названия выполнялся внутри этого буфера. Если искомое значение располагалось на границе блока, оно игнорировалось, и такой процесс избегал общей печальной участи. Чтобы предотвратить случайную выгрузку собственного процесса, троян размещал в его папке файл .shinigami — при обнаружении файла с этим именем процесс автоматически исключался из «расстрельного списка». Однако в самом коде зловреда был зашит лимит жизнедеятельности на зараженном устройстве: по истечении недели непрерывной работы процесс Mirai автоматически завершается. Описываемая здесь ранняя версия Mirai умела выполнять с десяток команд, среди которых — команды на установку и завершение TCP-соединения с указанным хостом и различные виды флуда по протоколам HTP, UDP и UDP over GRE. Также с помощью этого трояна можно было организовать DNS food и TSource Query Flood, то есть целый комплекс атак на отказ в обслуживании.

При соединении с управляющим сервером троян сообщал ему IP-адрес и MAC-адрес сетевого интерфейса, а также идентификатор архитектуры зараженного устройства. В ответ он ожидал поступления команд, для выполнения каждой из которых создавал форк собственного процесса, имеющий заданную в специальной переменной продолжительность жизни. Если за один цикл поступало сразу несколько команд, они выполнялись по очереди. При этом команды на начало DDoS-атаки могли содержать несколько целей, перечисленных в массиве. Содержимое команды разбиралось специальным парсером, затем зловред в определенном порядке формировал заголовки пакетов, их содержимое (либо при необходимости брал их из конфига), отправлял эти пакеты заданному хосту и после подсчета контрольной суммы переходил к следующей цели. Вся эта процедура продолжалась в непрерывном цикле до тех пор, пока выполняющий команду процесс не завершался по таймеру. В случае DNS-флуда Mirai отправлял на атакуемый DNS-сервер по сто случайных запросов доменных имен за один цикл, что при наличии хотя бы сотни активных ботов гарантированно укладывало сервер на лопатки.