SSRF DoS रिले

2012 में, SSRF के हमले कुछ विदेशी से बहुत वास्तविक खतरे में बदल गए। इस क्षेत्र में अलेक्जेंडर पोलाकोव, व्लादिमीर वोरोत्सोव और अन्य शोधकर्ताओं के काम ने इस तरह के हमलों के संभावित तंत्र और संभावित परिणामों की लगभग पूरी तस्वीर बनाई। फिर भी, चूंकि इस विषय का विकास अपेक्षाकृत हाल ही में शुरू हुआ, इसलिए शोध का क्षेत्र अभी भी बना हुआ है।

यह आलेख एफ़टीपी प्रोटोकॉल की एक छोटी सी विशेषता पर चर्चा करेगा, जिसके कारण SSRF हमले की अनुमति देने वाली भेद्यता का उपयोग न केवल जानकारी प्राप्त करने के लिए किया जा सकता है और न ही एक हमले वेक्टर को विकसित करने के लिए, बल्कि बाहरी और आंतरिक प्रणालियों (जैसे) पर DoS जैसे हमलों को रिले करने के लिए भी किया जा सकता है। एक भेद्यता के साथ एक प्रणाली शामिल है जो एक DoS हमले की अनुमति देता है)।

पिछली शताब्दी का एक सा सिद्धांत (आप छोड़ सकते हैं)

सबसे पुराने DoS हमलों में से एक SYN बाढ़ है। हमलावर SYN / ACK प्रतिक्रियाओं को नजरअंदाज करते हुए SYN पैकेट के साथ हमलावर सेवा को भरता है। इस प्रकार, पीड़ित के मेजबान पर कई आधे-खुले कनेक्शन दिखाई देते हैं, और अंत में पीड़ित सेवा से जुड़ने के लिए पूरी तरह से सामान्य और वैध अनुरोध का जवाब देने में असमर्थ हो जाता है। हमले का यह तरीका इंटरनेट जितना ही पुराना है, और CERT शोधकर्ताओं के लेखकों द्वारा पहला आधिकारिक वर्गीकरण, 1996 में पहले से ही दिखाई दिया था। वर्तमान में, SYN बाढ़ से निपटने के कई तरीके हैं, जैसे कि SYN कुकीज़, SYN कैशिंग, फ़िल्टरिंग और गेटवे पर अनुकूली प्रसंस्करण। सेमी-ओपन का उपयोग, लेकिन SYN बाढ़ में पूरी तरह से खुला कनेक्शन न केवल इसलिए फायदेमंद है क्योंकि हमला करने वाली पार्टी प्रतिक्रियाओं को संसाधित नहीं करती है, बल्कि इसलिए भी कि किसी भी आईपी पते को भेजे गए SYN अनुरोधों में प्रतिस्थापित किया जा सकता है, इस प्रकार हमलावर को छिपाया जा सकता है। इस तथ्य के बावजूद कि खुले कनेक्शन के साथ एक हमला बचाव गढ़ के संदर्भ में अधिक प्रभावी हो सकता है, इसका सही कार्यान्वयन बहुत अधिक कठिन है (जब तक, निश्चित रूप से, यह डीडीओएस हमला है)। SSRF का उपयोग करते हुए, आप खुले कनेक्शन के साथ DoS हमले का अनुकरण कर सकते हैं, और हमलावर का IP पता उसी तरह पीड़ित से छिपाया जाएगा।

भेद्यता का सार

मान लीजिए कि हमारे पास एक मेजबान है जिसमें एक भेद्यता है जो एसएसआरएफ हमले की अनुमति देता है। यह एक XXE इंजेक्शन हो सकता है, एक गलत सर्वर रीडायरेक्ट, CRLF एक अनुरोध को विभाजित कर रहा है, या PHP में एक उपयोगकर्ता पैरामीटर के साथ सबसे सरल file_get_contents ()। मेजबान को एक निश्चित यूआरआई पास करके, हम इसे उपयुक्त प्रोटोकॉल का उपयोग करके अनुरोध को पूरा करने के लिए मजबूर कर सकते हैं। DoS relaying के बारे में पहली बात जो दिमाग में आती है, वह है HTTP URI टाइप करना dos:/ dos:/ । लेकिन, चूंकि HTTP प्रोटोकॉल का अर्थ है कि क्लाइंट रिक्वेस्ट भेजने वाला पहला है, होस्ट रिले और पीड़ित होस्ट के बीच का कनेक्शन जल्दी खत्म हो जाएगा। अन्य प्रकार के यूआरआई का विकल्प छोटा है: HTTP के अलावा, केवल एफ़टीपी लगभग सभी व्यापक तकनीकों द्वारा समर्थित है जिसमें SSRF संभव है। पहली नज़र में, एक प्रकार का यूआरआई पास करना dos:/ dos:/ एफ़टीपी क्लाइंट कमांड भेजने से पहले सर्वर के ग्रीटिंग का इंतजार कर रहा है ("220 एफ़टीपी सर्वर तैयार") के बाद से dos:/ आशाजनक लगता है। लेकिन, दुर्भाग्यवश, अधिकांश एफ़टीपी ग्राहकों के पास एक छोटा कनेक्शन टाइमआउट है और 5-10 सेकंड के लिए सर्वर से प्रतिक्रिया नहीं मिलने के बाद, बस डिस्कनेक्ट करें। SSRF "समर्थन" के साथ अधिकांश सर्वर प्रौद्योगिकियां संभावित पीड़ित से डिस्कनेक्ट हो जाएंगी यदि SSRF हमला होता है, तो वह कनेक्शन काट दिया जाता है। एक अन्य बाधा यह है कि क्लाइंट तुरंत सर्वर से डिस्कनेक्ट हो जाता है अगर उसे मानक ग्रीटिंग के अलावा कोई संदेश प्राप्त होता है। लेकिन सब कुछ खो नहीं है - SSRF के माध्यम से एफ़टीपी को अभी भी DoS रिले के रूप में उपयोग किया जा सकता है। ऐसा करने के लिए, बस प्रोटोकॉल के कुछ गुणों को याद रखें।

एफ़टीपी सर्वर के साथ काम करते समय, क्लाइंट दो कनेक्शनों का उपयोग करता है - नियंत्रण और डेटा ट्रांसफर। पहले का उपयोग कमांड और ग्राहक और सर्वर के बीच उनके निष्पादन के परिणामों का आदान-प्रदान करने के लिए किया जाता है, दूसरा - डेटा के डायरेक्ट ट्रांसफर (डायरेक्टरी लिस्टिंग, टेक्स्ट और बाइनरी फाइल आदि) के लिए। एफ़टीपी दो मोड में काम कर सकता है - सक्रिय या निष्क्रिय, डेटा कनेक्शन स्थापित करने का तरीका मोड पर निर्भर करता है।

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

आधुनिक नेटवर्क में, निष्क्रिय मोड का सबसे अधिक उपयोग किया जाता है, क्योंकि ग्राहक NAT या फ़ायरवॉल के पीछे हो सकता है। क्लाइंट सर्वर को एक निष्क्रिय मोड कमांड भेजता है और, सर्वर से अपना आईपी पता और पोर्ट नंबर प्राप्त करता है, एक ग्राहक कनेक्शन से प्राप्त पते और पोर्ट के लिए एक डेटा कनेक्शन खोलता है। निष्क्रिय मोड की सबसे दिलचस्प विशेषता यह है कि सर्वर के डेटा चैनल से जुड़ा होने के बाद, ग्राहक तब तक इंतजार करेगा जब तक सर्वर डेटा संचारित करना शुरू नहीं करता। इसके अलावा, अधिकांश एफ़टीपी ग्राहकों में इस कनेक्शन के टाइमआउट टीसीपी कनेक्शन के टाइमआउट के बराबर हैं। अतीत में, FTP सर्वर पर सक्रिय मोड का व्यापक रूप से स्कैन के लिए उपयोग किया जाता था जैसे कि "FTP BOUNCE" और DoS पर खुले कनेक्शन। SSRF आपको खुले कनेक्शन के साथ DoS हमलों के संचालन के लिए निष्क्रिय मोड FTP क्लाइंट का उपयोग करने की अनुमति देता है।

चूंकि क्लाइंट हमेशा डेटा ट्रांसफर कनेक्शन मोड में सर्वर से डेटा का इंतजार करता है, इसलिए निम्न आक्रमण योजना को लागू किया जा सकता है (चित्र 1 देखें)। हमलावर कहीं न कहीं एक नकली एफ़टीपी सर्वर (0) उठाता है, जो डेटा ट्रांसफर कनेक्शन के पते के रूप में पीड़ित के पते को प्रसारित करेगा। बदले में, SSRF के हमले में, आप URI के रूप में पास हो सकते हैं ftp/file.txt ftp/file.txt (1)। तब होस्ट, SSRF (होस्ट रिले) के अधीन, नकली एफ़टीपी सर्वर से जुड़ जाएगा और जब फ़ाइल (2) डाउनलोड करने की कोशिश कर रहा है, तो इसे पीड़ित के पते और पोर्ट (3) से प्राप्त होगा और पासपोर्ट कनेक्शन के पते और पोर्ट के रूप में प्राप्त होगा। होस्ट रिले और पीड़ित के बीच स्थापित कनेक्शन (4) कम से कम 60 सेकंड के लिए सक्रिय होगा (यदि पीड़ित होस्ट की सेवा क्लाइंट से कुछ डेटा की प्रतीक्षा कर रही है, तो यह व्यवहार है, उदाहरण के लिए, HTTP और LDAP)। एक अच्छा जोड़: डेटा कनेक्शन स्थापित करने के बाद, नकली एफ़टीपी सर्वर और होस्ट रिले के बीच नियंत्रण कनेक्शन काट दिया जा सकता है। डेटा ट्रांसफर या समय समाप्त होने तक डेटा कनेक्शन प्रभावित नहीं होगा। इस प्रकार, होस्ट पीड़ित को नकली FTP सर्वर के पते को स्थानांतरित करके कई SSRF हमले के दौरान, कनेक्शन प्रवाह पूरी तरह से गिर जाएगा, जो पूरी तरह से मेजबान रिले के वेब सर्वर की शक्ति और सेटिंग्स पर निर्भर करता है । इसी समय, नकली सर्वर पर लोड इतना बड़ा नहीं है। यदि हमारा नकली सर्वर प्रति सेकंड 100 अनुरोधों को संसाधित करने में सक्षम है, तो पीड़ित होस्ट के साथ हमले के पहले मिनट के अंत तक, 6,000 कनेक्शन पहले ही स्थापित हो जाएंगे। इसके अलावा, मेजबान पीड़ित को हमलावर के आईपी पते का कभी पता नहीं चलेगा।

यह अंतिम समस्या को हल करने के लिए बनी हुई है - हम पीड़ित के पते को क्लाइंट (होस्ट-रिले) में कैसे स्थानांतरित कर सकते हैं?


हमला पैटर्न

आधुनिक एफ़टीपी कार्यान्वयन में, निष्क्रिय मोड की स्थापना के लिए दो PASV और EPSV कमांड जिम्मेदार हैं। उनका मुख्य अंतर उत्तर में है।

PASV प्रतिक्रिया सिंटैक्स:
227 निष्क्रिय मोड में प्रवेश (a1, a2, a3, a4, p1, P2)
(जहाँ a1-a4 दशमलव संकेतन में IP पते के ऑक्टेट हैं, और पोर्ट को 256 * p1 + P2 1 के रूप में दर्शाया गया है)
EPSV कमांड का सिंटैक्स थोड़ा अलग है:
229 विस्तारित निष्क्रिय मोड में प्रवेश (||| p | |
(जहाँ p पोर्ट है)

इस प्रकार, नया EPSV कमांड (RFC 2428 में वर्णित) डेटा कनेक्शन स्थापित करने के लिए एक अलग आईपी पते को निर्दिष्ट करने से रोकता है, और डिफ़ॉल्ट एफ़टीपी क्लाइंट इस पते को नियंत्रण कनेक्शन में सर्वर पते के बराबर मानता है। ऐसा लगता है कि हमले का पतला विचार चरमरा रहा है। लेकिन वास्तव में, यदि सर्वर EPSV कमांड "500 कमांड कार्यान्वित नहीं किया जाता है" का जवाब देता है, तो एफ़टीपी क्लाइंट कार्यान्वयन का विशाल बहुमत सर्वर को PASV कमांड की पेशकश करेगा। और पहले से ही इसमें आप पीड़ित की सेवा के पते और बंदरगाह को स्थानांतरित कर सकते हैं। इस मामले में, ज्यादातर मामलों में, एफ़टीपी क्लाइंट से आरईटीआर कमांड (एक फ़ाइल प्राप्त करना) प्राप्त करने के तुरंत बाद, आप क्लाइंट से डिस्कनेक्ट कर सकते हैं।

उदाहरण: मान लें कि हमारे पास एक XXE JSP सर्वलेट है जो Java 1.6.x के लिए असुरक्षित है। उदाहरण के लिए, इसे एक बाहरी ENTITY के रूप में भेजकर, "<! ENTITY J SYSTEM" fakeftp.adress/file"> fakeftp.adress/file"> ", आप नकली FTP से इसका कनेक्शन शुरू कर सकते हैं। बदले में, एक हमले को अंजाम देने के लिए कमांड के जवाबों की निम्नलिखित श्रृंखला का उत्पादन करना चाहिए:

220 i58 एफ़टीपी सर्वर तैयार।
USER अनाम
331 अतिथि लॉगिन ठीक है, अपना ईमेल पता पासवर्ड के रूप में भेजें।

PASS Java1.6.0_01 @
230 अतिथि लॉगिन ठीक है, पहुंच प्रतिबंध लागू होते हैं।

टाइप करें I
200 प्रकार मैं सेट

EPSV ALL (2)
500 कमांड कार्यान्वित नहीं की गई, जो इस साइट पर नहीं है। (2)

PASV (2)
227 पैसिव मोड में प्रवेश (vic, tim, server, ip, 0.80)। (3)

फ़ाइल पुनर्प्राप्त करें
'फ़ाइल' (5,000,000 बाइट्स) के लिए 150 ओपनिंग बैनरी मोड डेटा कनेक्शन।

[यहां नकली एफ़टीपी सर्वर सुरक्षित रूप से डिस्कनेक्ट हो सकता है]



वायरशर्क में यह कैसे दिखता है (192.168.200.138 - नकली एफ़टीपी, 192.168.200.128 - रिले, 46.4.xx - पीड़ित)

एक निश्चित सूक्ष्मता यह है कि नकली FTP को किसी भी सक्रिय मोड कमांड (जैसे EPRT) और नए गठन निष्क्रिय मोड कमांड (EPSV, EPSV ALL) में एक त्रुटि के साथ प्रतिक्रिया करने की आवश्यकता होती है ताकि एफ़टीपी क्लाइंट के पास पुराने पीएएसटी कमांड का उपयोग करने के अलावा कोई विकल्प न हो। इसके अलावा, आरईटीआर कमांड के जवाब में, एक पर्याप्त फ़ाइल आकार निर्दिष्ट किया जाना चाहिए ताकि एफ़टीपी क्लाइंट कनेक्शन बनाए रखना जारी रखे, भले ही हमला सेवा उसे कुछ डेटा भेजती है।

SSRF के हमलों से ग्रस्त विभिन्न वेब तकनीकों में अलग-अलग एफ़टीपी ग्राहक कार्यान्वयन होते हैं। इन कार्यान्वयनों के अपने गुण होते हैं, जो DoS के उपयोग पर प्रतिबंध को लागू करते हैं, जो कि ftp:// NRRI योजना का उपयोग करते हैं। ग्राहकों की समेकित विशेषताओं को तालिका में प्रस्तुत किया गया है:

पीएचपी	+ *
cURL	+
जावा 1.6	+ *
जावा 1.7	केवल डेटा कनेक्शन 127.0.0.1 और FTP सर्वर के पते के साथ *
LWP	+ *
ASP.Net	- **
अजगर	+

* कुछ मामलों में, नकली एफ़टीपी सर्वर की कोई आवश्यकता नहीं है, क्योंकि इस तकनीक में एफ़टीपी नियंत्रण कनेक्शन की अवधि ६० सेकंड है, और यदि हमला की गई सेवा वापस नहीं आती है (गलत) डेटा, तो यूआरआई के रूप में एसएसआरएफ हमले को स्थानांतरित करना संभव है। सीधे /file.txt /file.txt । यदि आप भाग्यशाली हैं, तो एफ़टीपी कनेक्शन डिस्कनेक्ट नहीं किया जाएगा, भले ही वह कनेक्शन जिसके भीतर एसएसआरएफ हमला हुआ हो।

** ASP.Net में, XXE इंजेक्शन के साथ, रिमोट होस्ट के लिए कंट्रोल एफ़टीपी कनेक्शन 60 सेकंड के टाइमर के साथ स्थापित किया गया है। इसके अलावा, अगर SSRF हमले के भीतर संबंध होता है, तो पीड़ित के साथ संबंध बना रहता है। इसलिए, पीएएसवी समर्थन की कमी के बावजूद, रिले के साथ एक सीधा हमला संभव है।

यह हास्यास्पद है, लेकिन जावा 1.7 में नियंत्रण कनेक्शन पते के अलावा एक पते के साथ डेटा कनेक्शन स्थापित करने के लिए मना किया गया है, भले ही PASV कमांड का उपयोग किया गया हो। लेकिन, इसे संपादित करते हुए, डेवलपर्स स्थानीय लूप के बारे में भूल गए , अर्थात, आप इस तकनीक को आंतरिक होस्ट सेवाओं के DoS पर लागू कर सकते हैं, यहां तक ​​कि फ़ायरवॉल द्वारा बंद भी किया जा सकता है। वास्तविक उदाहरण के रूप में, SAP पोर्टल के पुराने संस्करणों में से एक, जिसमें XXE के माध्यम से SSRF हमला संभव था, का हवाला दिया जा सकता है। पोर्टल SSRF के साथ = <50 अनुरोध के साथ नीचे चला गया और एफ़टीपी के साथ यूआरआई का उपयोग करते हुए स्थानीय एसएपी वेब सर्वर पर हमलों को रिले कर रहा था।

सुरक्षा

आप इस तरह के हमले से खुद को कैसे बचा सकते हैं? यह स्पष्ट है कि यदि SSRF के लिए कोई भेद्यता नहीं है, तो यह तकनीक भी काम नहीं करेगी। यदि हम इस तर्क को छोड़ देते हैं कि आधुनिक दुनिया में RFC 2428 के समर्थन के बिना कोई भी FTP- सर्वर नहीं बचा है और PASV कमांड के उपयोग को प्रतिबंधित करने के लिए FTP- क्लाइंट लाइब्रेरी के सभी डेवलपर्स को आदेश देना चाहिए, तो ... आप कर सकते हैं कि Oracle डेवलपर्स ने जावा के नवीनतम संस्करण में क्या किया। - स्थानीय लूप और एफ़टीपी सर्वर के अलावा अन्य मेजबानों के साथ डेटा कनेक्शन की स्थापना पर रोक। लेकिन, जैसा कि आप देख सकते हैं, यह "संपादन" DoS रिले के खिलाफ पूर्ण सुरक्षा प्रदान नहीं करता है। इस तरह के हमलों के खिलाफ कुछ गारंटी केवल आउटगोइंग कनेक्शन के सख्त फ़िल्टरिंग द्वारा प्रदान की जाती है, और इस मामले में सर्वर व्यवस्थापक या सूचना सुरक्षा इंजीनियर ऐसा कर सकते हैं, लेकिन यह वह स्थिति है जब दवा रोग से अधिक खतरनाक हो सकती है। लेकिन यह अभी भी DoS को स्थानीय लूप के माध्यम से रिले करने से नहीं बचाता है।

पूरी तरह से नए या पहले से खोजे गए कुछ भी ऊपर वर्णित नहीं है, लेकिन यह देखने के लिए दोगुना मजेदार है कि सिस्टम पर नए प्रकार के हमलों की खोज कैसे लंबे समय से भूली हुई तकनीकों को जीवन में आने की अनुमति देती है।

लेख के लेखक डिजिटल सुरक्षा विश्लेषक अलेक्जेंडर बोल्शेव हैं, दुर्भाग्य से, जिनके पास अभी तक हैर पर कोई खाता नहीं है।
UPD: Genome_X के लिए धन्यवाद , एक खाता दिखाई दिया है - उपयोगकर्ता से मिलें dark_k3y !