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

 (alexschapiro.com)
2 पॉइंट द्वारा GN⁺ 2025-05-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Cerca नाम के डेटिंग ऐप में एक गंभीर security vulnerability पाई गई
  • OTP response में दिखाई दे रहा था, इसलिए सिर्फ फोन नंबर जानकर कोई भी account access कर सकता था
  • authentication के बिना खुले कई API endpoints से personal data आसानी से लीक हो सकता था
  • यूज़र्स की sexual preference, messenger content, ID documents जैसे sensitive data बड़ी मात्रा में उजागर हुए
  • service provider ने researcher की responsible disclosure के बावजूद उचित response और notification नहीं दिया

security को गंभीरता से लेने वाली startups का महत्व

  • हाल के समय में startups market में जल्दी launch करने की दौड़ में security की अनदेखी कर रही हैं
  • डेटिंग ऐप होने के कारण यहां personal data बहुत केंद्रित था, फिर भी development और operations की अपरिपक्वता ने users को जोखिम में डाल दिया

vulnerability की खोज और सूचना देने की प्रक्रिया

  • 23 फ़रवरी 2025 को Cerca को email के जरिए security vulnerability और संबंधित समस्याओं के बारे में बताया गया
  • 24 फ़रवरी को video meeting के माध्यम से detailed vulnerability, mitigation steps और आगे की प्रक्रिया पर चर्चा हुई
  • Cerca team ने मामले की गंभीरता समझने, तेज़ी से कार्रवाई करने और users को सूचित करने का आश्वासन दिया
  • इसके बाद कई बार progress update पूछा गया, लेकिन 21 अप्रैल तक न तो जवाब मिला और न ही कोई public notice
  • स्वतंत्र रूप से जांच करने पर पता चला कि यह vulnerability patch की जा चुकी है

OTP vulnerability और आसान hacking process

  • app login प्रक्रिया में one-time password (OTP) network response में सीधे दिखाई दे रहा था
  • हमलावर सिर्फ फोन नंबर जानकर किसी भी account तक तेज़ और आसान पहुंच बना सकता था

API endpoint access और data leak

  • यह पुष्टि हुई कि सिर्फ app version header डालकर सभी API paths तक पहुंचा जा सकता था
  • /docs endpoint के जरिए पूरा OpenAPI documentation उजागर हो रहा था
  • Burp Suite जैसे tools से app headers और tokens की automatic injection करके API को नियंत्रित किया जा सकता था
  • कुछ endpoints सिर्फ business logic बदलते थे, लेकिन मुख्य endpoints गंभीर स्तर का personal data वापस कर रहे थे
  • user/{user_id} जैसे endpoints से personal data, phone number, यहां तक कि account takeover भी संभव था

बड़े पैमाने पर personal data और ID information का exposure

  • personal data endpoints के जरिए gender, city, birthday, school email, ID information जैसे PII बड़े पैमाने पर उजागर हो रहे थे
  • खास तौर पर national_id_verified जैसे ID-related fields से passport और national ID card images जैसी sensitive files तक पहुंच संभव थी
  • attack script के जरिए 6,117 users की पहचान हुई, जिनमें 207 users ने ID information भी जमा कर रखी थी
  • इनमें कुछ accounts ऐसे भी थे जो खुद को Yale University से जुड़ा बताते थे
  • Cerca के official Instagram के अनुसार यह पहले हफ्ते के 10,000 users के स्तर का exposure था

वास्तविक नुकसान का जोखिम और समस्या की गंभीरता

  • sexual preference, chat content, ID documents जैसे बेहद sensitive data के leak से stalking, identity theft और blackmail जैसे गंभीर खतरे पैदा हो सकते थे
  • Cerca ने 'encryption सहित industry standards का पालन करने' की बात कही थी, लेकिन वास्तविक operations इससे मेल नहीं खाते थे
  • users खुद इसकी जांच नहीं कर सकते, इसलिए app providers द्वारा सक्रिय और जिम्मेदार security management अनिवार्य है
  • वास्तव में यह भी संभव है कि अज्ञात लोगों ने पहले ही बड़े पैमाने पर personal data चुरा लिया हो

निष्कर्ष और जिम्मेदार security culture की ज़रूरत

  • ऐसा app operation जिसे कोई भी आसानी से hack कर सके, एक गंभीर सामाजिक समस्या है
  • अगर user data protection को सर्वोच्च प्राथमिकता नहीं दी गई, तो real-time में नुकसान हो सकता है
  • security researcher की रिपोर्ट पर सक्रिय प्रतिक्रिया और users को पर्याप्त जानकारी न देने वाला Cerca का मामला एक चेतावनी है
  • अधिक सुरक्षित internet environment बनाने के लिए सभी developers के लिए मजबूत security framework स्थापित करना सर्वोच्च प्राथमिकता होनी चाहिए

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

1 टिप्पणियां

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

  • यह मान लेने पर भी कि यह ऐप कॉलेज के छात्रों ने काफी शुरुआती स्तर पर बनाया था, मेरा मानना है कि सुरक्षा और कम्युनिकेशन में पूरी कोशिश करनी चाहिए। लेकिन जब बड़े VC फंडिंग वाले वयस्क-चालित स्टार्टअप भी ऐसी समस्याओं में फंसकर इसी तरह व्यवहार करते हैं, तो मुझे लगता है कि students पर बहुत ज्यादा कठोर होने की ज़रूरत नहीं है। लेख का लिंक साझा कर रहा हूँ

    • मैं इससे बिल्कुल सहमत नहीं हूँ। "हमें पता नहीं था" कोई माफ़ी नहीं हो सकती। बिना जाने इसे आगे बढ़ाना ही और बड़ा मुद्दा है। यह वैसा है जैसे कोई अनाड़ी ड्राइवर बिना लाइसेंस दुर्घटना कर किसी को घायल कर दे
    • मैं भी Cerca के बारे में जानकारी ढूंढते हुए स्रोत लिंक पर गया, और वह अप्रैल 2025 का लेख था जिसमें लगभग दो महीने पहले बने ऐप की तारीफ की गई थी। यह LLM की hallucination से बना कचरा जैसा लगता है। OP ने कहा था कि उसने फरवरी में Cerca टीम से संपर्क किया था, तो या तो यह लॉन्च होते ही मिली vulnerability थी, या फिर कुछ अजीब स्थिति है। फिर भी, यह "दो महीने पुरानी vulnerability" + "दो महीने पुरानी students द्वारा बनाई गई service" है
    • अगर ऐप "Cerca Applications, LLC" नाम से रिलीज़ होता है, तो लोगों को कैसे पता चले कि यह छात्रों का बनाया ऐप है इसलिए इसे थोड़ा नरमी से देखा जाए
    • मुझे लगता है इन छात्रों को कुछ और पढ़ना चाहिए
    • यह उनकी तरफ़दारी जैसा लगता है। सिर्फ इसलिए कि कोई ऐप कॉलेज छात्रों ने बनाया है, उसे यूँ ही छोड़ नहीं देना चाहिए। The Facebook भी शुरुआत में कॉलेज छात्रों ने ही शुरू किया था। Meta के लंबे समय से चल रहे privacy abuse और data security की अनदेखी का इतिहास पुराना है। इसलिए मेरा मानना है कि ऐसे व्यवहार को किसी भी तरह सही नहीं ठहराया जा सकता, और समाधान तभी होगा जब संस्थापकों की उम्र या अनुभव से परे उचित regulation और fines लगाए जाएँ
    • अगर आप passport और sexual orientation जैसे sensitive data संभाल रहे हैं, तो कम से कम डेटा लीक होने की सूचना मिलने पर जवाब देना चाहिए। यह पूरी तरह तबाही है, और यहाँ सुरक्षा की कमी बिल्कुल भी स्वीकार्य स्तर की नहीं है
    • अगर आपको app security के बारे में कुछ भी नहीं पता, तो शायद आपको ऐप बनाना ही नहीं चाहिए। यह थोड़ा भावनात्मक लग सकता है, लेकिन जब मैं दोस्तों को dating app इस्तेमाल करते देखता हूँ तो उनकी जानकारी का उजागर होना बहुत डरावना लगता है। बनाने वालों को शर्म आनी चाहिए। और security researcher के संपर्क का जवाब न देने पर भी शर्म आनी चाहिए। अगर मेरे साथ ऐसा अनदेखा व्यवहार हुआ होता, तो मैं इससे कहीं ज्यादा सीधा expose लिखता। कृपया ऐप बनाना बंद करें

  • एक डेवलपर के रूप में छोटी कंपनी में काम करते हुए मैं अक्सर अपनी व्यक्तिगत ज़िम्मेदारी को लेकर चिंतित रहता हूँ। बहुत-सी कंपनियाँ ऐसे क्षेत्रों में काम करती हैं जहाँ PCI या HIPAA जैसी regulations लागू नहीं होतीं। छोटे संगठनों में security को पूरे organization की जिम्मेदारी नहीं, बल्कि engineering task समझा जाता है। product team सिर्फ features पर, PM सिर्फ timeline पर, और QA सिर्फ bugs पर ध्यान देता है, और security की बात उठाने वाला बहुत कम होता है। इंजीनियरों में माहौल यह रहता है कि जो काम दिया गया है बस वही करो। अगर engineer security पर भी ध्यान दे तो अच्छा है, नहीं तो PM वगैरह से उल्टा सुनना पड़ता है। और हमेशा ऐसी बातें सुनने को मिलती हैं: "यह करने में कितना समय लगेगा?", "वास्तव में इसकी संभावना कितनी है?", "पहले MVP जल्दी ship करते हैं, बाद में सुधार लेंगे" वगैरह। इसलिए कर्मचारी के तौर पर मैं वही करने लगता हूँ जो कंपनी कहती है। लेकिन जब hack या breach के बाद कंपनी पर मुकदमा होता है, तो मैं अक्सर सोचता हूँ कि क्या सिर्फ इसलिए कि मैं वह engineer था जिसे "और बेहतर पता होना चाहिए था", मुझे जिम्मेदार ठहराया जाएगा

    • व्यावहारिक रूप से, जब तक आप वह व्यक्ति नहीं हैं जो compliance documents पर sign करता है और safety की गारंटी देता है, तब तक unsafe साबित होने पर भी जिम्मेदार नहीं ठहराए जाएँगे
    • अगर कंपनी LLC या Corp है, तो आपको 'corporate veil' सुरक्षा देती है। जब तक रिकॉर्ड में आपने कोई आपराधिक काम नहीं किया, आपको जिम्मेदारी नहीं उठानी पड़ेगी। लेकिन हर आकार की कंपनी में security standards की कमी एक बड़ी समस्या है। नए features जारी करना हमेशा security से ज्यादा महत्वपूर्ण माना जाता है
    • छोटे संगठन के engineer के रूप में इन risks के बारे में टीम को educate करना, और security के लिए development time allocate करने पर जोर देना हमारी जिम्मेदारी है। यह आसान नहीं है, लेकिन इसे नज़रअंदाज़ करने से कंपनी खुद खतरे में पड़ सकती है
    • मैं होता तो कम-से-कम खुद को बचाने लायक क़ानून समझता, illegal requests पर लिखित आपत्ति देता, और अगर कहा जाए कि इसे अनदेखा करो, तो वह मंजूरी भी लिखित में लेता। लेकिन छोटे startup में यह भी मुश्किल हो सकता है। अगर मुझे लगे कि चीज़ें कानूनी नहीं हैं, तो मैं बस नौकरी छोड़ दूँगा
    • मुझे "मुझे आदेश मिला था" वाली defense पसंद नहीं, लेकिन ऐसे मामलों में लिखित रिकॉर्ड ज़रूर रखना चाहिए: security issue के बारे में email भेजो, और boss का "इसे छोड़ दो" जैसा जवाब सबूत के रूप में रखो। मेरी जानकारी में entry-level कर्मचारियों को data breach के लिए कानूनी रूप से जिम्मेदार ठहराए जाते नहीं देखा है। आमतौर पर किसी पर व्यक्तिगत कार्रवाई नहीं होती, कंपनी एक प्रतीकात्मक fine भरती है और बात खत्म हो जाती है
    • अगर आप company executive नहीं हैं, तो शायद आपकी व्यक्तिगत जिम्मेदारी नहीं बनेगी
    • मेरे अनुभव में ऐसा नहीं होता

  • शोधकर्ता की कानूनी जिम्मेदारी कम करने के लिए, मुझे लगता है कि एक और account बना लेना या किसी दोस्त की सहमति से profile बनाकर access लेना ही काफी है। वास्तव में data scrape करने की ज़रूरत नहीं है। उदाहरण के लिए, अगर मेरी id 12345 है और दोस्त की id 12357, तो बीच की id से किसी और account की profile तक पहुंच संभव है, यह साबित किया जा सकता है। जैसा कई लोगों ने कहा, हजारों लोगों की private information तक पहुंचने की ज़रूरत नहीं, vulnerability साबित कर सार्वजनिक करना ही पर्याप्त है

    • यह वही standard और स्पष्ट तरीका है जो information security researchers जानते हैं। sensitive information scrape करके साबित करने का मन हो सकता है, लेकिन वह अनावश्यक है और उल्टा कपटपूर्ण व्यवहार है

  • यह पोस्ट खुद काफी उलझी हुई लगती है। OTP (one-time password) पाने वाला API इतना साधारण था कि server response में ही OTP दिखाई दे रहा था, यानी सिर्फ phone number पता हो तो कोई भी account access कर सकता था। कहा गया है कि API बस otp/mobile-number जैसा था और response में OTP आ रहा था, तो लगता है कि बस phone number guess करो और code भी मिल जाए। फिर script से user ID enumerate की गई, और 1,000 लगातार खाली IDs मिलने पर रुकने दिया गया, जिससे कुल 6,117 users, 207 लोगों के identity documents, और 19 Yale छात्रों की जानकारी मिलने की बात कही गई। लेकिन बिना सहमति इस स्तर तक दूसरों की personal information access करना, अतीत में weev द्वारा AT&T hack करने और जेल जाने वाले मामले जैसा लगता है। पैमाना छोटा हो सकता है, फिर भी ऐसा research कानूनी रूप से जोखिमभरा है, और यह चिंता की बात है कि लेखक शायद security researchers की रक्षा न करने वाले कानूनी माहौल को नहीं समझता

    • इसमें उस हिस्से का ज़िक्र है कि API otp/number पर final OTP सीधे लौटा रही थी। यानी सिर्फ phone number सही हो to OTP तुरंत मिल जाता था
    • अगर आप Auernheimer मामले की शुरुआती indictment पढ़ें, तो उसमें (इस मामले से अलग) criminal intent साबित करने के लिए काफी सबूत थे। उन पर वास्तव में personal information बाहर सार्वजनिक करने का आरोप भी था, और यह मामला उस स्तर तक वैसा नहीं है

  • मेरा भी एक ऐसा अनुभव रहा है। एक दूसरी dating app में bug बताने की कोशिश की, लेकिन संपर्क नहीं हो पाया, तो मैंने founder की profile को "कृपया संपर्क करें" में बदल दिया। उन्होंने उसे backup से restore कर दिया। कुछ साल बाद Instagram ad में वह ऐप फिर दिखी, तो दोबारा देखा और वही vulnerability अभी भी मौजूद थी। सिर्फ API endpoint पता हो तो कोई भी admin access, सभी messages और matches तक पहुंच सकता है। अब सोच रहा हूँ कि फिर से संपर्क करना चाहिए या नहीं

    • सुझाव है कि संपर्क करके बताओ कि तुम जिम्मेदार डेवलपर हो, issue disclose करो और आगे बढ़ जाओ

  • passport या address जैसी sensitive information इकट्ठा करते समय, मेरा मानना है कि ऐप्स को सच में दो बार सोचना चाहिए। "यह students का बनाया ऐप है" कहकर इसे हल्के में नहीं लेना चाहिए

    • UK सरकार porn sites तक पहुंच के लिए ID अनिवार्य करने की कोशिश कर रही है, तो देखना दिलचस्प होगा कि उसका नतीजा क्या निकलता है
    • अगर passport जैसी ID information ली गई है, तो input के बाद उसे कभी भी बाहर expose करने की ज़रूरत नहीं होनी चाहिए। अगर UI में ID data दिखाने के लिए API है, तो पूरे नंबर के बजाय आख़िरी कुछ digits लौटाना ही काफी है। dating app में तो सिर्फ ID verified है या नहीं, यह boolean type या enum (verified नहीं / passport / driver's license) के रूप में लौटाना भी काफी है। airline app जैसी प्रणालियाँ जहाँ ID के आधार पर चयन ज़रूरी हो, वे अपवाद हैं, लेकिन जैसे United app भी सिर्फ आख़िरी कुछ digits दिखाती है, वैसे ही internal APIs पर भी ऐसी पाबंदी होनी चाहिए
    • GDPR (यूरोपीय data protection law) देखने के लिए लिंक साझा किया गया
    • मेरा मानना है कि कोई सुरक्षित और private government-run identity verification service होनी चाहिए। या फिर Apple या Google जैसी कंपनियाँ, जो लगभग 'सरकार जैसी' भूमिका निभाती हैं, यह काम करें
    • आम तौर पर third-party identity verification services इस्तेमाल की जाती हैं, लेकिन मुझे संदेह है कि क्या वे सेवाएँ सच में ID image तक ऐप को भेजती हैं

  • API response में OTP को जस का तस लौटाना बहुत ही बेतुकी बात है। समझ नहीं आता क्यों

    • UI में input value से तुरंत compare करने के लिए ऐसा किया होगा। अगर security के बारे में न सोचो तो यह ऊपर-ऊपर सही लग सकता है। dating apps में मांगी जाने वाली personal information की सीमा बहुत बड़ी होती है, इसलिए ऐसी गलती भयावह है
    • इस तरह database cost एक झटके में कम की जा सकती है
    • OTP generate करने के बाद DB या cache response को सीधे return कर देने वाला मॉडल POC या MVP में जल्दी-जल्दी बनाते समय आसानी से छूट सकता है
    • ऐसा लगता है कि OTP "one-time password भेजने के अनुरोध के response" में ही खुलकर दिख रहा था। संभव है कि framework पूरे DB object को serialize करके HTTP से लौटा रहा हो
    • एक HTTP request बचती है और UX तेज़ हो जाता है, इसलिए सतह पर यह अच्छा लग सकता है। Pinterest ने भी कभी पुराने API में 2FA secret सहित सारी जानकारी expose कर दी थी। मैंने report किया था और reward भी मिला था, लेकिन ऐसी गलतियाँ Big Tech में भी कभी-कभी हो जाती हैं
    • मुझे भी समझ नहीं आता। बस इतना लगता है कि form build को आसान बनाने की कोशिश में हुई गलती थी

  • Yale Daily News का एक और संबंधित लेख साझा किया गया

  • काश कोई ऐसा कानून हो जो personal information को nuclear waste जितना खतरनाक मानकर संभाले। leak होने पर कंपनी सिर्फ बर्बाद ही न हो, जिम्मेदार लोगों को भी कानूनी संकट झेलना पड़े। अभी तो user data इकट्ठा करना बहुत आसान है, और leak होने पर बस माफ़ी मांगकर बात खत्म हो जाती है

    • PII को nuclear material की तरह ट्रीट करना शायद कुछ ज़्यादा है। email address जैसी चीज़ें, जो सिर्फ auth/contact के लिए उपयोग होती हैं, उतनी बड़ी समस्या नहीं हैं
    • शायद white-collar style जेल ही लोगों का ध्यान सच में खींच सकेगी

  • मुझे अब जाकर iOS par Charle's Proxy नाम का टूल पता चला। पहले मैं pentesting के लिए सीधे app binary में strings search करता था। iOS-only app analysis में यह सच में बहुत मददगार लग रहा है

    • अच्छा टूल है, recommendation है (बस SSL pinning हो तो काम नहीं करेगा)