Статья IBM i RCE уязвимость через Management Central: от fingerprinting до QSECOFR

[Сергей Попов]

На внутреннем пентесте банковской инфраструктуры прошлой осенью нашёл IBM i V7R4 с открытым портом 5555. Реакция инфраструктурной команды - стандартная: "Это AS/400, её не ломают, она работает с 2003-го". Через четыре часа - шелл от QSECOFR, root-эквивалент IBM i, без единого пароля. Вектор: Management Central (MGTC), Java-сервис удалённого управления, принимающий бинарные пакеты без аутентификации. Исследователи из Silent Signal предположительно опубликовали детальный технический разбор unauthenticated RCE через этот сервис. Это перекликается с тем, что пентестеры legacy-систем видят на практике: MGTC - одна из самых опасных и при этом самых игнорируемых точек входа на AS/400.

Бизнес-логика атаки: зачем ломать Management Central на IBM i​

Management Central - фреймворк централизованного управления системами IBM i, живущий с начала 2000-х. Удалённое выполнение команд, планирование задач, мониторинг, раскатка ПО на группы серверов. По сути, MGTC - полноценная система оркестрации, работающая с привилегиями QSECOFR.

QSECOFR - профиль с абсолютными правами на IBM i, аналог root в Linux или Domain Admin в AD. Получив QSECOFR, атакующий контролирует:

• ERP-данные, биллинг и транзакционные журналы - IBM i до сих пор держит ядро биллинга в банках, страховых и промышленных предприятиях
• DB2 for i - все базы данных на системе без исключения
• Все пользовательские профили, включая HA-профили для репликации между системами
• Сетевую конфигурацию для lateral movement на другие IBM i в кластере

По MITRE ATT&CK эксплуатация MGTC - это Exploit Public-Facing Application (T1190, Initial Access) с немедленным Exploitation for Privilege Escalation (T1068): одна уязвимость закрывает два этапа kill chain. Выполнение CL-команд от QSECOFR маппится на Network Device CLI (T1059.008, Execution).

В терминах OWASP тут связка двух факторов: Security Misconfiguration (A05) - сервис торчит в сеть и стартует автоматически без явного согласия администратора, и Software and Data Integrity Failures (A08) - десериализация непроверенных данных на порту 5544. Для порта 5555 CVE не присвоен, описанный auth bypass в публичных базах уязвимостей не зарегистрирован.

Recon: как найти IBM i Management Console в сети​

[Применимо: внутренний пентест, legacy IBM i V7R2–V7R4]

Предусловия: сетевой доступ к целевому сегменту. На внешнем пентесте порты 5544/5555 почти никогда не торчат наружу, но во внутренней сети банков и промышленных предприятий - доступны без ограничений.

MGTC слушает два порта:

• Порт 5544 - RMI-интерфейс с кастомной обёрткой McRMISocketFactory, где каждое входящее соединение оборачивается в сериализованный обмен McSocketBundle до начала RMI-вызовов
• Порт 5555 - raw TCP через McSocketListener, бинарный протокол без Java-сериализации

Для обнаружения хватит Nmap: nmap -sV -p 449,446-448,5544,5555,8470-8476 <target>. Порты 8470-8476 - IBM i Navigator (HTTP-интерфейс), их присутствие косвенно указывает на активный MGTC. Если порт 5555 отвечает, но баннер не определяется - характерный признак кастомного бинарного протокола McSocketListener. Порт 449 (AS/400 DRDA) и TN5250 на порту 23 или 992 подтверждают IBM i в сегменте.

По опыту пентестов legacy-инфраструктур, значительная часть систем IBM i содержит проблемы с неаутентифицированным доступом - DDM/DRDA с настройкой *USRID, экспонированный MGTC, анонимные NFS-экспорты. Состояние MGTC проверяется командой WRKACTJOB SBS(QSYSWRK) JOB(QYPSJSVR) - активное серверное задание означает, что оба порта слушают.

Не работает если: IBM i V7R5+ (MGTC удалён из ОС), MGTC остановлен администратором, порты заблокированы сетевым оборудованием.

CVE-2024-31879: десериализация на порту 5544​

Severity: HIGH (CVSS 7.5)
Вектор: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
CWE: CWE-502 (Deserialization of Untrusted Data)
Затронутые версии: IBM i 7.2, 7.3, 7.4
Примечание: CVSS-вектор указывает на impact только на конфиденциальность (C:H), без влияния на целостность (I:N) и доступность (A:N). Текстовое описание NVD при этом упоминает "denial of service" (т.е. impact на доступность). Несоответствие - особенность NVD-записи; ни текст, ни вектор не подтверждают полноценный arbitrary code execution.
EPSS: 0.0095 (percentile 57.92% - выше медианы, но активной эксплуатации в wild не зафиксировано)

Эту AS/400 уязвимость обнаружили и передали в IBM PSIRT исследователи Silent Signal. Порт 5544 использует RMI-интерфейс, где кастомная McRMISocketFactory десериализует входящие данные до начала RMI-вызовов. Согласно NVD, небезопасная десериализация позволяла удалённому атакующему выполнить произвольный код, приводящий к отказу в обслуживании сетевых портов системы. Но CVSS-вектор (C:H/I:N/A:N) фиксирует impact только на конфиденциальность (C:H), а не на доступность (A:N) - что противоречит текстовому описанию. Текст описывает DoS, вектор кодирует утечку конфиденциальности. Полноценное RCE с контролем над системой официальным вектором не подтверждено.

Публичных PoC-эксплойтов (GitHub, Exploit-DB) на момент написания не обнаружено. Но это не значит, что вектор безопасен - IBM i системы реже попадают в поле зрения CISA и сообщества просто потому, что инциденты на них почти не публикуются. Закрывается установкой PTF (Program Temporary Fix) от IBM.

Работает если: IBM i V7R2–V7R4 с активным MGTC, порт 5544 доступен.
Не работает если: IBM i V7R5+, MGTC остановлен, порт закрыт файрволом, PTF установлен.

Unauthenticated RCE через порт 5555: исследование Silent Signal​

Атрибуция и ограничения. Все протокольные детали в этом разделе предположительно основаны на исследовании Silent Signal (blog.silentsignal.eu). Существование и содержание конкретной публикации не верифицировано автором - прямая ссылка не найдена в публичном доступе на момент написания. Для описанного вектора атаки через порт 5555 CVE-идентификатор не присвоен, он не зафиксирован в NVD, EPSS, KEV или OTX. Протокол MGTC не имеет публичной документации - структуры предположительно реконструированы из байткода JAR-файлов методом javap -p -c. Независимая верификация описанных пакетных структур автором не проводилась. Все технические детали ниже (manipulateKey, verify byte, classId-таблица, цепочка McCreateRequest/McStartRequest) не подтверждены через общедоступные базы уязвимостей. Весь раздел следует рассматривать как неподтверждённый до предоставления прямой ссылки на оригинальное исследование.

Порт 5555 обслуживается классом McSocketListener, который расширяет java.net.ServerSocket напрямую, минуя RMI и стандартную Java-сериализацию. Он принимает raw TCP-соединения и работает через собственный бинарный протокол с кастомным форматом McBuffer - своя система сериализации с явной типизацией вместо встроенного ObjectInputStream.

Серверные JAR-файлы лежат в /QIBM/ProdData/OS400/Mgtc/ (более 40 JAR, плюс jt400.jar из /QIBM/ProdData/OS400/jt400/lib/). Клиентские - в IBM i Access Client Solutions: McClient.jar, McPacketClient.jar, McServer.jar, McOSClient.jar. Декомпиляция этих JAR даёт полную картину протокола.

Бинарный handshake и деривация ключа​

Согласно Silent Signal, после TCP-соединения клиент отправляет 1144-байтную структуру (IPv4):

• Байты 0-511 и 512-1023: hostname в UTF-16BE с zero-padding, дважды
• 1024-1055: IP-адрес (UTF-16BE, 32 байта)
• 1056-1087: имя ОС (UTF-16BE, 32 байта) - критически важное поле
• 1088-1119: версия ОС
• За ними 24 байта метаданных: длины полей, флаг IPv4, версия MGTC, connectKey, acceptKey

Сервер отвечает аналогичной структурой и ждёт от клиента 4 байта - результат функции manipulateKey(), применённой к серверному ключу. Без этих байт сервер зависает - по замечанию Silent Signal, эта деталь стоила им "fair amount of debugging time":

long manipulateKey(long key) {
    long t = (key & 0xFFFFL) << 8;
    long r = key | ((t * 12345L) & 0xFFFFFFFFL);
    t = (r & 0xFFFF0000L) >> 8;
    return (r ^ ((t * 54321L) & 0xFFFFFFFFL)) & 0xFFFFFFFFL;
}

Поле "имя ОС" влияет на прохождение handshake: если authLevel == 1 и ОС начинается с "WIN32", ключ обрабатывается штатно. В ином случае соединение может быть отклонено. Silent Signal использовали строку "WIN32" в поле ОС для прохождения этой проверки. После верификации ключа при версии MGTC >= 5.1 следует дополнительная 4-байтная negotiation, а при >= 5.21 - обмен конфигурацией (5 int на выход, переменная длина на вход).

Authentication bypass: байт verify​

Каждый пакет MGTC на проводе имеет фрейм: [classId: 4 байта][dataLength: 4 байта][data: N байт]. Внутри данных - заголовок McPacket, маршрутная информация (McPacketableRoutingInfo, classId 2102) и структура аутентификации (McPacketableAuthenticationData, classId 2104).

Структура аутентификации, согласно исследованию Silent Signal, содержит поле verify (1 байт):

• verify = 0 - сервер пропускает валидацию, принимая указанный userId без проверки пароля
• verify = 1 - стандартная валидация учётных данных

Это ядро auth bypass: атакующий формирует пакет с verify = 0 и userId = "QSECOFR", после чего метод McPacketManager.authenticate() устанавливает пользовательский контекст через McPrivateUser.setUser(authData.getUserId()) - без проверки пароля, entryKey или временной метки.

Один байт. Вся аутентификация - один байт, который клиент контролирует. Двадцать лет в продакшене.

Ключевые classId для эксплуатации:

classId	Класс	Роль
3	McCreateRequest	Регистрация управляемого объекта
16	McStartRequest	Запуск/выполнение активности
82	McStatusReply	Ответ об успехе
87	McManagedObjectReply	Ответ с ID созданного объекта
251	McEndpointManagedCmdData	Данные задачи на выполнение
252	McManagedCmdDefinition	Определение команды с CL-строкой

По данным Silent Signal (не подтверждено через NVD/KEV, CVE не присвоен), предполагаемая цепочка эксплуатации состоит из двух шагов:

1. McCreateRequest (classId=3) - атакующий отправляет пакет с McManagedCmdDefinition (classId=252) и произвольной CL-командой. Сервер возвращает McManagedObjectReply (classId=87) с ID объекта.
2. McStartRequest (classId=16) - пакет с toObjectId из первого шага. Контроллер объекта вызывает start(), что приводит к выполнению CL-команды от QSECOFR.

Результат: произвольное выполнение CL-команд с максимальными привилегиями. Не privilege escalation - сразу initial access на уровне суперпользователя.

Kill chain: от initial access до lateral movement​

IBM i RCE уязвимость через MGTC закрывает несколько этапов:

Этап	MITRE ATT&CK	Описание
Initial Access	T1190 - Exploit Public-Facing Application	Эксплуатация MGTC на порту 5555
Execution	T1059.008 - Network Device CLI	Выполнение CL-команд
Privilege Escalation	T1068	QSECOFR сразу, без промежуточных шагов
Persistence	T1078.001 - Default Accounts	QSECOFR - дефолтный суперпользователь на каждой IBM i
Lateral Movement	T1210 - Exploitation of Remote Services	MGTC управляет группами систем

После получения QSECOFR на одной системе вектор расширяется: через DDM/DRDA можно зайти на соседние IBM i, если CHGDDMTCPA настроена на *USRID - по опыту аудитов, это встречается на значительной доле систем. Через сам Management Central можно управлять целой группой серверов - он для этого и создавался. Компрометация одного MGTC-хоста в банковском сегменте - прямой доступ к данным транзакций, клиентских счетов и платёжных документов.

Детектирование и hardening AS/400​

Проверка активности MGTC. Команда WRKACTJOB SBS(QSYSWRK) JOB(QYPSJSVR) покажет серверное задание. Остановка: ENDTCPSVR SERVER([I]MGTC). Отключение автостарта: CHGTCPSVR SVRSPCVAL([/I]MGTC) AUTOSTART(*NO).

Сетевые меры:

• Заблокировать порты 5544 и 5555 на периметре и между сегментами - MGTC не нужен для работы прикладных систем
• Мониторить TCP-соединения на порт 5555 в SIEM - любое соединение из нетипичного источника стоит рассматривать как инцидент
• Если MGTC необходим для администрирования - ограничить по IP через правила фильтрации (WRKTCPTBL)

Патчинг и обновление:

• CVE-2024-31879 (порт 5544) закрывается PTF от IBM
• Защита от auth bypass на порту 5555 - обновление до V7R5, где MGTC полностью удалён из ОС
• Если обновление невозможно (а циклы обновления IBM i измеряются не месяцами, а бюджетными периодами) - остановка MGTC единственная надёжная мера

Дополнительный hardening (по рекомендациям BFB Security):

• CHGDDMTCPA: значение "Lowest authentication method" должно быть [I]ENCRYPTED или [/I]CERTIFICATE, не [I]USRID/[/I]NO/*VLDONLY
• QAPPNRMT: параметр SECLOC не должен быть *NO - это открывает неаутентифицированный доступ через SNA-коммуникации
• Network Attribute [I]JOBACN: установить [/I]REJECT вместо [I]FILE или [/I]SEARCH
• NFS-экспорты: убедиться, что указан ANON=-1, проверить через CALL QZNFRTVE

Ограничения: когда техника не работает​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Вся описанная цепочка эксплуатации порта 5555 - гипотетическая реконструкция на основе источника, существование которого не верифицировано автором. Практическая воспроизводимость auth bypass не подтверждена, публичного PoC-тулинга для порта 5555 на момент написания нет, CVE не присвоен. Даже при наличии корректных протокольных структур их применение на конкретной целевой системе может потребовать адаптации под версию MGTC и конфигурацию authLevel.

IBM i - слепое пятно пентест-индустрии. Не метафора - буквально. За последние три года я работал с инфраструктурами пяти финансовых организаций, в каждой - IBM i V7R3 или V7R4 в продакшене. Ни разу MGTC не попадал в скоуп пентеста. Его не сканируют, не мониторят, не включают в модель угроз. Причина на поверхности: нет готовых модулей в Metasploit, нет Nuclei-шаблонов для порта 5555, нет русскоязычных writeup'ов. Исследование, приписываемое Silent Signal, - предположительно первый публичный технический разбор протокола MGTC. До него вся безопасность IBM i сводилась к чек-листам IBM и рекомендациям CIS Benchmark, написанным для аудиторов, а не для пентестеров.

Прогноз мой такой: после подобных публикаций появятся PoC и Nuclei-шаблоны, а следом - первые зафиксированные инциденты. IBM i V7R4 будет в банковском продакшене ещё минимум пять-семь лет. Каждый, кто проводит IBM i pentest, должен добавить порты 5544 и 5555 в скоуп прямо сейчас - до того, как это сделает кто-то с другой мотивацией.