पूर्व Gizmodo पत्रकार ने अपना नाम ‘Slackbot’ में बदल लिया और महीनों तक पकड़े नहीं गए

 (theverge.com)
1 पॉइंट द्वारा GN⁺ 2024-02-25 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • IT Brew के Tom McKay ने 2022 में Gizmodo छोड़ते समय अपने Slack अकाउंट को Slackbot जैसा दिखाकर कई महीनों तक डिलीट होने से बचाए रखा
  • Slack ने पहले से इस्तेमाल हो रहे “Slackbot” नाम को रोक दिया था, लेकिन McKay ने उससे मिलते-जुलते दिखने वाले Unicode characters से display name की सीमा को बायपास कर लिया
  • उन्होंने profile photo भी असली Slackbot icon से मिलती-जुलती गुस्से वाली version में बदल दी, जिससे admin डुप्लिकेट Slackbot और भौंहों का फर्क नहीं पकड़ पाए
  • अकाउंट बचे रहने के दौरान McKay अपने सहकर्मियों को “Slackbot fact of the day” जैसे bot जैसे दिखने वाले messages भेज सकते थे
  • कंपनी के हिसाब से ऐसी शरारतों को रोकने के लिए security measures हो सकते हैं, इसलिए departing employees के accounts की cleanup और display name verification अहम है

नौकरी छोड़ने के बाद बचा हुआ Slack account

  • IT Brew के Tom McKay ने Gizmodo छोड़ने के बाद अपने Slack account को Slackbot जैसा दिखाया
  • McKay ने X पर उस समय के screenshots साझा किए, और The Verge से भी पुष्टि की कि यह शरारत सच में हुई थी
  • नकली रूप दिए गए account को कई महीनों तक Gizmodo management ने न तो detect किया और न ही delete किया

Slackbot जैसा दिखाने का तरीका

  • Slackbot, Slack के अंदर notifications, office Wi-Fi password की जानकारी, और उन channels में mentions की alerts जैसी चीजों में मदद करने वाला परिचित bot है जिनमें user शामिल नहीं है
  • McKay ने नौकरी छोड़ते समय अपनी मौजूदा profile photo को असली Slackbot icon से मिलती-जुलती गुस्से वाली version image में बदल दिया
  • उन्होंने display name को भी “Slackbot” में बदलने की कोशिश की, लेकिन Slack ने यह कहकर सामान्य बदलाव की अनुमति नहीं दी कि यह नाम पहले से इस्तेमाल में है
  • इसके बजाय, उन्होंने अक्षरों जैसे दिखने वाले Unicode characters का इस्तेमाल कर नाम की सीमा को बायपास किया
    • उदाहरण: “o” को उससे मिलते-जुलते दिखने वाले Unicode character “о” से बदलने का तरीका

कई महीनों तक क्या-क्या संभव रहा

  • इस बदलाव की वजह से McKay का active Slack account कई महीनों तक delete होने से बचा रहा
  • account बचे रहने के दौरान वे सहकर्मियों को bot जैसे दिखने वाले messages भेज सकते थे
    • उदाहरण: “Slackbot fact of the day: Hi, I’m Slackbot! That’s a fact. Have a Slack-ly day!”
  • पहले Gizmodo में काम कर चुकी Victoria Song ने प्रतिक्रिया दी कि यह स्थिति आश्चर्यजनक नहीं है

कंपनी के हिसाब से बचाव की संभावना

  • सभी कंपनियां इसी तरीके से धोखा नहीं खातीं, और कुछ कंपनियों के पास इस तरह की स्थिति रोकने के लिए security measures होते हैं
  • Gizmodo management ने शायद सोचा होगा कि McKay का account पहले ही delete हो चुका है
  • या वे संदिग्ध भौंहों वाले duplicate Slackbot को पहचानने जितनी बारीकी से नहीं देख पाए होंगे

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

1 टिप्पणियां

 
GN⁺ 2024-02-25
Hacker News टिप्पणियाँ

  • एक पुराने पूर्व कर्मचारी, जिसे मैं जानता था, ने modem rack controller module में Ringing नाम का एक dial-up/ISDN provisioning profile बना रखा था। Radius server पर बनाता तो बहुत obvious हो जाता, इसलिए उसने उससे बचा।
    modem rack status page देखने पर connected users के साथ एक Ringing status दिखता था, जैसे कोई phone call अभी उठाई नहीं गई हो, और उसने पूरी तरह बिना पकड़े गए 1 साल से ज़्यादा समय तक 128Kbit ISDN service इस्तेमाल की।
    ज़ाहिर है, ऐसी हरकत करने की सलाह नहीं दूँगा। खासकर आजकल, जब CFAA की व्याख्या कभी-कभी URL parameter बदलने या carpet पर नाक की मैल उछालने जैसी चीज़ों तक को शामिल करने के अंदाज़ में भी की जाती है।

    • CFAA के बारे में कोई आधार/स्रोत है क्या, यह जानना चाहूँगा। उल्टा, URL parameter बदलना शायद समस्या न हो, ऐसा लगता था।
      New Jersey कानून के तहत “unauthorized access या authorized access से आगे जाना” साबित करने के लिए सरकार को यह सिद्ध करना था कि code या password-based barrier को bypass किया गया था, और उस मामले में बात यह थी कि उन्होंने सिर्फ एक public login screen के हिस्से तक access किया और AT&T द्वारा अनजाने में public की गई जानकारी scrape की।
      https://law.justia.com/cases/federal/appellate-courts/ca3/13...
    • यह मुझे थोड़ा उस समय की याद दिलाता है जब Warcraft II LAN game में दो भाई computer के खिलाफ co-op खेल रहे थे, और मैंने अपना नाम Computer कर के चुपके से join कर लिया था।
    • पिछली नौकरी में मैं कई महीनों तक चुपचाप इंतज़ार करता रहा कि Slack से मेरा account remove कर दें। लगभग 1 साल बाद भी कई internal channels में मेरे पास पूरा access बचा था, जो वाकई अजीब था।
      वहाँ अच्छे दोस्त ज़रूर थे, लेकिन यह किसी goodwill में छोड़ा गया access नहीं था; वजह यह थी कि Slack account management और Google Office integration बिल्कुल अस्त-व्यस्त थे।
    • CFAA और नाक की मैल वाली बात की क्या कहानी है, समझ नहीं आया। search करने पर भी कोई reference material नहीं मिला।

  • 2016 के आसपास एक consulting company में वह शानदार दिन याद आता है जब हमने पता लगाया कि हम एक-दूसरे के Slack नाम बदल सकते हैं। एक समय पर सबका नाम बस dad था।

    • यह बहुत वैसा ही सुनाई देता है जैसे जब बच्चों को पता चलता है कि Netflix/Disney+ profile के नाम और photos कोई भी बदल सकता है।
    • अच्छा है, लेकिन मैं grandad पर अड़ा रहूँगा। नहीं तो अपनी पोतियों को खुला छोड़ दूँगा, और वे बेरहम हैं।
    • क्या यह अभी भी संभव है?
      हमारी university frisbee team Slack इस्तेमाल करती है।

  • नाम बदलने को रोकने के तरीके बहुत लोग सुझाते हैं, लेकिन उससे समस्या पूरी तरह हल नहीं होती। किसी का असली नाम Jira भी हो सकता है
    जिस $company में मैं पहले काम करता था, वहाँ customer dashboard को wildcard-आधारित https://*.$company.com पर रखा गया था। जैसे https://foo.$company.com
    लेकिन अगर कोई www या blog जैसे किसी असली record से टकराने वाला dashboard slug चुन लेता, तो वह dashboard पूरी तरह inaccessible हो जाता। prefix बदलने की setting भी https://$dashboard.$company.com पर ही होती, इसलिए customer खुद इसे ठीक नहीं कर सकता था और support team की जरूरत पड़ती। जाहिर है, support tool भी $dashboard prefix को सीधे बदलने की सुविधा expose नहीं करता था
    blocklist कैसे बनाई जाए, यह भी मामूली बात नहीं है। existing DNS entries, पहले से मौजूद $dashboard prefixes, गालियाँ, Unicode symbols, Punycode का xn-- prefix, पुराने prefix redirects और भविष्य में कब्जा रोकने के लिए reservations तक चाहिए होते हैं
    Slack में ऐसा hole होना चौंकाने वाला नहीं है। यह मूल रूप से कठिन समस्या है

    • Zendesk customer dashboards को अपने main domain के सीधे subdomain पर रखता है। custom domains भी allow करता है, और इस्तेमाल करने के लिए उसे Zendesk द्वारा दिए गए subdomain की ओर point करने वाला CNAME बनाना पड़ता है
      https://support.zendesk.com/hc/en-us/articles/4408838571930-...
      मुझे लगता है कि GitHub या Shopify की तरह customer pages के लिए subdomains कम-से-कम अलग domain पर रखना बेहतर है। GitHub अपने domain के लिए GitHub.com और user pages domain के लिए GitHub.io इस्तेमाल करता है, और Shopify भी Shopify.com और myshopify.com को अलग रखता है
      customer के लिए अलग domain का फायदा यह है कि company जिन existing और future subdomains को खुद इस्तेमाल करना चाहती है, उनसे टकराव कम होता है, और संभावित समस्याओं से बचने के लिए उस domain को Public Suffix List में डाला जा सकता है। फिर भी अपमानजनक या भ्रम पैदा करने वाले शब्दों को filter करना पड़ेगा
      https://publicsuffix.org/
    • spouse के workplace में सचमुच Admin नाम का एक employee है। IT यह समझने में परेशान है कि इसे कैसे handle करे
    • क्या यहाँ सच में Slack का बचाव किया जा रहा है? o और о संभव homograph character attacks में लगभग सबसे आसान किस्म में आते हैं
      https://en.wikipedia.org/wiki/IDN_homograph_attack
      बात यह है कि नौकरी छोड़ते समय McKay ने profile photo को ज्यादा गुस्से वाले Slackbot icon जैसा बदल दिया और नाम Slackbot कर लिया; Slack Slackbot नाम पहले से इस्तेमाल होने के कारण रोकता है, लेकिन o को Unicode character о से बदलने पर यह काम कर गया
      यह English/Cyrillic character pair 2001 में प्रकाशित शुरुआती homograph glyph attacks में से एक में भी पहले ही इस्तेमाल हुआ था
      https://web.archive.org/web/20200102175251/http://www.cs.tec...
      2022 में Slack की valuation लगभग 20 अरब डॉलर थी और यह करीब 10 साल से चल रहा था। ऊपर से यह security की जरूरत रखने वाले organizations और enterprises के लिए username-आधारित software है
    • उपलब्ध characters को restrict कर दें, और change allow करने से पहले सीधे check कर लें कि वह page पहले से resolve होता है या नहीं। इससे customer lock नहीं होगा और characters के जरिए किसी और की नकल करना भी मुश्किल होगा
      अगर कुछ symbols allow करना चाहते हैं, तो allowlist इस्तेमाल करें, या check करें कि username slackbot जैसे core names से पर्याप्त Levenshtein distance रखता है या नहीं, और फिर उसे ban कर दें या human review के लिए flag कर दें
      सब कुछ रोकना मूल रूप से कठिन है, लेकिन सबसे बड़ी समस्याओं को रोकना कठिन नहीं है
    • इस case में “मूल रूप से अलग namespaces को टकराने से बचाओ” कोई इतनी कठिन समस्या नहीं है

  • छिपने की सबसे अच्छी जगह किसी ऐसे service account जैसा दिखना है जिसे disable करने पर क्या टूटेगा, यह न पता होने के कारण हर कोई छूने से डरता हो। बढ़िया किया

    • इसके उलट, हमारे workplace के एक जरूरत से ज्यादा उत्साही IT person ने Jira automation account delete कर दिया था। उसे नहीं पता था कि वह account क्यों है, और $CompanySecretary नाम suspicious लग रहा था
      कुछ दिन बाद, कुछ बहुत जरूरी चीज टूटने से पहले उस user को reference करने वाले सारे workflows और tickets ढूंढकर ठीक करने में बहुत मेहनत करनी पड़ी
    • मशहूर malware और उनके process names याद आ जाते हैं

  • “बेशक हर company इस prank में नहीं फंसेगी”, लेकिन अंत में company भी हंस सकती है: https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act

    • इसलिए point यह है कि उसने 2 साल इंतजार करके बताया। यह ठीक CFAA statute of limitations से मेल खाता है
    • “हल्का-फुल्का prank” phrase देखकर मेरा पहला ख्याल यही था
    • अंत में हंसने वाला Slack भी हो सकता है। आखिर “sensitive business data” का काफी हिस्सा उसके हाथ लग जाता है

  • ASCII अक्षरों को मिलते-जुलते दिखने वाले Unicode characters से बदलना पुरानी तरकीब है। ऐसे characters काफी हैं, और इन्हें code में डालकर साथी developers को चौंकाने के लिए इस्तेमाल किया जा सकता है। 1 अप्रैल भी करीब आ रही है
    ऐसे “खतरनाक” characters को highlight करने वाला Vim plugin भी बनाया था: https://github.com/vim-utils/vim-troll-stopper
    Unicode characters से कभी prank नहीं हुआ, लेकिन एक जापानी consultant ने translation file में अनजाने में “Japanese-style space” character डाल दिया था, जिससे app टूट गई थी। मैंने Vim plugin हमेशा चालू रखा था, इसलिए वजह जल्दी समझ आ गई

    • कई apps ने कृपा करके दो hyphens को देखने में बेहतर Unicode long dash में बदलना शुरू कर दिया, और उसी वजह से command-line tools टूट गए
    • यह याद है: https://news.ycombinator.com/item?id=10438363
    • गलती से आए बेकार characters भी बहुत दूर तक जा सकते हैं। medical report में किसी ने superscript O को degree symbol की तरह इस्तेमाल किया था, यह याद आता है
      बाद में वह non-superscript character में convert हो गया, जिससे अर्थ काफी बदल गया। और भी खराब बात यह थी कि उस symbol की कोशिश के बाद degrees शब्द भी साथ में लिखा था

  • अगर Slack नाम बदलने पर lock लगाने की अनुमति नहीं देता, तो बड़ी कंपनियों के लिए यह बहुत बड़ा security hole लगता है
    नाम CEO पर बदल दें और profile image भी वैसी ही कर दें, तो बहुत देर होने तक फर्क पहचानने की संभावना बेहद कम है। Slackbot में बदलना तो छोटी बात लगता है

    • नाम बदलना lock किया जा सकता है। मैं Enterprise Grid org में हूँ, जहाँ display name और username employee profile के साथ sync होते हैं
      desktop app चलाते समय हर बार SSO भी अनिवार्य है, इसलिए अगर कोई कंपनी छोड़ दे तो वह कभी वापस नहीं आ सकता। account भी बहुत जल्दी deactivate कर दिया जाता है, इसलिए mobile भी शायद बड़ी चिंता नहीं है
      ticket डाले बिना जो चीजें बदली जा सकती हैं, वे असल में photo और कुछ खास महत्वपूर्ण न होने वाले free-input fields ही हैं
    • यह org settings में संभव है। नीचे वाली SAML/SSO वाली बात भी इसी तरह है। अगर नाम बदला जा सकता है, तो यह लगभग IT admin न होने या उसके आलसी होने जैसा है
    • बड़ी कंपनियाँ SAML या अन्य federated authentication इस्तेमाल करती हैं ताकि company authentication के बिना login न किया जा सके
    • साथ ही, नाम बदलने की सुविधा सच में बहुत बड़ा वरदान भी है
      हम display name में सीधे availability information डालकर इसका दुरुपयोग कर रहे हैं। जैसे mike-2/12~16vac. लिखते हैं, ताकि संपर्क करने वाला response time का अंदाजा लगा सके, या scheduled vacation से कुछ दिन पहले काम सौंपना ठीक होगा या नहीं, यह जान सके
      actual status property को कोई देखता नहीं लगता था, और calendar में जाकर check करने से बेहतर है
    • मुझे लगता है शायद यही उन कारणों में से एक है जिनकी वजह से हमारी कंपनी ने हाल ही में video conferencing system में लोगों की नाम बदलने की सुविधा हटा दी

  • जिन screenshots में लोग उसे reply कर रहे हैं, उन्हें देखें तो साफ है कि वे जानते हैं कि वह Slackbot नहीं है, और उसे Tom भी कहते हैं। इसलिए यह title से थोड़ा विरोधाभासी है। वह स्पष्ट रूप से “पकड़ा नहीं गया” वाली स्थिति में नहीं था
    हमारे Slack में भी पूर्व कर्मचारी अभी तक मौजूद हैं। वे कभी-कभी आकर hello कहते हैं, और यह अच्छा लगता है। अगर उनमें से कोई एक दिन व्यंग्यपूर्ण Slackbot की नकल शुरू कर दे, तो शायद हम भी हंसकर छोड़ देंगे

    • यहाँ मतलब “management द्वारा नहीं पकड़ा गया” है। article में भी यह साफ लिखा है। दोस्तों को पता था कि वह मौजूद है और वे साथ में हंस रहे थे
    • हमारे यहाँ भी कुछ ऐसा ही है। Slack मुख्य communication channel नहीं था, लेकिन external consultants के लिए इस्तेमाल होता था, और कंपनी छोड़ चुके लोग निकाले बिना ही lunch plans बनाते रहे

  • जहाँ मैं पहले काम करता था, वहाँ Slack account deactivation धीमा था। इसलिए छोड़ते समय मैंने #daves_cave नाम का private channel बनाया और दोस्तों को invite किया
    कभी-कभी छोटी कहानी या witty line छोड़ता था, और management को पता चलकर मेरा account deactivate करने तक यह मजेदार रहा

    • मेरे पास personal paid Slack team है, शायद लगभग $10/month था। दूसरे paid Slack teams के लोगों को room में invite करके बात कर सकते हैं
      इस तरीके की अच्छी बात यह है कि यह “intended design” है, इसलिए बंद होने की संभावना कम है, और computer misuse से जुड़े कानूनों में फंसने की संभावना भी कम है

  • कंपनी में शायद इस समस्या का जवाब single sign-on माना गया होगा
    आजकल मैं IT नहीं चलाता, लेकिन जब चलाता था, तो Azure Active Directory में कंपनी छोड़ने वालों को inactive mark करता था। फिर वे Office 365, Outlook, Teams आदि किसी भी service में login नहीं कर सकते थे, और MS SSO इस्तेमाल करने वाली third-party services में भी नहीं जा सकते थे। Slack को भी उसी से जोड़ना सही नहीं है क्या?

    • सक्षम या पर्याप्त staff वाले IT department तो जाहिर है ऐसा ही करते हैं। हालांकि यह भी संभव है कि किसी दूसरे department ने IT से सलाह लिए बिना Slack set up कर दिया हो