सर्च इंजन कंटेंट को इंडेक्स करने के लिए बनाए गए थे। हालांकि, हमलावर इनका इस्तेमाल आपकी गलतियों को इंडेक्स करने के लिए करते हैं। क्वेरी allintext:login फ़ाइल प्रकार: लॉग देखने में यह हानिरहित लग सकता है। लेकिन वास्तव में, यह प्रमाणीकरण प्रवाह, क्रेडेंशियल, टोकन और आंतरिक बुनियादी ढांचे के डेटा वाले उजागर लॉग फ़ाइलों का पता लगाने के सबसे सरल तरीकों में से एक है।
अगर गूगल उन लॉग्स को देख सकता है, तो हमलावर भी देख सकते हैं। एक बार इंडेक्स हो जाने पर, उनका खुलासा होना तय है। इसके अलावा, जब क्रेडेंशियल्स किसी सार्वजनिक रूप से सुलभ फ़ाइल में दिखाई देते हैं, तो डेटा लीक की प्रक्रिया पहले से ही शुरू हो चुकी होती है।
1. ऑल-इनटेक्स्ट क्यों:login फ़ाइल प्रकार: लॉग जितना दिखता है उससे कहीं अधिक खतरनाक है
गूगल डॉर्क एक सर्च क्वेरी है जो सर्च इंजनों द्वारा इंडेक्स की गई संवेदनशील या गलत तरीके से कॉन्फ़िगर की गई सामग्री का पता लगाने के लिए उन्नत ऑपरेटरों का उपयोग करती है। यह गूगल का शोषण नहीं करती, बल्कि आपकी सुरक्षा में मौजूद कमियों का फायदा उठाती है।
यह क्वेरी दो ऑपरेटरों को जोड़ती है:
- allintext: उन पृष्ठों को लौटाता है जहां सभी शब्द मुख्य पाठ में दिखाई देते हैं
- फ़ाइल प्रकार: लॉग परिणामों को सीमित करता है
.logफ़ाइलों
इसलिए:
मतलब: "मुझे वे लॉग फ़ाइलें दिखाएँ जिनमें यह शब्द मौजूद हो। login".
पहली नजर में तो यह मामूली लगता है। हालांकि, व्यवहार में अक्सर इसका परिणाम यह होता है:
- सार्वजनिक रूप से उजागर वेब सर्वर लॉग
- CI/CD लॉग को कलाकृतियों के रूप में अपलोड किया गया
- डिबग लॉग गलती से commitरिपॉजिटरी में स्थानांतरित
- प्लेनटेक्स्ट क्रेडेंशियल्स के साथ एप्लिकेशन लॉग
यह सर्च इंजन की कोई गड़बड़ी नहीं है। बल्कि, यह एक डेटा लीक होने की भेद्यता गलत कॉन्फ़िगरेशन के कारण। Google ने केवल वही इंडेक्स किया जो सार्वजनिक रूप से सुलभ था।
2. हमलावरों को उजागर लॉग फाइलों में वास्तव में क्या मिलता है
जब हमलावर भागते हैं allintext:login फ़ाइल प्रकार: लॉगवे यूं ही बेतरतीब ढंग से ब्राउज़ नहीं कर रहे हैं। वे प्रमाणीकरण के निशान खोज रहे हैं।
2.1 सादे पाठ क्रेडेंशियल
लॉग में अक्सर इस प्रकार की प्रविष्टियाँ होती हैं:
or
या फिर SMTP क्रेडेंशियल्स भी:
प्रमाणीकरण पेलोड को लॉग करना उत्पादन क्रेडेंशियल लीक करने के सबसे तेज़ तरीकों में से एक है। परिणामस्वरूप, एक भी लीक हुई लॉग फ़ाइल आपके संपूर्ण एक्सेस कंट्रोल मॉडल को अमान्य कर सकती है।
2.2 सेशन टोकन और JWT
भले ही पासवर्ड लॉग न किए जाएं, लेकिन टोकन अक्सर लॉग किए जाते हैं।
उदाहरण के लिए:
एक वैध JWT या सेशन कुकी के अंदर .log फ़ाइल सक्षम कर सकती है:
- सत्र अपहरण
- सुविधा वृद्धि
- आंतरिक प्रणालियों में पार्श्व गति
दूसरे शब्दों में, लॉग में मौजूद टोकन डिबगिंग आउटपुट को प्रमाणीकरण को बायपास करने के एक माध्यम में बदल देते हैं।
2.3 CI/CD कलाकृतियों
बिल्ड लॉग विशेष रूप से खतरनाक होते हैं। दरअसल, CI/CD सिस्टम अक्सर बिल्ड चरणों के दौरान पर्यावरण चर प्रिंट करते हैं।
हमलावर अक्सर यह पाते हैं:
जिनमें निम्नलिखित पंक्तियाँ शामिल हैं:
If CI/CD कलाकृतियाँ सार्वजनिक हैं, फिर रहस्य भी सार्वजनिक हो जाते हैं। गूगल डॉर्क खोज प्रक्रिया को और तेज़ कर देता है।
2.4 क्लाउड और इन्फ्रास्ट्रक्चर डेटा
लॉग फ़ाइलों के सामने आने से अक्सर ये बातें सामने आती हैं:
- AWS एक्सेस कुंजियाँ
- Azure स्टोरेज कनेक्शन स्ट्रिंग्स
- आंतरिक सेवा यूआरएल
- डेटाबेस क्रेडेंशियल्स
- रेडिस एंडपॉइंट्स
भले ही बाद में क्रेडेंशियल्स को बदल दिया जाए, हमलावर के पास अब ये जानकारी मौजूद है:
- बुनियादी ढांचे का मानचित्रण
- नामकरण की परंपरा
- भविष्य के हमलों के लिए लक्षित खुफिया जानकारी
इसलिए, सार्वजनिक रूप से उपलब्ध लॉग एक्सेस और जासूसी दोनों प्रदान करते हैं।
3. ये लॉग सबसे पहले सार्वजनिक कैसे हुए?
लॉग फ़ाइलें गूगल में अपने आप प्रकट नहीं होतीं। वे इंडेक्स हो जाती हैं क्योंकि वे सार्वजनिक रूप से उपलब्ध होती हैं।
3.1 गलत तरीके से कॉन्फ़िगर किए गए वेब सर्वर
सामान्य पैटर्न में निम्नलिखित शामिल हैं:
/logs/बिना प्रमाणीकरण के पहुंच योग्य निर्देशिकाएँ- डायरेक्टरी लिस्टिंग सक्षम
- Nginx या Apache द्वारा रॉ डेटा सर्व करना
.logफ़ाइलों
यदि कोई लॉग HTTP के माध्यम से पहुंच योग्य है, तो वह इंडेक्सेबल है।
3.2 CI/CD कलाकृति प्रदर्शन
विशिष्ट गलतियाँ:
- सार्वजनिक कलाकृतियाँ सक्षम की गईं गिटहब क्रिया
- लॉग्स को ओपन एस3 बकेट में अपलोड कर दिया गया है।
- Pipeline प्रमाणीकरण के बिना भी ट्रेस तक पहुंचा जा सकता है
A pipeline जो लॉग को सार्वजनिक बकेट में संग्रहीत करता है, वह प्रभावी रूप से अपने रहस्यों को प्रकाशित कर देता है।
3.3 उत्पादन में डिबग मोड
फ्रेमवर्क के डिफ़ॉल्ट सेटिंग्स खतरनाक हो सकती हैं:
इसके अतिरिक्त, अत्यधिक अनुरोध लॉगिंग से निम्न जानकारी प्रिंट हो सकती है:
- शीर्ष लेख
- टोकन
- पूर्ण अनुरोध निकाय
उत्पादन में डिबग लॉगिंग आपके एप्लिकेशन को क्रेडेंशियल निर्यातक में बदल देती है।
3.4 डॉकर और कंटेनर लॉग
कंटेनरीकृत वातावरण जोखिम के नए रास्ते खोलते हैं:
- लॉग साझा वॉल्यूम में माउंट किए गए
- साइडकार असुरक्षित एंडपॉइंट्स पर लॉग निर्यात कर रहे हैं
- लॉग इन dashboardसार्वजनिक पहुंच वाले
यदि कंटेनर लॉग HTTP या ओपन स्टोरेज के माध्यम से उपलब्ध कराए जाते हैं, तो वे खोजे जा सकते हैं। अंततः, उन्हें इंडेक्स किया जाता है।
4. यथार्थवादी आक्रमण प्रवाह: डॉर्क से ब्रीच तक
एक सामान्य हमले की श्रृंखला कुछ इस प्रकार दिखती है:
हमलावर चलाता है:
- खुला पाया गया
.logपट्टिका - अर्क:
- JWT टोकन
- बेसिक ऑथ हेडर
- डेटाबेस कनेक्शन स्ट्रिंग
प्रमाणीकरण का प्रयास किया जा रहा है:
- एपीआई समापन बिंदु
- व्यवस्थापक पैनल
- आंतरिक सेवाएँ
प्रमाणीकरण सफल होने पर हमलावर निम्न कार्य कर सकता है:
- विशेषाधिकार बढ़ाएँ
- पार्श्व दिशा में आगे बढ़ें
- पहुँच CI/CD
- आपूर्ति श्रृंखला से समझौता करें
जो एक खोज प्रश्न के रूप में शुरू हुआ था, वह बन जाता है:
- सत्र अपहरण
- आंतरिक प्रमाण पत्र में हेरफेर
- Pipeline अधिग्रहण
- कलाकृतियों में विषाक्तता
यह सब एक सार्वजनिक रूप से अनुक्रमित लॉग फ़ाइल से लिया गया है।
5. अत्यधिक लॉगिंग करना ऐप सुरक्षा के लिए समस्या क्यों है?
लॉगिंग तटस्थ नहीं है। बल्कि, यह एक स्थिति उत्पन्न करती है। द्वितीयक डेटा स्टोर.
यदि आप संवेदनशील डेटा को लॉग करते हैं, तो आप प्रभावी रूप से अपने रहस्यों की दूसरी प्रति बना लेते हैं।
हालांकि, लॉग को अक्सर थ्रेट मॉडलिंग से बाहर रखा जाता है। STRIDE के अंतर्गत, यह स्पष्ट रूप से निम्न से मेल खाता है:
प्रकटीकरण सूचना
इसलिए, सुरक्षित SDLC अभ्यासकर्ताओं को लॉग को इस प्रकार मानना चाहिए:
- सुरक्षा-संबंधी कलाकृतियाँ
- संवेदनशील संपत्तियाँ
- बुनियादी ढांचे के वे घटक जिन्हें सुरक्षा की आवश्यकता है
यदि आपका थ्रेट मॉडल लॉग को अनदेखा करता है, तो वह अधूरा है।
6. लॉग फाइलों में क्रेडेंशियल लीक होने से कैसे रोकें
6.1 गुप्त जानकारी लॉग करना बंद करें
कभी लॉग इन न करें:
- पासवर्ड
- टोकन
- एपीआई कुंजी
- सत्र आईडी
- प्राधिकरण शीर्षलेख
यहां तक कि डिबग मोड में भी।
जब भी संभव हो, स्वचालित संपादन लागू करें।
6.2 संरचित और सुरक्षित लॉगिंग
मास्किंग और फ़िल्टरिंग के साथ संरचित लॉगिंग का उपयोग करें।
उदाहरण (नोड.जेएस):
उदाहरण (पायथन):
मूल सिद्धांत सरल है: गुप्त जानकारी कभी भी लॉग सिंक तक नहीं पहुंचनी चाहिए।
6.3 लॉग स्टोरेज को लॉक डाउन करें
सुरक्षा नियंत्रणों में निम्नलिखित शामिल होने चाहिए:
- निर्देशिका सूची को अक्षम करें
- रक्षा करना
/logs/प्रमाणीकरण के साथ पथ - बकेट तक पहुंच प्रतिबंधित करें
- प्रतिधारण नीतियों को लागू करें
- संग्रहीत लॉग को एन्क्रिप्ट करें
लॉग फ़ाइलें कभी भी HTTP के माध्यम से सार्वजनिक रूप से सुलभ नहीं होनी चाहिए।
6.4 CI/CD Guardrails
मैन्युअल समीक्षाएँ अपर्याप्त हैं। इसके बजाय, स्वचालित नियंत्रण लागू करें:
- कलाकृतियों के प्रकाशन से पहले लॉग की गुप्त स्कैनिंग
- टोकन पाए जाने पर बिल्ड प्रक्रिया विफल करें
- क्रेडेंशियल वाले आर्टिफैक्ट अपलोड को रोकें
- कलाकृतियों के लिए हैश सत्यापन
CI/CD इंडेक्सिंग होने से पहले एक्सपोजर को ब्लॉक कर देना चाहिए।
7. ज़ाइगेनी किस प्रकार रोकता है allintext:login फ़ाइल प्रकार: लॉग घटनाएँ
समस्या गूगल डॉर्क नहीं है। समस्या एक्सपोज़र है। इसलिए, इंडेक्सिंग से पहले रोकथाम आवश्यक है।
7.1 लॉग और कलाकृतियों में गुप्त पहचान
ज़ाइजेनी स्कैन:
- आवेदन लॉग
- CI/CD नौकरी के निशान
- कलाकृतियाँ बनाएँ
- डॉकर परतें
- क्रमबद्ध आउटपुट
यदि क्रेडेंशियल, टोकन या संवेदनशील मान दिखाई देते हैं .log Xygeni फाइलों को तुरंत चिह्नित कर देता है।
7.2 CI/CD Guardrails उस ब्लॉक एक्सपोजर
मैन्युअल समीक्षाओं पर निर्भर रहने के बजाय, Xygeni सुरक्षा व्यवस्था को लागू करता है। pipeline का स्तर:
यह:
- लॉग में गुप्त जानकारी दिखाई देने पर बिल्ड विफल हो जाता है
- ब्लॉक कलाकृति प्रकाशन
- सार्वजनिक रूप से आकस्मिक रूप से उजागर होने से बचाता है
- मुख्य भाग तक पहुँचने से पहले असुरक्षित विलय को रोकता है
यदि कोई CI जॉब टोकन प्रिंट करता है, तो pipeline विफल रहता है।
कोई इंडेक्सिंग नहीं।
कोई जोखिम नहीं।
कोई घटना नहीं हुई।
7.3 गूगल द्वारा देखे जाने से पहले शिफ्ट-लेफ्ट सुरक्षा
समय का महत्व है।
प्रतिक्रिया देने के बजाय:
Xygeni इस समस्या को हल करता है:
- At commit पहर
- दौरान pull request सत्यापन
- दौरान pipeline निष्पादन
- कलाकृति प्रकाशन से पहले
अगर लॉग कभी सार्वजनिक नहीं होता, तो गूगल उसे कभी इंडेक्स नहीं करता।
निष्कर्ष: अगर गूगल इसे इंडेक्स कर सकता है, तो हमलावरों ने इसे पहले ही कर लिया होगा।
लॉग फाइलें हानिरहित नहीं होतीं। वास्तव में, वे शायद ही कभी अस्थायी होती हैं। आम तौर पर, वे गोपनीय नहीं होतीं। इसलिए, प्रत्येक लॉग फाइल को सुरक्षा की दृष्टि से महत्वपूर्ण संपत्ति के रूप में माना जाना चाहिए, न कि केवल डिबगिंग आउटपुट के रूप में।
यदि संवेदनशील डेटा किसी तक पहुँचता है .log फाइल सार्वजनिक रूप से सुलभ हो जाती है, यह तुरंत हमले का केंद्र बन जाता है। इसके अलावा, एक बार सर्च इंजन द्वारा इंडेक्स किए जाने के बाद, इसकी पहुंच आपके नियंत्रण से परे हो जाती है।
इसका समाधान लॉगिंग को रोकना नहीं है। बल्कि, जिम्मेदारी से लॉगिंग करना और भंडारण एवं वितरण पर सख्त नियंत्रण लागू करना है। दूसरे शब्दों में, सुरक्षा को एप्लिकेशन तक ही सीमित न रखकर अवलोकन परत तक विस्तारित करना होगा।
बजाय:
- गुप्त जानकारी लॉग करना बंद करें
- लकड़ी के भंडारण को बंद करें
- लागू करना pipeline guardrails
- पहचान और नीति प्रवर्तन को स्वचालित करें
अंत में, रोकथाम समय पर निर्भर करती है। क्योंकि एक बार allintext:login फ़ाइल प्रकार: लॉग यदि आपका डोमेन वापस आ जाता है, तो घटना पहले ही शुरू हो चुकी है।
