- एक 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 का कानूनी धमकी में बदल जाना एक वास्तविकता बनी हुई है
अभी कोई टिप्पणी नहीं है.