- 31 मई 2024 को, cloud कंपनी Snowflake को बड़े पैमाने पर डेटा लीक का सामना करना पड़ा
- Hudson Rock ने पुष्टि की कि हैकरों ने infostealer infection के ज़रिए access हासिल किया
- हैकरों ने Ticketmaster और Santander Bank सहित कई बड़ी कंपनियों का डेटा रूसी cybercrime forum पर बेचा
हैकिंग का तरीका
- हैकरों ने Snowflake कर्मचारी के ServiceNow account में चोरी किए गए credentials का इस्तेमाल करके login किया।
- उन्होंने OKTA को bypass करके session token बनाया और बड़े पैमाने पर डेटा बाहर निकाला।
- हैकरों का दावा है कि लगभग 400 कंपनियाँ प्रभावित हुईं।
अतिरिक्त सबूत
- हैकरों ने Hudson Rock के शोधकर्ताओं के साथ एक CSV file साझा की, जो Snowflake server तक access दिखाती है।
- यह file Snowflake के Europe server से जुड़े 2,000 से अधिक customer instances को document करती है।
हैकरों का लक्ष्य
- हैकरों ने डेटा वापस पाने के बदले Snowflake से 2 करोड़ डॉलर की मांग की।
- कंपनी ने इसका जवाब नहीं दिया।
infostealer infection में वृद्धि
- 2018 के बाद से infostealer infection में 6000% की वृद्धि हुई है, और यह शुरुआती attack vector के रूप में प्रमुख बन गया है।
- इसका उपयोग ransomware, डेटा लीक, account takeover और corporate espionage समेत कई cyber attacks को अंजाम देने में किया जाता है।
GN⁺ की राय
- cyber security का महत्व: यह घटना दिखाती है कि कंपनियों को cyber security पर और अधिक ध्यान देना चाहिए। खासकर कर्मचारियों के credentials का प्रबंधन बहुत महत्वपूर्ण है।
- infostealer का खतरा: infostealer बहुत तेज़ी से फैल रहा है, और कंपनियों को इसके खिलाफ तैयारी करनी चाहिए।
- response strategy: हैकिंग की घटना होने पर तेज़ response और नुकसान कम करने की रणनीति ज़रूरी है। Snowflake की धीमी प्रतिक्रिया से नुकसान बढ़ गया।
- security training: कर्मचारियों के लिए security training मज़बूत करना ज़रूरी है, ताकि credentials management और phishing attacks के प्रति जागरूकता बढ़े।
- वैकल्पिक solutions: Snowflake जैसे features देने वाले दूसरे cloud storage solutions पर भी विचार किया जा सकता है। उदाहरण के लिए, AWS S3 या Google Cloud Storage।
1 टिप्पणियां
Hacker News की राय
अभी लिंक किया गया URL
/पर 302 redirect हो रहा है। @dang, नीचे वाले archive link से बदलना बेहतर लगता हैhttps://web.archive.org/web/20240531140540/https://www.hudso...
हालांकि Hudson Rock का blog post हटाना भी एक दिलचस्प संकेत है, इसलिए बस archive link से बदलकर आगे नहीं बढ़ना चाहिए। क्या बदला होगा?
अपडेट: Snowflake का आधिकारिक जवाब मूल लेख के मुख्य दावों को लगभग पूरी तरह नकारता दिखता है। हो सकता है Hudson Rock किसी बेईमान source के झांसे में आ गया हो और अपनी गलती समझकर post हटा दिया हो
https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
मैं Snowflake से Felipe हूं। इस issue पर Snowflake की ताजा स्थिति यहां है: https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
कोई अतिरिक्त खबर होगी तो इस URL को लगातार update करता रहूंगा
लेकिन Snowflake का यह वाक्य, “प्रभावित customer accounts की तरह, हमें सबूत मिला कि threat actor ने एक पूर्व Snowflake कर्मचारी के demo account के लिए personal credentials हासिल कर access किया। कोई sensitive data नहीं था” पढ़ने में ऐसा लगता है कि Snowflake Hudson Rock की व्याख्या को झूठ मानता है। क्या यह समझ सही है?
इसके उलट Snowflake का post ऐसा लगता है कि customer account credentials leak हुए, बात वहीं खत्म, और central account या अन्य accounts तक कोई access नहीं था। two-factor authentication न होने वाले employee account details के इस्तेमाल पर कुछ नहीं कहा गया
यह साफ है कि Snowflake अपने internal employees के सभी access credentials पर two-factor authentication चाहेगा। पहले customer चाहे तो अपने data में login करने के लिए सिर्फ नाम/password बना सकता था और two-factor authentication के बिना भी access कर सकता था
chat log के screenshots सच में प्रभावशाली हैं। यह company दावा करती है कि वह असली अपराधी से बात कर रही है, और वह अपराधी कहता है कि अगर उन्होंने इस company का इस्तेमाल किया होता तो breach रोकने में मदद मिलती
इसलिए इस company की credibility को लेकर मैंने अपना आकलन बदला है
Hudson Rock ने उसी हिसाब से कहानी को असल से बड़ी breach की तरह बढ़ा-चढ़ाकर पेश किया लगता है। यह भी जानना चाहूंगा कि hacker पहले Hudson Rock के पास गया था या Hudson Rock ही उसे सुनने वाली पहली company थी
“आपको Hudson Rock की protection खरीदनी चाहिए थी, तो यह घटना रोकी जा सकती थी”
“सही है, इससे जरूर मदद मिलती”
“बधाई हो। आपकी company ने surprise information-security audit पास कर लिया है और ransomware victim बन गई है।”
[...]
उपलब्ध चीजें: 1) full decryption support 2) data deletion proof 3) मिली vulnerabilities पर security report 4) data publish या sell न करने की guarantee 5) future attacks न करने की guarantee
आखिरकार यह बस वही security consulting company है, जिसके payroll पर होने का आपको पता नहीं था
वैसे data deletion proof के तौर पर क्या देते हैं, देखा तो वह सचमुच सिर्फ
rm -vrf dataका standard output था। मैं समझता हूं कि absence का proof देना असंभव है और victim के पास negotiation power नहीं होती, लेकिन यह staging मुझे काफी पसंद आईभले ही असली हो, Hudson Rock messages हटाना common sense होता। इस company को मैंने अपने दिमाग की blacklist में डाल दिया है
अपराधी की बातों को ही देखें तो लगता है कि Snowflake ने सिस्टम इस तरह डिजाइन किया था कि एक अकेले admin account को हर चीज़ पर पूरा अधिकार मिल जाए
Snowflake ने 31 मई की घोषणा में कहा था कि वह “कुछ ग्राहकों को प्रभावित करने वाले industry-wide identity-based attack” की जांच कर रहा है, यह बात Ticketmaster और Santander वाली कहानी को और भरोसेमंद बनाती है
https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
अगर threat actor ने ठीक से काम किया होता, तो यह अब तक के सबसे बड़े data breaches में से एक हो सकता था
लगता है डेटा उस व्यक्ति के Snowflake account से आया था, जिसे वह ग्राहकों या संभावित ग्राहकों के लिए demo बनाने में इस्तेमाल करता था। यह संभव है कि ग्राहकों ने demo में कुछ वास्तविक डेटा इस्तेमाल करने के लिए access दिया हो, लेकिन यह ग्राहकों के Snowflake database तक unlimited access होने से बहुत अलग बात है
पूरी संभावना है कि hacker ने demo के लिए बनाए गए नकली लेकिन असली जैसे दिखने वाले डेटा को निकाला हो, और उसे फर्क पता न हो
एक sales engineer कई accounts संभालता है। Snowflake sales engineer आम तौर पर customer environment के अंदर build नहीं करते, बल्कि ऐसा 400-dollar credit demo account set up करते हैं जिसे कोई भी बना सकता है। Demo accounts समय के साथ expire हो जाते हैं, इसलिए वे लगातार नए बनाए जाते हैं
Sales engineer अपने बनाए demo account के अंदर build करता है और customer को दिखाता है। 30 दिन बाद, अगर credit card नहीं है तो Snowflake account को lock कर देता है, और बाद में demo instance और डेटा delete कर देता है
काम के लिए customer अपने Snowflake instance से sales engineer द्वारा बनाए गए demo instance में डेटा share कर सकता है, या SSO के जरिए उस Snowflake sales engineer को access दे सकता है
दोनों ही स्थितियों में यह ज्यादा उन organizations की समस्या लगती है जिन्होंने अपना security posture पर्याप्त रूप से restrictive नहीं रखा। यह attack नया कुछ नहीं है, बस इतना कि उन्हें एक मेहनती sales engineer और ऐसे customers मिल गए जिन्होंने employee/contractor/guest permissions का scope ठीक से सीमित नहीं किया
दिलचस्प बात यह है कि first page पर ही Eastern Europe की NGO के खिलाफ Pegasus इस्तेमाल होने की एक पड़ोसी कहानी भी है। Least privilege principle अहम है, लेकिन device security भी अहम है
https://news.ycombinator.com/item?id=40535912
मैं Snowflake employee नहीं हूं, लेकिन Snowflake और उसके sales engineer organization के साथ काफी समय तक काम किया है
Customers के साथ demo बनाते समय sales engineers ऐसे 400-dollar Snowflake demo account से demo environment बनाते हैं जिसे कोई भी बना सकता है। Demo बनाने के लिए customer उस sales engineer को access देता है, और sales engineer कुछ डेटा demo environment में ले जाकर उस पर काम करता है। Hudson Rock ने जो environment name सार्वजनिक किया है, वह भी इसी बात का समर्थन करता है
मुझे तो यह उस process की समस्या लगती है जिसमें डेटा share करने वाले व्यक्ति की ID customer ने expire नहीं की, और threat actor ने credentials चुरा लिए। यह vulnerability exploit नहीं है, इसलिए इसमें नया कुछ नहीं है
और Hudson Rock, बधाई हो कि आपने ऐसे व्यक्ति को सार्वजनिक रूप से उजागर कर दिया जिसे computer में malware होने के कारण नुकसान हुआ। यह contractor को credentials देने और उनके चोरी हो जाने से अलग नहीं है। बहुत घटिया हरकत है
Snowflake में sales engineer के credentials चोरी हो सकते हैं, वे credentials multi-factor authentication को bypass कर सकते हैं, और article के मुताबिक उनकी expiry भी नहीं है। यह strike 1, 2, 3 है
Snowflake की security practices ने ऐसी स्थिति बनाई जिसमें customers को बड़े datasets का access Snowflake employees के साथ share करने की जरूरत पड़ती थी, या कम से कम उन्हें ऐसा करने के लिए encourage किया जाता था। यह strike 4 है
Customer पर भी बहुत व्यापक access देने की जिम्मेदारी है, लेकिन ऐसी access की जरूरत ही न पड़े इसके लिए बेहतर system न बनाने, या कम से कम इस transitive access की बेहतर निगरानी और नियंत्रण न करने की जिम्मेदारी Snowflake पर भी है
जिस पल ऐसे account को customer data का access मिल जाता है, वह अब “demo account” नहीं रह जाता। वह real account है, और उसमें सचमुच बेहद मूल्यवान data है, इसलिए उसे उसी तरह treat किया जाना चाहिए
अतिरिक्त: Snowflake का दावा है कि उस demo account ने customer data access नहीं किया और वह leak का source भी नहीं था, जो attackers के दावे से contradict करता है
“कल्पना कीजिए कि आपके पास ऐसी prospecting platform तक access है जिसमें दुनिया भर की लाखों compromised companies और active vulnerabilities वाले prospects हैं, जिन्हें आप customers में convert कर सकते हैं।”
मैंने इस प्रकार की कुछ companies देखी हैं और उनसे deal किया है; यह काफी low-grade tactics है और technical रूप से भी skill या effort का स्तर कम है
Snowflake के आधिकारिक जवाब में यह लिखा है
“हम इसे customer data हासिल करने के इरादे से, पूरी industry में चल रहे identity-based attack का नतीजा मानते हैं. जांच के अनुसार ये हमले ग्राहकों के user credentials से किए जा रहे हैं, जो असंबंधित cyber threat activity के जरिए expose हुए थे. अब तक हमें नहीं लगता कि यह activity Snowflake product के भीतर किसी vulnerability, configuration error या malicious activity की वजह से हुई है.”
[0]https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
लगता है article को private कर दिया गया है, लेकिन Wayback Machine पर यह अभी भी मौजूद है: https://web.archive.org/web/20240531140540/https://www.hudso...
यह post दावा करती है कि कुछ दिन पहले Ticketmaster breach असल में Snowflake employee के stolen credentials के जरिए 400 से ज्यादा companies को प्रभावित करने वाला कहीं बड़ा hack था
फिलहाल यह एक बड़ी story जैसी लग रही है जिसे सिर्फ hudsonrock.com ही report कर रहा है. Hudson Rock का नाम मैंने पहली बार सुना है; क्या किसी को पता है कि यह भरोसेमंद source है?
कई accounts को Reddit operators और admins ने ban किया. निजी तौर पर मैं इसे भरोसेमंद या विश्वसनीय source नहीं मानता
https://www.bbc.co.uk/news/articles/c6ppv06e3n8o
Snowflake ऐसा कहता दिख रहा है कि गलती उनकी नहीं, customers की है
https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
अगर https://www.hudsonrock.com/blog/snowflake-massive-breach-acc... पूरी तरह गढ़ी हुई कहानी नहीं है, तो Snowflake facts को कुछ कम ईमानदारी से बता रहा है
“जांच के अनुसार…” जैसी भाषा अस्पष्ट है कि यह उनकी अपनी investigation है या general security research. “Snowflake product के भीतर vulnerability, configuration error या malicious activity की वजह से नहीं मानते” वाला वाक्य भी संभावित scenarios को गिनाकर उन्हें नकारता है, लेकिन असल में यह कैसे हुआ, इसे चतुराई से छोड़ देता है
अगर Hudson Rock पर भरोसा करें, तो Snowflake से malicious actor ने contact किया था, इसलिए उन्हें संभवतः काफी अच्छी तरह पता रहा होगा कि यह कैसे हुआ
उन्होंने कहा कि यह “असंबंधित cyber threat activity के जरिए expose हुए ग्राहकों के user credentials” से किया गया, यानी अगर यह मनगढ़ंत नहीं है तो वे मान रहे हैं कि credentials कहीं और से हासिल किए गए
आखिर में उन्होंने customers से account settings review करने को कहा है, यानी जिम्मेदारी अपने ऊपर से हटाने की दिशा है. हालांकि अभी sources हैं: वह company जिसका hack हुआ बताया जा रहा है, और वह company जिसने इस incident का इस्तेमाल अपने product को promote करने के लिए किया और एक employee की बेशर्मी से doxxing की, इसलिए शायद और detail आने तक इंतजार करना चाहिए
hacker दावा करता है कि उन्होंने refresh tokens को expire भी नहीं किया, जो सच हुआ तो बहुत बड़ा और साफ-साफ दिखने वाला issue है
Article “hundreds of customers breached” शीर्षक से बहुत consistent नहीं लगता
पहला, lift/okta password शायद सिर्फ ServiceNow portal access देता है, customer accounts का access नहीं, इसलिए refresh token issue ServiceNow portal तक सीमित लगता है और असली customer Snowflake accounts के data exposure से related नहीं दिखता
दूसरा, 10 company accounts compromise होने वाले screenshot में अलग-अलग Snowflake account credentials के 4 sets दिखते हैं, जिनमें से एक personal demo account जैसा लगता है. इसलिए इससे अधिकतम करीब 3 customer breaches explain हो सकते हैं, लेकिन दूसरे customer breaches दिखाने वाली details नहीं हैं
अगर मान भी लें कि sales engineer जिन सभी customers पर काम कर रहा था उनके सभी credentials compromise हो गए, तो breached customers की संख्या शायद low double digits में होगी. क्योंकि हर customer account को sales engineer को separately access देना पड़ा होगा
internal Okta portal के refresh token issue के आधार पर यह कहना कि सारे Snowflake customers breach हो गए, बहुत बड़ा leap है, और वह issue किसी भी customer Snowflake account से जुड़ा नहीं है