किसी भी S3 बकेट का AWS अकाउंट ID कैसे खोजें
एक नई तकनीक दिखाती है कि IAM condition matching का दुरुपयोग करके किसी भी दिए गए S3 बकेट के मालिक AWS अकाउंट ID का अनुमान कैसे लगाया जा सकता है, जिससे यह सवाल उठता है कि पहले निहित रहे कौन-से metadata अब मैप और correlate किए जा सकते हैं। टिप्पणीकार मोटे तौर पर सहमत हैं कि AWS अकाउंट IDs को secret नहीं माना जाना चाहिए—AWS यह बात स्पष्ट रूप से कहता है—लेकिन इस पर बहस करते हैं कि क्या operational security या correlation risks के लिए उन्हें “sensitive” मानना फिर भी उपयोगी है। कई लोग इसे याद दिलाने के रूप में देखते हैं कि सुरक्षा को छिपे हुए identifiers या obscurity पर निर्भर नहीं होना चाहिए, और कि cross-account misconfigured policies तथा metadata leakage ही वे वास्तविक खतरे हैं जिन्हें संबोधित करना चाहिए।
खोज का दायरा
- तकनीक S3 बकेट नीतियों और वाइल्डकार्ड के साथ
s3:ResourceAccountशर्तों का उपयोग करके यह अनुमान लगाती है कि कोई दिया गया बकेट किस AWS अकाउंट का है। - कई लोग इसे सीधे उल्लंघन की बजाय एक दिलचस्प साइड चैनल मानते हैं: एक्सेस पाने के लिए फिर भी गलत कॉन्फ़िगरेशन या अतिरिक्त जानकारी चाहिए।
क्या AWS अकाउंट IDs गुप्त या संवेदनशील हैं?
- AWS डॉक्स स्पष्ट रूप से कहते हैं कि अकाउंट IDs न तो गुप्त हैं, न संवेदनशील, न गोपनीय।
- एक पक्ष: अकाउंट IDs को सार्वजनिक मानना चाहिए; ऐसी प्रणालियाँ बनाना जो उनकी गोपनीयता पर निर्भर हों, खराब सुरक्षा और एक “गलत धारणा” है।
- दूसरा पक्ष: वे “गुप्त” नहीं हैं, लेकिन फिर भी “संवेदनशील” हैं; उनका लीक होना हमलावरों के लिए मूल्य जोड़ता है और जहाँ व्यावहारिक हो, उसे कम से कम किया जाना चाहिए।
ऑपरेशनल सिक्योरिटी और मेटाडेटा लीक
- मुख्य चिंता कच्चे IDs की नहीं, बल्कि संबंधों की है:
- एक ही मालिक से कई बकेट्स को जोड़ना (जैसे अलग-अलग ब्रांड, क्लाइंट, आंतरिक प्रोजेक्ट्स)।
- “छिपे” या staging बकेट्स को किसी ज्ञात production अकाउंट से जोड़ना।
- बिज़नेस इंटेलिजेंस / जासूसी के उपयोग-केस (जैसे बकेट नामों से प्रोजेक्ट्स के बारे में जानना)।
- कुछ लोगों के अनुसार यह सुरक्षा नहीं, opsec है; अन्य तर्क देते हैं कि opsec भी वास्तव में महत्वपूर्ण है।
Security by Obscurity पर बहस
- कई लोगों का कहना है कि obscurity अधिकतम एक कमजोर, न-रोटेट-होने वाली परत है और इसे कभी भी नियंत्रण के रूप में भरोसा नहीं करना चाहिए।
- दूसरे लोग जवाब देते हैं कि “सार्वजनिक नहीं लेकिन गुप्त भी नहीं” जानकारी एक वैध opsec चिंता है और इसका मतलब यह नहीं कि आप इसे access-control mechanism की तरह इस्तेमाल कर रहे हैं।
- सहमति का बिंदु: IAM या threat models इस धारणा पर न बनाएं कि अकाउंट ID छिपी रहेगी।
IAM Wildcards और Policy Design
- बहुतों को आश्चर्य है कि IAM अकाउंट IDs पर wildcard (
StringLike) matching की अनुमति देता है; कई लोगों को इसमें कोई वैध access-control use case नहीं दिखता। - दिए गए स्पष्टीकरण:
- एक सामान्य, loosely typed policy language जो सरलता के लिए हर जगह string operators लागू करता है।
- संभावित लेकिन संदिग्ध उपयोग (prefix के आधार पर कई accounts को bucket करना, sharding, policy size reduction)।
संबंधित Enumeration Vectors और Tools
- AWS access key IDs में अकाउंट ID embedded होता है और वे pre-signed URLs में दिखाई देते हैं, इसलिए बहुत से IDs पहले से ही लीक हो रहे थे।
- अन्य global namespaces (जैसे AMI vendors, अन्य public resources) स्वाभाविक रूप से अकाउंट IDs उजागर करते हैं।
- AWS Config के साथ org-wide aggregation और Athena को आंतरिक रूप से यह खोजने का “सही” तरीका बताया गया है कि कौन-सा अकाउंट किस resource का मालिक है, हालांकि यह मुफ्त नहीं है।