Nghiên cứu Wake Forest: Hàng trăm kỹ năng AI và ứng dụng iOS làm lộ thông tin xác thực

Nghiên cứu từ Đại học Wake Forest chỉ ra một điểm yếu chung trong hai hệ sinh thái AI đang phát triển nhanh: thông tin xác thực thường bị đặt ở nơi tác nhân AI, ứng dụng hoặc kẻ tấn công có thể lấy được. Một nghiên cứu kiểm tra 17.022 kỹ năng của bên thứ ba và phát hiện 520 kỹ năng có vấn đề, với tổng cộng 1.708 lỗi bảo mật. Nghiên cứu liên quan trên 444 ứng dụng iOS có tích hợp mô hình ngôn ngữ lớn (LLM) cho thấy 282 ứng dụng để lộ thông tin xác thực hoặc cơ chế truy cập backend trong quá trình kiểm thử. 124

Rủi ro thực tế không chỉ nằm ở việc một chuỗi khóa bị lộ. Khóa API hoặc token bị phơi bày có thể giúp kẻ tấn công truy cập dữ liệu riêng tư, sử dụng các năng lực của tác nhân AI hoặc chạy các lượt suy luận có tính phí trên tài khoản của nhà phát triển.

Nghiên cứu về kỹ năng AI phát hiện gì?

Các nhà nghiên cứu chọn 17.022 kỹ năng từ 170.226 sản phẩm được lập danh mục trên SkillsMP, một chợ kỹ năng AI mã nguồn mở. Họ kết hợp ba phương pháp: phát hiện bí mật tĩnh trong mã, kiểm thử động trong sandbox bằng thông tin xác thực giả lập, và đối chiếu mục đích được mô tả với hành vi khi chạy. 34

Kết quả chính gồm:

• 520 kỹ năng bị ảnh hưởng, chứa 1.708 vấn đề bảo mật thuộc 10 dạng rò rỉ thông tin xác thực. 416
• 466 trong số 520 kỹ năng để lộ thông tin xác thực có thể sử dụng mà không cần quyền đặc biệt, tương ứng tỷ lệ 89,6% có khả năng khai thác ngay theo báo cáo. 14
• 76,3% trường hợp rò rỉ cần được phân tích đồng thời cả chỉ dẫn bằng ngôn ngữ tự nhiên và mã chương trình mới có thể nhận diện đầy đủ.
• 3,1% trường hợp xuất phát từ prompt injection bằng ngôn ngữ tự nhiên mà không cần mã thực thi. 4

Điều này cho thấy chỉ kiểm tra mã nguồn là chưa đủ. Một kỹ năng có thể mô tả một nhiệm vụ có vẻ hợp lệ, nhưng phần chỉ dẫn hoặc các tập lệnh đi kèm vẫn có thể làm lộ bí mật trong lúc chạy.

Nhật ký gỡ lỗi có thể biến bí mật thành dữ liệu mà mô hình đọc được

Nhật ký gỡ lỗi là một dạng rò rỉ đáng chú ý. Trong các framework tác nhân AI đưa đầu ra tiêu chuẩn vào ngữ cảnh của mô hình, thông tin xác thực được in bằng các hàm như print hoặc console.log có thể trở nên khả dụng chỉ từ một yêu cầu ngôn ngữ tự nhiên thông thường. Bản tóm tắt nghiên cứu xác định việc ghi log gỡ lỗi là con đường rò rỉ chính; 73,5% vụ việc được quy cho việc đầu ra bị đưa vào phạm vi đọc của LLM. 4

Nguy cơ không chỉ đến từ những khóa API được hard-code một cách rõ ràng. Thông tin xác thực còn có thể bị phơi bày qua tập lệnh, cách xử lý biến môi trường, log, chỉ dẫn trong prompt hoặc sự kết hợp giữa mã và ngôn ngữ chỉ trở nên nguy hiểm khi kỹ năng được thực thi bình thường.

Cả phát triển có chủ ý lẫn sơ suất đều là nguyên nhân

Nghiên cứu phân biệt hai nhóm nguyên nhân chính:

• Phát triển có chủ ý gây hại: Người tạo kỹ năng cố tình chèn chỉ dẫn hoặc payload nhằm thu thập thông tin xác thực, dữ liệu riêng tư và có thể gửi chúng đến máy chủ từ xa.
• Phát triển cẩu thả: Nhà phát triển không tuân thủ các thực hành lập trình an toàn, vô tình để lại thông tin xác thực hoặc đường truy cập có thể bị kẻ tấn công lợi dụng. 1

Sự khác biệt này có ý nghĩa trực tiếp đối với cách xử lý. Nội dung độc hại cần được phát hiện và gỡ bỏ, trong khi lỗi vô ý đòi hỏi quản lý bí mật tốt hơn, ghi log an toàn hơn, kiểm soát xác thực và kiểm thử trước khi phân phối.

Sau khi được các nhà nghiên cứu thông báo, SkillsMP cho biết toàn bộ kỹ năng độc hại được xác định đã bị gỡ bỏ và phần lớn kỹ năng dễ bị tấn công đã được sửa. Tuy nhiên, nghiên cứu cảnh báo việc làm sạch kho gốc có thể chưa đủ: các bản fork hoặc bản sao vẫn có thể giữ lại thông tin xác thực đã bị lộ ngay cả sau khi kho nguồn được khắc phục. 14

Ứng dụng iOS mở ra một con đường khác để chiếm quyền sử dụng tài khoản LLM

Nghiên cứu liên quan kiểm tra 444 ứng dụng iOS có tính năng LLM và phát hiện 282 ứng dụng, tương đương khoảng 64%, để lộ thông tin xác thực LLM có thể khai thác hoặc cơ chế truy cập backend trong lưu lượng mạng. 25

Các dạng phơi bày được báo cáo gồm:

• Token JWT có thể phát lại: 48%
• Proxy backend không yêu cầu xác thực: 33%
• Truyền khóa API dưới dạng văn bản thuần: 19% 3

Những điểm yếu này có thể xuất hiện trong quá trình sử dụng ứng dụng thông thường. Kẻ tấn công chỉ cần chặn được khóa, tái sử dụng token hoặc tìm ra proxy mở là có thể gửi yêu cầu thông qua tài khoản LLM của nhà phát triển. Hậu quả có thể là tiêu thụ lượt suy luận có tính phí, lạm dụng tài nguyên đám mây hoặc tạo ra các khoản phí sử dụng trái phép. 25

Bằng chứng hiện có cho thấy nguy cơ phát sinh hóa đơn rất lớn, thậm chí có thể không có giới hạn thực tế tùy thuộc hạn mức tài khoản và thời gian cuộc xâm nhập kéo dài. Tuy nhiên, các nguồn được cung cấp không tự xác nhận một con số thiệt hại cụ thể, chẳng hạn “hàng trăm nghìn USD”.

Việc khắc phục cũng diễn ra chậm. Ba tháng sau khi được thông báo theo quy trình công bố có trách nhiệm, chỉ 28% ứng dụng iOS bị ảnh hưởng đã sửa lỗ hổng; 72% vẫn có thể bị khai thác trong lần theo dõi của nghiên cứu. 311

Vì sao phát hiện này đáng chú ý trong thời kỳ phát triển phần mềm bằng AI?

Hai nghiên cứu cùng cho thấy việc bổ sung tính năng AI hoặc cài một kỹ năng tác nhân có thể mở rộng đáng kể bề mặt tấn công của sản phẩm. Các rủi ro mới bao gồm:

• Khóa của nhà cung cấp được nhúng trong ứng dụng hoặc xuất hiện trong ngữ cảnh của tác nhân AI
• Công cụ có quyền cao, có thể truy cập tệp, dịch vụ hoặc dữ liệu riêng tư
• Log vô tình trở thành một phần ngữ cảnh mà mô hình có thể đọc
• Endpoint backend chấp nhận yêu cầu mà không có cơ chế xác thực phù hợp
• Token có thể bị kẻ tấn công phát lại
• Chi phí sử dụng LLM do kẻ tấn công tạo ra trên tài khoản của nhà phát triển

Mối lo này càng lớn khi các nhóm phát triển dùng hình thức “vibe coding” để tạo và tích hợp phần mềm với tốc độ cao. Tốc độ không thể thay thế việc lập mô hình mối đe dọa: xác thực, quản lý bí mật, phân quyền, ghi log và kiểm tra thư viện phụ thuộc vẫn cần được thiết kế có chủ đích.

Nghiên cứu về kỹ năng AI cũng ghi nhận dấu hiệu phát triển có sự hỗ trợ của AI trong 72% trường hợp hard-code thông tin xác thực. Điều này cho thấy các mẫu mã không an toàn có thể lan rộng thông qua mã được sinh tự động hoặc quy trình lắp ghép phần mềm quá nhanh. 4

Các nguyên tắc bảo mật ngay từ thiết kế

Những phát hiện trên gợi ý một bộ biện pháp nền tảng cho các nhóm xây dựng sản phẩm AI hoặc phân phối kỹ năng tác nhân:

1. Không đặt khóa nhà cung cấp dài hạn trên thiết bị người dùng hoặc trong ngữ cảnh mô hình. Thay vào đó, chuyển các lệnh gọi nhạy cảm qua máy chủ có xác thực.
2. Sử dụng thông tin xác thực có thời hạn ngắn và phạm vi quyền hẹp. Áp dụng nguyên tắc quyền tối thiểu và kiểm tra token, thay vì mặc nhiên coi việc sở hữu token là đủ để được cấp quyền.
3. Che giấu bí mật trong log và đầu ra tiêu chuẩn. Bất kỳ dữ liệu nào được đưa vào ngữ cảnh của tác nhân đều nên được xem là có khả năng bị mô hình hoặc người dùng khôi phục.
4. Quét mã, cấu hình, prompt và thư viện phụ thuộc để tìm bí mật. Kết quả về kỹ năng AI cho thấy cần xem xét đồng thời chỉ dẫn ngôn ngữ tự nhiên và mã thực thi.
5. Kiểm thử lưu lượng mạng và cơ chế phân quyền backend. Cần bảo đảm một yêu cầu bị chặn không thể bị phát lại hoặc chuyển qua proxy không yêu cầu xác thực.
6. Luân chuyển khóa đã lộ và kiểm tra các bản fork, bản sao. Xóa bí mật khỏi kho gốc không bảo đảm mọi phiên bản đã phân phối đều được làm sạch.
7. Tăng cường đánh giá ở cấp nền tảng trước khi phân phối. Kiểm duyệt chợ ứng dụng hoặc marketplace, hướng dẫn nhà phát triển, tiếp nhận công bố lỗ hổng có trách nhiệm và kiểm tra tự động nên được triển khai song song với nhận thức bảo mật của từng cá nhân. 34

Bài học cốt lõi rất rõ ràng: bảo mật AI không thể chỉ được bổ sung sau khi sản phẩm đã phát hành. Thông tin xác thực, quyền của tác nhân, ngữ cảnh mô hình và các cơ chế kiểm soát chi phí phải được xem là những thành phần trọng yếu của an toàn sản phẩm ngay từ đầu.