मई 2019 सुरक्षा घटना में एक गहरा गोता: ब्लॉग पोस्ट प्रतिक्रिया
हमने मई 2019 में वापस हुई सुरक्षा घटना का एक अपडेट पोस्ट किया , जो हुआ, यह कैसे हुआ, और इस तरह की घटना को फिर से होने से रोकने के लिए हमने जो रीमेडिएशन लागू किया था, उसका एक विवरण पोस्ट किया। यहाँ पोस्ट के कुछ अंश हैं - पहले परिचय से:
12 मई, 2019 को, लगभग 00:00 यूटीसी पर, हमें समुदाय के कई सदस्यों द्वारा एक नए उपयोगकर्ता खाते के लिए अप्रत्याशित विशेषाधिकार वृद्धि के लिए सतर्क किया गया था। एक उपयोगकर्ता जिसे किसी ने नहीं पहचाना, उसने स्टाॅक एक्सचेंज नेटवर्क की सभी साइटों में मॉडरेटर और डेवलपर स्तर तक पहुँच प्राप्त की थी। हमारी तत्काल प्रतिक्रिया विशेषाधिकारों को रद्द करने और इस खाते को निलंबित करने और फिर घटना के कारण होने वाले कार्यों की पहचान और ऑडिट करने के लिए एक प्रक्रिया निर्धारित करने के लिए थी।
प्रारंभिक खोज के बाद, हमने पाया कि विशेषाधिकार का विस्तार सिर्फ हिमशैल का हमला था और हमले के परिणामस्वरूप वास्तव में हमारे स्रोत कोड की घुसपैठ और पीआईआई के अनजाने संपर्क (ईमेल, वास्तविक नाम, आईपी पते) 184 उपयोगकर्ताओं के थे स्टैक एक्सचेंज नेटवर्क (जिनमें से सभी को सूचित किया गया था)। शुक्र है, डेटाबेस में से कोई भी - न तो सार्वजनिक (पढ़ें: स्टैक एक्सचेंज सामग्री) और न ही निजी (टीमें, प्रतिभा, या उद्यम) - जो अतिरंजित हैं। इसके अतिरिक्त, हमारे आंतरिक नेटवर्क के बुनियादी ढांचे तक किसी भी प्रत्यक्ष पहुंच का कोई सबूत नहीं है, और किसी भी समय हमलावर के पास कभी भी टीम्स, टैलेंट या एंटरप्राइज उत्पादों के डेटा तक पहुंच नहीं है।
और अंतिम पैराग्राफ से:
इस घटना ने हमें कुछ मूलभूत सुरक्षा प्रथाओं के बारे में याद दिलाया जिनका सभी को पालन करना चाहिए:
- अपने सभी इनबाउंड ट्रैफ़िक को लॉग इन करें। हम सभी इन-बाउंड कनेक्शन पर लॉग रखते हैं। इसने हमारी सभी जांचों को सक्षम बनाया। आप जांच नहीं कर सकते कि आप क्या लॉग नहीं करते हैं।
- 2FA का उपयोग करें। वह शेष प्रणाली जो अभी भी विरासत प्रमाणीकरण का उपयोग करती है, आपकी सबसे बड़ी भेद्यता हो सकती है।
- गार्ड बेहतर रहस्य। TeamCity में रहस्यों की रक्षा करने का एक तरीका है, लेकिन हमने पाया कि हम इसका लगातार उपयोग नहीं कर रहे थे। इंजीनियरों को शिक्षित करें कि "रहस्य केवल पासवर्ड नहीं हैं"। SSH कुंजियों और डेटाबेस कनेक्शन स्ट्रिंग्स को भी सुरक्षित रखें। जब संदेह हो, तो इसे सुरक्षित रखें। यदि आप एक Git रेपो में रहस्यों को संग्रहीत करना चाहते हैं, तो उन्हें git-crypt या Blackbox से सुरक्षित रखें ।
- ग्राहक के अनुरोधों को मान्य करें। किसी ग्राहक से अनुरोध जितना अधिक असामान्य है, यह सत्यापित करना उतना ही महत्वपूर्ण है कि अनुरोध वैध है या नहीं।
- सुरक्षा रिपोर्ट को गंभीरता से लें। हम आभारी हैं कि हमारे समुदाय ने इतनी जल्दी संदिग्ध गतिविधि की सूचना दी। धन्यवाद!
ब्लॉग पोस्ट में बहुत अधिक है - कृपया नीचे दिए गए पोस्ट से संबंधित किसी भी प्रश्न या टिप्पणी को पूछने के लिए स्वतंत्र महसूस करें और हम उन्हें जवाब देने के लिए अपनी पूरी कोशिश करेंगे। वर्तमान में चल रही जाँच के कारण, ब्लॉग पोस्ट में जो कुछ भी शामिल है उससे परे हमले से संबंधित अन्य विवरणों पर हम टिप्पणी नहीं कर सकते हैं।
जवाब
क्या आप हमलावरों के इरादों के बारे में कोई टिप्पणी कर सकते हैं?
क्या ऐसा प्रतीत होता है कि वे एक निश्चित लक्ष्य / निश्चित (उपयोगकर्ता) डेटा के बाद थे?
या शायद यह एक "जिज्ञासु किशोरी" से अधिक था जो लाठी से पीटते हुए देखती थी कि वे कितनी दूर तक पहुंच सकते हैं?
इस मामले के बारे में खुलेपन के लिए PS धन्यवाद, यह वाकई काबिले तारीफ है!
यह रेखा:
स्टैक एक्सचेंज नेटवर्क में चीजों को देखने (प्रश्नों का दौरा) करने की यह क्रिया एक लगातार घटना बन जाती है और हमें आने वाले दिनों में हमलावर की कार्यप्रणाली का अनुमान लगाने और समझने की अनुमति देती है । (जोर मेरा)
यह वास्तविक समय की तरह आवाज करता है , जैसा कि हमला हो रहा था, आप यह इंगित कर सकते हैं कि हमलावर ने स्टैक ओवरफ्लो पर जाने के आधार पर क्या किया होगा, बजाय इसके कि वे क्या करते हैं, जो उन्होंने देखा (हमले के बाद)। आपका कौन सा मतलब था?
मुख्य रूप से हमलावर से संबंधित कई प्रश्न:
- क्या हुआ हमलावर को?
- क्या आपने उनके खाते को निलंबित कर दिया था?
- क्या एसई ने किसी बिंदु पर हमलावर से संपर्क किया?
- आप हमलावर की पहचान उजागर क्यों नहीं करते?
- क्या किसी और ने बाद में इसी हमले की पद्धति का उपयोग करने की कोशिश की है?
क्या घटनाओं के दूसरे छोर पर एक खोजी नींद चक्र था?
स्पष्ट करने के लिए संपादित करें:
हमलावर के बारे में पता चलने के बाद, और जब से आप उनके कुछ कार्यों का पालन करते हैं, जैसा कि आपने खुलासा किया था, क्या आपने दिन-प्रतिदिन और पूर्वव्यापी दोनों तरह से एक जैविक चक्र के समान कुछ देखा था? जैसे: भोजन (1-2 घंटे का ब्रेक), नींद (8 घंटे की निष्क्रियता पैटर्न), "पावर नैप्स" (90 मिनट), आदि ...?
यह वास्तव में घटना का हिस्सा नहीं है, लेकिन कर्मचारी खातों के आसपास सुरक्षा उपायों के बारे में अधिक सामान्य चिंता है। इस घटना में बहुत सारे कदम थे, लेकिन अंतिम एक एसई खाते के विशेषाधिकारों को बढ़ा रहा था। मैं उत्पादन में एसक्यूएल को निष्पादित करने के लिए देव उदाहरण के माध्यम से सीआई सर्वर तक व्यवस्थापक पहुंच प्राप्त करने की तुलना में इस पर प्रयास करने के लिए और अधिक सरल तरीकों की कल्पना कर सकता हूं, और मुझे इस बात में दिलचस्पी है कि एसई ने लाभ प्राप्त करने के लिए सरल प्रयासों के खिलाफ बचाव के लिए क्या लागू किया है कर्मचारी खाते तक पहुंच।
आप मुख्य एसई साइटों को फ़ायरवॉल के पीछे स्पष्ट रूप से नहीं रख सकते हैं, इसलिए वे हमेशा उजागर होंगे। और एसई आंतरिक लॉगिन विधि किसी भी 2FA तरीके प्रदान नहीं करती है, जो मुझे कुछ हद तक संबंधित लगता है।
- क्या कर्मचारी खाते 2FA अन्य साधनों (या अन्य लॉगिन प्रदाताओं) के माध्यम से संरक्षित हैं?
- क्या यह सुनिश्चित करने के लिए कोई उपाय है कि कोई भी निजी ईमेल पते या लॉगिन प्रदाता कर्मचारी खातों से जुड़े नहीं हैं जो कम सुरक्षित हो सकते हैं और फिर भी खाते तक पहुंच प्राप्त करने के लिए रिकवरी मेल प्राप्त करने के लिए उपयोग किया जा सकता है?
- क्या कर्मचारी खातों के लिए नए स्रोतों से लॉगिन प्रयासों की निगरानी है?
- यदि किसी कर्मचारी खाते के चालू सत्र में पहुँच प्राप्त करने के लिए (जैसे पासवर्ड और / या 2FA टोकन की आवश्यकता होती है, तो सुरक्षा-महत्वपूर्ण उपकरण एक्सेस करने पर खतरनाक कर्मचारी साधनों के लिए अतिरिक्त सुरक्षा होती है)
भाला फ़िशिंग जैसा कुछ शायद अभी भी अधिक संभव तरीकों में से एक है जो किसी कर्मचारी खाते तक पहुंच प्राप्त करने की कोशिश कर सकता है।
लगभग उसी समय यह सुरक्षा घटना घटी, कुछ दिनों बाद, कुछ उपयोगकर्ताओं ने यह देखना शुरू कर दिया कि ट्विटर चैटिंग में वनबॉक्सिंग अब काम नहीं कर रहा था । एक कर्मचारी ने बाद में अगले साल फरवरी में पुष्टि की कि इस सुरक्षा घटना के परिणामस्वरूप "कुछ अंतराल को बंद करने" के कारण इसे जानबूझकर अक्षम कर दिया गया था ।
क्या हम इस बात का पूरा विवरण प्राप्त कर सकते हैं कि क्यों इस सुरक्षा घटना के परिणामस्वरूप चैट में ट्विटरबॉक्सिंग को निष्क्रिय करना पड़ा? ब्लॉग पोस्ट समय पर प्रकाशित ने कहा कि "अन्य संभावित वैक्टर" तो बंद कर दिया गया था, और मैं जुड़ा हुआ फरवरी 2020 कर्मचारियों संदेश ऊपर कहा गया है कि ट्विटर oneboxing सुविधा "अंतराल हम बंद कर दिया में से एक का इस्तेमाल किया"। वह कौन सी चीज थी, और उसने कौन सा सुरक्षा जोखिम पैदा किया?
अंत में, क्या कोई तरीका है कि इस कार्यक्षमता को फिर से, सुरक्षित तरीके से लागू किया जा सकता है? अगस्त 2020 में, ऊपर दिए गए कर्मचारियों के संदेश के कुछ महीने बाद, उस समय दर्ज की गई बग रिपोर्ट को किसी अन्य कर्मचारी द्वारा स्टेटस-बायडिजाइन के रूप में चिह्नित किया गया था । क्या डिज़ाइन को वापस (सुरक्षित तरीके से) बदलने के लिए एक सुविधा अनुरोध पर विचार किया जाएगा, या एक हमले के वेक्टर को खोलने के बिना ऐसा करना असंभव है?
मैं झंडी दिखाऊंगा कि TeamCity में "पासवर्ड" पैरामीटर प्रकार सभी सुरक्षित नहीं माने जाते हैं:
पासवर्ड मान टीम फ़ाइल डेटा निर्देशिका के अंतर्गत कॉन्फ़िगरेशन फ़ाइलों में संग्रहीत किया जाता है। सर्वर एन्क्रिप्शन सेटिंग्स के आधार पर, मूल्य या तो कस्टम कुंजी के साथ तले हुए या एन्क्रिप्ट किया गया है।
बिल्ड लॉग मान एक सरल खोज-और-बदलें एल्गोरिथ्म के साथ छिपा हुआ है, इसलिए यदि आपके पास "123" का एक तुच्छ पासवर्ड है, तो "123" की सभी घटनाओं को बदल दिया जाएगा, संभवतः पासवर्ड को उजागर करना। पासवर्ड प्रकार के पैरामीटर सेट करना यह गारंटी नहीं देता है कि कच्चे मूल्य को पुनर्प्राप्त नहीं किया जा सकता है। कोई भी प्रोजेक्ट व्यवस्थापक इसे पुनः प्राप्त कर सकता है, और कोई भी डेवलपर जो बिल्ड स्क्रिप्ट को बदल सकता है वह पासवर्ड प्राप्त करने के लिए संभवतः दुर्भावनापूर्ण कोड लिख सकता है।
क्यों जादू सीएम के लिए देव में देखने योग्य था (संभवतः सिर्फ देव में) एक वास्तविक जादू लिंक?
यह वास्तव में एक भयानक घटना की रिपोर्ट है! मैंने जो सबसे अच्छा पढ़ा है, उनमें से एक।
एक महान लेखन के लिए इसे सार्वजनिक करने के लिए स्टैक और डीन धन्यवाद!
मैं कुछ चीजें जानने के लिए उत्सुक हूं:
- घटना प्रतिक्रिया टीम का आकार क्या है?
- क्या जांच के दौरान कोई विशिष्ट प्रोटोकॉल का पालन किया गया था?
- बाहरी सुरक्षा विक्रेता को संलग्न करने के लिए कौन से महत्वपूर्ण कारक शामिल थे? उस विशेष विक्रेता को चुनने में किन बिंदुओं पर विचार किया गया था?
- बाहरी सुरक्षा विक्रेता से क्या सबक सीखा गया? क्या उनकी ऑडिट प्रक्रिया टीम द्वारा पहले से उपयोग किए गए से अलग (प्रभावी / अप्रभावी) थी?
लेख स्टैक की संपूर्ण वास्तुकला और विकास प्रक्रियाओं की अच्छी झलक देता है। एक अधिक विस्तृत पढ़ा या लिंक होगा यदि इसके बारे में पहले से ही एक लेख है तो यह बहुत अच्छा होगा।
"दूसरों को सलाह" के तहत:
अपने सभी इनबाउंड ट्रैफ़िक को लॉग इन करें। हम सभी इन-बाउंड कनेक्शन पर लॉग रखते हैं। इसने हमारी सभी जांचों को सक्षम बनाया। आप जांच नहीं कर सकते कि आप क्या लॉग नहीं करते हैं।
Stack Exchange के रूप में व्यस्त नेटवर्क पूरे इनबाउंड ट्रैफ़िक को कैसे लॉग कर सकता है? क्या ये लॉग वेब सर्वर प्रविष्टियाँ, या आईपी प्रवाह, या पूर्ण टीसीपी सत्र हैं?
मैं अपने छोटे नेटवर्क पर अधिकांश प्रविष्टियों और कनेक्शन के प्रयासों को रिकॉर्ड कर सकता था, लेकिन मुझे नहीं पता कि यह इतना बड़ा नेटवर्क कैसे करता है।
क्या आप अधिक स्पष्ट रूप से बता सकते हैं कि नीचे दिए गए उद्धरण में "सार्वजनिक रूप से सुलभ गुण" का क्या मतलब है?
हमारे पास सार्वजनिक रूप से सुलभ गुणों के लिए सभी ट्रैफ़िक का लॉग वाला एक डेटाबेस है