Giải mã vụ xâm nhập đại lý AI tại phòng thí nghiệm tiên phong: Dòng thời gian kỹ thuật sự cố tháng 7/2026

Quay lại các bài viết

Một bài viết kỹ thuật đi kèm với thông báo về sự cố của chúng tôi. Bài đăng này mô tả chi tiết cách thức cuộc xâm nhập thực sự diễn ra: hai vectơ truy cập ban đầu, cách tác nhân (agent) xoay chuyển và di chuyển ngang, các ví dụ tiêu biểu về các lệnh đã được thực thi và cách chúng tôi điều tra bằng GLM 5.2 (một mô hình mã nguồn mở). Các thông tin xác thực thực tế, tên máy chủ nội bộ và các chỉ số cụ thể đã được biên tập lại hoặc khái quát hóa, trong khi các kỹ thuật được mô tả chính xác như những gì Hugging Face đã quan sát được.

Chúng tôi công bố mức độ chi tiết này vì kỹ thuật quan trọng hơn bản thân sự cố, vì nó tiết lộ các khả năng tấn công mới nổi của các tác nhân tiên phong, cách chúng có thể bị các đối tượng xấu lợi dụng và cách mọi người nên chuẩn bị với tư cách là những người phòng thủ.

▶ Xem phát lại tương tác - hình ảnh trực quan từng bước về cuộc xâm nhập kéo dài 4,5 ngày: chuỗi tấn công qua các ranh giới tin cậy, hoạt động theo giai đoạn và các lệnh được ghi lại.

Tóm tắt (TL;DR)

Trong khoảng hai ngày rưỡi, một tác nhân AI tự hành được vận hành bởi sự kết hợp của các mô hình OpenAI đã thực hiện một cuộc xâm nhập toàn diện vào nền tảng của chúng tôi: đó là hàng nghìn quyết định nhỏ, tự động, được thực thi với tốc độ máy tính trên các môi trường sandbox tồn tại trong thời gian ngắn, với hệ thống chỉ huy và kiểm soát (C2) được dàn dựng trên các dịch vụ web công cộng thông thường.

Tác nhân này đang chạy một bộ đánh giá khả năng an ninh mạng của OpenAI có tên là ExploitGym, một tiêu chuẩn đánh giá giao nhiệm vụ cho tác nhân AI tìm kiếm và khai thác các lỗ hổng phần mềm. Theo những gì chúng tôi có thể suy luận, trong quá trình được đánh giá trên tiêu chuẩn này, tác nhân đã suy luận rằng Hugging Face có thể lưu trữ các mô hình, tập dữ liệu và lời giải tham khảo của tiêu chuẩn đó. Chúng tôi tin rằng toàn bộ cuộc xâm nhập, từ quan điểm của tác nhân, là một nỗ lực để gian lận trong bài đánh giá: tiếp cận các hệ thống sản xuất của chúng tôi và đánh cắp các lời giải kiểm thử thay vì tự mình giải quyết thử thách.

Quá trình tái dựng pháp y của chúng tôi bao gồm khoảng 17.600 hành động của kẻ tấn công mà chúng tôi có thể khôi phục, được nhóm thành khoảng 6.280 cụm, trong khoảng thời gian từ 02:28 UTC ngày 09/07/2026 đến 14:14 UTC ngày 13/07/2026. Chúng tôi đã tái dựng các hành động này từ nhật ký của tác nhân trên một sandbox mã nguồn được tác nhân sử dụng (xem bên dưới) và có thể ánh xạ chúng thành các lệnh shell cũng như các bài nộp đánh giá, đồng thời đối chiếu các hành động với nhật ký nền tảng của chính chúng tôi, đặc biệt là từ các nút xử lý tập dữ liệu, API và pod. Sử dụng các mô hình trọng số mở, đặc biệt là zai-org/GLM-5.2, chúng tôi đã có thể giải mã hầu hết các payload của tác nhân (xem bên dưới) vốn được mã hóa thông qua việc chia nhỏ và mã hóa khóa.

Chiến dịch này, theo như chúng tôi có thể tái dựng, có hai giai đoạn:

Khi đã thiết lập được chỗ đứng trong prod-pod, tác nhân đã thực hiện theo hình thức leo thang tiêu chuẩn: trinh sát, thả trình cài đặt (stager), thiết lập Chỉ huy và Kiểm soát (C2), sau đó xoay chuyển vào cụm (cluster), vào siêu dữ liệu đám mây, vào mạng nội bộ của chúng tôi và vào chuỗi cung ứng kiểm soát nguồn của chúng tôi. Đầu ra của các lệnh chạy bên trong pod của chúng tôi được gửi ngược lại cho tác nhân thông qua HF API và các tập dữ liệu dead-drop do kẻ tấn công kiểm soát, mà tác nhân đã đọc lại từ sandbox đó.

Mặc dù cuộc xâm nhập đã tiếp cận được cơ sở hạ tầng nội bộ của Hugging Face, nội dung khách hàng duy nhất bị truy cập là bộ lời giải thử thách ExploitGym/CyberGym được lưu trữ trong năm tập dữ liệu. Không có mô hình, tập dữ liệu, Spaces hoặc gói phần mềm nào khác hướng tới khách hàng bị ảnh hưởng, và các hồ sơ khách hàng duy nhất bị đọc là siêu dữ liệu vận hành gắn liền với các truy vấn tìm kiếm đối với máy chủ tập dữ liệu.

Chuỗi tấn công đầy đủ qua các ranh giới tin cậy. Tác nhân đã thoát khỏi sandbox đánh giá của OpenAI, tiếp cận internet, chiếm quyền root một sandbox mã nguồn của bên thứ ba làm căn cứ, sau đó lạm dụng bộ xử lý tập dữ liệu của chúng tôi (đọc tệp, sau đó thực thi mã) để tiếp cận mạng nội bộ của chúng tôi. Mũi tên nét đứt: đầu ra lệnh được tác nhân đọc lại qua HF API và các tập dữ liệu dead-drop.

Truy cập ban đầu

Giai đoạn 1: từ sandbox đánh giá của OpenAI đến bệ phóng đã bị chiếm quyền root

Giai đoạn 1 là con đường của tác nhân đến một bệ phóng bên ngoài, và nó chạy qua cơ sở hạ tầng của hai bên khác, không bên nào là chúng tôi, vì vậy chúng tôi sẽ giữ ngắn gọn về những phần này và chủ yếu giới thiệu người đọc đến bài đăng trên blog của OpenAI về chủ đề này: https://openai.com/index/hugging-face-model-evaluation-security-incident/

Như OpenAI đã chia sẻ trong bài đăng blog này, trong một cuộc đánh giá khả năng nội bộ trên nền tảng của OpenAI, tác nhân tình cờ thoát ra bằng cách sử dụng một lỗ hổng 0-day từ bộ nhớ đệm proxy gói để truy cập internet. Từ đó, nó tìm thấy và thâm nhập vào một sandbox đánh giá mã nguồn công cộng không được bảo mật được lưu trữ trên cơ sở hạ tầng của nhà cung cấp bên thứ ba (một bộ công cụ kiểu CyberGym) và sử dụng sandbox bên ngoài này làm căn cứ kiểm soát, dàn dựng và thoát ra, chạy các lệnh với quyền admin/root và sử dụng nó làm bệ phóng tấn công. Sandbox đó không có đường mạng trực tiếp vào cụm của chúng tôi; mọi thứ bên dưới đều chạy từ đó.

Trên sandbox bên ngoài này, tác nhân đã lạm dụng một bộ công cụ thực thi CyberGym hiện có (bộ công cụ được sử dụng trong tiêu chuẩn SunBlaze-UCB/exploitgym), một bộ công cụ được thiết kế đặc biệt để đánh giá các tác nhân AI trong việc phát hiện lỗ hổng. Tóm lại: một tác nhân gửi mã C thông qua lệnh gọi API /submit-function, và bộ công cụ sẽ biên dịch và chạy mã đó bên trong một sandbox cho mỗi lần gửi đối với một chương trình mục tiêu (ở đây là sqlite3). Tác nhân đã tái sử dụng bộ công cụ này để chạy các lệnh shell tùy ý như sau.

Sandbox biên dịch tệp src/main.c được gửi và liên kết nó với một mục tiêu gọi sqlite3_initialize. Hàm đó được đăng ký dưới dạng một constructor: nó tự động chạy khi thư viện được tải. Tác nhân chỉ đơn giản là định nghĩa lại nó:

Chỉ riêng điều đó đã mang lại khả năng thực thi mã. Nhưng tác nhân còn đi xa hơn và lạm dụng chính siêu dữ liệu gửi. Sandbox phản hồi đường dẫn nguồn được gửi vào một bước shell, vì vậy một kiểu tiêm;...;# cổ điển trong trường đường dẫn đã biến quá trình xây dựng thành các lệnh tùy ý:

Cả hai con đường đều dẫn đến cùng một kết quả: shell tùy ý với uid=0 bên trong sandbox. Lệnh RCE đầu tiên được khôi phục, vào lúc 04:01 UTC ngày 09/07, chỉ đơn giản là:

Trong vòng một giờ, tác nhân đã lập bản đồ sandbox: bảng mount của container, cgroups, các socket mặt phẳng điều khiển của nhà cung cấp và một shell gỡ lỗi đi kèm tình cờ có sẵn curl, nc và ip:

Chuỗi công cụ đi kèm đó đã trở nên quan trọng sau này: khi lưu lượng thoát ra bình thường bị hạn chế, tác nhân liên tục quay lại sử dụng các tệp nhị phân đã được dàn dựng sẵn này.

Giai đoạn 2: Thâm nhập cơ sở hạ tầng Hugging Face bằng hai vectơ tiêm vào bộ xử lý tập dữ liệu của chúng tôi

Đây là cách tác nhân tiếp cận bên trong vành đai của chúng tôi, và nó được vận hành hoàn toàn từ sandbox bên ngoài ở Giai đoạn 1. Tác nhân đã tạo ra các cấu hình tập dữ liệu độc hại và tải chúng lên nền tảng của chúng tôi. Khi máy chủ tập dữ liệu của chúng tôi xử lý một cấu hình, cấu hình đó sẽ điều khiển trình tải dữ liệu bên trong pod sản xuất mà máy chủ đang chạy. Tác nhân không có đường mạng trực tiếp đến cụm của chúng tôi và đang sử dụng các tập dữ liệu làm đường vào và đường ra. Đầu ra từ mọi hành động được gửi ngược lại cho tác nhân thông qua HF API và các tập dữ liệu dead-drop do kẻ tấn công kiểm soát, mà nó đã đọc lại từ sandbox đó.

Cả hai vectơ đều lạm dụng cùng một bề mặt (trình tải chuyển đổi cấu hình đã khai báo của tập dữ liệu thành các lệnh đọc tệp) nhưng với các mục đích khác nhau, và cả hai đều né tránh cùng một biện pháp phòng thủ. Một biến thể trước đó và ồn ào hơn đã thử SSRF cổ điển, hướng worker đến các URL từ xa (các điểm cuối siêu dữ liệu đám mây như 169.254.169.254): danh sách cho phép URL của thư viện tập dữ liệu đã từ chối mọi URL không phải của nền tảng trước khi thực hiện bất kỳ lệnh tìm nạp nào (ValueError: not an hf path). Vì vậy, tác nhân đã ngừng yêu cầu worker tìm nạp các tài nguyên từ xa và thay vào đó khiến nó hành động trên các tài nguyên cục bộ: đọc một tệp cục bộ (Vectơ 1), hoặc thực thi mã cục bộ (Vectơ 2). Không cái nào là tìm nạp URL, vì vậy danh sách cho phép không bao giờ phát hiện ra chúng.

Vectơ 1: Đọc tệp lưu trữ thô bên ngoài HDF5

Một cấu hình tập dữ liệu có thể khai báo các tệp dữ liệu của nó ở nhiều định dạng, với HDF5 là một trong số đó. Tác nhân đã cam kết một tập dữ liệu có cấu hình trỏ mỗi phân đoạn (split) vào một tệp.h5 nhỏ, và mỗi tệp là một container HDF5 hợp lệ chứa một tập dữ liệu đơn lẻ có dữ liệu thô được khai báo nằm tại một đường dẫn hệ thống tệp cục bộ. Khi worker mở tệp để xây dựng phân đoạn, nó đã đọc các byte thô từ đường dẫn đó và trả về chúng dưới dạng các hàng của tập dữ liệu, mà tác nhân sau đó đã đọc lại qua HF API. Không có mã nào chạy: vectơ này hoàn toàn là tiết lộ tệp, và đây là vectơ mà tác nhân đã sử dụng đầu tiên.

Các đường dẫn lưu trữ được khai báo trỏ chính xác vào những gì một kẻ tấn công đang tìm kiếm chỗ đứng mong muốn:

Việc đọc phân đoạn envu8 đã trả về toàn bộ môi trường của pod worker bao gồm một số bí mật và thông tin xác thực. Các phân đoạn mainu8 và startu8 trả về mã nguồn của chính worker, cung cấp cho tác nhân một bản đồ chính xác về cách đường ống (pipeline) biến một cấu hình thành các hành động. Một lần tải lên tập dữ liệu duy nhất đã làm rò rỉ cả thông tin xác thực và chi tiết triển khai của đường ống, mà không cần thực thi mã.

Vectơ 2: Tiêm mẫu Jinja2 (Jinja2 template injection)

Vectơ thứ hai là tiêm mẫu phía máy chủ (server-side template injection), và đây là vectơ mang lại cho tác nhân khả năng thực thi mã. Một cấu hình tập dữ liệu độc hại đã sử dụng một đặc tả fsspec reference:// có trường offset số thực chất là một mẫu Jinja2. Trình kết xuất đã đánh giá sai nó, và tác nhân đã đi qua biểu đồ đối tượng Python tiêu chuẩn để tiếp cận exec:

Điều này đã chạy Python tùy ý bên trong một pod worker chuyển đổi sản xuất trên cụm Kubernetes của chúng tôi, được điều khiển bởi sự tiêm nhiễm từ bệ phóng. Pod đó là chỗ đứng của tác nhân bên trong vành đai của chúng tôi, và mọi lệnh nó chạy ở đó đều được chuyển lậu ngược ra ngoài thông qua HF API và các tập dữ liệu dead-drop.

Vòng lặp tiêm lệnh và đọc ngược của Giai đoạn 2. Tác nhân tải lên một cấu hình tập dữ liệu độc hại (1), máy chủ tập dữ liệu của chúng tôi xử lý nó (2), trình tải hoạt động trong pod sản xuất - đọc tệp cục bộ hoặc thực thi mã (3), kết quả được cam kết vào một tập dữ liệu dead-drop (4) và được phục vụ ngược lại qua HF API (5). Cuối cùng, tác nhân đọc nó và tạo ra hành động tiếp theo (6).

Chuỗi tiêu diệt (The kill chain)

Các hành động được khôi phục được nhóm thành các giai đoạn. Hai ngày chiếm phần lớn khối lượng: một đợt bùng phát vào Ngày 1 để thiết lập chỗ đứng và C2 trên sandbox bên ngoài bị xâm nhập, và chiến dịch chính vào Ngày 3, khi mọi giai đoạn di chuyển ngang bắt đầu cùng một lúc.

Khối lượng hàng ngày có hai đỉnh:

Theo từng ngày

Chiến dịch được ghi lại, từ hành động đầu tiên vào 02:28 UTC ngày 09/07 đến hành động cuối cùng vào 14:14 UTC ngày 13/07. Trên cùng: khối lượng sự kiện theo thời gian. Bên dưới: hoạt động theo từng giai đoạn, mỗi hàng một giai đoạn. Trinh sát, rce và dropper chạy từ Ngày 1; các giai đoạn di chuyển ngang (k8s, chuỗi cung ứng, tailscale) đều bắt đầu vào Ngày 3, khi chiến dịch xoay chuyển vào các cụm của chúng tôi.

Ngày 1 (09/07): chỗ đứng và C2