एसएसएल / टीएलएस प्रोटोकॉल पर पहला काम करने वाला हमला

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

BEAST क्या है?

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

शोधकर्ता अभी तक उपयोगिता को प्रकाशित नहीं करते हैं, लेकिन किए गए काम के बारे में श्वेतपत्र साझा करते हैं । कार्यक्रम में दो तत्व शामिल हैं: एक स्निफर जो HTTPS ट्रैफ़िक का विश्लेषण करता है, और जावास्क्रिप्ट और जावा में लिखा गया एक विशेष एजेंट, जिसे पीड़ित के ब्राउज़र में लोड किया जाना चाहिए (उदाहरण के लिए, आपको उपयोगकर्ता को आवश्यक कोड के साथ पृष्ठ खोलने के लिए मजबूर करना होगा)। गुप्त कुकीज़ को प्रसारित करने के लिए उपयोग किए जाने वाले उसी सुरक्षित संचार चैनल में डेटा को विशेष रूप से एम्बेड करने के लिए एक एजेंट की आवश्यकता होती है। यह डेटा को कैसे डिक्रिप्ट करता है? यह वह जगह है जहां लंबे समय से एसएसएल 3.0 / टीएलएस 1.0 भेद्यता आती है, जिसे हम अधिक विस्तार से बताएंगे।

सरल प्रतिस्थापन मोड समस्या

एसएसएल एन्क्रिप्शन 1.0 सुविधाएँ

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

ब्लॉक सिफर के संचालन का सिद्धांत समान आकार के एन्क्रिप्टेड ब्लॉकों में प्लेटेक्स्ट ब्लॉक प्रदर्शित करना है। ब्लॉक सिफर की कल्पना करने का सबसे आसान तरीका 2 ^ 128 प्रविष्टियों वाली एक विशाल तालिका के रूप में है, जिनमें से प्रत्येक में पाठ एम का एक ब्लॉक और इसके संबंधित एन्क्रिप्टेड ब्लॉक सी है। तदनुसार, प्रत्येक एन्क्रिप्शन कुंजी के लिए एक अलग तालिका होगी। अगला, हम एक फ़ंक्शन के रूप में एन्क्रिप्शन को निरूपित करेंगे:

सी = ई (की, एम), जहां एम स्रोत डेटा है, कुंजी एन्क्रिप्शन कुंजी है, और सी प्राप्त एन्क्रिप्टेड डेटा है।

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

Ci = E(Key, Mi xor Ci-1)

पहले ब्लॉक के एन्क्रिप्शन के दौरान, XOR स्रोत कोड कुछ आरंभीकरण वेक्टर (इनिशियलाइज़ेशन वेक्टर, IV) है, जो पिछले एन्क्रिप्शन के परिणाम को बदलता है, जो कि स्पष्ट कारण के लिए नहीं है। जैसा कि आप देख सकते हैं, सब कुछ काफी सरल है। हालांकि, यह सिद्धांत एक बड़ी वस्तु के लिए स्थिति का वर्णन करता है, जैसे कि, उदाहरण के लिए, एक फाइल जो आसानी से ब्लॉक में विभाजित है। बदले में, एसएसएल / टीएलएस एक क्रिप्टोग्राफिक प्रोटोकॉल है - इसे एक फ़ाइल को नहीं, बल्कि पैकेटों की एक श्रृंखला को एन्क्रिप्ट करने की आवश्यकता है। एसएसटी / टीएलएस कनेक्शन का उपयोग एचटीटीपीएस अनुरोधों की एक श्रृंखला भेजने के लिए किया जा सकता है, जिनमें से प्रत्येक को एक या एक से अधिक पैकेट में विभाजित किया जा सकता है, जो बदले में, कुछ सेकंड या कई मिनटों के भीतर भेजा जा सकता है। इस स्थिति में, CBC मोड का उपयोग करने के दो तरीके हैं:

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

ध्यान देना, एक महत्वपूर्ण बिंदु। SSL 3.0 / TLS 1.0 प्रोटोकॉल दूसरे विकल्प का उपयोग करता है, और यह वह जगह है जहाँ हमले का अवसर निहित है।

सीबीसी सिफर के संचालन का सिद्धांत

पूर्वनिर्धारित प्रारंभिक वेक्टर

हमला कई मान्यताओं पर आधारित है, लेकिन BEAST के रचनाकारों के अनुभव से पता चला है कि वास्तविक जीवन में उन्हें लागू करना काफी यथार्थवादी है। पहली धारणा: एक हमलावर को ट्रैफ़िक को सूंघने में सक्षम होना चाहिए जो ब्राउज़र भेजता है। दूसरी धारणा: बुरे व्यक्ति को पीड़ित को उसी सुरक्षित संचार चैनल पर डेटा संचारित करने के लिए मजबूर करना पड़ता है। इसकी आवश्यकता क्यों है? ऐसे मामले पर विचार करें जहां बॉब और एलिस कंप्यूटर के बीच एक सुरक्षित संबंध स्थापित हो। हमें एक संदेश मिलता है जिसका i-block, जैसा कि हम मानते हैं, में ऐलिस का पासवर्ड (या गुप्त कुकी है - यह महत्वपूर्ण नहीं है)। एन्क्रिप्टेड ब्लॉक को सीआई के रूप में निरूपित करें, क्रमशः एमआई - इसका पासवर्ड। आपको याद दिला दूं कि Ci = E (Key, Mi xor Ci-1)। अब मान लें कि उसका पासवर्ड R है। मुख्य विचार यह है कि हम अपनी धारणा की शुद्धता को सत्यापित कर सकते हैं!

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

M1 = Ci-1 xor IV xor P

यदि संदेश उसी सुरक्षित संचार चैनल पर भेजा गया था, तो एन्क्रिप्शन के बाद नए संदेश का पहला ब्लॉक इस तरह दिखाई देगा:

C1 = E(Key, M1 xor IV) =
= E(Key, (Ci-1 xor IV xor P) xor IV)
= E(Key, (Ci-1 xor P))
= i

मैंने सभी पूर्ण M1 संकेतन का उपयोग किया था, जिसके बाद मैंने इस तथ्य का उपयोग करके सूत्र को सरल किया कि (IV xor IV) नष्ट हो जाएगा (XOR की उल्लेखनीय संपत्ति)। यह पता चला है कि अगर ऐलिस के पासवर्ड के बारे में हमारी धारणा सही है (यानी, एम वास्तव में पी के बराबर है), तो नए संदेश सी 1 का पहला एन्क्रिप्टेड ब्लॉक पहले से इंटरसेप्ट किए गए सीई के बराबर होगा! और इसके विपरीत: यदि धारणा गलत है, तो कोई समानता नहीं होगी। इसलिए हम अपनी धारणाओं को परख सकते हैं।

SSL हमले को लागू करने के लिए सर्वर से अनुरोध भेजना

खोज सुविधाएँ

यदि हम मानते हैं कि हमारे पास बहुत समय और कई प्रयास हैं, तो हम इस तकनीक को बार-बार दोहरा सकते हैं जब तक कि हम एम का सही मूल्य नहीं पाते हैं। हालांकि, व्यवहार में, एम का एक खंड लंबाई में 16 बाइट्स है। यहां तक ​​कि अगर हम बाइट्स को छोड़कर सभी बाइट्स का मूल्य जानते हैं, तो बचे हुए बाइट्स का अनुमान लगाने के लिए, हमें 2 ^ 15 (32,768) प्रयासों की आवश्यकता है। और अगर हम कुछ भी नहीं जानते हैं? संक्षेप में, एक तकनीक केवल एकमात्र मामले में काम कर सकती है - यदि आपके पास एम। के मूल्य के बारे में मान्यताओं की सीमित संख्या है। अधिक सटीक: हमें इस ब्लॉक की अधिकांश सामग्रियों को जानना चाहिए - यह वर्णित भेद्यता का फायदा उठाने का एकमात्र तरीका है। एक तरकीब है।
मान लीजिए कि एक हमलावर नियंत्रित कर सकता है कि एन्क्रिप्टेड ब्लॉक में डेटा कैसे स्थित होगा। चलो वापस जाते हैं, उदाहरण के लिए, ऐलिस के साथ। मान लीजिए कि हम जानते हैं कि उसका पासवर्ड 8 वर्ण लंबा है। यदि कोई हमलावर पासवर्ड की व्यवस्था कर सकता है ताकि केवल एक ही पात्र पहले ब्लॉक में आए, और शेष सात अगले भाग में आए। विचार पहले ब्लॉक के पहले 15 बाइट्स में ज्ञात डेटा प्रसारित करने के लिए है - फिर केवल अंतिम बाइट का चयन करना संभव होगा, जो पासवर्ड का पहला चरित्र है। उदाहरण के लिए, मान लें कि आप फ़ॉर्म की एक पंक्ति भेजना चाहते हैं: "उपयोगकर्ता: ऐलिस पासवर्ड: ********", जहां "********" पासवर्ड ही है। यदि कोई हमलावर स्ट्रिंग को पास करने का प्रबंधन करता है, तो यह निम्नलिखित ब्लॉकों में विभाजित है "[जूँ पासवर्ड: *] [******* .........]", तो पासवर्ड के पहले चरित्र का चयन करना अब असंभव नहीं लगता है कार्य। सबसे खराब स्थिति में, हमें एक दयनीय 256 प्रयासों की आवश्यकता होगी। और विशेष भाग्य के मामले में, यह पूरी तरह से एक है :)! पहला बाइट लेने के बाद, विभाजन के सीमा को एक वर्ण द्वारा स्थानांतरित करना संभव है: अर्थात्, पहले संदेश में 14 ज्ञात बाइट्स को प्रसारित करना। ब्लॉक अब पासवर्ड के पहले दो बाइट्स के साथ समाप्त होगा, जिनमें से पहला हमने पहले ही चुना है। और फिर से: हमें इसकी दूसरी बाइट का अनुमान लगाने के लिए 256 आवश्यक प्रयास करने होंगे। पासवर्ड मिलान होने तक प्रक्रिया को दोहराया जा सकता है। BEAST भी गुप्त कुकीज़ का चयन करने के लिए इस सिद्धांत का उपयोग करता है, और संशोधित अनुरोध हेडर ज्ञात डेटा के रूप में उपयोग किया जाता है। संभावित पात्रों को संकुचित करके चयन को तेज किया जाता है (सभी अनुरोध में उपयोग नहीं किया जा सकता है), साथ ही साथ कुकी का नाम मानकर।

गुप्त पेपल कुकी को डिक्रिप्ट करने में सिर्फ 103 सेकंड का समय लगा।

हमले का कार्यान्वयन

हालांकि, स्वयं भेद्यता और डिक्रिप्शन करने का एक अनुकूलित तरीका लंबे समय तक वर्णित किया गया है। एक हमले के लिए सभी आवश्यक शर्तों को लागू करने में BEAST डेवलपर्स वास्तव में सफल रहे:

1. पीड़ित के ब्राउज़र द्वारा शुरू किए गए नेटवर्क कनेक्शन को सुनने में सक्षम होना चाहिए;
2. हमलावर को पीड़ित के ब्राउज़र में एजेंट को इंजेक्ट करने में सक्षम होना चाहिए;
3. एजेंट को मनमाने ढंग से (अधिक या कम) HTTPS अनुरोध भेजने में सक्षम होना चाहिए;

सामग्री की शुरुआत में, मैंने पहले ही कहा था कि BEAST का एक महत्वपूर्ण हिस्सा तथाकथित एजेंट है, जो हमलावर को सर्वर (सुरक्षित प्रोटोकॉल का उपयोग करके) के लिए अनुरोध स्थानांतरित करने में सक्षम होगा। शोधकर्ताओं ने विभिन्न तकनीकों और ब्राउज़र प्लग-इन की एक सूची तैयार की है जो इस स्थिति को पूरा कर सकते हैं। जैसा कि यह निकला, उनमें से काफी कुछ हैं: जावास्क्रिप्ट XMLHttpRequest API, HTML5 WebSocket API, Flash URLRequest API, Java Applet URLConnection API और Silverlight WebClient API। हालांकि, पहले सन्निकटन में, उनमें से कुछ प्रतिबंधों की उपस्थिति के कारण अनुपयुक्त थे जो हमलों के कार्यान्वयन को बाधित करते हैं। परिणाम केवल HTML5 WebSocket API, Java URLConnection API और Silverlight WebClient API है। फिलहाल जब शोधकर्ताओं ने विक्रेताओं को अपने बग की सूचना दी, तो उनके हाथ में एचटीएमएल 5 वेबसॉकेट के आधार पर काम करने वाला एजेंट था। लेकिन यह तकनीक लगातार विकसित हो रही है, और प्रोटोकॉल में लगातार बदलाव हो रहा है। नतीजतन, काम करने वाले एजेंट कॉर्न ने काम करना बंद कर दिया। BEAST का वर्तमान संस्करण, जिसे लोग जनता के सामने प्रस्तुत करते हैं, में जावास्क्रिप्ट / जावा में लिखा गया एक एजेंट और एक नेटवर्क स्नैफर होता है।
उपयोगकर्ता को एक एप्लेट या जावास्क्रिप्ट तैनात करना वास्तव में इतना मुश्किल काम नहीं है। लेकिन एक छोटी सी बारीकियां बनी रहती हैं - स्क्रिप्ट या एप्लेट के लिए पीड़ित द्वारा स्थापित कनेक्शन पर डेटा भेजने में सक्षम होने के लिए, एसओपी प्रतिबंध (समान-मूल नीति, डोमेन प्रतिबंध नियम) को बायपास करना आवश्यक है। यह कुछ क्लाइंट-साइड प्रोग्रामिंग भाषाओं, जैसे कि जावास्क्रिप्ट के लिए एक महत्वपूर्ण सुरक्षा अवधारणा है। नीति एक साइट के पृष्ठों पर स्थित प्रतिबंधों के बिना एक-दूसरे के तरीकों और गुणों तक पहुंचने की अनुमति देती है, लेकिन विभिन्न साइटों पर पृष्ठों के लिए अधिकांश तरीकों और गुणों तक पहुंच को रोकती है। सीधे शब्दों में कहें, एक पृष्ठ पर चलने वाला ग्राहक वांछित साइट (Paypal.com का कहना है) के लिए अनुरोध करने में सक्षम नहीं होगा। एसओपी नीति को दरकिनार करने के लिए, लेखकों ने जावा वर्चुअल मशीन में 0day भेद्यता पाई और इसके लिए एक काम करने वाला स्पूफ लिखा। बस यह मत सोचो कि यह आपको मौजूदा कुकीज़ पढ़ने की अनुमति देता है। यदि ऐसा था, तो एन्क्रिप्टेड ट्रैफ़िक के साथ यह सब उपद्रव क्यों था? एसओपी को बायपास करने के लिए विभाजन का उपयोग करके, आप अनुरोध भेज सकते हैं और सर्वर प्रतिक्रियाओं को पढ़ सकते हैं (नए कुकीज़ के साथ प्रतिक्रियाएं सहित), लेकिन आप मौजूदा कुकीज़ को नहीं पढ़ सकते हैं जो ब्राउज़र में संग्रहीत हैं। डेवलपर्स अपने ब्लॉग पर एक एजेंट बनाने की पूरी कहानी साझा करते हैं।

सम्मान

अंत में, मैं उन शोधकर्ताओं के भारी काम को नोट करना चाहता हूं जो न केवल दस साल पहले हर किसी द्वारा भुला दी गई भेद्यता का उपयोग करने में कामयाब रहे, बल्कि अपनी उपयोगिता बनाने के लिए बहुत सारे काम भी किए। इस सामग्री के भाग के रूप में, हमने मुख्य विचार को व्यक्त करने की कोशिश करते हुए, उपयोग की जाने वाली तकनीकों के विवरण को बहुत सरल किया है। लेकिन हमें वास्तव में शोधकर्ताओं से विस्तृत दस्तावेज पढ़ने में मज़ा आया, जिसमें वे लागू हमले के बारे में विस्तार से बात करते हैं। अच्छा काम!

---

समस्या का परिमाण

तो आपदा का पैमाना क्या है? या दूसरे शब्दों में - कौन असुरक्षित है? TLS1.0 का उपयोग करने वाली लगभग कोई भी वेबसाइट, जो सबसे सामान्य सुरक्षा प्रोटोकॉल है। यह मजेदार है कि BEAST के साथ यह सब होने के बाद, कई ने प्रोटोकॉल के नए संस्करणों - टीएलएस 1.1 और उच्चतर में रुचि दिखाना शुरू कर दिया। लेकिन अब कितने साइट इन प्रोटोकॉल का समर्थन करते हैं? हाँ, लगभग कोई नहीं! चित्रण देखिए। भले ही टीएलएस 1.1 पहले से ही पांच साल पुराना है, इकाइयां इसका उपयोग करती हैं!



एक और सवाल: अपनी सुरक्षा कैसे करें? वास्तव में, यह आतंक से कोई मतलब नहीं है - अधिकांश ब्राउज़रों में भेद्यता पहले से ही तय की गई है। लेकिन अगर व्यामोह प्रबल होता है, तो आप ब्राउज़र (TLS 1.0 और SSL 3.0) में असुरक्षित प्रोटोकॉल और उसी समय जावा को निष्क्रिय करने का प्रयास कर सकते हैं। हालांकि, इस मामले में यह बहुत आश्चर्य की बात नहीं है कि कई साइटें काम करना बंद कर देंगी।

---

हैकर पत्रिका, नवंबर (11) 154
सामूहिक मन ।

हैकर की सदस्यता लें

• 1 999 पी। पेपर विकल्प के 12 नंबरों के लिए
• 1249 आरयूआर iOS / iPad की वार्षिक सदस्यता के लिए (Android रिलीज़ जल्द ही आ रहा है!)
• एंड्रॉइड पर हैकर