AWS आउटेज के बाद AWS अकाउंट हैक हुआ

 (news.ycombinator.com)
1 पॉइंट द्वारा GN⁺ 2025-10-22 | 1 टिप्पणियां | WhatsApp पर शेयर करें

हाल ही में AWS में हुई सेवा आउटेज के बाद, एक उपयोगकर्ता ने बताया कि उसका AWS अकाउंट बाहरी हमलावर द्वारा हैक कर लिया गया।

उल्लंघन का रास्ता और समस्या की स्थिति

  • आउटेज की अवधि में कुछ सुरक्षा नीतियाँ सामान्य रूप से काम न कर पाने की संभावना सामने आई।
  • हमलावर ने आउटेज के बाद एकाउंट लॉग में असामान्य एक्सेस के निशान छोड़े, और कुछ संसाधनों के अचानक निर्माण/हटाने की घटना देखी गई।
  • उपयोगकर्ता ने आउटेज के साथ अधिकार परिवर्तन या प्रमाणीकरण क्रेडेंशियल के उजागर होने की संभावना को लेकर चिंता जताई।

नुकसान और प्रतिक्रिया

  • लागत में वृद्धि, डेटा लीक आदि वास्तविक नुकसान हुए।
  • AWS सपोर्ट टीम से संपर्क कर घटना का विवरण और निवारण के तरीके पूछे।
  • समुदाय ने दो-फैक्टर ऑथेंटिकेशन (2FA) सक्रिय करने, रोल-बेस्ड एक्सेस और न्यूनतम विशेषाधिकार जैसे पूर्व-निवारण की अहमियत पर जोर दिया

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-10-22
Hacker News टिप्पणी

  • आमतौर पर लगता है कि ऐसे मामले अक्सर सिर्फ संयोग होते हैं, लेकिन मेरे साथ भी क्लाइंट के account के compromise होने का एक केस आया था। ग्राहक एक छोटा संगठन था, और दो पुराने IAM account जो 5 साल से ज़्यादा इस्तेमाल नहीं हो रहे थे, उनमें अचानक console login और password बदलने का इतिहास दिखा। जांच में अब तक जो पता चला, वह बस इतना ही था कि AWS SES production access enable करने और daily email limit को 50,000 तक बढ़ाने के लिए एक support ticket बनाया गया था। 5 साल से अधिक समय से निष्क्रिय रहे account का ठीक इसी समय सक्रिय हो जाना बहुत अजीब है।

    • इसमें phishing attack की गंध आती है। उदाहरण के लिए, अगर कोई AWS outage notice के नाम पर ईमेल भेजकर console login के लिए lure करे और बाद में malicious wrapper के जरिए authenticate करे, तो account security टूट सकती है।
    • लगभग यही काम मैंने करीब एक साल पहले खुद झेला था। बहुत पुराने account से login, SES access, और email quota बढ़ाने का अनुरोध। हमने जल्दी respond कर पाए क्योंकि quota बढ़ाने वाला ticket ज़रूरी था। अगर अभी तक नहीं देखा है तो नए बनाए गए Roles भी check करना चाहिए। हमने तुरंत समझौता किए गए account साफ़ कर दिए, और पूरे Roles को देखते हुए जो एक महीने से कम पुराने थे या जिनमें admin privilege था, उन्हें हटा दिया। दूसरी तरफ हमने यह भी confirm किया कि compromise सच में मेरे ही key से शुरू हुआ था। वास्तविक SES request से लगभग एक महीना पहले उस user को बनाया गया था, और संभव है attacker पहले से हमें breach करके बैठा हो, फिर AWS outage आते ही उसने मौका लिया हो। इसे अन्य AWS मुद्दों के साथ mix करके शायद ठीक से दिखा नहीं।

  • शायद किसी को पहले से access मिल चुका हो और वह AWS infrastructure में किसी बड़े disruption की प्रतीक्षा करता हो, फिर उसी समय attack करके उस हंगामे में छिप जाए। यदि token कुछ हफ्तों या महीनों पहले leak हो गया हो, फिर भी तुरंत action न लेकर किसी बड़े incident का इंतज़ार करना एक strategy हो सकती है। अगर मैं attacker होता, तो शायद यही तरीका चुनता।

    • निश्चित रूप से संभव। एक security audit में काम करते हुए भी मैंने ऐसे वास्तविक केस सुने हैं। attackers अक्सर पहले से पूरी तैयारी करके कंपनी के sale जैसे major events का wait करते हैं और फिर move करते हैं। जितना mature attacker, उतना ही ऐसे मौके के लिए पहले से plan करता है।
    • उसी टीम का होने के नाते, सच में आज exploited key से संबंधित warning email हमने दो साल पहले किसी random व्यक्ति से पाया था। लेकिन कल तक कोई misuse नहीं दिखा।
    • दरअसल यह शायद attack के लिए गलत timing हो। अभी सबकी नज़र AWS पर होती है और सभी ज़्यादा login कर रहे होते हैं, इसलिए कोई anomaly दिख जाए तो जल्दी notice होगी। अगर हमारी कंपनी AWS चला रही होती, तो इस स्थिति में हम हर चीज़ पर और भी अधिक नज़र रखते।

  • अगर मैं attacker होता और attack का वक्त चुनना होता, तो वह समय जब log aggregation ठीक से न हो रहा हो, एक बड़ा outage, एक अच्छा मौका हो सकता है। संभव है कि पहले से compromised स्थिति में attacker ने इसी समय abuse किया हो, या AWS outage का सहारा लेकर मेरे संसाधनों से किसी अन्य attack को launch किया हो।

  • cloud में अगर कोई odd resource (EC2 आदि) बनता दिखे, तो यह पता करने के लिए कि वह किस event से बना, CloudTrail देख सकते हैं। सामान्यतः RunInstances event देखने से पता चल जाता है।

    • मैं अभी AWS रोज़मर्रा में नहीं use करता, इसलिए सीधे console नहीं देख पाया, लेकिन अगर किसी के साथ ऐसा हो तो लगभग ये steps recommend करूँगा:
      1. EC2 किस account/प्रमुख entity (subject) ने बनाया, पहचानें (eventSource:ec2.amazonaws.com, eventName:RunInstances)
      2. userIdentity के आधार पर follow-up actions track करें
      3. direct console login history देखें (eventSource:signin.amazonaws.com, userIdentity.type:[Root/IAMUser/AssumedRole/FederatedUser/AWSLambda], eventName:ConsoleLogin)
      4. Security Token Service से authentication request history देखें (eventSource:sts.amazonaws.com, eventName:GetSessionToken)
      5. STS session के जरिए AssumeRole के उपयोग की जाँच करें (eventSource:sts.amazonaws.com, eventName:AssumeRole)
      6. नए IAM Role/Account बनाए गए हों—persistence के प्रयास देखें (eventSource:iam.amazonaws.com, eventName:CreateUser/DeleteUser)
      7. existing Role/Account को higher privilege में बदलने का प्रयास देखें (eventSource:iam.amazonaws.com, eventName:CreateRole/DeleteRole/AttachRolePolicy/DetachRolePolicy)
      8. Access Key create/delete history देखें (eventSource:iam.amazonaws.com, eventName:CreateAccessKey/DeleteAccessKey)
      9. production EC2 में IAMInstanceProfile बदलकर backdoor की संभावना check करें (रिफ़रेंस के लिए AWS Docs sample देखें) यदि deeper compromise का शक हो तो किसी expert से environment check और audit कराने की सलाह दूँगा।
    • अच्छी जानकारी है, इसलिए मैं भी logs देखने वाला हूँ। अतिरिक्त observations ये हैं:
      1. root account के नीचे करीब 20 organisaties बने थे और सभी ने co.jp domain वाला ईमेल एड्रेस इस्तेमाल किया।
      2. attacker ने कई Fargate templates तैयार कर रखे थे।
      3. 16~17 AWS regions में resources बनाए गए।
      4. SES, WS Fargate resource quota increase requests, SageMaker notebook maintenance requests जैसे गैरज़रूरी requests दिखे (इन पर कई alert emails आए)।
      5. कुछ ईमेलों में नया नाम (random name@outlook.com) जोड़ा जाता दिखा।
    • RunInstances event वही वास्तविक event था।

  • कुछ Reddit users ने बताया कि AWS outage के बीच refresh करते समय कुछ पल के लिए अलग user के रूप में login दिखा था।

    • पहले मेरी company में भी लगभग ऐसा ही हुआ था। ग्राहक अलग-अलग customer data में access कर रहे थे, कारण था कि किसी गलत employee ने real-time production में live debugging करने की कोशिश की थी (interview में मैंने उसकी hiring के खिलाफ वोट दिया था)। ऐसे मामले को track और fix करना बहुत कठिन था।
    • शायद outage के दौरान DynamoDB में temporary inconsistency हुई हो और IAM credentials भी बिगड़ गए हों। अगर ऐसा है तो यह सच में critical issue है। कोई ऐसा लिंक मिल सकता है क्या जहाँ संबंधित उदाहरण हो?
    • अगर कोई related evidence हो तो share करें। सच में shocking है।
    • याद आता है कि क्या ChatGPT में भी हाल में कोई similar issue नहीं था। किसी हद तक वही vibe लगती है।
    • ऐसे security incidents सामान्य temporary service disruption से कहीं ज्यादा serious होते हैं।

  • सामान्य हालात में शायद इसे सिर्फ संयोग कहा जाएगा, लेकिन आमतौर पर कारण exposed access key ही होता है। MFA न लगे हुए console account की password leak से भी समस्या हो सकती है, लेकिन थोड़ा uncommon है।

  • panic के समय लोग phishing attacks के प्रति सबसे vulnerable होते हैं। सभी passwords तुरंत reset करें और AWS टीम को स्थिति बताएं। आमतौर पर তারা trust के साथ अच्छी तरह handle कर देते हैं।

  • us-east-1 region अपेक्षा से बहुत बड़ा है। ताज़ा public जानकारी के हिसाब से इसमें 159 data centers बताए जाते हैं। हो सकता है कि लाखों accounts यहाँ focus हों। यह घटना AWS outage से जुड़ भी सकती है, लेकिन व्यक्तिगत रूप से मुझे लगता है कि संयोग की संभावना ज्यादा है।

    • 159 सुनकर सच में हैरानी होती है। अगर कोई विश्वसनीय स्रोत हो तो share करें।

  • अजीब लगेगा शायद, लेकिन अगर कोई API key भेज दे तो शायद यह check कर पाते हैं कि वो leak सूची में है या नहीं।

    • मैं समझता हूँ यह एक मज़ाक जैसा है, लेकिन एक सचेतक बात share कर दूँ: मज़ाक में भी API key या credentials share करने की कोशिश से बचना चाहिए। कोई इसे seriously ले सकता है, इसलिए सावधानी ज़रूरी है।