HTTP अनुरोध तस्करी - नए दृष्टिकोण

7 अक्टूबर, 2019 को, पोर्टस्विगर (बर्पसुइट के निर्माता) के अनुसंधान निदेशक ने HTTP रिक्वेस्ट तस्करी के नए तरीकों पर एक अध्ययन प्रकाशित किया। उनकी मदद से, उसने बगबाउंट पर $ 70,000 कमाए। इस लेख में, हम संक्षेप में हमले, उपकरण, और उन वेब सर्वरों पर शोध करने के तरीकों का पता लगाते हैं जो इस भेद्यता की चपेट में हैं।

HTTP रिक्वेस्ट स्मगलिंग क्या है

HTTP रिक्वेस्ट स्मगलिंग - वेब सर्वर के फ्रंट और वेब सर्वर के बैकेंड को वंशानुक्रम में लाने के उद्देश्य से किया गया एक हमला, जिसके परिणामस्वरूप हमलावर फ्रंटएंड सर्वर से पिछले एक एचटीटीपी अनुरोध को स्मगल कर सकता है। मूल लेख से चित्र एक अच्छे प्रदर्शन के रूप में कार्य करता है:

इस तरह के हमले से कई परिणाम हो सकते हैं - अन्य उपयोगकर्ताओं के सत्र में एक्सएसएस की शुरूआत, उपयोगकर्ताओं को तीसरे पक्ष के संसाधनों पर पुनर्निर्देशित करना, सर्वर कैश को जहर देना, एसएसआरएफ की समानता, और कई अन्य।

2019 के 2019 के स्मगलिंग अवतार में, जेम्स केटल ने गलत वेब सर्वर हेडर प्रोसेसिंग का शोषण किया

Transfer-Encoding: chunked 

यह दर्शाता है कि संदेश निकाय को भागों ( RFC ) में प्रेषित किया जाएगा। इस तथ्य के कारण कि कुछ वेब सर्वर chunked ट्रांसमिशन का समर्थन नहीं करते हैं, या हेडर को अलग तरीके से संभालते हैं, फ्रंटएंड केवल एक अनुरोध को "देखेगा" और बैकएंड इसे दो के रूप में पहचान लेगा। हमले के विवरण के बारे में अधिक जानकारी मूल लेख में पाई जा सकती है, एक व्यावहारिक कार्य भी है जिस पर आप मैन्युअल रूप से भेद्यता को खोजने के लिए अभ्यास कर सकते हैं।

त्वरित खोज के लिए, जेम्स ने बर्पसूट के लिए एक प्लग-इन विकसित किया, जो इनपुट के लिए अनुरोध प्राप्त करता है और आउटपुट पर सेवा की भेद्यता (यदि कोई हो) पर एक नोट बनाता है।

कमजोर वेब सर्वर के उदाहरण

मुझे कहना होगा कि वेब सर्वर के संचालन से संबंधित तस्करी और अन्य कमजोरियों की समस्या लंबे समय से एक अन्य शोधकर्ता ने उपनाम रेजिलो के तहत निपटा दी है । पिछले तीन वर्षों में, उन्होंने तीन लेख प्रकाशित किए हैं जिसमें उन्होंने लोकप्रिय वेब सर्वरों में पाई गई कमजोरियों का वर्णन किया है, जिनमें से अधिकांश को मध्यम और उच्च जीवनशैली सीवीई सौंपा गया है। संवेदनशील सर्वरों में अपाचे ट्रैफिक सर्वर, जेट्टी, अप्सिस हैं।

समस्या में रुचि के मद्देनजर, एक अन्य शोधकर्ता, नाथन डेविसन ने HAProxy में एक भेद्यता की खोज की , जिसने एक गलत तरीके से गठित हेडर को अनदेखा किया।

 Transfer-Encoding:[\x0b]chunked 

और इसे निम्न रूप में परिवर्तित कर दिया:

 Transfer-Encoding: chunked 

लेकिन बैकएंड सर्वर - gunicorn, फ्लास्क पर एप्लिकेशन को सम्‍मिलित करते हुए, हेडर पढ़ते हैं, जो भेद्यता को भड़काता है।

थोड़ी देर बाद, कई अन्य शोधकर्ताओं ने गोलंग http सर्वर के कार्यान्वयन में एक भेद्यता (सीवीई-2019-16276 को सौंपा) की खोज की - सर्वर ने हेडर को सामान्य किया यदि प्रीलेट से पहले एक जगह थी।
प्रश्न:

सर्वर द्वारा प्रसंस्करण के बाद:

जोखिम का फायदा उठाया जा सकता है यदि फ्रंटएंड सर्वर ने हेडर को एक स्थान के साथ अनदेखा किया, और अनुरोध के आकार की गणना करने के लिए सामग्री-लंबाई का उपयोग किया।

गो में लिखा गया कैडी वेब सर्वर भी असुरक्षित था क्योंकि इसमें उसी नेट / http लाइब्रेरी का उपयोग किया गया था। डेवलपर्स ने पुष्टि की कि GO को अपडेट करने और पैकेज के पुनर्निर्माण के बाद, समस्या गायब हो जाती है।

इस लेख के लेखक को lighthttpd सर्वर में एक समान समस्या मिली (कोई CVE असाइन नहीं किया गया था)। स्क्रीनशॉट से पता चलता है कि सर्वर अंतरिक्ष वाले हेडर को स्वीकार और संसाधित करता है:

डेवलपर्स RFC 7230 (और लेखक, भी) के साथ काफी सहमत नहीं हैं, और मानते हैं कि हेडर के गलत प्रसंस्करण के लिए जिम्मेदारी प्रॉक्सी के साथ निहित है जो सामान्य अनुरोधों को सामान्य करने और उनकी जांच किए बिना। हालाँकि, बग को नई रिलीज़ में ठीक किया जाएगा:

डिफ़ॉल्ट रूप से, lighttpd पार्स (और सामान्य करता है) अनुरोधों को रिवर्स करने के लिए उन्हें रिवर्स करने से पहले। ऐसा करने से https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn में उल्लिखित हमलों को लाइटटीडी से ऊपर की ओर सर्वर तक पहुंचाया जा सकता है।
हालांकि, जैसा कि ऊपर स्टब्यूहलर द्वारा उल्लेख किया गया है, लाइटस्टैप से नीचे की ओर प्रॉक्सिस, लाइटटैप के लिए कुछ भी पास कर सकता है।
लाइटटैप की अगली रिलीज़ में जो बदलाव किया जाएगा, वह फ़ील्ड-नेम और कॉलन से पहले स्पेस या टैब के साथ रिक्वेस्ट को रिजेक्ट करना होगा, लेकिन तभी जब लाइटटैप को सख्त http हैडर पार्सिंग के (डिफ़ॉल्ट) मोड में कॉन्फ़िगर किया गया हो।

चेरी बग ढांचे द्वारा उपयोग किए जाने वाले चेरूट वेब सर्वर में भी यही बग पाया गया था। यह मिनी-फ्रेमवर्क स्टार्टअप्स में पाया जाता है, इसका उपयोग अक्सर एपीआई लिखने के लिए किया जाता है। बग रिपोर्ट खोली स्थिति में हैंग हो जाती है।

भेद्यता के लिए आवश्यक और पर्याप्त स्थिति

इसलिए, भेद्यता की जाँच और दोहन के लिए आवश्यक शर्तें क्या हैं:

• पोस्ट अनुरोध। हालांकि RFC GET अनुरोधों के लिए सामग्री-लंबाई और स्थानांतरण-एन्कोडिंग हेडरों के उपयोग को स्पष्ट रूप से प्रतिबंधित नहीं करता है, वास्तव में उनका उपयोग केवल POST अनुरोधों में किया जाता है।
• फ्रंटेंड और बैकेंड सर्वर की उपस्थिति - यदि कोई नहीं है, तो सिंक्रनाइज़ करने के लिए कुछ भी नहीं होगा।
• वेब सर्वर को ट्रांसफर-एन्कोडिंग हेडर को अलग तरीके से पार्स करना चाहिए, अर्थात, इसे "पढ़ना" चाहिए, और दूसरे को अनदेखा करना चाहिए।

प्रयोगशाला परीक्षण

मौजूदा वेब सर्वर और प्रॉक्सी में बेहतर समझ और समस्या निवारण के लिए, डॉकर का उपयोग करके स्थानीय रूप से परीक्षण वातावरण को तैनात करना बुद्धिमानी है।

परीक्षण पर्यावरण आरेख का एक उदाहरण:

आवेदन कोड:

 from flask import Flask, request, jsonify app = Flask(__name__) @app.route('/', methods=['GET', 'POST']) def main(): # the next line is required for Transfer-Encoding support in the request request.environ['wsgi.input_terminated'] = True headers = {} for header in request.headers: headers[header[0]] = header[1] print (request.data) print (headers) return jsonify(body=str(request.data), headers=headers) 

उदाहरण के लिए, दृश्यपटल सेटिंग्स के साथ फाइल

 localhost:80 log ../access.log proxy / host.docker.internal:8888 

फिर सब कुछ सरल है, एप्लिकेशन चलाएँ:

 gunicorn --keep-alive 10 -k gevent --bind 0.0.0.0:8888 -w 4 backend:app 

और कंटेनर:

 docker run -d -t --name caddy -p 80:80 -p 443:443 -v /Users/sun/work/caddyfile:/etc/Caddyfile abiosoft/caddy:latest 

बर्प स्टोर से हम डीबगिंग सुविधा के लिए HTTP रिक्वेस्ट स्मगलर और लकड़हारा ++ स्थापित करते हैं। रिपीटर में अगला हम एक सरल अनुरोध बनाते हैं, उदाहरण के लिए यह:

 POST / HTTP/1.1 Host: localhost Content-Length: 8 Connection: close body=123 

और यह जांचने के लिए भेजें कि सब कुछ सही तरीके से कॉन्फ़िगर किया गया है:

 HTTP/1.1 200 OK Content-Length: 202 Content-Type: application/json Date: Mon, 07 Oct 2019 13:17:18 GMT Server: Caddy Server: gunicorn/19.9.0 Connection: close {"body":"b'body=123'","headers":{"Accept-Encoding":"gzip","Connection":"close","Content-Length":"8","Host":"host.docker.internal:8888","User-Agent":"Go-http-client/1.1","X-Forwarded-For":"172.17.0.1"}} 

अब लॉन्च स्मॉगल प्रोब लॉन्च करें और जवाब देखें।

सबसे दिलचस्प इस पल में शुरू होता है। यह समझने के लिए अनुरोधों और प्रतिक्रियाओं का विश्लेषण करना आवश्यक है कि क्या सेवाएं कमजोर हैं या नहीं। जिज्ञासु पाठक के लिए यह हिस्सा बचा हुआ है।