hacktricks/pentesting-web/h2c-smuggling.md

Upgrade Header Smuggling

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}

Try Hard Security Group

{% embed url="https://discord.gg/tryhardsecurity" %}

---

H2C Smuggling

HTTP2 Over Cleartext (H2C)

H2C, या http2 ओवर क्लियरटेक्स्ट, अस्थायी HTTP कनेक्शनों के मानक से भटकता है, एक मानक HTTP कनेक्शन को स्थायी में अपग्रेड करके। यह अपग्रेड किया गया कनेक्शन ongoing संचार के लिए http2 बाइनरी प्रोटोकॉल का उपयोग करता है, जो कि plaintext HTTP की एकल-रिक्वेस्ट प्रकृति के विपरीत है।

स्मगलिंग समस्या का मुख्य कारण रिवर्स प्रॉक्सी का उपयोग है। सामान्यतः, रिवर्स प्रॉक्सी HTTP अनुरोधों को प्रोसेस और फॉरवर्ड करता है, उसके बाद बैकएंड का उत्तर लौटाता है। हालाँकि, जब HTTP अनुरोध में Connection: Upgrade हेडर मौजूद होता है (जो सामान्यतः वेबस्केट कनेक्शनों के साथ देखा जाता है), तो रिवर्स प्रॉक्सी क्लाइंट और सर्वर के बीच एक स्थायी कनेक्शन बनाए रखता है, जो कुछ प्रोटोकॉल द्वारा आवश्यक निरंतर विनिमय को सुविधाजनक बनाता है। H2C कनेक्शनों के लिए, RFC का पालन करने के लिए तीन विशिष्ट हेडरों की उपस्थिति आवश्यक है:

Upgrade: h2c
HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
Connection: Upgrade, HTTP2-Settings

The vulnerability arises when, after upgrading a connection, the reverse proxy ceases to manage individual requests, assuming its job of routing is complete post-connection establishment. H2C Smuggling का लाभ उठाने से अनुरोध प्रसंस्करण के दौरान लागू किए गए रिवर्स प्रॉक्सी नियमों को दरकिनार किया जा सकता है, जैसे कि पथ-आधारित रूटिंग, प्रमाणीकरण, और WAF प्रसंस्करण, यह मानते हुए कि H2C कनेक्शन सफलतापूर्वक आरंभ किया गया है।

Vulnerable Proxies

यह भेद्यता रिवर्स प्रॉक्सी के Upgrade और कभी-कभी Connection हेडर के प्रबंधन पर निर्भर करती है। निम्नलिखित प्रॉक्सियों में स्वाभाविक रूप से इन हेडरों को प्रॉक्सी-पास के दौरान अग्रेषित किया जाता है, जिससे H2C स्मगलिंग सक्षम होती है:

• HAProxy
• Traefik
• Nuster

इसके विपरीत, ये सेवाएँ स्वाभाविक रूप से प्रॉक्सी-पास के दौरान दोनों हेडरों को अग्रेषित नहीं करती हैं। हालाँकि, इन्हें असुरक्षित रूप से कॉन्फ़िगर किया जा सकता है, जिससे Upgrade और Connection हेडरों का बिना फ़िल्टर किया गया अग्रेषण संभव हो जाता है:

• AWS ALB/CLB
• NGINX
• Apache
• Squid
• Varnish
• Kong
• Envoy
• Apache Traffic Server

Exploitation

यह ध्यान रखना महत्वपूर्ण है कि सभी सर्वर स्वाभाविक रूप से एक अनुपालन H2C कनेक्शन अपग्रेड के लिए आवश्यक हेडरों को अग्रेषित नहीं करते हैं। इस प्रकार, AWS ALB/CLB, NGINX, और Apache Traffic Server जैसे सर्वर स्वाभाविक रूप से H2C कनेक्शनों को अवरुद्ध करते हैं। फिर भी, अनुपालन न करने वाले Connection: Upgrade वैरिएंट के साथ परीक्षण करना सार्थक है, जो Connection हेडर से HTTP2-Settings मान को बाहर करता है, क्योंकि कुछ बैकएंड मानकों के अनुसार नहीं हो सकते हैं।

{% hint style="danger" %} proxy_pass URL में निर्दिष्ट विशेष पथ (जैसे, http://backend:9999/socket.io) की परवाह किए बिना, स्थापित कनेक्शन डिफ़ॉल्ट रूप से http://backend:9999 होता है। यह इस तकनीक का लाभ उठाते हुए उस आंतरिक एंडपॉइंट के भीतर किसी भी पथ के साथ बातचीत की अनुमति देता है। इसलिए, proxy_pass URL में पथ का निर्दिष्ट करना पहुँच को प्रतिबंधित नहीं करता है। {% endhint %}

उपकरण h2csmuggler by BishopFox और h2csmuggler by assetnote H2C कनेक्शन स्थापित करके प्रॉक्सी-लगाए गए सुरक्षा उपायों को दरकिनार करने के प्रयासों को सुविधाजनक बनाते हैं, जिससे प्रॉक्सी द्वारा संरक्षित संसाधनों तक पहुँच संभव होती है।

इस भेद्यता के बारे में अतिरिक्त जानकारी के लिए, विशेष रूप से NGINX के संबंध में, इस विस्तृत संसाधन को देखें।

Websocket Smuggling

Websocket स्मगलिंग, प्रॉक्सी के माध्यम से पहुँच योग्य एक एंडपॉइंट के लिए HTTP2 टनल बनाने के विपरीत, संभावित प्रॉक्सी सीमाओं को दरकिनार करने और एंडपॉइंट के साथ सीधे संचार को सुविधाजनक बनाने के लिए एक Websocket टनल स्थापित करता है।

Scenario 1

इस परिदृश्य में, एक बैकएंड जो एक सार्वजनिक WebSocket API के साथ एक अनुपलब्ध आंतरिक REST API प्रदान करता है, एक दुर्भावनापूर्ण क्लाइंट द्वारा लक्षित किया जाता है जो आंतरिक REST API तक पहुँच प्राप्त करने की कोशिश कर रहा है। हमला कई चरणों में विकसित होता है:

1. क्लाइंट एक गलत Sec-WebSocket-Version प्रोटोकॉल संस्करण के साथ रिवर्स प्रॉक्सी को एक अपग्रेड अनुरोध भेजकर शुरू करता है। प्रॉक्सी, Sec-WebSocket-Version हेडर को मान्य करने में विफल रहते हुए, अपग्रेड अनुरोध को मान्य मानती है और इसे बैकएंड को अग्रेषित करती है।
2. बैकएंड 426 स्थिति कोड के साथ प्रतिक्रिया करता है, जो Sec-WebSocket-Version हेडर में गलत प्रोटोकॉल संस्करण को इंगित करता है। रिवर्स प्रॉक्सी, बैकएंड की प्रतिक्रिया स्थिति को नजरअंदाज करते हुए, WebSocket संचार के लिए तत्परता मानती है और प्रतिक्रिया को क्लाइंट को भेजती है।
3. परिणामस्वरूप, रिवर्स प्रॉक्सी को यह विश्वास दिलाया जाता है कि क्लाइंट और बैकएंड के बीच एक WebSocket कनेक्शन स्थापित हो गया है, जबकि वास्तव में, बैकएंड ने अपग्रेड अनुरोध को अस्वीकार कर दिया था। फिर भी, प्रॉक्सी क्लाइंट और बैकएंड के बीच एक खुला TCP या TLS कनेक्शन बनाए रखती है, जिससे क्लाइंट को इस कनेक्शन के माध्यम से निजी REST API तक बिना किसी प्रतिबंध के पहुँच मिलती है।

प्रभावित रिवर्स प्रॉक्सी में Varnish शामिल है, जिसने इस मुद्दे को संबोधित करने से इनकार कर दिया, और Envoy प्रॉक्सी संस्करण 1.8.0 या उससे पुराने, जिनके बाद के संस्करणों ने अपग्रेड तंत्र को बदल दिया है। अन्य प्रॉक्सी भी संवेदनशील हो सकते हैं।

Scenario 2

यह परिदृश्य एक बैकएंड को शामिल करता है जिसमें एक सार्वजनिक WebSocket API और स्वास्थ्य जांच के लिए एक सार्वजनिक REST API है, साथ ही एक अनुपलब्ध आंतरिक REST API है। हमला, जो अधिक जटिल है, निम्नलिखित चरणों में शामिल है:

1. क्लाइंट स्वास्थ्य जांच API को सक्रिय करने के लिए एक POST अनुरोध भेजता है, जिसमें एक अतिरिक्त HTTP हेडर Upgrade: websocket शामिल होता है। NGINX, जो रिवर्स प्रॉक्सी के रूप में कार्य करता है, इसे केवल Upgrade हेडर के आधार पर एक मानक अपग्रेड अनुरोध के रूप में व्याख्या करता है, अनुरोध के अन्य पहलुओं की अनदेखी करता है, और इसे बैकएंड को अग्रेषित करता है।
2. बैकएंड स्वास्थ्य जांच API को निष्पादित करता है, एक बाहरी संसाधन से संपर्क करता है जिसे हमलावर द्वारा नियंत्रित किया जाता है जो 101 स्थिति कोड के साथ एक HTTP प्रतिक्रिया लौटाता है। यह प्रतिक्रिया, जब बैकएंड द्वारा प्राप्त होती है और NGINX को अग्रेषित की जाती है, प्रॉक्सी को यह सोचने के लिए धोखा देती है कि एक WebSocket कनेक्शन स्थापित हो गया है क्योंकि यह केवल स्थिति कोड की मान्यता करता है।

Warning: इस तकनीक की जटिलता बढ़ जाती है क्योंकि इसे एक ऐसे एंडपॉइंट के साथ बातचीत करने की क्षमता की आवश्यकता होती है जो स्थिति कोड 101 लौटाने में सक्षम हो।

अंततः, NGINX को यह विश्वास दिलाया जाता है कि क्लाइंट और बैकएंड के बीच एक WebSocket कनेक्शन मौजूद है। वास्तव में, ऐसा कोई कनेक्शन नहीं है; स्वास्थ्य जांच REST API लक्ष्य था। फिर भी, रिवर्स प्रॉक्सी कनेक्शन को खुला रखती है, जिससे क्लाइंट को इसके माध्यम से निजी REST API तक पहुँच प्राप्त होती है।

अधिकांश रिवर्स प्रॉक्सी इस परिदृश्य के प्रति संवेदनशील हैं, लेकिन शोषण एक बाहरी SSRF भेद्यता की उपस्थिति पर निर्भर करता है, जिसे आमतौर पर एक निम्न-गंभीरता समस्या माना जाता है।

Labs

दोनों परिदृश्यों का परीक्षण करने के लिए प्रयोगशालाओं की जाँच करें https://github.com/0ang3el/websocket-smuggle.git

References

• https://blog.assetnote.io/2021/03/18/h2c-smuggling/
• https://bishopfox.com/blog/h2c-smuggling-request
• https://github.com/0ang3el/websocket-smuggle.git

Try Hard Security Group

{% embed url="https://discord.gg/tryhardsecurity" %}

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}