mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/binary-exploitation/libc-heap/heap-overflow.md', 'src/b
This commit is contained in:
Translator
parent
b93e673cc3
commit
a571f52d4f
@ -13,36 +13,68 @@ Stack overflows में हम जानते हैं कि कुछ र
|
||||
|
||||
### Stack Overflows vs Heap Overflows
|
||||
|
||||
Stack overflows में उस समय stack में मौजूद डेटा और व्यवस्था जो भेद्यता को सक्रिय कर सकती है, काफी विश्वसनीय होती है। इसका कारण यह है कि stack रैखिक है, हमेशा टकराते मेमोरी में बढ़ता है, **कार्यक्रम के चलने के विशिष्ट स्थानों पर stack मेमोरी आमतौर पर समान प्रकार के डेटा को स्टोर करती है** और इसमें प्रत्येक फ़ंक्शन द्वारा उपयोग किए जाने वाले stack भाग के अंत में कुछ पॉइंटर्स के साथ कुछ विशिष्ट संरचना होती है।
|
||||
Stack overflows में उस समय stack में मौजूद डेटा और व्यवस्था जब भेद्यता को सक्रिय किया जा सकता है, काफी विश्वसनीय होती है। इसका कारण यह है कि stack रैखिक है, हमेशा टकराते मेमोरी में बढ़ता है, **कार्यक्रम के चलने के विशिष्ट स्थानों पर stack मेमोरी आमतौर पर समान प्रकार के डेटा को स्टोर करती है** और इसमें प्रत्येक फ़ंक्शन द्वारा उपयोग किए जाने वाले stack भाग के अंत में कुछ पॉइंटर्स के साथ कुछ विशिष्ट संरचना होती है।
|
||||
|
||||
हालांकि, heap overflow के मामले में, उपयोग की गई मेमोरी रैखिक नहीं होती है बल्कि **आवंटित चंक्स आमतौर पर मेमोरी के अलग-अलग स्थानों में होते हैं** (एक के बगल में नहीं) क्योंकि **आकार द्वारा आवंटन को अलग करने के लिए बिन और ज़ोन** होते हैं और क्योंकि **पिछली मुक्त मेमोरी का उपयोग किया जाता है** नए चंक्स आवंटित करने से पहले। यह **जानना जटिल है कि कौन सा ऑब्जेक्ट उस ऑब्जेक्ट के साथ टकराने वाला है जो heap overflow के लिए संवेदनशील है।** इसलिए, जब एक heap overflow पाया जाता है, तो यह आवश्यक है कि **विश्वसनीय तरीके से वांछित ऑब्जेक्ट को उस मेमोरी में अगला बनाना** जो ओवरफ्लो किया जा सकता है।
|
||||
हालांकि, heap overflow के मामले में, उपयोग की गई मेमोरी रैखिक नहीं होती है बल्कि **आवंटित चंक्स आमतौर पर मेमोरी के अलग-अलग स्थानों में होते हैं** (एक के बगल में नहीं) क्योंकि **bins और zones** आवंटनों को आकार के अनुसार अलग करते हैं और क्योंकि **पिछली मुक्त मेमोरी का उपयोग किया जाता है** नए चंक्स को आवंटित करने से पहले। यह **जानना जटिल है कि कौन सा ऑब्जेक्ट उस ऑब्जेक्ट के साथ टकराने वाला है** जो heap overflow के लिए संवेदनशील है। इसलिए, जब एक heap overflow पाया जाता है, तो यह आवश्यक है कि **वांछित ऑब्जेक्ट को मेमोरी में अगले स्थान पर लाने का एक विश्वसनीय तरीका खोजा जाए** जो ओवरफ्लो किया जा सकता है।
|
||||
|
||||
इसका एक तकनीक **Heap Grooming** है जिसका उपयोग उदाहरण के लिए [**इस पोस्ट में**](https://azeria-labs.com/grooming-the-ios-kernel-heap/) किया गया है। पोस्ट में यह समझाया गया है कि जब iOS कर्नेल में एक ज़ोन में मेमोरी खत्म हो जाती है, तो यह इसे एक कर्नेल पृष्ठ द्वारा बढ़ाता है, और यह पृष्ठ अपेक्षित आकार के चंक्स में विभाजित होता है जो क्रम में उपयोग किए जाएंगे (iOS संस्करण 9.2 तक, फिर ये चंक्स इन हमलों के शोषण को कठिन बनाने के लिए यादृच्छिक तरीके से उपयोग किए जाते हैं)।
|
||||
|
||||
इसलिए, पिछले पोस्ट में जहां heap overflow हो रहा है, ओवरफ्लो किए गए ऑब्जेक्ट को एक पीड़ित क्रम के साथ टकराने के लिए मजबूर करने के लिए, कई **`kallocs` को कई थ्रेड्स द्वारा मजबूर किया जाता है ताकि यह सुनिश्चित किया जा सके कि सभी मुक्त चंक्स भरे हुए हैं और एक नया पृष्ठ बनाया गया है**।
|
||||
इसलिए, पिछले पोस्ट में जहां heap overflow हो रहा है, ओवरफ्लो किए गए ऑब्जेक्ट को एक पीड़ित ऑर्डर के साथ टकराने के लिए मजबूर करने के लिए, कई **`kallocs` को कई थ्रेड्स द्वारा मजबूर किया जाता है ताकि यह सुनिश्चित किया जा सके कि सभी मुक्त चंक्स भरे हुए हैं और एक नया पृष्ठ बनाया गया है**।
|
||||
|
||||
विशिष्ट आकार के ऑब्जेक्ट के साथ इस भरने को मजबूर करने के लिए, **iOS mach port से संबंधित आउट-ऑफ-लाइन आवंटन** एक आदर्श उम्मीदवार है। संदेश के आकार को तैयार करके, `kalloc` आवंटन के आकार को सटीक रूप से निर्दिष्ट करना संभव है और जब संबंधित mach port नष्ट हो जाता है, तो संबंधित आवंटन तुरंत `kfree` पर वापस जारी किया जाएगा।
|
||||
विशिष्ट आकार के ऑब्जेक्ट के साथ इस भराई को मजबूर करने के लिए, **iOS mach port से संबंधित आउट-ऑफ-लाइन आवंटन** एक आदर्श उम्मीदवार है। संदेश के आकार को तैयार करके, `kalloc` आवंटन के आकार को सटीक रूप से निर्दिष्ट करना संभव है और जब संबंधित mach port नष्ट होता है, तो संबंधित आवंटन तुरंत `kfree` पर वापस जारी किया जाएगा।
|
||||
|
||||
फिर, इनमें से कुछ प्लेसहोल्डर्स को **मुक्त** किया जा सकता है। **`kalloc.4096` मुक्त सूची तत्वों को अंतिम-में-प्रथम क्रम में जारी करती है**, जिसका मूल रूप से मतलब है कि यदि कुछ प्लेसहोल्डर्स मुक्त किए जाते हैं और शोषण कई पीड़ित ऑब्जेक्ट्स को आवंटित करने की कोशिश करता है जबकि ओवरफ्लो के लिए संवेदनशील ऑब्जेक्ट को आवंटित करने की कोशिश करता है, तो यह संभावना है कि यह ऑब्जेक्ट एक पीड़ित ऑब्जेक्ट द्वारा अनुसरण किया जाएगा।
|
||||
फिर, इनमें से कुछ प्लेसहोल्डर्स को **मुक्त** किया जा सकता है। **`kalloc.4096` मुक्त सूची तत्वों को अंतिम-में-प्रथम-से-आदेश में जारी करती है**, जिसका मूल रूप से मतलब है कि यदि कुछ प्लेसहोल्डर्स मुक्त किए जाते हैं और शोषण कई पीड़ित ऑब्जेक्ट्स को आवंटित करने की कोशिश करता है जबकि ओवरफ्लो के लिए संवेदनशील ऑब्जेक्ट को आवंटित करने की कोशिश करता है, तो यह संभावना है कि यह ऑब्जेक्ट एक पीड़ित ऑब्जेक्ट द्वारा अनुसरण किया जाएगा।
|
||||
|
||||
### Example libc
|
||||
|
||||
[**इस पृष्ठ में**](https://guyinatuxedo.github.io/27-edit_free_chunk/heap_consolidation_explanation/index.html) एक बुनियादी Heap overflow अनुकरण पाया जा सकता है जो दिखाता है कि अगले चंक के prev in use बिट और prev size की स्थिति को ओवरराइट करके **एक उपयोग किए गए चंक को समेकित करना** (इसे अप्रयुक्त समझाना) और **फिर से आवंटित करना** संभव है, जिससे यह डेटा ओवरराइट किया जा सके जो एक अलग पॉइंटर में भी उपयोग किया जा रहा है।
|
||||
[**इस पृष्ठ में**](https://guyinatuxedo.github.io/27-edit_free_chunk/heap_consolidation_explanation/index.html) एक बुनियादी Heap overflow अनुकरण पाया जा सकता है जो दिखाता है कि अगले चंक के prev in use बिट और prev size की स्थिति को ओवरराइट करके **एक उपयोग किए गए चंक को समेकित करना** (इसे अप्रयुक्त समझाना) और **फिर से इसे आवंटित करना** संभव है जिससे डेटा को ओवरराइट किया जा सके जो एक अलग पॉइंटर में भी उपयोग किया जा रहा है।
|
||||
|
||||
[**protostar heap 0**](https://guyinatuxedo.github.io/24-heap_overflow/protostar_heap0/index.html) से एक और उदाहरण एक बहुत बुनियादी CTF का उदाहरण दिखाता है जहां **heap overflow** का दुरुपयोग करके विजेता फ़ंक्शन को **फ्लैग प्राप्त करने के लिए** कॉल किया जा सकता है।
|
||||
[**protostar heap 0**](https://guyinatuxedo.github.io/24-heap_overflow/protostar_heap0/index.html) से एक और उदाहरण एक बहुत बुनियादी CTF का उदाहरण दिखाता है जहां **heap overflow** का दुरुपयोग करके विजेता फ़ंक्शन को कॉल किया जा सकता है **फ्लैग प्राप्त करने के लिए**।
|
||||
|
||||
[**protostar heap 1**](https://guyinatuxedo.github.io/24-heap_overflow/protostar_heap1/index.html) उदाहरण में यह देखा जा सकता है कि एक बफर ओवरफ्लो का दुरुपयोग करके **एक निकट चंक में एक पता ओवरराइट करना** संभव है जहां **उपयोगकर्ता से मनमाना डेटा** लिखा जाएगा।
|
||||
[**protostar heap 1**](https://guyinatuxedo.github.io/24-heap_overflow/protostar_heap1/index.html) उदाहरण में यह देखा जा सकता है कि एक बफर ओवरफ्लो का दुरुपयोग करके यह संभव है कि **एक निकट चंक में एक पता ओवरराइट किया जाए** जहां **उपयोगकर्ता से मनमाना डेटा** लिखा जाएगा।
|
||||
|
||||
### Example ARM64
|
||||
|
||||
पृष्ठ [https://8ksec.io/arm64-reversing-and-exploitation-part-1-arm-instruction-set-simple-heap-overflow/](https://8ksec.io/arm64-reversing-and-exploitation-part-1-arm-instruction-set-simple-heap-overflow/) में आप एक heap overflow उदाहरण पा सकते हैं जहां एक कमांड जो निष्पादित होने वाली है, ओवरफ्लो किए गए चंक से अगले चंक में स्टोर की गई है। इसलिए, इसे एक आसान शोषण जैसे ओवरराइट करके निष्पादित कमांड को संशोधित करना संभव है:
|
||||
पृष्ठ [https://8ksec.io/arm64-reversing-and-exploitation-part-1-arm-instruction-set-simple-heap-overflow/](https://8ksec.io/arm64-reversing-and-exploitation-part-1-arm-instruction-set-simple-heap-overflow/) में आप एक heap overflow उदाहरण पा सकते हैं जहां एक कमांड जो निष्पादित होने वाली है, ओवरफ्लो किए गए चंक से अगले चंक में स्टोर की गई है। इसलिए, इसे एक आसान शोषण जैसे कि ओवरराइट करके निष्पादित कमांड को संशोधित करना संभव है:
|
||||
```bash
|
||||
python3 -c 'print("/"*0x400+"/bin/ls\x00")' > hax.txt
|
||||
```
|
||||
### Other examples
|
||||
### अन्य उदाहरण
|
||||
|
||||
- [**Auth-or-out. Hack The Box**](https://7rocky.github.io/en/ctf/htb-challenges/pwn/auth-or-out/)
|
||||
- हम Heap Overflow प्राप्त करने के लिए एक Integer Overflow भेद्यता का उपयोग करते हैं।
|
||||
- हम एक `struct` के अंदर एक फ़ंक्शन के लिए पॉइंटर्स को भ्रष्ट करते हैं जो ओवरफ्लो किए गए चंक में है ताकि `system` जैसे फ़ंक्शन को सेट किया जा सके और कोड निष्पादन प्राप्त किया जा सके।
|
||||
|
||||
### वास्तविक-विश्व उदाहरण: CVE-2025-40597 – `__sprintf_chk` का दुरुपयोग
|
||||
|
||||
SonicWall SMA100 फर्मवेयर 10.2.1.15 में रिवर्स-प्रॉक्सी मॉड्यूल `mod_httprp.so` एक **0x80-बाइट** हीप चंक आवंटित करता है और फिर इसमें कई स्ट्रिंग्स को `__sprintf_chk` के साथ जोड़ता है:
|
||||
```c
|
||||
char *buf = calloc(0x80, 1);
|
||||
/* … */
|
||||
__sprintf_chk(buf, /* destination (0x80-byte chunk) */
|
||||
-1, /* <-- size argument !!! */
|
||||
0, /* flags */
|
||||
"%s%s%s%s", /* format */
|
||||
"/", "https://", path, host);
|
||||
```
|
||||
`__sprintf_chk` **_FORTIFY_SOURCE_** का हिस्सा है। जब यह **सकारात्मक** `size` पैरामीटर प्राप्त करता है, तो यह सुनिश्चित करता है कि परिणामी स्ट्रिंग गंतव्य बफर के अंदर फिट हो। **`-1` (0xFFFFFFFFFFFFFFFF)** पास करके, डेवलपर्स ने प्रभावी रूप से **बाउंड्स चेक को अक्षम** कर दिया, सुरक्षित `sprintf` को फिर से एक क्लासिक, असुरक्षित कॉल में बदल दिया।
|
||||
|
||||
इसलिए एक अत्यधिक लंबा **`Host:`** हेडर प्रदान करने से एक हमलावर **0x80-बाइट चंक को ओवरफ्लो कर सकता है और अगले हीप चंक के मेटाडेटा को क्लॉबर कर सकता है** (tcache / fast-bin / small-bin आवंटक के आधार पर)। एक क्रैश को निम्नलिखित के साथ पुन: उत्पन्न किया जा सकता है:
|
||||
```python
|
||||
import requests, warnings
|
||||
warnings.filterwarnings('ignore')
|
||||
requests.get(
|
||||
'https://TARGET/__api__/',
|
||||
headers={'Host': 'A'*750},
|
||||
verify=False
|
||||
)
|
||||
```
|
||||
व्यावहारिक शोषण के लिए **heap grooming** की आवश्यकता होगी ताकि एक नियंत्रित वस्तु कमजोर हिस्से के ठीक बाद रखी जा सके, लेकिन मूल कारण दो महत्वपूर्ण बातें उजागर करता है:
|
||||
|
||||
1. **_FORTIFY_SOURCE कोई जादुई समाधान नहीं है** – दुरुपयोग सुरक्षा को नष्ट कर सकता है।
|
||||
2. हमेशा `_chk` परिवार को **सही बफर आकार** पास करें (या, और भी बेहतर, `snprintf` का उपयोग करें)।
|
||||
|
||||
## References
|
||||
* [watchTowr Labs – Stack Overflows, Heap Overflows and Existential Dread (SonicWall SMA100)](https://labs.watchtowr.com/stack-overflows-heap-overflows-and-existential-dread-sonicwall-sma100-cve-2025-40596-cve-2025-40597-and-cve-2025-40598/)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,15 +4,15 @@
|
||||
|
||||
## What is a Stack Overflow
|
||||
|
||||
एक **स्टैक ओवरफ्लो** एक सुरक्षा कमी है जो तब होती है जब एक प्रोग्राम स्टैक में उस डेटा से अधिक डेटा लिखता है जितना कि उसे रखने के लिए आवंटित किया गया है। यह अतिरिक्त डेटा **सन्निहित मेमोरी स्थान को ओवरराइट** कर देगा, जिससे वैध डेटा का भ्रष्टाचार, नियंत्रण प्रवाह में विघटन, और संभावित रूप से दुर्भावनापूर्ण कोड का निष्पादन हो सकता है। यह समस्या अक्सर असुरक्षित कार्यों के उपयोग के कारण उत्पन्न होती है जो इनपुट पर सीमा जांच नहीं करती हैं।
|
||||
A **stack overflow** एक सुरक्षा कमी है जो तब होती है जब एक प्रोग्राम स्टैक में उस डेटा से अधिक डेटा लिखता है जितना कि उसे रखने के लिए आवंटित किया गया है। यह अतिरिक्त डेटा **सन्निकट मेमोरी स्थान को ओवरराइट** करेगा, जिससे वैध डेटा का भ्रष्टाचार, नियंत्रण प्रवाह में विघटन, और संभावित रूप से दुर्भावनापूर्ण कोड का निष्पादन हो सकता है। यह समस्या अक्सर असुरक्षित कार्यों के उपयोग के कारण उत्पन्न होती है जो इनपुट पर सीमा जांच नहीं करते हैं।
|
||||
|
||||
इस ओवरराइट की मुख्य समस्या यह है कि **सहेजा गया निर्देश सूचक (EIP/RIP)** और **सहेजा गया बेस पॉइंटर (EBP/RBP)** जो पिछले फ़ंक्शन पर लौटने के लिए हैं, **स्टैक पर संग्रहीत** होते हैं। इसलिए, एक हमलावर उन्हें ओवरराइट करने में सक्षम होगा और **प्रोग्राम के निष्पादन प्रवाह को नियंत्रित** कर सकेगा।
|
||||
इस ओवरराइट का मुख्य समस्या यह है कि **सहेजा गया निर्देश सूचक (EIP/RIP)** और **सहेजा गया बेस सूचक (EBP/RBP)** जो पिछले कार्य में लौटने के लिए होते हैं, **स्टैक पर संग्रहीत** होते हैं। इसलिए, एक हमलावर उन्हें ओवरराइट करने में सक्षम होगा और **प्रोग्राम के निष्पादन प्रवाह को नियंत्रित** कर सकेगा।
|
||||
|
||||
यह सुरक्षा कमी आमतौर पर इसलिए उत्पन्न होती है क्योंकि एक फ़ंक्शन **स्टैक के अंदर उन बाइट्स की अधिक मात्रा की कॉपी करता है जो इसके लिए आवंटित हैं**, जिससे यह स्टैक के अन्य भागों को ओवरराइट करने में सक्षम होता है।
|
||||
यह सुरक्षा कमी आमतौर पर इसलिए उत्पन्न होती है क्योंकि एक कार्य **स्टैक के अंदर उन बाइट्स की अधिक संख्या की नकल करता है जितनी कि इसके लिए आवंटित की गई है**, इसलिए अन्य स्टैक के हिस्सों को ओवरराइट करने में सक्षम होता है।
|
||||
|
||||
इससे प्रभावित कुछ सामान्य फ़ंक्शन हैं: **`strcpy`, `strcat`, `sprintf`, `gets`**... इसके अलावा, फ़ंक्शन जैसे **`fgets`**, **`read` & `memcpy`** जो **लंबाई तर्क** लेते हैं, यदि निर्दिष्ट लंबाई आवंटित लंबाई से अधिक है तो उन्हें असुरक्षित तरीके से उपयोग किया जा सकता है।
|
||||
इससे प्रभावित कुछ सामान्य कार्य हैं: **`strcpy`, `strcat`, `sprintf`, `gets`**... इसके अलावा, ऐसे कार्य जैसे **`fgets`**, **`read` & `memcpy`** जो **लंबाई तर्क** लेते हैं, यदि निर्दिष्ट लंबाई आवंटित लंबाई से अधिक है तो उन्हें असुरक्षित तरीके से उपयोग किया जा सकता है।
|
||||
|
||||
उदाहरण के लिए, निम्नलिखित फ़ंक्शन असुरक्षित हो सकते हैं:
|
||||
उदाहरण के लिए, निम्नलिखित कार्य असुरक्षित हो सकते हैं:
|
||||
```c
|
||||
void vulnerable() {
|
||||
char buffer[128];
|
||||
@ -23,9 +23,9 @@ printf("You entered: %s\n", buffer);
|
||||
```
|
||||
### Stack Overflows ऑफसेट्स खोजना
|
||||
|
||||
Stack overflows खोजने का सबसे सामान्य तरीका बहुत बड़े `A`s (जैसे `python3 -c 'print("A"*1000)'`) का इनपुट देना है और एक `Segmentation Fault` की उम्मीद करना है जो यह संकेत करता है कि **पता `0x41414141` को एक्सेस करने की कोशिश की गई थी**।
|
||||
Stack overflows खोजने का सबसे सामान्य तरीका `A`s का बहुत बड़ा इनपुट देना है (जैसे `python3 -c 'print("A"*1000)'`) और एक `Segmentation Fault` की उम्मीद करना जो यह संकेत करता है कि **पता `0x41414141` को एक्सेस करने की कोशिश की गई थी**।
|
||||
|
||||
इसके अलावा, एक बार जब आप यह पता लगा लेते हैं कि Stack Overflow की कमजोरी है, तो आपको यह पता लगाने की आवश्यकता होगी कि **रिटर्न पता ओवरराइट करने के लिए कितना ऑफसेट आवश्यक है**, इसके लिए आमतौर पर एक **De Bruijn अनुक्रम** का उपयोग किया जाता है। जो एक दिए गए वर्णमाला के आकार _k_ और लंबाई _n_ के उप अनुक्रमों के लिए एक **चक्रीय अनुक्रम है जिसमें लंबाई _n_ का हर संभव उप अनुक्रम ठीक एक बार एक सन्निहित उप अनुक्रम के रूप में प्रकट होता है**।
|
||||
इसके अलावा, एक बार जब आप यह पता लगा लेते हैं कि Stack Overflow की कमजोरी है, तो आपको यह पता लगाने की आवश्यकता होगी कि **रिटर्न एड्रेस को ओवरराइट करने के लिए कितना ऑफसेट चाहिए**, इसके लिए आमतौर पर एक **De Bruijn अनुक्रम** का उपयोग किया जाता है। जो एक दिए गए वर्णमाला के आकार _k_ और लंबाई _n_ के उप अनुक्रमों के लिए एक **चक्रीय अनुक्रम है जिसमें लंबाई _n_ का हर संभव उप अनुक्रम ठीक एक बार एक सन्निहित उप अनुक्रम के रूप में प्रकट होता है**।
|
||||
|
||||
इस तरह, EIP को नियंत्रित करने के लिए आवश्यक ऑफसेट को हाथ से पता लगाने के बजाय, इन अनुक्रमों में से एक को पैडिंग के रूप में उपयोग करना संभव है और फिर उन बाइट्स का ऑफसेट ढूंढना संभव है जो इसे ओवरराइट करने के अंत में हैं।
|
||||
|
||||
@ -50,14 +50,14 @@ pattern search $rsp #Search the offset given the content of $rsp
|
||||
```
|
||||
## स्टैक ओवरफ्लोज़ का शोषण
|
||||
|
||||
एक ओवरफ्लो के दौरान (मान लेते हैं कि ओवरफ्लो का आकार पर्याप्त बड़ा है) आप स्टैक के अंदर स्थानीय चर के मानों को **ओवरराइट** करने में सक्षम होंगे जब तक कि आप सुरक्षित **EBP/RBP और EIP/RIP (या इससे भी अधिक)** तक नहीं पहुँच जाते।\
|
||||
इस प्रकार की भेद्यता का दुरुपयोग करने का सबसे सामान्य तरीका **रिटर्न पते को संशोधित करना** है ताकि जब फ़ंक्शन समाप्त हो, तो **नियंत्रण प्रवाह उस पते पर पुनर्निर्देशित हो जाए जो उपयोगकर्ता ने निर्दिष्ट किया है**।
|
||||
एक ओवरफ्लो के दौरान (मान लेते हैं कि ओवरफ्लो का आकार पर्याप्त बड़ा है) आप स्टैक के अंदर स्थानीय वेरिएबल्स के मानों को **ओवरराइट** करने में सक्षम होंगे जब तक कि आप सुरक्षित **EBP/RBP और EIP/RIP (या इससे भी अधिक)** तक नहीं पहुँच जाते।\
|
||||
इस प्रकार की भेद्यता का दुरुपयोग करने का सबसे सामान्य तरीका **रिटर्न एड्रेस को संशोधित करना** है ताकि जब फ़ंक्शन समाप्त हो, तो **नियंत्रण प्रवाह उस प्वाइंटर में उपयोगकर्ता द्वारा निर्दिष्ट स्थान पर पुनर्निर्देशित किया जाएगा**।
|
||||
|
||||
हालांकि, अन्य परिदृश्यों में केवल **स्टैक में कुछ चर के मानों को ओवरराइट करना** शोषण के लिए पर्याप्त हो सकता है (जैसे आसान CTF चुनौतियों में)।
|
||||
हालांकि, अन्य परिदृश्यों में केवल **स्टैक में कुछ वेरिएबल्स के मानों को ओवरराइट करना** शोषण के लिए पर्याप्त हो सकता है (जैसे आसान CTF चुनौतियों में)।
|
||||
|
||||
### Ret2win
|
||||
|
||||
इस प्रकार की CTF चुनौतियों में, बाइनरी के अंदर एक **फंक्शन** है जो **कभी नहीं बुलाया जाता** और जिसे **आपको जीतने के लिए बुलाना होगा**। इन चुनौतियों के लिए आपको केवल **रिटर्न पते को ओवरराइट करने के लिए ऑफसेट** ढूंढना है और **बुलाने के लिए फंक्शन का पता** लगाना है (आमतौर पर [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) अक्षम होगा) ताकि जब कमजोर फ़ंक्शन लौटे, तो छिपा हुआ फ़ंक्शन बुलाया जाए:
|
||||
इस प्रकार की CTF चुनौतियों में, बाइनरी के अंदर एक **फंक्शन** है जो **कभी नहीं बुलाया जाता** और जिसे **आपको जीतने के लिए बुलाना होगा**। इन चुनौतियों के लिए आपको केवल **रिटर्न एड्रेस को ओवरराइट करने के लिए ऑफसेट** ढूंढना है और **बुलाने के लिए फंक्शन का पता** लगाना है (आमतौर पर [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) अक्षम होगा) ताकि जब कमजोर फ़ंक्शन लौटे, तो छिपा हुआ फ़ंक्शन बुलाया जाएगा:
|
||||
|
||||
{{#ref}}
|
||||
ret2win/
|
||||
@ -71,7 +71,7 @@ ret2win/
|
||||
stack-shellcode/
|
||||
{{#endref}}
|
||||
|
||||
### ROP & Ret2... तकनीकें
|
||||
### ROP और Ret2... तकनीकें
|
||||
|
||||
यह तकनीक मुख्य सुरक्षा को बायपास करने के लिए मौलिक ढांचा है: **कोई निष्पादन योग्य स्टैक (NX)**। और यह कई अन्य तकनीकों (ret2lib, ret2syscall...) को निष्पादित करने की अनुमति देती है जो बाइनरी में मौजूदा निर्देशों का दुरुपयोग करके मनमाने आदेशों को निष्पादित करेंगी:
|
||||
|
||||
@ -95,4 +95,33 @@ stack-shellcode/
|
||||
../common-binary-protections-and-bypasses/
|
||||
{{#endref}}
|
||||
|
||||
### वास्तविक-विश्व उदाहरण: CVE-2025-40596 (SonicWall SMA100)
|
||||
|
||||
क्यों **`sscanf` को अविश्वसनीय इनपुट को पार्स करने के लिए कभी भी भरोसा नहीं किया जाना चाहिए** इसका एक अच्छा प्रदर्शन 2025 में SonicWall के SMA100 SSL-VPN उपकरण में सामने आया।\
|
||||
`/usr/src/EasyAccess/bin/httpd` के अंदर कमजोर रूटीन किसी भी URI से संस्करण और एंडपॉइंट निकालने का प्रयास करता है जो `/__api__/` से शुरू होता है:
|
||||
```c
|
||||
char version[3];
|
||||
char endpoint[0x800] = {0};
|
||||
/* simplified proto-type */
|
||||
sscanf(uri, "%*[^/]/%2s/%s", version, endpoint);
|
||||
```
|
||||
1. पहला रूपांतरण (`%2s`) सुरक्षित रूप से **दो** बाइट्स को `version` में स्टोर करता है (जैसे कि `"v1"`).
|
||||
2. दूसरा रूपांतरण (`%s`) **कोई लंबाई निर्दिष्ट नहीं करता**, इसलिए `sscanf` **पहले NUL बाइट** तक कॉपी करना जारी रखेगा.
|
||||
3. क्योंकि `endpoint` **स्टैक** पर स्थित है और इसकी लंबाई **0x800 बाइट्स** है, 0x800 बाइट्स से लंबा पथ प्रदान करने से बफर के बाद जो कुछ भी है, वह सब भ्रष्ट हो जाता है ‑ जिसमें **स्टैक कैनरी** और **सहेजा गया रिटर्न पता** शामिल है.
|
||||
|
||||
एकल-पंक्ति प्रमाण-ऑफ-कॉन्सेप्ट क्रैश को **प्रमाणन से पहले** ट्रिगर करने के लिए पर्याप्त है:
|
||||
```python
|
||||
import requests, warnings
|
||||
warnings.filterwarnings('ignore')
|
||||
url = "https://TARGET/__api__/v1/" + "A"*3000
|
||||
requests.get(url, verify=False)
|
||||
```
|
||||
हालाँकि स्टैक कैनरी प्रक्रिया को समाप्त कर देते हैं, एक हमलावर अभी भी एक **Denial-of-Service** प्राइमिटिव प्राप्त करता है (और, अतिरिक्त जानकारी लीक के साथ, संभवतः कोड-एक्ज़ीक्यूशन)। सबक सरल है:
|
||||
|
||||
* हमेशा एक **अधिकतम फ़ील्ड चौड़ाई** प्रदान करें (जैसे `%511s`)।
|
||||
* `snprintf`/`strncpy_s` जैसे सुरक्षित विकल्पों को प्राथमिकता दें।
|
||||
|
||||
## References
|
||||
* [watchTowr Labs – Stack Overflows, Heap Overflows and Existential Dread (SonicWall SMA100)](https://labs.watchtowr.com/stack-overflows-heap-overflows-and-existential-dread-sonicwall-sma100-cve-2025-40596-cve-2025-40597-and-cve-2025-40598/)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user