900 साइटें, 12.5 करोड़ खाते, 1 कमजोरी

 (env.fail)
3 पॉइंट द्वारा GN⁺ 2024-03-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • गलत तरीके से सेट किया गया सिर्फ एक Firebase security rule सैकड़ों साइटों के user data के exposure की वजह बना, और पुष्टि किया गया पैमाना ही लगभग 12.46 करोड़ records तक पहुंचा
  • जांच की शुरुआत websites और loaded JavaScript bundles में Firebase configuration variables खोजने के तरीके से हुई; Python scanner में memory समस्या के कारण इसे Go में फिर से लिखा गया
  • सहायक scanner Catalyst Firebase collections के readable होने की स्थिति अपने-आप जांचता है, और sample data के आधार पर exposed information के प्रकार और पैमाने का अनुमान लगाता है
  • aggregate exposure items में 84,221,169 नाम, 106,266,766 emails, 33,559,863 phone numbers, plaintext passwords 20,185,831, और payment information 27,487,924 शामिल हैं
  • researchers ने 13 दिनों में 842 report emails भेजे, लेकिन configuration ठीक करने वाले site owners 24%, reply करने वालों का अनुपात 1%, और bug bounty offer करने वाली sites सिर्फ 2 रहीं

Internet-scale Firebase exposure scan

  • Chattr.ai breach case के बाद, misconfigured Firebase instances के जरिए exposed PII खोजने के लिए पूरे internet का scan शुरू किया गया
  • पहला Python scanner websites या loaded .js bundles में Firebase configuration variables जांचता था, लेकिन लगभग 500 threads पर चलते हुए memory usage बढ़ गया और 1 घंटे के अंदर OOM हो गया
  • बाद में Go में फिर से लिखा गया scanner 55 लाख domains पर चलाया गया, और शुरुआती अनुमानित लगभग 11 दिनों से ज्यादा, 2–3 हफ्ते लगे
  • शुरुआती manual review से ही 136 sites और 62 लाख records मिले, लेकिन candidate list बहुत बड़ी हो जाने पर full automation की जरूरत पड़ी

Catalyst और exposure scale estimation

  • Catalyst candidate sites या JavaScript bundles को input के रूप में लेकर, common Firebase collections और JavaScript में सीधे mention किए गए collections पर read access संभव है या नहीं, यह अपने-आप जांचता है
  • readable collection मिलने पर यह 100 records का sample collect करके उसमें मौजूद information types की जांच करता है, और इसे collection के कुल size से multiply करके impact का estimate लगाता है
  • results store के लिए PostgreSQL-based open-source Firebase competitor Supabase चुना गया, और cleaned data private database tables में upload किया गया
  • aggregate figures इस प्रकार हैं, और वास्तविक exposure scale दिखाए गए आंकड़ों से बड़ा हो सकता है
    • कुल records: 124,605,664
    • नाम: 84,221,169
    • emails: 106,266,766
    • phone numbers: 33,559,863
    • passwords: 20,185,831
    • payment information: bank information, invoices आदि 27,487,924

जिन sites पर ज्यादा असर पड़ा

  • Silid LMS

    • students और teachers के लिए learning management system
    • नाम, email, phone number सहित 2.7 करोड़ user records exposed हुए, जो सबसे बड़ा पैमाना था

  • Online gambling network

    • आपस में reskinned 9 sites से बना
    • कुछ spins में जीतने की probability 0% हो जाए, इस तरह manipulate किए गए थे
    • bank account detailed login information 80 लाख के साथ सबसे ज्यादा exposed हुई
    • plaintext passwords भी 1 करोड़ के साथ प्रभावित sites में सबसे बड़े पैमाने पर थे
    • issue report करने की प्रक्रिया में customer support ने बातचीत के दौरान flirt किया

  • Lead Carrot

    • cold calls के लिए online lead generation service
    • exposed user information के पैमाने में top 3 में, और 2.2 करोड़ लोगों पर असर

  • MyChefTool

    • restaurants के लिए business management app और POS application
    • exposed names की संख्या में पहला और emails की संख्या में दूसरा स्थान, क्रमशः 1.4 करोड़ और 1.3 करोड़ exposed हुए

रिपोर्ट के बाद प्रतिक्रियाएं

  • researchers ने 13 दिनों में 842 emails भेजे
    • 85% delivered हुए और 9% bounced हुए
    • 24% site owners ने गलत configuration ठीक किया
    • reply करने वाले site owners सिर्फ 1% रहे
    • 0.2% यानी 2 site owners ने bug bounty offer किया

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

1 टिप्पणियां

 
GN⁺ 2024-03-19
Hacker News की राय

  • मैंने Firebase में लंबे समय तक काम किया है, और security rules की समस्या product को लगातार परेशान करती रही है
    अपने-आप expire होने वाले default rules, बेहतर शिक्षा वगैरह जैसे कई तरीके आज़माए, लेकिन अंत में अब भी बहुत सारे असुरक्षित databases दिखते हैं
    वजहें जटिल हैं, लेकिन Firebase-स्टाइल security rules अब भी लोगों के लिए नया concept है, और कई बार किसी मौजूदा जगह पर data जोड़ने वाला नया developer data की privacy requirements बदलने के हिसाब से rules को भी update नहीं करता
    साथ ही, अपने-अपने बनाए backend से मिलने वाली “security by obscurity” खत्म हो जाती है, जिससे बड़े पैमाने पर scanning आसान हो जाती है
    खासकर Realtime Database के rules लिखना मुश्किल है और उनकी scalability भी अच्छी नहीं, लेकिन automatic scans आम तौर पर सिर्फ खुले data को ढूंढते हैं, इसलिए read write true से थोड़ा भी बेहतर हो तो उन्हें रोका जा सकता था
    तकनीकी तौर पर Firebase approach अपने-आप में गलत नहीं है, लेकिन यह stored data और security rules पर केंद्रित model इस्तेमाल करने वाले लगभग इकलौते backend में से है, इसलिए गलतफहमी, गलत इस्तेमाल और ऐसी घटनाओं के लिए ज्यादा exposed रहता है

    • सच कहूं तो frontend का database में सीधे data लिख सकने वाला model, security rules होने पर भी, हमेशा संदिग्ध लगा
      backend में validation/security rules specification का हिस्सा लगते हैं, लेकिन Firebase security rules एक अलग प्रक्रिया हैं, इसलिए आसानी से भूल जाते हैं और हर नई feature बनाते समय उन्हें फिर से evaluate करना पड़ता है
    • Google support channel से संपर्क करके मदद करने या websites को समस्या बताने की अनुमति मांगी, लेकिन जवाब सिर्फ इतना मिला कि चाहें तो वे मेरी ओर से एक feature request बना सकते हैं
      project owners को alert कर सकने वाले किसी व्यक्ति का ध्यान खींचने के लिए शायद Firebase के अंदर काफी ऊंचे स्तर तक escalation करनी पड़ती
    • https://firebase.google.com/docs/rules/basics देखकर सोचता हूं कि पहले से तय security rule templates चुनने वाला simple security mode practical होगा या नहीं
      उदाहरण के लिए लेख के “सिर्फ content owner को access” या “attribute-based/role-based access” जैसे templates ज्यादातर apps के patterns cover कर सकते हैं या सच में बहुत सारे custom rules की जरूरत पड़ती है, यह सवाल है
      security rules लिखने की बड़ी समस्या यह है कि लगभग हर गलती security issue बन जाती है, इसलिए जरूरत न हो तो उन्हें छूना नहीं चाहते
      rules बहुत ज्यादा locked down हों तो app नहीं चलता और तुरंत पता चल जाता है, लेकिन बहुत खुले हों तो excessive access को खुद probe करने से पहले अक्सर पता नहीं चलता
      इसी संदर्भ में हर security rule के लिए access-denied example test case developer से लिखवाना अनिवार्य करने का तरीका भी सोचा जा सकता है
    • हमारे लिए एक सरल तरकीब ने काफी मदद की: fireplan नाम का rules transpiler हर property में default "$other": {".read": false, ".write": false} rule जोड़ देता है
      इससे नए fields को explicitly add करना पड़ता है, इसलिए किसी नए value का अनजाने में मौजूदा rules को “inherit” कर लेना लगभग असंभव हो जाता है
      Firebase को 10 साल से ज्यादा इस्तेमाल किया है, इसलिए पता नहीं कि latest rules tools भी ऐसा करते हैं या नहीं
      असल में मददगार चीजें होंगी: ऐसी स्थिति में field name change या data structure change को default support करना जहां कई client versions को control करना मुश्किल हो; database चलाए बिना rules को हल्के तरीके से test करने का तरीका; और production environment में rule failures पर बेहतर debugging information देना
      हर failure पर rule ने जिन-जिन values को access किया उन्हें साथ में log करना चाहिए, ताकि बदलते data के कारण होने वाली intermittent failures debug की जा सकें
    • मैंने Firebase और Firestore का काफी बचाव किया है, लेकिन ऊपर की सभी बातों से सहमत हूं
      यह पर्याप्त रूप से explain न किया गया conceptual model है
      projects में हम कहते हैं कि हर collection के लिए public, user data, सिर्फ authenticated users के लिए public, admin-only जैसे security profiles होने चाहिए, और हर collection पर custom conditions लिखने के बजाय security rule functions से इन categories को enforce करने का approach लेते हैं
      field level की बजाय collection level पर security सोचने से एक ही document में अलग-अलग security intent मिल जाने की संभावना कम होती है
      अगर collection public है तो उसमें non-public fields नहीं होने चाहिए, और जरूरत हो तो Firestore trigger से sensitive context से public context में data replicate किया जा सकता है, लेकिन उल्टी दिशा में नहीं
      समस्या यह है कि rules की intent को rules के बाहर document करना पड़ता है, इसलिए गलत apply करना आसान है; पहले tests लिखना भी दर्दनाक था, लेकिन अब काफी बेहतर हो गया है

  • “How I pwned half of America’s fast food chains, simultaneously.” याद आता है: https://mrbruh.com/chattr/
    HN: https://news.ycombinator.com/item?id=38933999

    • दोनों लेख मैंने ही लिखे हैं, और यह लेख उस blog post का follow-up है
    • यह normal है। blog post का छठा शब्द उसी लेख की ओर link है
      After the initial buzz of [pwning Chattr.ai] had settled down, […]

  • अगर मैं गलत नहीं देख रहा, तो लेख के अंत तक इसका मतलब यह है कि ऐसी vulnerability वाली sites में से 75% अब भी वैसे ही खुली हैं और dump की जा सकती हैं?
    पागलपन है
    कभी-कभी लगता है कि computer छूने के लिए license होना चाहिए

    • कई companies में full-time developer नहीं होता
      वे website बनाने वाली agency को outsource करती हैं, agency developers बदलती रहती है; शुरुआत में अच्छे developer को लगाती है और बाद में, जब तक company शिकायत न करे, contract कम अनुभवी developer को दे देती है
      vulnerability वाला email शायद spam मानकर ignore हुआ, या forward होने के बाद पड़ा रह गया, या PM की meeting schedule queue में चला गया होगा—ऐसा item जिसे client से जितना हो सके bill करते हुए fix करना है
      जिन fields में professional license अनिवार्य है, वहां भी अयोग्य license holders बहुत हैं
      doctors के लिए भी education और licensing requirements भारी हैं, लेकिन quack doctors और licensed alternative-medicine practitioners की कमी नहीं है
    • दुखद है लेकिन सच है, और शायद संख्या इससे कहीं ज्यादा होगी
      हर site को affected details, fix करने का तरीका और contact method शामिल करते हुए custom email भेजकर मैंने पूरी कोशिश की
    • सही है। इसलिए malicious actors तुरंत exploit न कर सकें, इसके लिए affected sites की list public नहीं कर सका
    • जब तक privacy leak से company बंद नहीं होती, उनके लिए यह business cost है और वह cost users पर डाल दी जाती है

  • यह PM के cheap-fast-good त्रिकोण में सस्ता और तेज़ विकल्प चुनने का अनिवार्य नतीजा है
    अफसोस की बात है कि कुछ ग्राहकों और यूज़र्स की चिंताएँ चर्चा से बाहर रह गईं, और कीमत उनकी personal information से चुकाई गई
    यहाँ सूचीबद्ध कंपनियों में से जिन जगहों पर ऐसे फैसले के बाद भी leadership नहीं बदली, उनसे मैं सावधान रहूँगा
    यह कई बार साबित हो चुका है कि बहुत-सी कंपनियाँ ग्राहकों की सुरक्षा की पर्याप्त परवाह नहीं करतीं, और इतिहास खुद को दोहराता है

    • मोटे तौर पर सहमत हूँ, लेकिन बहुत कम सही, ऐसे अच्छे उदाहरण भी थे जिन्होंने आभार जताया और जल्दी fix किया

  • Firebase को लेकर मेरा एक बहुत बुनियादी सवाल है: क्या इस लेख की ज़्यादातर apps custom server code के बिना सिर्फ statically hosted client-side JavaScript से बनी थीं?
    यानी backend 100% Google द्वारा hosted Firebase configuration था?
    अगर ऐसा है, तो मुझे नहीं पता था कि लाखों यूज़र्स वाली sites में ऐसी architecture इतनी आम हो गई है

    • हाँ। या तो पूरी तरह client-side, या server से होकर जाते हुए भी naïvely pass-through करने वाला तरीका
      API में default-allow security model रखें तो ऐसा होना अनिवार्य है
      दुर्भाग्य से JavaScript developers को target करने वाली libraries में unsafe defaults आम हैं, और GraphQL भी ऐसा क्षेत्र लगता है जहाँ ऐसी समस्या सामने आ सकती है
    • मिश्रण भी हो सकता है
      Firebase में cloud से callable functions, यानी Firebase Functions, भी होते हैं, और उनका code public नहीं होता
      लेकिन Firestore और Firebase Realtime Database दोनों में users को security rules सेट करने पड़ते हैं; नहीं तो कोई भी सारा data पढ़ सकता है
    • यह काफी radical setup जैसा लगता है, लेकिन backend के SQL schema में उचित authorization rules code किए जाएँ तो काम कर सकता है
      backend में उचित authorization rules आसानी से लिख पाना महत्वपूर्ण है

  • ऐसी चीज़ें देखकर लगता है कि बहुत पहले password manager और virtual cards चुन लेना अच्छा रहा
    फिर भी internet और डरावना हो गया है
    ज़्यादातर लोगों को बिल्कुल पता नहीं कि web कितना vulnerable है और वे खुद कितने exposed हैं

    • आगे यह और खराब होगा लगता है
      AI agents bots की तुलना में vulnerabilities ढूँढ़ने में कहीं ज्यादा efficient होंगे, तो अजीब भविष्य इंतज़ार कर रहा है
    • समय के साथ services website बनाना आसान करती जा रही हैं और अधिक चीज़ों को abstract कर रही हैं, जिससे developers को पता ही नहीं रहता कि क्या configure करना है
    • सिर्फ password manager काफी नहीं है
      जिस भी service में sign up करें, हर एक के लिए unique email address इस्तेमाल करना चाहिए
      breach होने पर नुकसान सीमित किया जा सकता है, और दूसरी services से मिलान करके public information collection का शिकार होने से भी बचा जा सकता है
      कभी-कभी अगर उस unique address पर malicious email आए, तो site operator से पहले आपको breach का पता चल सकता है

  • “लगभग 500 threads वाला Python program समय के साथ memory खाने लगता है” वाले हिस्से के बारे में किसी को और जानकारी है?
    मेरे पास भी Python में सैकड़ों threads वाला एक scraper है और लगता है कि वह काफी memory खाता है
    कोई workaround है या किसी दूसरी language में फिर से लिखना ही इकलौता समाधान है?

    • Python में भी किया जा सकता है, लेकिन Python की reference counting threads के साथ कैसे interact करती है, इसमें गहराई से जाना होगा
      व्यक्तिगत रूप से मैं threads की बजाय processes पसंद करता हूँ, और shared memory के बजाय worker pool और message bus इस्तेमाल करता हूँ
      इस solution में भी drawbacks और थोड़ा overhead है, लेकिन memory issues की चिंता बहुत कम करनी पड़ती है
      crawlers में processes की संख्या अपेक्षाकृत स्थिर होती है और हर process का काम independent होता है, इसलिए process model ज्यादा उपयुक्त लगता है
    • import multiprocessing as threading
    • exact problem पता नहीं, लेकिन सच कहूँ तो Python इस तरह के काम के लिए सही language नहीं है
      फिर से लिखना व्यावहारिक रूप से इकलौते solution के करीब है
    • इस use case के लिए asyncio इस्तेमाल करना सही है
      यह बहुत अच्छी तरह fit होने वाला use case है

  • अच्छा काम
    यह निष्कर्ष कैसे निकाला कि प्रभावित users की संख्या असल में और ज्यादा होने की संभावना है, यह जानना चाहूँगा
    देखने में लगता है कि gambling sites या Lead Carrot जैसी कुछ sites में fake account data काफी मिला-जुला हो सकता है

    • कई sites को manual review करने पर दिखा कि automated scanner variable names के आधार पर phone number जैसी ज्ञात data types check करता था, इसलिए non-English personal information को अच्छी तरह identify नहीं कर पाया
      यह तरीका सिर्फ English sites पर ही अच्छी तरह काम करता है
    • यह confirm किया कि gambling site का data fake नहीं था, लेकिन Lead वाले के बारे में नहीं पता
      ज्यादा होने की बात इसलिए कही क्योंकि scan list में नहीं मौजूद दूसरी services भी vulnerable हो सकती हैं