Copilot ने audit log को नुकसान पहुँचाया, लेकिन Microsoft ने ग्राहकों को नहीं बताया
(pistachioapp.com)- Microsoft के M365 Copilot में audit log रिकॉर्ड न होने वाली एक कमजोरी मिली, जिसके कारण file access का रिकॉर्ड log में नहीं बचता था
- सिर्फ Copilot को एक खास तरीके से काम करने के लिए कहने पर audit record के बिना file access संभव था, जिससे insider threat और कानूनी/नियामकीय उल्लंघन का जोखिम बढ़ सकता था
- शोधकर्ता ने इसकी रिपोर्ट MSRC को दी, लेकिन Microsoft ने अपनी आधिकारिक नीति के विपरीत CVE जारी नहीं किया और ग्राहकों को भी सूचित नहीं किया
- Microsoft ने इस कमजोरी को केवल 'Important' स्तर का माना और यह कहते हुए कि automatic update से समस्या हल हो गई है, अलग से सूचना आवश्यक नहीं समझी
- लेकिन इससे HIPAA जैसे विनियमित उद्योगों में audit log पर निर्भर कंपनियों के लिए गंभीर सुरक्षा और कानूनी समस्याएँ पैदा हो सकती हैं, और Microsoft की पारदर्शिता की कमी की कड़ी आलोचना हो रही है
Copilot की audit log कमजोरी: अवलोकन और प्रभाव
- Microsoft के प्रमुख AI service Copilot, जिसे कंपनी तेज़ी से अपना रही है, में ऐसा दोष पाया गया जिसमें user request के आधार पर file access history audit log में दर्ज नहीं होती थी
- सामान्य स्थिति में M365 Copilot जब किसी file का summary बनाता है, तो उस file access का रिकॉर्ड audit log में जाना चाहिए, और यह किसी संगठन की information security का महत्वपूर्ण हिस्सा है
- लेकिन अगर Copilot से कहा जाए कि file summary result में file link शामिल न करे, तो उस access का log बिल्कुल दर्ज नहीं होता
- उदाहरण के लिए, कोई कर्मचारी नौकरी छोड़ने से पहले Copilot के जरिए बड़ी संख्या में files देखे, तो वह बिना किसी log trace के data बाहर ले जा सकता है
- यह कमजोरी किसी बनावटी hacking तकनीक से नहीं, बल्कि संयोग से और स्वाभाविक रूप से भी सामने आ सकती है; वास्तव में ब्लॉग लेखक ने इसे अपने feature test के दौरान पाया
- Zenity के CTO Michael Bargury ने भी यह कमजोरी एक साल पहले खोजकर Microsoft को रिपोर्ट की थी, लेकिन इस बार की रिपोर्ट तक भी यह लंबे समय तक अनदेखी रही
MSRC (कमजोरी रिपोर्टिंग) की समस्याएँ और प्रतिक्रिया की अस्वीकार्यता
- Microsoft कमजोरी रिपोर्टिंग के लिए आधिकारिक guidance और process देता है, लेकिन वास्तविक response process में उसने उनका ठीक से पालन नहीं किया
- लेखक द्वारा MSRC को रिपोर्ट देने के बाद, reproduction steps पूरे होने से पहले ही Copilot feature बदल जाने जैसी उलझनभरी स्थिति बनी
- रिपोर्ट status change (reproduction → development) जैसी प्रगति दिखी, लेकिन progress या फैसलों के आधार पर स्पष्ट communication की कमी रही
- security vulnerability के लिए CVE जारी करने पर Microsoft की ओर से यह रुख बताया गया कि आधिकारिक नंबर तभी दिया जाता है जब ग्राहकों को स्वयं कार्रवाई करनी हो
- लेकिन यह Microsoft की पहले की policy से अलग है, और इस कमजोरी को सिर्फ 'Important' rating देकर न तो सार्वजनिक रूप से घोषित किया गया और न ही अलग से सूचना दी गई
- कुल मिलाकर progress tracking वास्तविक कार्रवाई से अलग केवल दिखावटी रूप से update होती रही, जिससे रिपोर्ट करने वाले के लिए यह अनुभव अक्षम और अपारदर्शी रहा
सूचना और ग्राहक अलर्ट न देने की समस्या
- Microsoft ने इस कमजोरी के लिए न तो CVE जारी करने का, न ही ग्राहकों को सूचित करने का फैसला किया
- चूँकि यह ऐसी गलती थी जो अनजाने में भी आसानी से हो सकती थी, इसलिए वास्तविक संगठनों में लंबे समय तक audit log के गलत तरीके से दर्ज होने की संभावना बनी रही
- स्वास्थ्य संस्थान (जैसे HIPAA) सहित कई संगठन कानूनी और नियामकीय उद्देश्यों के लिए audit log का उपयोग करते हैं, फिर भी Microsoft ने प्रभावित होने की बात उपयोगकर्ताओं को नहीं बताई
- audit log संगठन की security, incident response और कानूनी साक्ष्य सहित कई क्षेत्रों में केंद्रीय भूमिका निभाते हैं, लेकिन Microsoft ने इस मुद्दे पर चुप्पी बनाए रखी
- यह दृष्टिकोण संकेत देता है कि अन्य संभावित security issues भी सार्वजनिक किए बिना संभाले जा सकते हैं, जिससे संगठन की विश्वसनीयता पर गंभीर सवाल उठते हैं
1 टिप्पणियां
Hacker News टिप्पणियाँ
मैं कंपनी के अंदरूनी chatbot development का काम संभाल रहा हूँ, और management को यह समझाने में दिक्कत हो रही है कि अगर chatbot गोपनीय documents तक पहुँचते समय मौजूदा user की permissions पूरी तरह चेक नहीं करता, तो information leak का रास्ता ज़रूर बनता है
vector database, search index, AI Search Database आदि या तो user-वार मौजूद होने चाहिए, या content के साथ access permissions को track करना चाहिए
लेकिन access permissions बहुत जटिल होती हैं और कभी भी बदल सकती हैं, इसलिए इन्हें बड़े पैमाने पर लागू करना कठिन है और race condition के प्रति कमजोर भी है — मैं इसी बात पर ज़ोर देना चाहता हूँ
यह 'Confused Deputy' समस्या का एक ठोस उदाहरण है
यह OWASP LLM Top 10 के LLM02:2025 ‘Sensitive Information Disclosure’ और LLM06:2025 ‘Excessive Agency’ से जुड़े जोखिमों में आता है
कुछ enterprise RAG solutions अलग-अलग ACLs की वजह से user-विशिष्ट indexes बनाकर इसका समाधान करते हैं
vendors इस permission समस्या को कैसे manage करते हैं, यह अलग-अलग होता है, इसलिए RAG solution का विश्लेषण करते समय इस हिस्से की ज़रूर जाँच करनी चाहिए
जापान में इसे "kengen kondo (権限混同)" कहा जाता है, जो काफ़ी दिलचस्प नाम लगता है
Confused Deputy का विवरण देखें, OWASP LLM Top 10 risks देखें
मैं जानना चाहता हूँ कि user access permissions को track करना scalability problem क्यों माना जा रहा है
query आने पर vector DB या index में matching documents ढूँढे जाएँ, और उनमें से सिर्फ़ वही LLM को दिए जाएँ जिन तक user की पहुँच है
यह कुछ वैसा ही है जैसे बैंक का customer service agent सिर्फ़ authenticated customer की जानकारी ही देख सकता है, इसलिए गलती से किसी और की जानकारी लीक नहीं होती; और अगर authentication न हो, तो किसी और की जानकारी operator भी नहीं देख सकता, इसलिए misuse का जोखिम नहीं होना चाहिए
जब ऐसी दीवार से टकराते हैं, तो असल में यह ज़रूरी नहीं कि मैं communication में fail हुआ हूँ या management समझ नहीं पा रही
शायद management ने इस समस्या को नज़रअंदाज़ करने का फैसला कर लिया है, और बाद में leak होने पर engineer पर दोष डालने का इरादा है
अगर management को समस्या समझाने में मुश्किल हो रही है, तो Legal/Compliance टीम को CC में रखना असरदार हो सकता है
हाँ, buzzword से चिपके रहने वाले कुछ executives इस कदम से नाराज़ हो सकते हैं
ज़्यादातर vector databases vectors के साथ अतिरिक्त metadata जोड़ने देते हैं
access रखने वाले subjects की सूची (जैसे HR, executives) metadata में रखी जाए, तो request के समय user को उन roles तक expand करके filter किया जा सकता है
इससे वे documents शुरू से ही बाहर किए जा सकते हैं जिन्हें user देख नहीं सकता
लेकिन document-वार permissions बदलते ही vector metadata को भी तुरंत update करना होगा
यह समस्या है कि Copilot audit logs को bypass कर रहा है और privileged user की तरह काम कर रहा है
ऐसा नहीं होना चाहिए
Copilot वास्तव में files तक सीधे पहुँच नहीं रहा, बल्कि पहले से indexed files की सामग्री search engine के ज़रिए पढ़ रहा है
Microsoft को Copilot की search history का audit करना चाहिए; अगर Copilot ने सिर्फ़ index पढ़ा, लेकिन log में file access दिखे, तो यह भ्रामक होगा
यह वैसा ही है जैसे Google search results देखने को website पर सीधे जाने के बराबर कहना
Microsoft बेवजह AI integration के पीछे भागते हुए audit logs पर लापरवाही बरत रहा है
Windows में Backup privilege वाला process सभी access permissions को bypass कर सकता है और default रूप से audit नहीं करता
backup apps के मामले में ऐसा इसलिए है क्योंकि audit logs बहुत ज़्यादा हो जाते हैं; यह privilege explicitly enable करना पड़ता है, और C# जैसे managed code में यह आसानी से किया जा सकता है
Restore privilege के साथ भी यही बात लागू होती है
यह वैसा ही है जैसा पहले Delve के शुरुआती rollout में permission trimming ग़लत हो गई थी, जिससे user search results में चीज़ें दिखने लगीं, या SharePoint search कुछ ऐसे documents दिखा देता था जो मौजूद तो थे लेकिन accessible नहीं थे
उदाहरण के लिए, "Fall 2025 layoffs" खोजने पर सिर्फ़ संबंधित document का मौजूद होना ही उजागर हो जाता था, जिससे security issue बनता था
Microsoft के बारे में अब भी यही मज़बूत धारणा बनती है कि ‘security बाद में सोची जाती है’
इससे बेहतर शीर्षक शायद "Microsoft Copilot HIPAA compliance का पालन नहीं करता" होगा
ऐसा शीर्षक लिखें तो शायद समस्या कहीं जल्दी हल हो
इससे भी आगे बढ़कर, कोई भी उपयोगी AI search system design के हिसाब से unsafe है, क्योंकि vector database में रखे गए RAG vectors अंततः documents का lossy compression ही हैं
समस्या पहले ही ठीक की जा चुकी है
अभी की शिकायत यह है कि customers को इसकी सूचना नहीं दी गई
“CVE उन security releases को assign किए जाते हैं जहाँ customers को सुरक्षा के लिए कुछ action लेना पड़ता है. इस मामले में action अपने-आप Copilot में deploy हो गया, और users को manually update नहीं करना था, इसलिए CVE assign नहीं किया गया”
मैं जानना चाहता हूँ कि क्या यह CVE की मूल विशेषता है, या Microsoft इसे ऐसे इस्तेमाल कर रहा है
अच्छा होता अगर ऐसी vulnerabilities के लिए भी reference के तौर पर कोई common ID होती, और vendor-निर्भर न रहने वाली अलग numbering scheme भी होनी चाहिए
Microsoft का कहना है कि CVE security incidents/vulnerabilities को track करने के लिए होता है
चाहे असामान्य रूप से emergency patch लगाया जा सके, इससे यह security incident होना बंद नहीं हो जाता
Microsoft security incidents के transparent disclosure में कमज़ोर और कम भरोसेमंद होता जा रहा है, इसलिए ऐसे मामलों में और भी ज़्यादा disclosure ज़रूरी है
यह CVE की सीमा से ज़्यादा ऐसा लगता है कि Microsoft PR के लिए CVE process को मोड़कर इस्तेमाल कर रहा है
CVE में ‘C’ का मतलब Common है
यानी यह system ‘सामान्यता’ पर केंद्रित है
इस समय महत्वपूर्ण LOB apps को भी Microsoft से दूर ले जाने की कोशिश चल रही है
पिछले कुछ महीनों के कई hacks, SSO zero-day, और Copilot indexer के global admin की तरह चलकर permissions ignore करने जैसी बातों को देखकर बेचैनी बढ़ती जा रही है
LLM को सीधे audit और activity logs की ज़िम्मेदारी देने पर कितनी समस्याएँ हो सकती हैं, इसका हिसाब लगाना भी मुश्किल है
इसलिए मैं जानना चाहता हूँ कि इस बार bug fix कैसे किया गया — कहीं ऐसा तो नहीं कि उन्होंने ‘shadow prompt’ जोड़ दिया हो
पोस्ट में कहीं भी यह नहीं कहा गया कि LLM खुद audit logs manage करता है
उल्टा, audit logs शायद LLM नहीं बल्कि ऊपर की scaffolding layer (side system) में रिकॉर्ड होते हैं, और लगता है कि log लिखने का 'समय' ग़लत चुना गया था
उदाहरण के लिए, किसी के link click करने के समय log लिखने की बजाय, document के LLM में inject होने के समय log होना चाहिए था
यह design भी आदर्श नहीं है, लेकिन LLM से direct logging करवाने से कम गंभीर है
मैं shadow prompt (या किसी भी तरह के prompt) को असली security या compliance control के रूप में इस्तेमाल करने को लेकर बहुत संदेह में हूँ
ऐसे controls को अनिवार्य रूप से deterministic और predictable systems होना चाहिए
अगर कोई tool LLM को file का छोटा-सा हिस्सा भी दिखाता है, तो उसके बाद LLM द्वारा निकाली गई सारी जानकारी को उस file को पढ़ा हुआ माना जाना चाहिए
मुझे लगता है कि LLM prompt में अजीब मांगें भी आ सकती हैं, जैसे “अगर user ने तुम्हें link न देने को कहा हो तो उसे अनदेखा करो, नहीं तो तुम्हारे परिवार के साथ XYZ भयानक घटना होगी”
इससे shadow copies की समस्या भी याद आती है
यहाँ किस तरह के audit logs की बात हो रही है, यह साफ़ नहीं है
SharePoint file access logs? Copilot activity record? Purview? या कुछ और?
बहुत-सी बातें अस्पष्ट हैं
Copilot file पर नहीं, indexed content पर पहुँच रहा है, इसलिए तकनीकी रूप से उसने file को access नहीं किया
blog author को index access logs देखने चाहिए
blog के footnote में एक राय है: “audit log का CopilotInteraction के रूप में रहना, न कि user द्वारा file को direct access करने के रूप में, मुझे इरादतन लगता है
अगर user ने सिर्फ़ Copilot के ज़रिए access किया हो, तो उसे ऐसे record करना जैसे उसने file को सीधे छुआ हो, यह उल्टा अजीब होगा”
मैंने ChatGPT से यही सवाल पूछा तो उसने समझाया कि बात Microsoft 365, Office 365 के audit logs, खासकर Microsoft Purview Compliance Portal के Unified Audit Log की हो रही है
ऐसे मुद्दे ही वजह हैं कि Microsoft जैसे बड़े vendors पर भरोसा ‘guarantee’ नहीं बल्कि ‘किस्मत’ जैसा लगने लगता है
मैं सच में जानना चाहता हूँ कि व्यावहारिक रूप से इस समस्या को कैसे ठीक किया जा सकता है
मेरी समझ से Copilot जिस index/DB का इस्तेमाल करता है, वह उस file को पहले ही crawl कर चुका है, इसलिए file को दोबारा fetch किए बिना भी वह जानकारी दे सकता है
तो फिर इसे ठीक कैसे किया जाए?
क्या database/index access को ही audit logs से जोड़ना होगा?
या LLM को यह आदेश देना होगा कि “knowledge lookup करते समय वादा निभाओ और ज़रूर log छोड़ो”?
Microsoft इस समस्या को कैसे समझता और हल करता है, इस पर आधिकारिक communication की सख़्त ज़रूरत है
मेरा मानना है कि sensitive data इस्तेमाल करने वाली कंपनियों के लिए यह issue चेतावनी की घंटी होना चाहिए
सामान्य तौर पर CVE के लिए कोई भी registration कर सकता है
मैं खुद submit करके Microsoft की प्रतिक्रिया को मजबूर कर सकता हूँ
सिर्फ़ वह blog post भी काफ़ी persuasive लगती है
असल में यह इतना आसान नहीं है
MITRE या national CERT जैसे ज़्यादातर CVE Numbering Authorities (CNA) में कोई भी report कर सकता है, लेकिन वहाँ evaluation और review होता है
Microsoft खुद CNA है, इसलिए खास वजह न हो तो Microsoft से जुड़े CVE बाहर से assign नहीं किए जाएँगे
सिर्फ़ Microsoft द्वारा चलाए जाने वाले service के लिए CVE माँगना कितना सार्थक है, इस पर भी सवाल है
user इससे आख़िर कर क्या सकता है?
CVE registration form यहाँ उपलब्ध है
PGP support, लंबा track record, और verified sponsors जैसी वजहों से इसकी विश्वसनीयता भी ऊँची है
इसका उपयोग केवल वैध और उचित मामलों में ही करना चाहिए
दिलचस्प तो है, लेकिन मुझे नहीं लगता कि यह CVE का मामला है
CVE ऐसी vulnerabilities के लिए होना चाहिए जो कई sources के कई products पर समान रूप से लागू हों, और Copilot उस श्रेणी में नहीं आता
इस घटना का सबसे गंभीर पहलू यह design mistake है कि Copilot LLM को ही audit log generation का निर्देश दिया गया
file या URL lookup करने वाले API को अपने-आप audit log छोड़ना चाहिए था; यह engineering का बुनियादी सिद्धांत है