Harvest ऐप के खुले रीडायरेक्ट से Microsoft अकाउंट OAuth टोकन चोरी संभव

• Harvest के Outlook Calendar OAuth कनेक्शन फ्लो में callback URL, state वैल्यू की मंज़िल पर फिर से चला जाता था, जिससे open redirect होता था; implicit grant flow के साथ मिलाने पर token बाहरी URL पर उजागर हो सकता था
• समस्या Microsoft में नहीं, बल्कि Harvest integration की तरफ थी; registered OAuth redirect_uri एक redirect relay बन गया था जो उपयोगकर्ता को हमलावर द्वारा तय किए गए domain पर भेज देता था
• state URI-encoded JSON है, और subdomain में example.com/ जैसे slash लगे बाहरी domain को डालने पर navigation example.com/.harvestapp.com/... जैसे रूप में हो जाता है
• PoC ने Microsoft OAuth authorize URL में client_id=0dcef4db-36d8-4aed-9cc5-ab43e1814884, response_type=id_token, response_mode=fragment, scope=openid का इस्तेमाल करके यह flow दिखाया जिसमें #id_token=... fragment redirect target से जुड़ जाता है
• vulnerability 23 अगस्त 2020 को report की गई थी, 1 अगस्त 2023 को patch की पुष्टि हुई, और 22 अक्टूबर 2023 को Harvest ने देरी को human error बताते हुए माफी मांगी

---

OAuth callback में token leak होने का flow

• Harvest एक time-tracking software है जिसमें users Outlook Calendar को OAuth के जरिए connect कर सकते हैं
• authorization सफल होने पर user को https://outlook-integration.harvestapp.com/auth/outlook-calendar/… पर redirect किया जाता है
• यह callback फिर user को state के अंदर दिए गए URL पर भेजता है, और इसी प्रक्रिया में open redirect होता है
• मूल रूप से पहचाने गए callback URL की state value URI-encoded JSON है
  • Decode करने पर यह {"return_to":"/","subdomain":"hackerone295"} जैसा होता है
  • subdomain value का इस्तेमाल hackerone295.harvestapp.com जैसे Harvest app space का अनुमान लगाने के लिए किया जाता है
• अगर subdomain में example.com/ जैसा slash जोड़ दिया जाए, तो callback URL बाहरी domain पर redirect होने लगता है
• यह callback URL OAuth application में registered redirect_uri है, इसलिए open redirect और implicit grant flow को मिलाने पर token redirect target पर उजागर हो सकता है
• PoC authorize URL ने ये values इस्तेमाल कीं
  • client_id=0dcef4db-36d8-4aed-9cc5-ab43e1814884
  • response_type=id_token
  • redirect_uri=https://outlook-integration.harvestapp.com/auth/outlook-calendar/…?...
  • scope=openid
  • response_mode=fragment
  • state=1
  • nonce=123456
• user आखिर में इस तरह के रूप में redirect होता है
  • https://example.com/.harvestapp.com/auth/… access token]&state=1
• यह Microsoft की तरफ की vulnerability नहीं है

report से patch तक लगा समय

• vulnerability disclosure और patching प्रक्रिया में Harvest team की response बहुत कम रही, और triage में vulnerability स्वीकार करने के बाद भी fix तक लंबा समय लगा
• vulnerability 23 अगस्त 2020 को report की गई, और Harvest ने 16 अक्टूबर 2020 को पहली बार contact किया
• 27 नवंबर 2020 को report triaged status में गई
• 28 अप्रैल 2022 को company ने कहा कि fix जारी है और अनुमानित समय 2 हफ्ते बताया, लेकिन असल fix में लगभग 1 साल और लग गया
• 1 अगस्त 2023 को vulnerability patch होने की पुष्टि हुई
• 21 अक्टूबर 2023 को public post के जरिए report सार्वजनिक हुई
• उसी दिन तक report अभी भी triage status में थी, और bug bounty policy में reward का उल्लेख था, लेकिन bounty या HackerOne points नहीं दिए गए
• 22 अक्टूबर 2023 को post पर ध्यान जाने के बाद Harvest ने देरी को human error बताते हुए माफी मांगी

[GN⁺]

Hacker News टिप्पणियाँ

• bug bounty program के प्रभारी के रूप में, मैं समझाता हूँ कि अंदर क्या हुआ था। मैं पहले ही @0xcrypto से माफ़ी मांग चुका हूँ और अंदरूनी तौर पर समझा भी चुका हूँ, लेकिन मुझे लगता है कि यहाँ भी इसे समेटना सही होगा
  शुरू से ही हम इस समस्या को पूरी तरह reproduce नहीं कर पाए थे, और कुछ छूट न जाए इस डर से इसे बंद भी नहीं कर पा रहे थे। आख़िरी बार “हम समाधान ढूँढेंगे” कहने के तुरंत बाद हम इस निष्कर्ष के क़रीब पहुँच गए कि यह reproduce नहीं हो रहा, और इसी बीच इसी तरह की OAuth-संबंधित रिपोर्ट आने से अंदर भ्रम पैदा हुआ और हमने ग़लती से समझ लिया कि इसे पहले ही संभालकर आगे भेज दिया गया है
  notification settings की वजह से हम follow-up संदेश चूक गए, और यह issue Triage स्थिति में अनिश्चितकाल तक पड़ा रहा, बिना किसी अपडेट के। यह कोई बहाना नहीं है, और मैंने खुद लंबे समय तक bug bounty hunter के रूप में काम किया है, इसलिए मैं अच्छी तरह जानता हूँ कि कंपनी के अपडेट का इंतज़ार करना कितना निराशाजनक होता है। ग्राहक सुरक्षा हमारी सर्वोच्च प्राथमिकता है, और security page पर लिखा हुआ सच है

  • ग़लतियाँ हो सकती हैं, लेकिन यह अब भी समझाया नहीं गया है कि 3 साल तक HackerOne से कई बार संपर्क करने के बावजूद HackerOne Harvest से संपर्क क्यों नहीं कर सका
    इसके अलावा, अब यह भी स्पष्ट नहीं है कि ऐसी रिपोर्ट का क्या किया जाए जिसे अब reproduce नहीं किया जा सकता। मैं HackerOne पर इस पर और चर्चा करना चाहता था, लेकिन माफ़ी वाले संदेश के बाद फिर से कोई जवाब नहीं आया, ऐसा लगता है
  • आख़िरकार, मैं यह जानना चाहता हूँ कि क्या आप मानते हैं कि यह vulnerability वास्तव में बताए गए तरीके से काम करती थी, और अगर हाँ, तो फिर इसे reproduce करने में असफलता क्यों हुई
  • सीधे स्पष्टीकरण सुनना अच्छा है। भले ही यह reproduce न हुआ हो, क्या source code देखकर आसानी से यह सत्यापित नहीं किया जा सकता था कि open redirect संभव है या नहीं?
  • कम से कम यह अच्छा है कि आपने यह लिखकर दिखाया कि आप इसे गंभीरता से ले रहे हैं। ग़लती किसी से भी हो सकती है, लेकिन जब ग़लती के बाद ज़िम्मेदारी नहीं ली जाती, तब मामला बड़ा हो जाता है
  • मैं Harvest का अच्छा-खासा उपयोग करता हूँ, लेकिन अब iOS की नई mobile app को भी ठीक कर देना चाहिए। छोटी-छोटी समस्याएँ इतनी बढ़ गईं कि मैंने support team को report करना भी बंद कर दिया
    app की स्थिति अक्सर server की स्थिति से मेल नहीं खाती, और server में बदलाव forced refresh के बाद ही दिखते हैं, या client के बदलाव save होने के बाद फिर वापस पलट जाते हैं। time tracking user experience भी असुविधाजनक है, क्योंकि बटन देखने के लिए scroll करना पड़ता है, या start/stop/restart/delete बटन की जगह item की स्थिति के अनुसार बार-बार बदलती रहती है। पुराना app सुंदर नहीं था, लेकिन बिना समस्या के काम करता था

• यह काफ़ी अस्थिर करने वाला है। जब मैंने Harvest इस्तेमाल किया, तब support सच में शानदार था, जवाब तेज़ी से मिलते थे, और वे इस बात को बारीकी से समझते थे कि ग्राहक product को कैसे इस्तेमाल करते हैं, यहाँ तक कि मौजूदा features को रचनात्मक तरीक़े से इस्तेमाल करने के तरीके भी विस्तार से बताते थे
  जो features लागू नहीं थे, उनके लिए जवाब होता था, “हम इसे backlog में डाल देंगे, लेकिन गारंटी नहीं दे सकते।” [1] के अनुसार engineering staff 30 लोग हैं, लेकिन यह समझना मुश्किल है कि वह क्षमता कहाँ लग रही है, क्योंकि मैंने दूसरे features को तेज़ी से आते नहीं देखा
  “Harvest user” के रूप में मुझे spam मिलना शुरू हुआ, तो मुझे शक हुआ कि शायद customer list बेच दी गई है, लेकिन कंपनी के ज़िम्मेदार लोग तुरंत जुड़ गए, ज़ोरदार ढंग से इनकार किया, और फ़ौरन जाँच शुरू की—यह अच्छी बात थी
  लेकिन आख़िरकार यह भी engineering समस्या जैसा ही लगता है। मैंने यह पता लगाने का काफ़ी आसान तरीका खोज लिया कि active customers का अंदाज़ा कैसे लगाया जा सकता है, और यह भी “backlog” में जाने के बाद कई महीनों से ठीक नहीं हुआ है। fix बहुत छोटा लगता था। साथ ही, MFA सिर्फ Google से login करने पर ही मिलता है [2]। फिर भी app अपना काम सच में बहुत अच्छे से करता है
  1: https://www.getharvest.com/about/meet-the-team
  2: https://support.getharvest.com/hc/en-us/articles/36005266713...

  • अच्छी राय के लिए धन्यवाद। support team शानदार है—इस बात से मैं निश्चित रूप से सहमत हूँ। टीम छोटी है, लेकिन हर मामले को बहुत गंभीरता से लेती है, और ऊपर बताई गई जाँच में भी सीधे शामिल थी
    इस thread के रिपोर्टर के साथ संचार बिगड़ना पूरी तरह मेरी ग़लती थी, और जैसा मैंने ऊपर जवाब में समझाया, मैं सुनिश्चित करूँगा कि ऐसा दोबारा न हो
  • समझ नहीं आ रहा कि यह तारीफ़ है या नापसंदगी। क्या यह व्यंग्य है?
  • support की quality निश्चित रूप से अच्छी थी। अनुरोध हमेशा बहुत अनुभवी लोगों ने संभाले, और आम तौर पर कुछ ही मिनटों में जवाब मिल जाता था
    feature requests में से कुछ वास्तव में product में शामिल भी हुईं। हो सकता है वह मेरे प्रभाव से न हुआ हो, लेकिन कम से कम ऐसा लगा कि एक अच्छे time tracker को लेकर हमारी सोच मिलती-जुलती थी

• शीर्षक Microsoft के साथ काफ़ी अन्यायपूर्ण लगता है। हाल की authentication घटनाओं के कारण Microsoft पर जो ध्यान है, उसका फ़ायदा उठाने की कोशिश जैसा लगता है, और शीर्षक देखते ही मेरे मन में “फिर से MS breach?” आया
  असल में यह Harvest के token हैं, और Harvest code की injection vulnerability की वजह से सिर्फ Harvest app access permissions ग़लती से उजागर हुईं। यह किसी और identity provider के पीछे भी होता, तो भी उतना ही vulnerable होता

  • मैं उस blog post का लेखक हूँ। आपकी चिंता समझता हूँ, और मैंने शीर्षक से Microsoft का नाम हटाने की कोशिश की थी, लेकिन कोई उपयुक्त अभिव्यक्ति सूझी नहीं
    यह vulnerability केवल Microsoft account connection के लिए की गई OAuth implementation को प्रभावित करती है। मूल शीर्षक “Microsoft OAuth token leak via open redirect in Harvest App” था, और बाद में इसे “Microsoft Account's OAuth tokens leaking via open redirect in Harvest App” में बदला गया। मैं अब भी इसे बदलने के लिए तैयार हूँ और सुझावों का स्वागत करूँगा
  • मेरा भी यही विचार था। यहाँ तक कि मुझे यह भी संदेह हुआ कि क्या लेखक OAuth के काम करने का तरीका ठीक से जानते हुए भी इसे MS token कह रहा है

• RFC 6749 विस्तार से बताता है कि authorization server को ऐसे हमलों को कैसे रोकना चाहिए
  authorization server को public clients के लिए redirect URI registration अनिवार्य करनी चाहिए, और confidential clients के लिए भी करना बेहतर है. अगर request में redirect URI दिया गया है, तो authorization server को उसे registered value से मिलाकर verify करना चाहिए
  ऐसे में यह सवाल उठता है कि Harvest app ने कोई malicious redirect_uri register नहीं किया होगा, फिर यह कैसे संभव हुआ. क्या Microsoft OAuth server, OAuth client के registered redirect URI से तुलना करते समय redirect_uri के अंदर के URL parameters को ignore करता है?

  • लगता है कि उस पर एक second redirect चढ़ाया गया और उसे state parameter में रखा गया. शायद मकसद कहीं भी redirect करना था
    इरादा यह रहा होगा: Harvest auth URL पर जाना → Microsoft auth URL पर redirect_uri=registered_uri और state=some_encoded_final_uri के साथ redirect होना → user credentials दर्ज करे → registered URI पर redirect हो → state पढ़कर उसके अंदर वाले URI पर फिर redirect कर दिया जाए
    यह हमला फिर भी authorized URI पर ही redirect करता है, लेकिन वह endpoint state को पढ़कर response/token को आगे pass कर देता है. यहां तीन गलतियां थीं: state का दुरुपयोग, अगर ऐसा करना ही था तो state को encrypt और validate न करना, और implicit grant को enable करना. अगर जरूरत थी, तो सीमित उपयोग के लिए अलग registration बनानी चाहिए थी
  • Harvest का redirect_uri, Microsoft में registered था. Microsoft OAuth server ने Harvest पर redirect किया, और उसके बाद Harvest ने state के data के आधार पर अपना redirect implement किया

• Implicit grant इसी तरह की वजहों से काफी भयानक है, जैसा इस पोस्ट में दिखता है
  वैसे, आने वाली OAuth 2.1 spec में इसे हटाया जाने वाला है: https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-09.htm...

  • क्या इसे लगभग 6 साल पहले से deprecated नहीं माना जा रहा था? CORS ने इसका उपयोग-क्षेत्र बदल दिया है, इसलिए नई spec में इसे रखने की कोई वजह नहीं है

• क्या vulnerability fix करने में 3 साल लगे? अगस्त 2020 से अगस्त 2023 तक — Harvest team का size नहीं पता, लेकिन यह फिर भी असंगत रूप से लंबा लगता है

  • शायद कई कंपनियों की तरह इसे low priority के साथ backlog में डाल दिया गया, फिर कई Jira cleanup और org reshuffle के बाद, बाद में दोबारा सामने आने पर fix किया गया होगा
  • मैं Harvest security team से हूं. दूसरे comments में भी जवाब दिया है, पर मूल रूप से हम इसे reproduce नहीं कर पाए थे और कोई explicit fix भी नहीं था. हालांकि जो issue बंद हो जाना चाहिए था, वह मेरी मानवीय गलती से Triage status में पड़ा रह गया

• काश कोई OAuth expert इस समस्या को थोड़ा और विस्तार से समझाए. मैंने blog कई बार पढ़ा, लेकिन actual vulnerability अब भी पूरी तरह समझ नहीं आई
  OAuth के बारे में मेरी सीमित समझ के अनुसार, Harvest app Microsoft से user verification मांगता है, Microsoft user को verify करता है, और success होने पर callback URL पर redirect करते हुए response body में access token देता है — क्या यही flow नहीं है?
  इस हिसाब से, क्या blog author ने बस एक handcrafted URL बनाया, जो return URL को असली return URL की जगह example.com पर भेज देता है?

  • हां. Blog author ने ऐसा handcrafted URL बनाया था. लेकिन attack URL का callback URL harvestapp domain पर है, और attacker के नियंत्रण वाला हिस्सा OAuth server की नजर में लगभग opaque रहने वाले state के अंदर है
    उस URL का इस्तेमाल करके कोई भी किसी को login.microsoftonline.com link भेज सकता है, “Harvest में login करें” वाला prompt दिखा सकता है, और फिर attacker को असली Harvest account से जुड़े permissions मिल सकते हैं
    आम तौर पर यह संभव नहीं होता. Attacker example.com पर redirect होने वाला एक नया app register कर सकता है, लेकिन तब उसे Harvest से संबंधित permissions वाला access token नहीं मिलेगा, इसलिए उसका कोई उपयोग नहीं होगा
    Microsoft side के OAuth app में valid redirect allowlist होती है, इसलिए login.microsoftonline.com/authorize?client_id=$harvestAppID&redirect_uri=attacker.com जैसी कोशिश Microsoft side पर error देगी. हमला इसलिए संभव हुआ क्योंकि valid outlook-integration.harvestapp.com URL, access token मिलने के बाद attacker site पर दोबारा redirect कर देता था, और access token भी साथ भेज देता था
  • vulnerability outlook-integration.harvestapp.com में थी. OAuth2 callback सफल होने के बाद क्या करना है, इसका निर्देश देने वाले JSON object को state के रूप में इस्तेमाल किया गया था
    subdomain property का उपयोग browser को harvestapp.com के subdomain पर redirect करते हुए #id-token पहुंचाने के लिए किया जाता था. समस्या यह थी कि subdomain की value नीचे दिए गए URL में ज्यों-का-त्यों inject की जाती थी
    https://${subdomain}.harvestapp.com/...#id-token=...
    अगर JSON payload के subdomain को attacker-controlled.com/ जैसा slash के साथ खत्म होने वाला value बना दिया जाए, तो URL https://attacker-controlled.com/.harvestapp.com/...#id-token=.. बन जाता है, और browser दूसरे domain पर चला जाता है, जिससे token leak हो जाता है
  • Microsoft यह verify करता है कि return URL, Harvest द्वारा तय allowlist में है या नहीं. शायद Harvest ने software के कई instances support करने के लिए उसके ऊपर अपना redirect mechanism जोड़ा, लेकिन redirect input को ठीक से sanitize नहीं किया
    इसलिए यह OAuth की intrinsic problem नहीं, बल्कि खराब implementation थी
  • पक्का नहीं कह सकता, लेकिन मुझे लगता है समस्या यह थी कि Harvest ने सभी URLs को callback URL के रूप में allow कर दिया. Microsoft को यह बताना चाहिए कि callback के लिए सिर्फ specific URLs ही allow हों
    workflow सेट करते समय trusted callback URLs की असली list बनाने के बजाय, संभव है कि callback URL allowlist में wildcard इस्तेमाल किया गया हो. मैं पूरी तरह गलत भी हो सकता हूं

• समझ नहीं आता कि 3 साल तक इंतज़ार क्यों किया गया। सार्वजनिक खुलासे से पहले 90 दिन की मोहलत काफ़ी है

  • अगर बहुत बड़ा बदलाव चाहिए हो और काफ़ी बड़ी टीम अपने ज़्यादातर काम के समय को इस समस्या पर लगा रही हो, तो यह 90 दिनों से ज़्यादा भी हो सकता है। या समाधान मौजूद हो, लेकिन ग्राहक सूचना के कारण इसे किसी तय और अपेाकृत छोटे शेड्यूल के मुताबिक करना पड़े।
    लेकिन ऐसी अतिरिक्त मोहलत शोधकर्ता या उसके वकील/प्रतिनिधि की अनुमति से ही होनी चाहिए। आम मामलों से बड़े मुद्दे पर कंपनी अच्छे इरादे से ऐसा अनुरोध कर सकती है

• अगर HackerOne कंपनियों को ऐसी चीज़ें 3 साल तक लटकाने देता है, तो लगता है कि वह अपनी भूमिका ठीक से नहीं निभा रहा

  • HackerOne bug bounty program चलाने वाली कंपनियों पर निर्भर है। वह कितना दखल देता है, यह दी जाने वाली सेवा पर बहुत निर्भर करता है, जैसे triage handling करता है या नहीं।
    सबसे बुनियादी स्तर पर वह सिर्फ़ vulnerability disclosure platform और ऐसा standard legal wording देता है ताकि शोधकर्ताओं पर legal team मुकदमा न करे।
    ज़्यादातर मामलों में कंपनियाँ disclosure request ठुकरा देती हैं। अगर शोधकर्ता बिना अनुमति के खुलासा करे, तो वह HackerOne और कंपनी के साथ हुए समझौते का उल्लंघन करेगा और कानूनी ज़िम्मेदारी के जोखिम में आएगा। इस मामले में लगता है कि कंपनी ने खुलासे के लिए सहमति दी, और भले ही प्रतिक्रिया बहुत धीमी थी, उस बात का श्रेय दिया जा सकता है।
    व्यक्तिगत तौर पर, मेरे साथ भी कई बार ऐसा हुआ है कि चार अंकों के इनाम वाले bug एक साल से ज़्यादा समय तक ठीक नहीं किए गए, लेकिन मैंने इसे HackerOne की गलती नहीं माना
  • कंपनी की तरफ़ से HackerOne issue संभालने का अनुभव रहा है, और एक HackerOne participant बार-बार HackerOne के अपने नियम तोड़ता रहा। disclosure timeline का उल्लंघन, bug के बारे में झूठी social media posts, यहाँ तक कि कर्मचारियों को धमकाना भी हुआ।
    HackerOne ने परवाह नहीं की। कई बार बताने पर भी कि वह व्यक्ति उनके नियम तोड़ रहा है, उन्होंने कहा कि वे कुछ नहीं कर सकते।
    ऐसा लगा जैसे किसी ठीक-ठाक चल रही कंपनी को घटाकर बस न्यूनतम स्टाफ़ पर छोड़ दिया गया हो, जहाँ बिना अधिकार वाले support staff सवालों के जवाब दे रहे हों। यह काफ़ी पुरानी बात है, तो अब स्थिति बदली भी हो सकती है, लेकिन तब मेरी यही छाप थी
  • तीन पक्षों में, यानी HackerOne, कंपनी, और bug ढूँढने वाला शोधकर्ता, कंपनी के पास पूरा leverage है
    अगर HackerOne हद से आगे जाए और उसे लगे कि कंपनी तय कर रही है कि वह क्या करने की “इजाज़त” देगा, तो कंपनियाँ बस HackerOne छोड़कर अपना internal solution बना लेंगी
  • शायद company review की ज़रूरत है, ताकि ऐसे खराब हाल वाली कंपनियों से बचा जा सके जो मामलों को सालों तक घसीटती हैं और इनाम भी नहीं देतीं

• समझ नहीं आता कि यह issue Microsoft तक क्यों नहीं पहुँचाया गया। Microsoft इस OAuth application की access तब तक revoke कर सकता था जब तक समस्या ठीक न हो जाती।
  हालाँकि, लगता है Microsoft से OAuth के ज़रिए जुड़ी ऐसी ही खराब implementation हज़ारों होंगी

  • मुझे नहीं पता था कि ऐसा संभव है। व्यक्तिगत तौर पर, मेरे दिमाग में तो ऐसा ख़याल कभी नहीं आता