Приветствую, читатели. И начну я сразу же с вопроса. Что вы знаете о червях? Нет, не тех, что обитают в земле, а о компьютерных паразитах. Скорее всего, большинство ответит, мол, их называют червями, потому что они, подобно этим существам, способны распространяться между устройствами без непосредственного участия злоумышленника. Некоторые люди припомнят эпидемию вируса Mydoom 2004 года или уже ставший культовым вредонос ILoveYou. 

Примерно с 2000 годов до 2010 была целая эра компьютерных червей. Их разнообразие в те годы было настолько огромным, что говорить об этом можно практически бесконечно. 

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

Все изменилось летом этого года, когда исследователями был обнаружен абсолютно новый и продвинутый червь, который распространяется через уязвимости нулевого дня. P2P Infect — это и есть предмет нашего сегодняшнего диалога. Обнаружен он был 11 июля 2023 года и нацелен на облачные серверы с установленным популярным приложением для работы с базами данных Redis. Но сперва выделю основную информацию о типе этого вредоноса. 

Компьютерные черви — что же это такое на самом деле? 

Компьютерные черви (или просто «черви»‎) — это тип вредоносных программ, которые распространяются по компьютерным сетям и системам, копируя себя и распространяясь автоматически без необходимости вмешательства пользователя. Они отличаются от компьютерных вирусов, которые прикрепляются к исполняемым файлам и требуют выполнения таких файлов для своего распространения.

Вот некоторые характеристики компьютерных червей:

Автономное распространение: черви способны распространяться по сети, находя и инфицируя уязвимые компьютеры без участия пользователя. Они могут использовать различные методы, такие как сканирование IP-адресов и эксплуатацию известных уязвимостей, чтобы попасть на новые компьютеры.

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

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

Масштаб и скорость: черви могут быстро распространяться по сетям, инфицируя множество компьютеров за короткое время.

Уязвимость нулевого дня (zero-day vulnerability) — это уязвимость в программном обеспечении или операционной системе, которая стала известной злоумышленникам до того, как разработчики соответствующего программного продукта выпустили патч или исправление для этой уязвимости. Термин означает, что у разработчиков нет ни одного дня для исправления уязвимости, так как они ещё не знают о её существовании.

Redis (Remote Dictionary Server) — это высокопроизводительная, открытая, динамическая система управления данными и кэширования, которая использует память для хранения данных. Redis был разработан как ключ-значение для хранилища данных, но он также предоставляет ряд других структур данных для работы с различными типами данных.

Краткая история вредоноса P2P Infect 

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

За это время ему удалось скомпрометировать более 300 тысяч систем, в том числе и в России, с установленным ПО Redis. В основном от действий червя страдают облачные хостинги. P2P Infect пока что не оказывает на зараженные устройства никакого воздействия, просто оставаясь в системе. Но стоит отметить, что вредонос имеет очень продвинутую систему управления и зараженное устройство может быть использовано для любых противозаконных действий. Самое интересное, что P2P может даже организовывать DDoS-атаки, выполняя функцию ботнета. 

Для первичного доступа к системе, вирус использует критическую уязвимость CVE-2022-0543. Отдельного внимания стоит то, что отнюдь не только P2P пользуется ей, к примеру, этот безымянный вредонос на GO эксплуатирует ту же болячку. 

CVE-2022-0543 — это уязвимость, позволяющая злоумышленнику скомпрометировать оболочку Redis и выйти из так называемой «песочницы», а затем с помощью простого LUA-скрипта выполнять на удаленной машине произвольный код. 

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

Уязвимость CVE-2022-0543 

Здесь стоит отметить, что другие вредоносы, которые также атакуют платформу Redis, не очень часто используют конкретно эту уязвимость. Конкретных причин для этого нет, но факт остается фактом. 

CVE-2022-0543 представляет собой уязвимость в библиотеке LUA, которая непосредственно связана с установкой дистрибутивов на основе Debian и Ubuntu. Возникла она из-за того, что библиотека LUA предоставляется как динамическая, и одна переменных, а именно package, заполняется автоматически. Из этого выплывает то, что удаленный злоумышленник, намеренно не указывая или указывая ложную переменную, мог выполнить псеводопроизвольную команду на удаленном сервере. 

Таким образом при выполнении Package к нему всегда будет добавлен фрагмент .loadlib, что вызывает загрузку основных модулей LUA, которые в дальнейшем можно использовать для выполнения базовых команд:

local io_l = package("/usr/lib/x86_64-linux-gnu/liblua5.1.so.0", "luaopen_io");
local io = io_l();
local f = io.popen("id", "r");
local res = f:read("*a");
f:close();
return res

А в оболочке Redis это будет выглядеть следующим образом: 

eval 'local io_l = package.loadlib("/usr/lib/x86_64-linux-gnu/liblua5.1.so.0", "luaopen_io"); local io = io_l(); local f = io.popen("id", "r"); local res = f:read("*a"); f:close(); return res' 0

Необходимо уточнить, что я предоставляю данные, которые и так находятся в открытом доступе и уязвимость уже была исправлена.

Краткий статистический анализ P2P Infect 

Список инструментов, используемых для анализа: 

  1. DIE — Detect It Easy: многофункциональный инструмент, имеющий просто огромный арсенал. Позволит нам опередить тип компилятора вредоноса, язык, библиотеки и таблицы импорта/экспорта с последующим дизассемблированием. 

  2. PE Bear — неплохой инструмент для просмотра и редактирования составляющих PE-файла. 

  3. Tiny Tracer — утилита для динамического отслеживания исполнения бинарных элементов. Так называемый трейсер.

  4. IDA PRO — инструмент для реверс-инжиниринга. 

  5. Reko — декомпилятор, также знаком нам с прошлых статей.

  6. HollowHunter — утилита распознает и сбрасывает множество потенциально вредоносных имплантов (замененные/имплантированные PE, шелл-коды, перехватчики, патчи в памяти)

  7. Wireshark — программа-анализатор трафика для компьютерных сетей Ethernet и некоторых других. Имеет графический пользовательский интерфейс.

  8. NotePad++ — неплохой редактор текстовых файлов.

Итак, по счастливой случайности мне удалось раздобыть достаточно свежий образец этого вредоноса. Как уже ранее упоминалось, вредонос написан на достаточно гибком и простом языке Rust. Этот язык прекрасно подходит для различных облачных вычислительных операций, так как он достаточно быстр и оптимизирован.

Также стоит уточнить, что посредством использования уязвимости происходит только первичная установка червя в систему, далее вирус свяжется с командным сервером и начнет загружать дополнительные полезные нагрузки, их список примерно таков: 

  1. Первичная полезная нагрузка: закрепление в системе, связь с C&C-сервером и загрузка конфигурации.  

  2. Вторичная полезная нагрузка: этап распространения в локальной среде

  3. Третичная полезная нагрузка: конечный модуль управления

 Сперва давайте разберемся с первичной полезной нагрузкой. 

Первичная полезная нагрузка: закрепление в системе, связь с C&C сервером

Перед нашими глазами образец весом всего в 3 КБ и без какой-либо сопутствующей информации. Использовать DIE в этом случае будет практически бесполезно, но все же я это сделал: 

По традиции выгрузим вредонос на VirusTotal, чтобы определить процент обнаружения антивирусными приложениями. Барабанная дробь, ни один из антивирусов его не видит! К слову, Rust вполне себе может быть установлен на Windows, а значит, что и P2P может запуститься. Возникает логичный вопрос, а почему хэша вредоноса нет в антивирусных базах? 

Для просмотра кода первичной полезной нагрузки мы воспользуемся обычным Notepad++. Оказалось, что он никак не зашифрован, но только в этом случае. 

Сразу после попадания на устройство вредонос определит свою копию в следующие директории:

/usr /lib/x86/

В случае Windows он ещё и создаст ключ реестра, позволяющий ему запускаться автоматически при старте системы: 

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

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

Затем вредонос пытается связаться с C&C сервером, IP-адреса этих серверов указаны в самом коде и никак не шифруются: 

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

Далеко не с первой попытки удалось перехватить загружаемый протокол связи, но выглядит он следующим образом: 

Естественно, он закодирован, и узнать о его подробном содержимом не представляется возможным, по крайней мере, на данный момент. Но при более детальном осмотре удалось установить, что это модифицированный протокол TLS 1.3. 

TLS 1.3 (Transport Layer Security 1.3) — это криптографический протокол безопасности, который используется для защиты соединений в сетях, таких как интернет. Он представляет собой последнюю версию протокола TLS, который был разработан для обеспечения конфиденциальности и целостности данных, а также аутентификации серверов и клиентов во время обмена информацией.

Также я заметил загрузку нескольких файлов, а именно: p2p.rs, linux.rs, config.json, windows.rs и miner.rs, vuln.rs.

Затем основной скрипт запустит только загруженный файл p2p.rs и закончит своё выполнение.

Вторичная полезная нагрузка: этап распространения в локальной среде

Переходим к обзору второго модуля вредоноса. Сразу после запуска червь обновит списки серверов, на которых он уже установлен, добавив текущий IP-адрес. Реализовано это посредством простого запроса на редактирование файла config.json.

И на этом моменте червь начинает просто перебирать сначала локальную сеть на наличие уязвимых серверов, а в случае неудачи — случайный диапазон IP-адресов. В WireShark это выглядит следующим образом: 

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

И на этом функции конкретно этого модуля заканчиваются. Далее он запустит основной модуль в зависимости от типа системы, в конкретно моем случае был запущен Windows.rs.

Третичная полезная нагрузка: конечный модуль управления

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

Основные функции этого модуля следующие:

  1. Скачать и запустить (считайте, некое подобие простого дроппера).

  2. DDoS. 

  3. Обновление. 

  4. Самоуничтожение.

  5. Отключение сервера от интернета(самая странная функция). 

Естественно, они выполняются только при получении команды от основного сервера управления, но до сих пор они просто висят, увеличивая лишь свою численность. Думаю, ранее вы заметили модуль miner.rs, и изначально ходили слухи, что червь P2P майнит криптовалюту на серверах Redis, но этот файл никак не был задействован, он просто есть. В случае, когда никаких команд червю не поступает, он продолжает находиться в режиме сна.

DDoS (Distributed Denial of Service) — это вид кибератаки, при котором злоумышленники пытаются перегрузить целевой сервер или сеть трафиком, чтобы сделать их недоступными для легитимных пользователей. В отличие от обычной атаки на сервер, при которой злоумышленник пытается получить несанкционированный доступ к данным или ресурсам, DDoS-атака направлена на выведение ресурса из строя, делая его недоступным.

Специалистами из Unit 42 был также обнаружен вредоносный PowerShell, который настраивал брандмауэр Windows так, чтобы устройство больше не давало подключиться пользователям из сети Redis. Разрешены к подключению только С&C-сервера, адреса которых заранее были внесены в правило Защитника. Я такого скрипта не нашел, но обязан упомянуть об этом. Таким нехитрым образом злоумышленникам удается дольше сохранять доступ к зараженной машине. 

Но вот что мне удалось найти интересного, так это мониторинговую службу червя P2P, эта его особенность проявляется только при развертывании на операционной системе Windows. Червь наблюдает и записывает деятельность собственных процессов, а затем сохраняет этот дамп по следующему пути: 

C:\Users\username\AppData\Local\Temp

К слову, зачем он это делает — я не знаю. Скорее всего, злоумышленники хотят убедиться, что их их детище работает нормально. Но это все очень сомнительно. 

Методы обнаружения и выводы

Переходим к самому главному. Как вы уже могли понять, P2P Infect является модульным червем, написанным на языке Rust. Сам по себе этот язык очень гибок и отказоустойчив, а также универсален. При наличии пакета Rust приложение на этом языке может быть запущено на любом устройстве: Windows, Linux, MAC. 

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

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

Корень всего зла — необновленный Redis, хотя стоит отметить, что даже если вы его обновите, это не будет 100% гарантом вашей безопасности. Стоит признать, уязвимо практически всё. Но так как P2P распространяется исключительно через уязвимость CVE-2022-0543, то обновив Redis, вы точно не станете очередной жертвой. 

Что же делать, если червь-ботнет уже на вашем устройстве? Его достаточно просто удалить вручную. Так как в этой статье уже были описаны все идентификаторы компрометации, то повторяться не буду. А на этом у меня все. До скорого.

Автор статьи @DeathDay


НЛО прилетело и оставило здесь промокод для читателей нашего блога:
— 15% на заказ любого VDS (кроме тарифа Прогрев) — HABRFIRSTVDS.

Комментарии (14)


  1. olegtsss
    28.11.2023 07:59
    -1

    Не совсем понятно, зачем Redis светить в LAN (еще хуже WAN)? Он должен кешировать ответы от сервиса, логично еще держать на localhost. Зачем вообще делать хеш сервер доступным за пределами localhost, грубо говоря за пределами веб сервера (сервера приложения)?


    1. Heggi
      28.11.2023 07:59
      +1

      Редис не только как кеш используют, а еще как Key-Value DB, при этом кластеризуют и творят прочие непотребства. В большинстве случаев редис находится на отдельном сервере и торчит в локалку.

      Другой вопрос что в таких случаях надо включать авторизацию (да и файрвол правильно настраивать надо)


      1. olegtsss
        28.11.2023 07:59
        -2

        По-моему мнению, общение с любой базой осуществляется через сервис. Мы не никогда не оставляем базу данных, например, Postgre, открытой своим 5432 портом в LAN. Потому что это не безопасно. Так и здесь, сервис осуществляет полное взаимодействие с ней и все процедуры: AAA и т.д.


        1. Areso
          28.11.2023 07:59

          а как у вас взаимодействует сервис и база, если они на разных серверах?


          1. olegtsss
            28.11.2023 07:59

            Сервис "прикрывает" базу. Это backend приложение, доступ к которому может балансироваться и т.д. База работает с ним либо в изолированной среде (согласен, что это тоже lan) - на одном сервере или кластере. Есть вариант vpn, но это тоже не самое безопасное решение. Такое же архитектурное решение обычно принято. Хотя отвечая на свой же вопрос - вредоносный код может оказаться в одном кластере с Redis в каком-нибудь не благонадежном контейнере). Таким образом, проблема не безопасности сохраняется.


            1. withkittens
              28.11.2023 07:59
              +3

              Сервис "прикрывает" базу. Это backend приложение,

              То есть вместо специально предназначенных инструментов (фаервола и аутентификации) использовать какие-то костыли?


              1. olegtsss
                28.11.2023 07:59

                Firewall-то вам как прикроет сервис)? А так да, только это называется backend.


    1. dsh2dsh
      28.11.2023 07:59
      +2

      Ответ, я полагаю, простой. Потому что очередной DevOps прочитал в статье от такого же DevOps, что для того, что бы запустить редис, нужно выполнить вон ту команду с докером. Ну и сделал. Он что, должен что-ли ещё разбираться, как это работает? И вот так всЕ.


      1. olegtsss
        28.11.2023 07:59

        Вот вы верно тут между строк подметили, учиться никогда не поздно, особенно на ошибках). Но в серьезной продуктовой инфраструктуре такого же колхоза не встретишь или я ошибаюсь?


        1. withkittens
          28.11.2023 07:59

          Как это не встретишь? Торчащая редиска без аутентификации - это уже классика. Вот первая попавшаяся статья для понимания масштабов проблемы: В зоне доступа: Group-IB обнаружила в России 7 500 незащищенных баз данных / Хабр (habr.com)


        1. baldr
          28.11.2023 07:59

          По-умолчанию mongoDB и Redis до недавнего времени ставили "listen 0.0.0.0". Без авторизации. Причем, по-умолчанию, конфиг не нужен и поди догадайся что надо его явно прописать и запретить это всё.

          Только в последних версиях пару лет назад это всё переделали под "127.0.0.1".

          А часто бывает что надо поднять сервачок - и берут недорогой VPS где-нибудь. Firewall-то есть, вроде бы, а по факту не всегда.


          1. olegtsss
            28.11.2023 07:59

            Я выше про это выше писал, но получил минусы. Специалисты почему-то верят, что им тут поможет firewall. Насколько видно из контекста - L3 firewall ) . В результате считаю, что высказанное выше мнение про "очередной DevOps" истино. Заражались криво настроенные DB (например, как вы и пишите - с конфигами из прошлого или из сомнительных контейнеров). А далее все становится еще яснее - за сетью никто не следит, полный бардак, что создает отличные условия для распространения заразы. Вывод - хорошему специалисту всегда будет чем заняться)


            1. baldr
              28.11.2023 07:59

              Минусы вы получили, скорее всего, за категоричное сомнение в использовании Redis отдельно от localhost. Во внутренней сети вполне себе хорошо может использоваться же.

              Ну а криво настроить можно что угодно - Docker, кстати, по-умолчанию тоже на 0.0.0.0 биндит порты при ключе "-p".


  1. olegtsss
    28.11.2023 07:59

    Такова ИБ - если база светит портом в сеть, жди проблем. А если соединение с базой еще не зашифровано - то и целостность, и достоверность и доступность информации будет сомнительна. Уведут у вас и сервер и инфу с него.