Yandex.Mail। हैकॉस्ट्रोपे निवारण

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

शुरुआत

जब प्रतियोगिता की घोषणा की गई थी, मैं, डिजिटल सुरक्षा में लेखा परीक्षा विभाग के प्रमुख के रूप में, इसमें भाग नहीं लेना चाहता था (मैं सामान्य रूप से प्रतियोगिताओं से डरता हूं, और मालिकों के पास करने के लिए अन्य महत्वपूर्ण चीजें हैं: वहां एक आदेश दें या रिपोर्ट का अनुरोध करें): 8), लेकिन, हमेशा की तरह , जिज्ञासा और लाभ की प्यास ने उनकी स्थितियों को निर्धारित किया। मैंने कुछ दिलचस्प और मजेदार देखने का फैसला किया, इसलिए मैंने एक्सएसएस और सीएसआरएफ जैसी कमजोरियों की तलाश में समय बर्बाद नहीं करने का फैसला किया। सबसे पहले, वे किसी भी स्क्रिप्ट का अध्ययन करते समय स्वचालित रूप से पाए जाते हैं (वास्तव में, XSS'ok के एक जोड़े को तुरंत मिल गया था)। दूसरी बात - यह दिलचस्प नहीं है (हालांकि यह खतरनाक है, जैसा कि kyprizel ने एक ही प्रतियोगिता में दिखाया था)। इसके अलावा, चूंकि प्रतियोगिता क्षेत्र बहुत बड़ा था, इसलिए मैंने खुद को केवल मेरे लिए सबसे दिलचस्प सेवा - मेल तक सीमित करने का फैसला किया। उसी समय, उन्होंने एक से अधिक कार्य दिवस नहीं बिताने का फैसला किया ताकि काम से विचलित न हों। इसने मुझे चिंता करने की अनुमति नहीं दी कि मुझे कुछ भी नहीं मिलेगा, क्योंकि कोई समय नहीं है (आत्म-औचित्य, हुह!), और वास्तव में कुछ कार्बन मोनोऑक्साइड की तलाश करें। किसी भी मामले में, शुरुआत के लिए, आपको बस वेब इंटरफ़ेस की संरचना और तर्क का अध्ययन करना होगा। यह तुच्छ था - बर्पसुइट और Google क्रोम में निर्मित डेवलपर इंटरफ़ेस की मदद से।


एंटोन कारपोव उर्फ टॉक्सा ( टोक्ज़ा ) बताता है कि कैसे पाए जाने वाले कीड़े का मूल्यांकन किया जाएगा।

फ़्रंटएंड

मेल सामग्री वितरित करने के लिए मुख्य स्क्रिप्ट एक निश्चित हैंडलर है ।jsx यह उल्लेखनीय है कि डेवलपर्स स्वयं स्वेच्छा से मेल वास्तुकला पर जानकारी साझा करते हैं, इसलिए हम जानते हैं कि इस मामले में हम सर्वर-साइड जावास्क्रिप्ट के साथ काम कर रहे हैं। हालाँकि, मुझे इन सभी सूक्ष्मताओं की आवश्यकता नहीं थी, क्योंकि वहां पाए जाने वाले पहले भेद्यता इतनी क्लासिक हो गई थी कि कार्यान्वयन विवरण इतना महत्वपूर्ण नहीं है। लेकिन पहले, सामान्य विवरण:

• हैंडलर.jsx के लिए एक अनुरोध POST या GET हो सकता है
• अनुरोध वांछित मॉड्यूल और इसके संबंधित मापदंडों को इंगित करता है
• अनुरोध के जवाब में, सामग्री XML के रूप में है

कुछ मॉड्यूल और उनके अर्थ:

• "फ़ोल्डर" - फ़ोल्डर्स की सामग्री
• "संदेश-निकाय" - संदेश निकाय
• "निकटतम संदेश" - आसन्न पत्र

इसे स्पष्ट करने के लिए, मैं अलेक्सई एंड्रोसोव की उसी प्रस्तुति का एक स्क्रीनशॉट दूंगा।



यही है, यह स्पष्ट है कि सभी सामग्री को AJAX अनुरोधों का उपयोग करके एक सामान्य इंटरफ़ेस में इकट्ठा किया गया है और XSL टेम्पलेट्स के लिए "मानव" रूप में लाया गया है।
खैर, एक ही prese से एक उदाहरण अनुरोध:

/handlers.jsx?_handlers.0=message&ids=1234567890&_handlers.1=message&ids=1234567891

XML प्रतिक्रिया:

<handlers> <handler name=”message” key=”_h=message&ids=1234567890”> <!--  --> </handler> <handler name="message" key="_h=message&ids=1234567891"> <!--  --> </handler> </handlers> 

ऐसा लगता है कि सब कुछ सरल है। _Handlers पैरामीटर उस डेटा को निर्धारित करेगा जिसकी हमें ज़रूरत है (हैंडलर मॉड्यूल), और आईडी पहचानकर्ता है। अर्थात्, यह उदाहरण पहचानकर्ता 1234567890 और 1234567891 के साथ पत्रों को लोड करता है। स्वाभाविक रूप से, मैंने पहली कोशिश की थी कि मैं आईडी और विकल्प को बदल दूं, उदाहरण के लिए, 123431337, जो आदर्श रूप से, मुझे इस पहचानकर्ता के साथ एक पत्र वापस करना चाहिए, भले ही यह मेरा नहीं।

मैं सफल नहीं हुआ वैसे, मेरे सहयोगी और मित्र - चिपिक ने भी यही कार्रवाई की। पिछले साल, उन्होंने और मैंने पहले ही Google को तोड़ दिया था (और हमने लिखा था कि यह कैसा था )। लेकिन वह भी असफल रहा। हालाँकि, यह एक मज़ेदार बात है: "कोड कवरेज" जैसी कोई चीज़ है। अर्थात्, कुछ सत्यापन कार्रवाई करने के बाद, हमने कोड का हिस्सा चेक किया। यह मानना ​​तर्कसंगत है कि यदि आप मॉड्यूल नाम को बदलने का प्रयास करते हैं, तो आईडी कोड पहचानकर्ता द्वारा एक्सेस प्राधिकरण की जांच के लिए जिम्मेदार है। लेकिन थोड़ी किस्मत ने यह समझने में मदद की कि ऐसा नहीं है।

बागा

कुछ समय बाद, मैंने फिर से आईडी बदलने का फैसला किया, लेकिन एक और मॉड्यूल के लिए - " निकटतम-संदेश ", और लो और निहारना ... पहले तो मुझे समझ में नहीं आया कि यह कैसे हुआ, लेकिन बाद में मुझे विश्वास हो गया कि यह एकमात्र मॉड्यूल है जो जांच नहीं करता है क्या आईडी संदेश वर्तमान उपयोगकर्ता के हैं। इसका मतलब है कि इस मॉड्यूल के साथ मैं अन्य सर्वर उपयोगकर्ताओं के "पड़ोसी पत्रों" को लोड कर सकता हूं! आइए वैध अनुरोध का विश्लेषण करें:

http:// mail.yandex.ru/neo2/handlers/handlers.jsx?_handlers=message-nearest&ids=2020000002590081157

2020000002590081157 मेरे पत्र के आईडी हैं, काफी ठोस और निश्चित हैं। यांडेक्स सर्वर इस अनुरोध को वापस करता है:

(... - वॉल्यूम कम करने के लिए कट)

 <handlers> <handler name="message-nearest" gid="0" key="_handler=message-nearest&ids=2020000002590081157"> <message-nearest> <list> <message id="2020000002590182740"> <thread id="2020000001499988536"/> <folder id="2020000650059912118"/> <date> <timestamp>1320143331000</timestamp> <iso>2011-11-01T14:28:51</iso> <short>01.11.11</short> <full>1 . 2011  14:28</full> </date> <size>2 </size> <last_status/> <subject fwd="Fwd:">TEST</subject> <firstline>,     2</firstline> <to> <name>ne_eik01110d111@yandex.ru</name> . . . </to> <from> <name>SSS AAA</name> . . . </from> … </message> <message id="2020000002590081157"> <thread id="2020000001499929723"/> <folder id="2020000650059912118"/> . . . <size>1,8 </size> <last_status/> <subject re="Re[2]:">TEST</subject> <firstline> ,  … </firstline> … </message> <message id="2020000002590076913"> <thread id="2020000001499929723"/> <folder id="2020000650059912118"/> . . . <full>1 . 2011  14:01</full> . . . <subject>TEST</subject> <firstline> 1</firstline> <from> <name>Alexey Sintsov</name> <email ref="3cab8cda1a132a2d17803cc47cd55d91">ddookie1@inbox.ru</email> </from> <reply-to> <name>ddookie1@inbox.ru</name> <email ref="3cab8cda1a132a2d17803cc47cd55d91">ddookie1@inbox.ru</email> </reply-to> . . . </message> </list> <timer_db>266</timer_db> <timer_logic>175197</timer_logic> </message-nearest> </handler> <login>ne_eik01110d111</login> <actual-version>5.11.55</actual-version> <timestamp>1335882564270</timestamp> </handlers> 

सर्वर तीन वस्तुओं के साथ एक्सएमएल लौटाता है। प्रत्येक वस्तु पत्र के बारे में जानकारी है:

• जब
• किससे
• जिसे
• हैडर
• अक्षर के शरीर की पहली पंक्ति

इसके अलावा, अनुरोध में जिस आईडी का संकेत दिया गया है वह संदेश दूसरी वस्तु पर जाता है। प्रथम और तृतीय ऑब्जेक्ट अनुरोधित ऑब्जेक्ट के समान फ़ोल्डर में आसन्न संदेश हैं। आईडी बदलना, उदाहरण के लिए, एक के बाद, हमें तीन अन्य लोगों के संदेश मिलते हैं। बल्कि, प्राप्ति की तिथि, हेडर, प्राप्तकर्ता, आईडी पहचानकर्ता और पत्र की पहली पंक्ति। लेकिन वास्तव में पहली पंक्ति केवल पहली पंक्ति नहीं है! अनुभव से पता चला है कि कई लाइनें वहां प्रवेश कर सकती हैं, और यहां मुख्य बात लाइन फीड की मात्रा और संख्या है। मेरे प्रयोगों में परिणाम और प्रत्येक 5 पंक्तियाँ थीं! यही है, एक वास्तविक खतरे के बारे में बात करने के लिए वॉल्यूम काफी बड़ा है।

संदेश निकाय में भेजा गया:

– 1

, – 3
----- – 4
– 5
– 6

– 8
! – 9



हैंडलर.jsx का उपयोग करते हुए इंटरसेप्टेड:

 <firstline> –  1 ,   –  3 ----- –  4  –  5  –  6  </firstline> 

जैसा कि आप देख सकते हैं, डेटा की यह मात्रा गोपनीयता का उल्लंघन करने और यहां तक ​​कि सेवाओं से खातों को चुराने के लिए है जो पंजीकरण डेटा ई-मेल (उदाहरण के लिए, फेसबुक) को भेजते हैं।

थोड़ा सा

सामान्य तौर पर, सब कुछ स्पष्ट है - बग सबसे सरल है, लेकिन कुछ सवाल हैं:

• कैसे पहुंच बॉक्स के लिए उपयोग करने के लिए?
• बॉक्स में आवश्यक पत्र कैसे प्राप्त करें?

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

और कुछ और विवरण हैं जिन्हें स्पष्ट रूप से स्पष्ट किया गया है। यह पता चला है कि आईडी एक पत्र या फ़ोल्डर के लिए सिर्फ एक पहचानकर्ता नहीं है, यह वास्तव में एक वस्तु है।

पहले 4 अंक नोड की संख्या है (मुझे नहीं पता कि इसे सही तरीके से कैसे कहा जाता है, इसलिए मैं इसे कॉल करूंगा) जिस पर बॉक्स होस्ट किया गया है। यदि आप ध्यान देते हैं, तो आप देखेंगे कि आपके सभी पत्रों और फ़ोल्डरों में एक स्थिर संख्या है। इसलिए, पहचाने गए भेद्यता का उपयोग करके, आप केवल उसी नोड से पत्र पढ़ सकते हैं जहां आपका मेलबॉक्स स्थित है। एक नोट पर कई अरब पत्र! कई नोड्स हैं, और दो एक साथ पंजीकृत उपयोगकर्ता विभिन्न नोड्स के लिए प्राप्त कर सकते हैं।

बीच में, प्रकार पहचानकर्ता एक फ़ोल्डर या संदेश (संदेश 00 में 65 की तरह एक फ़ोल्डर है), और अंतिम अंक नोड पर संदेश पहचानकर्ता हैं। यह सिर्फ आखिरी बदलाव है और आप कर सकते हैं। अर्थात्, मेरे उदाहरण में, वर्तमान संदेश 259008115 7 नंबर के साथ था। अब आप मोटे तौर पर एक नोड पर संदेशों की मात्रा का प्रतिनिधित्व करते हैं।

दूसरा मज़ेदार तथ्य: संदेश पहचानकर्ता एक पूर्ण, वृद्धिशील मूल्य है। यही है, वर्तमान नोड द्वारा संसाधित (प्राप्त) अगला पत्र 259008115 8 होगा । भले ही यह पत्र मुझे न भेजा जाए। अब आप दोनों समस्याओं को हल कर सकते हैं। यही है, एक लक्षित हमले को अंजाम देना, न कि मूर्खतापूर्ण तरीके से एक अरब पत्र 8 को डंप करना)

आक्रमण

आपको पीड़ित के समान नोड पर मेलबॉक्स बनाना होगा। पीड़ित का बॉक्स बहुत पहले पंजीकृत होने पर हल करना मुश्किल है। आप विभिन्न नोड्स से बक्से को भुना सकते हैं या चोरी कर सकते हैं और उन नोड्स पर बक्से पंजीकृत कर सकते हैं जहां यह संभव है। लेकिन अगर पीड़ित का बॉक्स हाल ही में बनाया गया था, तो हमले में सफलता की 100% संभावना है। इसलिए, उदाहरण के लिए, हम लक्ष्य- mail1 @ yandex.ru मेलबॉक्स पर हमला करेंगे। हमने इसे हाल ही में बनाया है। इसलिए, हमले की सफलता अधिक है। इसलिए, हम मेलबॉक्‍स का एक समूह बनाते हैं: चेक-मेल 1 , चेक-मेल 2 , चेक-मेल 3 आदि। मुख्य बात यह है कि सभी बनाए गए बॉक्स अलग-अलग नोड्स पर होने चाहिए। उसके बाद, हम लक्ष्य-mail1 पर एक ईमेल भेजते हैं और हमारे द्वारा बनाए गए सभी मेलबॉक्सेस की प्रतिलिपि बनाते हैं।



हास्य क्या है? जब हम अपने "चेक-मेल" खातों में आईडी पत्र देखते हैं, तो हम इस मूल्य को 5 इकाइयों द्वारा बढ़ाने और घटाने का प्रयास करेंगे। और उस नोड पर जहां चेक-मेलएन लक्ष्य-मेल 1 के साथ मेल खाता था, हम अपना पत्र देखेंगे। एक उदाहरण देखें:



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

निष्कर्ष

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

यद्यपि भेद्यता सरल है, हमला स्वयं काफी जटिल है और इसे आईडी पीढ़ी और नोड आर्किटेक्चर के विश्लेषण की आवश्यकता है। एक भेद्यता को उजागर करना केवल "छेद" की तलाश में अधिक दिलचस्प है। एक विशिष्ट मेलबॉक्स से एक विशिष्ट पत्र को अपहरण करने में यह एक दिलचस्प चुनौती थी। यह पुराने बक्से के लिए मुश्किल है, लेकिन अभी भी संभव है, और हौसले से निर्मित बक्से के लिए, सफलता दर 100% है। पुराने के लिए, यह एक ही नोड पर एक मेलबॉक्स बनाने की क्षमता पर निर्भर करता है। नए सिरे पर आंकड़े: प्रत्येक तीसरे या चौथे बनाए गए बॉक्स को एक ही नोड पर मिलता है। इसके लॉन्च के क्षण से नोड पर पंजीकरण की संभावना की अवधि लगभग छह महीने है (अर्थात, "नया" / "हौसले से बनाया गया" बॉक्स, यह एक ऐसा बॉक्स है जिसे आधे साल पहले बनाया गया था)। सिद्धांत रूप में, फिर, छह महीने बाद, इस नोड पर पंजीकरण करना असंभव है, जैसा कि मुझे लगता है, अतिभारित है।

धन्यवाद:

एंटोन कारपोव ( टोकोज़ा ) और यैंडेक्स - एक दिलचस्प चुनौती और प्रतियोगिता के लिए, और दूसरे स्थान के लिए। दरअसल, कमजोरियां हर जगह हैं, और इस तरह की प्रतियोगिता से उनमें से कई को बंद करने में मदद मिली!
दिमित्री चस्तुखिन ( चिपिक ) - क्योंकि जब वह बग के बारे में पता लगाता था तो वह बहुत परेशान नहीं होता था, क्योंकि वह पहले ही "परीक्षण कर चुका था"
d0znpp , kyprizel , ptsecurity - प्रतियोगिता में भाग लेने के लिए और भयानक छेद खोजने के लिए, जिसने मुझे पूरे महीने आराम करने की अनुमति नहीं दी (मुझे प्रतियोगिताओं से नफरत है)।

अंत में प्रूफ वीडियो ...



सबको बाय!

पुनश्च: चूंकि मैं यैंडेक्स का कर्मचारी नहीं हूं, इसलिए वास्तुकला, एल्गोरिदम और नामों का विवरण अविश्वसनीय हो सकता है। Yandex.Mail डिवाइस के बारे में सभी निष्कर्ष लेखक की आंतरिक भावनाओं और सहज ज्ञान युक्त दृष्टि पर आधारित हैं।