GitLost: GitHub AI एजेंट को छलकर private repositories लीक कराना

 (noma.security)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Noma Labs ने GitHub Agentic Workflows में indirect prompt injection vulnerability GitLost खोजी, जिसमें सिर्फ public repository issue के जरिए उसी organization की private repository data को public comment में उजागर कराया जा सकता था
  • यह feature Markdown workflow को YAML Actions file में compile करता है, और Claude या GitHub Copilot-आधारित AI agent issues पढ़कर tools call करता है और organization के भीतर repositories तक पहुंचता है
  • vulnerable workflow issues.assigned event पर issue का Title और Body पढ़ता था और add-comment से जवाब देता था, जबकि उसके पास public और private repositories पढ़ने की permission थी
  • attacker को code, access permission या credentials की जरूरत नहीं थी; बस public repository में एक plausible issue खोलना था, और test में poc और testlocal के README.md contents public issue comment में post हो गए
  • GitHub के guardrails “Additionally” variant में अपेक्षा के मुताबिक रोक नहीं पाए, और agentic AI में context window को खुद attack surface मानकर user-controlled content को trusted instructions से अलग करना चाहिए

GitLost ने जिस trust boundary को निशाना बनाया

  • Noma Labs ने GitHub के नए Agentic Workflows में GitLost नाम की vulnerability खोजी
  • अगर कोई unauthenticated attacker उसी organization की public repository में crafted GitHub Issue post करता, तो agent को organization के भीतर private repositories का data लाने के लिए प्रेरित किया जा सकता था
  • attack तरीका indirect prompt injection था, जिसमें AI agent द्वारा पढ़े जाने वाले content के अंदर malicious instructions छिपाए जाते हैं
  • अगर attacker के छिपाए गए निर्देश operator के intended instructions से पहले process हो जाएं, तो private data ऐसे public issue comment में उजागर हो सकता है जिसे कोई भी देख सके

GitHub Agentic Workflows कैसे काम करता है

  • GitHub Agentic Workflows teams को repository automation natural language में लिखने देता है
  • workflow Markdown .md file में लिखा जाता है और YAML format की GitHub Actions .yml file में compile होता है
  • run होने पर Claude या GitHub Copilot-आधारित AI agent configured permissions के भीतर काम करता है
    • GitHub Issue पढ़ना
    • tools call करना
    • organization के भीतर दूसरी repositories तक पहुंचना

vulnerable workflow की conditions

  • Noma Labs द्वारा confirm की गई vulnerable configuration में problem तब होती थी जब public issues और agent permissions साथ आते थे
    • GitHub के issues.assigned event पर workflow trigger होना
    • issue का Title और Body पढ़ना
    • add-comment tool से comment post करना
    • organization के भीतर दूसरी repositories पढ़ने की permission होना
      • public repositories
      • private repositories
  • attacker को अलग से code लिखने, access permission या credentials की जरूरत नहीं थी
  • जरूरी condition सिर्फ इतनी थी कि GitHub Agentic Workflow इस्तेमाल करने वाली organization की public repository में issue खोला जाए

attack flow

  • researchers ने ऐसा plausible GitHub Issue बनाया जो customer meeting के बाद VP Sales के request जैसा दिखता था
  • issue assign होते ही workflow action trigger हुआ, और tests में दूसरे GitHub workflow action में भी यही तरीका काम करता दिखा
  • GitHub automation ने issue assign करने के बाद, event से run हुए workflow ने agent से repository contents मंगवाए
  • agent को निम्न repositories के README.md contents लाने के लिए प्रेरित किया गया
    • poc public repository
    • testlocal private repository
  • इसके बाद GitHub agent ने वह content public repository के issue comment में post कर दिया, जिससे वह किसी के भी पढ़ने योग्य हो गया

“Additionally” से guardrail bypass

  • GitHub में इस scenario को रोकने के लिए limited guardrail था
  • Noma Labs ने attacker की तरह कई variants को बार-बार test किया
  • “Additionally” keyword जोड़ने पर model ने reject नहीं किया और output को restructure करने वाला unintended behavior हुआ
  • इस bypass के कारण GitHub का guardrail अपेक्षा के मुताबिक काम नहीं कर पाया और data leak नहीं रोक सका

PoC और exposed data

agentic AI में बदलती security assumptions

  • agent की context window workspace होने के साथ-साथ attack surface भी बन जाती है
  • agent द्वारा पढ़ा जाने वाला हर content weaponize किया जा सकता है
    • issues
    • Pull Requests
    • comments
    • files
  • traditional security models अक्सर मानते हैं कि trust boundary code द्वारा enforce होती है
  • agentic systems में trust boundary का एक हिस्सा model behavior द्वारा enforce होता है
  • model स्वभावतः instructions follow करता है, इसलिए prompt injection agentic AI के लिए उसी category की vulnerability बन जाती है जैसी web applications के लिए SQL injection थी
  • इस vulnerability type के लिए systematic strategies और defenses की जरूरत है

recommended defenses और disclosure process

  • user-controlled content को AI agent के trusted instruction input की तरह treat नहीं करना चाहिए
  • agent permissions को जरूरी न्यूनतम scope तक सीमित रखना चाहिए
    • कई repositories तक access रखने वाले agents खास तौर पर high-value attack targets बन जाते हैं
  • जैसे issue content पर respond करने के case में, agent publicly क्या post कर सकता है इसे सीमित करना चाहिए
  • user input को model को भेजने से पहले instruction context से sanitize या isolate करना चाहिए
  • GitLost को GitHub को responsibly disclose किया गया, और vulnerability details GitHub की जानकारी में share की गईं

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

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की राय

  • यह तुलना अजीब लगती है कि agentic AI में prompt injection की वही जगह है जो web apps में SQL injection की थी। मुझे लगता है prompt injection LLMs के लिए SQL injection से कहीं ज़्यादा घातक है
    SQL injection तब हुआ जब user input, SQL engine को भेजी जाने वाली command string का हिस्सा बन गया, और malicious input ने मौजूदा command को SQL syntax tokens से खत्म करके अपना SQL command जोड़ दिया, तो engine ने दोनों चला दिए। इसका समाधान prepared statements जैसे fixed, static, pre-compiled command strings का इस्तेमाल करना था, और मनमाने user input को सिर्फ data की तरह लागू करना था
    agents में इसी तरह का mitigation यह होगा कि “repo 1 पढ़ो”, “repo 2 पढ़ो” जैसे fixed actions हों, और user input सिर्फ इस बात का data हो कि कौन-सा action चलाना है, लेकिन इसे तो हम पहले से menu नाम की तकनीक कहते हैं। LLM की value मूल रूप से menu से आगे होने में है, जबकि SQL की value को “मनमाने data पर लागू pre-defined logic” से आगे जाने की ज़रूरत नहीं होती

    • सही। SQL injection इसलिए हुआ क्योंकि user input को pure data नहीं बल्कि command के हिस्से की तरह treat किया गया, और दोनों को अलग कर देने पर समस्या हल हो गई। Prompt injection से बचना मुश्किल है क्योंकि user input खुद command के रूप में intended होता है
    • “समाधान prepared statements हैं” से ज़्यादा सही बात यह है कि असली बात parameter binding है। Parameters को SQL statement से अलग submit किया जाता है ताकि code और user data अलग रहें
      agents में सिर्फ restricted actions की इजाज़त देना कुछ खास तरह की समस्याएँ ही संभालता है, और यह code और user data को अलग भी नहीं करता, इसलिए यह वही समस्या नहीं है। सिर्फ limited actions रखना, ज़्यादा सख्त database permissions इस्तेमाल करने के करीब है। अगर user को वैसे भी सिर्फ वही SQL चलाने दी जाए जो वह पहले से चला सकता है, तो SQL injection भी खास मायने नहीं रखता
    • यह SQL injection जैसी ही तरह की समस्या है, लेकिन इसे हल करने की कठिनाई समान नहीं है। इसमें कहीं ज़्यादा सूक्ष्म समस्याएँ आ सकती हैं, फिर भी समझाने के लिए यह तुलना ठीक है
      menu से चुनवाना एक तरीका है, लेकिन possible actions की range इससे ज़्यादा चौड़ी design की जा सकती है। अगर आप email tool दे दें, तो वह customers को spam भेज सकता है, और अगर उसे सिर्फ reply करने तक lock कर दें, तो नुकसान की सीमा घट सकती है। image rendering के ज़रिए data leak होने जैसी vulnerabilities की तरह, data exfiltration को भी सीमित करना होगा
    • Prompt injection घातक नहीं है, और वास्तव में यह कोई असली समस्या कम, बल्कि underlying security architecture की समस्या को उजागर करने वाली चीज़ ज़्यादा है। यह इंसानों पर होने वाले social engineering attacks जैसा है
      समाधान भी वही है। least-privilege role-based access control लागू करें, और महत्वपूर्ण actions के लिए admin approval अनिवार्य करें। तब LLM अपने आप सबसे बुरा यही कर पाएगा कि कुछ अनुचित शब्द output कर दे
    • मुझे यक़ीन नहीं कि यह उतनी गहरी समस्या है जितना सब सोचते हैं। SQL injection भी उतना ही खतरनाक है, क्योंकि यह query user जितने भी database actions कर सकता है, उन सब तक अनियंत्रित पहुँच खोल देता है
      mitigation में से एक prepared statements है, लेकिन दूसरा यह है कि किसी भी user को पूरे database की पहुँच ही न दी जाए। read-only user को SQL injection हो या न हो, DROP TABLE नहीं कर पाना चाहिए
      इस agent के पास बिना सीमा वाली read access है, और इसके जवाब में “recipient” का कोई concept नहीं है। अगर recipient की permissions भी शामिल कर दी जाएँ, तो read access अपने आप deny हो जाए, ऐसा बनाना काफ़ी सरल है। यह इकलौता समाधान नहीं है, लेकिन इस दिशा के हल सोचना मुश्किल नहीं है
      “menu” वाला उदाहरण यह भी दिखाता है कि वास्तव में कुछ बदला नहीं है। चाहे LLM हो या इंसानी कर्मचारी, अनुमति सिर्फ नियंत्रित, fixed actions के set तक ही सीमित होती है। आज़ादी मुख्य रूप से अभिव्यक्ति में होती है, authorization तो fixed set पर ही आधारित होता है। मुझे नहीं समझ आता कि इसे menu से आगे क्यों होना चाहिए

  • समझ नहीं आता कि यह GitHub की vulnerability क्यों है। शोधकर्ताओं ने agent को private repository की access दी और public repository में सवालों के जवाब देने को कहा, तो जाहिर है private information exfiltration संभव होगा
    यह वैसा ही है जैसे कोई सामान्य CI job बनाई जाए जिसे secrets की access हो और उसे public PR पर चलाया जाए। अगर आप GitHub को इस तरह configure करते हैं कि public code या LLM instructions ऐसे context में run हों जहाँ sensitive चीज़ों की access हो, तो leak होगा। यह GitHub की गलती नहीं, configure करने वाले की गलती है

    • लगता है यह मान लिया गया था कि permissions सिर्फ उस repository तक सीमित होंगी जिसमें सवाल पूछा जा रहा है, private repositories तक नहीं। दोनों तरफ की दलील कुछ हद तक समझ में आती है
    • GitHub agent access को सुरक्षित तरीके से configure करना आसान नहीं बनाता। सामान्य access tokens और app credentials में private repositories तक direct access देने के लिए पर्याप्त granular control नहीं है
      token scope को बहुत सख्त रखने पर भी public repository access हमेशा allowed रहती है, और उदाहरण के लिए public repository issue के जरिए exfiltration path बचा रहता है। इसे सुरक्षित बनाना हो तो GitHub जो देता है उससे ज्यादा सख्त control लागू करने वाले MITM proxy से इसकी भरपाई करनी होगी
      GitHub Agentic workflows शायद इस तरह की समस्या के लिए आधिकारिक पहला समाधान होने चाहिए, लेकिन security model हो या safe usability, अभी काफी काम बाकी दिखता है
      विवरण: https://haulos.com/blog/do-not-give-your-agent-github-access...
    • इस तरह के prompt injection attack के मूल में agent permission scope को ठीक से सीमित न कर पाना है। इस मामले में, agent को वास्तव में क्या करना है उसके हिसाब से repository-दर-repository अलग workflow agents रखे जा सकते हैं, या फिर broader repository access वाला agent रखा जा सकता है लेकिन उसे सिर्फ allowlist वाले users से ही trigger होने दिया जाए
      यह public development के साथ भी compatible है, और बाहरी लोगों को public issues खोलने देना भी संभव रहता है, साथ ही हर user के लिए अलग trust level reflect किया जा सकता है। ठीक से सोचा जाए तो विकल्प इससे भी ज्यादा होंगे
      इसके लिए fine-grained scoping और permissions का technical support चाहिए, और agent से क्या हासिल करना है तथा उसके लिए कौन-सी minimum permissions और capabilities चाहिए, इस पर समय लगाकर विचार करना होगा
      पहला वाला शायद आ जाएगा। अभी agent use पूरी तरह wild west जैसा है। दिलचस्प यह होगा कि इंसान जब agent design करे तो scope और permissions को खोजने और define करने की friction कम करने वाली abstraction कैसी होगी, और agent capabilities सीमित करते समय granularity और usability के बीच संतुलन बनाने वाला interface कैसा होगा
      दूसरा मुद्दा तो हमेशा से high-quality software बनाने में सबसे बड़ा अवरोध रहा है। ठीक से सोचना और ठीक से implement करने में समय देना, “move fast and break things” अंदाज़ में agent को कहीं भी फेंक देने के बिल्कुल उलट है
    • क्या agentic workflow के हिसाब से access को अलग किया जा सकता है, ताकि एक sensitive data तक पहुँचे और दूसरा सिर्फ public data तक? क्या default scope अभी सिर्फ current repository तक सीमित है? क्या GitHub private repository data access और agentic workflows को जोड़ने के जोखिम के बारे में पर्याप्त चेतावनी देता है?
      अगर इनमें से किसी एक सवाल का जवाब भी “नहीं” है, तो यह समस्या है। पारंपरिक GitHub Workflows में भी PR-triggered workflows के जरिए privilege escalation की भरमार है, लेकिन वह अलग विषय है
    • permissions के नज़रिए से LLM बस एक बेवकूफ terminal है। लोग जो चाहते हैं वह prompt के आधार पर on-the-fly synthesized permissions बनाने जैसा लगता है, लेकिन यह “prepared statements” वाला समाधान नहीं बल्कि “मैं regex से user SQL को safely साफ कर दूँगा” के ज्यादा करीब है। उसका अंजाम हम पहले से जानते हैं
      असली समाधान prompt-by-prompt permission control UI को बेहतर बनाना है। जैसे “web search enabled” चुनते हैं, वैसे ही “मेरे private repositories शामिल करें” option को आसानी से on/off किया जा सके

  • यह मजेदार है कि शोधकर्ताओं ने “Additionally” जैसे सिर्फ एक शब्द से GitHub के दावे वाले guardrails bypass कर दिए। यह दिखाता है कि LLM context window के अंदर मजबूत security boundary बनाने की कोशिश आखिरकार विफल ही होगी
    मॉडल मूल रूप से instructions follow करने के लिए बनाया गया है, इसलिए system rules और user input को मिलाने पर ज्यादा नया या ज्यादा जिद्दी instruction जीत जाता है

  • “responsible disclosure” section में यह क्यों नहीं है कि इसे कब fix किया गया, GitHub ने इसे स्वीकार किया या खारिज किया? लिखा है कि GitLost को GitHub को responsible तरीके से disclose किया गया और details GitHub की जानकारी में रहते हुए साझा की जा रही हैं, तो क्या यह अभी तक fix नहीं हुआ?

    • यह सामान्य software bug नहीं है, और जैसे किसी सामान्य support कर्मचारी के झाँसे में आ जाने को “fix” नहीं किया जा सकता, वैसे ही इसे भी उसी तरीके से ठीक नहीं किया जा सकता। जवाब है LLM को untrusted input और sensitive data दोनों की एक साथ access न देना
    • मैं जानना चाहता हूँ कि क्या मूल पोस्ट के लेखक ने नीचे वाली setting enabled रखकर experiment किया था। इसे रोकने के लिए literal setting मौजूद है। मैं जानना चाहता हूँ कि क्या यह setting इसी report की वजह से आई, या reporter की लापरवाही थी कि उसने इसे comment में नहीं डाला
      https://github.github.com/gh-aw/reference/cross-repository/#...
    • यहाँ fix करने जैसा क्या है? बस LLM को private data access और public comments पढ़ने की capability एक साथ दे दी गई है। यह सिर्फ misconfiguration है

  • Microsoft जैसी बड़ी कंपनियाँ अब investor pressure की वजह से खुद को AI company बताने के लिए हर product पर AI चढ़ा रही हैं। कुछ-कुछ वैसा ही जैसा Adobe ने किया था
    consumers इस तरह के आधे-अधूरे AI integration से थक रहे हैं, और लगता है जल्द ही इसकी सीमा सामने आएगी

    • मैं तो निकल चुका हूँ। Forgejo पर चला गया। शानदार है और सब कुछ बेहतर काम करता है
      सच में, इधर-उधर क्लिक करते समय सब कुछ तुरंत होता है और runner जोड़कर CI भी बहुत खूबसूरती से चलता है। runner setup docs थोड़े और स्पष्ट हो सकते हैं, लेकिन उसके अलावा सब कुछ बेहद smooth था
    • Microsoft एक public company है। कौन-से investors GitHub को ऐसे unwanted AI features से खराब करने का दबाव डाल रहे हैं? यह किस room में हो रहा है?
    • सहमत, लेकिन enterprise AI products मुझे काफी प्रभावशाली लगते हैं। investors और consumers शायद इसे ठीक से नहीं समझते, और employees इसमें सौदा नहीं कर सकते
      revenue वास्तव में मौजूद है और प्रभावशाली है, और यह consumer तथा seat-based revenue की जगह ले रहा है। market अभी भी SaaS multiples को नीचे ला रहा है, और मुझे लगता है वह आकलन सही है। quarterly reports में revenue को अलग करके देखें तो वास्तविक efficiency से निकली बड़ी growth story दिखाई देती है

  • समझ नहीं आ रहा कि public repository context में चलने वाले action के पास private repository access क्यों था। workflow को देखें तो आमतौर पर private repository permissions न देने वाला github token इस्तेमाल होता दिखता है
    या फिर agent के पास ही somehow उससे ज़्यादा privileges थे? अगर ऐसा था, तो agent को गलत configure किया गया था। यह तो पहले से पता है कि agent किसी चीज़ को enforce करेगा, इस पर भरोसा नहीं करना चाहिए

  • यह लेख Noma marketing जैसा लगता है। इसमें प्यारा-सा नाम, logo, clickbait title, और non-technical readers को निशाना बनाता हुआ नाटकीय tone तक है
    असली vulnerability अगर कुछ है, तो वह यह है कि अगर आप LLM को private data दे दें और किसी को भी उससे interact करने दें, तो data leak हो सकता है। यह बहुत ही obvious है

  • ऐसे लोग LLM को पूरे disk पर write access दे देंगे और फिर destructive काम होने पर शिकायत करेंगे
    अगर आप नहीं चाहते कि AI agent private repository पढ़े, तो उसे private repository access ही मत दें। यह permissions bypass की समस्या नहीं, बल्कि prompt injection की समस्या है, और इसे agent layer पर reliably हल नहीं किया जा सकता

  • या तो यह पहले से हल की जा चुकी समस्या है, या फिर GitHub अभी तक इसे हल नहीं कर पाया है और इस बीच malicious actors repositories पर vulnerabilities आज़माएँगे
    repositories की संख्या बहुत ज़्यादा है, इसलिए leak होने की संभावना 0 नहीं है। लेकिन scam victims की तरह, लगभग कोई भी leak स्वीकार नहीं करेगा