वेबसाइट विज़िट किए बिना Arc ब्राउज़र तक पहुंच संभव बनाने वाली भेद्यता

 (kibty.town)
2 पॉइंट द्वारा GN⁺ 2024-09-20 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Arc ब्राउज़र के Boosts और Firestore rules की समस्या एक साथ मिलकर ऐसी स्थिति बना रही थी, जिसमें हमलावर पीड़ित के अकाउंट से मनमाना JavaScript वाला Boost जोड़ सकता था
  • Firebase authentication और Firestore के उपयोग की पुष्टि Frida hooking से हुई, और preferences, users, user_referrals, boosts collections तक पहुंच का flow सामने आया
  • यह भेद्यता इसलिए पैदा हुई क्योंकि Boost लागू करने का लक्ष्य creatorID से तय किया जा रहा था, जबकि हमलावर अपने Boost document का creatorID किसी दूसरे user ID में बदल सकता था
  • पीड़ित का user ID user_referrals, सार्वजनिक Boosts के boostSnapshots, साझा Easels आदि से हासिल किया जा सकता था, और पीड़ित के target site पर जाने पर malicious Boost चल सकता था
  • The Browser Company ने patch के साथ $2,000 का bounty दिया, और CVE-2024-45489 आवंटित होने के बाद Firebase usage कम करने, security audit और bug bounty program चलाने की योजना बनाई

Arc के cloud features और Firestore का उपयोग

  • Arc को इस्तेमाल करने के लिए account चाहिए था, और signup प्रक्रिया में Firebase authentication इस्तेमाल होने की पुष्टि हुई
  • शुरुआती network observation में दूसरी requests दिखी नहीं, लेकिन Easels sharing feature देखने पर Firestore के उपयोग की संभावना सामने आई
  • Easels एक whiteboard-style interface है, जिसे दूसरों के साथ share करने पर web पर देखा जा सकता है
  • Firestore एक database-as-a-backend service है, जिसमें अलग backend के बिना database security rules और client direct access से features बनाए जा सकते हैं
  • Firestore security rules की कमजोरी वाले पुराने उदाहरण के रूप में Firewreck का उल्लेख किया गया

Firebase calls की पुष्टि कैसे की गई

  • Firebase का Swift SDK system proxy settings को फॉलो नहीं करता था, इसलिए mitmproxy की जगह Frida script से संबंधित calls dump किए गए
  • script ने Objective-C classes की Firestore calls को hook किया
    • FIRCollectionReference["- documentWithPath:"]
    • FIRQuery["- queryWhereField:isEqualTo:"]
    • FIRFirestore["- collectionWithPath:"]
    • getDocuments, addSnapshotListener:, getDocument जैसे execution methods
    • updateData, setData series के document write methods
  • Arc चलाते समय Firestore paths और queries के ये प्रकार देखे गए
    • preferences/{userID}
    • preferences/{userID}/stringValues/...
    • users/{userID}
    • user_referrals में inviter_id == {userID} query
    • boosts में creatorID == {userID} query
  • इस structure में Arc कुछ settings, base user object, referral info और Boosts को Firestore में store कर रहा था

Boosts attack path क्यों बने

  • Arc Boosts ऐसी feature है जिससे user वेबसाइट को customize कर सकता है
    • element blocking
    • font change
    • color change
    • custom CSS
    • custom JavaScript
  • Boosts Firestore में store होते हैं, और Arc browser किस Boost को लागू करे यह creatorID field से query करके तय करता है
  • हमलावर ने अपने account में Google.com के लिए Boost बनाया और फिर Firestore document के कुछ parameters बदलकर test किया
  • creatorID आधारित query की वजह से दूसरे users के Boosts सीधे query नहीं किए जा सकते थे, लेकिन अपने Boost document का creatorID दूसरे account के user ID में बदला जा सकता था
  • दूसरे account के साथ test करने पर, पीड़ित के computer से Google.com खोलते ही हमलावर का बनाया Boost लागू हो गया

Attack chain और user ID हासिल करना

  • अंतिम attack flow इस तरह था
    • पीड़ित का user ID हासिल करना
    • हमलावर के account से इच्छित payload वाला malicious Boost बनाना
    • Boost document की creatorID field को पीड़ित के user ID में बदलना
    • पीड़ित target website पर जाए तो malicious Boost execute हो जाना
  • यह भेद्यता इसलिए संभव हुई क्योंकि Arc Boosts में arbitrary JavaScript शामिल हो सकता था, वह Firestore में store होता था, और उसका apply target creatorID field से तय होता था
  • पीड़ित का user ID पाने के कई रास्ते थे
    • user_referrals: किसी को Arc पर invite करने या किसी से referral मिलने पर user_referrals table से दूसरे पक्ष का user ID मिल सकता था
    • सार्वजनिक Boosts: JavaScript के बिना Boosts share किए जा सकते हैं, और Arc Boosts public site के boostSnapshots में creator user ID शामिल होता था
    • Easels: share किए जा सकने वाले whiteboard feature के जरिए भी user ID मिल सकता था

Patch और disclosure timeline

  • The Browser Company आम तौर पर bug bounty नहीं चलाती थी, लेकिन इस भेद्यता के लिए $2,000 USD दिया गया
  • भेद्यता की timeline इस प्रकार थी
    • 25 अगस्त 5:48pm: Arc co-founder Hursh से Signal पर पहला संपर्क
    • 25 अगस्त 6:02pm: Hursh के Arc account पर vulnerability PoC चलाया गया
    • 25 अगस्त 6:13pm: encrypted format में details share करने के बाद Slack channel में जोड़ा गया
    • 26 अगस्त 9:41pm: vulnerability patch और bounty payment
    • 6 सितंबर 7:49pm: CVE-2024-45489 आवंटित
  • इसके बाद Arc ने इस मुद्दे पर अपना लेख CVE-2024-45489 incident response प्रकाशित किया

Privileged pages पर execution और privacy conflict

  • Boosts भले client पर बनाए न जा सकें, फिर भी वे दूसरे protocols पर execute हो सकते थे
  • settings page को target करने वाला Boost chrome://settings पर चल सकता था, जिससे privilege escalation हो सकता था
  • साइट विज़िट के समय यह Firestore query होती थी
    • boosts collection में creatorID == {userID} और hostPattern == "www.google.com"; शर्तों के साथ query
  • यहां hostPattern विज़िट की गई साइट को दर्शाता है, जो Arc की उस privacy policy से टकराता है जिसमें कहा गया था कि Arc को यह पता नहीं होता कि user कौन-सी साइट विज़िट कर रहा है

Arc के follow-up कदम

  • Arc ने इस भेद्यता और नए features के संदर्भ में Firebase से दूर जाने की दिशा में बदलाव शुरू किया
  • Arc के अपने summary में ये कदम शामिल थे
    • issue fix की पुष्टि
    • client side पर Boosts disable करने की सुविधा जोड़ना
    • मौजूदा Firebase ACL rules का internal audit
    • security issue response protocol बनाना
  • Arc की internal discussion में साझा किए गए अतिरिक्त कदम ये थे
    • v1.61.1 update में privacy issue fix
    • नए features और products में Firebase का उपयोग बंद करना
    • उस version के लिए external security audit
    • भविष्य की vulnerabilities के लिए bug bounty program शुरू करना

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

1 टिप्पणियां

 
GN⁺ 2024-09-20
Hacker News की रायें

  • मैं Hursh हूँ, Arc बनाने वाली The Browser Company का co-founder और CTO. असल में कोई user प्रभावित नहीं हुआ और हमने तुरंत patch कर दिया, लेकिन हमें लगता है कि इस vulnerability की संभावित गंभीरता अस्वीकार्य थी
    तकनीकी विवरण, आगे के सुधारों की योजना, Firebase से दूर जाने और औपचारिक bug bounty program बनाने की बात यहाँ संक्षेप में लिखी है: https://arc.net/blog/CVE-2024-45489-incident-response
    vulnerability खुद और देर से हुई communication—दोनों के लिए सच में माफ़ी, और निराशा·गुस्से·हौसला बढ़ाने समेत feedback की वजह से हमें बेहतर करने की ज़िम्मेदारी और महसूस हुई

    • शक है कि क्या यह पोस्ट सिर्फ HN users के लिए लिखी गई है. blog list(https://arc.net/blog) में भी नहीं दिख रही और Twitter पर भी नहीं डाली गई है
      पूरा response ऐसा लगता है जैसे तभी react करते हैं जब मामला काफ़ी शोर मचा दे
    • मेरे कुछ दोस्त Arc पसंद करते हैं, इसलिए मैं खुद switch करने पर भी विचार कर रहा था, लेकिन अब इस्तेमाल नहीं करने का सोच रहा हूँ. वजह vulnerability खुद नहीं, बल्कि यह है कि सभी users को ख़तरनाक तरीके से takeover कर सकने वाले bug के लिए सिर्फ $2k bounty दी गई
      मैं ऐसा browser इस्तेमाल नहीं करना चाहता जिसे बनाने वाली company user security को इतना हल्के में लेती हो. पक्का नहीं, लेकिन इस level की गंभीरता वाला exploit शायद black market में इससे कहीं ज़्यादा महँगा बिक सकता था
    • नीचे comments में चिंता है कि क्या हर page load पर URL और identifiable user ID TBC को भेजी जा रही थी. Chrome के अलावा browser इस्तेमाल करने वाले लोग आम तौर पर privacy को लेकर भी संवेदनशील हो सकते हैं, इसलिए इस हिस्से का जवाब देना अच्छा होगा
      vulnerabilities हो सकती हैं, लेकिन browsing data भेजना एक जानबूझकर किया गया design choice लगता है
    • यह घटना देखने के बाद team के पास browser maintain करने की expertise है, यह समझाने का कोई तरीका नहीं दिखता. इसे fix कर दिया गया—इससे अलग, अभी भी और आगे भी safe browser बनाने की क्षमता उनमें नहीं दिखती
      मुझे लगता है कि यह CTO के resign करने लायक मामला है
    • जानना चाहता हूँ कि क्या bug bounty payout बढ़ाने की योजना है. $2,000 इस bug की value की तुलना में बहुत छोटी रकम है, और उम्मीद है कि finder को उचित reward दिया जाएगा
      सही दिशा पकड़ने का यह एक बेहतरीन मौका मिला है

  • यहाँ comments में लोग Firebase को बहुत दोष दे रहे हैं, लेकिन ऐसा लगता है कि वे असल में ठीक से न जानते हुए बातें दोहरा रहे हैं. मैं Firebase इस्तेमाल नहीं करता, लेकिन पहले इस्तेमाल करने के अनुभव से कहूँ तो यह न कोई edge case है, न ही solve करने में मुश्किल problem—यह तो बिल्कुल basic है
    असली समस्या यह है कि API को client द्वारा भेजी गई “मैं कौन हूँ” वाली value पर भरोसा करने के लिए बनाया गया था. आखिरकार यह amateur mistake है, और शायद एक line के बदलाव से ठीक हो सकती थी. docs देखकर भी https://firebase.google.com/docs/rules/rules-and-auth#cloud-... में request.auth ज़रूरी user ID(request.auth.uid) देता है

    • Firebase से बनी app चलाने वाले के तौर पर सहमत हूँ. लेखक ने सही पकड़ा है कि config mistake करना बहुत आसान है, लेकिन ऐसी basic security practices Firebase docs में bold और साफ़ warnings के साथ highlight की गई हैं
      security rules को गंभीरता से लेना चाहिए, और वे असल में defense की एकमात्र line हैं
    • यह दिलचस्प है कि software engineers पहले खुद authentication बनाते थे, फिर खुद न बनाने की तरफ गए, और अब इतनी खुली security problem भी नहीं पहचान पा रहे हैं
      खुद authentication बनाओ या न बनाओ, core बात एक ही है: client पर कभी भरोसा मत करो
    • अगर “आखिरकार amateur mistake” है तो बल्कि अच्छा होगा. मेरे colleagues ने भी internal frontend apps में यही गलती कई बार की है
    • कोई भी व्यक्ति कभी amateur mistake नहीं करेगा, इस assumption पर निर्भर security plan खुद एक amateur mistake है
    • अगर मैंने सही समझा है, तो इस issue का fix firestore.rules के match statement के अंदर नीचे वाला rule डालने जितना ही था. Firebase Firestore security के beginner-level docs में यही बात सीधे मिलती है 
      
// Allow create new object if user is authenticated

allow create: if request.auth != null;

// Allow update or delete document if user is owner of document

allow update, delete: if request.auth.uid == resource.data.ownerUID

  • click की हुई जगह की तरफ दौड़कर आने वाली छोटी pixel art cat मुझे सच में बहुत पसंद आई. आजकल कम दिखने वाली मज़ेदार और creative छोटी चीज़ थी, और एक reminder जैसी लगी कि अगर हम चाहें तो internet भी इतना आनंददायक space हो सकता है

    • मेरी तरफ तो नहीं दिखी, शायद developer prefers-reduced-motion का सम्मान कर रहा है और वह setting हो तो इसे display नहीं करता. जो चाहते हैं उन्हें मज़ा देना और जिन्हें पसंद नहीं उन्हें परेशानी से बचाना—बहुत अच्छा handling है
    • 35 साल की बिल्ली के हिसाब से तो यह काफ़ी अच्छी तरह चल रही है
      https://en.wikipedia.org/wiki/Neko_(software)
    • Debian में cat को इस तरह install और run कर सकते हैं
      sudo apt install oneko
      oneko &
      अपनी seat से दूर गए colleague के computer पर gift करने के लिए अच्छा है
    • cute तो है, लेकिन यह पता था कि mouse हिलाने या scroll करने पर हर बार cat move करेगी, इसलिए article पर focus नहीं कर पा रहा था. console खोलकर उसे हटा दिया. sorry, cat
    • phone पर वह लगातार text ढक रही थी, इसलिए उसे हटाने का तरीका ढूँढ रहा था. Firefox reading mode से solve हो गया

  • इस लेख के मुताबिक Arc में account अनिवार्य है, और वह आपके visit किए हर page का hostname और user ID Google Firebase को भेजता है। तो क्या Arc अभी इस्तेमाल हो रहे browsers में सबसे कमजोर privacy वाला browser नहीं बन जाता?

    • install करते ही जब पता चला कि account अनिवार्य है, मैंने तुरंत Arc हटा दिया। यह Wi‑Fi की जरूरत वाले toothbrush जितना बेतुका लगा था, लेकिन अब देख रहा हूं तो मामला और गंभीर है
    • लगता है वह खिताब OperaGX ले जाएगा
    • यह भी जानना चाहूंगा कि Firebase down होने पर Arc कितना टूट जाएगा
    • कुछ महीने पहले जब मैंने इसे download किया था, तो इस्तेमाल के लिए account चाहिए देखकर instinct हुई कि बस Firefox ही इस्तेमाल करते रहना बेहतर है
    • क्या वे Firebase को भेजे जाने वाले data को encrypt नहीं करते? अगर data sensitive है, तो Google भी ऐसा करने की सलाह देगा

  • सच में शानदार bug है। Firebase जैसी backend services के security rules में कुछ अजीब defaults होते हैं जिन्हें समझाना मुश्किल है। अगर मैं खुद API बनाता, तो इस case के boost जैसे record का userId request payload से नहीं लेता, बल्कि session के user ID पर set करता
    एक certain level से ऊपर का developer protected API route में client से अपने userId होने का दावा करने वाली value pass कराने के बारे में आम तौर पर सोचता ही नहीं। दूसरी ओर, security rules में actual programmed use से अलग, system का misuse किए जा सकने वाले हर तरीके की कल्पना करनी पड़ती है

    • अगर आप उस तरीके से approach कर रहे हैं, तो सच कहूं तो आप गलत कर रहे हैं। default deny से शुरू करें, तो आपको सिर्फ legitimate usage patterns की कल्पना करनी होती है
    • insert के मामले में यह सही है, लेकिन update में मैंने अक्सर देखा है कि पूरा request सीधे ORM या document store में डाल दिया जाता है। “owner document update कर सकता है” सोचना आसान है, लेकिन यह छूट सकता है कि कुछ fields जिन्हें official client set नहीं करता—जैसे owner या creation time—बदलने नहीं चाहिए
      सही solution शायद हर field के लिए default deny permissions रखना है। तब कम से कम owner field को writable करने के लिए explicit करना पड़ेगा, और इस object को किसी दूसरे user को transfer करने के impact के बारे में भी सोचना पड़ेगा

  • हैरानी होती है कि यह vulnerability कितनी बेवकूफाना है। arbitrary code execution करने के लिए सचमुच बस किसी और का user ID भेजना है, और वह ID हासिल करना भी काफी आसान है
    मैं FAANG में काम नहीं करता, और एक ऐसी company में काम करता हूं जो एक घटिया product बनाती है जिसकी असल में जरूरत भी नहीं, लेकिन मैं भी ऐसा bug नहीं बनाऊंगा। फिर ये लोग browser बनाने की बात करते हैं, और उसके साथ आने वाली security expertise और नैतिक जिम्मेदारी भी उठाना चाहते हैं?

    • क्या आप समझा सकते हैं कि किसी और का user ID कैसे मिल सकता है? मुझे पता है कि यह बड़ी vulnerability है, लेकिन समझना चाहता हूं कि वह हिस्सा कैसे होता है

  • post title में Arc होना चाहिए ताकि Arc इस्तेमाल करने वाले या Arc users को जानने वाले लोग इसे बेहतर पहचान सकें

    • पूरी तरह सहमत। कल पहली बार जब देखा तो मुझे लगा ही नहीं कि यह मुझ पर लागू होता है, और title बदलने के बाद ही click किया
      सच कहूं तो मुझे strongly लगता है कि title “Arc browser का fundamental bug (CVE 123-4567)” जैसा होना चाहिए

  • दुनिया में कई गंभीर security vulnerabilities ऐसी होती हैं जो समझने लायक तरीके से बन जाती हैं, और अगर responsibly handle करके fix कर दिया जाए तो माफ की जा सकती हैं
    लेकिन यह वैसा case नहीं है। personally यह reputation खराब कर देने लायक अक्षमता दिखाता है, और मुझे फिर कभी Arc न इस्तेमाल करने का फैसला कराने के लिए काफी है

    • दूसरी तरफ response speed खुद काफी impressive है
      aug 25 5:48pm: Signal encrypted channel पर Arc co-founder Hursh से पहला contact
      aug 25 6:02pm: Hursh के Arc account पर vulnerability proof of concept run
      aug 25 6:13pm: encrypted format में details disclose करने के बाद Slack channel में add किया गया
      aug 26 9:41pm: vulnerability patch, bounty paid
      sep 6 7:49pm: CVE assigned (CVE-2024-45489)
      sudden first contact से fix deploy होने तक 4 घंटे, यह काफी अच्छा है, भले ही fix simple रहा हो। correction: date बदल गई थी, तो असल में 28 घंटे थे। फिर भी decent है, और first contact के 30 मिनट के अंदर “हमारे Slack channel में आ जाइए” वाला response बहुत तेज है
    • Arc को एक बार try करने के लिए भी mandatory account चाहिए था, यह शुरू से बड़ा red flag था, इसलिए मैंने इसे try ही नहीं किया। अब अच्छा है कि नहीं किया
    • सच कहूं तो Arc मुझे हमेशा खासकर privacy के मामले में भेड़ की खाल में भेड़िया जैसा लगा
      browser जैसे important और personal product में, $50–60 million cash और $500 million valuation होने के बावजूद कोई business model न होना बड़ा red flag है। यह charity नहीं है, इसलिए किसी न किसी तरह किसी को cost चुकानी ही पड़ेगी
    • browser distribute करने वाली company से आप उम्मीद करते हैं कि वह security rules पर थोड़ी ज्यादा care करेगी
      Firebase का इसे थोड़ा और idiot-proof न बना पाना भी अफसोसजनक है। और सच में सिर्फ $2,500? literally Arc के सभी users पर कब्जा किया जा सकता था; NSA होती तो कुछ और zero जोड़ देती
    • ऊपर से Firebase, सच में? जिस company ने low-level software engineers तक hire किए हैं, वह boxed CRUD backend इस्तेमाल कर रही है। cost-efficient जरूर रहा होगा, लेकिन अगर मैं ऐसा design करता, तो Firebase backend candidates की लंबी list में भी नहीं होता
      खासकर जब Supabase जैसे functional competitors regular DBMS और authentication model को wrap करने के तरीके पर हैं

  • share करने के लिए thanks। beta के पहले हफ्ते से Arc इस्तेमाल कर रहा हूं
    लेकिन यह काफी concerning है कि उन्होंने इस bug और fix को social media पर कहीं mention नहीं किया। Arc इस्तेमाल करने का समय अच्छा रहा, लेकिन इस handling को देखकर लगता नहीं कि आगे continue कर पाऊंगा

    • problem स्वीकार करके 28 घंटे के अंदर fix करना काफी नहीं है? ऐसी response देखकर मुझे लगता है कि Arc इस्तेमाल करते रहना ठीक है

  • इतनी बड़ी vulnerability के लिए $2,000 insulting amount है

    • HN के blog posts देखकर लगता है कि ऐसी vulnerabilities को अक्सर कोई reward नहीं मिलता या बहुत छोटी amount मिलती है। ऐसा लगता है जैसे companies hackers से exploit बेचने की विनती कर रही हों
      शायद ऐसा इसलिए भी हो सकता है कि breach incidents पर regulators उन्हें punish नहीं करते
    • सही, मेरी भी पहली reaction यही थी। इतना कंजूस होना सच में चौंकाने वाला था
    • इस amount का 20–50 गुना देने वाले malicious पक्ष को न बेचने के लिए काफी मजबूत conscience चाहिए