Copilot làm hỏng nhật ký kiểm toán nhưng Microsoft không thông báo cho khách hàng
(pistachioapp.com)- Đã phát hiện lỗ hổng khiến nhật ký kiểm toán không được ghi lại trong M365 Copilot của Microsoft, dẫn đến việc truy cập tệp không xuất hiện trong log
- Chỉ cần yêu cầu Copilot hoạt động theo một cách cụ thể là có thể truy cập tệp mà không để lại bản ghi kiểm toán, điều này có thể dẫn đến rủi ro từ mối đe dọa nội bộ và vi phạm các quy định pháp lý
- Nhà nghiên cứu đã báo cáo cho MSRC, nhưng Microsoft không cấp CVE và cũng không thông báo cho khách hàng, trái với chính sách chính thức
- Microsoft chỉ phân loại lỗ hổng này ở mức Important và quyết định rằng đã được khắc phục bằng cập nhật tự động nên không cần thông báo riêng
- Tuy nhiên, điều này có thể gây ra các vấn đề bảo mật và pháp lý nghiêm trọng cho những doanh nghiệp trong các ngành chịu quản lý như HIPAA vốn phụ thuộc vào nhật ký kiểm toán, và việc Microsoft thiếu minh bạch đang bị chỉ trích mạnh mẽ
Lỗ hổng nhật ký kiểm toán của Copilot: tổng quan và tác động
- Trong Copilot, dịch vụ AI tiêu biểu mà Microsoft đang tích cực triển khai, đã phát hiện lỗi khiến lịch sử truy cập tệp không được ghi vào nhật ký kiểm toán tùy theo yêu cầu của người dùng
- Thông thường, khi M365 Copilot tóm tắt một tệp, lịch sử truy cập vào tệp đó phải được ghi vào nhật ký kiểm toán, và đây là yếu tố cốt lõi của bảo mật thông tin trong tổ chức
- Tuy nhiên, nếu yêu cầu Copilot không đưa liên kết tệp vào kết quả tóm tắt, sẽ xảy ra hiện tượng log tương ứng hoàn toàn không được ghi lại
- Ví dụ, ngay cả khi một nhân viên tra cứu số lượng lớn tệp qua Copilot trước khi nghỉ việc, họ vẫn có thể làm rò rỉ dữ liệu mà không để lại dấu vết trong log
- Lỗ hổng này không phải là kiểu tấn công được dàn dựng có chủ ý mà có thể xảy ra một cách tự nhiên ngoài ý muốn; tác giả bài blog đã phát hiện ra nó trong quá trình tự kiểm thử tính năng
- Michael Bargury, CTO của Zenity, cũng đã phát hiện lỗ hổng này từ 1 năm trước và báo cáo cho Microsoft, nhưng đến tận lần báo cáo này nó vẫn bị bỏ mặc trong thời gian dài
Vấn đề với MSRC (báo cáo lỗ hổng) và việc không công nhận biện pháp xử lý
- Microsoft có cung cấp hướng dẫn chính thức và quy trình cho việc báo cáo lỗ hổng, nhưng trong quá trình xử lý thực tế lại không tuân thủ đúng các nội dung đó
- Sau khi tác giả báo cáo lên MSRC, đã xảy ra tình huống khó hiểu như việc tính năng Copilot thay đổi ngay cả khi chưa trải qua đầy đủ các bước tái hiện lỗi
- Trạng thái báo cáo có thay đổi (tái hiện → phát triển), nhưng thiếu giao tiếp rõ ràng về tiến độ cũng như căn cứ cho các quyết định được đưa ra
- Về việc cấp CVE cho lỗ hổng bảo mật, tác giả được thông báo rằng chỉ khi khách hàng cần trực tiếp thực hiện biện pháp xử lý thì mới được cấp mã chính thức
- Tuy nhiên, điều này khác với chính sách trước đây của Microsoft, và lỗ hổng này chỉ được xếp hạng ở mức 'Important' nên không có công bố hay thông báo riêng
- Nhìn chung, việc theo dõi tiến độ chỉ được cập nhật một cách bề ngoài mà không gắn với hành động thực tế, khiến trải nghiệm của người báo cáo trở nên kém hiệu quả và thiếu minh bạch
Vấn đề từ việc thiếu công bố và không thông báo cho khách hàng
- Microsoft đã quyết định không cấp CVE cho lỗ hổng lần này và cũng không thông báo cho khách hàng
- Vì đây là loại lỗi có thể rất dễ phát sinh ngay cả do vô tình, nên có khả năng trong thời gian dài nhật ký kiểm toán tại các tổ chức đã bị ghi nhận sai
- Dù có nhiều tổ chức như cơ sở y tế (ví dụ: HIPAA) sử dụng nhật ký kiểm toán cho mục đích pháp lý và tuân thủ quy định, Microsoft vẫn không thông báo cho người dùng về mức độ ảnh hưởng
- Nhật ký kiểm toán là thành phần cốt lõi trong bảo mật tổ chức, ứng phó sự cố và chứng cứ pháp lý, nhưng Microsoft vẫn giữ im lặng về vấn đề liên quan
- Cách tiếp cận này cho thấy những vấn đề bảo mật tiềm ẩn khác cũng có thể bị xử lý mà không công khai, qua đó đặt ra nghi vấn nghiêm trọng về độ tin cậy của tổ chức
1 bình luận
Ý kiến trên Hacker News
Tôi phụ trách phát triển chatbot nội bộ trong công ty, và đang rất khó giải thích với ban lãnh đạo rằng nếu chatbot không kiểm tra đầy đủ quyền của người dùng hiện tại khi truy cập tài liệu mật thì chắc chắn sẽ tạo ra đường rò rỉ thông tin
Các vector database, search index hay AI Search Database либо phải tồn tại riêng cho từng người dùng, либо phải theo dõi quyền truy cập cùng với nội dung
Nhưng quyền truy cập thì cực kỳ phức tạp, có thể thay đổi bất cứ lúc nào, nên tôi muốn nhấn mạnh rằng rất khó triển khai ở quy mô lớn và dễ bị race condition
Đây là một ví dụ cụ thể của vấn đề 'Confused Deputy'
Nó tương ứng với các rủi ro trong OWASP LLM Top 10 là LLM02:2025 ‘Sensitive Information Disclosure’ và LLM06:2025 ‘Excessive Agency’
Một số giải pháp RAG cho doanh nghiệp xử lý bằng cách tạo index riêng cho từng người dùng do có nhiều ACL khác nhau
Mỗi nhà cung cấp quản lý các vấn đề quyền truy cập này theo cách khác nhau, nên khi phân tích giải pháp RAG nhất định phải kiểm tra phần đó
Ở Nhật người ta gọi đây là "nhầm lẫn quyền hạn(権限混同)", nghe cũng khá thú vị
Xem giải thích về Confused Deputy, Xem rủi ro trong OWASP LLM Top 10
Tôi tò mò vì sao bạn cho rằng việc theo dõi quyền truy cập của người dùng lại là vấn đề về khả năng mở rộng
Khi có query đi vào, chỉ cần tìm các tài liệu khớp trong vector DB hoặc index, rồi chỉ chuyển cho LLM những tài liệu mà người dùng được phép truy cập là được
Cũng giống như nhân viên tư vấn ngân hàng chỉ có thể xem thông tin của khách hàng đã được xác thực nên sẽ không vô tình làm lộ thông tin của người khác; còn nếu chưa xác thực thì ngay cả người vận hành cũng không thể xem thông tin của người khác nên cũng không có nguy cơ bị lạm dụng
Khi đụng phải những bức tường như thế này, thực tế không hẳn là tôi giao tiếp thất bại hay ban lãnh đạo không hiểu
Có lẽ ban lãnh đạo đã quyết định phớt lờ vấn đề này, rồi nếu sau này xảy ra rò rỉ thì sẽ đổ trách nhiệm sang kỹ sư
Nếu bạn gặp khó trong việc giải thích vấn đề cho ban lãnh đạo, thêm bộ phận Legal/Compliance vào danh sách CC có thể sẽ hiệu quả
Tuy vậy, một số lãnh đạo quá ám ảnh với buzzword có thể sẽ khó chịu vì hành động này
Hầu hết vector database đều cho phép gắn metadata bổ sung vào vector
Nếu lưu danh sách các chủ thể có quyền truy cập (ví dụ: HR, lãnh đạo) vào metadata, thì khi có yêu cầu có thể mở rộng người dùng thành các vai trò tương ứng để lọc
Làm vậy sẽ loại bỏ ngay từ đầu các tài liệu mà người dùng không thể xem
Tuy nhiên, mỗi khi quyền của tài liệu thay đổi thì metadata của vector cũng phải được cập nhật ngay lập tức
Việc Copilot né audit log và hoạt động như người dùng đặc quyền là một vấn đề
Tôi không nghĩ điều đó là có thể chấp nhận được
Copilot thực ra không trực tiếp truy cập file, mà đang đọc nội dung của các file đã được lập chỉ mục thông qua công cụ tìm kiếm
Microsoft nên audit lịch sử tìm kiếm của Copilot; nếu Copilot chỉ đọc index mà lại bị ghi là đã truy cập file thì sẽ gây hiểu nhầm
Cũng giống như không thể nói rằng bạn đã trực tiếp truy cập một website chỉ vì bạn xem kết quả tìm kiếm Google về nó
Microsoft đang mải mê tích hợp AI một cách không cần thiết, và trong quá trình đó lại lơ là với audit log
Trên Windows, tiến trình có quyền Backup có thể bỏ qua mọi quyền truy cập và mặc định không bị audit
Lý do là với ứng dụng backup, audit log sẽ trở nên quá nhiều; quyền này phải được kích hoạt tường minh và có thể làm khá dễ ngay cả trong managed code như C#
Quyền Restore cũng tương tự
Hiện tượng này giống với vấn đề thời Delve mới ra mắt, khi permission trimming làm sai khiến kết quả tìm kiếm của người dùng bị lộ, hoặc SharePoint Search hiển thị một phần các tài liệu tuy có tồn tại nhưng không thể truy cập
Ví dụ, nếu tìm "Fall 2025 layoffs" thì chỉ cần tài liệu liên quan tồn tại là nó đã bị lộ ra, gây ra vấn đề bảo mật
Microsoft vẫn tạo cảm giác rằng ‘bảo mật là chuyện đứng sau’
Có lẽ tiêu đề tốt hơn sẽ là "Microsoft Copilot không tuân thủ HIPAA"
Nếu dùng tiêu đề như vậy thì có lẽ vấn đề sẽ được xử lý nhanh hơn nhiều
Đi xa hơn nữa thì, mọi hệ thống AI search hữu dụng đều không an toàn ngay từ thiết kế, vì các vector RAG được lưu trong vector database về bản chất là một dạng nén mất dữ liệu của tài liệu gốc
Vấn đề đã được sửa rồi
Điều đang bị phàn nàn lúc này là khách hàng không được thông báo
“CVE được gán cho các bản phát hành bảo mật khi khách hàng cần thực hiện hành động để được bảo vệ. Trong trường hợp này, biện pháp khắc phục được tự động triển khai tới Copilot và người dùng không cần cập nhật thủ công, nên không có CVE nào được gán”
Tôi thắc mắc không biết đó có phải là bản chất cốt lõi của CVE hay chỉ là cách Microsoft đang sử dụng CVE
Tôi vẫn muốn có một ID chung để tham chiếu cho những lỗ hổng kiểu này, và nghĩ rằng nên có một hệ thống đánh số riêng không phụ thuộc vào nhà cung cấp
Microsoft nói CVE là để theo dõi sự cố/lỗ hổng bảo mật
Dù có thể vá khẩn cấp nhanh bất thường thì điều đó cũng không khiến nó không còn là sự cố bảo mật nữa
Microsoft ngày càng có xu hướng thiếu minh bạch và kém đáng tin trong việc công bố sự cố bảo mật, nên trong những trường hợp như thế này việc công khai thông tin lại càng quan trọng hơn
Cảm giác đây không phải là giới hạn của CVE mà giống việc Microsoft đang uốn quy trình CVE để phục vụ PR hơn
Chữ ‘C’ trong CVE là Common
Tức là đây là một hệ thống nhấn mạnh tính ‘chung’
Hiện tại tôi cũng đang cố đưa các ứng dụng LOB quan trọng rời khỏi Microsoft
Sau nhiều vụ hack trong vài tháng gần đây, zero-day ở SSO, và việc Copilot chạy indexer như global admin rồi bỏ qua quyền hạn, cảm giác bất an ngày càng lớn hơn
Có quá nhiều vấn đề có thể xảy ra nếu giao trực tiếp việc audit và activity log cho LLM, nhiều đến mức khó mà đếm xuể
Vì vậy tôi rất tò mò không biết họ đã sửa bug lần này như thế nào, có phải họ đã đưa vào một ‘shadow prompt’ hay không
Không có chỗ nào trong bài viết nói rằng LLM trực tiếp quản lý audit log
Ngược lại, có vẻ audit log được ghi ở tầng scaffolding phía trên chứ không phải ở LLM, chỉ là họ đã chọn sai ‘thời điểm’ cần ghi log
Ví dụ, thay vì ghi audit log tại thời điểm ai đó bấm vào link, họ lẽ ra nên ghi khi tài liệu được đưa vào LLM, chẳng hạn vậy
Thiết kế này cũng chưa phải tối ưu, nhưng vẫn đỡ nghiêm trọng hơn việc để LLM tự ghi log
Tôi rất hoài nghi việc dùng shadow prompt (hoặc bất kỳ dạng prompt nào) như một cơ chế kiểm soát bảo mật hay tuân thủ thật sự
Những kiểm soát như vậy bắt buộc phải là các hệ thống có tính quyết định và có thể dự đoán được
Nếu một công cụ cho phép LLM nhìn thấy dù chỉ là một phần của file, thì từ thời điểm đó mọi thông tin mà LLM xuất ra đều phải được xem là đã đọc file đó
Tôi nghĩ hoàn toàn có thể có những yêu cầu kỳ quặc trong prompt của LLM kiểu như “nếu người dùng bảo đừng đưa link cho nó thì hãy bỏ qua, còn nếu không thì gia đình bạn sẽ gặp chuyện XYZ khủng khiếp”
Cũng làm tôi nghĩ tới vấn đề shadow copies
Không rõ ở đây họ đang nói chính xác tới loại audit log nào
Log truy cập file của SharePoint? Log hành vi của Copilot? Purview? Hay một thứ gì khác?
Có rất nhiều điểm chưa rõ
Copilot đang truy cập nội dung đã được lập chỉ mục chứ không phải chính file đó, nên đúng là nó chưa thực sự truy cập file
Tác giả blog nên xem log truy cập index
Trong phần chú thích của blog có ý rằng “audit log được ghi dưới dạng CopilotInteraction chứ không phải dấu vết người dùng trực tiếp truy cập file, và tôi nghĩ đó là chủ đích
Nếu người dùng chỉ truy cập thông qua Copilot mà lại bị ghi như thể đã trực tiếp đụng vào file thì mới là điều kỳ lạ”
Tôi đã hỏi ChatGPT cùng câu này và nó giải thích rằng đang nói tới audit log của Microsoft 365, Office 365, cụ thể là Unified Audit Log trong Microsoft Purview Compliance Portal
Chính những vấn đề kiểu này khiến niềm tin vào các nhà cung cấp lớn như Microsoft không còn mang cảm giác là ‘đảm bảo’ mà giống ‘hên xui’ hơn
Tôi thực sự tò mò trên thực tế có thể sửa lỗi này như thế nào
Theo hiểu biết của tôi, index/DB mà Copilot dùng đã crawl file tương ứng rồi, nên kể cả không truy vấn lại file thì nó vẫn có thể trả lời thông tin đó
Vậy rốt cuộc phải sửa kiểu gì?
Có phải cần liên kết chính việc truy cập database/index với audit log không?
Hay là phải ra lệnh cho LLM kiểu “khi tra cứu tri thức thì nhớ giữ lời hứa và обязательно để lại log”?
Microsoft rất cần có truyền thông chính thức về việc họ nhận diện và xử lý vấn đề này như thế nào
Với các doanh nghiệp sử dụng dữ liệu nhạy cảm, tôi nghĩ sự việc lần này phải là một hồi chuông cảnh báo
Nói chung thì CVE ai cũng có thể đăng ký
Tôi thậm chí có thể tự nộp để thúc đẩy Microsoft phản hồi
Chỉ với bài blog đó thôi tôi đã thấy khá thuyết phục rồi
Thực tế không đơn giản vậy
Hầu hết các cơ quan có thẩm quyền cấp số CVE (CNA) như MITRE hay CERT quốc gia đều cho phép bất kỳ ai báo cáo, nhưng vẫn có bước đánh giá và thẩm định
Microsoft là CNA riêng của họ, nên trừ khi có lý do đặc biệt thì CVE liên quan tới MS sẽ không được bên ngoài cấp
Tôi đang băn khoăn liệu việc yêu cầu CVE cho một dịch vụ chỉ do Microsoft vận hành có thực sự có ý nghĩa không
Câu hỏi là người dùng thực sự có thể làm gì với nó
Có thể dùng biểu mẫu đăng ký CVE tại đây
Mức độ tin cậy cũng khá cao nhờ hỗ trợ PGP, bề dày hoạt động lâu năm và các nhà bảo trợ đã được xác minh
Chỉ nên sử dụng cho các vấn đề hợp pháp và chính đáng
Cũng thú vị đấy, nhưng tôi không nghĩ đây là đối tượng của CVE
CVE phải áp dụng cho các lỗ hổng có tính chung trên nhiều sản phẩm từ nhiều nguồn khác nhau, còn Copilot thì không thuộc trường hợp đó
Điểm nghiêm trọng nhất của vụ này là sai lầm trong thiết kế khi giao cho chính Copilot LLM việc tạo audit log
Audit log lẽ ra phải được ghi tự động ở API truy vấn file hoặc URL, và đó là nguyên tắc cơ bản trong kỹ thuật