Upgrade Header Smuggling

Reading time: 8 minutes

tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

H2C Smuggling

HTTP2 Over Cleartext (H2C)

H2C, या http2 over cleartext, अस्थायी HTTP कनेक्शनों के मानक से भटकता है, एक मानक HTTP कनेक्शन को स्थायी में अपग्रेड करके। यह अपग्रेडेड कनेक्शन ongoing communication के लिए 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 मान को बाहर करता है, क्योंकि कुछ बैकएंड मानकों का पालन नहीं कर सकते हैं।

caution

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

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

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

https://github.com/0ang3el/websocket-smuggle/raw/master/img/2-4.png

Scenario 2

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

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

https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-4.png

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

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

https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-5.png

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

Labs

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

References

tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें