mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/mobile-pentesting/ios-pentesting/ios-pentesting-without
This commit is contained in:
Translator
parent
4d1f7933c3
commit
fa00eeea6e
@ -4,7 +4,7 @@
|
||||
|
||||
## मुख्य विचार
|
||||
|
||||
**entitlement `get_task_allow`** के साथ साइन की गई एप्लिकेशन तीसरे पक्ष की एप्लिकेशनों को **`task_for_pid()`** नामक एक फ़ंक्शन को प्रारंभिक एप्लिकेशन के प्रक्रिया ID के साथ तर्क के रूप में चलाने की अनुमति देती हैं ताकि उस पर कार्य पोर्ट प्राप्त किया जा सके (इसे नियंत्रित करने और इसकी मेमोरी तक पहुँचने में सक्षम होना)।
|
||||
**entitlement `get_task_allow`** के साथ साइन की गई एप्लिकेशन तीसरे पक्ष की एप्लिकेशनों को **`task_for_pid()`** नामक एक फ़ंक्शन को प्रारंभिक एप्लिकेशन के प्रक्रिया आईडी के साथ तर्क के रूप में चलाने की अनुमति देती हैं ताकि उस पर कार्य पोर्ट प्राप्त किया जा सके (इसे नियंत्रित करने और इसकी मेमोरी तक पहुँचने में सक्षम होना)।
|
||||
|
||||
हालांकि, यह केवल IPA को खींचने, इसे entitlement के साथ फिर से साइन करने और इसे अपने डिवाइस पर फ्लैश करने जितना आसान नहीं है। इसका कारण FairPlay सुरक्षा है। जब ऐप का हस्ताक्षर बदलता है, तो DRM (Digital Rights Management) कुंजी **अमान्य हो जाती है और ऐप काम नहीं करेगा**।
|
||||
|
||||
@ -31,7 +31,7 @@ IPA को डिक्रिप्ट करने के लिए हम इ
|
||||
```bash
|
||||
unzip redacted.ipa -d unzipped
|
||||
```
|
||||
`Info.plist` में न्यूनतम समर्थित संस्करण के लिए जांचें और यदि आपका डिवाइस उससे पुराना है, तो मान को बदलें ताकि यह समर्थित हो।
|
||||
`Info.plist` में न्यूनतम समर्थित संस्करण के लिए जांचें और यदि आपका डिवाइस उससे पुराना है, तो मान को बदलें ताकि यह समर्थित हो सके।
|
||||
|
||||
IPA को फिर से ज़िप करें:
|
||||
```bash
|
||||
@ -48,11 +48,11 @@ ideviceinstaller -i no-min-version.ipa -w
|
||||
|
||||
### पैच अधिकार और फिर से साइन करें
|
||||
|
||||
`get-task-allow` अधिकार के साथ एप्लिकेशन को फिर से साइन करने के लिए कई उपकरण उपलब्ध हैं जैसे `app-signer`, `codesign`, और `iResign`। `app-signer` का एक बहुत उपयोगकर्ता-अनुकूल इंटरफ़ेस है जो एक IPA फ़ाइल को फिर से साइन करने की अनुमति देता है, जिसमें फिर से साइन करने के लिए IPA को इंगित करना, **इसे `get-task-allow` में डालना** और उपयोग करने के लिए प्रमाणपत्र और प्रोविजनिंग प्रोफ़ाइल शामिल है।
|
||||
`get-task-allow` अधिकार के साथ एप्लिकेशन को फिर से साइन करने के लिए कई उपकरण उपलब्ध हैं जैसे `app-signer`, `codesign`, और `iResign`। `app-signer` का एक बहुत उपयोगकर्ता-अनुकूल इंटरफ़ेस है जो एक IPA फ़ाइल को फिर से साइन करने की अनुमति देता है, जिसमें फिर से साइन करने के लिए IPA को इंगित करना, **`get-taks-allow` डालना** और उपयोग करने के लिए प्रमाणपत्र और प्रोविजनिंग प्रोफ़ाइल शामिल है।
|
||||
|
||||
प्रमाणपत्र और साइनिंग प्रोफाइल के संबंध में, Apple सभी खातों के लिए Xcode के माध्यम से **मुफ्त डेवलपर साइनिंग प्रोफाइल** प्रदान करता है। बस एक ऐप बनाएं और एक कॉन्फ़िगर करें। फिर, `Settings` → `Privacy & Security` पर जाकर **iPhone को डेवलपर ऐप्स पर भरोसा करने के लिए कॉन्फ़िगर करें**, और `Developer Mode` पर क्लिक करें।
|
||||
|
||||
फिर से साइन की गई IPA के साथ, इसे डिवाइस में स्थापित करने का समय है ताकि इसे pentest किया जा सके:
|
||||
फिर से साइन की गई IPA के साथ, इसे डिवाइस में स्थापित करने का समय है ताकि इसे पेंटेस्ट किया जा सके:
|
||||
```bash
|
||||
ideviceinstaller -i resigned.ipa -w
|
||||
```
|
||||
@ -60,7 +60,7 @@ ideviceinstaller -i resigned.ipa -w
|
||||
|
||||
### डेवलपर मोड सक्षम करें (iOS 16+)
|
||||
|
||||
iOS 16 के साथ Apple ने **डेवलपर मोड** पेश किया: कोई भी बाइनरी जो `get_task_allow` ले जाती है *या* एक विकास प्रमाणपत्र के साथ हस्ताक्षरित है, वह तब तक लॉन्च करने से मना कर देगी जब तक कि डिवाइस पर डेवलपर मोड सक्षम न हो। आप Frida/LLDB को भी संलग्न नहीं कर पाएंगे जब तक कि यह ध्वज चालू न हो।
|
||||
iOS 16 से Apple ने **डेवलपर मोड** पेश किया: कोई भी बाइनरी जो `get_task_allow` ले जाती है *या* एक विकास प्रमाणपत्र के साथ हस्ताक्षरित है, वह तब तक लॉन्च करने से मना कर देगी जब तक कि डिवाइस पर डेवलपर मोड सक्षम नहीं किया गया है। आप Frida/LLDB को भी संलग्न नहीं कर पाएंगे जब तक कि यह ध्वज चालू न हो।
|
||||
|
||||
1. फोन पर **कोई भी** डेवलपर-हस्ताक्षरित IPA स्थापित या पुश करें।
|
||||
2. **सेटिंग्स → गोपनीयता और सुरक्षा → डेवलपर मोड** पर जाएं और इसे चालू करें।
|
||||
@ -93,7 +93,7 @@ frida -U -f com.example.target -l my_script.js --no-pause
|
||||
|
||||
### स्वचालित डायनामिक विश्लेषण MobSF के साथ (कोई जेलब्रेक नहीं)
|
||||
|
||||
[MobSF](https://mobsf.github.io/Mobile-Security-Framework-MobSF/) एक वास्तविक डिवाइस पर एक डेवलपर-साइन किया हुआ IPA को उसी तकनीक (`get_task_allow`) का उपयोग करके इंस्ट्रूमेंट कर सकता है और फाइल सिस्टम ब्राउज़र, ट्रैफ़िक कैप्चर और Frida कंसोल के साथ एक वेब UI प्रदान करता है【】। सबसे तेज़ तरीका यह है कि MobSF को Docker में चलाएं और फिर अपने iPhone को USB के माध्यम से कनेक्ट करें:
|
||||
[MobSF](https://mobsf.github.io/Mobile-Security-Framework-MobSF/) एक वास्तविक डिवाइस पर एक डेवलपर-साइन की गई IPA को उसी तकनीक (`get_task_allow`) का उपयोग करके इंस्ट्रूमेंट कर सकता है और एक वेब UI प्रदान करता है जिसमें फ़ाइल सिस्टम ब्राउज़र, ट्रैफ़िक कैप्चर और Frida कंसोल शामिल हैं【†L2-L3】। सबसे तेज़ तरीका यह है कि MobSF को Docker में चलाएं और फिर अपने iPhone को USB के माध्यम से कनेक्ट करें:
|
||||
```bash
|
||||
docker pull opensecurity/mobile-security-framework-mobsf:latest
|
||||
docker run -p 8000:8000 --privileged \
|
||||
|
||||
@ -1,7 +1,100 @@
|
||||
# HTTP/2 डाउनग्रेड में अनुरोध स्मगलिंग
|
||||
# Request Smuggling in HTTP/2 Downgrades
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
**पोस्ट की जांच करें [https://portswigger.net/research/http-2-downgrades](https://portswigger.net/research/http-2-downgrades)**
|
||||
HTTP/2 को आमतौर पर क्लासिक request-smuggling के लिए प्रतिरक्षित माना जाता है क्योंकि प्रत्येक DATA फ्रेम की लंबाई स्पष्ट होती है। **यह सुरक्षा तब गायब हो जाती है जब एक फ्रंट-एंड प्रॉक्सी अनुरोध को HTTP/1.x में “डाउनग्रेड” करती है इससे पहले कि इसे बैक-एंड पर अग्रेषित किया जाए**। जिस क्षण दो अलग-अलग पार्सर (HTTP/2 फ्रंट-एंड और HTTP/1 बैक-एंड) यह सहमत होने की कोशिश करते हैं कि एक अनुरोध कहाँ समाप्त होता है और अगला कहाँ शुरू होता है, सभी पुराने desync ट्रिक्स वापस आ जाते हैं - साथ ही कुछ नए भी।
|
||||
|
||||
---
|
||||
## डाउनग्रेड क्यों होते हैं
|
||||
|
||||
1. ब्राउज़र पहले से ही HTTP/2 बोलते हैं, लेकिन बहुत सारी विरासती मूल अवसंरचना अभी भी केवल HTTP/1.1 को समझती है।
|
||||
2. रिवर्स-प्रॉक्सीज़ (CDNs, WAFs, लोड-बैलेंसर) इसलिए TLS + HTTP/2 को एज पर समाप्त करते हैं और **हर अनुरोध को HTTP/1.1 के लिए फिर से लिखते हैं**।
|
||||
3. अनुवाद चरण को *दोनों* `Content-Length` **और/या** `Transfer-Encoding: chunked` हेडर बनाने होंगे ताकि मूल शरीर की लंबाई निर्धारित कर सके।
|
||||
|
||||
जब भी फ्रंट-एंड HTTP/2 फ्रेम की लंबाई पर भरोसा करता है **लेकिन** बैक-एंड CL या TE पर भरोसा करता है, एक हमलावर उन्हें असहमत करने के लिए मजबूर कर सकता है।
|
||||
|
||||
---
|
||||
## दो प्रमुख प्राइमिटिव वर्ग
|
||||
|
||||
| Variant | Front-end length | Back-end length | Typical payload |
|
||||
|---------|-----------------|-----------------|-----------------|
|
||||
| **H2.TE** | HTTP/2 फ्रेम | `Transfer-Encoding: chunked` | एक अतिरिक्त chunked संदेश शरीर को एम्बेड करें जिसका अंतिम `0\r\n\r\n` *नहीं* भेजा जाता है, ताकि बैक-एंड हमलावर द्वारा प्रदान किए गए “अगले” अनुरोध की प्रतीक्षा करे। |
|
||||
| **H2.CL** | HTTP/2 फ्रेम | `Content-Length` | एक *छोटी* CL भेजें जो असली शरीर से कम हो, ताकि बैक-एंड सीमा के पार अगली अनुरोध में पढ़ सके। |
|
||||
|
||||
> ये क्लासिक TE.CL / CL.TE के समान हैं, बस HTTP/2 एक पार्सर को बदल रहा है।
|
||||
|
||||
---
|
||||
## डाउनग्रेड श्रृंखला की पहचान करना
|
||||
|
||||
1. एक TLS हैंडशेक में **ALPN** का उपयोग करें (`openssl s_client -alpn h2 -connect host:443`) या **curl**:
|
||||
```bash
|
||||
curl -v --http2 https://target
|
||||
```
|
||||
यदि `* Using HTTP2` प्रकट होता है, तो एज H2 बोलता है।
|
||||
2. HTTP/2 (Burp Repeater अब HTTP/2 को मजबूर करने के लिए एक ड्रॉपडाउन है) पर जानबूझकर गलत CL/TE अनुरोध भेजें। यदि प्रतिक्रिया एक HTTP/1.1 त्रुटि है जैसे `400 Bad chunk`, तो आपके पास प्रमाण है कि एज ने HTTP/1 पार्सर के लिए ट्रैफ़िक को परिवर्तित किया।
|
||||
|
||||
---
|
||||
## शोषण कार्यप्रवाह (H2.TE उदाहरण)
|
||||
```http
|
||||
:method: POST
|
||||
:path: /login
|
||||
:scheme: https
|
||||
:authority: example.com
|
||||
content-length: 13 # ignored by the edge
|
||||
transfer-encoding: chunked
|
||||
|
||||
5;ext=1\r\nHELLO\r\n
|
||||
0\r\n\r\nGET /admin HTTP/1.1\r\nHost: internal\r\nX: X
|
||||
```
|
||||
1. **फ्रंट-एंड** ठीक 13 बाइट्स (`HELLO\r\n0\r\n\r\nGE`) पढ़ता है, सोचता है कि अनुरोध समाप्त हो गया है और उतना ही मूल पर अग्रेषित करता है।
|
||||
2. **बैक-एंड** TE हेडर पर भरोसा करता है, तब तक पढ़ता है जब तक कि यह *दूसरा* `0\r\n\r\n` नहीं देखता, इस प्रकार हमलावर के दूसरे अनुरोध (`GET /admin …`) का प्रीफिक्स खा जाता है।
|
||||
3. शेष (`GET /admin …`) को पीड़ित के पीछे कतार में एक *नए* अनुरोध के रूप में माना जाता है।
|
||||
|
||||
स्मगल किए गए अनुरोध को बदलें:
|
||||
* `POST /api/logout` सत्र स्थिरीकरण को मजबूर करने के लिए
|
||||
* `GET /users/1234` एक पीड़ित-विशिष्ट संसाधन चुराने के लिए
|
||||
|
||||
---
|
||||
## h2c स्मगलिंग (स्पष्ट-टेक्स्ट अपग्रेड)
|
||||
|
||||
2023 के एक अध्ययन ने दिखाया कि यदि एक फ्रंट-एंड HTTP/1.1 `Upgrade: h2c` हेडर को एक बैक-एंड पर पास करता है जो स्पष्ट-टेक्स्ट HTTP/2 का समर्थन करता है, तो एक हमलावर *कच्चे* HTTP/2 फ्रेम को एक एज के माध्यम से सुरंग कर सकता है जो केवल मान्य HTTP/1.1 को मानता है। यह हेडर सामान्यीकरण, WAF नियमों और यहां तक कि TLS समाप्ति को बायपास करता है।
|
||||
|
||||
मुख्य आवश्यकताएँ:
|
||||
* एज **दोनों** `Connection: Upgrade` और `Upgrade: h2c` को बिना बदले अग्रेषित करता है।
|
||||
* मूल HTTP/2 में बढ़ता है और कनेक्शन-रीयूज़ अर्थशास्त्र को बनाए रखता है जो अनुरोध कतारबद्ध करने की अनुमति देता है।
|
||||
|
||||
निवारण सरल है - एज पर `Upgrade` हेडर को हटा दें या हार्ड-कोड करें सिवाय WebSockets के।
|
||||
|
||||
---
|
||||
## उल्लेखनीय वास्तविक-विश्व CVEs (2022-2025)
|
||||
|
||||
* **CVE-2023-25690** – Apache HTTP Server mod_proxy पुनर्लेखन नियमों को अनुरोध विभाजन और स्मगलिंग के लिए श्रृंखला में जोड़ा जा सकता है। (2.4.56 में ठीक किया गया)
|
||||
* **CVE-2023-25950** – HAProxy 2.7/2.6 अनुरोध/प्रतिक्रिया स्मगलिंग जब HTX पार्सर ने पाइपलाइन किए गए अनुरोधों को गलत तरीके से संभाला।
|
||||
* **CVE-2022-41721** – Go `MaxBytesHandler` ने बचे हुए बॉडी बाइट्स को **HTTP/2** फ्रेम के रूप में पार्स किया, जो क्रॉस-प्रोटोकॉल स्मगलिंग को सक्षम बनाता है।
|
||||
|
||||
---
|
||||
## उपकरण
|
||||
|
||||
* **Burp Request Smuggler** – v1.26 से यह स्वचालित रूप से H2.TE/H2.CL और छिपे हुए ALPN समर्थन का परीक्षण करता है। एक्सटेंशन विकल्पों में "HTTP/2 probing" सक्षम करें।
|
||||
* **h2cSmuggler** – स्पष्ट-टेक्स्ट अपग्रेड हमले को स्वचालित करने के लिए Bishop Fox द्वारा Python PoC:
|
||||
```bash
|
||||
python3 h2csmuggler.py -u https://target -x 'GET /admin HTTP/1.1\r\nHost: target\r\n\r\n'
|
||||
```
|
||||
* **curl**/`hyper` – मैन्युअल पेलोड बनाने के लिए: `curl --http2-prior-knowledge -X POST --data-binary @payload.raw https://target`।
|
||||
|
||||
---
|
||||
## रक्षात्मक उपाय
|
||||
|
||||
1. **एंड-टू-एंड HTTP/2** – डाउनग्रेड अनुवाद को पूरी तरह से समाप्त करें।
|
||||
2. **लंबाई सत्य का एकल स्रोत** – डाउनग्रेड करते समय, *हमेशा* एक मान्य `Content-Length` **और** **हटाएं** किसी भी उपयोगकर्ता-प्रदत्त `Content-Length`/`Transfer-Encoding` हेडर।
|
||||
3. **रूट से पहले सामान्यीकरण** – रूटिंग/पुनर्लेखन तर्क से *पहले* हेडर-सैनिटाइजेशन लागू करें।
|
||||
4. **कनेक्शन अलगाव** – उपयोगकर्ताओं के बीच बैक-एंड TCP कनेक्शन का पुन: उपयोग न करें; "एक कनेक्शन प्रति अनुरोध" कतार-आधारित शोषण को पराजित करता है।
|
||||
5. **WebSocket को छोड़कर `Upgrade` हटा दें** – h2c सुरंगिंग को रोकता है।
|
||||
|
||||
---
|
||||
## संदर्भ
|
||||
|
||||
* PortSwigger Research – “HTTP/2: The Sequel is Always Worse” <https://portswigger.net/research/http2>
|
||||
* Bishop Fox – “h2c Smuggling: request smuggling via HTTP/2 clear-text” <https://bishopfox.com/blog/h2c-smuggling-request>
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user