2 पॉइंट द्वारा GN⁺ 2024-02-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें

S3 bucket का AWS account ID पता करना

  • 2021 में Ben Bridts ने सार्वजनिक रूप से एक्सेस किए जा सकने वाले S3 bucket का AWS account ID पता करने का एक अनोखा तरीका प्रकाशित किया था.
  • यह लेख private और public, दोनों तरह के S3 bucket के account ID पता करने की तकनीक समझाता है.

S3 bucket से AWS account ID तक

  • shell output के ज़रिए bucket-alpha नाम के bucket का पहले से अज्ञात AWS account ID पता करने की तकनीक दिखाई गई है.

यह तकनीक वास्तव में कैसे काम करती है?

  • Ben की तकनीक क्यों काम करती है, इसका विश्लेषण करते हुए तीन मुख्य तत्वों को जोड़ा गया है:
    • request पर IAM policy लागू करने की क्षमता
    • यह अनुमान लगाने की क्षमता कि IAM policy ने request को allow किया या नहीं
    • s3:ResourceAccount condition key पर wildcard match लागू करने की क्षमता

समाधान

  • S3 के लिए VPC endpoint का उपयोग करके और CloudTrail में request reject होने पर व्यवहार के अंतर का लाभ उठाकर एक समाधान खोजा गया.

चरण-दर-चरण देखें

  • जब bucket bucket-alpha का account ID पता करना हो, तब यह step-by-step प्रक्रिया अपनाई जाती है:
    • bucket region निर्धारित करना
    • उसी region में VPC और VPC endpoint deploy करना
    • VPC के भीतर EC2 instance शुरू करना और यह पुष्टि करना कि S3 के लिए VPC endpoint इस्तेमाल हो रहा है
    • VPC endpoint policy में बदलाव करके यह तय करना कि target bucket का account ID "0" से शुरू होता है या नहीं
    • target bucket को request भेजना
    • CloudTrail में देखना कि request दिखाई देती है या नहीं
    • नतीजों के आधार पर VPC endpoint policy बदलकर account ID के बारे में और जानकारी निकालना

परिणाम

  • इस प्रक्रिया को automate करने के लिए एक script लिखी गई, जिससे bucket का account ID भरोसेमंद तरीके से पता किया जा सकता है.
  • ज़रूरी tests की संख्या कम करने के लिए हर digit पर binary search की जाती है.

गति में सुधार

  • VPC endpoint policy के प्रभावी होने और CloudTrail में हर result का अलग-अलग इंतज़ार करने में लगने वाला समय घटाने के लिए VPC endpoint policy में बदलाव किया गया.
  • इससे account ID पता करने का समय घटकर 10 मिनट से कम रह गया.

राय

  • AWS security team से चर्चा करने के बाद यह blog post प्रकाशित की गई.
  • AWS account ID को sensitive information माना जाना चाहिए या नहीं, इस पर दिलचस्प चर्चा हुई.
  • यह तकनीक S3 के अलावा दूसरी services पर भी लागू हो सकती है.
  • ये तकनीकें इसलिए संभव हैं क्योंकि s3:ResourceAccount के लिए StringLike condition का उपयोग किया जा सकता है.
  • VPC endpoint policy द्वारा reject किए गए events का CloudTrail में log होना उपयोगी हो सकता है.

आभार

  • Ben Bridt की मूल तकनीक ने इस काम को प्रेरित किया.
  • Chris Farris की मदद और सलाह के लिए धन्यवाद.

GN⁺ की राय

  • यह तकनीक cloud environment में security audit करने के लिए बेहद उपयोगी हो सकती है, खासकर AWS S3 bucket की ownership सत्यापित करने में.
  • इस तकनीक से मिलने वाली जानकारी की संवेदनशीलता पर चर्चा, cloud service provider और users के बीच data security और privacy पर चल रही व्यापक बातचीत को दर्शाती है.
  • इसी तरह की क्षमता देने वाले अन्य tools में AWS की अपनी service CloudTrail शामिल है, जिसका उपयोग उपयोगकर्ता के AWS environment में होने वाली सभी गतिविधियों को log और monitor करने के लिए किया जाता है.
  • इस तकनीक को अपनाने से पहले users को सुनिश्चित करना चाहिए कि यह AWS की policies और security best practices के अनुरूप हो.
  • इस तकनीक के फायदे हैं efficient security audit और data ownership की तेज़ पुष्टि, लेकिन संभावित privacy exposure जैसे जोखिमों पर भी विचार करना चाहिए.

1 टिप्पणियां

 
GN⁺ 2024-02-27
Hacker News राय
  • AWS के s3:ResourceAccount condition key पर wildcard match लागू करने की क्षमता

    • इस फीचर की चौंकाने वाली बात यह है कि partial account ID match के आधार पर permissions देना या deny करना सही ठहराने का कोई वाजिब कारण नहीं है। AWS account ID, IP address की तरह, संवेदनशील हो सकती है, लेकिन काम आगे बढ़ाने के लिए किसी न किसी को इसे जानना ही पड़ता है.
  • AWS account ID == आपका IP address. यह संवेदनशील हो सकता है, लेकिन काम पूरा करने के लिए किसी को इसे जानना ही होगा.

    • उदाहरण: लेखक ने anti-money laundering प्रक्रिया के कारण एक third party के साथ integration करना था, और खुले sftp port की तुलना में आम तौर पर अधिक सुरक्षित privatelink setup चाहता था। लेकिन उस कंपनी ने account ID छिपाने की security concern के कारण मना कर दिया। नतीजतन, लेखक की टीम ने उनके public IP range को port 22 पर whitelist कर दिया.
    • इस कहानी का सबक: ID छिपाना समझदारी लग सकता है, लेकिन अगर लोगों के पास आपसे संपर्क करने का कोई पता ही न हो, तो आप वास्तव में business नहीं चला सकते.
  • आम तौर पर आप account ID को सार्वजनिक रूप से distribute नहीं करेंगे, लेकिन किसी बिंदु पर इसके कुछ हिस्से सार्वजनिक हो जाने की उम्मीद रखनी चाहिए.

    • जैसे-जैसे third-party vendors और SaaS platforms IAM users और access keys से हटकर role assumption को प्राथमिकता देने वाले integration तरीकों की ओर बढ़ रहे हैं, integration point के रूप में इस्तेमाल होने वाले account का account ID दूसरे पक्षों को पता होता है, और उनकी अपनी dependencies और vulnerabilities होती हैं.
  • global namespace वाले अन्य public AWS resources भी AWS account ID उजागर करते हैं.

    • रुचि रखने वालों के लिए, संबंधित code यहाँ ऑनलाइन पोस्ट किया गया है: find-s3-account
  • संबंधित: AWS key ID (secret key वाला हिस्सा नहीं) में account ID शामिल होता है, बस एक position से bit-shift किया गया होता है.

    • यह key ID S3 के presigned links के URL में शामिल होता है, इसलिए संभव है कि आप पहले से ही account ID सार्वजनिक कर रहे हों.
  • दिलचस्प खोज है, लेकिन शीर्षक देखकर मुझे उम्मीद थी कि कोई और आसान तरीका होगा.

    • काश AWS में admin account से यह पूछने का कोई आसान तरीका होता कि "resource X कहाँ है"। खासकर यह जल्दी बताने वाली कोई सुविधा कि कोई खास S3 bucket किस account में है। यह मुख्य रूप से उन legacy buckets की समस्या है जो code में define किए जाने से पहले से मौजूद थे। जब आपके पास बहुत सारे AWS accounts हों, तो अज्ञात accounts और संभावित regions में resources ढूँढना झंझट भरा हो सकता है.
  • असली hacking का वह scenario, जो "एक बार में एक character करके password को 'hack' करना" जैसी पुरानी cliché या गलतफहमी को सामने लाता है, हमेशा मजेदार होता है.

  • अब ज्यादा चिंताजनक attack vector यह है कि account number का उपयोग करके दूसरे account के principals को अपनी account policy की allowlist में जोड़ने की कोशिश की जाए.

    • अगर उस दूसरे account में वह principal मौजूद न हो, तो role/user नहीं मिला जैसी error आती है। इसका इस्तेमाल करके दूसरे account के वास्तविक principals का पता लगाया जा सकता है.
  • यह क्यों मायने रखता है? एक स्पष्ट बात: अगर production bucket दिया गया हो, तो उसी organization के development buckets खोजे जा सकते हैं, जो एक अप्रत्याशित behavior है.