Upgrade Header Smuggling

Reading time: 8 minutes

tip

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

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

H2C Smuggling

HTTP2 Over Cleartext (H2C)

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

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

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

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

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