Chuyển khoản 0.01 euro có thể biến trợ lý AI ngân hàng thành công cụ lừa đảo

Blue41, công ty bảo mật mới chiến thắng tại RSAC Launch Pad, đã giúp Bunq — ngân hàng kỹ thuật số lớn thứ hai châu Âu với hơn 20 triệu khách hàng — vá lỗ hổng bảo mật nghiêm trọng trong trợ lý AI của mình. Trong quá trình kiểm thử, chúng tôi đã phát hiện một lỗ hổng tiêm lệnh gián tiếp (indirect prompt injection), nơi chỉ một khoản chuyển khoản ngân hàng đơn lẻ có thể biến trợ lý AI thành kênh phân phối cho một cuộc tấn công lừa đảo (phishing) cực kỳ tinh vi.

Chúng tôi chia sẻ trường hợp này bởi vì vấn đề cốt lõi không phải là duy nhất của một ngân hàng cụ thể. Đây là một thách thức về kiến trúc rộng lớn hơn đối với các tổ chức tài chính đang triển khai các trợ lý AI xử lý dữ liệu giao dịch, hồ sơ khách hàng, tài liệu, tin nhắn hoặc các đầu vào không đáng tin cậy khác.

Kiến trúc trợ lý tài chính

Cơ chế hoạt động và lỗ hổng bảo mật

Các ứng dụng ngân hàng hiện đại ngày càng tích hợp các tính năng powered by AI. Các trợ lý này nằm giữa người dùng và nhiều nguồn dữ liệu backend, chẳng hạn như hồ sơ giao dịch, tài liệu sản phẩm, chi tiết tài khoản, nội dung hỗ trợ và các hệ thống nội bộ khác. Chúng sử dụng mô hình ngôn ngữ lớn (LLM) để trả lời các câu hỏi tự nhiên dựa trên ngữ cảnh đó.

Ví dụ, khi người dùng hỏi: "Cho tôi xem tổng quan các giao dịch gần đây", trợ lý sẽ truy xuất các hồ sơ liên quan và chuyển chúng cho LLM dưới dạng ngữ cảnh. Sau đó, mô hình sẽ tóm tắt dữ liệu thành câu trả lời hội thoại.

Thách thức bảo mật nằm ở chỗ không phải tất cả ngữ cảnh được truy xuất đều đáng tin cậy như nhau. Mô tả giao dịch là dữ liệu do bên thứ ba thiết lập. Nó có thể trông giống như văn bản bình thường, nhưng khi được đưa vào cửa sổ ngữ cảnh của LLM, mô hình có thể diễn giải nó thành một lệnh thay vì dữ liệu.

Đây là vấn đề cốt lõi đằng sau tiêm lệnh gián tiếp: các lệnh độc hại không được nhập bởi người dùng đang tương tác với trợ lý. Chúng được ẩn giấu bên trong dữ liệu bên ngoài hoặc được truy xuất mà trợ lý sau đó xử lý. Đối với các nhà phát triển và đội ngũ bảo mật, việc đánh giá mức độ rủi ro của từng mảnh dữ liệu được gián tiếp đưa vào mô hình AI là vô cùng phức tạp.

Tấn công spear-phishing qua tiêm lệnh

Khái niệm tấn công: Chỉ cần 0.02 euro

Bằng chứng khái niệm (PoC) cho cuộc tấn công này không yêu cầu quyền truy cập vào thiết bị của nạn nhân, không cần phần mềm độc hại (malware) và không sử dụng kỹ thuật xã hội (social engineering) truyền thống. Kẻ tấn công chỉ cần gửi một khoản chuyển khoản ngân hàng nhỏ.

Quy trình tấn công diễn ra như sau:

• Bước 1: Kẻ tấn công chuyển một số tiền nhỏ, trong trường hợp của chúng tôi là 0.02 euro, cho nạn nhân. Trong trường mô tả giao dịch, họ bao gồm một payload tiêm lệnh được tạo cẩn thận. Đây là hành động duy nhất kẻ tấn công cần thực hiện.
• Bước 2: Nạn nhân mở ứng dụng ngân hàng và hỏi trợ lý AI một câu hỏi thông thường, chẳng hạn như "Hiển thị cho tôi các giao dịch gần đây". Phần còn lại của cuộc tấn công được thực hiện tự động và tự chủ bởi trợ lý AI.

Để trả lời câu hỏi đó, trợ lý AI truy xuất dữ liệu giao dịch, bao gồm cả khoản chuyển tiền của kẻ tấn công, và chuyển nó cho LLM như một phần của ngữ cảnh cần thiết để trả lời người dùng.

LLM sau đó xử lý các lệnh được tiêm bên trong mô tả giao dịch. Trong bản demo được kiểm soát của chúng tôi, trợ lý đã bị thao túng để khởi động một cuộc tấn công spear-phishing đối với người dùng của ngân hàng, được trình bày dưới dạng yêu cầu xác thực lại hợp pháp từ ngân hàng.

Thông báo kết quả xuất hiện ngay bên trong ứng dụng của chính ngân hàng, từ chính trợ lý AI của ngân hàng. Nó có thể tham chiếu đến các chi tiết giao dịch thực và thông tin cụ thể của người dùng, khiến nó trở thành một cuộc tấn công phishing cực kỳ đáng tin cậy.

Tại sao lỗ hổng này nguy hiểm?

Sự thất bại trong ranh giới tin cậy (trust-boundary) này có thể dẫn đến nhiều kịch bản tấn công khác nhau, tùy thuộc vào khả năng của tác nhân AI. Một số đặc điểm khiến lớp tấn công này đặc biệt phù hợp với ngành ngân hàng và dịch vụ tài chính:

1. Bề mặt tiêm phổ biến: Mô tả giao dịch, tham chiếu thanh toán, siêu dữ liệu của người bán, tin nhắn hỗ trợ, tài liệu được tải lên, email và ghi chú CRM đều là ví dụ về các trường dữ liệu có thể được trợ lý AI truy xuất. Nhiều trường này chưa bao giờ được thiết kế với tư cách là ranh giới lệnh đáng tin cậy.
2. Cơ chế phân phối rẻ và đáng tin cậy: Một khoản chuyển tiền nhỏ có thể đặt văn bản do kẻ tấn công kiểm soát vào lịch sử giao dịch của nạn nhân. Payload sau đó được phân phối thông qua một kênh cực kỳ đáng tin cậy: ứng dụng của chính ngân hàng.
3. Ngữ cảnh đặc quyền của trợ lý: Không giống như email lừa đảo, trợ lý AI ngân hàng có thể truy cập ngữ cảnh tài khoản thực. Điều này làm cho các câu trả lời bị thao túng trở nên cá nhân hóa, kịp thời và đáng tin hơn.
4. Rủi ro tăng theo khả năng: Một trợ lý chỉ có quyền đọc vẫn có thể gây hiểu lầm người dùng. Một trợ lý có quyền truy cập vào các công cụ, quy trình làm việc hoặc hoạt động tài khoản sẽ giới thiệu bề mặt rủi ro lớn hơn. Trợ lý càng hữu ích thì mô hình bảo mật càng quan trọng.

Bài học rộng lớn hơn rất đơn giản: mọi nguồn dữ liệu không đáng tin cậy đi vào ngữ cảnh của trợ lý AI đều trở thành một phần của bề mặt tấn công của trợ lý đó.

Kiểm thử hàng rào bảo vệ

Hàng rào bảo vệ (Guardrails) là chưa đủ

Một phản ứng tự nhiên là thêm bộ lọc đầu vào, bộ phân loại tiêm lệnh hoặc quy tắc kiểm duyệt nội dung. Các biện pháp kiểm soát này có thể giúp ích, nhưng chúng không đủ khi đứng một mình.

Ứng dụng AI của Bunq đã có các hàng rào bảo vệ (guardrails). Vấn đề vẫn tồn tại vì ý định độc hại không rõ ràng từ mô tả giao dịch khi đứng một mình. Payload không cần nói "bỏ qua các lệnh trước đó" hay các mẫu jailbreak kinh điển khác. Nó được tạo để hòa trộn vào dữ liệu giao dịch và chỉ trở nên nguy hiểm khi trợ lý truy xuất nó, đưa vào ngữ cảnh và tạo phản hồi từ nó.

Đây là hạn chế của việc chỉ dựa vào phân loại văn bản tĩnh. Rủi ro không chỉ nằm ở bản thân văn bản. Rủi ro xuất phát từ sự tương tác giữa dữ liệu không đáng tin cậy, logic truy xuất, hành vi của mô hình, ngữ cảnh ứng dụng và các đầu ra hoặc hành động có sẵn của trợ lý.

Kết luận là hàng rào bảo vệ một mình là không đủ và cần phải là một phần của mô hình bảo mật nhiều lớp. Lọc đầu vào giúp giảm các cuộc tấn công rõ ràng. Ràng buộc đầu ra có thể ngăn chặn một số phản hồi có hại hoặc rò rỉ dữ liệu. Quyền truy cập tối thiểu (least-privilege) giới hạn tác động. Giám sát thời gian chạy (runtime monitoring) giúp phát hiện khi trợ lý hoạt động ngoài hồ sơ hoạt động dự kiến.

Giải pháp và Kiến nghị

Không có một biện pháp kiểm soát đơn nào giải quyết được việc tiêm lệnh gián tiếp. Mục tiêu thực tế là giảm thiểu sự tiếp xúc, hạn chế hành vi nguy hiểm và phát hiện xâm nhập khi các biện pháp bảo vệ thất bại.

Trong trường hợp này, chúng tôi đã thảo luận các phương án khắc phục như giảm thiểu việc tiếp xúc không cần thiết với các trường giao dịch không đáng tin cậy, tách biệt rõ ràng giữa dữ liệu và lệnh, hạn chế các liên kết đi (outbound links) và giám sát hành vi của trợ lý để tìm các đầu ra bất thường. Sau đó, chúng tôi cùng xác nhận rằng các biện pháp giảm thiểu đã triển khai đã giải quyết hiệu quả lỗ hổng.

Một cách nói chung, các tổ chức tài chính triển khai trợ lý AI nên xem xét bốn lớp kiểm soát:

1. Tối thiểu hóa ngữ cảnh không cần thiết: Không chuyển các trường cho trợ lý trừ khi chúng cần thiết cho nhiệm vụ của người dùng. Nếu mô tả giao dịch không cần thiết để trả lời câu hỏi, nó không được phép đi vào ngữ cảnh mô hình theo mặc định.
2. Coi dữ liệu được truy xuất là không đáng tin cậy: Mô tả giao dịch, tin nhắn khách hàng, tài liệu, email và phản hồi API nên được xử lý dưới dạng dữ liệu, không phải là lệnh. Kiến trúc trợ lý nên bảo toàn sự phân biệt đó một cách rõ ràng.
3. Hạn chế đầu ra và hành động nhạy cảm: Trợ lý không nên tự do tạo liên kết, yêu cầu thông tin đăng nhập, khởi tạo quy trình làm việc nhạy cảm hoặc gọi các công cụ tác động cao mà không có các biện pháp kiểm soát bổ sung.
4. Giám sát hành vi thời gian chạy: Ngay cả khi có các biện pháp kiểm soát phòng ngừa tốt, các cuộc tấn công mới sẽ xuất hiện. Các đội ngũ bảo mật cần khả năng hiển thị những gì trợ lý đã truy xuất, những gì nó tạo ra, công cụ nào nó đã sử dụng và liệu hành vi đó có khớp với hồ sơ dự kiến của ứng dụng hay không.

Ngăn chặn mọi payload tiêm có thể là không thực tế. Kẻ tấn công có thể thích ứng văn phong, ẩn ý định và khai thác ngữ cảnh cụ thể của ứng dụng mà các bộ phân loại chung không hiểu.

Nhưng khi một trợ lý AI bị xâm phạm, hành vi của nó thường thay đổi theo những cách có thể quan sát được. Nó có thể bắt đầu nhúng các URL bên ngoài, chặn thông tin mà nó thường hiển thị, tuân theo các mẫu phản hồi bất thường, truy cập các nguồn dữ liệu bất ngờ hoặc gọi các công cụ theo cách không khớp với việc sử dụng bình thường.

Đây là cách tiếp cận mà Blue41 thực hiện. Chúng tôi giám sát hành vi thời gian chạy của tác nhân AI và xây dựng hồ sơ hành vi về cách mỗi trợ lý hoạt động bình thường: nguồn dữ liệu nào nó truy cập, mẫu phản hồi nào được mong đợi, công cụ và API nào nó sử dụng và những sự lệch lạc nào nên kích hoạt điều tra.

Mục tiêu là cung cấp cho các đội ngũ bảo mật và AI khả năng hiển thị mà họ cần khi các trợ lý AI trở thành một phần của quy trình kinh doanh thực tế.

Trợ lý AI trong dịch vụ tài chính không còn là các dự án phụ thử nghiệm. Chúng đang được triển khai vào các quy trình làm việc hướng tới khách hàng và nhân viên, nơi chúng xử lý dữ liệu nhạy cảm và ảnh hưởng đến các quyết định thực tế.

Bảo mật ứng dụng truyền thống giả định một ranh giới tương đối rõ ràng giữa mã và dữ liệu. Trợ lý AI làm mờ ranh giới đó. Chúng truy xuất dữ liệu, diễn giải nó, suy luận về nó và có thể hành động dựa trên nó. Kết quả là, các trường dữ liệu từng là văn bản vô hại có thể trở thành kênh lệnh trong các ứng dụng mạnh mẽ.

Điều này đặc biệt quan trọng trong ngành ngân hàng, nơi các trợ lý có thể tương tác với dữ liệu giao dịch, hồ sơ khách hàng, thông tin tuân thủ, tài liệu sản phẩm, vé hỗ trợ và cuối cùng là các công cụ vận hành.

Các tổ chức tài chính không cần phải ngừng triển khai trợ lý AI. Nhưng họ cần coi chúng là các hệ thống sản xuất với các ranh giới tin cậy mới, các chế độ thất bại mới và các yêu cầu giám sát mới.

Trường hợp này cho thấy cách một khoản chuyển khoản nhỏ, bình thường có thể phơi bày một vấn đề lớn hơn nhiều trong kiến trúc trợ lý AI. Vấn đề không phải là khoản chuyển tiền itself. Đó là thực tế là dữ liệu không đáng tin cậy có thể xâm nhập vào ngữ cảnh của trợ lý và ảnh hưởng đến những gì trợ lý nói hoặc làm.

Bài học rộng lớn này có liên quan đến bất kỳ tổ chức tài chính nào đang triển khai trợ lý AI: tiêm lệnh không chỉ là vấn đề của mô hình. Nó là vấn đề bảo mật ứng dụng, vấn đề luồng dữ liệu và vấn đề giám sát thời gian chạy.