- जर्मनी में एक डेवलपर ने काम के दौरान सॉफ़्टवेयर लॉग की जांच करते हुए vendor DB access information खोजी और इसकी सूचना दी, लेकिन अदालत ने इसे हैकिंग माना
- संबंधित सॉफ़्टवेयर vendor database server के लिए MySQL connection बना रहा था, और उसमें डेवलपर के client के डेटा के साथ-साथ vendor के सभी ग्राहकों का डेटा भी मौजूद था
- credentials एप्लिकेशन के भीतर plain text में hardcoded थे और इतने खुले रूप में थे कि decompile करने की भी ज़रूरत नहीं थी
- अदालत ने माना कि सिर्फ़ password का मौजूद होना ही एक protection mechanism था, और इसे bypass करना हैकिंग के दायरे में आता है
- ऐसी सज़ा वैध security research को हतोत्साहित कर सकती है और कमज़ोर सुरक्षा वाली कंपनियों को ज़िम्मेदारी से बचाते हुए उपयोगकर्ताओं को और ज़्यादा जोखिम में डाल सकती है
खोज से मुकदमे तक
- यह मामला ऐसी चिंता पैदा करता है कि जर्मन क़ानून security research को ख़तरनाक काम बना सकता है
- एक डेवलपर को ऐसे सॉफ़्टवेयर की जांच का काम सौंपा गया था जिसमें log messages असामान्य रूप से बहुत अधिक आ रहे थे
- जांच के दौरान उसने पुष्टि की कि संबंधित सॉफ़्टवेयर vendor के database server के लिए MySQL connection बना रहा था
- उस database में उसके client के डेटा के अलावा vendor के सभी ग्राहकों का डेटा भी था
- डेवलपर ने इसकी पुष्टि करने के बाद तुरंत vendor को सूचना दी, vendor ने vulnerability ठीक कर दी, लेकिन डेवलपर के ख़िलाफ़ आपराधिक शिकायत दर्ज कराई
अदालत की नज़र में protection mechanism
- मुख्य सवाल यह था कि एप्लिकेशन में hardcoded database credentials क्या इतने सुरक्षा उपाय माने जा सकते हैं कि हैकिंग के आरोप को सही ठहराया जा सके
- ये credentials plain text में exposed थे और decompile करने की भी आवश्यकता नहीं थी
- अदालत ने कहा कि password मौजूद था, इसलिए protection mechanism था, और इसे bypass करना हैकिंग है
security research पर बना रहने वाला जोखिम
- लोग उम्मीद कर रहे हैं कि ऊपरी अदालत इस फ़ैसले को पलटे, क्योंकि अगर सुरक्षा उपाय कितना भी कमज़ोर हो, सिर्फ़ उसका मौजूद होना ही जर्मन क़ानून के तहत security research को आपराधिक हैकिंग बना सकता है
- अगर वैध research हतोत्साहित होती है, तो कंपनियाँ अपर्याप्त सुरक्षा बनाए रखते हुए भी ज़िम्मेदारी से बच सकती हैं, और अंततः उपयोगकर्ता जोखिम में पड़ते हैं
मूल स्रोत
- संबंधित जर्मन लेख: Gericht sieht Nutzung von Klartext-Passwörtern als Hacken an
1 टिप्पणियां
Hacker News की राय
लेख का शीर्षक थोड़ा भ्रमित करने वाला है और लगभग clickbait जैसा लगता है। अगर मैंने सही समझा है, तो उसका अपराध exposed database credentials का इस्तेमाल करके किसी third-party database server में login करना था
यानी शीर्षक जैसा यह मामला सिर्फ credentials “expose” करने पर मुकदमा चलाने का नहीं था, बल्कि असल में उनका इस्तेमाल करके अंदर झांकने जैसा था
यह कुछ वैसा है जैसे किसी building access card मिलने पर यह मान लेना कि जिन दरवाजों को वह खोलता है, उन कमरों में जाना ठीक है। अगर security team मुझे ऐसे कमरे में पाती है जहाँ मुझे नहीं जाना चाहिए था, तो यह अस्पष्ट है कि गलती मेरी है या उस व्यक्ति की जिसने गलत permissions वाला card दिया
अगर मैंने दरवाजा खोला, अंदर देखा और तुरंत समझ गया कि “यहाँ नहीं आना चाहिए” और security team को report कर दिया, तो यह भी सवाल है कि क्या मुझे सजा मिलनी चाहिए
लेकिन मुख्य बात यह है कि क्या login करने से पहले वह यह जान सकता था। अगर credentials app के अंदर हैं, तो क्या उसे यह मान लेना चाहिए कि company की security इतनी ढीली है कि सभी customer data तक access मिल जाएगा? उसे app इस्तेमाल करने का अधिकार था, और app वही credentials इस्तेमाल करती है, इसलिए उसका यह सोचना कि वह भी उनका इस्तेमाल कर सकता है, इतनी बड़ी छलांग नहीं है
जो भी हो, इस फैसले का नतीजा computer security के लिए साफ तौर पर बुरा होगा। आगे ऐसे vulnerabilities खोजने वाले लोग legal retaliation के डर से report न करें, ऐसा हो सकता है
Developer के नजरिए से यह सोचना स्वाभाविक है कि password normal users के अलावा non-users के access को रोकने के लिए होता है। शुरू से ही credentials न तो छिपाए गए थे, न obfuscate किए गए थे
जब यह स्पष्ट हुआ कि users को access नहीं होना चाहिए, तो उसने supplier को report किया। क्या मैं कुछ miss कर रहा हूँ? एक तरफ अपना काम करने वाला developer है, और दूसरी तरफ शर्मिंदा company है जो बदला लेते हुए संभावित bug reporters को डराती दिख रही है। क्या हो रहा है, यह बहुत साफ दिखता है
Database का नाम भी शायद ऐसा ही दिखता था। बाद में जैसे ही उसे पता चला कि उसमें सभी customers का data है, उसने connection बंद कर दिया
अहम बात यह है कि access के बाद उसने उस data के साथ क्या किया। अगर उसने कुछ नहीं किया, तो यह अपराध नहीं होना चाहिए; अपराध तब माना जाना चाहिए जब उस data का सचमुच malicious इस्तेमाल किया गया हो
यह Germany में काफी बड़ा मुद्दा है। उद्धृत StGB 202 और उसके बाद की धाराओं की वजह से private sector में security research प्रभावी रूप से असंभव, या कम से कम बेहद unattractive हो गई है
लगभग 20 साल का gap बन गया, जिससे युवा engineers की इस क्षेत्र में रुचि या training लगभग नहीं हुई। सबसे पैसे वाली बड़ी companies ने उपलब्ध talent अपने पास खींच लिया, और top talent विदेश चला गया। इसलिए Germany की ज्यादातर companies, यानी SMEs, हर दिन और ज्यादा hack हो रही हैं। कोई audit नहीं करता। आजकल network से जुड़ी हर चीज security risk है
यह उम्मीद करना कि higher court में फैसला पलट जाएगा, मुझे बहुत भोला विचार लगता है। Defendant AG से LG, OLG, BGH तक जाते हुए कई सालों का समय बर्बाद कर सकता है। खर्च भी शायद करीब 100,000 euro उड़ जाएगा। आखिर किसलिए? Company अपने data को ठीक से protect नहीं कर पाई, और जब उसे बताया गया तो “धन्यवाद” के तौर पर उसे court में खड़ा कर दिया
मेरी सलाह यह है: अगर कोई clear bug bounty program नहीं है, या वह आपकी अपनी company नहीं है, या उस company ने स्पष्ट रूप से written में commission करके उसके लिए payment नहीं किया है, तो उस समस्या को अपनी समस्या मत बनाइए। Good Samaritan complex को दबाइए, सभी files delete कीजिए, और किसी से कुछ मत कहिए। खासकर workplace में तो बिल्कुल नहीं। मुकदमा शुरू होने पर जिस व्यक्ति से सवाल पूछा जाएगा, वह कहेगा “अरे, DevOps वाले Mike ने hex dump में यह पता लगाया था,” और आपको पछताना पड़ेगा
Germany के पुराने infosec experts में से कुछ इस मुद्दे से इतने नाराज हैं कि government agencies में incident होने पर भी मदद करने से इनकार कर देते हैं। मतलब, दर्द से सीखो
यह मामला कई सालों से चल रहा है
पिछली गर्मियों में court ने prosecution का case खारिज कर दिया था। इस system में prosecution case को court में submit करता है, और court जल्दी से review करके अगर वह स्पष्ट रूप से कमजोर हो तो trial schedule करने से पहले उसे dismiss कर सकता है, जो काफी rare है। Prosecution ने higher court में इसे पलटवा दिया, इसलिए उसी lower court में trial हुआ, लेकिन उस judge से अलग judge ने मामला सुना जिसने पहले case dismiss किया था
“10 मई 2023 को Jülich district court के decision के अनुसार, security researcher के खिलाफ criminal proceedings खारिज कर दी गईं। Court का मानना है कि security researcher ने जिस data तक access किया, वह पर्याप्त रूप से protected नहीं था, इसलिए criminal offense नहीं बनता। Court decision में कहा गया, ‘केवल वही data इस offense की protection scope में आता है जो unauthorized access के खिलाफ विशेष रूप से protected हो। यह मानता है कि data access रोकने के लिए objectively suitable measures लिए गए हों।’ ‘Court prosecution के इस view से सहमत नहीं है कि password protection अपने-आप में पर्याप्त है। उदाहरण के लिए, अगर password बहुत simple हो या किसी particular application में standardized तरीके से इस्तेमाल होता हो, तो password हमेशा effective data protection नहीं देता। ऐसे मामलों में data access उपलब्ध कराना अपराध नहीं बनता।’”
“heise online ने Modern Solution software की अपनी जांच में पुष्टि की कि उसमें वास्तव में embedded default password शामिल था। इसका मतलब था कि company website से freely download किए जा सकने वाले software की जांच करने वाला कोई भी व्यक्ति Modern Solution servers के data तक access कर सकता था।”
नहीं, उसे उन credentials का इस्तेमाल करके database से connect करने के आरोप में दोषी ठहराया गया था। मुझे जर्मन कानून नहीं पता, लेकिन कम से कम UK में यह Computer Misuse Act का साफ़ उल्लंघन है, इसलिए नतीजा तय-सा मामला है
आपको पसंद हो या नहीं, अगर आप इस तरह की research करने की स्थिति में हैं, तो कानून की बुनियादी समझ तो होनी ही चाहिए
सुनने में लगता है कि developer security research नहीं कर रहा था, बल्कि bug investigate कर रहा था। database से connect करके यह समझने के बाद कि मामला क्या है, तुरंत disconnect करना और responsibly report करना सज़ा में नहीं बदलना चाहिए
जैसा किसी और ने कहा, अगर ऐसा होगा तो लोग इस जानकारी को उन लोगों को बेचने के लिए प्रोत्साहित होंगे जो सच में इसका “misuse” करेंगे
मुझे फर्क समझ नहीं आ रहा। Terms of service का violation हो सकता है, लेकिन इसे “hacking” कहना बहुत दूर की बात है
password होने का मतलब यह नहीं कि वे लोगों को रोकना चाहते थे। उन्होंने password साथ में distribute किया था
यह वैसा है जैसे किसी building में घुसते समय आपको keycard दे दिया जाए और कहा जाए “जहां नहीं जाना चाहिए, वहां मत जाइए”, लेकिन बाद में पता चले कि वह master key था। शुरू में आपको कैसे पता चलेगा कि वह card उन जगहों को भी खोल देगा जहां उसे नहीं खोलना चाहिए था
मेरे पास भी Google services के credentials हैं, लेकिन वे मुझे सिर्फ़ मेरी चीज़ों तक access देते हैं
उसने उस दूसरी service का connector चलाया जहां से वह data आता दिख रहा था, और firewall पर remote MySQL server के लिए plaintext connection खुलते देखा। देखने पर पता चला कि इस्तेमाल किए गए credentials MySQL DB के सभी tenants में समान थे। इसलिए expose सिर्फ़ customer data नहीं, बल्कि सभी tenants का data हुआ था
इसके बाद, मेरी जानकारी में उसने user data के hashes बनाए और उन्हें export करके authorities को report करने और users को यह check करने देने की कोशिश की कि वे उस system में शामिल हैं या नहीं जिसे breached माना जाना चाहिए। उस DB ने करीब 7 लाख end users का data expose किया था। उसने इस issue के बारे में DB operate करने वाली company को भी बताया था
उस connector vendor ने TLS इस्तेमाल करने वाला नया client निकाला, और उसने यह दिखाने के लिए उसे भी bypass किया कि समस्या अब भी valid है
उस पर client software decompile करके password पाने का आरोप भी लगा, लेकिन मुझे याद है कि उसका दावा था कि उसने बस file को Notepad में खोला था
जब उसे एहसास हुआ कि intended से ज़्यादा data access किया जा सकता है, तो उसने connection बंद कर दिया
मैंने भी एक मिलती-जुलती स्थिति में बिल्कुल यही किया था। एक problematic desktop software vendor था, और configuration file में database credentials plaintext में stored देखकर मैंने connect किया। मेरे मामले में वह database हमारी company के लिए dedicated single tenant था, इसलिए मैं अपना काम कर सका
ऐसे cases में कानून लागू करते समय intent को ज़रूर consider करना चाहिए, है ना? ऐसा नहीं लगता कि इस developer का restricted system access करने का इरादा था
ऐसे कानून को फिर से लिखने की ज़रूरत लगती है। intent मायने रखता है, और ऐसा नहीं दिखता कि इस “hacker” का नुकसान पहुंचाने का इरादा था
company security hole expose होने से शर्मिंदा हुई, और उसे public करने वाले व्यक्ति को punish करना चाहती है
सिर्फ़ इस case के आधार पर ही, एक developer के तौर पर मैं Germany में काम नहीं करना चाहूंगा, और security field में तो बिल्कुल नहीं
वे चाहते हैं कि “किसान” अपनी औकात जानें और nobles की खिड़कियों में झांकें नहीं। जब तक lawyers किसी तरह public opinion की रोशनी न डालें, state लगभग हमेशा उसी पक्ष में खड़ी होती है जिसके पास सबसे ज़्यादा पैसा होता है। इसलिए ऐसी चीज़ें anonymously करनी चाहिए
मैंने Netherlands में एक food startup किया था
हम PostNL के साथ काम करते थे, जो mail delivery की प्रमुख company है और पहले government organization थी। हर हफ्ते हम अपने orders उनके system में upload करते थे, और अपनी history देख सकते थे
फिर एक दिन अचानक हम सभी दूसरे customers की history access कर सकते थे और user data export कर सकते थे। उनमें से कई direct competitors थे, और उनकी mailing lists हमारे लिए काफी valuable होतीं
मेरे partner ने ज़्यादा funding पाए competitor Marley Spoon का पूरा data और कुछ और data Excel में export कर लिया। जब उसने मुझे बताया, मैंने तुरंत delete करने को कहा। मज़ेदार हो सकता था, लेकिन legal liability नहीं बनानी चाहिए। लेकिन अगर हम उसका इस्तेमाल करते, तो कुछ हफ्तों में 10–30% grow कर सकते थे
EU law के तहत उनकी duty थी, फिर भी उन्होंने कभी report नहीं किया
आखिरकार, अगर आपको castle की keys मिल जाएं, तो शायद उन्हें इस्तेमाल न करना बेहतर है। या शायद इस्तेमाल भी कर सकते हैं
हम price negotiations में इसका इस्तेमाल कर सकते थे, और शायद करना भी चाहिए था। बाद के महीनों में उन्होंने हमारे prices लगभग double कर दिए और कोई रहम नहीं दिखाया। यह अलग बात है कि वे 3–8% orders गलत handle करते थे और refund भी नहीं करते थे
लेकिन इसके बजाय हम कुछ दूसरी delivery services पर चले गए, और उनमें भी अपनी-अपनी कमियां थीं
personal data leak होने के evidence वाले screenshots ज़रूर मदद करेंगे, और मुझे नहीं लगता कि PostNL ने वह भयानक system ठीक किया होगा
Dutch law के तहत, अगर आपके colleague को पता था कि उसे access नहीं करना चाहिए, फिर भी उसने leak verify करने के लिए जरूरी दायरे से ज्यादा data download किया, तो उसने अपराध किया
अगर आपने negotiation में इस information को “use” किया होता, तो वह blackmail होता, और खासकर इतनी बड़ी company, जिसके पास practically कोई competitor भी नहीं है, के खिलाफ आप ऐसा बिल्कुल नहीं करना चाहेंगे। वे police को report करेंगे, और आपका खेल खत्म हो जाएगा
यह मेरे रहने की जगह पर हुई एक घटना जैसा लगता है
https://www.techdirt.com/2022/02/25/turns-out-it-was-actuall...
वह “hacking” असल में Base64 में मौजूद social security numbers को decode करना था
कल्पना करो कि आलसी programmers online Base64 decoders में क्या-क्या paste करते होंगे। उन payloads में कितना कुछ भरा होगा
base64decode.org जैसी site चलाना एक शानदार honeypot होगा
अगर उन्होंने सच में data encrypt किया होता तो ठीक था, लेकिन Base64 encoding encryption नहीं है। Base64 को बहुत आसानी से decode किया जा सकता है: https://developer.mozilla.org/en-US/docs/Glossary/Base64#the...
कई “hacks” ऐसे होते हैं जैसे कोई मूर्ख अपना front door पूरा खुला छोड़ दे
अगर आपने front door पूरा खुला छोड़ दिया और चोरी हो गई, तो जनता सहानुभूति नहीं दिखाएगी; लेकिन जब companies basic security best practices को update, maintain और enforce करने पर पैसा बचाती हैं और कुछ नहीं करतीं, तो लोग hacker पर चिल्लाते हैं
अगर तुमने front door खुला छोड़ दिया और मैं अंदर जाकर चोरी कर लूं, तो मैंने अपराध किया है। “दरवाज़ा खुला था” कोई बहाना नहीं है
मुझे दोष दिया जाना चाहिए, लेकिन जिसने मुझे लूटा उसे भी उचित सज़ा मिलनी चाहिए
भले ही वे दावा करें कि वे “सिर्फ यह जांचना चाहते थे कि सब सुरक्षित है या नहीं”
क्या यह Good Samaritan laws का उल्टा नहीं है? कुछ दिखे तो कुछ मत कहो, कुछ मत करो—ऐसा लगता है
अगर ऐसी problem ढूंढना illegal है, तो यह जानने के बाद कि problem हो सकती है, रुक जाना और उस company के shares short करना legal होगा या नहीं, सोच रहा हूं
असल में ऐसा करने पर जो problem आएगी, वह यह है कि investors security issues की बहुत कम परवाह करते हैं। इसलिए vulnerability disclose करने पर भी share price गिरने की संभावना कम है। इसके अलावा, लगता नहीं कि यह company publicly listed है। मुझे German नहीं आती, इसलिए पक्का नहीं कहना चाहिए, लेकिन शायद यह वाली है: https://www.modernsolution.net/
कुछ ऐसा: “नमस्ते, संयोग से मुझे पता चला कि इस app के offset X पर एक password है। इस hex dump screenshot में password दिख रहा है। बगल में username और host भी हैं, और SQL connection होने के साफ संकेत भी हैं, लेकिन मैं यह verify नहीं कर सकता कि password क्या है। कृपया इस username और password से इस IP पर connect न करें। धन्यवाद!”
और US companies के मामले में, बड़े data leaks या breaches भी अक्सर company financials पर negative असर नहीं डालते
Criminal Code की धारा 202a यह कहती है
https://www.gesetze-im-internet.de/stgb/__202a.html
मोटे तौर पर, “ऐसे data तक अपने या किसी और के लिए access हासिल करना, जो unauthorized access से बचाने के लिए खास तरीके से protected हो”
apparently client में embedded hardcoded password भी इसी में आता है
लेकिन reality यही है, और शायद 2050 के आसपास इसे ठीक किया जाए