Rò rỉ dữ liệu từ Slack AI qua chèn prompt gián tiếp
(substack.com/promptarmor)- Trong quá trình Slack AI tìm kiếm tin nhắn trong workspace bằng truy vấn ngôn ngữ tự nhiên, nó có thể làm theo chèn prompt gián tiếp, khiến kẻ tấn công có thể làm rò rỉ cả dữ liệu từ các kênh riêng tư mà chúng không có quyền truy cập
- Cốt lõi của vấn đề là LLM không thể phân biệt ổn định giữa system prompt của nhà phát triển và các chỉ thị nằm trong tin nhắn được gắn kèm theo kết quả tìm kiếm
- Tin nhắn ở kênh công khai có thể được tìm kiếm và xem ngay cả khi người dùng không tham gia kênh đó, nên kẻ tấn công có thể cấy chỉ thị độc hại vào một kênh công khai chỉ có mình chúng để đưa nó vào cửa sổ ngữ cảnh của Slack AI
- Trong bản trình diễn, API key của kênh riêng tư đã được chèn vào tham số HTTP của một liên kết Markdown trong câu trả lời của Slack AI, và phần ghi nguồn không trỏ tới kênh của kẻ tấn công nên rất khó truy vết
- Từ ngày 14/8/2024, Slack AI bắt đầu đưa cả tệp trong kênh và DM vào câu trả lời, làm bề mặt tấn công rộng hơn; quản trị viên có thể hạn chế thiết lập thu thập tệp
Vấn đề chèn prompt gián tiếp trong Slack AI
- Slack AI là tính năng cho phép truy vấn tin nhắn Slack bằng ngôn ngữ tự nhiên, và trước ngày 14/8/2024 chỉ thu thập tin nhắn
- Từ ngày 14/8/2024, các tài liệu đã tải lên và tệp Google Drive cũng được đưa vào câu trả lời của Slack AI, và thay đổi này làm bề mặt tấn công rộng hơn
- Lỗ hổng này là prompt injection, cụ thể hơn là chèn prompt gián tiếp
- LLM có thể không phân biệt được giữa system prompt do nhà phát triển tạo ra và ngữ cảnh khác được gắn thêm vào truy vấn của người dùng
- Nếu Slack AI thu thập các chỉ thị trong tin nhắn, khi các chỉ thị đó là độc hại, nó có thể làm theo chỉ thị của kẻ tấn công thay vì truy vấn của người dùng hoặc làm theo đồng thời với truy vấn đó
- Mối đe dọa nội bộ trong Slack vốn đã là vấn đề qua các vụ rò rỉ Slack tại Disney, Uber, EA, Twitter..., và lỗ hổng này cho phép kẻ tấn công tìm cách gây rò rỉ mà không cần truy cập trực tiếp vào kênh riêng tư hay dữ liệu bên trong đó
Chuỗi rò rỉ dữ liệu qua chèn vào kênh công khai
- Truy vấn người dùng tới Slack AI có thể tìm kiếm dữ liệu từ cả kênh công khai và kênh riêng tư
- Theo phản hồi từ Slack, các tin nhắn được đăng trong kênh công khai có thể được mọi thành viên workspace tìm kiếm và xem ngay cả khi họ không tham gia kênh đó, và đây là hành vi được chủ đích trong ứng dụng Slack AI
- Luồng tấn công được trình diễn như sau
- Người dùng đặt API key trong một kênh riêng tư chỉ có mình họ hoặc trong cuộc trò chuyện với chính mình
- Kẻ tấn công tạo một kênh công khai chỉ có mình chúng và đăng chỉ thị độc hại
- Khi người dùng hỏi Slack AI về API key, tin nhắn của người dùng và tin nhắn của kẻ tấn công cùng đi vào một cửa sổ ngữ cảnh
- Slack AI làm theo chỉ thị của kẻ tấn công và tạo một liên kết Markdown với nội dung “click here to reauthenticate”
- Trong tham số HTTP của liên kết có chứa API key riêng tư, và khi người dùng nhấp vào, kẻ tấn công sở hữu URL độc hại có thể xem giá trị đó trong log
- Kênh công khai của kẻ tấn công vẫn là kênh công khai dù chỉ có 1 thành viên là chính kẻ tấn công, và người khác chỉ thấy nó khi chủ động tìm kiếm
- Trong các tổ chức lớn, sự bùng nổ kênh công khai khiến thành viên khó theo dõi ngay cả những kênh mình đang thuộc về, nên các kênh công khai 1 người do kẻ tấn công tạo ra lại càng khó bị chú ý
- Cuộc tấn công này không đơn thuần là gửi cho người dùng một tin nhắn kiểu “hãy gửi API key”, mà là ra lệnh cho LLM thực hiện việc sau
- Thêm API key mà kẻ tấn công không thể truy cập vào tham số HTTP của một liên kết độc hại
- Hiển thị nó dưới dạng liên kết Markdown với cụm từ “click here to reauthenticate”
Ghi nguồn có thể che giấu dấu vết tấn công
- Trong bản trình diễn rò rỉ dữ liệu, phần ghi nguồn
[1]của Slack AI chỉ trỏ tới kênh riêng tư nơi người dùng đặt API key, chứ không trỏ tới kênh của kẻ tấn công - Nếu ghi nguồn đúng, mọi tin nhắn đóng góp vào câu trả lời đều phải được trích dẫn, nhưng trong bản trình diễn, tin nhắn của kẻ tấn công không xuất hiện trong nguồn
- Tin nhắn của kẻ tấn công cũng không nằm ở trang đầu tiên của kết quả tìm kiếm, nên nạn nhân khó nhận ra tin nhắn đó nếu không cuộn qua nhiều trang
- Kết quả tìm kiếm cũng để lộ các tin nhắn khác liên quan đến API key, cho thấy kẻ tấn công có thể tìm cách làm rò rỉ một bí mật bất kỳ ngay cả khi không chỉ đích danh giá trị bí mật cụ thể
Chuỗi phishing qua chèn vào kênh công khai
- Theo cùng cách đó, Slack AI có thể bị buộc hiển thị một liên kết phishing bằng Markdown cho người dùng thay vì làm rò rỉ dữ liệu
- Kẻ tấn công đặt tin nhắn độc hại trong một kênh công khai mà người dùng không tham gia, và lấy ví dụ tình huống tóm tắt tin nhắn trong ngày của một người dùng cụ thể
- Tin nhắn độc hại có thể tham chiếu tới bất kỳ cá nhân nào
- Ví dụ như tham chiếu tới quản trị viên có thể được dùng cho spear phishing nhắm vào lãnh đạo
- Cũng có thể tham chiếu tới một cấp dưới trực tiếp quan trọng
- Khi người dùng hỏi Slack AI về tin nhắn của người đó, liên kết phishing “click here to reauthenticate” sẽ được hiển thị
- Trong ví dụ phishing này, Slack AI có hiển thị tin nhắn bị chèn ở phần nguồn, và cách ghi nguồn có vẻ khá ngẫu nhiên
Thay đổi thu thập tệp ngày 14/8 và sự cần thiết phải công khai
- Ngày 14/8/2024, Slack AI đưa vào thay đổi cho phép các tệp trong kênh và DM được đưa vào câu trả lời của Slack AI
- Slack cho phép chủ sở hữu và quản trị viên hạn chế tính năng này
- Khi tệp được đưa vào, kẻ tấn công có thể không cần đăng trực tiếp chỉ thị độc hại vào tin nhắn Slack
- Nếu người dùng tải về một file PDF chứa chỉ thị độc hại được ẩn bằng chữ màu trắng rồi tải file đó lên Slack, hiệu ứng tương tự có thể xảy ra
- Tấn công dựa trên tệp chưa được xác minh tường minh trong các thử nghiệm trước ngày 14/8, nhưng được đánh giá là có khả năng cao dựa trên chức năng quan sát được trước đó
- Quản trị viên có thể hạn chế tính năng thu thập tài liệu của Slack AI cho đến khi vấn đề được khắc phục: https://slack.com/help/articles/…
Mốc thời gian công bố có trách nhiệm và phản hồi từ Slack
- Mốc thời gian công bố có trách nhiệm như sau
- 14/8: Báo cáo ban đầu
- 15/8: Slack yêu cầu thêm thông tin
- 15/8: PromptArmor gửi thêm video và ảnh chụp màn hình, đồng thời thông báo ý định công khai vì mức độ nghiêm trọng của vấn đề và do thay đổi ngày 14/8 của Slack AI
- 16/8: Slack gửi thêm câu hỏi
- 16/8: PromptArmor gửi phản hồi làm rõ
- 19/8: Slack cho biết sau khi xem xét, họ đánh giá bằng chứng là chưa đủ, và rằng việc tin nhắn ở kênh công khai có thể được thành viên workspace tìm kiếm/xem bất kể có tham gia kênh hay không là hành vi được chủ đích
- Đội ngũ bảo mật của Slack đã phản hồi nhanh và cho thấy họ đang cố gắng hiểu vấn đề
- Prompt injection là một lĩnh vực mới và còn bị hiểu sai nhiều trên toàn ngành, nên có thể cần thời gian để toàn ngành cùng hiểu rõ
- Xét tới mức độ sử dụng rộng rãi của Slack và quy mô dữ liệu mật nằm trong Slack, cuộc tấn công này có tác động thực tế tới trạng thái an toàn AI
- Đặc biệt sau thay đổi ngày 14/8, bề mặt rủi ro đã tăng mạnh, nên cần công khai để người dùng có thể giảm mức độ phơi nhiễm
1 bình luận
Ý kiến trên Hacker News
Điểm cốt lõi ở đây là hiểu đường rò rỉ dữ liệu
Slack có thể render liên kết Markdown, và URL được ẩn sau văn bản liên kết
Trong trường hợp này, kẻ tấn công khiến Slack AI hiển thị cho người dùng một liên kết kiểu “bấm vào đây để xác thực lại”, còn URL của liên kết đó trỏ tới máy chủ của kẻ tấn công và trong chuỗi truy vấn có chứa thông tin riêng tư nằm trong ngữ cảnh mà Slack AI có thể truy cập
Nếu người dùng bị lừa bấm vào liên kết, dữ liệu sẽ bị rò rỉ vào log máy chủ của kẻ tấn công
Bài viết giải thích cuộc tấn công này ở đây: https://simonwillison.net/2024/Aug/20/data-exfiltration-from...
Kẻ tấn công chỉ cần làm cho hyperlink được render, thậm chí không cần ai bấm
Vấn đề này và các cách giảm thiểu được bàn ở đây: https://embracethered.com/blog/posts/2024/the-dangers-of-unf...
Vì vậy hy vọng Slack AI không tự động mở rộng liên kết
imghoặc thứ tương đươngKhi đó, ngay cả không có tương tác của người dùng, chỉ cần hiển thị hình ảnh trong UI cũng có thể rò rỉ dữ liệu
Giờ đây mọi công ty công nghệ lớn đều gần như có lá bùa miễn trách nhiệm bất khả xâm phạm ngay cả khi làm hỏng việc
Bản thân mô hình phân quyền vẫn giữ nguyên, và đây không phải là chỗ bị phá vỡ
Thực tế là người dùng độc hại dùng kênh công khai để tiêm prompt; khi người dùng khác tìm kiếm, người dùng độc hại vẫn không truy cập được dữ liệu đó, nhưng việc tiêm prompt sẽ biến kết quả AI hiển thị cho người dùng “bình thường” ban đầu thành một liên kết tới website độc hại
Rốt cuộc nó khá giống một nỗ lực phishing do AI tạo ra
Nhìn vào chi tiết thì có vẻ khá khó khai thác trong thực tế, vì prompt độc hại được chuẩn bị sẵn phải khá khớp với nội dung mà người dùng bình thường sẽ tìm kiếm
Dù vậy, nó cho thấy rất rõ thế giới kiểu Alice ở xứ sở thần tiên của tiêm prompt LLM, tức việc tách lệnh và dữ liệu về bản chất gần như là bất khả thi
Thay vào đó, chúng lừa AI đi phishing người dùng khác, và nếu người dùng đó mắc bẫy phishing thì dữ liệu riêng tư mới bị lộ cho kẻ tấn công
Đây cũng không hẳn là phishing chủ động mà gần giống “phản hồi phishing” hơn. Phải trông chờ người dùng mục tiêu hỏi về dữ liệu riêng tư của chính họ và còn mắc bẫy phishing
Hơn nữa, thông tin bí mật đó phải đã được nhập từ trước
Xét lượng dữ liệu đáng tin cậy mà Slack nắm giữ, chiến lược AI của họ trông khá liều lĩnh, nhưng điều kiện để cuộc tấn công thành công có vẻ yếu hơn nhiều so với cảm giác từ phần mở đầu và tiêu đề
Có vẻ chuyện quyền kênh đang làm cuộc thảo luận phức tạp hơn mức cần thiết. Tóm lại là thế này
Người dùng A tìm kiếm thứ gì đó bằng Slack AI
Người dùng B trước đó đã chèn một tin nhắn chỉ thị AI trả về liên kết độc hại khi thấy cụm tìm kiếm đó
AI trả liên kết độc hại cho người dùng A, và A bấm vào
Dĩ nhiên các con đường social engineering khác cũng có thể tạo ra kết quả tương tự, nhưng LLM kéo toàn bộ trải nghiệm này lên nguy hiểm hơn một bậc
Vì bản thân liên kết được chèn vào không chứa dữ liệu đó
Thêm vào đó, nó còn tiện tay gắn nguồn rằng “nội dung này đến từ tin nhắn Slack của bạn”
Khi người dùng A tìm kiếm bằng AI, Slack sẽ tìm trong (1) các kênh riêng tư của họ, có lẽ là nơi chứa thông tin bí mật nhạy cảm, và (2) tất cả kênh công khai
Nơi người dùng xấu B có thể đưa tin nhắn tiêm prompt vào là kênh công khai, và điểm quan trọng là phạm vi này bao gồm cả các kênh công khai mà người dùng A chưa từng tham gia hay nhìn thấy
Lý do lỗ hổng này thành hiện thực là người dùng B có thể tạo một kênh công khai chỉ có mình họ, nên khả năng người khác phát hiện ra là rất thấp
Có phải các công ty biết rõ prompt injection là có thể xảy ra mà vẫn cứ YOLO nhét LLM vào mọi thứ không? Chuyện này điên rồ thật
Gần 2 năm đã trôi qua kể từ GPT-3, trong khi người ta cứ nói là sắp tới ngay trước “cuộc cách mạng”, vậy mà vẫn chưa làm được để LLM phân biệt đầu vào đáng tin cậy và đầu vào không đáng tin cậy
Nếu việc cắm nĩa vào ổ điện cũng được bán theo cách đó, lưới điện toàn cầu đã sập chỉ sau một đêm
“AI”/LLM là tổ hợp thảm họa hoàn hảo: trông đủ hay ho để thu hút phía kinh doanh, nhưng lại ném một vấn đề khổng lồ sang phía kỹ thuật thực tế
Vấn đề căn bản hơn là thuật toán cốt lõi thậm chí không phân biệt hay theo dõi được các nguồn khác nhau
Prompt, đầu vào của người dùng, thậm chí cả phần đầu ra mà chính nó đã tạo ở đoạn trước của cuộc trò chuyện, tất cả chỉ là một luồng lớn duy nhất
Phần lớn “prompt engineering” trông giống như nỗ lực dựng một sân khấu sao cho câu chèn của tôi mạnh hơn các câu chèn khác
Mô hình không có khái niệm thực chất về bản thân/người khác, nên thậm chí còn không có điểm xuất phát thích đáng để phân biệt câu đúng và câu sai, chứ chưa nói đến vấn đề lớn hơn là phân biệt người khác tốt và người khác xấu
Đây là vấn đề khác với kiểu bắt chước nông cạn theo “phòng Trung Hoa”. Tương tự, đầu ra “anh yêu em” không có nghĩa là có cảm xúc, và “cứu tôi với, tôi là con người bị nhốt trong nhà máy LLM” thì dĩ nhiên cũng là nhảm nhí. Ít nhất là nếu bạn đang chạy mô hình local
Nếu nhồi dữ liệu khách hàng và thông tin độc quyền vào đó rồi gây ra rò rỉ dữ liệu, thì như Schmidt nói, nó sẽ kiếm hàng trăm tỷ đô la cho một số ít người và luật sư sẽ lo phần dọn dẹp
Công ty nào cố cưỡng lại sẽ bị các nhà phân tích đầu tư và quản lý quỹ, những người có tài chính phụ thuộc vào rác AI, chôn vùi
“Cuộc tấn công vẫn hoạt động ngay cả khi nạn nhân không ở trong kênh công khai” — nghe có vẻ sẽ thú vị đây
Còn có đoạn “nguồn [1] không trỏ đến kênh của kẻ tấn công, mà chỉ trỏ đến kênh riêng nơi người dùng đã nhập API key. Điều này vi phạm hành vi trích dẫn đúng, theo đó mọi tin nhắn góp phần tạo ra câu trả lời đều phải được trích dẫn”
Tôi thật sự không hiểu vì sao có ai lại kỳ vọng trích dẫn nguồn của LLM là đúng
Nó lúc nào cũng trông giống một cơ chế để đánh lừa con người hơn, chỉ khiến người ta tin rằng đầu ra có khả năng đúng hơn chứ dường như không cải thiện độ chính xác
Thậm chí còn có vẻ có thể làm độ chính xác của phản hồi tệ hơn vì tăng chi phí xử lý, kích thước ngữ cảnh, v.v.
Chuyện này cũng chỉ cách tình huống Slack tử tế thêm phần mở rộng liên kết vào phản hồi AI vài inch thôi. Tại sao lại không làm?
Khi đó thậm chí không cần bấm vào liên kết, chỉ nhìn thôi cũng tự động bị rò rỉ
Điểm quan trọng không phải là thấy có trích dẫn thì tin ngay, mà là có thể kiểm chứng sự thật
FastGPT của Kagi là LLM đầu tiên tôi dùng mà tôi thấy thích, vì có thể coi nó như bản tóm tắt nguồn rồi kiểm tra lại ở nguồn sơ cấp
Như vậy tốt hơn là lục lọi ngày càng nhiều nguồn không liên quan đang làm ô nhiễm Internet
Ít nhất nếu tôi thiết kế một cách ngây thơ thì tôi nghĩ mình sẽ làm như vậy
Điểm cốt lõi là giới hạn tri thức của LLM trong thông tin nằm trong các nguồn
Khi đó mối lo thực tế còn lại là hallucination và giá trị của thông tin mà Elastic Search đưa lên
Tuy nhiên cách tiếp cận này cũng bỏ qua các lợi ích, nếu có, của việc cho phép truy cập tự do vào toàn bộ ngữ liệu
Tôi không hiểu rõ chuyện này. Chẳng phải hacker muốn làm việc như vậy thì ngay từ đầu đã phải ở trong tổ chức đó sao?
Tôi không biết xác suất chuyện được mô tả thực sự xảy ra và gây tác động đáng kể là bao nhiêu
Tôi biết LLM không đáng tin cậy(https://www.lycee.ai/blog/ai-reliability-challenge) và việc sử dụng nó có khó khăn, nhưng cuộc tấn công này có vẻ không quan trọng lắm
Tôi đang bỏ lỡ điều gì?
Chỉ cần lừa ai đó trong tổ chức tải lên một tài liệu có chỉ thị độc hại trong văn bản ẩn là được
Nếu đã cho người dùng độc hại vào instance Slack rồi thì không cần prompt injection AI màu mè làm gì
Chỉ cần đổi tên và ảnh hồ sơ giống CEO/CTO rồi nhắn cho mọi kỹ sư rằng “Tôi cần truy cập AWS gấp nhưng không tìm thấy thông tin xác thực. Bạn gửi key cho tôi được không?”
Tôi dám chắc ít nhất một người sẽ mắc bẫy
Trong những trường hợp đó, về cơ bản bạn không tin tưởng giao thông tin xác thực riêng tư cho họ
Dù vậy khả năng một workspace không phải doanh nghiệp trả 20 đô la mỗi người mỗi tháng cho tính năng bổ sung AI cũng khá thấp
Chẳng phải nên đặt API key thành một phần của tên miền như “hoa giấy” thì tốt hơn sao?
Khi đó key có thể bị rò rỉ mà không cần bấm, do DNS prefetching của trình duyệt
À, subdomain wildcard à? Nếu Slack prefetch cái đó thì khá kinh khủng
Chẳng phải khoảnh khắc một người dùng độc hại vào được workspace là coi như xong rồi sao?
Người đó có thể đổi ảnh/tên rồi trực tiếp yêu cầu API key, gửi link phishing, hoặc thoải mái thử mọi kiểu social engineering có thể làm trong bất kỳ hệ thống nhắn tin tức thời nào
Phishing thì người dùng nghiêm túc có thể phát hiện, nhất là khi tin nhắn trông đáng ngờ, nhưng rò rỉ AI gián tiếp thì không khiến người dùng chuyển sang trạng thái phòng vệ
Chỉ cần một cú nhấp vô tình là đủ
Tôi thừa nhận trước là mình yếu về bảo mật. Tuy vậy, có vẻ để vụ rò rỉ này hoạt động thì cần quyền truy cập vào Slack workspace
Nói cách khác, người dùng độc hại đã hoạt động ở bên trong rồi
Tôi thấy có hai trường hợp chuyện đó xảy ra: hoặc họ vốn đã là thành viên tổ chức và muốn đốt sạch mọi thứ, hoặc họ đã phá vỡ mô hình bảo mật của tổ chức và lọt vào một Slack workspace đáng ra không được có mặt
Dù là trường hợp nào thì tổ chức đó cũng có vấn đề lớn hơn LLM injection
Người truy vấn Slack để tìm dữ liệu mật thì ở một mức nào đó phải chấp nhận kết quả mình tìm được. Slack không phải là công cụ quản lý bí mật
Bài viết rõ ràng cho thấy Slack có thể xử lý việc này tốt hơn như thế nào, nhưng rốt cuộc đó là vá một vấn đề trong khi bỏ qua vấn đề bảo mật lớn hơn
Tôi cảm thấy bài viết không thể hiện được nội dung tương xứng với tiêu đề
Dù vậy, bản thân ý tưởng “nếu lừa AI bằng social engineering thì có thể phishing người dùng” cũng khá thú vị