15 साल के लड़के ने Zendesk में एक backdoor bug खोजकर $50,000 कमाए

 (gist.github.com/hackermondev)
13 पॉइंट द्वारा GN⁺ 2024-10-13 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • खाली समय में bug hunting करने वाले 15 साल के एक लड़के ने Fortune 500 कंपनियों द्वारा इस्तेमाल किए जाने वाले Zendesk में email verification से जुड़ा एक bug खोजा
  • उसने इसकी जानकारी कई कंपनियों को देकर $50,000 से अधिक कमाए, लेकिन Zendesk ने bug patch करने के बावजूद रिपोर्ट करने वाले को कोई bounty नहीं दी

Zendesk का परिचय

  • Zendesk दुनिया की शीर्ष कंपनियों द्वारा इस्तेमाल किया जाने वाला customer service tool है
  • support email को Zendesk से जोड़ने पर Zendesk incoming emails को manage करता है और tickets बनाता है
  • यह हैरान करने वाली बात है कि कई बड़ी कंपनियां अपना ticket system बनाने के बजाय Zendesk पर निर्भर हैं

सबसे कमजोर कड़ी

  • "सिस्टम उतना ही मजबूत होता है जितनी उसकी सबसे कमजोर कड़ी" की तरह, Zendesk को अक्सर एक साधारण ticket tool मानकर बिना सावधानीपूर्वक configuration के इस्तेमाल किया जाता है
  • अगर "@company.com" domain को single sign-on(SSO) के लिए इस्तेमाल किया जाए और उसे Zendesk से जोड़ा जाए, तो security vulnerability पैदा हो सकती है
  • क्योंकि Zendesk domain emails को process करता है, अगर SSO system email address को ठीक से verify नहीं करता, तो Zendesk तक पहुंच रखने वाला व्यक्ति internal systems का दुरुपयोग कर सकता है

Email spoofing

  • एक गंभीर Zendesk vulnerability मिली, जिसके कारण attacker Zendesk इस्तेमाल करने वाली कंपनी के customer support tickets पढ़ सकता था
  • Zendesk में email spoofing के खिलाफ प्रभावी सुरक्षा तंत्र नहीं था
  • अगर attacker को support email address और ticket ID पता हो, तो वह email spoofing के जरिए असली sender बनकर ticket तक पहुंच सकता था
  • लेखक ने bug report किया, लेकिन Zendesk ने शुरुआत में इसमें रुचि नहीं दिखाई
    • email spoofing (SPF, DKIM, DMARC issues) को Out of Scope बताया गया
  • रिपोर्ट HackerOne service के जरिए process की गई, और Zendesk team member को सीधे report करने का अनुरोध भी ठुकरा दिया गया

इस issue को Slack takeover तक बढ़ाना

  • email spoofing bug को अलग-अलग कंपनियों को report किया जा सकता था, लेकिन लेखक इसका बड़ा impact दिखाना चाहता था
  • पहले एक अन्य researcher ने Zendesk के जरिए सैकड़ों कंपनियों के Slack में घुसपैठ की थी (TICKETTRICK)
  • लेखक ने अपने bug से इसे दोबारा reproduce करने की कोशिश की, लेकिन कुछ मुश्किलें थीं
  • Slack ने email address में random token जोड़कर verification करने का तरीका अपना लिया था
  • लेकिन OAuth के जरिए Apple ID से login करते समय token इस्तेमाल नहीं होता था, इसलिए इसे bypass किया जा सका

Reproduction steps: Apple → Zendesk → Slack

  1. "support@company.com" से Apple ID बनाएं और verification code मांगें, तो Zendesk ticket बनता है
  2. company.com support portal में अपने email से ticket बनाकर ID range को track करें
  3. email spoofing bug से उस ID range के सभी tickets में खुद को जोड़ने की कोशिश करें
  4. daniel@wearehackerone.com account से उस कंपनी के support portal में login करें और CC किए गए tickets देखें
  5. Apple ID में verification code दर्ज करें
  6. Slack के "Sign in with Apple" feature से @company.com email से जुड़े Apple ID द्वारा login करें और Slack में login हो जाएं
    लेखक ने इन 6 steps को सैकड़ों Zendesk और Slack instances पर लागू किया

घटना के बाद

  • एक हफ्ते तक अलग-अलग कंपनियों को vulnerability report भेजी गई; कुछ ने तुरंत कार्रवाई की, जबकि कुछ ने कहा कि यह Zendesk की समस्या है
  • कुछ कंपनियों ने Zendesk से संपर्क किया, जिसके बाद Zendesk ने अंततः रिपोर्ट को private रखने का अनुरोध किया और Slack vulnerability के reproduction steps मांगे
  • Slack takeover PoC देने के बाद Zendesk ने समस्या की पुष्टि की, लेकिन fix करने में 2 महीने लगे
  • कई कंपनियों ने अपने instances को सुरक्षित रखने के लिए email collaboration feature disable कर दिया
  • लेखक को इस bug bounty report के जरिए HackerOne और अन्य platforms पर अलग-अलग कंपनियों से $50,000 से अधिक का reward मिला
  • कुछ कंपनियों ने Zendesk के साथ अपना contract समाप्त कर दिया

Zendesk का fix और मेरी $0 bounty

  • 2 महीने बाद Zendesk ने पुष्टि की कि समस्या हल कर दी गई है
  • उसने Cloudmark और Rspamd EAP spam filter इस्तेमाल किए, लेकिन Rspamd score का उपयोग न करने की वजह से कई emails hold पर नहीं गईं
  • शुरुआत में fix यह था कि कुछ शर्तों के तहत अपने-आप Rspamd पर switch किया जाए
  • बाद में Apple और Google authentication emails को अपने-आप hold करने वाला filter लागू किया गया
  • समस्या हल करने के बावजूद Zendesk ने अंततः इस bug bounty report पर reward न देने का फैसला किया
    • क्योंकि लेखक ने vulnerability को प्रभावित कंपनियों के साथ साझा करके HackerOne की disclosure guidelines का उल्लंघन किया

निष्कर्ष

  • एक छोटा email bug दुनिया की सबसे बड़ी कंपनियों के internal systems में घुसपैठ तक पहुंच गया
  • Zendesk ने आखिरकार vulnerability fix की, लेकिन इनकार, धीमी प्रतिक्रिया और अनदेखी की प्रक्रिया बेहद कठिन रही
  • bug hunting की यही हकीकत है—कभी जीत, कभी हार

GN⁺ की राय

  • Zendesk प्रकरण दिखाता है कि third-party solution को बिना आलोचनात्मक समीक्षा के अपनाना कितना जोखिमभरा हो सकता है। किसी भी प्रसिद्ध कंपनी का product हो, security review अनिवार्य है।
  • बड़ी कंपनियों के internal systems का takeover भारी नुकसान पहुंचा सकता है, इसलिए Zendesk की धीमी प्रतिक्रिया बेहद गैरजिम्मेदाराना थी। bounty देने से इनकार करना security researchers का मनोबल भी गिराता है।
  • कंपनियों को SSO domain बहुत सावधानी से चुनना चाहिए और email verification process को मजबूत करना चाहिए। DMARC, SPF, DKIM जैसी email authentication technologies का सक्रिय उपयोग जरूरी है।
  • HackerOne की disclosure guidelines researcher के नजरिए से बहुत कठोर लगती हैं। गंभीर vulnerabilities को तेजी से साझा किया जाना चाहिए, इसलिए परिस्थिति के अनुसार अधिक लचीला दृष्टिकोण जरूरी है।
  • bug hunting कंपनियों और researchers दोनों के लिए win-win होनी चाहिए। उम्मीद है कि researchers की सद्भावना और मेहनत का सम्मान करने और उन्हें उचित reward देने वाली संस्कृति बनेगी।

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

2 टिप्पणियां

 
aer0700 2024-10-13

ऐसे issues को देखकर लगता है कि security solutions को बस लाकर इस्तेमाल करने के बजाय, security experts को लाना और उन्हें तैयार करना कहीं ज़्यादा बेहतर है T_T
 
GN⁺ 2024-10-13
Hacker News राय

  • एक उपयोगकर्ता ने उल्लेख किया कि उसने जून 2024 में Zendesk, Apple और Slack को यही bug रिपोर्ट किया था, और शायद उन्हें bug bounty इसलिए नहीं मिली क्योंकि वे पहले रिपोर्ट करने वाले नहीं थे

    • गैर-directory SSO विकल्प Sign in with Apple (SIWA) को गलत तरीके से implement किया गया था, और यही स्थिति Slack जैसी बड़ी कंपनियों में भी थी
    • गैर-directory SSO को directory SSO जितना भरोसा नहीं दिया जा सकता, और SSO providers एक ही email address इस्तेमाल करने पर भी एक-दूसरे के विकल्प नहीं होते

  • एक अन्य उपयोगकर्ता ने दावा किया कि Zendesk ने Google search results को प्रदूषित करने के लिए "Zendesk Alternative" नाम का एक fake band बनाया

    • उसने कहा कि यह अवैध तो नहीं है, लेकिन यह उनकी सोच दिखाने वाला एक manipulative व्यवहार है

  • एक उपयोगकर्ता ने कहा कि Zendesk का bug के लिए इनाम देने से इनकार करना निराशाजनक है, और यही तरीका लोगों को बड़े bounty programs में भाग न लेने के लिए मजबूर करता है

    • उसने जोड़ा कि Zendesk के साथ उसका interview experience बहुत खराब था

  • एक और उपयोगकर्ता ने कहा कि अक्षम bug bounty programs software services पर नकारात्मक असर डालते हैं

    • उसका तर्क था कि Zendesk को इनाम देना चाहिए, माफी मांगनी चाहिए, और program में सुधार करना चाहिए

  • एक उपयोगकर्ता ने आलोचना की कि 1.3 अरब डॉलर का revenue कमाने वाली कंपनी होने के बावजूद Zendesk का इनाम न देना short-term सोच है

    • उसने कहा कि यह कोई तर्कसंगत फैसला नहीं है, और private capital लागत घटाकर brand को खपा रहा है

  • एक अन्य उपयोगकर्ता ने समझाया कि शायद Zendesk ने इसे इसलिए नजरअंदाज किया क्योंकि वह bug के प्रभाव को ठीक से समझ नहीं पाया

    • उसने कहा कि स्पष्ट impact न होने पर कई vulnerabilities सिर्फ साधारण bug जैसी लग सकती हैं

  • एक उपयोगकर्ता ने बताया कि Zendesk ने केवल Apple account verification email की समस्या ठीक की, लेकिन मूल समस्या को नहीं सुलझाया

    • उसने कहा कि default settings में अगर किसी को email और ticket ID पता हो, तो कोई भी support ticket hijack कर सकता है

  • उसने समझाया कि यहाँ दो अलग-अलग vulnerabilities मौजूद थीं

    • Zendesk मूल requester के email address से reply भेजने और CC जोड़ने की अनुमति देता था
    • Slack बिना अतिरिक्त verification के Sign in with Apple के जरिए पूरे domain login की अनुमति देता था

  • Zendesk की इस बात के लिए आलोचना की गई कि उसने समस्या को नजरअंदाज किया और उसे private रखने की कोशिश की

    • कहा गया कि यह गैर-पेशेवर रवैया है, और शायद यही इनाम न देने का कारण भी रहा हो

  • आखिर में, एक उपयोगकर्ता ने Zendesk द्वारा bug के लिए इनाम देने से इनकार करने की आलोचना की और इस बात पर जोर दिया कि रिपोर्ट करने वाले ने सारी प्रक्रिया सही तरीके से पूरी की थी