मोबाइल एसडीके पर भरोसा करें

सबसे लोकप्रिय एनपीएम पुस्तकालय में हाल ही में पिछले दरवाजे की कहानी ने कई लोगों को यह सोचने के लिए प्रेरित किया है कि हम तीसरे पक्ष के कोड पर कितना भरोसा करते हैं और हम अपनी परियोजनाओं में इसका उपयोग कितना साहसपूर्वक करते हैं (जिससे संभवतः हमारे उत्पादों के उपयोगकर्ता प्रतिस्थापन करते हैं)।

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

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

एसडीके सुरक्षा

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

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

यह वास्तव में कैसे हो सकता है? चलो एक कदम पीछे लेते हैं और बुनियादी नेटवर्क चीजों और उनके दुरुपयोग के बारे में बात करते हैं।

नेटवर्क

मैं आपको चेतावनी देता हूं कि मेरे स्पष्टीकरण 100% सटीक और विस्तृत नहीं होंगे। मेरा लक्ष्य सार को व्यक्त करना है, इसलिए मैं सब कुछ कुछ सरल रूप में प्रस्तुत करूंगा। यदि आप विवरण में रुचि रखते हैं, तो मेरा सुझाव है कि आप मेरे ब्लॉग को देखें या विषय को स्वयं देखें।

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

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

पहले, सब कुछ निम्नानुसार काम करता था। जब आप किसी प्रोटोकॉल को निर्दिष्ट किए बिना एड्रेस बार में "google.com" दर्ज करते हैं, तो डिफ़ॉल्ट रूप से ब्राउज़र ने HTTP के माध्यम से आपका अनुरोध भेजा है। लेकिन चूंकि Google सर्वर HTTPS के माध्यम से संचार करना पसंद करता है, इसके जवाब में आपको उपसर्ग "https: //" के साथ एक नया लिंक (रीडायरेक्ट) प्राप्त हुआ। यहां चार्ल्स प्रॉक्सी (एक HTTP / HTTPS ट्रैफिक मॉनिटरिंग टूल) से एक स्क्रीन है जो इसे प्रदर्शित करता है:



हालाँकि, नया लिंक स्वयं HTTP प्रोटोकॉल के माध्यम से भेजा गया था। यह समझना आसान है कि यहां क्या गलत हो सकता है: अनुरोध और प्रतिक्रिया दोनों को HTTP के माध्यम से प्रेषित किया जाता है, जिसका अर्थ है कि आप उदाहरण के लिए, प्रतिक्रिया पैकेट को रोक सकते हैं और इसमें स्थान URL को "http: //" से बदल सकते हैं। इस सरल प्रकार के हमले को एसएसएल स्ट्रिप कहा जाता है। आज तक, ब्राउज़र पहले से ही थोड़े अलग तरीके से काम करना सीख चुके हैं। लेकिन समझ में आता है कि एक एसएसएल स्ट्रिप हमारे लिए क्या उपयोगी है।

कई बार आप OSI नेटवर्क मॉडल को याद रख सकते हैं। मैं उसे असहनीय उबाऊ के रूप में माना जाता है। लेकिन बाद में उन्हें पता चला कि, विचित्र रूप से पर्याप्त, OSI मॉडल का अस्तित्व ही नहीं है और यह उपयोगी भी हो सकता है।

हम इस पर विस्तार से विचार नहीं करेंगे। मुख्य बात समझने के लिए: सब कुछ में कई परतें होती हैं जो अलग-अलग चीजों के लिए जिम्मेदार होती हैं और एक ही समय में एक दूसरे के साथ निरंतर संपर्क में होती हैं।

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



समस्या यह है कि हैकर अनुरोध का तेजी से जवाब दे सकता है: "हां, मुझे सभी पैकेट भेजें।" इसे ARP स्पूफिंग या ARP कैश पॉइज़निंग कहा जाता है। इस स्थिति में, इंटरनेट के साथ आपकी सहभागिता की योजना इस में बदल जाती है:



सभी पैकेट अब हैकर के उपकरण से होकर गुजरते हैं, और यदि ट्रैफ़िक को एन्क्रिप्ट नहीं किया जाता है, तो यह पढ़ने और लिखने में सक्षम होगा। HTTPS के मामले में, संभावना कम है, लेकिन आप ट्रेस कर सकते हैं कि आप कौन से होस्ट एक्सेस कर रहे हैं।

दिलचस्प है, वास्तव में, समान शक्तियों में इंटरनेट और वीपीएन प्रदाता हैं। वे इंटरनेट के साथ आपकी बातचीत में मध्यस्थ हैं और उसी तरह एआरपी स्पूफिंग के संभावित खतरे को भी उठाते हैं।

मानव-मध्य दृष्टिकोण में ही कुछ नया नहीं है। लेकिन यह सब वास्तव में मोबाइल एसडीके पर कैसे लागू होता है?

मोबाइल की बारीकियां

CocoaPods एक मानक निर्भरता प्रबंधन उपकरण है जिसका उपयोग iOS विकास में किया जाता है। खुले स्रोत कोड के लिए कोकोपोड्स का उपयोग करना व्यावहारिक रूप से सुरक्षित माना जाता है - यह आमतौर पर GitHub पर होस्ट किया जाता है, आमतौर पर HTTPS या SSH के माध्यम से पहुंच प्राप्त करता है। हालाँकि, मैं HTTP लिंक के उपयोग के आधार पर एक भेद्यता खोजने में कामयाब रहा।

तथ्य यह है कि कोकोपोड्स बंद स्रोत कोड के साथ एसडीके को स्थापित करना संभव बनाता है, और आपको बस URL निर्दिष्ट करने की आवश्यकता है। कोई सत्यापन नहीं है कि ट्रैफ़िक एन्क्रिप्ट किया जाएगा, और कई एसडीके एक HTTP पते की पेशकश करते हैं।

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

यह विचार करना और भी दिलचस्प है कि गैर-संवेदी एसडीके की स्थापना कोकोआइड्स से कैसे नहीं होती है। उदाहरण के लिए, स्थानीयता मंच लें।



Docs.localytics.com पेज एन्क्रिप्टेड नहीं है। ऐसा लगता है कि इस मामले में यह उपेक्षित किया जा सकता है, क्योंकि यह सिर्फ दस्तावेज है। लेकिन ध्यान दें कि पृष्ठ, अन्य बातों के अलावा, बायनेरिज़ को डाउनलोड करने के लिए एक लिंक है। लिंक को एन्क्रिप्ट किया जा सकता है, लेकिन यह किसी भी सुरक्षा की गारंटी नहीं देता है: चूंकि पेज स्वयं HTTP के माध्यम से प्रेषित होगा, इसे इंटरसेप्ट किया जा सकता है और लिंक को अनएन्क्रिप्टेड के साथ बदल दिया जा सकता है। स्थानीय लोगों के डेवलपर्स को इस भेद्यता के बारे में सूचित किया गया था और यह पहले से ही तय किया गया है।

आप अन्यथा कर सकते हैं: HTTP से लिंक को न बदलें, लेकिन HTTPS को छोड़ दें, लेकिन पते को स्वयं बदलें। इसकी खोज करना बहुत मुश्किल होगा। इन दो लिंक को देखें:



उनमें से एक मेरा है। असली डेवलपर्स में से कौन सा है, और कौन सा नहीं है? समझने की कोशिश करो।

चेक का अभ्यास करें

तब मैंने MITM हमले का उपयोग करके SDK की सामग्री को बदलने के लिए वास्तविकता में प्रयास करके अपनी मान्यताओं का परीक्षण करने का निर्णय लिया। यह पता चला कि यह इतना मुश्किल नहीं है। मेरे सर्किट को बनाने और संचालित करने के लिए, मुझे सबसे सरल सार्वजनिक टूल सेट करने में कुछ ही घंटे लगे।



मैंने इंटरसेप्ट करने के लिए सामान्य रास्पबेरी पाई को सौंपा। स्थानीय नेटवर्क में शामिल, वह इसमें ट्रैफ़िक सुन सकता था। इंटरसेप्ट किए गए पैकेट में, उसे सबसे पहले, HTTP लिंक के साथ सभी HTTPS लिंक को बदलना होगा, और फिर सभी लोकल आईओएस .zip फाइलों को hack.zip फाइल से बदलना होगा। यह सब सरल हो गया और धमाके के साथ काम किया।



Trollface.jpg फ़ाइल परिणामी संग्रह में दिखाई दी, और लाइन "KrauseFx द्वारा संशोधित" Info.plist फ़ाइल में दिखाई दी। इस तरह के हमले के लिए कितना आवश्यक था? केवल दो शर्तें:

1. वे आपके नेटवर्क तक पहुंचने में कामयाब रहे (याद रखें कि इंटरनेट और वीपीएन प्रदाताओं के लिए यह बिल्कुल भी सवाल नहीं है)। हम कितनी कॉफी और होटल श्रृंखलाओं से जुड़ते हैं?
2. आरंभिक डाउनलोड अनएन्क्रिप्टेड है।

आप कहते हैं, "लेकिन मैं अभी ब्राउज़र में सिक्योर आइकन देख रहा हूं, जिसका अर्थ है कि मैं ठीक हूं।" और अगर आप अमेज़न पर हैं, तो सब कुछ ठीक होना चाहिए, है ना?

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



"सुरक्षित" आइकन, एक प्रसिद्ध साइट, कुछ भी नहीं दिखाती है। लेकिन अफसोस - केवल पहली नज़र में। एसडीके को डाउनलोड करने का लिंक बिना किसी उपसर्ग के इंगित किया गया है (न तो https: // और न ही http: //)। और उसी समय, यह उपयोगकर्ता को दूसरे होस्ट में ले जाना चाहिए। इसलिए, ब्राउज़र HTTPS से HTTP पर स्विच हो जाएगा। जैसा कि आप देख सकते हैं, यहाँ SDK डाउनलोड अनएन्क्रिप्टेड है! फिलहाल, अमेज़ॅन डेवलपर्स द्वारा भेद्यता पहले से ही तय की गई है, लेकिन यह वास्तव में एक जगह थी।

मुझे कहना होगा कि आधुनिक ब्राउज़र का विकास भी सुरक्षा मुद्दों पर ध्यान दिए बिना किया जाता है। उदाहरण के लिए, यदि आप HTTPS का उपयोग करके किसी पृष्ठ को लोड करते हैं, और किसी एक चित्र को HTTP लिंक के माध्यम से दर्शाया जाता है, तो Google Chrome आपको तथाकथित "मिश्रित सामग्री" के बारे में सूचित करेगा। लेकिन डाउनलोड के लिए ऐसा कोई सुरक्षा उपाय उपलब्ध नहीं कराया गया है: ब्राउज़र यह ट्रैक नहीं करते कि पेज पर दर्शाए गए डाउनलोड लिंक के लिए कौन सा प्रोटोकॉल ट्रिगर किया गया है। इसलिए, इस परियोजना के हिस्से के रूप में, मैंने ब्राउज़र डेवलपर्स को मिश्रित सामग्री पर नज़र रखने और इसके बारे में उपयोगकर्ताओं को सूचित करने के लिए अनुरोध के साथ लिखा था।

Apple आईडी डेटा चोरी

अब एक और समस्या पर नजर डालते हैं। IPhone उपयोगकर्ताओं को इस नियमित रूप से पॉप-अप विंडो से परिचित होना चाहिए:



बाईं ओर आपको दाईं ओर iOS का मूल संस्करण दिखाई देता है - मेरी प्रति। इसी तरह की विंडो को कैसे बनाना आसान है, इसके बारे में मैंने कुछ महीने पहले अपने ब्लॉग पर लिखा था। दृश्य को फिर से बनाने में 20 मिनट का समय लगा।

iPhone अक्सर iCloud प्रमाणीकरण डेटा का अनुरोध करता है, और उपयोगकर्ता के लिए, अनुरोध का कारण आमतौर पर अस्पष्ट रहता है। यूजर्स को इसकी आदत होती है कि वे अपने आप पासवर्ड डालते हैं। पासवर्ड के लिए कौन पूछ रहा है - ऑपरेटिंग सिस्टम या एप्लिकेशन - बस ध्यान में नहीं आता है।

यदि आपको लगता है कि यह ईमेल पता प्राप्त करना मुश्किल है, जिसके लिए Apple ID संलग्न है, तो आप अतिशयोक्ति करते हैं: यह संपर्क पुस्तक के माध्यम से और iCloud कंटेनर (यदि आपके पास iCloud एप्लिकेशन तक पहुंच है, जिसके बारे में आप पता लगा सकते हैं) इस आवेदन के UserDefaults से)। और सबसे सरल विकल्प उपयोगकर्ता को व्यक्तिगत रूप से अपना ईमेल दर्ज करने के लिए कहना है: सिद्धांत रूप में, यह भी उसे आश्चर्यचकित नहीं करना चाहिए, क्योंकि आईओएस में वास्तव में एक तरह की खिड़की है जो न केवल एक पासवर्ड, बल्कि एक ईमेल भी पूछती है।

मैंने सोचा: "क्या होगा अगर मैं एसडीके स्पूफिंग की मदद से मेरे पास मौजूद अनुरोध फॉर्म के इस कोड को लेता हूं, इसके साथ कई अलग-अलग एप्लिकेशनों में घुसना करता हूं ताकि उनके साथ सभी iCloud पासवर्ड चुरा सकें?" यह कार्य कितना कठिन है?



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

अब ब्राउजर खोलें, Amazon Web Services पर जाएं। AWS मोबाइल SDK पेज ढूंढें और डाउनलोड लिंक का पालन करें। डाउनलोड किए गए बाइनरी को अनपैक करें और एक्सकोड में हमारी परियोजना में सभी रूपरेखाओं को खींचें। फिर हम पुस्तकालयों का आयात करते हैं। हमें किसी भी कोड को कॉल करने की आवश्यकता नहीं है - यह पर्याप्त है कि इसे डाउनलोड किया जाएगा। मैं ध्यान देता हूं कि पूरी प्रक्रिया के दौरान Xcode ने कोई चेतावनी नहीं दी थी।

क्या होता है जब आवेदन recompiling? स्क्रीन पर विंडो की एक ही प्रति दिखाई देती है, जो मुझे आईट्यून्स स्टोर में लॉग इन करने के लिए प्रेरित करती है। मैं पासवर्ड दर्ज करता हूं, विंडो गायब हो जाती है। उसी समय एप्लिकेशन लॉग को देखते हुए, मैं देखता हूं कि मैंने जो पासवर्ड दर्ज किया है, वह तुरंत इसमें प्रदर्शित होता है - ऐप्पल आईडी डेटा अवरोधन पूरा हो गया है। इस डेटा को सर्वर पर कहीं भेजना आसान होगा।

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

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

प्रबंधन अधिग्रहण

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

मैंने सोचा, "आईओएस एसडीके क्या मैं इसके लिए उपयोग कर सकता हूं?" एक ऐसी सेवा है जो SDK को कर्ल कमांड और एक HTTP लिंक के साथ sh कमांड पर पुनर्निर्देशित आउटपुट प्रदान करती है। यही है, आपका टर्मिनल शेल स्क्रिप्ट को डाउनलोड और चलाएगा।



अपने आप से, यह स्थापना विधि आपको पहले से ही जोखिम में डालती है, ऐसा न करें। लेकिन इस मामले में, HTTP प्रोटोकॉल का भी उपयोग किया गया था। फिर क्या करना संभव है?



मान लीजिए आप एक उपयोगकर्ता हैं। आप आधिकारिक प्रलेखन पृष्ठ पर जाते हैं। इस तथ्य पर ध्यान दें कि पृष्ठ HTTPS प्रोटोकॉल के साथ एन्क्रिप्टेड है - महान! आप कमांड को कॉपी करते हैं, इसे घर पर चलाते हैं। कमांड को कुछ सेकंड के भीतर निष्पादित किया जाता है। इस दौरान क्या हुआ है?

और इस समय के दौरान, मेरे रास्पबेरी पाई को शामिल करने वाला एक सरल हमला तंत्र काम करने में कामयाब रहा। उपयोगकर्ता द्वारा लोड किए गए अपडेटएसडीकेके शेल स्क्रिप्ट में मेरे स्वयं के कोड की एक छोटी छप थी। और अब मुझे SSH के माध्यम से आपके कंप्यूटर को दूरस्थ रूप से एक्सेस करने की अनुमति है, और आपके पास एक keylogger भी स्थापित है।



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

निष्कर्ष में

आपके साथ ऐसा होने की कितनी संभावना है? आखिरकार, डेवलपर्स अभी भी सुरक्षित वाई-फाई का उपयोग करने की कोशिश करते हैं, एक वीपीएन खरीदते हैं।

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

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

नवंबर 2017 में, मैंने अपना शोध किया और आईओएस के लिए शीर्ष 41 सबसे लोकप्रिय एसडीके में सूचीबद्ध कमजोरियों की उपस्थिति का विश्लेषण किया (Google और फेसबुक से एसडीके की गिनती नहीं की, वे सभी संरक्षित हैं)।



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

यह समझना महत्वपूर्ण है कि बंद अनुप्रयोगों के उपयोगकर्ता हमेशा अधिक जोखिम के अधीन होते हैं, जबकि खुले स्रोत अनुप्रयोगों के उपयोगकर्ता कम उपयोग करते हैं। आप जाँच नहीं कर सकते हैं कि कोई बंद अनुप्रयोग कैसे काम करता है। यह निर्धारित करना बेहद मुश्किल है कि क्या इसका सुरक्षित समाधान है। आप हैश और हैश रकम की तुलना कर सकते हैं, लेकिन ऐसा करके आप डाउनलोड की सफलता को सत्यापित कर पाएंगे। इसके विपरीत, आप खुले स्रोत उत्पादों को अच्छी तरह से, साथ और उस पार शोध कर सकते हैं, जिसका अर्थ है कि आप अपने आप को अधिक सुरक्षा प्रदान कर सकते हैं।

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

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

, : Mobius 22-23 , , .