प्राचीन Roblox हैकिंग मामले की याद दिलाता है, जहाँ एक non-production staging site पर users साइन अप कर सकते थे, और वहाँ एक बैनर था: "यहाँ की हर चीज़ स्थायी नहीं है"। जब production account में एक नया admin account जोड़ा गया, तो किसी ने staging site पर उसी username से रजिस्टर किया और cookies व tokens का इस्तेमाल करके production account पर कब्ज़ा कर लिया, जिससे site जोखिम में पड़ गई। यह कल्पना करना मुश्किल है कि ऐसी समस्या दुर्लभ हो: जब username या user ID के आधार पर crypto tokens बनाए जाते हैं, और production/staging के लिए अलग secrets नहीं होते, या staging site ऐसे external services से बात करती है जो production privileges को गड़बड़ा देते हैं, आदि।
बड़ी कंपनियों में dev/production की सीमा लोगों की सोच से कहीं ज़्यादा पारगम्य होती है। एक सामान्य दिन को देखें: आप PC में लॉग इन करते हैं, ईमेल चेक करते हैं, फिर उन्हीं credentials से Azure portal में लॉग इन करते हैं (सब कुछ उसी tenant द्वारा समर्थित होता है)। account GitHub और cloud accounts से जुड़ा होता है।
Teams या OneDrive में काम करने के लिए, ऐसे groups और teams जगह-जगह बना दिए जाते हैं जिनकी permissions समझना मुश्किल होता है, और वे company directory में security groups के रूप में लगभग अलग न पहचाने जा सकने वाली स्थिति में रह जाते हैं।
कभी-कभी एक automated email आता है जो पूछता है कि क्या आप अभी भी किसी चीज़ की ज़रूरत रखते हैं, लेकिन संदेश अस्पष्ट होता है, और सचमुच बड़ी कंपनियों में पूछने के लिए कोई नहीं होता (help desk को जवाब देने में दो दिन लगते हैं, और Twitter पर John Savill से भी संपर्क नहीं किया जा सकता), इसलिए आप बस confirm दबाते हैं और आगे बढ़ जाते हैं।
आखिरकार, संरचना फटने लगती है और attacker किसी कमजोर जगह पर किस्मत आज़मा कर tenants के पार वह हासिल कर सकता है जो वह चाहता है।
जैसा एक समझदार CISO ने एक बार कहा था, hackers घुसपैठ नहीं करते, वे लॉग इन करते हैं।
cyber security उद्योग में इसे आम तौर पर "whoopsie" के नाम से जाना जाता है।
शोधकर्ता और security expert Kevin Beaumont ने Mastodon पर इशारा किया कि OAuth app को 'full_access_as_app' role असाइन कर सकने वाले account के पास admin privileges होने चाहिए। उनका कहना था कि "किसी ने" production environment में काफ़ी बड़ी configuration mistake की है।
मुझे system की details नहीं पता, लेकिन लगता नहीं कि वही असली समस्या है, और यह सुनकर हैरानी होती है कि experts इसे समस्या कह रहे हैं। ऐसी गलती करना संभव ही नहीं होना चाहिए। designers और administrators को इसे असंभव बनाना चाहिए, और जवाबदेही उन्हीं की होनी चाहिए।
शानदार security certifications होने के बावजूद, ऐसा लगता है जैसे Amazon पर $36 की किताब में दी गई अच्छी तरह सोची-समझी best practices को पूरी तरह नज़रअंदाज़ किया जा रहा है।
इस पोस्ट में जो बात गायब है: लेखक "production" को कैसे परिभाषित करते हैं, और किस स्थिति में कोई "non-production" account production domain पर administrative privileges रख सकता है।
यह पैटर्न MS ecosystem में अपवाद नहीं बल्कि नियम है, लेकिन Microsoft का खुद ऐसा करना खास तौर पर शर्मनाक है।
एक कंपनी में सभी production servers और databases के passwords code repository में एक text file में रखे गए थे, क्योंकि chief architect passwords याद नहीं रखना चाहता था। जब CTO को बताया गया कि यह कितना बेवकूफ़ी भरा है, तो जवाब मिला: "हम अपने कर्मचारियों पर भरोसा करते हैं" और "हम security audit पास कर चुके हैं"।
नई नौकरी पर जाते समय मुझे यह नापसंद है जब कोई "क्योंकि इससे आसान है" कहकर बहुत सारी permissions दे देता है। ऐसा नहीं करना चाहिए। इससे सिर्फ कंपनी ही expose नहीं होती, बल्कि आपके ऊपर ऐसी ज़िम्मेदारी भी आ जाती है जो आप नहीं चाहते। आप गलती से किसी महत्वपूर्ण चीज़ को तोड़ सकते हैं, और अगर आपका account hack हो जाए तो permissions होने की वजह से शक आप पर भी आ सकता है कि यह आपने किया।
इसे "गलती" क्यों माना जा रहा है? यह Microsoft में admin के रूप में काम कर रहे किसी जासूस की हरकत भी हो सकती है।
1 टिप्पणियां
Hacker News की राय