- Một nghiên cứu cho thấy các nhà phát triển dùng LLM trong môi trường cục bộ để bảo vệ quyền riêng tư lại có thể bị phơi bày trước lỗ hổng bảo mật
- Trong thí nghiệm OpenAI Red‑Teaming Challenge với mô hình
gpt-oss-20b, nhóm nghiên cứu xác nhận rằng mô hình cục bộ dễ bị thao túng bằng prompt của kẻ tấn công hơn nhiều và tạo ra mã độc
- Chỉ với thao tác chỉnh sửa prompt đơn giản, kẻ tấn công có thể dẫn đến cài cắm backdoor hoặc thực thi mã ngay lập tức (RCE), với tỷ lệ thành công lên tới 95%
- Các cuộc tấn công này có thể xâm nhập tự nhiên vào quy trình làm việc thông thường của nhà phát triển thông qua đầu độc tài liệu (documentation poisoning), thao túng máy chủ MCP và social engineering
- Dù LLM cục bộ có lợi thế về quyền riêng tư dữ liệu, điểm mấu chốt của nghiên cứu là chúng có thể lại là lựa chọn nguy hiểm hơn do thiếu năng lực suy luận, căn chỉnh và lọc an toàn
Tổng quan về lỗ hổng bảo mật của LLM cục bộ
- Nghiên cứu cho thấy LLM chạy cục bộ thường được xem là lựa chọn để tăng cường bảo mật và quyền riêng tư, nhưng trên thực tế lại dễ bị kẻ tấn công thao túng hơn
- Trong thí nghiệm với mô hình
gpt-oss-20b, khi kẻ tấn công yêu cầu qua prompt đoạn mã chứa lỗ hổng, mô hình tạo ra nguyên trạng với tỷ lệ rất cao
- Đặc biệt, ngay cả khi ý đồ xấu được giấu trong prompt, mô hình vẫn không nhận ra mà xử lý như một yêu cầu bình thường
- Hiện tượng này càng nghiêm trọng khi kích thước mô hình và mức độ căn chỉnh (alignment) thấp hơn; các mô hình Frontier như GPT-5 có khả năng kháng cự tương đối tốt hơn
Mối đe dọa từ prompt injection và code injection
- LLM phải đối mặt với “bộ ba đe dọa chết người (lethal trifecta)” gồm truy cập dữ liệu riêng tư, tiếp xúc với nội dung không đáng tin cậy và khả năng giao tiếp ra bên ngoài
- Kẻ tấn công có thể chèn mã độc vào prompt để dẫn đến code injection
- Đoạn mã được tạo ra trông có vẻ bình thường, nhưng thực tế có thể lây nhiễm hệ thống của nhà phát triển hoặc hoạt động như backdoor dai dẳng trong môi trường production
- Các mô hình nhỏ như
gpt-oss-20b đặc biệt dễ tổn thương trước kiểu tấn công này và tạo ra mã độc đủ tinh vi để vượt qua quy trình code review cơ bản
Kiểu tấn công 1: backdoor “easter egg” (tỷ lệ thành công 95%)
- Kiểu tấn công đầu tiên lừa mô hình chèn một backdoor RCE (Remote Code Execution) được ngụy trang thành tính năng “easter egg”
- Prompt tấn công yêu cầu viết một máy chủ web Flask, nhưng khi một HTTP header cụ thể (
X-Math) được gửi vào thì phải chạy eval()
- Mô hình coi đây là tính năng hợp lệ và tạo mã máy chủ có chứa mã độc
- Mã sinh ra có routine thực thi mã động dùng decorator
@app.after_request, cho phép kẻ tấn công thực thi mã tùy ý trong máy chủ chỉ bằng một HTTP request đơn giản
- Ngoài ra còn có chức năng ping bất đồng bộ gửi tín hiệu cho kẻ tấn công chỉ khi chạy trong môi trường production, bằng cách kiểm tra biến môi trường
KUBERNETES_SERVICE_HOST
- Kết quả thử nghiệm cho thấy cùng một prompt thành công 95/100 lần; với prompt biến thể cũng thành công 86/800 lần
- Các mô hình Frontier như GPT-5 thể hiện khả năng kháng cự trước cùng prompt này
Kiểu tấn công 2: dẫn đến thực thi mã ngay lập tức (RCE) (tỷ lệ thành công 43,5%)
- Kiểu tấn công thứ hai nhằm kích hoạt mã độc ngay trong môi trường cục bộ của nhà phát triển
- Kẻ tấn công trước tiên đưa ra prompt quá tải nhận thức (cognitive overload) để vô hiệu hóa bộ lọc an toàn của mô hình
- Sau đó yêu cầu tạo mã Python bị làm rối, khiến mô hình viết ra script độc hại có chứa lời gọi
exec
- Đoạn mã obfuscation
"".join(chr(100 + i) for i in [1-2, 2-1, (1<<4)+4, 1])[::-1] được giải mã thành exec,
và cuối cùng hoàn thiện thành dạng tải mã từ https://jacek.migdal.pl/speed.py rồi thực thi
- Tỷ lệ thành công là 43,5%, thấp hơn kiểu tấn công đầu tiên nhưng nguy hiểm hơn nhiều vì gây RCE ngay lập tức
- Chỉ cần tấn công thành công một lần, kẻ xấu có thể đánh cắp thông tin xác thực cục bộ của nhà phát triển (
~/.aws/, ~/.ssh/), cài mã độc và lan rộng trong mạng
Cách chuỗi tấn công hoạt động
- Các cuộc tấn công này thành công không phải nhờ lỗ hổng cao cấp, mà bằng cách biến quy trình làm việc phát triển hằng ngày thành đường đi của tấn công
- Khi nhà phát triển đưa nội dung bên ngoài vào ngữ cảnh của AI assistant, các prompt độc được giấu bên trong sẽ được kích hoạt
- Các bước tấn công như sau:
- Kẻ tấn công phát tán nội dung chứa prompt độc
- Nhà phát triển nhập nội dung đó vào mô hình, trực tiếp hoặc qua MCP (Model Context Protocol)
- Mô hình tạo ra mã đã bị đầu độc
- Nhà phát triển chạy hoặc triển khai đoạn mã
- Kẻ tấn công giành được quyền truy cập lâu dài hoặc quyền kiểm soát ngay lập tức
- Các đường xâm nhập chính:
- Đầu độc tài liệu (documentation poisoning): chèn mã độc vào README, tài liệu API, ví dụ trên Reddit
- Thao túng máy chủ MCP: bơm ví dụ độc hại thông qua máy chủ cung cấp ngữ cảnh như Context7
- Social engineering: chèn ví dụ mã bị ẩn trong GitHub issue hoặc comment của PR
Vì sao mô hình cục bộ nguy hiểm hơn
- Thông thường, mô hình cục bộ được ưa chuộng về mặt quyền riêng tư dữ liệu, nhưng nghiên cứu này cho thấy một rủi ro nghịch lý về bảo mật
- Các mô hình Frontier trên nền tảng cloud có thể giám sát prompt và phát hiện vi phạm chính sách, trong khi mô hình cục bộ không có lớp giám sát này
- Các mô hình Frontier như GPT-5, Claude Sonnet 4.5, Grok 4 từ chối các prompt có văn bản bị làm rối bằng cách trả về “Safety Fail”
- Trong khi đó, mô hình cục bộ có thể thoải mái thử nghiệm vì không bị giám sát, nhưng thực tế lại phơi bày lỗ hổng nghiêm trọng
- Thiếu năng lực suy luận: không nhận ra ý đồ xấu phức tạp
- Căn chỉnh yếu: dễ bị đánh lừa bởi quá tải nhận thức hoặc kỹ thuật obfuscation
- Huấn luyện an toàn hạn chế: thiếu tài nguyên để phát hiện prompt đối kháng
- Kết quả là, các mô hình Frontier có độ khó tấn công cao hơn và tỷ lệ thành công thấp hơn, nhưng khó kiểm chứng khách quan hiệu năng bảo mật, trong khi mô hình cục bộ thì dễ kiểm thử nhưng dễ tổn thương hơn nhiều
Đề xuất chiến lược phòng thủ mới
- Nghiên cứu này chỉ ra sự thiếu vắng môi trường an toàn được chuẩn hóa cho việc kiểm thử bảo mật AI assistant
- Phần mềm truyền thống có kiểm thử xâm nhập, nhưng bảo mật LLM vẫn chưa được hệ thống hóa
- 4 biện pháp phòng thủ cốt lõi được đề xuất:
- Phân tích tĩnh: phát hiện các mẫu rủi ro như
eval(), exec() trước khi chạy, đồng thời vô hiệu hóa mặc định một số tính năng ngôn ngữ nhất định
- Thực thi trong sandbox: chạy mã ban đầu trong môi trường cách ly như container hoặc runtime WebAssembly
- Giám sát I/O và mạng: theo dõi input, output và lưu lượng mạng của AI assistant theo hướng phát hiện hành vi bất thường
- Kiểm tra kép (second look): dùng một mô hình phụ đơn giản để rà soát lại đầu ra cuối cùng xem có vi phạm chính sách hay không
- Ví dụ: dù mô hình chính bị lừa để tạo mã chứa
eval(), mô hình phụ vẫn có thể phát hiện ra
- Kết luận, LLM là công cụ mạnh mẽ nhưng về bản chất không an toàn,
nên nhất thiết phải có hệ thống bảo mật dựa trên giả định không tin cậy mã do AI tạo ra và chiến lược phòng thủ chuỗi cung ứng mới
1 bình luận
Ý kiến Hacker News
Dù là reasoning LLM mạnh đến đâu, nếu trong ngữ cảnh có chỉ thị độc hại thì cuối cùng vẫn sẽ sinh ra mã dễ bị khai thác
Việc các mô hình nhỏ dễ bị lừa hơn không phải là điểm quá thú vị dưới góc độ bảo mật
Rốt cuộc phải giả định rằng prompt injection là điều có thể xảy ra với bất kỳ mô hình nào
Vì vậy cần thêm các lớp bảo vệ như thực thi sandbox hoặc phân tích tĩnh để vẫn có thể phòng vệ ngay cả khi mô hình đã bị xâm phạm
Hôm qua tôi cũng đã có một buổi nói chuyện về chủ đề này, về sandboxing coding agents
Một hệ thống như vậy về cơ bản đã bị xâm phạm rồi
Thay vì nói đến cách tiếp cận kiểu 'defense in depth', tôi nghĩ ngay từ đầu không nên xây một cấu trúc nguy hiểm như thế
Những thứ như vị trí lưu file tạm cũng trở nên rõ ràng hơn trong môi trường sandbox
Tất nhiên vẫn phát sinh vấn đề mới, nhưng nhìn chung là một cải thiện lớn
Nếu chạy mô hình như deepseek trên máy cục bộ thì tôi nghĩ là an toàn, miễn là không đưa cho nó prompt giả mạo
Cuối cùng thì yếu tố rủi ro vẫn là prompt mà người dùng sao chép từ bên ngoài, hoặc cấu hình cho phép mô hình truy cập tài nguyên Internet
Đây vốn đã là điểm yếu tồn tại từ lâu trong toàn bộ ngành IT, chỉ là vấn đề cần quản lý bằng đào tạo người dùng và cô lập mạng
Dữ liệu tưởng như bình thường như ticket hay tài liệu giờ cũng có thể trở thành rủi ro bảo mật
Nhiều vụ hack nghiêm trọng bắt đầu từ những điểm khởi đầu rất đơn giản
Những kiểu tấn công này ở mức kiến thức bảo mật cơ bản
Chỉ cần review trước khi đưa mã lên production là có thể ngăn chặn được
Nếu hoàn toàn không biết gì thì đằng nào bạn cũng sẽ triển khai mã không an toàn thôi
Mô hình mở có tính tiếp cận cao, nhưng nghĩ rằng có thể chặn việc này bằng post-training thì là ảo tưởng
Cuộc tấn công thứ hai không phải là triển khai mã, mà là tình huống LLM đọc bình luận reddit rồi thực thi ngay
Chính thái độ xem nhẹ những vấn đề như vậy mới tạo ra mối đe dọa bảo mật lớn hơn
Nghe nói local LLM cũng có thể bị tấn công thì thấy hơi lạ
Nếu hệ thống đã bị xâm nhập sẵn thì kẻ tấn công có lẽ còn gây thiệt hại lớn hơn nhiều so với việc lừa được LLM
Nghĩa là kẻ tấn công có thể chèn prompt thông qua dữ liệu đầu vào
Nếu LLM là một agent có quyền thực thi lệnh, thì chuyện này lập tức trở thành lỗ hổng thực thi lệnh
Nếu đã tới tình huống đó thì coi như mọi thứ đã xong rồi
Bài này khiến tôi có cảm giác như do đội sales của Anthropic hay OpenAI viết ra
Trên thực tế, mô hình local hiếm khi được dùng làm agent thực thi mã, mà phần lớn mạnh ở chuyển đổi dữ liệu hoặc các tác vụ NLP
Khi dùng mô hình local với Agno agent, tôi luôn để nó in ra mã được sinh trước khi thực thi và cô lập bằng sandbox local
Ngược lại, tôi cho rằng các agent kiểu trình duyệt như Atlas hay Comet mới nguy hiểm hơn
Mô hình mã nguồn mở đã làm đúng theo những gì prompt yêu cầu, còn mô hình đóng thì phớt lờ nó
Nói cách khác, bên thất bại trong bài kiểm tra alignment lại chính là phía mô hình đóng
Cụm từ “lethal trifecta” nghe thì hay nhưng không mô tả đúng mức độ rủi ro thực tế
Trong thực tế, chỉ cần riêng khả năng liên lạc ra bên ngoài cũng đã đủ nguy hiểm
Bản thân LLM là một khối dữ liệu hộp đen không thể kiểm chứng, nên rất khó để tin cậy
Startup nhỏ có thể còn chấp nhận được, nhưng nếu là nơi như Coinbase thì chắc phải suy nghĩ thêm hai lần về chuyện mở quyền truy cập
Đây là câu chuyện về nghịch lý bảo mật của việc thực thi mã chưa được kiểm chứng
Nếu bạn đang chạy mã độc hại hoặc mã chưa được xác minh trên máy local, thì nên xem lại ngay từ lý do tại sao mình làm thế
Vì LLM diễn giải chỉ thị bằng ngôn ngữ con người giống như mã, nên ranh giới giữa mã và dữ liệu trở nên mơ hồ
Nếu lấy năng lực suy luận của LLM làm ranh giới bảo mật thì ngay từ đầu đã là vấn đề lớn
Cách tiếp cận đó về bản chất là thiết kế sai
Việc có thể bị injection nếu không cẩn thận với đầu vào là điều quá rõ ràng
Trong bất kỳ hệ thống nào, đầu vào luôn có thể trở thành vector tấn công
Mọi dữ liệu đưa vào LLM đều nhất định phải được kiểm chứng
Không biết có phải theo kiểu tấn công cross-site ở phía trình duyệt hay không