डेटिंग ऐप को हैक करने का अनुभव, और security researchers के साथ गलत व्यवहार

 (alexschapiro.com)
2 पॉइंट द्वारा GN⁺ 2025-05-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Cerca Dating App में phone number-आधारित login और exposed API के मेल से एक खतरनाक स्थिति बनी हुई थी, जहाँ OTP response में authentication code शामिल था और इससे व्यक्तिगत जानकारी तक पहुँचा जा सकता था
  • api.cercadating.com पर app version header जोड़ने पर /docs की openapi.json के जरिए endpoints सामने आ जाते थे, और कुछ requests से forced matching जैसी business logic तक बदली जा सकती थी
  • user/{user_id} valid user ID भर देने पर नाम, location, जन्मतिथि, school, phone number, email, profile status जैसी PII लौटाता था, जो OTP कमजोरी के साथ मिलकर account takeover तक ले जा सकता था
  • account access मिलने के बाद submitted users के लिए passport या ID जानकारी, selfie URL, और private messages तक पहुँचना संभव था; verification script से 6,117 users, 207 ID-info submitters, और 19 Yale student-marked users मिले
  • इस कमजोरी की सूचना 23 फ़रवरी 2025 को Cerca को दी गई और 24 फ़रवरी को कॉल भी हुई, लेकिन 21 अप्रैल को disclosure के समय तक न तो आगे कोई जवाब मिला और न ही users को notification; सिर्फ patch होने की बात स्वतंत्र रूप से verify की गई

रिपोर्ट के बाद रुकी हुई प्रतिक्रिया

  • Cerca Dating App में dating app security vulnerability थी, जिससे private messages, passport जानकारी, sexual preferences, और अन्य personal data उजागर हो सकते थे
  • कमजोरी मिलने के बाद 23 फ़रवरी 2025 को Cerca टीम को email से रिपोर्ट भेजी गई, और अगले दिन video call में vulnerability, mitigation, और follow-up steps पर चर्चा हुई
  • Cerca टीम ने समस्या की गंभीरता मानी, responsible disclosure के लिए धन्यवाद दिया, और vulnerability fix करने तथा प्रभावित users को सूचित करने का वादा किया
  • इसके बाद 5 मार्च और 13 मार्च को fix और user notification plan पर update माँगा गया, लेकिन 21 अप्रैल 2025 को public disclosure तक कोई जवाब नहीं मिला
  • disclosure से पहले vulnerability patch हो चुकी थी, यह बात स्वतंत्र रूप से verify की गई, और उसी आधार पर इसे public किया गया

OTP login से शुरू हुआ account access

  • app केवल phone number पर code भेजने वाला OTP-आधारित login इस्तेमाल करता था
  • network requests देखने के लिए iPhone app पर Charles Proxy का उपयोग करके app traffic intercept किया गया
  • OTP trigger करने वाले response में one-time password सीधे शामिल था
  • इस ढाँचे में किसी user का phone number पता हो तो उसके account तक पहुँचा जा सकता था
  • account holder का phone number पता करने के लिए अलग रास्ते की ज़रूरत थी, और इसी वजह से API endpoint exploration शुरू हुई

OpenAPI दस्तावेज़ से सामने आए endpoints

  • api.cercadating.com पर directory fuzzer से paths enumerate किए गए
  • app-संबंधित headers के बिना site के किसी भी हिस्से तक पहुँचना संभव नहीं था
  • Gobuster में वह header जोड़कर request भेजने पर /docs endpoint मिला, जहाँ openapi.json उपलब्ध था
  • Burp Suite के match-and-replace feature से app version header और Charles Proxy से निकाला गया bearer token हमेशा जोड़ने के लिए सेट किया गया
  • कुछ unprotected endpoints business logic को प्रभावित करते थे, और दो लोगों को force match कराने वाली request भी संभव थी

user profile और personal data exposure

  • user/{user_id} endpoint valid user ID मिलने पर कई तरह की personal information लौटाता था
  • response में यह जानकारी शामिल थी
    • नाम, gender, interested gender, city, latitude और longitude
    • school email और verification status, industry, job, जन्मतिथि, height
    • school ID और school name, profile completion status
    • nationality ID verification status, mobile और email verification status
    • premium status, account active·suspended·onboarding status
    • phone number, email, user ID, बचे हुए search count
    • profile image, matching preferences, user prompts, mutual contact information, creation·modification time, age आदि
  • Python script से valid user IDs ढूँढकर user data को बड़े पैमाने पर enumerate किया जा सकता था
  • लौटाए गए phone numbers, OTP कमजोरी के साथ जुड़कर पूरे account access के लिए इस्तेमाल हो सकते थे
  • OTP login के बिना भी user personal data exposed था

ID दस्तावेज़ और private messages तक पहुँचना

  • national_id_verified field से पता चलता था कि system में passport या identity document जानकारी store की जाती है
  • ID-संबंधित response में यह जानकारी शामिल थी
    • verification_type: PASSPORT
    • document_number
    • front_side_url
    • back_side_url
    • selfie_url
    • status, ID, user ID
  • यह जानकारी केवल logged-in user को दी जाती थी, लेकिन OTP कमजोरी के कारण किसी भी user के रूप में login करना संभव था
  • जिन users ने submit किया था, उनके लिए किसी का भी ID data देखा जा सकता था, लेकिन लेखक ने कहा कि उसने वास्तव में ऐसा नहीं किया
  • संभावित dating matches के साथ हुए private messages भी देखे जा सकते थे, और submit होने पर passport जानकारी तक पहुँचना भी संभव था

पुष्टि किया गया exposure का पैमाना

  • एक तेज script से यह गिना गया कि कितने users की जानकारी मिल सकती है, कितने users Yale student के रूप में दर्ज थे, और कितनों ने ID जानकारी जमा की थी
  • script valid user IDs गिनती रहती थी और अगर लगातार 1,000 IDs valid न मिलें तो रुक जाती थी
  • यह तरीका इस संभावना को ख़ारिज नहीं करता कि और भी users मौजूद हों
  • Cerca ने कहा था कि पहले हफ्ते में उसके users की संख्या 10,000 थी
  • पुष्टि किए गए आँकड़े इस प्रकार थे
    • 6,117 users
    • ID जानकारी जमा करने वाले 207 users
    • Yale student के रूप में चिह्नित 19 users

privacy promise और वास्तविक जोखिम

  • Cerca की privacy policy कहती है कि वह “encryption और अन्य industry-standard measures से data की रक्षा करती है”
  • वास्तविक vulnerability स्थिति से तुलना करने पर यह वाक्य भ्रामक हो सकता है
  • exposed data में sexual preferences, private messages, और कई तरह की personal information शामिल हो सकती थी
  • अगर कोई malicious user इस जानकारी तक पहुँचता, तो identity theft, stalking, और blackmail जैसी स्थितियाँ पैदा हो सकती थीं
  • dating apps संवेदनशील data संभालते हैं, इसलिए app launch speed से ज़्यादा user data security को प्राथमिकता मिलनी चाहिए

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

1 टिप्पणियां

 
GN⁺ 2025-05-13
Hacker News की राय

  • यह ऐप कॉलेज छात्रों द्वारा बनाया गया काफ़ी शुरुआती स्तर का प्रोजेक्ट लगता है। यह सही है कि उन्हें security और communication practices ठीक से निभाने की पूरी कोशिश करनी चाहिए, लेकिन ऐसे ही मुद्दों पर बड़े VC-funded “बड़े लोगों वाली कंपनियों” को भी गड़बड़ तरीके से respond करते देखते हुए मैं इन्हें बहुत बेरहमी से घेरना नहीं चाहूँगा
    https://georgetownvoice.com/2025/04/06/georgetown-students-c...

    • कड़ा असहमति। “उन्हें पता नहीं था कि वे क्या कर रहे हैं, इसलिए बहुत कठोरता से judge न करें” कहना अजीब है। अगर उन्हें पता नहीं था कि वे क्या कर रहे हैं और फिर भी launch तक चले गए, तो यह सज़ा कम करने वाली बात नहीं, बल्कि उल्टा और गंभीर बात लगती है
      यह वैसा है जैसे किसी driver ने accident में किसी को मार दिया और बाद में पता चला कि उसके पास license भी नहीं था
    • “Cerca” की जानकारी खोजते हुए मैंने भी वही link देखा, लेकिन वह April 2025 का लेख है और दो महीने पहले बने app की तारीफ़ करता है, इसलिए यह LLM hallucination जैसा कचरा लेख लगता है
      मूल पोस्ट में कहा गया है कि उन्होंने February में Cerca team से संपर्क किया था, तो या तो यह launch day पर मिला flaw था या कोई अजीब structure है। किसी भी तरह, यह “दो महीने पुरानी vulnerability” और “दो महीने पुराना छात्रों द्वारा बनाया गया app/service” है
    • अगर app Cerca Applications, LLC के नाम से release हुआ है, तो कोई कैसे जाने कि ये बस कुछ script kiddies हैं जिन्हें छोड़ देना चाहिए
    • इन लोगों के लिए शायद कोई दूसरा major पढ़ना बेहतर होगा
    • बात में दम है, लेकिन फिर भी यह बहुत ज़्यादा है। जो OTP secret होना चाहिए, उसे response body में वापस न भेजना तो experienced developer हो या high-school student, लगभग common sense है
      ऊपर से यह मज़े के लिए बनाई गई चीज़ नहीं, बल्कि commercial product है। In-app purchases में Cerca App $9.99, Cerca App 3 month $9.99, 10 Swipes $2.99, 3 Swipes $0.99, 5 swipes $1.99, 3 Searches $1.99, 10 Searches $3.99, 5 Searches $2.99 दिख रहे हैं

  • एक छोटी company के engineer के रूप में कभी-कभी मुझे अपनी personal liability की चिंता होती है। PCI या HIPAA लागू न होने वाले unregulated sectors में चलने वाली बहुत-सी companies हैं, और छोटे organizations में security को organization-level responsibility नहीं, बल्कि बस engineering concern मानकर किनारे कर दिया जाता है
    Product team features पर, PM schedule पर, QA bugs ढूँढने पर focus करती है, और security के बारे में reasonable आवाज़ उठाने वाले लोग कम होते हैं। Engineer से board पर आए tasks खत्म करने से ज़्यादा उम्मीद नहीं की जाती। अगर timeline पर असर डाले बिना सुरक्षित बनाया जा सके तो अच्छा, वरना PM वगैरह से pressure आता है
    “उसमें कितना time लगेगा?”, “असल में ऐसा होने का risk कितना है?”, “security बाद में कर लेंगे, पहले MVP customers को ship करते हैं” जैसी बातें सुननी पड़ती हैं। एक employee के तौर पर मैं employer के कहे काम कर रहा होता हूँ, लेकिन अगर hacking या data breach की वजह से company पर मुकदमा हो गया, तो क्या “मुझे पता होना चाहिए था” वाला अकेला व्यक्ति होने के कारण मुझे personally liable ठहरा दिया जाएगा?

    • सख्ती से कहें तो हम असली engineering engineers नहीं हैं। हम safety certify करने वाले design drawings पर sign नहीं करेंगे, और अगर कुछ unsafe साबित हुआ तो उसकी responsibility भी नहीं लेंगे
    • अगर LLC या corporation है, तो जब तक आपने criminal act किया है ऐसा कोई लिखित record नहीं छोड़ा, corporate veil से protection मिलने की संभावना काफ़ी है
      हालांकि organization के size से परे, पूरी organization में security standards की कमी शर्मनाक है। लगता है अच्छे security practices ensure करने से पहले हमेशा नए features launch करना प्राथमिकता बन जाता है
    • निजी तौर पर, मैं खुद को protect करने लायक law जानना चाहूँगा, illegal चीज़ों पर लिखित में oppose करना चाहूँगा, और ignore करने के निर्देश भी written approval में लेना चाहूँगा
      हालांकि समझता हूँ कि startup में अगर developers सिर्फ एक-दो ही हों तो यह भी मुश्किल है। अगर मुझे लगे कि वे legal काम pursue नहीं कर रहे हैं, तो शायद मैं छोड़ दूँगा
    • अगर आप छोटे organization के engineer हैं, तो मेरे हिसाब से बाकी team को ऐसे security risks के बारे में educate करना और उन्हें mitigate करने के लिए engineering time secure करने पर जोर देना आपकी responsibility है
      यह आसान नहीं है, लेकिन अगर इसे गंभीरता से न लिया जाए तो यह ऐसा महत्वपूर्ण मामला है जो business को ही डुबो सकता है
    • “मैं तो बस orders follow कर रहा था” वाले defense logic को मैं पसंद नहीं करता, लेकिन ऐसे मामलों में written record ज़रूर रखना चाहिए
      security की कमी पर concerns उठाने वाले emails का record और manager के “चिंता मत करो” कहने वाले जवाब का record चाहिए। पता नहीं किस jurisdiction की बात है, लेकिन मुझे ऐसा कोई case नहीं पता जहाँ एक आम employee को data breach के लिए legally liable ठहराया गया हो। आमतौर पर data breach में किसी को भी वास्तविक परिणाम नहीं भुगतने पड़ते, company बस औपचारिक fine भरकर आगे बढ़ जाती है

  • एक researcher के तौर पर legal exposure घटाने के लिए दूसरा account बनाना या किसी दोस्त से profile बनवाकर access consent लेना ही शायद काफ़ी होता
    enumeration vulnerability साबित करने के लिए सच में data scrape करने की ज़रूरत नहीं है। अगर मेरी ID 12345 है और दोस्त ने sign up करके 12357 पाया, तो यह साबित करने के लिए काफ़ी है कि किसी भी user की ID खोजकर profile access की जा सकती है
    जैसे दूसरों ने कहा, vulnerability verify और disclose करने के लिए दूसरे users की इतनी personally identifiable information access करने की ज़रूरत नहीं है

    • यही वह standard और obvious तरीका है जिसे ज़्यादातर security researchers ignore करते हैं
      personally identifiable information protected रहे, यह चाहना और फिर उसे scrape करके prove करना unnecessary और hypocritical है

  • लेख काफ़ी उलझा हुआ है। OTP-आधारित login में one-time password request के response में OTP जस का तस आ जाता है—यह हिस्सा ठीक से समझाया नहीं गया है, लेकिन शायद मतलब यह है कि यह api.cercadating.com/otp/ जैसी कोई API है, जहाँ अगर आप phone number का अंदाज़ा लगा लें तो उस नंबर के मालिक हुए बिना भी OTP code पा सकते हैं।
    फिर वे कहते हैं कि एक script, जो 1,000 लगातार IDs में valid user न मिलने पर रुक जाती है, उससे 6,117 लोग, ID जानकारी डालने वाले 207 लोग, और Yale student होने का दावा करने वाले 19 लोग मिले। मुझे नहीं पता लेखक को अंदाज़ा है या नहीं कि यह कितना जोखिम भरा है। असल में यह काफ़ी हद तक वैसा ही है जैसे weev ने AT&T में breach किया था, और वह जेल गया था[0]
    भले ही वह बड़ी company और बड़ा leak था, मैं शायद public में यह brag नहीं करता कि security hole का इस्तेमाल करके मैंने हज़ारों लोगों के data को unauthorized तरीके से access किया। मैं नैतिकता पर फैसला नहीं सुना रहा; मेरा मानना है कि security researchers को चेतावनी देने की गुंजाइश होनी चाहिए, लेकिन कानून security researchers के लिए काफ़ी प्रतिकूल है।
    [0] https://en.wikipedia.org/wiki/Goatse_Security#AT&T/iPad_emai...

    • Phone number guessing का ज़िक्र किया गया था, और OTP भेजने वाली API call सचमुच OTP return करती है ऐसा लिखा है।
    • Auernheimer case की original complaint पढ़ें तो prosecutors के पास वहाँ काफ़ी व्यापक intent के evidence थे, जो यहाँ शायद मौजूद नहीं होंगे।
      उस मामले के defendants पर basic personally identifiable information publish करने का आरोप भी था, जबकि यहाँ ऐसा हुआ हो, ऐसा नहीं दिखता।

  • एक दूसरे dating app में मेरे साथ भी कुछ ऐसा ही हुआ था, लेकिन वहाँ से आखिर तक कोई जवाब नहीं आया। Founder का ध्यान खींचने के लिए मैंने उसका profile text “contact me” जैसे वाक्य में बदल दिया, तो उन्होंने backup restore कर दिया।
    कुछ साल बाद Instagram ad देखकर मैंने check किया कि issue अब भी है या नहीं, और वह अब भी था। Structure ऐसा था कि app-proxy-server से आसानी से मिलने वाले API endpoint का पता हो तो कोई भी full admin privileges पा सकता था और सभी messages, matches आदि तक access कर सकता था।
    सोच रहा हूँ कि वापस जाकर एक बार फिर कोशिश करूँ या नहीं।

    • Responsible developer की तरह contact address पर बस vulnerability disclosure करके आगे बढ़ जाना ही ठीक नहीं होगा?

  • Passport या address जैसी sensitive information लेने से पहले लोगों को दो बार सोचने पर मजबूर करना चाहिए। ऐसी चीज़ को बस बच्चों ने app बना दिया कहकर टाला नहीं जा सकता।

    • Passport या दूसरी ID information input के बाद public में expose करने की कोई वजह नहीं है। UI में दिखाने के लिए API से data लाना भी पड़े, तो full passport/ID number शामिल करने की ज़रूरत नहीं; कम-से-कम सिर्फ़ आख़िरी कुछ digits भेजने के लिए mask किया जा सकता है।
      Dating site हो तो API के लिए ID status पर verified/not-verified boolean या ‘not-verified’, ‘passport’, ‘drivers-license’ जैसे enum values return करना ही काफ़ी है। Client/UI में detailed information दिखाने की कोई वास्तविक ज़रूरत नहीं।
      Airline app जैसे cases, जहाँ immigration purposes के लिए identity document चुनना पड़ता है, exception के तौर पर ज़्यादा जानकारी दिखा सकते हैं, लेकिन United app की तरह passport number के सिर्फ़ आख़िरी कुछ digits दिखाना काफ़ी है। Internal API से भी बस उतना ही भेजा जाए, यही उम्मीद है।
    • UK government porn sites access के लिए ID verification mandatory करने पर बहुत जोर लगा रही है; जिस दिन यह उनके ही मुँह पर फटेगा, उसका इंतज़ार है।
    • Government द्वारा चलने वाली कोई secure और private identity verification service होनी चाहिए।
      या फिर Apple या Google जैसी “government जैसी” जगहें भी इसे संभाल सकती हैं।
    • GDPR को देख लें।
      https://en.wikipedia.org/wiki/General_Data_Protection_Regula...
    • क्या उन्होंने third-party identity verification service इस्तेमाल नहीं की थी? आम तौर पर apps ऐसे ही handle करते हैं। कहीं ऐसा तो नहीं कि ऐसी third-party services असली images जैसी raw ID documents सीधे app को दे देती हों?

  • Request API response में OTP return करना समझ से बाहर है। ऐसा क्यों किया होगा?

    • शायद UI से यह verify करवाना चाहते थे कि user ने जो value enter की है वह सही है।
      Security के बारे में न सोचें तो यह बहुत plausible और obvious solution है। Dating apps में अनिवार्य रूप से बहुत personally identifiable information होती है, इसलिए ये बनाने के लिए सबसे risky तरह के apps में से हैं, और यह तो भयावह है।
    • हो सकता है OTP generate और store करने के बाद database या cache आदि का response जस का तस return कर दिया गया हो।
      Quick proof-of-concept या MVP में time बचाने के लिए stored model को API response के रूप में सीधे इस्तेमाल करना आम है, इसलिए यह आसानी से छूट सकता है।
    • Database cost खत्म करने का एक आसान secret trick है।
    • एक HTTP request कम हो जाती है और user experience भी तेज़ हो जाता है। नापसंद करने की क्या वजह हो सकती है?
      जब Pinterest की नई API आई थी, तो OAuth integration इस्तेमाल करने वाले सभी apps को वह पूरी user information बाँट रही थी, और उसमें two-factor authentication secret भी शामिल था। मैंने report करके bounty ली, लेकिन ऐसी हरकतें उन बड़ी-company APIs में भी होती हैं जिन्हें इससे बेहतर पता होना चाहिए।
    • लगता है OTP “one-time password trigger करने वाले response” में भेजा गया था।
      यह framework की वजह से हो सकता है। शायद database में डाले जाने वाले object को ORM या किसी और storage system से सीधे serialize करके HTTP response में लौटा देने वाला structure रहा होगा।

  • https://yaledailynews.com/blog/2025/04/24/yale-student-expos...
    इस मामले पर एक और article है।

    • “Developers को best practices इस्तेमाल करनी चाहिए, लेकिन शायद वह पर्याप्त न हो। Data को सुरक्षित रखना एक unsolved problem है”—अच्छा, ठीक है। फिर तो कुछ नहीं किया जा सकता।

  • काश कोई ऐसा कानून हो जो personally identifiable information store करने को nuclear waste storage जितना जोखिम भरा बना दे। Leak हो तो company लगभग निश्चित रूप से bankrupt हो, और responsible लोगों को legal risk झेलना पड़े।
    Incentives को सही तरीके से align करने का सबसे अच्छा तरीका मुझे यही लगता है। अभी users की information जितनी ज़्यादा हो सके store करने का downside लगभग नहीं है। Data breach? एक apology tweet डालो और आगे बढ़ो।

    • Personally identifiable information को nuclear waste जैसा treat करना थोड़ा extreme लगता है। Personally identifiable information में authentication और contact purposes के लिए email address जैसा अपेक्षाकृत harmless data भी शामिल होता है।
    • शायद white-collar prison की ज़रूरत है।
      तभी शायद इस issue को उतना ध्यान मिलेगा जितना इसे मिलना चाहिए।

  • अगर “कोई जवाब नहीं मिला” है, तो यह बताने का समय है कि अगर चुप्पी जारी रही तो 90 दिनों बाद vulnerability सार्वजनिक कर दी जाएगी

    • यह कंपनी से ज़्यादा निर्दोष users के लिए बड़ी सज़ा बन जाएगा
    • यहाँ तो इसे vulnerability कहने लायक भी कुछ नहीं है। यह बस खुलेआम खुली हुई स्थिति है
    • ऐसा करने पर lawsuit झेलने और criminal complaint तक होने का अच्छा-खासा रास्ता बन जाएगा