इंश्योरेंस प्रीमियम कैलकुलेटर का दुरुपयोग कर बीमा कंपनी हैक करने की घटना

 (eaton-works.com)
1 पॉइंट द्वारा GN⁺ 2024-01-18 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Eicher Motors के इंश्योरेंस प्रीमियम कैलकुलेटर subdomain पर Microsoft enterprise cloud credentials उजागर हो गए, जिससे TTIBI के noreply email account में login संभव था
  • समस्या वाले email भेजने वाले API ने authentication के बिना mail भेजे, और server error response के delivery logs ने base64-encoded password उजागर कर दिया
  • उजागर account में ग्राहकों को भेजे गए 657,000 emails और करीब 25GB के insurance policy PDFs, customer information, password reset links और OTP मौजूद थे
  • account पर two-factor authentication नहीं था, और Microsoft enterprise directory, SharePoint, Teams जैसे अन्य cloud resources तक भी access संभव था
  • रिपोर्ट के 2 महीने से अधिक बाद vulnerable API को authentication मांगने के लिए ठीक किया गया, और 27 जनवरी 2024 तक email account का password भी बदल दिया गया, इसलिए अब login संभव नहीं है

Eicher इंश्योरेंस प्रीमियम कैलकुलेटर से शुरू हुआ TTIBI breach

  • Eicher Motors systems की जांच के दौरान Toyota Tsusho Insurance Broker India, यानी TTIBI, का noreplyeicher@ttibi.co.in Microsoft email account उजागर हुआ
  • TTIBI, जापान की Toyota Tsusho Insurance Management Corporation के तहत एक भारतीय insurance broker है, जिसकी स्थापना 2008 में हुई थी
  • Eicher Motors भारत की automobile manufacturer है और Royal Enfield Motors की motorcycles तथा Volvo Group के साथ joint venture VE Commercial Vehicles के commercial vehicles बनाती है
  • दोनों कंपनियों के बीच insurance-related partnership थी, और TTIBI site पर Eicher के लिए dedicated subdomain मौजूद था

vulnerability मिलने का रास्ता

  • MY EICHER Android app का analysis करते समय API interface Java class में insurance premium calculator URL मिला
  • insurance premium calculator website के source code में client-side email sending mechanism शामिल था
  • code में Bearer Authorization के उपयोग के संकेत थे, जिससे authentication जरूरी लगता था, लेकिन जब सीधे API request बनाई गई तो 401 Unauthorized के बजाय email वास्तव में भेज दिया गया
  • server error response ने email delivery log भी साथ में लौटाया, और उसमें base64-encoded password शामिल था

noreply account में बचा हुआ data

  • noreplyeicher@ttibi.co.in automated mail भेजने के लिए noreply account था, लेकिन TTIBI में यह एक ऐसा account था जिसमें वास्तव में login किया जा सकता था
  • उस account में ग्राहकों को भेजे गए सभी emails का record मौजूद था
    • कुल 657,000 emails
    • करीब 25GB data
    • customer information
    • insurance policy PDFs
    • password reset links
    • OTP
  • OTP और password reset links तक देखे जा सकते थे, इसलिए इसमें ऐसी जानकारी शामिल थी जिसका दुरुपयोग कर customer insurance accounts पर कब्जा किया जा सकता था
  • उसी account से Microsoft cloud resources तक भी access संभव था
    • enterprise directory
    • SharePoint
    • Teams

vulnerability को बड़ा बनाने वाली security failures

  • client-side email sending feature

    • ऐसा email sending feature जिसमें client subject, body और recipients को control कर सके, malicious mails भेजने के लिए दुरुपयोग किया जा सकता है
    • चूंकि mail वास्तविक account से भेजे जाते हैं, इससे email reputation को नुकसान और phishing हो सकती है

  • API authentication missing

    • frontend में authentication token इस्तेमाल होने के संकेत थे, लेकिन server वास्तव में token check नहीं कर रहा था
    • अगर server ने token verify किया होता, तो संभव है यह attack रोका जा सकता था

  • बहुत ज्यादा जानकारी लौटाने वाला API error response

    • API processing के दौरान error आने पर client को बहुत अधिक जानकारी लौटाई गई
    • इस मामले में error response ने सीधे password expose कर दिया

  • two-factor authentication का अभाव

    • Microsoft account login के समय two-factor authentication या कोई अन्य login verification prompt नहीं था
    • अगर two-factor authentication होता, तो successful login मुश्किल हो सकता था

  • email retention

    • account द्वारा भेजे और प्राप्त किए गए सभी emails सुरक्षित रखे गए थे, जिससे बड़ी मात्रा में customer information तक आसानी से access मिल गया
    • अगर retention policy होती, तो customer data exposure का impact कम किया जा सकता था

response और current status

  • 17 जनवरी 2024 के समय, TTIBI को vulnerability का पता चले 5 महीने से अधिक हो चुके थे, लेकिन email account का password बदला नहीं गया था
  • 27 जनवरी 2024 के update के अनुसार email account password बदल दिया गया है, इसलिए अब उस account में login नहीं किया जा सकता
  • vulnerable API को अंततः authentication require करने के लिए ठीक कर दिया गया
  • यह confirm नहीं हुआ कि abnormal Microsoft login alerts आए थे या नहीं, और अगर alerts आए थे तो संभव है उन्हें ignore किया गया हो या check न किया गया हो

reporting timeline

  • TTIBI Toyota के HackerOne vulnerability disclosure program के scope में नहीं था, इसलिए India CERT-In को report किया गया
  • 7 अगस्त 2023: CERT-In को vulnerability की detailed report भेजी गई
  • 8 अगस्त 2023: CERT-In ने case ID जारी किया और जवाब दिया कि वह TTIBI से contact करेगा
  • 1 सितंबर 2023: progress update मांगा गया
  • 6 सितंबर 2023: CERT-In ने जवाब दिया कि उसने TTIBI को vulnerability forward कर दी है और आगे के updates share करेगा
  • 8 अक्टूबर 2023: impacted website down हो गई थी, लेकिन vulnerable API अभी भी मौजूद था, इसलिए CERT-In को सूचित किया गया
  • 11 अक्टूबर 2023: CERT-In ने जवाब दिया कि TTIBI ने vulnerability fix कर दी है, लेकिन verify करने पर vulnerability अभी भी मौजूद थी
  • 18 अक्टूबर 2023: email sending API को authentication require करने के लिए बदला गया और vulnerability fix हो गई
  • इसके बाद bug bounty reward की स्थिति पूछने को लेकर बातचीत जारी रही, लेकिन TTIBI ने जवाब नहीं दिया, और 22 दिसंबर 2023 को case close कर दिया गया

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

1 टिप्पणियां

 
GN⁺ 2024-01-18
Hacker News की राय

  • मैं भारतीय नहीं हूं, लेकिन Tata जैसी बड़ी IT कंपनियों में काम करने के नाते यह बहुत वास्तविक लगता है
    यहां सस्ते में काम निपटाने पर इनाम देने वाली मैनेजमेंट संस्कृति, और डेवलपर की पहल या आत्म-संतुष्टि को दबाने वाली संस्कृति बड़ा असर डालती है
    अगर मैंने अमेरिका में ऐसा देखा होता तो तुरंत नौकरी छोड़ देता, लेकिन इनके पास नौकरी छोड़ने पर 90 दिन की सैलरी वापस लेने का नियम है, इसलिए असल में कोई विकल्प नहीं रहता
    ज्यादातर मैनेजर non-technical background से होते हैं, इसलिए वही सुनना चाहते हैं जो उन्हें अच्छा लगे, और गलत बात सुनना पसंद नहीं करते
    यह मानना भी गलत हो सकता है कि नतीजा उसी टीम या उसी कंपनी ने बनाया है, क्योंकि डेवलपर्स को बहुत ज्यादा silo में बांट दिया जाता है—API developer, Office 365 developer, frontend developer जैसे छोटे-छोटे हिस्सों में—और जिस क्षेत्र में वे खुद “certified” नहीं हैं उसे छूते नहीं
    100 मिलियन डॉलर के प्रोजेक्ट की मीटिंग में भी SendGrid के खर्च पर गंभीर बहस होती है, और आखिर में कोई डेवलपर सिर्फ इसलिए कह देता है कि यह Office 365 से किया जा सकता है क्योंकि उसके पास “SendGrid experience” नहीं है
    Security team का बजट सबसे पहले काटा जाता है क्योंकि “यह तो पहले से सुरक्षित होना चाहिए”, और सुरक्षा के लिए भर्ती किए गए किसी भतीजे-टाइप व्यक्ति से बात करें तो रवैया यह होता है कि सरकार या कोई और मुकदमा तो करेगा नहीं, फिर परेशान क्यों होना
    डेवलपर्स को develop करने के लिए प्रोत्साहित नहीं किया जाता, बल्कि tickets निपटाना और सवाल न पूछना सिखाया जाता है
    मैं भारत के स्मार्ट डेवलपर्स के साथ काम करता हूं, लेकिन यह innovation culture नहीं है; यह काम को call center जैसा treat करना है। script से बाहर मत जाओ, संकरे problem domain में रहो, और जब तक fail नहीं कर रहे हो तब तक मानो जीत रहे हो

    • 90 दिन की सैलरी वापस लेने जैसी चीजें union और labour rights न होने का नतीजा हैं
      यह हमारे यहां भी जल्द आ सकता है

  • 2000 के दशक के मध्य-उत्तरार्ध में जिस Honda से जुड़े car dealer से मेरा पाला पड़ा था, वह finance applications को बढ़ते हुए numeric ID से store कर रहा था
    मैंने report नहीं किया, लेकिन SSN, जन्मतिथि, नाम, पता जैसी New Jersey के residents की कई sensitive जानकारी देखी जा सकती थी
    उस समय bug bounty लगभग नहीं थे और CFAA मौजूद था, इसलिए मैंने report नहीं किया
    मैंने अपनी application delete करवा दी, लेकिन vulnerability नए system पर जाने तक कई साल बनी रही, और नया system भी vulnerable लगता था
    उसके बाद मैंने उस dealer से कारोबार नहीं किया, और आज भी car dealers और finance applications को लेकर बहुत सावधान रहता हूं। थोड़ा महंगा हो तो भी आम तौर पर कहीं और से finance लेता हूं

    • लेखक ने भी जून 2023 में यह vulnerability फिर से खोजी थी
      https://eaton-works.com/2023/06/06/honda-ecommerce-hack/
    • identity information के trusted broker के रूप में एक बड़ा gap है
      https://cerebrum.com पर एक अलग क्षेत्र, यानी identity lookup पर काम कर रहा हूं, और यह comment देखकर कई ideas आए

  • सुरक्षा की गलती अपने-आप में भयानक है, लेकिन इसे कुछ हद तक इस तरह समझाया जा सकता है कि किसी अनुभवहीन developer को उसकी समझ से बहुत आगे का काम दे दिया गया
    लेकिन आखिर confidential customer documents को email account में store करने की मंजूरी कैसे मिली, यह समझ नहीं आता
    इसका मतलब है कि इस business को चलाने का तरीका जानने वाला कोई responsible व्यक्ति नहीं है, और अगर यह subsidiary या outsourcing partner है तो इसका मतलब यह भी है कि किसी ने audit नहीं किया
    company owner और यह काम सौंपने वाली party, दोनों की ओर से यह criminal negligence के करीब की हरकत है

    • इस स्तर की क्षमता में लगता नहीं कि किसी ने approve भी किया होगा
      शायद mail server में sent mail save करने का feature था, और “noreply” address के लिए real account इस्तेमाल करने के मूर्खतापूर्ण फैसले का यह byproduct बना होगा
    • मैंने एक काफी बड़े real estate brokerage system में देखा था कि सभी outgoing emails को shared account में BCC किया जाता था और सब लोग उसे Outlook में sync करते थे
      यह audit log, debugging tool और database backup—तीनों का काम कर रहा था
      जब उन्हें पता चला कि employees सभी customer information अपनी नई jobs में ले जा रहे हैं, तभी इसे बदला गया

  • अगर “5 महीने से ज्यादा हो गए और TTIBI ने vulnerability जानने के बाद भी email account का password नहीं बदला”, तो उम्मीद है कि कम से कम error logs से Base64 password निकाल दिया होगा
    जाहिर है किया होगा। है ना?

  • असर सचमुच SharePoint और Outlook के full access स्तर जितना बड़ा है, लेकिन रास्ता सिर्फ client-side JavaScript देखने जैसा है, इसलिए यह काफी अजीब vulnerability है
    एक छोटी बात यह है कि screenshots में sensitive information को blur करने से बेहतर काले blocks से ढकना लगता है। सावधानी में कोई नुकसान नहीं

    • आजकल blur feature शायद असल text को blur नहीं करता, बल्कि बस उसे धुंधला दिखाने वाला processing करता है

  • “certificate of appreciation” पर खत्म होने वाली व्यवस्था की वजह से ऐसी vulnerabilities का ज्यादातर हिस्सा whitehats द्वारा report और disclose नहीं होता, बल्कि hackers द्वारा सक्रिय रूप से exploit किया जाता है
    customer personal information से जुड़े मामले में एक निश्चित स्तर से ऊपर की security mismanagement के लिए companies को जिम्मेदार ठहराने वाला legal framework होना चाहिए

    • Europe में ऐसी चीज पहले से है, और उसका नाम GDPR है

  • भारत में data leaks से भी बड़ी समस्याएं हैं
    उनमें से एक reliable power supply है
    मैं उस दिन का इंतजार कर रहा हूं जब भारत में पर्याप्त बिजली होगी और hacking मुख्य चिंता बनेगी
    हर महीने 100,000 km fiber optic बिछाई जा रही है, और हर दिन 350 5G base stations लगाए जा रहे हैं

  • यह भी देखना चाहिए कि monitoring email endpoint असल में communication worker/agent/runner की तरह design हुआ था और छोड़ दिए जाने के बाद लगातार फूला-फला
    इसका मतलब है कि email usage monitor नहीं हो रहा था, और “इस email alias की storage cost बाकी चीजों से कई गुना ज्यादा क्यों है?” जैसे abnormal behavior पकड़ने के लिए कोई supplementary control भी नहीं था
    मुख्य बात यह है कि “noreply account में ग्राहकों को भेजे गए सभी records संभावित रूप से हो सकते हैं, इसलिए यह organization का सबसे महत्वपूर्ण account हो सकता है”

  • अगर “भारत भर का leading insurance broker” सक्षम developers रखने के लिए पैसे नहीं दे सकता, तो कम से कम उस व्यक्ति को कुछ रकम देनी चाहिए जिसने customers को risk में डालने वाली कई गंभीर समस्याएं खोजीं और जिम्मेदारी से बताईं
    लेकिन उन्होंने ऐसा नहीं किया, और यह यकीन करना मुश्किल है कि compromised email account password भी अभी तक reset नहीं किया गया
    जो company इस तरह behave करती है, उस पर कैसे भरोसा किया जाए कि वह कुछ भी ठीक से करेगी
    Toyota Tsusho Insurance Broker India ऐसी company लगती है जिससे महामारी की तरह बचना चाहिए

    • मैंने similar level की incompetence खुद देखी है
      यह ऐसा नहीं है कि कोई important security warning को जानबूझकर ignore कर रहा है; वे समझ ही नहीं पा रहे कि आप क्या कह रहे हैं
      वे जिस environment को operate कर रहे हैं या जिस task से जूझ रहे हैं, उसे मूल रूप से नहीं समझते, और आपके technical terms का उनके या उनकी team के लिए कोई अर्थ नहीं है, इसलिए वे बस चाहते हैं कि आप चले जाएं
      रवैया कुछ ऐसा है: “confusing emails भेजना बंद करें। हमारे पास important काम है”
      इसे ठीक करने के लिए organization level पर top leadership replacement चाहिए, और IT head तथा उसने जिन भी चीजों को छुआ है, सबको बाहर जाना होगा
    • बहुत संभव है कि alternatives लगभग न हों, और शुरुआत में यही बात ऐसे issues पैदा करती हो

  • समस्या का एक हिस्सा यह है कि इस inbox को असल में “free” SMTP account की तरह इस्तेमाल किया गया ताकि outgoing email costs न देनी पड़ें
    अगर SES जैसी चीज इस्तेमाल की होती तो इस account के sent items/inbox में इतनी sensitive information नहीं होती
    SES 1,000 emails पर $0.10 में बहुत सस्ता है

    • तकनीकी रूप से सही है, लेकिन यहां SES इस्तेमाल करने की असली cost शायद development time होगी
      भेजे गए सभी emails को store करना, और non-developer operations staff के लिए past messages देखने और search करने का interface बनाना पड़ेगा
      अगर इस “free” SMTP approach की सारी functionality इस्तेमाल हो रही थी, तो development और maintenance cost काफी ज्यादा है