Bài học từ sự cố bảo mật tại Hugging Face: Khi AI vượt rào kiểm soát

Đến nay, có lẽ bạn đã nghe về một AI agent đã thoát khỏi quá trình đánh giá bảo mật và tấn công Hugging Face, một thị trường dành cho các mô hình ngôn ngữ lớn (LLM). AI agent này cho rằng Hugging Face có thể chứa đáp án cho các bài kiểm tra năng lực (benchmark) của nó, vì vậy nó đã đánh cắp chúng để gian lận trong bài thi. Đó là một động cơ nghe có vẻ hài hước nhưng lại dẫn đến kết quả đáng sợ.

Hugging Face đã công bố bản tái hiện chi tiết về vụ xâm nhập. Báo cáo bao gồm khoảng 17.600 hành động được khôi phục trong hơn bốn ngày rưỡi, bao gồm việc thoát khỏi sandbox, thực thi mã, đánh cắp thông tin xác thực đám mây, thiết lập các hệ thống chỉ huy và kiểm soát (C2) tự chế, và cuối cùng là sử dụng Tailscale để lan rộng khắp tổ chức của họ.

Nhưng Tailscale là một mạng zero trust (không tin cậy)! Mục đích cốt lõi của zero trust là ngăn chặn kẻ tấn công di chuyển ngang (lateral movement) trong công ty của bạn. Vậy điều gì đã xảy ra?

Nơi Tailscale xuất hiện

Không có "lỗ hổng" nào trong Tailscale được tìm thấy hay bị khai thác, và điều đó có lẽ càng khiến chúng ta cảm thấy không thoải mái hơn. Tailscale xuất hiện ở khắp mọi nơi trong cơ sở hạ tầng AI: hầu như mọi công ty AI đều sử dụng Tailscale. Vì vậy, không có gì ngạc nhiên khi cuối cùng chúng tôi cũng xuất hiện trong một báo cáo sự cố AI.

Tuy nhiên, chúng tôi là một công cụ bảo mật. Vụ xâm nhập của họ cũng là vụ xâm nhập của chúng tôi, và nhiệm vụ của chúng tôi là phải nghiêm túc nhìn nhận vấn đề này. Như trong bất kỳ cuộc phân tích sau sự cố (post-mortem) nào, chúng tôi cần suy ngẫm về những gì đã xảy ra và những gì chúng tôi có thể làm để ngăn chặn nó.

Vào thời điểm AI agent thoát khỏi sandbox và tìm thấy Tailscale, nó đã giành được quyền thực thi mã bên trong một worker sản xuất, đạt được quyền truy cập root trên một node Kubernetes và đọc được một kho lưu trữ bí mật sản xuất chứa 136 khóa. Theo một nghĩa nào đó, trò chơi đã kết thúc trước khi chúng tôi kịp có mặt tại hiện trường.

Nhưng đó chẳng phải là vấn đề sao? Hãy lùi lại một hoặc hai bước. Tại sao các khóa bí mật có thời hạn sử dụng dài lại có thể bị bất kỳ ai truy cập?

Bởi vì thông tin xác thực có thời hạn sử dụng dài là tiêu chuẩn

Tuy nhiên, lẽ ra không nên như vậy. Và giờ đây chúng ta đã thấy một ví dụ điển hình về lý do tại sao. Trong thế giới cũ, nơi hầu hết các vụ xâm nhập được thực hiện bởi con người với tốc độ của con người, việc giảm thiểu rò rỉ thông tin xác thực được coi là một tính năng "có thì tốt". Một kho lưu trữ thông tin xác thực lớn, nơi bạn có thể đọc 136 khóa cùng lúc, chỉ là một mục cần làm nằm đâu đó trong danh sách ưu tiên thấp của đội ngũ bảo mật.

Giờ đây, trong thế giới của các AI agent độc hại, kho lưu trữ thông tin xác thực lớn chính là mục tiêu hàng đầu. Điều đó không còn chấp nhận được nữa.

Tôi chỉ biết hai giải pháp chính cho vấn đề thông tin xác thực có thời hạn sử dụng dài.

Thứ nhất, bạn có thể cấu hình một vault (kho lưu trữ) chỉ cấp các thông tin xác thực có thời hạn ngắn dựa trên các thông tin xác thực dài hạn mà bạn nhập vào một lần và vault sẽ không bao giờ trả lại chúng. Ví dụ, HashiCorp Vault có thể làm điều này; họ gọi đó là thông tin xác thực động (dynamic credentials). Thật không may, thông tin xác thực động đòi hỏi rất nhiều công sức để thiết lập và duy trì. Khi bảo mật đòi hỏi quá nhiều công sức, mọi người thường sẽ không làm.

Lựa chọn thứ hai là một proxy tiêm thông tin xác thực (credential-injecting proxy). Nếu client C muốn truy cập server S, đừng cấp thông tin xác thực của S cho C; thay vào đó, hãy để C gửi yêu cầu qua một proxy P đã được tăng cường bảo mật, proxy này chỉ làm nhiệm vụ nhận yêu cầu, chèn thông tin xác thực vào và chuyển tiếp nó. Việc tiêm thông tin xác thực đang trở nên phổ biến khi các mạng lưới dựa trên mesh hiện đại loại bỏ hầu hết độ trễ của nó. Vài tháng trước, chúng tôi đã mua lại Border0 ("Tailscale PAM"), một proxy tiêm thông tin xác thực tinh tế và khá hiện đại, được tích hợp chặt chẽ với Tailscale. Nếu được triển khai đầy đủ, Border0 đã có thể ngăn chặn việc đọc 136 khóa đó và ghi lại mọi nỗ lực sử dụng chúng. (Cơ chế tiêm thông tin xác thực tương tự cũng cung cấp năng lượng cho Aperture Connectors). Nhưng, những công nghệ này còn quá mới. Hầu hết khách hàng của chúng tôi thậm chí còn chưa xem xét đến chúng.

Một lựa chọn thứ ba: chính là Tailscale. Trong Tailscale, khóa node của bạn có thể được gắn với máy bằng TPM để ngăn chặn việc xuất khóa, và nếu bạn là doanh nghiệp, bạn chắc chắn nên làm điều đó. Đáng tiếc, chúng tôi đã phải tắt tính năng lưu trữ TPM theo mặc định trên Linux và Windows do các vấn đề về HSM mà chúng tôi tìm thấy trên phần cứng của một số người dùng. Dù sao thì, trong trường hợp hôm nay, cuộc tấn công chính là thứ đã cấp quyền truy cập vào Tailscale, vì vậy chúng tôi đã đến quá muộn.

Khóa xác thực có thời hạn dài đó không cần thiết phải tồn tại

Cả thông tin xác thực động lẫn proxy tiêm thông tin xác thực đều không được áp dụng, dẫn đến 136 khóa bị rò rỉ. Tuyến phòng thủ tiếp theo là gì?

Một trong 136 thông tin xác thực đó là khóa xác thực Tailscale có thể tái sử dụng, được dùng để tạo các node Tailscale CI (tích hợp liên tục, dùng cho kiểm thử tự động) mới trong tailnet của họ. AI agent đã sao chép khóa đó vào một loạt các sandbox bên ngoài và sử dụng nó trong vài ngày để đăng ký tổng cộng 181 node vào tailnet của Hugging Face. Mỗi node đó đều nhận được một thẻ định danh Tailscale, cấp mọi quyền truy cập mà một node CI có được.

Chúng tôi không thể cứu được 136 khóa đó. Nhưng một khóa Tailscale có thể tái sử dụng không cần thiết phải nằm trong số đó.

Chúng tôi đã xây dựng liên kết định danh workload (workload identity federation) cho những trường hợp như thế này. Nó dựa vào nhà cung cấp đám mây của bạn để cung cấp "quyền hạn môi trường" (ambient authority) dưới dạng các thông tin xác thực có thời hạn ngắn được tạo từ định danh đám mây của một máy ảo (hoặc container) đang chạy. Công việc CI có thể yêu cầu nền tảng đám mây của nó cấp một token OIDC đã ký. Tailscale xác minh token đó, sau đó cấp quyền truy cập với các thẻ và phạm vi được gán cho workload đó. Điều thú vị là quá trình này có thể diễn ra tự động sau khi được kích hoạt: khởi chạy node CI, Tailscale nhận định danh và gán các thẻ phù hợp. Không có thông tin xác thực nào để rò rỉ và, khi được cấu hình cẩn thận, không có cách nào để sử dụng thông tin xác thực này ở bất kỳ đâu ngoài CI.

Điều đó có nghĩa là bạn không thể lấy thông tin xác thực CI, chạy nó trên một node ở nơi khác và biến nó thành một con đường thông suốt từ cụm kiểm thử ra phần còn lại của mạng lưới.

Đáng tiếc, không có đủ người sử dụng liên kết định danh workload. Lẽ ra chúng tôi nên làm nhiều hơn để đảm bảo khách hàng biết rằng đó là con đường dễ dàng và an toàn hơn, đồng thời có cách rõ ràng để áp dụng nó. Chúng tôi có thể cải thiện tài liệu và thêm nhiều lời nhắc hơn trong giao diện người dùng.

Không có nhật ký client không có nghĩa là không có bằng chứng

Trong nỗ lực che giấu dấu vết, AI agent đã chạy Tailscale với tùy chọn --no-logs-no-support, giúp ngăn chặn việc báo cáo từ client đó.

Đó là một tùy chọn được thiết kế cho những người dùng lo ngại về việc gửi siêu dữ liệu đo lường (telemetry) cho Tailscale. Ngay cả khi chúng tôi không cung cấp tùy chọn đó, việc sửa đổi mã nguồn để loại bỏ telemetry cũng rất dễ dàng.

Nhưng việc dừng ghi nhật ký không làm cho kết nối trở nên vô hình. Nếu bạn bật nhật ký lưu lượng mạng (network flow logs) của Tailscale, chúng sẽ báo cáo lưu lượng truy cập từ cả hai đầu của mọi kết nối, cũng như từ các subnet router và exit node. Điều này tinh tế nhưng quan trọng: một node bị xâm nhập có thể không gửi flow logs, nhưng mọi node mà nó kết nối đến thì có. Và sau đó, SIEM của bạn, nếu được cấu hình cẩn thận, có thể đưa ra cảnh báo đỏ ngay lập tức nếu hai đầu kết nối không khớp nhau.

Flow logs có thể hỗ trợ phát hiện khi chúng được truyền vào một SIEM được cấu hình cẩn thận. Nhưng đó là một công việc đòi hỏi nhiều nỗ lực. Flow logs cần được kích hoạt và bạn cần có các quy tắc phát hiện trực tiếp phù hợp để chúng hữu ích trong thời gian thực, chứ không chỉ để phục vụ công tác điều tra sau này. Chúng tôi đang xem xét cách làm cho flow logs dễ khám phá, cấu hình, áp dụng và đóng vai trò là các trình kích hoạt cảnh báo hơn. Tôi muốn chúng tôi làm cho flow logs dễ sử dụng đến mức chúng có thể giúp ích ngay cả khi bạn không có đội ngũ bảo mật để theo dõi chúng.

Nếu bạn muốn kiểm soát trực tiếp ngoài việc ghi nhật ký, bạn cũng có thể bật Tailnet Lock. Điều này mang lại cho bạn khả năng hiển thị trực tiếp và kiểm soát nhập học nghiêm ngặt, có thể lập trình cho từng node mới. Ví dụ, với một chút công sức, bạn có thể lập trình node ký (signing node) của mình để kiểm tra xem các thẻ "CI" luôn có dải địa chỉ IP cụ thể hoặc bằng chứng xác thực khác hay không.

Hãy biến con đường an toàn thành con đường dễ dàng

Bảo mật mạng rất khó. Nó luôn luôn khó. Trong thế giới mới của các AI agent độc hại, nó không chỉ khó mà còn là điều thiết yếu. Và đó là một vấn đề vì nhiều tổ chức đơn giản là không có chuyên môn về bảo mật mạng.

Vì vậy, tại Tailscale, chúng tôi coi đây là vấn đề cá nhân. Mọi người mong đợi sản phẩm của chúng tôi ngăn chặn các kiểu tấn công di chuyển ngang này theo mặc định, để họ không phải làm điều đó. Ngay cả khi họ không biết tấn công di chuyển ngang là gì.

Nếu sự cố này khiến bạn nhìn vào cơ sở hạ tầng của chính mình với chút lo lắng, hãy bắt đầu bằng việc kiểm tra các khóa xác thực Tailscale có thể tái sử dụng mà các workload của bạn có thể đọc được. Đặc biệt đối với đám mây và CI, hãy thay thế chúng bằng liên kết định danh workload bất cứ khi nào có thể. Hãy loại bỏ các khóa xác thực có thời hạn dài đó.

(Các khóa xác thực vẫn có những công dụng tốt, đặc biệt là cho việc cung cấp quyền truy cập một lần và trong các môi trường không có định danh nền tảng. Khi bạn cần một khóa, hãy ưu tiên các khóa dùng một lần; sử dụng OAuth client để giữ thời hạn hết hạn của khóa xác thực ngắn; sử dụng các thẻ hẹp; kiểm tra các quyền được cấp cho các khóa đó trong ACL của bạn.)

Hãy bật network flow logs và gửi chúng đến các công cụ mà đội ngũ bảo mật của bạn đang sử dụng.

Sử dụng lưu trữ trạng thái node an toàn trên các đội máy được quản lý, nơi bạn có quyền kiểm soát TPM. Sử dụng tư thế thiết bị (device posture) để cô lập và hạn chế các node mà bạn không có quyền kiểm soát.

Tôi biết chúng tôi đã không làm cho những lựa chọn an toàn này trở nên đủ rõ ràng. Đó là lỗi của chúng tôi. Chúng tôi sẽ cải thiện tài liệu, thêm lời nhắc vào giao diện người dùng, cố gắng hết sức để bật các tính năng này theo mặc định, cảnh báo bạn khi bạn đang làm điều gì đó nguy hiểm và đề xuất các giải pháp thay thế tốt hơn.

Đây là lời xin lỗi đậm chất Canada của chúng tôi: xin lỗi vì bạn đã gặp rắc rối. Cuộc tấn công không khai thác Tailscale, và Tailscale không gây ra vụ xâm nhập. Nhưng, chúng tôi đã không ngăn chặn được nó. Lần tới, chúng tôi sẽ làm được.

Nếu bạn đang chạy Tailscale và muốn tìm hiểu sâu hơn, hãy liên hệ với các đội ngũ hỗ trợ và kỹ thuật giải pháp của chúng tôi. Chúng tôi có thể giúp bạn thắt chặt các cài đặt và giúp bạn tìm ra những lỗ hổng trước khi AI agent tiếp theo làm điều đó.