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

Сценарий

Во время вашей смены в качестве аналитика второй линии SOC вы получаете информацию с первой линии относительно общедоступного сервера. Этот сервер был помечен как установивший подключения к нескольким подозрительным IP-адресам. В ответ вы запускаете стандартный протокол реагирования на инциденты, который создает изоляцию сервера от сети для предотвращения потенциального горизонтального перемещения или утечки данных и получение перехваченного пакета от утилиты NSM для анализа. Ваша задача — проанализировать PCAP и проверить наличие признаков вредоносной активности.

Используемый инструмент - Wireshark.

Галопом по Европам: Cмотрим на CVE-2023-49103

CVE-2023-49103 представляет собой возможность удаленного выполнения кода (RCE) в Apache ActiveMQ, что позволяет удаленному злоумышленнику, который имеет сетевой доступ к Apache ActiveMQ, выполнять произвольные команды оболочки. Атака включает манипулирование сериализованными типами классов в протоколе OpenWire, побуждая брокера создать экземпляр любого доступного класса в пути к классам.

Коротко и ясно: про сериализацию и десериализацию

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

Немного про Apache ActiveMQ

Это опенсорсный брокер сообщений, который представляет собой реализацию API службы сообщений Java для обмена данными между программными компонентами. Active MQ поддерживает протоколы OpenWire и Stomp.
Словом, его основная функция — пересылка сообщений между различными приложениями.

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

Именно здесь и попались Apache ActiveMQ. Злоумышленник может создать поддельный класс и обманом заставить систему считать его легитимным. Когда система пытается использовать этот класс во время десериализации, она, помимо легитимных действий, принимается выполнять вредоносный код. Используя эту уязвимость, злоумышленник создает экземпляр класса ClassPathXmlApplicationContext и передает ему в качестве параметра XML-файл с вредоносным кодом. Ниже - пример файла как полезной нагрузки.

<?xml version="1.0" encoding="UTF-8" ?>
    <beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="
     http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
        <bean id="pb" class="java.lang.ProcessBuilder" init-method="start">
            <constructor-arg >
            <list>
                <value>open</value>
                <value>-a</value>
                <value>calculator</value>
            </list>
            </constructor-arg>
        </bean>

Для эксплуатации данной уязвимости многие прибегают к использованию публичных эксплойтов, пример такого эксплойта можно посмотреть тут: CVE-2023-46604.

Смотрим на атаку

Все начинается с того, что злоумышленник, имея сетевой доступ к нашему серверу, использует протокол OpenWire. Каким образом и для чего?

  1. Он создает экземпляр сериализуемого класса и преобразовывает его в байтовый поток с помощью механизма сериализации.

  2. Байтовый поток с сериализованными данными упаковывается в OpenWire, которое включает в себя заголовок и тело сообщения.

  3. Сообщение OpenWire передается через сеть от клиента к брокеру с использованием протокола TCP.

  4. Брокер получает сообщение, извлекает из него байтовый поток с сериализованными данными и распаковывает их.

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

Злоумышленник использует класс ClassPathXmlApplicationContext для загрузки вредоносного invoice.xml со своего C2-сервера. Все это дело отправляется на порт 61616, который является дефолтным для Apache ActiveMQ.

То, как это выглядит со стороны..
То, как это выглядит со стороны..
..и то, что происходит внутри
..и то, что происходит внутри

Именно этот вредоносный XML определяет произвольный код, который будет запускаться на уязвимой машине.
Злоумышленник посылает HTTP-запрос на скомпрометированный сервер, запрашивая XML. Это позволяет ему запустить код с помощью Java-класса java.lang.ProcessBuilder и метода start, что можно увидеть в запросе.

Внутренности, которые очень интересно посмотреть:

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

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

Взаимодействие с хостом с одеялом HTTPS: всего лишь зашифрованный секрет
Взаимодействие с хостом с одеялом HTTPS: всего лишь зашифрованный секрет

Что стоит почитать, чтобы точно разобраться с CVE-2023-46604: ресерчи, разборы, атаки

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