Optus डेटा ब्रीच कैसे हुआ और इससे कैसे बचें?

1. परिचय#

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

यह लेख निम्नलिखित प्रश्नों पर ध्यान केंद्रित करेगा:

• डेटा ब्रीच का कारण बनने वाली Optus के पास कौन सी सुरक्षा खामियां थीं?
• सुरक्षा ब्रीच से बचने के लिए Optus कौन से बचाव के तरीके इस्तेमाल कर सकता था?

2. Optus डेटा ब्रीच का कारण बनने वाली सुरक्षा खामियां#

निम्नलिखित में, आप Optus में डेटा ब्रीच की 5 सुरक्षा खामियां पाएंगे।

2.1 सुरक्षा खामी #1: उजागर सार्वजनिक API#

Optus ब्रीच में पहली प्रमुख सुरक्षा खामी एक सार्वजनिक API का उपयोग था जिसने संवेदनशील आंतरिक डेटा तक पहुंच की सुविधा प्रदान की। सार्वजनिक API को बाहरी सिस्टम को कंपनी की सेवाओं के साथ बातचीत करने में सक्षम बनाने के लिए डिज़ाइन किया गया है, लेकिन जब ये API ठीक से सुरक्षित नहीं होते हैं, तो वे हमलावरों के लिए एक प्रवेश द्वार बन सकते हैं।

सार्वजनिक API का उपयोग किस लिए किया जाता है?

सुरक्षित सार्वजनिक API, जैसे कि Google Maps API या Weather API, बाहरी सिस्टम को सीमित, गैर-संवेदनशील डेटा प्रदान करते हैं। वे मुख्य व्यावसायिक संचालन से किसी भी साझा डेटा को अलग करने के लिए डिज़ाइन किए गए हैं, जिससे वे स्वाभाविक रूप से सुरक्षित हो जाते हैं।

इस मामले में सार्वजनिक API एक समस्या क्यों हैं?

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

हमलावर इस API का शोषण कैसे कर सकते हैं?

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

2.2 सुरक्षा खामी #2: असुरक्षित API जो संवेदनशील ग्राहक डेटा तक पहुंच प्रदान करता है#

Optus डेटा ब्रीच में दूसरी प्रमुख सुरक्षा खामी यह थी कि API सुरक्षित नहीं था। इसलिए इसने अत्यधिक संवेदनशील ग्राहक डेटा तक पहुंच प्रदान की। जबकि पहला मुद्दा API के सार्वजनिक होने के इर्द-गिर्द घूमता था, यहां मुख्य समस्या उचित एक्सेस कंट्रोल की कमी थी, जिसने गोपनीय जानकारी तक अप्रतिबंधित पहुंच की अनुमति दी।

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

इस मामले में, उजागर API ने हमलावरों को निम्नलिखित प्रकार के व्यक्तिगत डेटा तक सीधे पहुंच प्रदान की, जो विशेष रूप से पहचान की चोरी और धोखाधड़ी के लिए मूल्यवान हैं:

• ड्राइविंग लाइसेंस नंबर • फोन नंबर • जन्म तिथि • घर के पते

सार्वजनिक डोमेन नेम सिस्टम (DNS) रिकॉर्ड के एक विश्लेषण से बाद में पता चला कि यह API संभवतः सार्वजनिक था और लगभग तीन महीनों तक इंटरनेट पर किसी के लिए भी उपलब्ध था।

2.3 सुरक्षा खामी #3: अनुक्रमिक ग्राहक पहचानकर्ताओं का उपयोग#

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

Optus ग्राहक पहचानकर्ता: इस मामले में, ग्राहक पहचानकर्ताओं ने एक अनुमानित पैटर्न का पालन किया, जो 1 की वृद्धि से भिन्न होता है। उदाहरण के लिए, यदि एक ग्राहक का पहचानकर्ता 5332 था, तो अगला 5333 होगा। एक बार जब हैकर ने डेटाबेस तक पहुंच प्राप्त कर ली, तो वे केवल पहचानकर्ता को बढ़ाकर हर रिकॉर्ड को प्राप्त करने के लिए एक स्वचालित स्क्रिप्ट लिख सकते थे।

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

2.4 सुरक्षा खामी #4: कोडिंग त्रुटि के कारण कमजोर एक्सेस कंट्रोल#

API और ग्राहक आईडी कमजोरियों के अलावा और भी सुरक्षा समस्याएं थीं: 2018 में, एक कोडिंग त्रुटि ने कुछ Optus डोमेन पर एक्सेस कंट्रोल को कमजोर कर दिया, जिससे वे कम सुरक्षित हो गए। हालांकि Optus ने अगस्त 2021 में अपनी मुख्य वेबसाइट पर इस समस्या को ठीक कर लिया, लेकिन यह इंटरनेट पर उपलब्ध द्वितीयक वेबसाइट पर उसी फिक्स को लागू करने में विफल रहा। यह द्वितीयक डोमेन सितंबर 2022 में ब्रीच की खोज होने तक संवेदनशील बना रहा।

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

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

2.5 सुरक्षा खामी #5: संवेदनशील दूसरा डोमेन#

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

सक्रिय उपयोग में न होने पर भी, ऐसे डोमेन हमले के वैक्टर के रूप में काम कर सकते हैं यदि उनमें कमजोरियां मौजूद हों। इन जोखिमों को कम करने के लिए, कंपनियों को नियमित रूप से अपनी डिजिटल संपत्तियों का ऑडिट करना चाहिए, अप्रयुक्त डोमेन को तुरंत डिकमीशन करना चाहिए, या सक्रिय सिस्टम के समान ही सुरक्षा का स्तर लागू करना चाहिए।

3. ऐसे डेटा ब्रीच से कैसे बचें?#

Optus हैक के समान डेटा ब्रीच को रोकने और प्रतिष्ठा को नुकसान पहुंचने के जोखिम को कम करने के लिए, संगठन विभिन्न सुरक्षा रणनीतियों को अपना सकते हैं जो आप निम्नलिखित में पा सकते हैं:

3.1 उपाय #1: OWASP API सुरक्षा प्रोजेक्ट का संदर्भ लें#

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

• ब्रोकेन ऑब्जेक्ट लेवल ऑथराइजेशन (BOLA): उपयोगकर्ता एक्सेस अनुमतियों में अंतराल जो अनधिकृत डेटा पहुंच की अनुमति देता है।

• अत्यधिक डेटा एक्सपोजर: API जो आवश्यकता से अधिक जानकारी लौटाते हैं, संवेदनशील डेटा लीक के जोखिम को बढ़ाते हैं।

• सुरक्षा गलत कॉन्फ़िगरेशन: गलत सेटिंग्स या डिफ़ॉल्ट जो संवेदनशील API को हमलों के संपर्क में लाते हैं।

• इंजेक्शन दोष: हमलावर दुर्भावनापूर्ण कमांड या डेटा को इंजेक्ट करने के लिए API का शोषण करते हैं।

3.2 उपाय #2: सभी API को प्रमाणीकरण प्रोटोकॉल के साथ सुरक्षित करें#

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

कुछ मामलों में, विरासत प्रणालियों के साथ संगतता बनाए रखने या परीक्षण उद्देश्यों के लिए API को जानबूझकर बिना प्रमाणीकरण के छोड़ दिया जाता है। यह संभव है कि Optus ने समान कारणों से अपने API को बिना प्रमाणीकरण के छोड़ दिया हो। हालांकि, परीक्षण या विरासत प्रणाली की आवश्यकताएं कितनी भी महत्वपूर्ण क्यों न हों, किसी भी API को तैनात करना—चाहे वह आंतरिक हो या सार्वजनिक—बिना प्रमाणीकरण के एक महत्वपूर्ण सुरक्षा जोखिम है।

बिना प्रमाणित API के शोषण को कैसे रोकें

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

छिपी हुई API कमजोरियों की पहचान करना

एक API सुरक्षा नीति तभी प्रभावी होती है जब सुरक्षा की आवश्यकता वाले सभी API का हिसाब रखा जाता है। लेकिन क्या होता है यदि आपका संगठन अनजाने में सार्वजनिक API द्वारा उजागर हो जाता है, जैसा कि Optus के मामले में हुआ था?

मानक स्कैनिंग टूल का उपयोग करके छिपे हुए या अनदेखे API का पता लगाना मुश्किल है। उन्हें उजागर करने का सबसे प्रभावी तरीका पेनेट्रेशन टेस्टिंग है, जो निम्नलिखित कमजोरियों को उजागर करता है:

• कमजोर प्रमाणीकरण तंत्र: सिस्टम जो सादे पाठ पासवर्ड या खराब रूप से हैश किए गए क्रेडेंशियल्स को स्वीकार करते हैं।

• क्रेडेंशियल स्टफिंग या ब्रूट फोर्स हमलों के संपर्क में आना: बड़े पैमाने पर चोरी हुए उपयोगकर्ता नाम और पासवर्ड का शोषण करना।

• API पैरामीटर हेरफेर: URL या प्रतिक्रियाओं में संवेदनशील प्रमाणीकरण विवरण उजागर करना।

4. निष्कर्ष#

अंत में, Optus डेटा ब्रीच मजबूत साइबर सुरक्षा उपायों को लागू करने और डिजिटल संपत्तियों का नियमित रूप से ऑडिट करने के महत्वपूर्ण महत्व को रेखांकित करता है। API को सुरक्षित करने, उचित प्रमाणीकरण प्रोटोकॉल लागू करने और द्वितीयक डोमेन पर अनदेखी कमजोरियों को दूर करने में विफलता ने इस घटना में महत्वपूर्ण योगदान दिया। उद्योग के सर्वोत्तम प्रथाओं को अपनाकर, जैसे कि OWASP API सुरक्षा प्रोजेक्ट में उल्लिखित, और व्यापक सुरक्षा रणनीतियों को प्राथमिकता देकर, संगठन समान ब्रीच से बचाव कर सकते हैं, संवेदनशील ग्राहक डेटा की रक्षा कर सकते हैं, और सबसे महत्वपूर्ण रूप से अपने उपयोगकर्ताओं का विश्वास बनाए रख सकते हैं।

Corbado के बारे में

Corbado बड़े पैमाने पर consumer authentication चलाने वाली CIAM टीमों के लिए Passkey Intelligence Platform है। हम आपको वह दिखाते हैं जो IDP logs और सामान्य analytics tools नहीं दिखा सकते: कौन-से devices, OS versions, browsers और credential managers passkeys को support करते हैं, क्यों enrollments login में नहीं बदलते, WebAuthn flow कहाँ fail होता है, और कब कोई OS या browser update चुपचाप login को तोड़ देता है — और यह सब Okta, Auth0, Ping, Cognito या आपके in-house IDP को बदले बिना। दो products: Corbado Observe जोड़ता है passkeys और किसी भी अन्य login method के लिए observability। Corbado Connect देता है analytics के साथ built-in managed passkeys (आपके IDP के साथ-साथ)। VicRoads, Corbado के साथ 5M+ users के लिए passkeys चला रहा है (+80% passkey activation)। Passkey विशेषज्ञ से बात करें →

Frequently Asked Questions#

Optus ब्रीच में कौन सा व्यक्तिगत डेटा चोरी हुआ और यह इतना हानिकारक क्यों है?#

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

कोई कंपनी पहली बार में API को बिना प्रमाणीकरण के क्यों छोड़ेगी?#

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

हमलावरों द्वारा उनका फायदा उठाने से पहले सुरक्षा टीमें छिपे हुए या अनदेखे API की खोज कैसे कर सकती हैं?#

मानक स्कैनिंग उपकरण छिपे हुए या अनदेखे API का पता लगाने में संघर्ष करते हैं। सबसे प्रभावी तरीका पेनेट्रेशन टेस्टिंग है, जो कमजोर प्रमाणीकरण तंत्र, क्रेडेंशियल स्टफिंग हमलों के संपर्क में आने और URL या API प्रतिक्रियाओं में सामने आने वाले संवेदनशील प्रमाणीकरण विवरणों को उजागर कर सकता है।

OWASP API सुरक्षा प्रोजेक्ट क्या है और यह संगठनों को Optus जैसे ब्रीच से बचने में कैसे मदद करता है?#

OWASP API सुरक्षा प्रोजेक्ट एक नियमित रूप से अपडेट किया गया संसाधन है जो ब्रोकेन ऑब्जेक्ट लेवल ऑथराइजेशन, अत्यधिक डेटा एक्सपोजर, सुरक्षा गलत कॉन्फ़िगरेशन और इंजेक्शन दोष जैसे ज्ञात API सुरक्षा जोखिमों को सूचीबद्ध करता है। साइबर सुरक्षा टीमों को इसे नियमित रूप से मॉनिटर करना चाहिए ताकि हमलावर उनका फायदा उठाने से पहले कमजोरियों को पहचान कर उन्हें दूर कर सकें।