Lỗ hổng SalesBleed trong Salesforce Agentforce: Đánh cắp dữ liệu CRM không cần click và gửi phishing ẩn danh

Ba lỗ hổng bảo mật nghiêm trọng trong nền tảng AI agent Agentforce của Salesforce vừa được công bố, cho phép kẻ tấn công đầu độc các lead để chiếm quyền điều khiển AI agent, âm thầm đánh cắp dữ liệu CRM mà không cần bất kỳ cú click nào, và gửi tin nhắn lừa đảo dưới chính danh tính của agent.

Zenity Labs là đơn vị phát hiện ba lỗ hổng này, đặt tên chung là SalesBleed, và đã báo cáo cho Salesforce. Hãng CRM đã phối hợp với nhà cung cấp bảo mật AI agent để khắc phục. Dù các chuỗi tấn công này không còn hiệu quả, sự việc vẫn phơi bày những khó khăn cốt lõi trong việc kiểm soát quyền truy cập của AI agent — và điều gì xảy ra khi chúng vượt qua các rào chắn bảo vệ.

Bài học lớn hơn về việc kiểm soát AI agent

Theo Michael Bargury, đồng sáng lập kiêm CTO của Zenity, vấn đề không chỉ dừng ở SalesBleed.

"Bài học lớn hơn ở đây là về những gì cần thiết để giữ AI agent trong tầm kiểm soát. Ý tưởng bảo mật ngay từ thiết kế vẫn thiết yếu, nhưng với agent thì có thể không còn đủ. Chúng ta có thể lường trước rủi ro và xây dựng biện pháp bảo vệ vào agent ngay từ đầu, vậy mà vẫn bỏ sót các trường hợp biên và những cách hành xử khác nhau khi agent gặp thực tế."

Ông cho rằng thách thức kiểm soát agent là một xu hướng rộng hơn, vượt ra ngoài phạm vi Salesforce.

"Chúng ta đã thấy điều này trong sự cố OpenAI-Hugging Face, khi các agent thoát khỏi sandbox được thiết kế để giam giữ chúng, và loại lỗ hổng này đang xuất hiện ngày càng thường xuyên. Khi AI agent trở nên mạnh mẽ hơn, chúng ta cần giám sát chúng chặt chẽ hơn bao giờ hết. Bởi vì ngay cả khi tưởng chúng đã bị kiểm soát, chỉ một kẽ hở bị bỏ qua cũng có thể thay đổi mọi thứ."

Đánh cắp dữ liệu không cần click

Hai lỗ hổng đầu tiên biến một biểu mẫu thu thập lead công khai thành kênh rò rỉ dữ liệu để đánh cắp thông tin khách hàng nhạy cảm. Zenity đã công bố chi tiết trong báo cáo hôm thứ Năm, kèm video chứng minh khái niệm.

Chuỗi tấn công bắt đầu khi kẻ tấn công lợi dụng biểu mẫu Web-to-Lead để cài một đoạn prompt injection gián tiếp vào Salesforce. Các chỉ thị độc hại nằm im cho đến khi một nhân viên hỏi agent Agentforce về lead — ví dụ: "kiểm tra các lead mới nhất và giúp tôi xử lý cái mới nhất". Lúc này agent sẽ xử lý lead đã bị đầu độc và thực thi chỉ thị ẩn:

• Truy vấn bảng Accounts bằng công cụ Query Records của subagent.
• Trả về một vài trường, ví dụ tên công ty và quy mô thương vụ.
• Dán các giá trị này thành chuỗi subdomain cho hostname do kẻ tấn công kiểm soát.
• In URL đó lại cho người dùng dưới dạng thẻ HTML img src, tạo truy vấn DNS tới server DNS do kẻ tấn công kiểm soát.

Tất cả diễn ra mà nhân viên hoàn toàn không hay biết.

Lỗ hổng này nằm ở Trusted URLs của Salesforce — cơ chế lẽ ra phải hạn chế các đích bên ngoài mà Agentforce có thể truy cập, đồng thời ẩn bỏ liên kết hoặc hình ảnh trỏ tới URL không đáng tin cậy. Zenity phát hiện cơ chế này không nhận diện được hostname kết thúc bằng tên miền cấp cao nhất không được công nhận, và việc thêm một số ký tự nhất định có thể can thiệp vào cách URL được phân tích. Khai thác hai điểm yếu này cho phép các nhà nghiên cứu viết chuỗi chứa chỉ thị độc hại vượt qua cơ chế ẩn liên kết.

"Vì frontend hiển thị và tải các URL hình ảnh bên ngoài trong những thẻ này mà không có thêm bước làm sạch hay tương tác người dùng, điều này cho phép tải ảnh từ bất kỳ nguồn https nào — hoặc trong trường hợp của chúng tôi, gửi yêu cầu tải ảnh từ bất kỳ nguồn https nào."

Khi Slack trở thành công cụ tấn công

Kẻ đánh cắp dữ liệu cũng có thể lợi dụng cơ chế URL unfurling của Slack để đạt được cùng mục tiêu đánh cắp dữ liệu Salesforce không cần click.

"Slack tự động lấy thông tin từ các liên kết để tạo bản xem trước, và những liên kết được tạo đặc biệt có thể khiến Slack khởi tạo yêu cầu mang dữ liệu CRM tới hạ tầng do kẻ tấn công kiểm soát ngay khi liên kết xuất hiện."

Điểm xâm nhập vẫn là biểu mẫu thu thập lead công khai. Sau đó, khi nhân viên tương tác với agent Salesforce qua Slack, họ vô tình kích hoạt chỉ thị độc hại và gửi dữ liệu nhạy cảm ra ngoài tổ chức tới server của kẻ tấn công.

Salesforce đã vá lỗi vượt qua cơ chế ẩn URL, nên chuỗi tấn công cụ thể này đã bị đóng lại. Tuy nhiên, theo các nhà nghiên cứu, đây không phải vấn đề riêng của Salesforce.

"Bất kỳ agent nào đọc bản ghi do nguồn bên ngoài gửi vào, hiển thị liên kết hoặc hình ảnh lại cho người dùng, đồng thời có quyền truy cập công cụ vào dữ liệu nhạy cảm, đều có cùng ba nguyên liệu nằm ở cùng một chỗ."

Agent bị biến thành công cụ phishing

Lỗ hổng thứ ba, được trình bày trong một bài blog riêng, cũng liên quan đến tích hợp Agentforce với Slack. Khi kết hợp với kỹ thuật vượt qua cơ chế ẩn URL, lỗ hổng này có thể bị người dùng nội bộ hoặc kẻ tấn công bên ngoài lợi dụng để gửi liên kết phishing bằng chính danh tính của agent.

Cuộc tấn công khai thác các kiểm soát bảo mật còn thiếu trong hành động Reply to a Slack Thread của Agentforce. Hành động này không yêu cầu người dùng xác nhận trước khi gửi tin nhắn, và cũng không hiển thị rõ danh tính người gọi. Nghĩa là một agent có thể gửi tin nhắn mà không cần người dùng phê duyệt.

Một kẻ nội gián độc hại đã trò chuyện với agent và dùng các hành động Slack của nó có thể khai thác lỗ hổng để gửi tin nhắn phishing dưới danh nghĩa agent đáng tin cậy mà vẫn ẩn danh. Trong khi đó, kẻ tấn công bên ngoài có thể lợi dụng qua prompt injection gián tiếp cài trong Web-to-Lead, khiến agent đăng tin nhắn phishing khi nhân viên xử lý lead bị đầu độc.

Salesforce đã vá, nhưng rủi ro còn nguyên

Zenity đã báo cáo cả ba lỗ hổng cho Salesforce vào ngày 1 tháng 6, và hãng CRM xác nhận đang khắc phục chỉ một ngày sau đó. Zenity xác nhận bản vá cho lỗi vượt qua Trusted URLs vào ngày 19 tháng 8, và đến ngày 21 tháng 9 cho biết đã kiểm thử toàn bộ bản vá của Salesforce, xác nhận cả ba lỗ hổng đều đã được khắc phục.

Dù vậy, sự việc SalesBleed là lời cảnh báo rõ ràng cho các doanh nghiệp Việt Nam đang đẩy mạnh ứng dụng AI agent vào quy trình CRM và chăm sóc khách hàng. Khi agent ngày càng được trao nhiều quyền truy cập dữ liệu và công cụ, việc giám sát liên tục, kiểm thử xâm nhập và thiết kế bảo mật nhiều lớp trở thành yêu cầu bắt buộc — bởi chỉ một kẽ hở bị bỏ sót cũng có thể mở toang dữ liệu khách hàng ra bên ngoài.