На днях мне позвонил старый приятель, и в панике сообщил, что у него что-то случилось с домашним файлохранилищем NAS QNAP. При обращении к девайсу на экране демонстрируется вот такая вот забавная картинка, вынесенная в заглавие этого поста, а файлы на дисках теперь имеют расширение .encrypt. Вердикт, в общем-то, был очевиден и неутешителен: NAS подвергся атаке трояна-шифровальщика. Несмотря на то, что большинство подобных устройств используют в качестве операционной системы одну из реализаций Linux, вредоносы проникают с завидной регулярностью и туда. И этот случай — лишь один из многих, с которыми мне, так или иначе, доводилось сталкиваться. Как вообще происходят подобные заражения? Возможны несколько вариантов.

▍ В закоулках истории

Первым трояном-энкодером, нацеленным конкретно на заражение NAS, с которым я познакомился лично в 2014 году, был Synolocker. Из названия трояна становится очевидно, на устройствах какого именно производителя он специализировался. Тогда я ещё работал в антивирусной компании, и именно мне выпала миссия делать подробное описание этого вредоноса для вирусной энциклопедии.

Synolocker использовал для проникновения на устройство дыру в реализации протокола SSL в составе устаревших версий ОС DSM, в которых эта уязвимость ещё не была устранена. Он представлял собой исполняемый ELF-файл для архитектуры ARM. Трой состоял из двух модулей: первый отключал доступ к заражённому девайсу по SSL и Telnet, после чего выполнял рекурсивный обход файлов на дисках и шифровал их при помощи алгоритма AES-256-CBC и HMAC-SHA256. Ключ AES формировался на основе хеша имени файла и его размера с добавлением 32 случайных байт, а потом зашифровывался публичным RSA-ключом и записывался в начало файла. Сам публичный ключ сохранялся в файле “/etc/synolock/RSA_PUBLIC_KEY”. Список всех зашифрованных файлов Synolocker записывал в журнал crypted.log, размещённый в папке «/usr/syno/synoman/».


Тот самый Synolocker

Второй модуль трояна отвечал за взаимодействие с пользователем. Он генерировал по специальному шаблону веб-страницу с требованием выкупа и начинал прослушивать порт 80, 8080 или 443 в ожидании команд. При поступлении соответствующей директивы от злоумышленников Synolocker расшифровывал файлы (имена обработанных файловых объектов при этом сохранялись в журнал «/usr/syno/synoman/decrypted.log»), после чего самоудалялся.

Очевидной причиной распространения Synolocker была лень владельцев NAS: если бы они вовремя обновляли ПО своего устройства, ничего страшного с ним не случилось бы. Вторая причина — банальная беспечность: некоторые пользователи наивно полагают, что если их девайс работает под управлением Linux, он защищён от всевозможных вредоносов самой архитектурой операционной системы. Хотя это, конечно же, не так.

▍ Воинственные эльфы

Когда я увольнялся из антивирусной компании в конце 2018 года и в качестве «дембельского аккорда» писал итоговый годовой обзор вирусной активности, то обнаружил, что число выявленных угроз для устройств IoT на базе Linux выросло прямо-таки в разы. Думаю, по прошествии четырёх лет ситуация только усугубилась. Fgt, Hajime, Mirai, и их многочисленные модификации вроде BrickBot, Sora, Wicked, Omni, Owari, а также множество других троянов под Linux непрерывно атакуют различные «умные» устройства — роутеры, телевизионные приставки, сетевые хранилища, медиацентры и «одноплатники». Шутка о том, что вредоноса для Linux нужно сначала собрать из исходников, убедиться в том, что в системе есть все нужные библиотеки и зависимости, и только после этого пытаться запустить, выдав ему предварительно права root, утратила актуальность. Современные линукс-трояны прекрасно обходятся и без этого.

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

Этим и пользуются злоумышленники. В первую очередь они брутят по словарю логин и пароль для доступа к девайсу по SSH или Telnet — именно так поступают, например, Mirai и Hajime. В обоих троянах используется генератор случайного диапазона IP, из которого исключаются локальные и служебные адреса, после чего полученный массив данных передаётся сканеру. Тот последовательно стучится на 23-й TCP-порт по каждому из адресов, пробуя установить Telnet-соединение. Если попытка увенчалась успехом, трой начинает брутить атакуемый хост с использованием словаря. В случае неудачи вредонос пытается подключиться к девайсу по SSH.

Если пользователь не удосужился сменить заводские настройки и установить сложный пароль, брут не представляет серьёзной проблемы. Авторизовавшись в системе, троян обычно пытается убедиться в том, что он попал именно в Linux-окружение. Для этого используются разные методы: например, Hajime отправляет устройству сначала команду system для перехода в системное меню, а затем команды shell и sh для запуска терминала. Чтобы проверить, активен ли нужный для его работы шелл, Hajime передаёт на атакуемый хост строку “/bin/busybox ECCHI”. Специфические оболочки не смогут обработать эту команду, в то время как стандартный sh запустит BusyBox, который вернёт сообщение об ошибке в аргументе — “ECCHI: applet not found”. Это служит трояну сигналом о том, что взлом удался и можно приступать к работе.

После этого Linux-вредоносы обычно пытаются определить, на каком «железе» собран девайс. Самый простой способ сделать это — прочитать заголовок файла “/bin/echo”, чтобы узнать тип процессора. Обычно подобные трояны уже имеют доступ к хранящемуся на управляющем сервере или другом инфицированном хосте набору заранее скомпилированных бинарников для разных архитектур: ARM, MIPS, PowerPC, SPARC, M68K, SuperH, SH-4 или Intel x86-64. Узнав, с каким железом он имеет дело, вредонос получает из файла «/proc/mounts» список смонтированных файловых систем и ищет открытые на запись папки, отличные от «/proc», «/sys» или «/». В одну из таких папок загружается ELF-файл под соответствующую архитектуру и запускается. Всё, заражение произошло.

Распространяя такую малварь, злоумышленники могут преследовать разные цели — это организация DDoS-атак, майнинг, использование взломанного девайса в качестве прокси-сервера, формирование ботнетов. Я своими глазами наблюдал домашнюю сеть, в которой отовсюду лезла реклама порносайтов и онлайн-казино, хотя на компьютерах не обнаруживалось ни единого вредоноса. Проблема заключалась в трояне, поселившемся в недрах роутера: он подменял адреса DNS-серверов, из-за чего в веб-трафик подмешивалась реклама. Смена настроек DNS на правильные не помогала: через определённые промежутки времени роутер автоматически перезагружался и всё возвращалось на круги своя. Ну а если трою удалось проникнуть в NAS, самый выгодный для злодеев вариант — зашифровать все файлы и потребовать у владельца денег за их расшифровку.

▍ И снова уязвимость

В случае с моим приятелем, с упоминания которого я начал эту заметку, причиной атаки, по всей видимости, послужила старая RCE-уязвимость в PHP7 под названием CVE-2019-11043. NAS от QNAP, как и многие другие сетевые хранилища, «смотрит» в интернет, и на нём поднят небольшой веб-сервер. Упомянутая уязвимость позволяет выполнять на атакуемом хосте произвольный код, просто обращаясь к определённым URL с добавлением к ним префикса «?a=[…]». PoC-эксплоит для CVE-2019-11043 был опубликован на GitHub ещё в 2019 году, а сама уязвимость для своей эксплуатации не требует каких-то глубоких знаний и специальных навыков, что и предопределило её популярность.

Эта дыра актуальна только для веб-серверов на платформе nginx с поддержкой FastCGI Process Manager или PHP-FPM. Чтобы злодеи могли запустить шифровальщика в сетевом хранилище, требуется сочетание нескольких факторов. Во-первых, операционная система QTS, которая обслуживает сетевые накопители QNAP, не должна быть обновлена до актуальной версии (в которых все потенциально опасные дыры уже пофиксили), во-вторых, на устройстве должен работать nginx и PHP-FPM (не на всех сетевых накопителях он запущен по умолчанию). Здесь сработали все эти факторы: NAS имел доступ в интернет, на нём была установлена «торрентокачалка», а обновлений он не видел со времён царя Гороха.


DeadBolt

Сегодня вектор атак с использованием уязвимостей применяется для распространения шифровальщика-вымогателя DeadBolt, который часто досаждает владельцам NAS, уделяя особое внимание устройствам QNAP и ASUSTOR. Причём он зачастую использует для взлома сетевых накопителей уязвимости в медиасервере Plex или EZ Connect. Только в январе 2022 года DeadBolt зашифровал более 3600 устройств QNAP, после чего производитель NAS вынужден был выкатывать пользователям принудительные обновления.


Qlocker

Исторически одним из первых вымогателей для устройств QNAP был троян, известный под названием Qlocker. Воспользовавшись одной из уязвимостей в ПО сетевого хранилища, Qlocker упаковывал хранящиеся на дисках файлы в запароленные 7z-архивы, а потом требовал у пользователя 0,01 биткоина, обещая предоставить пароль. Заработав таким образом около 350 000 долларов, в мае 2021 года вирусописатели прикрыли взаимодействующий с трояном сайт и сообщили, что прекращают дальнейшее распространение вымогателя.

Не меньше хлопот владельцам NAS доставляет и написанный на Go вымогатель ech0raix, который проникает на устройства старым добрым методом — брутфорсом, хотя не брезгует и использованием уязвимостей. Этот трой первым делом проверяет языковые и региональные настройки NAS: жители России, Украины и Беларуси — избегают счастливой участи стать жертвами энкодера. Затем ech0raix запрашивает с расположенного в Tor управляющего сервера публичный ключ шифрования, прибивает процессы httpd, mysqld, mysqd, php-fpm, apache2 и nginx, после чего начинает шифровать документы Microsoft Word, OpenOffice, PDF-файлы, изображения, видеофайлы, текстовые документы и базы данных. По окончании процесса жертве демонстрируется требование заплатить выкуп в биткойнах на BTC-кошелёк, уникальное имя которого троян получает с управляющего сервера. Любопытно, что вирусописатели регулярно обновляют код трояна, устраняя возможность использования различных утилит для расшифровки файлов, которые создают ИБ-эксперты. А исходя из того, что в URL для запроса данных на C&C используется специальный параметр, идентифицирующий трояна, можно предположить, что для распространения ech0raix активно используются различные партнёрки, продвигающие его по схеме SaaS.


ech0raix

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

▍ Что делать-то?

Таким образом, мы установили два основных вектора атак малвари на сетевые хранилища, и первый из них — несвоевременная установка обновлений. Тут совет простой: не отключайте авто-апдейты и по возможности скачивайте и устанавливайте обновлённые прошивки с сайта производителя устройства по мере их появления. Однако, если речь идёт об уязвимостях нулевого дня, которыми, в частности, пользовался DeadBolt, это не поможет. Авторы трояна даже обращались к производителям NAS с предложением продать им информацию о 0-day уязвимостях, которые использует малварь для проникновения на устройство, и заодно обещали им передать мастер-ключ для расшифровки всех пострадавших от нашествия DeadBolt файлов, но не нашли понимания. Так что своевременное обновление — это важная вещь, но отнюдь не панацея.

Второй вектор — неправильная конфигурация самого устройства. Про смену дефолтных паролей я отдельно упоминать не стану, это вещь сама собой разумеющаяся. Что ещё можно предпринять, чтобы хоть немного обезопасить NAS от возможного нашествия вредоносов?

• Установите сложные и уникальные пароли для доступа к устройству;
• Измените порты по умолчанию для веб-доступа к NAS (80, 8080, 8000, 8001), а также порты удалённого доступа Telnet/SSH (443 и 22);
• Если вы не используете их, отключите службы Terminal, SSH и SFTP;
• Закройте порты и отключите службы Plex и EZ Connect, если они вам не нужны;
• По возможности вообще не подключайте NAS к интернету.

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

Существует и ещё один вектор атак, о котором я не упомянул ранее — социальная инженерия и фишинг. Имеется тысяча и один способ выманить у пользователя логин-пароль от его учётки на сервере электронной почты или в социальных сетях. Кроме того, в Telegram полно ботов, предлагающих выдать по адресу электронной почты или номеру телефона привязанные к ним пароли, слитые со взломанных сайтов интернет-магазинов и различных служб доставки. Если вы везде используете одни и те же учётные данные, у меня для вас плохие новости. Безусловно, городить атаку методом социальной инженерии, чтобы взломать чей-то личный NAS — довольно непростое и накладное мероприятие. Но если за расшифровку ценных файлов у жертвы можно запросить несколько тысяч долларов, а злоумышленник точно знает, что такие деньги у пострадавшего есть, игра вполне может стоить свеч.

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

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