स्वीडिश बैंकआईडी में गंभीर भेद्यता उपयोगकर्ता डेटा को उजागर करती है

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

मैं स्वयं स्वीडन में रहता हूं, तथा मेरे मस्तिष्क में हमेशा हैकर मानसिकता घूमती रहती है, इसलिए मैंने निर्णय लिया कि यह सुरक्षा अनुसंधान करने के लिए एक बहुत ही दिलचस्प क्षेत्र होगा।

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

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

बैंकआईडी प्रमाणीकरण प्रोटोकॉल

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

बैंकआईडी भी इससे अलग नहीं है और यह ऐसी सेवाओं के लिए दस्तावेज उपलब्ध कराता है, जिन्हें अब से रिलाइंग पार्टी (आरपी) के रूप में संदर्भित किया जाएगा, ताकि वे आसानी से बैंकआईडी के साथ अपने प्रमाणीकरण प्रवाह को एकीकृत कर सकें। https://www.bankid.com/en/utvecklare/guider/teknisk-integrationsguide/rp-introduktion .

बैंकआईडी के साथ उपयोगकर्ता को प्रमाणित करने के लिए दो मुख्य प्रवाहों का उपयोग किया जाता है:

• उसी डिवाइस पर प्रमाणीकरण करें

• किसी अन्य डिवाइस पर प्रमाणीकरण करें

  
  

हम जल्द ही इन दोनों पर फिर से विचार करेंगे, हालाँकि, दोनों प्रवाह RP द्वारा प्रमाणीकरण आदेश शुरू करने के लिए BankID के API को अनुरोध भेजने से शुरू होते हैं। इस पोस्ट अनुरोध में, RP को endUserIp पैरामीटर निर्दिष्ट करना होगा, जिसमें लॉग इन करने का प्रयास करने वाले उपयोगकर्ता का IP शामिल है, यह रिपोर्ट में बाद में महत्वपूर्ण होगा।

/auth API एंडपॉइंट कुछ इस तरह से प्रतिक्रिया देगा:

 HTTP/1.1 200 OK Content-Type: application/json { "orderRef":"131daac9-16c6-4618-beb0-365768f37288", "autoStartToken":"7c40b5c9-fa74-49cf-b98c-bfe651f9a7c6", "qrStartToken":"67df3917-fa0d-44e5-b327-edcc928297f8", "qrStartSecret":"d28db9a7-4cde-429e-a983-359be676944c" }

• orderRef एक पहचानकर्ता है जिसका उपयोग RP /collect एंडपॉइंट के विरुद्ध प्रमाणीकरण स्थिति की जांच करने के लिए कर सकता है और बाद में उस व्यक्ति से आवश्यक उपयोगकर्ता जानकारी प्राप्त कर सकता है
• autoStartToken एक टोकन है जिसका उपयोग आरपी द्वारा डीप लिंक बनाने के लिए किया जाता है, जिस पर क्लिक करने पर बैंकआईडी ऐप खुल जाएगा और उपयोगकर्ता को स्वयं को प्रमाणित करने के लिए संकेत मिलेगा ( यह वास्तव में महत्वपूर्ण होगा )

qrStartToken और qrStartSecret नीचे कवर किया जाएगा, लेकिन वे किए गए सुरक्षा अनुसंधान के लिए कड़ाई से महत्वपूर्ण नहीं हैं।

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

प्रमाणीकरण आवश्यकताओं में से, जिन पर यह पोस्ट ध्यान केंद्रित करेगी उन्हें प्रमाणपत्र नीतियां कहा जाता है, ये आरपी को बैंकआईडी को यह बताने की अनुमति देते हैं कि उपयोगकर्ता द्वारा दो प्रवाहों में से कौन सा चुना गया था।

एक ही डिवाइस पर प्रमाणीकरण

जब कोई उपयोगकर्ता उसी डिवाइस पर BankID का उपयोग करके प्रमाणित होना चुनता है, तो RP एक डीप लिंक बनाने के लिए autoStartToken का उपयोग करता है जो इस तरह दिखता है: bankid:///?autostarttoken=7c40b5c9-fa74-49cf-b98c-bfe651f9a7c6&redirect=https://service.com/login यह डीप लिंक तब उपयोगकर्ता के OS द्वारा उठाया जाता है और BankID एप्लिकेशन को सौंप दिया जाता है।

इस प्रवाह की जांच करते समय, एक ओपन रीडायरेक्ट भेद्यता पाई गई क्योंकि बैंकआईडी की ओर से redirect पैरामीटर का कोई सत्यापन नहीं है, मैं बाद में बताऊंगा कि यह अतिरिक्त बग सत्र अपहरण हमले को और भी अधिक शक्तिशाली क्यों बनाता है।

किसी अन्य डिवाइस पर प्रमाणीकरण

जब कोई उपयोगकर्ता किसी अन्य डिवाइस पर BankID का उपयोग करके प्रमाणीकृत होना चुनता है, तो RP qrStartToken और qrStartSecret उपयोग करके एक गतिशील QR कोड (उपर्युक्त /collect समापन बिंदु से अगले फ्रेम का डेटा प्राप्त करके) उत्पन्न करता है, जिसे उपयोगकर्ता द्वारा अपने मोबाइल BankID एप्लिकेशन का उपयोग करके स्कैन किया जा सकता है।

प्रमाणपत्र नीतियां

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

इनके अलावा, एक बार प्रमाणीकरण पूरा हो जाने पर, RP उस ipAddress प्राप्त कर सकता है जिसका उपयोग /collect API एंडपॉइंट से BankID के एप्लिकेशन को खोलने के लिए किया गया था। इसके बाद RP पर उपयोगकर्ता के आईपी पते के विरुद्ध इसकी जाँच की जानी चाहिए , यदि उसने "उसी डिवाइस पर प्रमाणीकरण" चुना है।

यह सुनिश्चित करने के लिए कि प्रमाणीकरण प्रवाह के साथ छेड़छाड़ नहीं की जा सकती, प्रमाणपत्र नीतियों के साथ-साथ ipAddress भी उपयोग किया जाना चाहिए ।

फिर भी, जबकि ये सुरक्षा उपाय लागू हैं, BankID उनके महत्व को रेखांकित करने में विफल रहता है और उन्हें उनके प्रदान किए गए उदाहरण कार्यान्वयन में भी सही ढंग से लागू नहीं करता है! https://github.com/BankID/SampleCode

सत्र निर्धारण बग

तो क्या होगा जब इस प्रोटोकॉल को सुरक्षित रूप से क्रियान्वित नहीं किया जाता?

जब मैंने पहली बार bankid:/// डीप लिंक देखा तो मैं अपने विश्वविद्यालय के आवेदन फॉर्म ब्राउज़ कर रहा था, जिसे BankID से लॉग इन करके एक्सेस किया जा सकता है। सबसे पहले, मैंने सोचा: अगर मैं यह डीप लिंक किसी को भेज दूं तो क्या होगा? इसलिए मैंने इसे अपने एक दोस्त को भेजा जिसने इस पर क्लिक किया, और मुझे आश्चर्य हुआ कि जब उसने BankID खोला, तो उसके सामने उसके सभी विश्वविद्यालय के आवेदन थे!

तभी मैंने बैंकआईडी के एपीआई पर गौर करना शुरू किया, अपना स्वयं का आरपी क्रियान्वित किया, तथा उन सभी चीजों के बारे में सीखा जो मैंने पहले बताई थीं।

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

मैं ऐसा कर सका क्योंकि:

• आरपी ने बैंकआईडी को प्रमाणपत्र नीतियां नहीं भेजीं, जिससे मेरे लिए डीप लिंक प्राप्त करना और उसे मोबाइल बैंकआईडी ऐप पर रिले करना संभव हो गया

• आर.पी. ने लिंक का अनुरोध करने वाले आई.पी. पते की तुलना उस आई.पी. पते से नहीं की जिसने प्रमाणीकरण पूरा कर लिया था

• आरपी ने “किसी अन्य डिवाइस पर प्रमाणीकरण” विकल्प चुने जाने पर भी लिंक प्रदान किया

  
  

जिसके कारण सत्र निर्धारण भेद्यता उत्पन्न हुई।

आक्रमण

आइए AmazingSevice AB नामक एक असुरक्षित सेवा की कल्पना करें, उन्होंने प्रदान किए गए नमूना कोड के बाद BankID प्रवाह को लागू किया है और इस तरह के कार्यान्वयन को https://amazingservice.se/login/bankid पर होस्ट कर रहे हैं।

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

इस तरह के अकाउंट टेकओवर में बहुत कम सोशल इंजीनियरिंग शामिल होती है क्योंकि एक बार पीड़ित लिंक पर क्लिक करता है, तो उसे तुरंत BankID खोलने के लिए कहा जाता है, जिससे हमलावर की साइट के "अज्ञात क्षेत्र" को छोड़कर, अधिक परिचित इंटरफ़ेस, BankID पर चला जाता है। इसके अतिरिक्त, पीड़ित को BankID एप्लिकेशन में जो प्रमाणीकरण अनुरोध दिखाई देगा, वह AmazingSevice AB द्वारा अनुरोधित किया जाता है, जिससे धोखाधड़ी वाले व्यवहार का पता लगाना असंभव हो जाता है।

एक बार जब पीड़ित प्रमाणित हो जाता है, तो हमलावर का सत्र पीड़ित के खाते में प्रमाणित हो जाता है, पीड़ित को बैंकआईडी में मौजूद ओपन रीडायरेक्ट भेद्यता का फायदा उठाकर और भी बेवकूफ बनाया जा सकता है, जिससे हमलावर redirect पैरामीटर को https://amazingservice.se/login/bankid के रूप में निर्दिष्ट कर सकता है। इससे पीड़ित को वैध सेवा वेबसाइट पर रीडायरेक्ट कर दिया जाएगा, जिससे उसे बस यह सोचना पड़ेगा कि प्रमाणीकरण सफल नहीं हुआ।

डेमो

मैं जिन कम्पनियों को रिपोर्ट करता था, उनमें से एक का उपयोग स्पष्ट कारणों से नहीं कर सका, इसलिए इसके स्थान पर डेमो में बैंकआईडी की डेमो सेवा को इसके प्रति संवेदनशील दिखाया गया है!

दाएं कोने में लिंक प्राप्त करने वाले पीड़ित का दृश्य है, यहाँ हमलावर की वेबसाइट पर जाकर सिम्युलेट किया गया है। एक बार जब पीड़ित लिंक पर जाता है, तो हमलावर का सर्वर हेडलेस ब्राउज़र खोलता है और bankid:/// लिंक को निकालता है जिसे फिर पीड़ित के फ़ोन पर रिले किया जाता है। BankID के ऐप में, आप “Test av BankID” देख सकते हैं जो BankID की डेमो साइट के लिए वैध स्रोत है। इसके अतिरिक्त, वीडियो की शुरुआत में, यह देखने के लिए एक VPN चालू किया जाता है कि प्रमाणीकरण के दौरान कोई IP पता जाँच नहीं की जा रही है। अंत में, यह देखना संभव है कि हमलावर के लैपटॉप पर, वह पीड़ित (जोहान जोहानसन) के रूप में लॉग इन है।

प्रभाव

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

मैंने जिन सेवाओं के बारे में इस कमज़ोरी की रिपोर्ट की थी, उनमें से एक सेवा मुझे स्वीडन के राष्ट्रीय CSIRT से संपर्क करवाने में सक्षम थी, क्योंकि यह समस्या बहुत व्यापक और गंभीर है। बातचीत अभी शुरू हुई है, इसलिए अगर आप अपडेट रहना चाहते हैं तो ट्विटर पर मुझे फ़ॉलो करें (X) @m4st3rspl1nt3r

उपचार

यदि आप सुरक्षित BankID RP API कार्यान्वयन के उदाहरण की तलाश कर रहे हैं, तो मैंने एक बनाया है जिसे आप Golang लाइब्रेरी के रूप में उपयोग कर सकते हैं या माइक्रोसर्विस के रूप में कस्टमाइज़ और तैनात कर सकते हैं। आप इसे यहाँ पा सकते हैं।

बैंकआईडी का जवाब

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

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

इसके अतिरिक्त, ओपन रीडायरेक्ट भेद्यता को ठीक करने की योजना भी बनाई गई है।

इस पर मेरी निजी राय यह है कि यदि आप ऐसे महत्वपूर्ण और अत्यधिक अपनाए गए प्रमाणीकरण प्रदाता को विकसित और संचालित करते हैं, जिसका उपयोग अक्सर बहुत संवेदनशील उपयोगकर्ता जानकारी की सुरक्षा के लिए किया जाता है, तो आपको अपने सुरक्षा तंत्र को ठीक से प्रलेखित करना चाहिए ताकि RP इसे सुरक्षित रूप से एकीकृत कर सकें। वैकल्पिक सुरक्षा सुविधाएँ पूरी तरह से बेकार हैं, अगर कोई डेवलपर कुछ सुविधाओं/मापदंडों को लागू न करके समय बचा सकता है तो यही होगा और हम इसके लिए RP पक्ष को दोष नहीं दे सकते। BankID को "एकीकरण की आसानी" बनाए रखने के लिए अपने पक्ष में अधिक से अधिक धोखाधड़ी-रोधी और सुरक्षा सुविधाएँ लाने की पूरी कोशिश करनी चाहिए, लेकिन यह भी सुनिश्चित करना चाहिए कि RP द्वारा लागू की जाने वाली किसी भी अतिरिक्त सुरक्षा सुविधा का ठीक से प्रलेखित किया जाए; वैकल्पिक नहीं बल्कि आवश्यक पर ध्यान दें।

सार्वजनिक खतरे में निजी कंपनी

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

यदि किसी को फेसबुक पर आपका अकाउंट टेकओवर मिल जाता है, तो आप कुछ तस्वीरें खो सकते हैं, यदि किसी को आपके देश के ईआईडी प्रदाता (अक्सर निजी) में कोई कमजोरी मिल जाती है, तो किसी के जीवन पर पड़ने वाले परिणाम अकल्पनीय हो सकते हैं।

अधिकाधिक यूरोपीय देश ईआईडी को अपना रहे हैं, और यूरोपीय संघ आने वाले वर्षों में अपनी स्वयं की ईआईडी शुरू करने की योजना बना रहा है (आप इसके बारे में यहां अधिक पढ़ सकते हैं)।

मेरी आशा है कि विनियामक ईआईडी प्रदाताओं को पूर्णतः सार्वजनिक संस्थाओं द्वारा विकसित और नियंत्रित करने पर जोर देंगे, संभवतः ऐसी प्रणालियों के लिए ओपन सोर्स होना तथा सुरक्षा खामियों के लिए नियमित रूप से उनका ऑडिट किया जाना आवश्यक होगा।

यदि सॉफ्टवेयर के ऐसे महत्वपूर्ण टुकड़ों को किसी निजी कंपनी द्वारा विकसित किया गया है, तो हम उन्हें अपने समाज में सुरक्षित रूप से कैसे स्वीकार कर सकते हैं?

अग्रगामी अनुसंधान

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

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

तब तक, ग्रह को हैक करो!