![](https://habrastorage.org/webt/_s/qo/1o/_sqo1omeqqlvqaemrcjcfdaqayq.jpeg)
На днях мне позвонил старый приятель, и в панике сообщил, что у него что-то случилось с домашним файлохранилищем 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/».
![](https://habrastorage.org/webt/ek/xk/yo/ekxkyoitgmg17wjnjlb7whmjq0q.jpeg)
Тот самый Synolocker
Второй модуль трояна отвечал за взаимодействие с пользователем. Он генерировал по специальному шаблону веб-страницу с требованием выкупа и начинал прослушивать порт 80, 8080 или 443 в ожидании команд. При поступлении соответствующей директивы от злоумышленников Synolocker расшифровывал файлы (имена обработанных файловых объектов при этом сохранялись в журнал «/usr/syno/synoman/decrypted.log»), после чего самоудалялся.
Очевидной причиной распространения Synolocker была лень владельцев NAS: если бы они вовремя обновляли ПО своего устройства, ничего страшного с ним не случилось бы. Вторая причина — банальная беспечность: некоторые пользователи наивно полагают, что если их девайс работает под управлением Linux, он защищён от всевозможных вредоносов самой архитектурой операционной системы. Хотя это, конечно же, не так.
▍ Воинственные эльфы
![](https://habrastorage.org/webt/tg/ac/sd/tgacsdkobdvv1jgbhes7vl3tzr0.jpeg)
Когда я увольнялся из антивирусной компании в конце 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 имел доступ в интернет, на нём была установлена «торрентокачалка», а обновлений он не видел со времён царя Гороха.
![](https://habrastorage.org/webt/7u/dz/y_/7udzy_w2i9q7cf9opycnre1t5pw.png)
DeadBolt
Сегодня вектор атак с использованием уязвимостей применяется для распространения шифровальщика-вымогателя DeadBolt, который часто досаждает владельцам NAS, уделяя особое внимание устройствам QNAP и ASUSTOR. Причём он зачастую использует для взлома сетевых накопителей уязвимости в медиасервере Plex или EZ Connect. Только в январе 2022 года DeadBolt зашифровал более 3600 устройств QNAP, после чего производитель NAS вынужден был выкатывать пользователям принудительные обновления.
![](https://habrastorage.org/webt/tp/sw/z7/tpswz7fp8ipw2tqeahl23g-2rmw.png)
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.
![](https://habrastorage.org/webt/5k/tw/vo/5ktwvocukjiahvio39huxewkrqa.jpeg)
ech0raix
В общем, дыры в ПО сетевых хранилищ и накопителей обнаруживаются регулярно, и с не меньшей регулярностью появляются шифровальщики, использующие эти уязвимости. Если пользователь не удосужился сменить заводские настройки или использует слабые пароли — на помощь злоумышленникам приходит старый добрый брутфорс.
▍ Что делать-то?
Таким образом, мы установили два основных вектора атак малвари на сетевые хранилища, и первый из них — несвоевременная установка обновлений. Тут совет простой: не отключайте авто-апдейты и по возможности скачивайте и устанавливайте обновлённые прошивки с сайта производителя устройства по мере их появления. Однако, если речь идёт об уязвимостях нулевого дня, которыми, в частности, пользовался DeadBolt, это не поможет. Авторы трояна даже обращались к производителям NAS с предложением продать им информацию о 0-day уязвимостях, которые использует малварь для проникновения на устройство, и заодно обещали им передать мастер-ключ для расшифровки всех пострадавших от нашествия DeadBolt файлов, но не нашли понимания. Так что своевременное обновление — это важная вещь, но отнюдь не панацея.
Второй вектор — неправильная конфигурация самого устройства. Про смену дефолтных паролей я отдельно упоминать не стану, это вещь сама собой разумеющаяся. Что ещё можно предпринять, чтобы хоть немного обезопасить NAS от возможного нашествия вредоносов?
- Установите сложные и уникальные пароли для доступа к устройству;
- Измените порты по умолчанию для веб-доступа к NAS (80, 8080, 8000, 8001, 443), а также порты удалённого доступа Telnet/SSH (23 и 22);
- Если вы не используете их, отключите службы Terminal, SSH и SFTP;
- Закройте порты и отключите службы Plex и EZ Connect, если они вам не нужны;
- По возможности вообще не подключайте NAS к интернету.
Специалисты по ИБ также рекомендуют в обязательном порядке делать резервные копии всех хранящихся на дисках NAS файлов, но основная проблема заключается в том, что NAS как раз чаще всего и используется именно в качестве хранилища резервных копий. То есть, совет, безусловно, мудрый и правильный, но с этой точки зрения, несколько странный.
Существует и ещё один вектор атак, о котором я не упомянул ранее — социальная инженерия и фишинг. Имеется тысяча и один способ выманить у пользователя логин-пароль от его учётки на сервере электронной почты или в социальных сетях. Кроме того, в Telegram полно ботов, предлагающих выдать по адресу электронной почты или номеру телефона привязанные к ним пароли, слитые со взломанных сайтов интернет-магазинов и различных служб доставки. Если вы везде используете одни и те же учётные данные, у меня для вас плохие новости. Безусловно, городить атаку методом социальной инженерии, чтобы взломать чей-то личный NAS — довольно непростое и накладное мероприятие. Но если за расшифровку ценных файлов у жертвы можно запросить несколько тысяч долларов, а злоумышленник точно знает, что такие деньги у пострадавшего есть, игра вполне может стоить свеч.
Довольно разумным решением с точки зрения безопасности может стать создание личного облака на арендованном VPS-сервере, куда можно сохранять резервные копии самых ценных файлов. Нужно лишь правильно настроить облако, об этом будет подробная статья позднее.
Сложности могут возникнуть лишь в том случае, если пользователь сам напортачит с настройками или станет использовать для доступа слишком простые пароли, которые легко подобрать по словарю. Конечно, даже личное облачное хранилище не гарантия стопроцентной безопасности, но в качестве резервного инструмента для размещения бекапов и самых ценных файлов этот вариант очень неплох. По крайней мере, он позволит быстро восстановить нужные для работы данные, пока на побитых шифровальщиком дисках переустанавливается система.
![](https://habrastorage.org/webt/sz/7j/pf/sz7jpfj8i1pa6ocj-eia09dev4q.png)