मुझे एक vulnerability मिली। उन्होंने एक वकील ढूंढ लिया

 (dixken.de)
2 पॉइंट द्वारा GN⁺ 2026-02-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • एक diving instructor और platform engineer लेखक ने diving insurance company के member portal में गंभीर security vulnerability खोजी
  • पोर्टल में sequential user ID और एक जैसे default password इस्तेमाल हो रहे थे, जिससे कोई भी साधारण संयोजन से दूसरे members की personal information तक पहुंच सकता था
  • समस्या को CSIRT Malta और संबंधित संस्था को एक साथ report किया गया, लेकिन संस्था ने आभार जताने के बजाय कानूनी प्रतिनिधि के जरिए संभावित आपराधिक जिम्मेदारी की चेतावनी दी
  • लेखक ने NDA की मांग ठुकरा दी और सिर्फ data deletion की पुष्टि वाला एक संशोधित declaration प्रस्तावित किया, लेकिन संस्था ने defamation की संभावना का हवाला देकर फिर से धमकी दी
  • यह मामला responsible vulnerability disclosure की अहमियत और कानूनी धमकियों से researchers की सुरक्षा कमजोर होने की वास्तविकता को उजागर करता है

vulnerability की खोज

  • Costa Rica के Cocos Island diving trip के दौरान, diving insurance company के member portal में structural flaw मिला
    • instructor जब student को register करता था, तो system sequential numeric ID और ऐसा default password बनाता था जो बदला नहीं जाता था
    • कई users password नहीं बदलते थे, इसलिए दूसरे members की पूरी personal information (नाम, पता, जन्मतिथि, संपर्क विवरण आदि) तक पहुंच संभव थी
  • password change enforcement, login restriction, MFA जैसी बुनियादी security measures बिल्कुल नहीं थीं
  • कुछ accounts में नाबालिगों (14 वर्ष) की जानकारी भी शामिल थी
  • लेखक ने न्यूनतम access से समस्या verify की, तुरंत रुक गया, और सारा एकत्र किया गया data स्थायी रूप से delete कर दिया

verification और proof

  • Python requests से कोशिश की गई, लेकिन session structure जटिल होने के कारण Selenium से browser automation द्वारा verification किया गया
    • सिर्फ user ID और default password डालने पर login संभव था
    • automation script को non-functional example code के रूप में public किया गया है, और सभी वास्तविक identifiers हटा दिए गए हैं
  • output example में नाम, email, पता, जन्मतिथि आदि पूरा profile data शामिल था
  • इस प्रक्रिया में कई नाबालिग accounts भी इसी तरीके से exposed होने की पुष्टि हुई

vulnerability disclosure प्रक्रिया

  • 28 अप्रैल 2025 को vulnerability की औपचारिक report दी गई और 30 दिन की remediation grace period तय की गई
  • CSIRT Malta और संबंधित संस्था को एक साथ email से सूचित किया गया
    • report में issue summary, संभावित GDPR violation, screenshots, और encrypted PoC link शामिल थे
    • 7 दिनों के भीतर acknowledgment और 30 दिनों में remediation का अनुरोध किया गया
  • यह national vulnerability disclosure policy (NCVDP) के अनुरूप standard procedure था

संस्था की प्रतिक्रिया

  • दो दिन बाद IT team की जगह data protection officer के lawyer (DPO law office) से जवाब आया
    • उन्होंने password reset और 2FA adoption का जिक्र किया, लेकिन सरकारी संस्था को पहले सूचित करने पर आपत्ति जताई
    • उन्होंने चेतावनी दी कि लेखक की कार्रवाई Malta criminal law के तहत अपराध हो सकती है और कानूनी जिम्मेदारी बन सकती है
  • संस्था ने confidentiality declaration पर हस्ताक्षर की मांग की, साथ में passport copy और उसी दिन signing deadline भी दी
    • declaration में “इस declaration की सामग्री को गोपनीय रखा जाएगा” जैसी clause थी, यानी यह व्यावहारिक रूप से NDA था
  • इसके बाद “friendly reminder”, “urgent reminder” जैसी बार-बार signing requests आती रहीं

researcher का इनकार और जवाब

  • लेखक ने confidentiality clause पर हस्ताक्षर से इनकार किया और उसकी जगह सिर्फ data deletion confirmation वाला संशोधित declaration प्रस्तावित किया
    • उसने स्पष्ट किया कि CSIRT Malta को सूचना देना official procedure का हिस्सा है, और public disclosure के बाद analysis security industry की standard practice है
  • संस्था ने criminal code section 337E (computer misuse) का हवाला देते हुए चेतावनी दी कि विदेश में किया गया कार्य भी Malta में अपराध माना जा सकता है
  • साथ ही यह भी कहा गया कि अगर blog या conference में संस्था का नाम लिया गया, तो defamation और damages claim हो सकती है
  • अभी vulnerability fix कर दी गई है, और default password reset तथा 2FA adoption जारी है
  • लेकिन GDPR articles 33 और 34 के तहत affected users को notification दिया गया या नहीं, यह स्पष्ट नहीं है

जिम्मेदारी टालना और GDPR violation

  • संस्था ने दावा किया कि “password बदलना users की जिम्मेदारी है”
  • लेकिन GDPR article 5(1)(f) और article 24(1) के अनुसार data controller को उचित technical और organizational measures अपनाने होते हैं
  • एक जैसे default password और sequential ID स्पष्ट रूप से अपर्याप्त security measures हैं

बार-बार दिखने वाला pattern

  • जब security researcher vulnerability को जिम्मेदारी से disclose करते हैं, तब भी कानूनी धमकियों का ‘chilling effect’ बना हुआ है
  • कानूनी प्रतिक्रिया उल्टा reputation को और नुकसान पहुंचाती है; असली समस्या vulnerability नहीं बल्कि organization की response strategy है

सही response प्रक्रिया

  • report receive करना और fix लागू करना
  • researcher का आभार व्यक्त करना
  • CVD (Coordinated Vulnerability Disclosure) policy बनाना
  • affected users को notify करना, खासकर नाबालिगों की सुरक्षा के लिए
  • NDA के जरिए चुप्पी थोपने से बचना

organizations और researchers के लिए सलाह

  • organizations को security.txt जैसी स्पष्ट disclosure प्रक्रिया बनानी चाहिए और researchers का धन्यवाद करना चाहिए
  • researchers को national CSIRT को शामिल करना, सभी records सुरक्षित रखना, data delete करने के बाद confidentiality clause ठुकराना जैसी practices अपनानी चाहिए
  • NIS2 directive EU के भीतर responsible vulnerability disclosure को प्रोत्साहित करती है
  • फिर भी 2026 में भी, एक साधारण vulnerability report का कानूनी धमकी में बदल जाना एक वास्तविकता बनी हुई है

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

1 टिप्पणियां

 
GN⁺ 2026-02-21
Hacker News की राय

  • ऐसे मामले पहले भी हुए हैं जहाँ लोगों ने क्रमिक रूप से बढ़ते user ID ढूँढकर टेस्ट किया और जेल तक गए
    जैसे ही आप इस तरह टेस्ट करते हैं, CFAA उल्लंघन का जोखिम पैदा हो जाता है
    अगर आपको पहले से पता था कि ID क्रमिक रूप से बढ़ रहे हैं और default password सेट है, तो उसी समय तुरंत vulnerability report करनी चाहिए थी
    जैसे ही आपने टेस्ट चलाया, हो सकता है आपने कानून तोड़ दिया हो
    अभी यह लिखना भी लगभग इकबालिया बयान जैसा है, इसलिए वकील रखना चाहिए और संबंधित कानून पढ़ना चाहिए

  • मेरे पास कानूनी विशेषज्ञता नहीं है, लेकिन तीन बातें हैं

    1. अगर कानूनी disclosure process बहुत कठिन होगी, तो आखिरकार vulnerabilities की जानकारी सिर्फ अपराधियों के ज़रिए ही मिलेगी
    2. अगर दूसरी industries की तरह यह स्थिति हो कि कोई architect building defect खोजे और उसी पर मुकदमा हो जाए, तो यह बेतुकी बात है। हाँ, cyber security अलग है क्योंकि किसी defect के बारे में जानना ही जोखिम बढ़ा सकता है
    3. यूँ ही रास्ते से गुज़रने वाला कोई random व्यक्ति audit करे, यह बहुत अस्थिर व्यवस्था है। अगर कोई website मेरी PII (व्यक्तिगत पहचान योग्य जानकारी) मांगती है, तो मुझे उस जानकारी की सुरक्षा की मांग करने का अधिकार होना चाहिए
      insurance company जैसी संस्थाओं के लिए कानूनन cyber audit अनिवार्य होना चाहिए, white-hat hackers की रक्षा होनी चाहिए, और users को class action मुकदमे करने की अनुमति मिलनी चाहिए
      ऐसा होने पर बुनियादी vulnerabilities कम होंगी, और वकीलों की तुलना में software engineers आर्थिक रूप से ज़्यादा उपयोगी साबित होंगे
    • दूसरी industries में professional engineer system होता है, जहाँ कानूनी जिम्मेदारी भी तय होती है
      सोचता हूँ कि AI युग में CS भी क्या इसी दिशा में जाएगा
      professional engineers design approval और inspection संभालते हैं, और safety सुनिश्चित करने में केंद्रीय भूमिका निभाते हैं
      उसी अनुपात में उनके पास अधिकार और जिम्मेदारी दोनों अधिक होते हैं, और उनका पारिश्रमिक भी ऊँचा होता है
    • दूसरी industries में designer के पास insurance और license होता है
      मैं beginner developers की open source गतिविधियों को रोकना नहीं चाहता, लेकिन जो sites बड़े पैमाने पर personal data या पैसा संभालती हैं, उन पर certified software engineer के हस्ताक्षर अनिवार्य होने चाहिए
      तभी management की अव्यावहारिक मांगों को रोकने की ताकत बनेगी
      हालाँकि Boeing या Volkswagen के मामलों को देखें तो यह भी कोई पूर्ण समाधान नहीं है
    • कुछ देशों में सच बात भी defamation मानी जा सकती है
      यानी अधिकारियों को report करना और media में सार्वजनिक करना, ये बिल्कुल अलग बातें हैं
      खासकर Malta जैसी जगहों में, जहाँ organized crime और corruption गंभीर हैं, ऐसे मामलों को सार्वजनिक करने वाले व्यक्ति के साथ ‘दुर्घटनावश हादसा’ भी हो सकता है

  • मैं हर service के लिए अलग email address इस्तेमाल करता हूँ
    लगभग 15 साल पहले मुझे diversalertnetwork पते पर spam मिलना शुरू हुआ
    मैंने DAN को breach के बारे में बताया, तो जवाब में सिर्फ password बदलने वाला email मिला
    अब सोचता हूँ कि मेरे खिलाफ criminal complaint नहीं हुई, यही गनीमत थी

    • वह hacking हो सकती थी, या कंपनी ने third party को data बेचा हो सकता है
    • मेरे साथ भी ऐसा ही हुआ। Portugal airline के लिए बनाए गए खास email पर spam आने लगा, लेकिन कंपनी ने कोई जवाब नहीं दिया

  • यह कि लेखक संगठन का नाम बताने से डर रहा है, इसका मतलब है कि कानूनी धमकी असरदार रही

    • या diving community में “Malta में मुख्यालय वाली diver insurance company” कहना ही शायद DAN Europe की ओर इशारा करना हो
    • पोस्ट के सुरागों को देखें तो, अंतरराष्ट्रीय diving insurance कंपनियों में Malta में registered संस्था सिर्फ DAN Europe ही लगती है, इसलिए लगभग तय माना जा सकता है
    • बेशक, यह संभावना भी पूरी तरह खारिज नहीं की जा सकती कि उसने मिली हुई जानकारी black-hat को बेच दी हो

  • “data deletion confirmation पर sign करो” जैसी मांग पर सवाल उठता है कि उसने sign क्यों किया
    कंपनी सहयोग से ज़्यादा control चाहती हुई लगती है

    • लेकिन अगर आप सामने वाले से अपनी शर्तों पर सहमति ले लें, तो उनकी control strategy को निष्प्रभावी करके उसे कानूनी रूप से बाध्यकारी बना सकते हैं

  • security researchers द्वारा vulnerability report करने पर कानूनी धमकियाँ मिलने का पैटर्न दशकों से दोहराया जा रहा है
    सरकारें और कंपनियाँ cyber security की अहमियत की बात तो करती हैं, लेकिन व्यवहार में researchers के प्रति शत्रुतापूर्ण रहती हैं
    इस तरह की अनुचित प्रतिक्रिया रोकने के लिए कानून बनाने की जरूरत है
    संबंधित उदाहरण इस लिंक में देखे जा सकते हैं

  • क्या यह मामला DAN Europe और उसकी subsidiary IDA Insurance Limited से जुड़ा है, यह जानने की जिज्ञासा है

    • दूसरे comment में पहले ही ऐसा अनुमान लगाया गया है

  • Germany में इस तरह script चलाकर दूसरे लोगों का data access करना गैरकानूनी है
    यह वैसा ही है जैसे किसी और की car का दरवाज़ा खुला देखकर अंदर घुसकर ignition चालू कर देना
    संबंधित कानूनी व्याख्या के लिए यह लेख देखें

    • अगर ऐसा है, तो कानून बदलना चाहिए। इस स्तर की security उदासीनता good-faith reporter या बड़े data leak के बिना कभी नहीं सुधरेगी
    • मैं भी सहमत हूँ। यह समझना जरूरी है कि कहाँ रुकना चाहिए
      site का सामान्य उपयोग करते हुए screenshot लेकर report करना ठीक है, लेकिन Python script से data इकट्ठा करना सीमा पार करना है
      यह वैसा है जैसे bank का दरवाज़ा खुला देखकर पुलिस को सूचना देने के बजाय खुद अंदर चले जाना
    • उम्मीद है अपराधी इस खामी का फायदा न उठाएँ

  • पिछले साल मैंने एक बड़े event ticket system में vulnerability पाई
    email से मिला ticket link दरअसल क्रमिक order number की base64 encoding था
    यानी दूसरे लोगों के ticket भी आसानी से download किए जा सकते थे
    मैंने आयोजकों और development company को mail भेजा, लेकिन कोई प्रतिक्रिया नहीं मिली, और अब भी वह खुला पड़ा है
    इस साल event के समय देखूँगा कि क्या इसे ठीक किया गया है

  • अगर user ID क्रमिक थे और default password सबके लिए एक जैसा था, तो असली vulnerability यह थी कि “यह मान लेना कि कोई security team मौजूद है”
    आजकल ‘responsible disclosure’ का मतलब आखिरकार सिर्फ कंपनी को वकील रखने के लिए समय देना रह गया है