Slack AI में indirect prompt injection के जरिए data leak

 (substack.com/promptarmor)
1 पॉइंट द्वारा GN⁺ 2024-08-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Slack AI जब workspace messages को natural language queries से search करता है, तो वह indirect prompt injection का पालन कर सकता है, जिससे attacker ऐसे private channel data तक भी leak करा सकता है जिसकी उसे access permission नहीं है
  • समस्या की जड़ यह है कि LLM developer के system prompt और search results के रूप में जोड़े गए messages के अंदर मौजूद instructions के बीच भरोसेमंद तरीके से फर्क नहीं कर पाता
  • Public channel messages को user के channel में शामिल न होने पर भी search और view किया जा सकता है, इसलिए attacker अपने अकेले वाले public channel में malicious instructions डालकर उन्हें Slack AI की context window में ला सकता है
  • Demo में private channel की API key Slack AI के answer में Markdown link के HTTP parameter में चली गई, और source citation attacker channel की ओर इशारा नहीं कर रहा था, जिससे trace करना मुश्किल था
  • 14 अगस्त 2024 से Slack AI ने channels और DMs की files को भी answers में शामिल करना शुरू किया, जिससे attack surface बढ़ गया; admins file collection settings को restrict कर सकते हैं

Slack AI की indirect prompt injection समस्या

  • Slack AI एक feature है जिससे Slack messages पर natural language में queries की जा सकती हैं, और 14 अगस्त 2024 से पहले यह केवल messages collect करता था
  • 14 अगस्त 2024 से uploaded documents और Google Drive files आदि भी Slack AI answers में शामिल होने लगीं, और इस बदलाव से attack surface बढ़ गया
  • Vulnerability prompt injection है, और ज्यादा specific तौर पर indirect prompt injection में आती है
  • LLM developer द्वारा बनाए गए system prompt और user query के साथ जोड़े जाने वाले दूसरे context के बीच फर्क नहीं कर सकता
    • अगर Slack AI message के अंदर मौजूद instructions collect करता है, तो instructions malicious होने पर वह user query के बजाय या user query के साथ-साथ attacker के instructions follow कर सकता है
  • Slack insider threats पहले भी Disney, Uber, EA, Twitter जैसे Slack leak cases में समस्या बन चुके हैं, और यह vulnerability attacker को private channel या उसके data तक direct access के बिना भी leak की कोशिश करने देती है

Public channel injection के जरिए data leak chain

  • Slack AI की user queries public channels और private channels के data को साथ में search कर सकती हैं
  • Slack के response के अनुसार, public channel में posted messages को workspace के सभी members search और view कर सकते हैं, भले ही user उस channel में शामिल न हो; Slack AI application में यह intended behavior है
  • Demo किया गया attack flow इस प्रकार है
    • User किसी ऐसे private channel में जहां सिर्फ वही है, या खुद के साथ message में API key डालता है
    • Attacker एक ऐसा public channel बनाता है जहां सिर्फ वही है, और malicious instructions post करता है
    • User जब Slack AI से API key के बारे में query पूछता है, तो user message और attacker message एक ही context window में आ जाते हैं
    • Slack AI attacker के instructions follow करके “click here to reauthenticate” नाम का Markdown link generate करता है
    • Link के HTTP parameter में private API key शामिल होती है, और user के click करने पर malicious URL का owner attacker logs में value देख सकता है
  • Attacker का public channel, भले ही उसका member सिर्फ attacker 1 व्यक्ति हो, फिर भी public channel है, और दूसरे users को यह तभी दिखता है जब वे explicitly search करें
  • बड़ी organizations में public channels की भरमार की वजह से team members के लिए अपने joined channels को भी track करना मुश्किल होता है, और attacker द्वारा बनाया गया one-person public channel और भी कम नज़र आता है
  • यह attack user को सीधे “API key भेजो” वाला message भेजने का तरीका नहीं है, बल्कि LLM को ये काम करने का निर्देश देता है
    • ऐसी API key को malicious link के HTTP parameter में जोड़ना जिस तक attacker की access नहीं है
    • उसे “click here to reauthenticate” text वाले Markdown link के रूप में render करना

Source citations attack traces को छिपा सकते हैं

  • Data leak demo में Slack AI का source citation [1] attacker channel की ओर नहीं, बल्कि केवल उस private channel की ओर इशारा कर रहा था जहां user ने API key डाली थी
  • सही source behavior में answer में योगदान देने वाले सभी messages cite होने चाहिए, लेकिन demo में attacker message source में शामिल नहीं था
  • Attacker message search results के first page में भी शामिल नहीं था, इसलिए victim को कई pages नीचे scroll किए बिना वह message notice करना मुश्किल था
  • Search results में API key से जुड़े दूसरे messages भी expose हुए, जिससे दिखता है कि attacker किसी specific secret value को exact तरीके से refer किए बिना भी किसी भी secret value को leak कराने की कोशिश कर सकता है

Public channel injection के जरिए phishing chain

  • इसी तरीके से Slack AI को data leak के बजाय user के लिए Markdown में phishing link render करने पर मजबूर किया जा सकता है
  • Attacker ने user के शामिल न होने वाले public channel में malicious message डालने और किसी specific user के दिनभर के messages summarize करने की situation को example बनाया
  • Malicious message किसी भी व्यक्ति को refer कर सकता है
    • Example की तरह admin को refer करने पर इसे executives के खिलाफ spear phishing में इस्तेमाल किया जा सकता है
    • किसी key direct report को refer करने का तरीका भी संभव है
  • जब user उस व्यक्ति के messages के बारे में Slack AI से query करता है, तो “click here to reauthenticate” phishing link render हो जाता है
  • इस phishing case में Slack AI ने injected message को source में दिखाया, और source citation behavior काफी probabilistic लगता है

14 अगस्त का file collection बदलाव और disclosure की जरूरत

  • 14 अगस्त 2024 को Slack AI ने channels और DMs की files को Slack AI answers में शामिल करने वाला बदलाव introduce किया
  • Slack ने owners और admins को इस feature को restrict करने की सुविधा दी
  • Files शामिल होने पर attacker को Slack messages में malicious instructions सीधे post करने की जरूरत नहीं भी पड़ सकती
    • अगर user white text में छिपे malicious instructions वाला PDF download करके Slack पर upload करता है, तो वही follow-up effect हो सकता है
  • File-based attack को 14 अगस्त से पहले की testing में explicitly verify नहीं किया गया था, लेकिन पहले observe की गई functionality के आधार पर इसकी संभावना अधिक मानी गई
  • समस्या हल होने तक admins Slack AI के document collection feature को restrict कर सकते हैं: https://slack.com/help/articles/…

Responsible disclosure timeline और Slack का response

  • Responsible disclosure timeline इस प्रकार है
    • 14 अगस्त: पहली report
    • 15 अगस्त: Slack ने additional information मांगी
    • 15 अगस्त: PromptArmor ने extra videos और screenshots भेजे, और issue की severity व Slack AI के 14 अगस्त वाले बदलाव के कारण disclosure intent बताया
    • 16 अगस्त: Slack ने additional questions भेजे
    • 16 अगस्त: PromptArmor ने clarification answers भेजे
    • 19 अगस्त: Slack ने review के बाद माना कि evidence sufficient नहीं है, और जवाब दिया कि public channel messages को channel membership से अलग workspace members द्वारा search और view किया जा पाना intended behavior है
  • Slack security team ने तेजी से response दिया और issue को समझने की कोशिश करती दिखी
  • Prompt injection एक नया और industry-wide काफी misunderstood area है, इसलिए industry को इसे साथ मिलकर समझने में समय लग सकता है
  • Slack के व्यापक usage और Slack के अंदर मौजूद confidential data के scale को देखते हुए, यह attack AI security posture पर वास्तविक impact डालता है
  • खासकर 14 अगस्त के बदलाव के बाद risk surface काफी बढ़ गया, इसलिए users को exposure कम करने का मौका देने के लिए disclosure जरूरी था

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

1 टिप्पणियां

 
GN⁺ 2024-08-21
Hacker News की राय

  • यहाँ असली बात लीक होने के रास्ते को समझना है
    Slack Markdown लिंक render कर सकता है, और URL लिंक टेक्स्ट के पीछे छिप जाता है
    इस मामले में हमलावर Slack AI से यूज़र को “री-ऑथेंटिकेट करने के लिए यहाँ क्लिक करें” जैसा लिंक दिखवा सकता है, और उस लिंक का URL हमलावर के सर्वर की ओर इशारा करता है, जिसमें query string में Slack AI द्वारा access किए जा सकने वाले context की निजी जानकारी शामिल होती है
    अगर यूज़र धोखे में आकर लिंक क्लिक कर देता है, तो डेटा हमलावर के server logs में लीक हो जाता है
    इस हमले को समझाने वाला पोस्ट यहाँ है: https://simonwillison.net/2024/Aug/20/data-exfiltration-from...

    • Slack, Discord, Teams, Telegram जैसे bots में असल में link preview unfurling नाम का एक और leak path होता है
      हमलावर को बस hyperlink render करवाना होता है, क्लिक की भी जरूरत नहीं
      इस समस्या और mitigation methods पर यहाँ चर्चा की गई है: https://embracethered.com/blog/posts/2024/the-dangers-of-unf...
      इसलिए उम्मीद है कि Slack AI links को automatically unfurl नहीं करता होगा
    • अगर platform img tag या उसके बराबर किसी चीज़ को बिना सोचे-समझे render करता है, तो मामला और खराब हो जाता है
      तब user interaction के बिना भी, UI में image दिखाने भर से data exfiltration संभव हो जाता है
    • असल में समझने वाली मुख्य बात यह है कि user data चोरी हो जाने पर भी कोई meaningful accountability नहीं होती
      अब हर बड़ी tech company के पास गलती करने पर भी practically अजेय माफी-पत्र है
    • शुरू में जिसे समझने में समय लगा, वह यह था कि Slack में जब यूज़र search करता है या AI उसकी जगह search करता है, तो search scope सभी public channels और “केवल उस user को access वाले private channels” होते हैं
      permission model खुद वैसा ही है, और यहाँ टूटा हुआ हिस्सा वह नहीं है
      असल में malicious user public channel का इस्तेमाल करके prompt injection करता है, और जब दूसरा user search करता है तो malicious user अब भी उस data तक access नहीं कर पाता, लेकिन prompt injection मूल “normal” user को दिखने वाले AI result को malicious website link में बदल देता है
      आखिरकार यह AI द्वारा बनाए गए phishing attempt जैसा है
      details देखें तो असल दुनिया में इसका दुरुपयोग करना काफी कठिन लगता है, क्योंकि पहले से तैयार malicious prompt injection को normal user द्वारा search की जाने वाली चीज़ से काफी अच्छी तरह match करना होगा
      फिर भी यह LLM prompt injection की Alice in Wonderland जैसी दुनिया को अच्छी तरह दिखाता है—यानी commands और data को अलग करना स्वाभाविक रूप से लगभग असंभव है
    • पहली wording देखकर ऐसा लगता है कि attacker AI को धोखा देकर दूसरे user के private channel data को उजागर करवा सकता है, लेकिन असल में ऐसा नहीं है
      इसके बजाय संरचना यह है कि AI को धोखा देकर वह दूसरे user को phishing कराता है, और अगर वह user phishing में फंस जाता है तो private data attacker के सामने उजागर हो जाता है
      यह भी active phishing से ज्यादा “phishing response” जैसा है। target user से उम्मीद करनी पड़ती है कि वह अपने private data के बारे में पूछे, और phishing attempt में भी फंस जाए
      ऊपर से वह secret information पहले से दर्ज होनी चाहिए
      Slack के पास मौजूद trust data की मात्रा देखते हुए AI strategy काफी reckless लगती है, लेकिन intro और title से जितना लगता है, उससे कहीं ज्यादा कमजोर preconditions पर यह निर्भर दिखती है

  • channel permissions की बात discussion को जरूरत से ज्यादा जटिल बना रही है। मुद्दा यह है
    user A Slack AI से कुछ search करता है
    user B ने पहले से एक message inject कर रखा है जो AI को निर्देश देता है कि वह उस search term के आने पर malicious link लौटाए
    AI user A को malicious link लौटाता है, और A उसे click करता है
    जाहिर है, दूसरे social engineering रास्तों से भी वही result मिल सकता था, लेकिन LLM इस पूरे experience को एक कदम और खतरनाक बना देता है

    • इस summary में एक महत्वपूर्ण step छूट गया है। Slack AI user का private data malicious link में जोड़ देता है
      क्योंकि injected link में खुद वह data शामिल नहीं होता
      ऊपर से यह भी जोड़ देता है कि “यह सामग्री आपके Slack messages से आई है”, source attribution के तौर पर
    • channel permissions की बात बिल्कुल गैर-जरूरी नहीं है, क्योंकि यह बताती है कि यह vulnerability काम कैसे करती है
      जब user A AI search करता है, Slack (1) उसके private channels, जहाँ शायद secret sensitive information हो, और (2) सभी public channels search करता है
      यहाँ bad user B जिस जगह prompt injection message डाल सकता है वह public channel है, और अहम बात यह है कि इसमें वे public channels भी शामिल हैं जिनमें user A कभी शामिल नहीं हुआ या जिन्हें उसने कभी देखा भी नहीं
      यह vulnerability इसलिए काम करती है क्योंकि user B ऐसा public channel बना सकता है जिसमें सिर्फ वही हो, इसलिए दूसरे लोगों द्वारा उसके discover होने की संभावना बहुत कम होती है
    • social engineering फिर भी कंपनी द्वारा approved search engine द्वारा malicious link दिखाए जाने की तुलना में कहीं ज्यादा आसानी से पहचानी जा सकती है

  • क्या कंपनियां यह जानते हुए भी कि prompt injection संभव है, बस YOLO अंदाज़ में LLM को हर चीज़ में ठूंस रही हैं? यह पागलपन है
    “क्रांति” आने ही वाली है कहते-कहते GPT-3 के बाद लगभग 2 साल बीत चुके हैं, फिर भी हम LLM को trusted input और untrusted input में फर्क करना नहीं सिखा पाए हैं

    • अभी भी कंपनियों को असली सुरक्षा की चिंता करवाना मुश्किल है, और अब दुनिया भर के marketing/sales विभाग executives को यह बेच रहे हैं कि “इसे इस्तेमाल करो तो सबको निकाल सकते हो”
      अगर electric socket में कांटा घुसाने को भी इसी तरह बेचा गया होता, तो दुनिया भर की power grids एक रात में बैठ गई होतीं
      “AI”/LLM इतना अच्छा दिखता है कि business side का ध्यान खींच ले, और असली technology side के लिए विशाल समस्या बन जाए — यह तबाही का परफेक्ट कॉम्बिनेशन है
    • यह काफी अजीब है कि बहुत-से लोग मानना चाहते हैं कि “कोई शानदार नई जादुई चीज़ बस आने ही वाली है”, और इसमें असली पैसा लगा है कि सब लोग इसे पक्का मानकर ही व्यवहार करते रहें
      ज्यादा मूल समस्या यह है कि core algorithm अलग-अलग sources में फर्क या tracking तक नहीं कर पाता
      prompt, user input, बातचीत के पहले हिस्से में खुद द्वारा generate किया गया output — सब बस एक बड़ा flow है
      “prompt engineering” का बड़ा हिस्सा ऐसा लगता है जैसे मेरी injection phrase को दूसरी injection phrases से ज्यादा ताकतवर मंच दिलाने की कोशिश हो
      model में self/other की कोई वास्तविक अवधारणा नहीं है, इसलिए अच्छे other और बुरे other में फर्क करने की बड़ी समस्या तो दूर, सच्चे वाक्य और झूठे वाक्य में फर्क करने की शुरुआत भी ढंग से नहीं होती
      यह सतही “Chinese room” वाली नकल से अलग समस्या है। उसी तरह “I love you” output का मतलब भावनाएं नहीं होता, और “Help me, I’m a human trapped in an LLM factory” भी जाहिर तौर पर बकवास है। कम से कम अगर आप local model चला रहे हैं तो
    • कंपनियां और सरकारें, दोनों अपना data और हमारा data AWS, OpenAI, MSFT, Google, Meta, Salesforce, nVidia के datacenters में भेजने की होड़ में हैं
    • AI का उन्माद investor class के लिए numbers बनाने के मकसद से बड़े पैमाने पर data चुराने या उसका दुरुपयोग करने पर आधारित है
      customer data और proprietary information ठूंसकर data breach कराओ, तो Schmidt के कहे मुताबिक कुछ लोगों को सैकड़ों अरब डॉलर मिलेंगे और lawyers बाद में सफाई कर देंगे
      जो company टिकने की कोशिश करेगी, वह उन investment analysts और fund managers के नीचे दब जाएगी जिनकी financials AI कचरे पर निर्भर हैं

  • “पीड़ित public channel में न हो तब भी attack काम करता है” — यह तो दिलचस्प होने वाला है
    और यह हिस्सा भी है कि “source [1] attacker के channel की ओर इशारा नहीं करता, सिर्फ उस private channel की ओर इशारा करता है जहां user ने API key डाली थी। यह सही citation behavior का उल्लंघन करता है कि answer में योगदान देने वाले सभी messages cite होने चाहिए”
    मुझे सच में समझ नहीं आता कि कोई LLM की source citation के सही होने की उम्मीद क्यों करेगा
    यह हमेशा इंसानों को भरोसा दिलाने वाली device जैसी लगी, जो बस यह विश्वास बढ़ाती है कि output ज्यादा सही होगा, accuracy सुधारती नहीं
    उल्टा processing cost, context size वगैरह बढ़ाकर response accuracy को खराब करने की संभावना भी लगती है
    यह Slack द्वारा AI response में मेहरबानी से link expansion जोड़ने से बस कुछ इंच दूर लगता है। क्यों नहीं करेंगे?
    तब link पर click करने की जरूरत भी नहीं होगी; सिर्फ देखने भर से अपने-आप leak हो जाएगा

    • मुझे लगता है citations उपयोगी हैं, क्योंकि उनसे check किया जा सकता है कि LLM ने बस hallucinate तो नहीं किया
      citation दिखते ही भरोसा कर लेना बात नहीं है, अहम बात यह है कि fact-check किया जा सकता है
      Kagi का FastGPT उन LLMs में पहला था जो मुझे पसंद आया, क्योंकि उसे source summary की तरह लेकर primary sources में verify किया जा सकता है
      यह internet को contaminate कर रहे लगातार कम relevant sources खंगालने से बेहतर है
    • LLM citations को सही तरह से काम करवाना संभव है। उदाहरण के लिए user का prompt लेकर LLM से उसे Elastic Search query में बदलवाएं, फिर Elastic Search या मिलते-जुलते tool से keywords वाले sources खोजें, उसके बाद LLM को उस page की information तक answer सीमित करने को कहें, और दूसरे चरण के results के आधार पर citations डालें जिन्हें हम real sources जानते हैं
      कम से कम अगर मैं naive design करता तो शायद ऐसा ही करता
      key point यह है कि LLM के knowledge को sources के भीतर की information तक सीमित किया जाए
      तब बची हुई वास्तविक चिंताएं hallucination और Elastic Search द्वारा ऊपर लाई गई information की value भर हैं
      हालांकि यह approach पूरे corpus तक freely access देने पर मिलने वाले फायदे, अगर कोई हों, उन्हें भी नजरअंदाज करती है

  • यह मुझे ठीक से समझ नहीं आ रहा। hacker को ऐसा करने के लिए शुरू से उस organization के अंदर होना जरूरी नहीं होगा क्या?
    वर्णित चीज़ के सच में होने और meaningful impact देने की probability कितनी है, समझ नहीं आता
    मुझे पता है कि LLM भरोसेमंद नहीं हैं(https://www.lycee.ai/blog/ai-reliability-challenge) और इस्तेमाल में दिक्कतें हैं, लेकिन यह attack इतना important नहीं लगता
    मैं क्या miss कर रहा हूं?

    • Slack AI अब uploaded documents को भी search feature में शामिल करने लगा है, इसलिए hacker को chat message पोस्ट करने में सक्षम होना भी जरूरी नहीं
      बस organization के किसी व्यक्ति को धोखे से ऐसा document upload करवाना होगा जिसमें hidden text में malicious instructions हों
    • उसी Slack workspace में होना पड़ेगा, लेकिन जरूरी नहीं कि उसी organization का member हो

  • अगर आपने malicious user को Slack instance में आने दिया है, तो fancy AI prompt injection की जरूरत नहीं है
    नाम और profile photo CEO/CTO जैसी बदलें और सभी engineers को message भेजें: “AWS तक urgent access चाहिए, credentials नहीं मिल रहे। क्या key भेज सकते हो?”
    मैं guarantee दे सकता हूं कि कम से कम एक व्यक्ति फंस जाएगा

    • बात सही है, लेकिन यह ध्यान रखना चाहिए कि open source projects या networking/peer groups के Slack workspaces जैसी कई जगहें company accounts नहीं होतीं
      ऐसे मामलों में वे default रूप से उन्हें private credentials के लिए trust नहीं करते
      हालांकि non-enterprise workspace के AI add-on के लिए प्रति व्यक्ति $20/month देने की संभावना भी कम ही है

  • “confetti” की तरह API key को domain name के हिस्से के रूप में रखना बेहतर नहीं होगा?
    तब browser के DNS prefetch की वजह से click किए बिना भी key leak हो सकती है

    • अगर आपको पहले से नहीं पता कि domain क्या होगा, तो server को own कैसे करेंगे? हो सकता है मैं गलत समझ रहा हूं
      आह, wildcard subdomain? अगर Slack में वह prefetch होता है तो यह काफी भयानक है

  • क्या वर्कस्पेस में किसी दुर्भावनापूर्ण यूज़र के आते ही खेल खत्म नहीं हो जाता?
    वह यूज़र फोटो/नाम बदलकर सीधे API key मांग सकता है, phishing link भेज सकता है, या किसी भी instant messaging system में संभव social engineering को जी भरकर आज़मा सकता है

    • कई SaaS कंपनियों के public Slack मौजूद हैं
      phishing को गंभीर यूज़र पहचान सकते हैं, खासकर जब संदेश संदिग्ध लगे, लेकिन indirect AI leak यूज़र को defensive mode में नहीं डालता
      एक आकस्मिक क्लिक ही काफी है

  • मैं पहले यह मानता हूँ कि यह security के लिहाज़ से कमजोर है। लेकिन लगता है कि इस leak के काम करने के लिए Slack workspace access की जरूरत है
    दूसरे शब्दों में, malicious user पहले से ही अंदर सक्रिय है
    ऐसा होने के दो मामले दिखते हैं। या तो वह पहले से संगठन का सदस्य है और सब कुछ जला देना चाहता है, या उसने संगठन के security model को तोड़कर उस Slack workspace में प्रवेश कर लिया है जहाँ उसे होना ही नहीं चाहिए था
    किसी भी स्थिति में, उस संगठन के पास LLM injection से बड़ी समस्या है
    confidential data ढूँढ़ने के लिए Slack से query करने वाले व्यक्ति को मिलने वाले results का कुछ हद तक जोखिम खुद स्वीकार करना चाहिए। Slack secret management tool नहीं है
    लेख साफ़ दिखाता है कि Slack इसे बेहतर तरीके से कैसे संभाल सकता है, लेकिन अंत में यह एक समस्या को patch करते हुए बड़े security issue को नज़रअंदाज़ करने जैसा है

    • मैंने कई संगठनों को community Slack चलाते देखा है जहाँ non-employees को बातचीत के लिए invite किया जाता है, और मैं खुद भी ऐसी कुछ जगहों में शामिल हूँ

  • मुझे लगा कि लेख ने title जितना दमदार content नहीं दिखाया
    फिर भी “AI को social engineering से धोखा देकर users को phish किया जा सकता है” यह idea अपने आप में दिलचस्प है