SAPokalipsis। ब्लैकहैट। हैकिंग J2EE। दुःस्वप्न दुःस्वप्न

सभी को नमस्कार! यहाँ कई लोगों ने हमें और लिखने के लिए कहा; वास्तव में, उड़ानों के बीच थोड़ा समय खुर्द-बुर्द करते हुए, मुझे पुरानी कमजोरियों के एक जोड़े की याद आई ... हालाँकि, आपने पहले ही अनुमान लगा लिया था कि क्या।

इन बग्स के बारे में जानकारी के पहले प्रकाशन के बाद से यह एक लंबा समय रहा है। या बल्कि, एक पूरे साल। ठीक एक साल पहले, मैं J2EE SAP इंजन के सुरक्षा विषय पर एक रिपोर्ट के साथ ब्लैकहैट गया था। उस बग के बारे में बात क्यों नहीं की गई, खासकर जब से अभी भी हाथों में सब कुछ का वर्णन करने के लिए हाथ तक नहीं पहुंचे हैं जो कि RuNet में ब्लैकहैट पर प्रस्तुत किया गया था, अच्छी तरह से, ज़ीरोनाइट्स के एक लघु वीडियो के अलावा, जहां यह गड़बड़ हो गया था।

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

कुछ पानी

एसएपी से सभी व्यावसायिक अनुप्रयोग दो प्लेटफार्मों में से एक पर आधारित होते हैं, पुराने समाधानों और किसी भी सहायक अनुप्रयोगों की गिनती नहीं करते हैं। अधिक सटीक रूप से, एक तीसरा प्लेटफ़ॉर्म है - एसएपी व्यापार ऑब्जेक्ट, जो कई सिस्टम चलाता है, लेकिन सामान्य तौर पर यह कम सामान्य है और नेटवेवर जे 2 ईई इंजन के समान है।

प्लेटफ़ॉर्म नंबर एक, सबसे पुराना, सबसे प्रसिद्ध और कमोबेश सुरक्षा के दृष्टिकोण से अध्ययन किया गया, SAP NetWeaver ABAP है। इस एप्लिकेशन सर्वर के आधार पर, ईआरपी, सीआरएम, एसआरएम, पीएलएम और अन्य तीन-अक्षर संक्षिप्तिकरण जैसे सिस्टम का उपयोग किया जाता है, जो आमतौर पर स्मार्ट लोगों की आंखों में खुद को वजन देने के लिए सूचीबद्ध होते हैं। इन सभी अनुप्रयोगों को एक सामान्य लक्ष्य द्वारा एकजुट किया जाता है - व्यावसायिक प्रक्रियाओं को स्वचालित करने के लिए। इसका क्या मतलब है, कई अभी भी अद्यतित नहीं हैं, लेकिन इस लेख के लिए यह कोई फर्क नहीं पड़ता है।

दूसरा प्लेटफ़ॉर्म SAP NetWeaver J2EE इंजन है (इसके बाद "J2EE इंजन" के रूप में जाना जाता है; लेख में J2EE इंजन सभी अनुप्रयोगों के साथ संपूर्ण एप्लिकेशन सर्वर प्लेटफ़ॉर्म को संदर्भित करता है, न कि JAVA वर्चुअल मशीन का मूल)। यह मंच, वास्तव में, व्यावसायिक अनुप्रयोगों को संयोजित करने के लिए डिज़ाइन किया गया है, अर्थात्, अपने आप में अक्सर इसमें कोई महत्वपूर्ण जानकारी नहीं होती है, लेकिन तथाकथित मध्यस्थ के रूप में कार्य करता है। NetWeaver J2EE प्लेटफ़ॉर्म पर आधारित ऐसे अनुप्रयोगों की सूची में अन्य बातों के अलावा, SAP पोर्टल, एक प्रकार का सार्वभौमिक उद्यम पोर्टल शामिल है, जो विभिन्न संसाधनों के लिए एकीकृत पहुँच प्रदान करता है, उदाहरण के लिए, SSO के माध्यम से। पोर्टल पर, आप अक्सर कुछ आंतरिक SCADA- सिस्टम के इंटरफ़ेस का लिंक पा सकते हैं, जो सीधे उपलब्ध नहीं है, लेकिन कार्यक्षमता का हिस्सा पोर्टल पर प्रसारित होता है। इससे मुझे क्या खतरा है, मुझे समझ में आता है। पोर्टल के अलावा, जे 2 ईई इंजन आधारित है, उदाहरण के लिए, एसएपी इलेवन / पीआई एप्लिकेशन, जो एक उद्यम एकीकरण बस है और विभिन्न व्यावसायिक अनुप्रयोगों और कई अन्य अनुप्रयोगों के बीच विनिमय प्रदान करता है। सामान्य तौर पर, मैं यह सब क्यों कर रहा हूं?

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

इसलिए, J2EE भाग को विच्छेदित करने का निर्णय लिया गया। JAVA इंजन के हमारे सुरक्षा अध्ययन, 2009 में किसी समय शुरू हुए, लगभग 200 भेद्यताओं की खोज के कारण, जिनमें से अधिकांश वर्तमान में निर्माता द्वारा बंद हैं। एक्सएसएस-ओके, सूचना प्रकटीकरण कमजोरियों और अन्य अपेक्षाकृत सामान्य समस्याओं के द्रव्यमान के अलावा, अधिक दिलचस्प बग थे, जो वास्तव में, मैं और अधिक विस्तार से बताऊंगा।

यहाँ से पढ़े

हर कोई जानता है कि एक अलग समस्या से कमजोरियों के एक पूरे वर्ग (या कम से कम एक उपवर्ग) का पता लगाने के लिए बहुत कूलर है, क्योंकि यदि आप एक नया वर्ग खोजते हैं, तो आप बहुत सारे उदाहरण पा सकते हैं। और J2EE इंजन में उदाहरणों के साथ, कोई समस्या नहीं होगी, क्योंकि SAP NetWeaver J2EE इंजन प्लेटफ़ॉर्म एक J2EE मानक अनुप्रयोग सर्वर है जो आपको JAVA में लिखे गए अनुप्रयोगों को होस्ट करने की अनुमति देता है। यह Apache Tomcat की तरह कुछ है, केवल 100 गुना बड़ा है, और अधिक जटिल है, और समझ से बाहर है - और जहां जटिलता है, कमजोरियां निश्चित रूप से दिखाई देंगी। इस सर्वर पर, वास्तव में, व्यवसाय सिस्टम स्वयं स्थित हैं, जैसे एसएपी पोर्टल, एसएपी इलेवन, एसएपी पीआई, अलग-अलग अनुप्रयोगों या अनुप्रयोगों के सेट के साथ-साथ स्वयं के विकास के अनुप्रयोग। इस तरह की बड़ी प्रणालियों में छोटे अनुप्रयोग (एप्लिकेशन) शामिल होते हैं, जिनमें से प्रत्येक कोड की जटिलता और आकार के संदर्भ में अक्सर एक छोटे वेब-प्रोजेक्ट के बराबर होता है। डिफ़ॉल्ट रूप से बहुत सारे ऐसे एप्लिकेशन इंस्टॉल किए जाते हैं। इसलिए, नेटवेवर संस्करण में 6.40 में लगभग 500 हैं, और संस्करण 7.2 में पहले से ही 1200 हैं। स्वाभाविक रूप से, प्रत्येक एप्लिकेशन में अपने स्वयं के बग होते हैं, लेकिन उनके लिए खोज करने की कोई आवश्यकता नहीं है और वे सभी काफी विशिष्ट हैं। हम कुछ अधिक सामान्य, कुछ प्रकार की सामूहिक भेद्यता का पता लगाना चाहते थे, जिसका अर्थ है कि यह संभवतः सभी अनुप्रयोगों में मौजूद होना चाहिए।

यहां से बेहतर है

J2EE अनुप्रयोगों से परिचित लोग शायद जानते हैं कि वे सभी कम से कम एक फ़ाइल - web.xml से एकजुट होते हैं। जो लोग इस फ़ाइल के साथ और एसएपी के साथ और भी परिचित हैं, सबसे अधिक संभावना है, पहले से ही अनुमान लगाते हैं कि यह क्या है। लेकिन पहले, एक विशिष्ट WEB.XML फ़ाइल की संरचना को देखें:

<servlet> <servlet-name>CriticalAction</servlet-name> <servlet-class>com.sap.admin.Critical.Action</servlet-class> </servlet> <servlet-mapping> <servlet-name>Critical</</servlet-name> <url-pattern>/admin/criticalfunc</url-pattern> </servlet-mapping> <security-constraint> <web-resource-collection> <web-resource-name>Restrictedaccess</web-resource-name> <url-pattern>/admin/*</url-pattern> <http-method>GET</http-method> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> </auth-constraint> </security-constraint> 

किसी को शायद पहले से ही समझ में आ गया कि त्रुटि कहाँ हो सकती है ... नहीं, एक अस्पष्ट टैग पर उंगली उठाने की जल्दी मत करो, मेरा मतलब है कि केवल एक टाइपो नहीं है, लेकिन एक भेद्यता जो दुखद परिणाम पैदा कर सकती है। नहीं मिला? फिर मैं पढ़ने की सलाह देता हूं। J2EE इंजन में Invoker Servlet जैसा एक तंत्र है। यह आपको किसी भी सर्वलेट (एप्लिकेशन का वह भाग जो सर्वर पर कार्यशीलता का कार्य करता है) को डायरेक्ट लाइन पर, क्लास के नाम से कॉल करने की अनुमति देता है, ताकि डेवलपर्स के लिए डिबग मोड में सीधे क्लास का उपयोग करना सुविधाजनक हो। किसी भी मामले में, यह बहुत समझाया गया है, इसलिए मैं बहस नहीं करता, शायद यह वास्तव में सुविधाजनक है। लेकिन इस तरह से इस सर्वलेट के लिए URL का नाम URL बार में टाइप करके सुरक्षा सेटिंग्स को बायपास करने के लिए यह विशेष रूप से सुविधाजनक है: / सर्वलेट / <सर्वलेट-नाम-या-क्लास>।

और यहाँ सामान्य रूप से सबसे अधिक नम्र है

समस्या तब शुरू होती है जब आप एक सर्वलेट बनाते हैं जो एक खतरनाक क्रिया करता है, इसे निर्देशिका में जैसे कि व्यवस्थापक / व्यवस्थापक तक पहुंचाएं और व्यवस्थापक भूमिका वाले उपयोगकर्ताओं को छोड़कर, सभी के लिए <परिस्थिति-बाधा> का उपयोग करके इसे बंद कर दें। फ़ाइल यह है कि आप अभी भी लिंक / सर्वलेट / <सर्वलेट-नाम-या-वर्ग> पर Invoker तंत्र के माध्यम से सीधे सर्वलेट तक पहुंच सकते हैं और प्रमाणीकरण के बिना आवश्यक डेटा प्राप्त कर सकते हैं, क्योंकि / सर्वलेट निर्देशिका तक सीधी पहुंच किसी भी तरह से अवरुद्ध नहीं है (यदि यदि रक्षा / * पर खड़ा था, तो सब कुछ ठीक होगा)। यह इतना सरल और संक्षिप्त है, और इससे कोई फर्क नहीं पड़ता कि J2EE अनुप्रयोगों में कोई बफर अतिप्रवाह नहीं है और ऐसे वास्तुशिल्प कीड़े होने पर JAVA प्रकार C से अधिक सुरक्षित है।

हमारे लिए मुख्य समस्या यह थी कि, पहली बार , सभी 500 अनुप्रयोगों के बीच, जिन्होंने इनवोक सर्वलेट तक पहुंच को फ़िल्टर नहीं किया था और इस सर्वलेट के माध्यम से खतरनाक क्रियाएं कीं - आखिरकार, आपको वास्तविक जोखिम दिखाने की आवश्यकता है, और न केवल घुमावदार वास्तुकला में अपनी उंगली को इंगित करें शब्दों के साथ: "यह सैद्धांतिक रूप से, विशेष स्थितियों में, बशर्ते कि + bc * d कुछ बहुत अच्छा नहीं हो सकता है।"

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

मैंने धोखा दिया, वास्तव में यहाँ सबसे अधिक आनंदित है

इस भेद्यता के लिए कुछ हमारे लिए पर्याप्त नहीं था, और यह ब्लैकबैट जाने के लिए गोले के बिना किसी भी तरह से il faut नहीं था। और इसलिए मैंने और खोज शुरू की: WEB.XML के साथ और क्या किया जा सकता है? और फिर मुझे वर्ब टैम्परिंग जैसी भेद्यता के बारे में एक पुराना लेख याद आया। सिद्धांत रूप में वर्णित एक मान्य बग है, लेकिन वास्तविक सिस्टम पर कोई व्यावहारिक उदाहरण नहीं हैं। स्वाभाविक रूप से, मैंने कोशिश करने का फैसला किया: क्या होगा अगर यह काम करता है, और, वास्तव में भाग्य की उम्मीद नहीं है, मैं लगभग एक सुबह डोनट पर घुट गया ... यह वास्तव में काम करता है - नहीं, यह नहीं हो सकता! बहुत बढ़िया!
जुनून के कम होने के बाद, मुझे एहसास हुआ कि मुझे वास्तव में क्या करना था, क्योंकि यह वास्तुकला में एक समस्या का पता लगाने के लिए एक चीज थी, और दूसरा एक वास्तविक उदाहरण खोजने के लिए कि ऐसी कमजोरियां मौजूद हैं। हालाँकि, मैं आपको बताता हूँ कि मामला क्या है। तो, यहाँ फिर से हमारे प्रिय WEB.XML का एक उदाहरण है, या इसके भाग, जो अभिगम नियंत्रण के लिए जिम्मेदार है:

 <url-pattern>/admin/*</url-pattern> <http-method>GET</http-method> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> </auth-constraint> 

हमारे उदाहरण में, यह इंगित किया गया है कि केवल व्यवस्थापक भूमिका वाला उपयोगकर्ता ही / व्यवस्थापक निर्देशिका में स्थित अनुप्रयोगों तक पहुंच सकता है और केवल GET विधि को निष्पादित कर सकता है। इसके बारे में बिना? जो भी मामला है: यह पता चला है कि सब कुछ जो स्पष्ट रूप से निषिद्ध नहीं है, अनुमति दी जाती है, उदाहरण के लिए, HEAD पद्धति का उपयोग करना, जो बिल्कुल GET के समान है, लेकिन उपयोगकर्ता को परिणाम नहीं दिखाता है, इसे गुमनाम रूप से लागू किया जा सकता है , बिना उपयोगकर्ता और भूमिका के बिना। क्यों? हां, क्योंकि यह फ़ाइल में ऐसा कहता है: केवल व्यवस्थापक GET पद्धति का उपयोग करके / व्यवस्थापक निर्देशिका में प्राप्त कर सकते हैं। और अन्य तरीकों से - किसी को भी! यही है, अगर विधि का नाम स्पष्ट रूप से इंगित नहीं किया गया था, इसका मतलब यह होगा कि केवल व्यवस्थापक ही सभी तरीकों से जा सकता है, और सब कुछ ठीक होगा। और चूंकि एक विधि का संकेत दिया गया था, तो कृपया अन्य सभी को सूचीबद्ध करें।

क्या आप खुश रहना चाहते हैं? हां, यह वहां नहीं था: अब आपको फिर से हाईस्टैक में सुई की तलाश करने की जरूरत है, या यों कहें कि J2EE इंजन पर कम से कम कुछ एप्लिकेशन इंस्टॉल किए गए हैं:

• क्रिया छेड़छाड़ के लिए कमजोर
• HEAD अनुरोध का समर्थन करता है और इसे GET की तरह ही संसाधित करता है
• एक महत्वपूर्ण कार्रवाई करता है, और प्रतिक्रिया शरीर हमारे लिए महत्वपूर्ण नहीं है, क्योंकि यह HEAD है
• सभी प्रतिष्ठानों में मौजूद वांछनीय, और न केवल एक डेमो के रूप में

हाँ, थक गया। हां, मैंने किया।

सामान्य तौर पर, इस एप्लिकेशन को कहा जाता है ... लेकिन वैसे, आप इस पोस्ट को ध्यान से पढ़कर पता लगा सकते हैं। और यह वेब इंटरफेस के साथ J2EE इंजन के लिए किसी नियंत्रण से कम नहीं है। यही है, आप सिस्टम में एक उपयोगकर्ता बना सकते हैं, लेकिन उपयोगकर्ता क्या है! आप उसे किसी भी भूमिका को सौंप सकते हैं, आप ओएस कमांड को निष्पादित कर सकते हैं, आप दूरस्थ रूप से सर्वर को रोक सकते हैं, और यह सब एक साधारण HEV अनुरोध के साथ किया जा सकता है।

वहीं, SAP पोर्टल, जो J2EE इंजन का उपयोग करता है, आसानी से ऑनलाइन गूगल कर सकता है। उदाहरण के लिए, इस तरह: inurl: / irj / portal

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

आज के लिए बस इतना ही, मैं २०१२ में ब्ला के साथ लास वेगास के लिए एक हवाई जहाज पर उड़ान भर रहा हूं, जहां मैं एक बहुत ही सुंदर बग पेश करने जा रहा हूं - वैसे, SAP में भी और JAVA के संदर्भ में भी, इसलिए रिपोर्ट का इंतजार करें ...