- AWS ने S3 bucketsquatting समस्या को हल करने के लिए एक नया account-based namespace protection feature पेश किया है
- नया namespace
<prefix>-<accountid>-<region>-an फ़ॉर्मेट में है, और उसी account को उस नाम का bucket बनाने की अनुमति देता है
- अगर कोई दूसरा account वही नाम इस्तेमाल करने की कोशिश करे, तो
InvalidBucketNamespace error मिलता है, और गलत region देने पर भी यही error लौटता है
- इस namespace को डिफ़ॉल्ट रूप से इस्तेमाल करने की सिफारिश की गई है, और organization policy (SCP) में
s3:x-amz-bucket-namespace condition key से इसे enforce किया जा सकता है
- यह मौजूदा buckets पर retroactive तरीके से लागू नहीं होता, लेकिन नए buckets के लिए मज़बूत protection देता है, जो S3 security architecture में बुनियादी सुधार को दर्शाता है
Bucketsquatting समस्या का अवलोकन
- Bucketsquatting (या Bucketsniping) AWS S3 में bucket names के globally unique होने की विशेषता का दुरुपयोग करने वाला एक attack है
- bucket delete होने के बाद उसका नाम फिर से उपलब्ध हो जाता है, इसलिए attacker उसी नाम से नया bucket register कर सकता है
- इससे sensitive data access या service disruption का जोखिम पैदा हो सकता है
- organizations अक्सर
myapp-us-east-1 जैसे predictable naming rules इस्तेमाल करती थीं, जिससे attack exposure बढ़ जाता था
- AWS की internal teams भी इस समस्या से प्रभावित हुई थीं, और लगभग 10 साल तक AWS security team के साथ मिलकर इसका समाधान खोजा गया
नया S3 namespace पेश किया गया
- AWS ने इस समस्या के समाधान के लिए account namespace की अवधारणा पेश की
- फ़ॉर्मेट:
<prefix>-<accountid>-<region>-an
- उदाहरण:
myapp-123456789012-us-west-2-an
- यह namespace केवल उसी account को उस नाम का bucket बनाने की अनुमति देता है
- अगर कोई दूसरा account वही नाम बनाता है, तो
InvalidBucketNamespace error मिलता है
- bucket name में दिया गया region अगर actual region से मेल नहीं खाता, तब भी यही error लौटता है
- AWS ने सभी नए buckets के लिए डिफ़ॉल्ट रूप से इस namespace का उपयोग करने की सिफारिश की है
- मौजूदा namespaces (
.mrap, --x-s3, -s3alias) से अलग, इस बार इसे security purpose के लिए सामान्य users के namespace के रूप में पेश किया गया है
policy लागू करना और प्रबंधन
- security administrators
s3:x-amz-bucket-namespace condition key का उपयोग करके पूरे organization की policy (SCP) के जरिए namespace usage को enforce कर सकते हैं
- यह मौजूदा buckets या बिना namespace वाले templates पर अपने-आप लागू नहीं होता
- मौजूदा buckets को सुरक्षित करने के लिए नए namespace फ़ॉर्मेट में bucket बनाना होगा और data migrate करना होगा
- इस कदम की वजह से bucketsquatting व्यावहारिक रूप से “खत्म होने की ओर” है, और नए buckets को पूर्ण protection मिलता है
अन्य cloud providers का approach
- Google Cloud Storage (GCS) पहले से ही domain name verification-based namespace इस्तेमाल करता है
myapp.com जैसे domain-format buckets केवल domain owner ही बना सकते हैं- non-domain-format buckets में अब भी bucketsquatting की संभावना मौजूद है
- Azure Blob Storage storage account name + container name संरचना का उपयोग करता है
- अधिकतम 24 characters की सीमा होने से namespace छोटा हो जाता है, इसलिए यह उसी समस्या के प्रति अधिक संवेदनशील हो सकता है
निष्कर्ष (tl;dr)
- AWS S3 में नया account-region namespace पेश किया गया है
- यह namespace bucketsquatting attacks को रोकता है, और नए bucket बनाते समय इसका उपयोग करना दृढ़ता से सुझाया गया है
- मौजूदा buckets अपने-आप सुरक्षित नहीं होते, इसलिए जरूरत पड़ने पर data migration के जरिए protection बढ़ानी होगी
1 टिप्पणियां
Hacker News टिप्पणियाँ
हाल ही में पता चला कि AWS अकाउंट डिलीट करने के बाद भी root user email address को दोबारा इस्तेमाल नहीं किया जा सकता
हमारे संगठन में किसी ने कंपनी के मुख्य ईमेल से बंद हो चुके अकाउंट का root user बनाया था, और नए अकाउंट के लिए दूसरा ईमेल इस्तेमाल किया, लेकिन अब डिलीशन रिकवरी अवधि भी निकल चुकी है
नतीजतन, वह ईमेल डिलीट किए गए root अकाउंट से स्थायी रूप से बंध गया है, इसलिए बाहरी IdP के जरिए SSO लॉगिन संभव नहीं रहा
AWS सपोर्ट से संपर्क किया, लेकिन लगभग कोई मदद नहीं मिली
पासवर्ड दस्तावेज़ में था, लेकिन MFA हटाने का कोई तरीका नहीं था, इसलिए AWS सपोर्ट, अकाउंट प्रतिनिधि आदि से संपर्क किया गया, पर समाधान नहीं मिला
आखिरकार root अकाउंट तक पहुँच बंद है, और शायद पूरे जटिल environment को नए अकाउंट में शिफ्ट करना पड़े
AWS plus वाले ईमेल को अलग address मानता है
इसे केवल तब इस्तेमाल करना बेहतर है जब वास्तव में बहुत गंभीर समस्या हो
आखिर किसी phisher ने customer support टीम को धोखा देकर 10/10 रेटिंग ले ली, तो सब कुछ टूट सकता है
वास्तव में कौन-सा mechanism इस्तेमाल को रोकता है, यह समझना चाहता हूँ
लगता है लेखक ने Azure Blob Storage के account name कॉन्सेप्ट को गलत समझा
यह व्यवहार में S3 के bucket name के ही बराबर है, और global uniqueness चाहिए, इसलिए यह अब भी बड़ी असुविधा है
खासकर name length सिर्फ 24 characters होने से और भी परेशानी होती है
Microsoft को भी AWS की तरह customer-specific namespace लाना चाहिए
लेकिन शुरुआती design constraints की वजह से इसे बदला नहीं जा सका
व्यक्तिगत रूप से समझ नहीं आता कि अब तक S3 v2 API क्यों नहीं बनाया गया
नए API से gradual migration करवाया जा सकता था, लेकिन अंत में ग्राहक और engineer दोनों बेवजह की परेशानी झेल रहे हैं
इसलिए केवल numbers और lowercase letters ही इस्तेमाल किए जा सकते हैं, जो बहुत असुविधाजनक है
काश S3 या GCS की तरह कम से कम dash तो allowed होता
container registry जैसे दूसरे resources में भी यही स्थिति है
package name, bucket name, GitHub account name वगैरह के लिए Discord जैसा @name-random4digits फॉर्मेट कैसा रहेगा, ऐसा विचार आया
इससे namespace का लोकतंत्रीकरण होगा और squatting या reuse attacks को रोका जा सकेगा
अकाउंट डिलीट होने पर पूरा नाम रिटायर किया जा सकता है, इसलिए यह साफ-सुथरा तरीका है
वजह आधिकारिक घोषणा में समझाई गई है,
यानी 4-अंकों की संख्या याद रखना पड़ता था और case sensitivity भी झेलनी पड़ती थी
खासकर chat apps में internal ID इस्तेमाल हो और user सिर्फ alias इस्तेमाल करे, तो यह ज्यादा साफ लगता है
bucket के मामले में human-readable name ही मुख्य बात है, इसलिए बेहतर होगा कि अपना domain इस्तेमाल किया जाए
उल्टा typo का जोखिम बढ़ जाता है
online communities में नाम टकराना स्वाभाविक बात है,
फिर आखिर global unique names को मजबूरी क्यों बनाया जाए, यह सवाल है
लेखक Ian Mckay का धन्यवाद
AWS ने आधिकारिक रूप से account और region-स्तरीय namespace अपनाया है, यह अच्छा बदलाव है
Terraform जैसे IaC tools अगर इस नियम को default के रूप में अपना लें, तो और बेहतर होगा
Terraform पहले से ही bucket name के अंत में random hash suffix जोड़कर टकराव रोकता है
AWS आधिकारिक ब्लॉग में भी इससे जुड़ी जानकारी है
यह दिलचस्प है कि cloud providers जब अपने internal scratch space के लिए predictable bucket names इस्तेमाल करते हैं, तब bucket squatting attacks पैदा हो जाते हैं
AWS में hash की वजह से वास्तविक हमला कठिन था, लेकिन GCP हाल तक भी ऐसी समस्या झेलता रहा
संबंधित प्रस्तुति: DC32 AWS bucket squatting talk,
GCP vulnerability: CVE-2026-1727
जैसे ही देखा कि bucket names का अनुमान लगाया जा सकता है, खतरे का अहसास तुरंत हो गया
bucket squatting + public bucket + CloudFormation की TOCTOU समस्या का संयोजन हो,
तो दूसरे अकाउंट में resources deploy करना भी संभव हो सकता था
यह हैरानी की बात है कि AWS security टीम ने इसे और पहले नहीं पकड़ा
DNS names में भी इसी तरह की समस्या होती है
अगर domain renew न किया जाए, तो कोई उसे फिर से register कर सकता है,
और MX record सेट करके password reset emails जैसी चीज़ों को intercept कर सकता है
AWS buckets अब भी सिर्फ तभी special features देते हैं जब उनका name hostname के समान हो
संबंधित दस्तावेज़: Virtual Hosting in S3
नाम उस चीज़ के समान नहीं होना चाहिए जिसका वह संदर्भ देता है
अगर नाम दोबारा इस्तेमाल हो, तो वह पूरी तरह अलग चीज़ की ओर इशारा करने लगता है,
और उसका अर्थ संदर्भ के अनुसार बदल जाता है
केवल तब उसे वही माना जा सकता है जब आप स्वयं नाम को फिर से असाइन करें
यह जिज्ञासा थी कि अकाउंट ID को सार्वजनिक करना security risk है या नहीं
आधिकारिक दस्तावेज़ के अनुसार,
इसे सावधानी से संभालना चाहिए, लेकिन sensitive information नहीं माना जाता
बहुत ज्यादा उजागर न किया जाए, तो ठीक है
IAM rules में attacker
*इस्तेमाल कर सकता है, इसलिए अंततः defender की policy configuration ज़्यादा महत्वपूर्ण हैउसे base32 में decode करने पर Account ID निकाला जा सकता है
संदर्भ: संबंधित विश्लेषण लेख
S3 का सिर्फ bucket name को access key की तरह इस्तेमाल करना design के लिहाज़ से सबसे झुंझलाने वाले फैसलों में से एक था