Okta Security
Basic Information
Okta, Inc. पहचान और पहुंच प्रबंधन क्षेत्र में अपने क्लाउड-आधारित सॉफ़्टवेयर समाधानों के लिए जाना जाता है। ये समाधान विभिन्न आधुनिक अनुप्रयोगों में उपयोगकर्ता प्रमाणीकरण को सरल और सुरक्षित बनाने के लिए डिज़ाइन किए गए हैं। ये न केवल उन कंपनियों के लिए हैं जो अपने संवेदनशील डेटा की सुरक्षा करना चाहती हैं, बल्कि उन डेवलपर्स के लिए भी हैं जो अनुप्रयोगों, वेब सेवाओं और उपकरणों में पहचान नियंत्रण को एकीकृत करने में रुचि रखते हैं।
Okta की प्रमुख पेशकश Okta Identity Cloud है। यह प्लेटफ़ॉर्म उत्पादों का एक सूट शामिल करता है, जिसमें शामिल हैं लेकिन सीमित नहीं हैं:
Single Sign-On (SSO): कई अनुप्रयोगों में एक सेट लॉगिन क्रेडेंशियल्स के माध्यम से उपयोगकर्ता पहुंच को सरल बनाता है।
Multi-Factor Authentication (MFA): कई प्रकार की सत्यापन आवश्यकताओं के माध्यम से सुरक्षा बढ़ाता है।
Lifecycle Management: उपयोगकर्ता खाता निर्माण, अपडेट और निष्क्रियता प्रक्रियाओं को स्वचालित करता है।
Universal Directory: उपयोगकर्ताओं, समूहों और उपकरणों का केंद्रीकृत प्रबंधन सक्षम बनाता है।
API Access Management: APIs तक पहुंच को सुरक्षित और प्रबंधित करता है।
ये सेवाएँ सामूहिक रूप से डेटा सुरक्षा को मजबूत करने और उपयोगकर्ता पहुंच को सरल बनाने का लक्ष्य रखती हैं, जिससे सुरक्षा और सुविधा दोनों में सुधार होता है। Okta के समाधानों की बहुपरकारीता उन्हें विभिन्न उद्योगों में एक लोकप्रिय विकल्प बनाती है, जो बड़े उद्यमों, छोटे कंपनियों और व्यक्तिगत डेवलपर्स के लिए फायदेमंद है। सितंबर 2021 में अंतिम अपडेट के अनुसार, Okta पहचान और पहुंच प्रबंधन (IAM) क्षेत्र में एक प्रमुख इकाई के रूप में मान्यता प्राप्त है।
Okta का मुख्य लक्ष्य विभिन्न उपयोगकर्ताओं और समूहों के लिए बाहरी अनुप्रयोगों तक पहुंच को कॉन्फ़िगर करना है। यदि आप Okta वातावरण में व्यवस्थापक विशेषाधिकारों को समझौता करने में सफल होते हैं, तो आप संभवतः कंपनी द्वारा उपयोग किए जा रहे सभी अन्य प्लेटफार्मों को समझौता करने में सक्षम होंगे।
Okta वातावरण की सुरक्षा समीक्षा करने के लिए आपको व्यवस्थापक केवल पढ़ने की पहुंच मांगनी चाहिए।
Summary
यहाँ उपयोगकर्ता हैं (जो Okta में संग्रहीत हो सकते हैं, कॉन्फ़िगर किए गए पहचान प्रदाताओं से लॉग इन कर सकते हैं या Active Directory या LDAP के माध्यम से प्रमाणित हो सकते हैं)। ये उपयोगकर्ता समूहों के अंदर हो सकते हैं। यहाँ प्रमाणक भी हैं: प्रमाणीकरण के लिए विभिन्न विकल्प जैसे पासवर्ड, और कई 2FA जैसे WebAuthn, ईमेल, फोन, Okta Verify (इन्हें सक्षम या अक्षम किया जा सकता है)...
फिर, यहाँ अनुप्रयोग हैं जो Okta के साथ समन्वयित हैं। प्रत्येक अनुप्रयोग का कुछ Okta के साथ मैपिंग होगा ताकि जानकारी साझा की जा सके (जैसे ईमेल पते, पहले नाम...)। इसके अलावा, प्रत्येक अनुप्रयोग को एक Authentication Policy के अंदर होना चाहिए, जो यह दर्शाता है कि उपयोगकर्ता को अनुप्रयोग तक पहुँचने के लिए आवश्यक प्रमाणक क्या हैं।
सबसे शक्तिशाली भूमिका Super Administrator है।
यदि एक हमलावर Okta को व्यवस्थापक पहुंच के साथ समझौता करता है, तो सभी अनुप्रयोग जो Okta पर भरोसा करते हैं संभवतः समझौता हो जाएंगे।
Attacks
Locating Okta Portal
आमतौर पर किसी कंपनी का पोर्टल companyname.okta.com पर स्थित होगा। यदि नहीं, तो companyname. के सरल विविधताएँ आज़माएँ। यदि आप इसे नहीं ढूंढ सकते हैं, तो यह भी संभव है कि संगठन के पास CNAME रिकॉर्ड हो जैसे okta.companyname.com जो Okta पोर्टल की ओर इशारा करता है।
Login in Okta via Kerberos
यदि companyname.kerberos.okta.com सक्रिय है, तो Okta पहुंच के लिए Kerberos का उपयोग किया जाता है, आमतौर पर Windows उपयोगकर्ताओं के लिए MFA को बायपास करते हुए। AD में Kerberos-प्रमाणित Okta उपयोगकर्ताओं को खोजने के लिए, getST.py को उपयुक्त पैरामीटर के साथ चलाएँ। एक AD उपयोगकर्ता टिकट प्राप्त करने के बाद, इसे नियंत्रित होस्ट में Rubeus या Mimikatz जैसे उपकरणों का उपयोग करके इंजेक्ट करें, यह सुनिश्चित करते हुए कि clientname.kerberos.okta.com इंटरनेट विकल्पों के "इंट्रानेट" क्षेत्र में है। एक विशिष्ट URL तक पहुँचने पर JSON "OK" प्रतिक्रिया मिलनी चाहिए, जो Kerberos टिकट की स्वीकृति को दर्शाती है, और Okta डैशबोर्ड तक पहुँच प्रदान करती है।
Okta सेवा खाते को डेलिगेशन SPN के साथ समझौता करना एक Silver Ticket हमले को सक्षम करता है। हालाँकि, Okta का AES का उपयोग टिकट एन्क्रिप्शन के लिए AES कुंजी या प्लेनटेक्स्ट पासवर्ड की आवश्यकता होती है। ticketer.py का उपयोग करके पीड़ित उपयोगकर्ता के लिए एक टिकट उत्पन्न करें और इसे Okta के साथ प्रमाणीकरण के लिए ब्राउज़र के माध्यम से वितरित करें।
हमले की जांच करें https://trustedsec.com/blog/okta-for-red-teamers।
Hijacking Okta AD Agent
यह तकनीक एक सर्वर पर Okta AD एजेंट तक पहुँचने से संबंधित है, जो उपयोगकर्ताओं को समन्वयित करता है और प्रमाणीकरण को संभालता है। OktaAgentService.exe.config में कॉन्फ़िगरेशन की जांच और डिक्रिप्ट करके, विशेष रूप से AgentToken का उपयोग करके DPAPI, एक हमलावर संभावित रूप से प्रमाणीकरण डेटा को इंटरसेप्ट और हेरफेर कर सकता है। यह न केवल Okta प्रमाणीकरण प्रक्रिया के दौरान उपयोगकर्ता क्रेडेंशियल्स को प्लेनटेक्स्ट में निगरानी और कैप्चर करने की अनुमति देता है, बल्कि प्रमाणीकरण प्रयासों का उत्तर देने की भी अनुमति देता है, जिससे अनधिकृत पहुंच सक्षम होती है या Okta के माध्यम से सार्वभौमिक प्रमाणीकरण प्रदान किया जाता है (जैसे 'स्केलेटन की')।
हमले की जांच करें https://trustedsec.com/blog/okta-for-red-teamers।
Hijacking AD As an Admin
यह तकनीक एक OAuth कोड प्राप्त करके पहले Okta AD एजेंट को हाईजैक करने से संबंधित है, फिर एक API टोकन का अनुरोध करना। टोकन एक AD डोमेन से संबंधित है, और एक कनेक्टर को एक नकली AD एजेंट स्थापित करने के लिए नामित किया गया है। प्रारंभिककरण एजेंट को प्रमाणीकरण प्रयासों को संसाधित करने की अनुमति देता है, Okta API के माध्यम से क्रेडेंशियल्स को कैप्चर करता है। स्वचालन उपकरण इस प्रक्रिया को सरल बनाने के लिए उपलब्ध हैं, जो Okta वातावरण के भीतर प्रमाणीकरण डेटा को इंटरसेप्ट और संभालने के लिए एक सहज विधि प्रदान करते हैं।
हमले की जांच करें https://trustedsec.com/blog/okta-for-red-teamers।
Okta Fake SAML Provider
हमले की जांच करें https://trustedsec.com/blog/okta-for-red-teamers।
यह तकनीक एक नकली SAML प्रदाता को तैनात करने से संबंधित है। एक विशेषाधिकार प्राप्त खाते का उपयोग करके Okta के ढांचे के भीतर एक बाहरी पहचान प्रदाता (IdP) को एकीकृत करके, हमलावर IdP को नियंत्रित कर सकते हैं, किसी भी प्रमाणीकरण अनुरोध को इच्छानुसार अनुमोदित कर सकते हैं। प्रक्रिया में Okta में SAML 2.0 IdP सेट करना, स्थानीय होस्ट फ़ाइल के माध्यम से पुनर्निर्देशन के लिए IdP सिंगल साइन-ऑन URL में हेरफेर करना, एक स्व-हस्ताक्षरित प्रमाणपत्र उत्पन्न करना, और उपयोगकर्ता नाम या ईमेल के खिलाफ Okta सेटिंग्स को कॉन्फ़िगर करना शामिल है। इन चरणों को सफलतापूर्वक निष्पादित करने से किसी भी Okta उपयोगकर्ता के रूप में प्रमाणीकरण की अनुमति मिलती है, व्यक्तिगत उपयोगकर्ता क्रेडेंशियल्स की आवश्यकता को बायपास करते हुए, संभावित रूप से अनदेखी तरीके से पहुंच नियंत्रण को महत्वपूर्ण रूप से बढ़ाता है।
Phishing Okta Portal with Evilgnix
इस ब्लॉग पोस्ट में बताया गया है कि Okta पोर्टल के खिलाफ फ़िशिंग अभियान कैसे तैयार करें।
Colleague Impersonation Attack
प्रत्येक उपयोगकर्ता के पास होने वाले और संशोधित करने योग्य विशेषताएँ (जैसे ईमेल या पहले नाम) Okta में कॉन्फ़िगर की जा सकती हैं। यदि एक अनुप्रयोग एक विशेषता के रूप में विश्वास करता है जिसे उपयोगकर्ता संशोधित कर सकता है, तो वह उस प्लेटफ़ॉर्म में अन्य उपयोगकर्ताओं का नकली रूप धारण करने में सक्षम होगा।
इसलिए, यदि ऐप userName फ़ील्ड पर भरोसा कर रहा है, तो आप इसे बदलने में सक्षम नहीं होंगे (क्योंकि आप आमतौर पर उस फ़ील्ड को नहीं बदल सकते), लेकिन यदि यह उदाहरण के लिए primaryEmail पर भरोसा कर रहा है, तो आप इसे एक सहयोगी के ईमेल पते में बदलने में सक्षम हो सकते हैं और उसका नकली रूप धारण कर सकते हैं (आपको ईमेल तक पहुंच प्राप्त करनी होगी और परिवर्तन को स्वीकार करना होगा)।
ध्यान दें कि यह नकली रूप धारण करना इस बात पर निर्भर करता है कि प्रत्येक अनुप्रयोग को कैसे कॉन्फ़िगर किया गया था। केवल वही जो उस फ़ील्ड पर भरोसा करते हैं जिसे आपने संशोधित किया और अपडेट स्वीकार करते हैं, वे समझौता किए जाएंगे। इसलिए, यदि यह फ़ील्ड मौजूद है तो ऐप को इसे सक्षम करना चाहिए:
मैंने अन्य ऐप्स को भी देखा है जो कमजोर थे लेकिन Okta सेटिंग्स में वह फ़ील्ड नहीं थी (अंत में विभिन्न ऐप्स को अलग-अलग तरीके से कॉन्फ़िगर किया जाता है)।
यह जानने का सबसे अच्छा तरीका कि क्या आप प्रत्येक ऐप पर किसी का भी नकली रूप धारण कर सकते हैं, इसे आज़माना होगा!
Evading behavioural detection policies
Okta में व्यवहारिक पहचान नीतियाँ तब तक अज्ञात हो सकती हैं जब तक कि उनका सामना न किया जाए, लेकिन उन्हें बायपास करना Okta अनुप्रयोगों को सीधे लक्षित करके किया जा सकता है, मुख्य Okta डैशबोर्ड से बचते हुए। एक Okta एक्सेस टोकन के साथ, मुख्य लॉगिन पृष्ठ के बजाय अनुप्रयोग-विशिष्ट Okta URL पर टोकन को पुनः चलाएँ।
मुख्य सिफारिशें शामिल हैं:
कैप्चर किए गए एक्सेस टोकन को पुनः चलाते समय लोकप्रिय एनोनिमाइज़र प्रॉक्सी और VPN सेवाओं का उपयोग करने से बचें।
ग्राहक और पुनः चलाए गए एक्सेस टोकनों के बीच संगत उपयोगकर्ता-एजेंट स्ट्रिंग्स सुनिश्चित करें।
एक ही IP पते से विभिन्न उपयोगकर्ताओं के टोकनों को पुनः चलाने से बचें।
Okta डैशबोर्ड के खिलाफ टोकनों को पुनः चलाते समय सावधानी बरतें।
यदि पीड़ित कंपनी के IP पते के बारे में जानकारी है, तो उन IPs या उनके रेंज तक ट्रैफ़िक को सीमित करें, सभी अन्य ट्रैफ़िक को ब्लॉक करें।
Okta Hardening
Okta में कई संभावित कॉन्फ़िगरेशन हैं, इस पृष्ठ पर आप उन्हें इस तरह से समीक्षा करना सीखेंगे कि वे यथासंभव सुरक्षित हों:
Okta HardeningReferences
Last updated
