RubyGems.org AWS root access घटना – सितंबर 2025

• सितंबर 2025 में Rubygems.org के AWS root account पर अनधिकृत access की घटना हुई
• सार्वजनिक जांच परिणामों में पुष्टि हुई कि user data या production environment में क्षति या exposure का कोई सबूत नहीं मिला
• मुख्य कारण थे: एक पूर्व कर्मचारी की access revocation के बाद भी AWS root account password को तुरंत न बदलना, और shared credentials management की कमी
• घटना के बाद सभी credentials और passwords rotate किए गए, security audit को मजबूत किया गया, और external audit व access change process में सुधार किया गया
• corporate ethics, data privacy, और transparent communication पर बार-बार ज़ोर दिया गया, और community trust बहाल करने के प्रयास स्पष्ट रूप से बताए गए

---

अवलोकन और पृष्ठभूमि

Ruby Central ने सितंबर 2025 में Rubygems.org की AWS root access breach घटना पर आधिकारिक postmortem report प्रकाशित की। यह दस्तावेज़ घटना के होने की प्रक्रिया, जांच के परिणाम, कहाँ चूक हुई, और आगे की security strengthening measures को पारदर्शी ढंग से व्यवस्थित करता है।

घटना तब शुरू हुई जब एक सार्वजनिक ब्लॉग के माध्यम से यह सामने आया कि पूर्व administrator André Arko की access revocation के बाद भी Rubygems.org production environment और monitoring tools तक पहुँच संभव थी। Ruby Central ने तुरंत service integrity और user data protection पर ध्यान केंद्रित किया और सार्वजनिक रूप से माफी भी व्यक्त की।

घटना प्रतिक्रिया टाइमलाइन

30 सितंबर 2025 की मुख्य प्रगति

• 17:23 UTC: André Arko ने ईमेल के ज़रिए सूचित किया कि उनके पास root access संभव है
• 17:30 UTC: एक बाहरी व्यक्ति के ब्लॉग पोस्ट के माध्यम से root account access और screenshot सार्वजनिक हुए
• 17:51 UTC: Ruby Central ने issue investigation team बनाई और पूरी service तथा credentials की जांच शुरू की
• 18:20 UTC: पुष्टि हुई कि मौजूदा password अमान्य हो चुका था
• 18:24 UTC: AWS root account password reset किया गया, MFA authentication के ज़रिए account recovery की गई
• 18:30 UTC: “Credentials Report” देखकर पुष्टि हुई कि 19 सितंबर को एक अनधिकृत व्यक्ति ने root password बदला था
• 20:45 UTC: सभी subordinate accounts और legacy credentials निरस्त किए गए, MFA फिर से जारी किया गया, और नए credentials को एक स्वतंत्र vault में सुरक्षित रखा गया

घटना का विस्तृत क्रम

Ruby Central का पूरा infrastructure AWS पर चलता है, और root account credentials एक shared vault में रखे गए थे, जिसे केवल 3 लोग access कर सकते थे (2 वर्तमान, 1 पूर्व)।

18 सितंबर 2025

• 18:40 UTC: Arko को ईमेल से production access और on-call service permissions हटाए जाने की सूचना मिली
• Arko द्वारा उपयोग किए गए AWS credentials हटा दिए गए, लेकिन root account password rotate नहीं किया गया

19 सितंबर 2025: हमले की शुरुआत

• 04:34~04:39 UTC: San Francisco IP से अनधिकृत root login, password change, privileged groups/policies से बाहर निकलना, और IAM की व्यापक जांच गतिविधि की गई

28 सितंबर 2025

• 05:49 UTC: Tokyo IP से अनधिकृत session हुआ, IAM introspection API के ज़रिए user metadata की जांच की गई
• (समय Kaigi on Rails conference से मेल खाता है, इसलिए उसी व्यक्ति होने की संभावना जताई गई)

30 सितंबर 2025

• 15:25~15:35 UTC: Los Angeles IP से root access किया गया, user credentials हासिल करने के commands चलाए गए (जो ब्लॉग में साझा screenshots से मेल खाते हैं)
• 18:24 UTC: Ruby Central ने root control फिर से हासिल कर लिया

प्रभाव और नुकसान का दायरा

• विस्तृत समीक्षा में user data, accounts, gems, और service availability में किसी भी क्षति का सबूत नहीं मिला
• Rubygems.org घटना के दौरान पूरी तरह सामान्य रूप से चलता रहा
• PII, financial data जैसी sensitive information तक कोई access या leakage नहीं हुआ
• production DB, S3, CI/CD में कोई बदलाव नहीं मिला
• हालांकि, shared credentials को rotate न करना और लंबे समय तक access exposure बने रहना operational procedure की गंभीर विफलता थी

समाधान प्रक्रिया

• सभी root और IAM credentials को निरस्त किया गया और नया MFA लागू किया गया
• जुड़े हुए external integrations (Datadog, GitHub Actions आदि) के tokens पूरी तरह rotate किए गए
• AWS CloudTrail, GuardDuty, DataDog के माध्यम से महत्वपूर्ण बदलावों की real-time monitoring मजबूत की गई
• IAM permission structure की फिर से समीक्षा की गई और अनावश्यक permissions हटाई गईं
• external experts सहित comprehensive security audit शुरू किया गया
• नया security runbook तैयार किया गया (staff changes पर तुरंत password rotation, quarterly review, और incident communication process सहित)

मूल कारण विश्लेषण

• यह नहीं समझा गया कि shared password management की external copy मौजूद हो सकती है
• कर्मचारी के जाने पर AWS root password और MFA को rotate नहीं किया गया
• इन दो कारणों से अनधिकृत व्यक्ति के लिए RubyGems production infrastructure तक पहुँच और access control को चुनौती देने की संभावना बनी

पुनरावृत्ति रोकने के उपाय

• access revocation procedures और checklist को shared vault management तक विस्तारित किया गया
• non-federated credentials (खासकर shared credentials) को staff changes होते ही rotate किया जाएगा
• independent security audit बाहरी विशेषज्ञों को सौंपा जाएगा
• किन लोगों को और किन शर्तों पर production permissions दी जाएँगी, इसके लिए स्पष्ट operator/contributor agreement लागू किया जाएगा

इसे security incident क्यों माना गया

• इसकी जड़ core system पर single-person control की समस्या में थी
• Mr. Arko पहले secondary on-call service के लिए सालाना $50,000 की paid consulting दे रहे थे; budget structure बदलने के बाद उन्होंने unpaid on-call support के बदले production HTTP logs (PII सहित) तक access और revenue generation opportunity का प्रस्ताव दिया
• इस प्रस्ताव में governance, privacy, और conflict of interest जैसे मूलभूत मुद्दे निहित थे, इसलिए Ruby Central ने इसे स्वीकार्य नहीं माना और operator structure तथा governance reform शुरू किए
• Arko की PII शामिल systems तक निरंतर पहुँच की पुष्टि निर्णायक रूप से इसे security incident के रूप में वर्गीकृत करने का आधार बनी
• अब तक RubyGems data के बाहर निकाले जाने या संग्रहीत किए जाने का कोई सबूत नहीं मिला है, और community trust की बहाली तथा transparency बढ़ाने का वादा किया गया है

निष्कर्ष

• community के समर्थन और स्वस्थ निगरानी के लिए आभार व्यक्त किया गया
• Ruby Central ने कहा कि वह transparent operations, जवाबदेही, और मजबूत security framework के साथ Rubygems.org की stability और trust सुनिश्चित करता रहेगा

Shan Cureton
Executive Director