नवीनतम प्रोजेक्ट ज़ीरो ब्लॉग पोस्ट में, टीम ने सैमसंग की रीयल-टाइम कर्नेल सुरक्षा को बायपास करने का एक तरीका खोजा है, जिसे नॉक्स हाइपरवाइज़र कहा जाता है।
Google की प्रोजेक्ट ज़ीरो टीम ने कई कारनामों का सत्यापन किया है जो कथित रूप से सुरक्षित सैमसंग नॉक्स सुरक्षा सूट चलाने वाले सैमसंग के फोन पर हमला करने में सक्षम बनाता है। ब्लॉग नोट करता है कि सभी कमजोरियाँ सैमसंग को दे दी गई हैं, जिन्होंने वास्तव में जनवरी सॉफ़्टवेयर अपडेट में उनके लिए फ़िक्सेस जारी किए हैं।
पृष्ठभूमि
सैमसंग द्वारा पेश किए गए सैमसंग नॉक्स सुरक्षा सॉफ्टवेयर सूट के हिस्से के रूप में, सॉफ्टवेयर का एक टुकड़ा है जो एंड्रॉइड एप्लिकेशन और कर्नेल के बीच बैठता है जिसे a कहा जाता है सूत्र. इसका उपयोग एंड्रॉइड डिवाइसों को और अधिक सुरक्षित करने के लिए एक अतिरिक्त परत के रूप में किया जा सकता है। सैमसंग नॉक्स हाइपरवाइज़र को "कहा जाता है"वास्तविक समय कर्नेल सुरक्षा"या संक्षेप में आरकेपी, जैसा कि मैं इस लेख के बाकी हिस्सों में इसका संदर्भ दूंगा।
एंड्रॉइड सॉफ़्टवेयर स्टैक में कर्नेल आरकेपी के नीचे बैठता है, और डिवाइस पर चलने वाले एप्लिकेशन शीर्ष पर बैठते हैं। आरकेपी के पीछे का विचार डिवाइस के लिए सुरक्षा की एक अतिरिक्त परत प्रदान करना है क्योंकि सभी अनुरोध (मेमोरी और अन्य संसाधन) कर्नेल के अनुप्रयोगों को पहले नॉक्स से गुजरना पड़ता है, जो यह पता लगाने की कोशिश करता है कि कोई एप्लिकेशन कुछ कर रहा है या नहीं नहीं करना चाहिए. आरकेपी संवेदनशील जानकारी को छिपाने के लिए एक अतिरिक्त परत के साथ अस्पष्टता के माध्यम से सुरक्षा भी प्रदान करता है जिसका उपयोग एप्लिकेशन डिवाइस से छेड़छाड़ करने के लिए कर सकता है।
ब्लॉग पोस्ट में काफी गहराई से बताया गया है कि एंड्रॉइड मेमोरी, आरकेपी और ऑपरेटिंग सिस्टम सामान्य रूप से कैसे काम करते हैं, इसलिए मैंने जो खोजा गया था उसका त्वरित अवलोकन देने के लिए इसे संक्षिप्त और सरल बनाया है। हालाँकि, यदि आपके पास समय हो तो मैं आपको पूरा लेख पढ़ने के लिए प्रोत्साहित करता हूँ, क्योंकि यह बहुत ज्ञानवर्धक है।
शोषण #1:
KASLR या कर्नेल एड्रेस स्पेस लेआउट रैंडमाइजेशन बूट पर यादृच्छिक मात्रा द्वारा मेमोरी में कर्नेल कोड के स्थान को बदलने की प्रक्रिया है। हर बार डिवाइस को बूट करने पर कर्नेल को एक अलग एड्रेस स्पेस (मेमोरी में क्षेत्र) में लोड किया जाता है। विचार यह है कि इस पर हमला करने के लिए कर्नेल कोड कहां स्थित है, यह पता लगाना कठिन बना दिया जाए क्योंकि प्रत्येक बूट के बाद कर्नेल कोड मेमोरी में यादृच्छिक मात्रा में "शिफ्ट" हो जाता है। भावी हमलावरों को रोकने के लिए यह एक बेहतरीन कदम लगता है, लेकिन हाल ही में अनुसंधान दिखाया है कि आप वास्तव में सॉफ़्टवेयर बग या भेद्यता की आवश्यकता के बिना इसे हरा सकते हैं, क्योंकि केएएसएलआर को स्थानीय हमलावरों के खिलाफ मजबूत तरीके से लागू करना वास्तव में बहुत कठिन है।
आरकेपी सॉफ्टवेयर के मामले में, केएएसएलआर को बायपास करने की क्षमता वास्तव में ऊपर उल्लिखित शोध की तुलना में सरल है। सभी एंड्रॉइड डिवाइसों की मेमोरी को पॉइंटर्स द्वारा संदर्भित किया जाता है और डिवाइसों को हमले से बचाने के लिए, जब भी एंड्रॉइड डिवाइस प्रिंट या आउटपुट करते हैं (चाहे स्क्रीन पर हों या लॉग या डिबगिंग के लिए फ़ाइल करने के लिए), पॉइंटर्स संदर्भ अज्ञात हैं, - जिससे यह पता लगाना असंभव हो जाता है कि पढ़ते समय पॉइंटर वास्तव में कहाँ इंगित करता है आउटपुट.
मेमोरी पॉइंटर्स को एक सड़क चिह्न की तरह सोचें जो किसी स्थान की ओर इशारा करता है और गुमनाम करने को उसे धुंधला करने के रूप में सोचें। टेलीविज़न की तरह, फिल्मांकन के बाद अज्ञातीकरण किया जाता है, एंड्रॉइड भी इस अज्ञातीकरण को आउटपुट समय पर लागू करता है और केवल तभी जब अज्ञातीकरण सही ढंग से कॉन्फ़िगर किया गया हो, और लेखक का कहना है उसके सामने आए प्रत्येक उपकरण में पॉइंटर एनोनिमाइजिंग को सही ढंग से कॉन्फ़िगर किया गया है. ऐसा लग सकता है कि इसे तोड़ना बहुत कठिन है, लेकिन आपको बस एक सूचक (सड़क चिन्ह के बारे में सोचें) ढूंढना है जो अज्ञात न हो (धुंधला हो) कर्नेल डेवलपर द्वारा (सावधान रहें कि यह आपका औसत एंड्रॉइड ऐप डेवलपर नहीं है) जब पॉइंटर लॉग या अन्य स्थान पर लिखा जाता है। स्क्रीन या ए फ़ाइल।
इसलिए यदि आप कोई ऐसा सूचक पा सकते हैं जो अज्ञात नहीं था, तो आप दोनों के बीच अंतर के रूप में कर्नेल के यादृच्छिक पता बदलाव की गणना कर सकते हैं। दिलचस्प बात यह है कि लेखक को कर्नेल में एक शोषक सूचक नहीं मिला, लेकिन उसने इसे आरपीके के अंदर पाया जहां डेवलपर्स डिबग (लॉगिंग) आउटपुट में एक पॉइंटर को अज्ञात करना भूल गए, जो कि एक तरीके से आया टाइपो. एंड्रॉइड में पॉइंटर्स को अज्ञात करने के लिए आपको एक विशेष कोड का उपयोग करना होगा और यह पता चला है कि आरपीके डेवलपर्स ने गलती से एक का उपयोग किया है निचला अक्षर 'k' एक के बजाय अपरकेस 'K'. इसलिए कर्नेल कोड की यादृच्छिक बदलाव मात्रा का पता लगाना और उस पर हमला करना अपेक्षाकृत सरल था।
शोषण #2:
अगला कारनामा थोड़ा अधिक जटिल है: सैमसंग नॉक्स दुर्भावनापूर्ण कोड को रोकने के लिए डिवाइस की मेमोरी में नियमों का एक सेट लागू करके आपके डिवाइस की सुरक्षा करता है। नियम इस प्रकार हैं:
- कर्नेल के कोड को छोड़कर, सभी पृष्ठ (मेमोरी में कोड), "विशेषाधिकार प्राप्त निष्पादन कभी नहीं" के रूप में चिह्नित हैं (मतलब यहां कोड कभी नहीं चल सकता)
- कर्नेल डेटा पेज (मेमोरी में प्रोग्राम द्वारा उपयोग किया गया डेटा) कभी भी निष्पादन योग्य के रूप में चिह्नित नहीं होते हैं (इसलिए यहां कोड कभी नहीं चल सकता है)
- कर्नेल कोड पेज (मेमोरी में कोड) को कभी भी लिखने योग्य चिह्नित नहीं किया जाता है (इसलिए कोई भी दुर्भावनापूर्ण कोड इसे बदल नहीं सकता है)
- सभी कर्नेल पृष्ठों को चरण 2 अनुवाद तालिका में केवल-पढ़ने के लिए चिह्नित किया गया है (वह तालिका जो एप्लिकेशन और कर्नेल के बीच स्थित है ताकि एप्लिकेशन को वास्तविक मेमोरी स्थानों के बारे में जानने से रोका जा सके)
- सभी मेमोरी अनुवाद प्रविष्टियों को अनुप्रयोगों के लिए केवल-पठन के रूप में चिह्नित किया गया है।
हम नियम 3 पर ध्यान केंद्रित करेंगे क्योंकि यहीं पर लेखक को उपरोक्त नियमों के कार्यान्वयन में समस्या मिली। आरपीके वास्तव में कर्नेल के लिए मेमोरी को रीड-ओनली के रूप में चिह्नित करता है, हालांकि केएएसएल की निगरानी में एक छेद की खोज की गई, जिसके कारण कथित तौर पर "केवल पढ़ने योग्य" अनुभाग में कोड लिखना. बूट समय पर कर्नेल के स्थान को अस्पष्ट करने के लिए कर्नेल को मेमोरी आवंटित की जाती है, लेकिन मेमोरी की यह मात्रा कर्नेल के टेक्स्ट सेगमेंट से बहुत बड़ी होती है। बड़ी मात्रा में मेमोरी आवंटित करने से वास्तविक कर्नेल कोड को ढूंढना बहुत कठिन हो जाता है जो कहीं भी हो सकता है, और जैसा कि हमने ऊपर देखा, यह डिवाइस के प्रत्येक बूट पर यादृच्छिक रूप से स्थानांतरित हो जाता है।
लेखक यह पुष्टि करने में सक्षम था कि कर्नेल द्वारा उपयोग की गई मेमोरी को वास्तव में "केवल पढ़ने के लिए" के रूप में चिह्नित किया गया था, हालांकि कर्नेल को छिपाने के लिए उपयोग की जाने वाली बड़ी मात्रा में मेमोरी का बाकी हिस्सा था नहीं "केवल पढ़ने योग्य" के रूप में चिह्नित। ऐसा इसलिए है क्योंकि KASLR स्लाइड को लागू करने के बाद RKP केवल कर्नेल के टेक्स्ट वाले क्षेत्र की सुरक्षा करता है।
शोषण #3
तीसरे कारनामे में लेखक स्मृति के दूसरे क्षेत्र तक पहुंचने में सक्षम था जिसे केवल पढ़ने तक ही सीमित रखा जाना चाहिए। आरकेपी मेमोरी की सुरक्षा करता है और इसका उपयोग करता है हाइपरवाइज़र कॉन्फ़िगरेशन रजिस्टर (एचसीआर) कुंजी कर्नेल संचालन को नियंत्रित करने के लिए। एचसीआर का उद्देश्य वैध और वास्तविक कर्नेल संचालन को रजिस्टरों तक पहुंचने और दुर्भावनापूर्ण हमलों को रोकने की अनुमति देना है। यह वर्चुअलाइजेशन सुविधाओं को नियंत्रित करने वाले रजिस्टरों पर की गई कॉल की जांच करके ऐसा करता है। एचसीआर को विशिष्ट संचालन को अवरुद्ध करने के लिए कॉन्फ़िगर किया गया है जिसे सामान्य रूप से आरकेपी को यह चुनने की अनुमति दी जाएगी कि अनुरोध को अनुमति दी जाए या अस्वीकार किया जाए।
इस कारनामे में एचसीआर का नियंत्रण था दो रजिस्टरों को कवर नहीं करना वह बहुत महत्वपूर्ण साबित हुआ. लेखक ने एआरएम संदर्भ मैनुअल को गहराई से खोजा और पाया कि पहले रजिस्टर ने उसे मूल रूप से अनुप्रयोगों के लिए आरकेपी को बंद करने की अनुमति दी थी। "EL1 के लिए सिस्टम कंट्रोल रजिस्टर (SCTLR_EL1) मेमोरी सिस्टम सहित सिस्टम पर शीर्ष-स्तरीय नियंत्रण प्रदान करता है।" एक आदर्श दुनिया में एप्लिकेशन उस मेमोरी का उपयोग करेगा जिसे आरकेपी के माध्यम से मैप किया गया था ताकि आरकेपी यह नियंत्रित कर सके कि एप्लिकेशन किस तक पहुंच सकता है। हालाँकि, इस रजिस्टर को बंद करने से इसकी अनुमति मिल गई आरकेपी को निष्क्रिय किया जाएगा आरकेपी स्थापित होने से पहले डिवाइस जिस तरह से चलता था उसे प्रभावी ढंग से वापस करके - जिसका अर्थ है कि डिवाइस को आरकेपी द्वारा प्रदान की गई अतिरिक्त सुरक्षा के बिना भौतिक मेमोरी में मैप किया गया है। बदले में इसका मतलब यह था कि लेखक उस मेमोरी को पढ़ और लिख सकता है जो आरकेपी सॉफ़्टवेयर द्वारा मूल रूप से और सही ढंग से अवरुद्ध थी।
दूसरा रजिस्टर जो छूट गया था, उसका प्रभाव अधिक सूक्ष्म था, लेकिन अंततः सुरक्षा के लिए उतना ही विनाशकारी था। EL1 के लिए अनुवाद नियंत्रण रजिस्टर (TCR_EL1) रजिस्टर सीधे मेमोरी की मात्रा से संबंधित है जिसके साथ एक एप्लिकेशन काम करता है जिसे पेज कहा जाता है। आरकेपी को 4kb के पृष्ठ आकार में हार्डकोड किया गया है क्योंकि AARCH64 लिनक्स कर्नेल (जैसे एंड्रॉइड) 4KB के अनुवाद आकार का उपयोग करते हैं। विचाराधीन रजिस्टर (TCR_EL1) एआरएम चिपसेट को उस मेमोरी के आकार पर सेट करता है जिसे वापस किया जाना है। यह पता चला है कि यह रजिस्टर एचसीआर द्वारा संरक्षित नहीं है और इसलिए एक हमलावर इसे बदल सकता है क्योंकि लेखक ने इसे 64kb पृष्ठ आकार में बदल दिया है।
इसका मतलब यह है कि जब आरकेपी द्वारा अनुरोध पूरा किया जाता है, तो पहुंच योग्य मेमोरी की वास्तविक मात्रा अब 4kb के बजाय 64kb है। इसका कारण यह है कि एआरएम चिपसेट अभी भी पृष्ठ आकार को नियंत्रित करता है और इसे एक्सप्लॉइट द्वारा 64kb पर सेट किया गया था। चूँकि आरकेपी मेमोरी को लिखे जाने से बचाता है, शोषण #2 में सूचीबद्ध नियमों के भाग के रूप में, मेमोरी वास्तव में अभी भी सुरक्षित है। लेकिन यहां एक समस्या है - चूंकि आरकेपी को 4kb पर हार्डकोड किया गया है, इसलिए रजिस्टर अपडेट होने पर यह 64kb पृष्ठ आकार में नहीं बदलता है, इसलिए केवल प्रथम 4kb मेमोरी सुरक्षित है हमलावर को ऐसा करने की अनुमति देना शेष 60kb के साथ वह जो चाहे.
शोषण #4
लेखक द्वारा दिखाया गया आखिरी कारनामा मेमोरी को संदर्भित करना है जहां आरकेपी सॉफ्टवेयर है, इसलिए हमलावर आरकेपी सॉफ्टवेयर पर ही हमला कर सकता है। इस प्रकार के हमले को रोकने के लिए एक तरकीब जिसका उपयोग लिनक्स कर्नेल भी करते हैं, वह है अपने प्रोग्राम को वर्चुअल मेमोरी एड्रेस स्पेस से अनमैप करना ताकि कोई भी एप्लिकेशन उस पर हमला न कर सके क्योंकि वे इसका संदर्भ नहीं दे सकते।
याद रखें कि मेमोरी सभी पॉइंटर्स और तालिकाओं के बारे में है जो भौतिक मेमोरी को वर्चुअल मेमोरी में मैप करती है। इस प्रकार के हमले में सामान्य रक्षा के अनुसार, आरकेपी खुद को अनमैप कर लेता है ताकि उस पर हमला न किया जा सके। हालाँकि, जहां कर्नेल ऐसी क्षमताएं प्रदान नहीं करता है, आरकेपी मेमोरी के एक टुकड़े को मैप करने और पढ़ने/लिखने के रूप में चिह्नित करने की अनुमति देता है। एकमात्र जांच यह है कि यह अंतर्निहित कर्नेल नहीं है क्योंकि आरकेपी यह देखने के लिए कोई जांच नहीं करता है कि जिन पते को मैप करने का अनुरोध किया जा रहा है वह वह क्षेत्र है जहां आरकेपी स्वयं मेमोरी में रहता है। मूलतः, आरकेपी स्वयं को पुनः मैप करने की अनुमति देता है उस पता स्थान पर वापस जाएं जिसे एप्लिकेशन एक्सेस कर सकते हैं और एक पक्ष के रूप में प्रभावित कर सकते हैं मेमोरी स्वचालित रूप से पढ़ने/लिखने के रूप में चिह्नित हो जाती है इसलिए एक हमलावर अब मेमोरी का उपयोग अपनी इच्छानुसार कर सकता है।
निष्कर्ष
ऊपर सूचीबद्ध चार कारनामों के साथ सबसे बड़ा मुद्दा यह है कि लेखक ने उल्लेख किया है कि बेस एंड्रॉइड कर्नेल में कार्यों की कमी के कारण इन्हें निष्पादित करना कितना मुश्किल होगा। विडंबना यह है कि सुरक्षित आरकेपी हाइपरवाइज़र ने हमलों को अंजाम देने के लिए आवश्यक सभी उपकरण प्रदान किए। इससे पता चलता है कि कभी-कभी नेक इरादे वाला सॉफ़्टवेयर हल करने की बजाय अधिक समस्याएं पैदा करता है और हम भाग्यशाली हैं कि हमारे पास ऐसे लोग हैं गैल बेनियामिनी की तरह अपने हाथ गंदे करने और यह जांचने को तैयार हैं कि दस्तावेज़ वास्तव में सॉफ़्टवेयर से मेल खाता है करता है।
हालाँकि ये कारनामे डरावने लगते हैं और नॉक्स को बहुत कमजोर बनाते हैं, मैं सभी को आश्वस्त करना चाहूंगा कि ये सभी मुद्दे हल हो गए हैं जनवरी अद्यतन में तय किया गया सैमसंग से. इसके अलावा, इन कारनामों के लिए एआरएम प्रोसेसर और प्रोग्रामिंग की बहुत गहरी समझ की आवश्यकता होती है, इसलिए इन कारनामों का उपयोग करने में प्रवेश की बाधा बहुत अधिक है।
स्रोत: प्रोजेक्ट जीरो