Công bố sự cố rò rỉ Secret trên nền tảng Hugging Face Spaces

• Đầu tuần này, nền tảng Spaces đã phát hiện truy cập trái phép liên quan đến secrets, và có khả năng một số secrets đã bị truy cập từ bên ngoài
• Trong quá trình ứng phó ban đầu, nhiều HF token có trong secrets đã bị thu hồi, và email thông báo đã được gửi tới người dùng bị ảnh hưởng
• Người dùng được khuyến nghị cấp lại các key và token liên quan, đồng thời chuyển sang fine-grained access tokens hiện đã trở thành mặc định mới
• Hugging Face đang điều tra cùng các chuyên gia pháp chứng an ninh mạng bên ngoài, đồng thời rà soát lại các chính sách và quy trình bảo mật
• Hạ tầng Spaces đã được áp dụng các biện pháp như loại bỏ org tokens, triển khai KMS, và tăng cường phát hiện/vô hiệu hóa token bị rò rỉ; sự cố cũng đã được báo cáo tới các cơ quan liên quan

---

Truy cập trái phép vào Spaces secrets và hành động người dùng cần thực hiện

• Hugging Face đã phát hiện truy cập trái phép liên quan đến Spaces secrets trên nền tảng Spaces
• Có khả năng một số Spaces secrets đã bị truy cập trái phép
• Trong quá trình khắc phục ban đầu, nhiều HF tokens có trong secrets đã bị thu hồi
  • Những người dùng có token bị thu hồi đã nhận được email thông báo
• Người dùng được khuyến nghị cấp mới key hoặc token
• Đối với HF tokens, nên chuyển sang fine-grained access tokens là mặc định mới

Tăng cường bảo mật hạ tầng Spaces và các bước ứng phó tiếp theo

• Hugging Face đang điều tra sự cố cùng các chuyên gia pháp chứng an ninh mạng bên ngoài và rà soát các chính sách, quy trình bảo mật
• Trong vài ngày gần đây, bảo mật của hạ tầng Spaces đã được tăng cường
  • Đã loại bỏ hoàn toàn org tokens để tăng khả năng truy vết và kiểm toán
  • Đã triển khai dịch vụ quản lý khóa (KMS) cho Spaces secrets
  • Đã tăng cường và mở rộng năng lực hệ thống trong việc xác định và vô hiệu hóa trước các token bị rò rỉ
  • Đã cải thiện bảo mật tổng thể
• Khi fine-grained access tokens đạt mức tương đương về tính năng, công ty dự kiến sẽ sớm loại bỏ hoàn toàn các “classic” read/write tokens
• Việc điều tra các sự cố liên quan có thể xảy ra vẫn đang tiếp tục
• Hugging Face cũng đã báo cáo sự cố này tới cơ quan thực thi pháp luật và cơ quan bảo vệ dữ liệu
• Mọi thắc mắc được tiếp nhận qua [e-mail]

[GN⁺]

Ý kiến trên Hacker News

• Hai ngày trước tôi xem lướt các slide của một hội nghị bảo mật, và Jossef Harush Kadouri đã cho thấy rằng nếu dùng mô hình từ những nơi như Hugging Face, tác giả mô hình có thể thực thi mã tùy ý trên máy của tôi
  Tôi không biết các slide đã được đăng ở nơi khác chưa, còn file tôi nhận được thì ở đây: https://dro.pm/c.pdf (45MB) slide 188
  Lúc đó tôi chưa nhận ra rằng điều này cũng có nghĩa là Hugging Face có thể làm điều tương tự nếu nhận lệnh của tòa án hoặc bị hack. Đặc biệt nếu việc bị xâm nhập không bị phát hiện trong một thời gian¹
  Tôi ở ngoài ngành AI nên chưa từng tự chạy các mô hình như vậy, nhưng tôi ngạc nhiên khi ngành này chuẩn hóa định dạng nhanh đến thế. Tôi từng nghĩ file mô hình chỉ là các ma trận số lớn và một ít metadata, nhưng nhìn slide 186 và 195 thì có vẻ mô hình thực chất là script Python có thể làm gần như tùy ý, nên việc chuẩn hóa mới dễ như vậy. Nếu cứ để mỗi bên làm điều họ muốn thì vấn đề được né tránh, nhưng cái giá phải trả là không nhỏ
  ¹ Theo https://www.verizon.com/business/resources/articles/s/how-to..., 20% không phát hiện ra việc bị xâm nhập trong nhiều tháng. Tất nhiên còn tùy tình huống và hành vi của kẻ tấn công
  • Về đoạn “tôi từng nghĩ file mô hình chỉ là các ma trận số lớn và một ít metadata”, ONNX[1] nhìn chung khá gần với dạng đó
    Nhưng vấn đề bạn sẽ gặp ngay là các layer/operator tùy chỉnh và logic suy luận của chúng. Bạn phải triển khai chỉ bằng các phép toán được hỗ trợ, điều này trên thực tế có thể khó hoặc bất khả thi, hoặc phải cung cấp phần triển khai operator cho runtime, và rốt cuộc lại quay về điểm xuất phát
    [1] https://onnx.ai/
  • Vậy chẳng phải vì thế mới có định dạng .safetensors, không thể chạy mã trên host sao?
  • Như những người khác đã chỉ ra, chuyện này phụ thuộc vào định dạng. Trong thread này, một định dạng chưa được nhắc đến ở phía an toàn là GGUF, được llama.cpp và các dự án phái sinh sử dụng
    Đây gần như là định dạng “ma trận số lớn và một ít metadata”, và một số lỗ hổng đã được phát hiện rồi vá
    [1] https://www.databricks.com/blog/ggml-gguf-file-format-vulner...
  • Theo tôi biết, vấn đề này chỉ xảy ra khi mô hình được serialize/deserialize bằng pickle[0]
    [0]: https://huggingface.co/docs/hub/en/security-pickle
  • Link dro.pm sẽ sớm hết hạn. Đó là link tạm nên ngắn hạn, có lẽ lẽ ra tôi nên dùng một dịch vụ lâu dài hơn
    Tôi đã tìm được video bài thuyết trình cho những ai đọc sau: https://m.youtube.com/watch?v=8XysLIq-e3s
• Việc mở đầu bằng “họ nghi ngờ” là một cách diễn đạt quá chừa đường rút. Nó có vẻ không phù hợp với một câu trong kiểu thông báo như thế này
  • Ngược lại, tôi thấy như vậy khá ổn. Thông thường các thông báo rò rỉ kiểu này sẽ nói kiểu “không có bằng chứng cho thấy các giá trị bí mật đã bị truy cập”, vì họ “không thể biết” hacker đã làm gì sau khi vào được
    Hugging Face ít nhất đã nói đại ý rằng “có lẽ các giá trị bí mật có khả năng đã bị truy cập, nhưng chúng tôi không thể xác nhận”, nên trông thành thật hơn
• Họ nói “trong vài ngày qua đã cải thiện đáng kể bảo mật hạ tầng Spaces”, gồm loại bỏ hoàn toàn token tổ chức, tăng cường khả năng truy vết và kiểm toán, đưa KMS vào cho các giá trị bí mật của Spaces, tăng cường nhận diện token bị rò rỉ và chủ động vô hiệu hóa, cùng các cải thiện bảo mật tổng thể; lượng việc như vậy khá lớn để hoàn tất trong “vài ngày”
  Chẳng phải các việc này nên kéo theo những quy trình tốn thời gian hơn như kiểm toán bảo mật hoặc pentest trước khi đưa vào vận hành sao?
  • Hy vọng đó là những việc đã được tiến hành một thời gian rồi, và vì thiệt hại đã xảy ra nên giờ họ mới triển khai
  • Điều đó đúng với một tổ chức lớn hơn có bộ phận SRE kèm đội bảo mật chuyên trách, nhưng ấn tượng của tôi là Hugging Face vẫn chưa phải tổ chức ở quy mô đó
• Khóa Anthropic của tôi bị rò rỉ và ai đó đã tạo ra hóa đơn 10.000 USD. Hugging Face có bồi thường chuyện này không?
  • Khóa OpenAI của tôi cũng bị rò rỉ và tôi phát hiện có người sử dụng nó. May là thiệt hại nhỏ hơn nhiều, chỉ vài USD tiền GPT-4, và lúc đó các app của tôi thậm chí không dùng mô hình đó
    Tôi gần như chắc chắn nó bị rò rỉ qua giá trị bí mật của HF Space. Vài ngày trước tôi nhận được cảnh báo rằng một số Spaces của tôi bị ảnh hưởng
  • Bạn có chắc khóa đó thật sự chỉ được lưu trong giá trị bí mật của Space không? Biến là công khai, và lưu trong file .env cũng là công khai
  • Tôi tưởng trên các nền tảng cung cấp cloud thường có thể đặt giới hạn tối đa chi tiêu
• Vài tuần trước tôi nhận ra vài khóa OpenAI của mình đã bị lấy cắp, và các khóa đó chỉ được kích hoạt dưới dạng giá trị bí mật trong Hugging Face Space
  Vài ngày trước tôi nhận được email nói rằng các Spaces tương ứng đã bị xâm nhập, nên vấn đề này có vẻ đã kéo dài ít nhất vài tuần
• Không thấy nhắc đến việc họ sẽ xử lý thế nào với các chi phí phát sinh không phù hợp. Nếu có thể truy cập các giá trị bí mật thì chẳng phải có thể gọi API và tích lũy chi phí sao?
  Hay đây thuần túy là vấn đề đánh cắp dữ liệu/mã?
  • Cả hai đều có thể. Trường hợp của tôi, khóa đã được dùng để gọi OpenAI, và tôi gần như chắc chắn nó rò rỉ từ giá trị bí mật của Spaces
• ‘Space’ là gì?
  • Là cách gọi tắt Spaces của Hugging Face
    https://huggingface.co/docs/hub/en/spaces-overview
    Có vẻ là phần frontend/portal, và có lẽ được viết bằng Python. Cũng có thể là thứ gì đó như Django
  • Là máy ảo chạy mã của người dùng
• Tại sao HF lại lưu “giá trị bí mật”?
  Không thể chỉ lưu khóa công khai, để người dùng giữ khóa bí mật rồi ký yêu cầu sao?
  • Bạn có thể tạo app được host trên HF và truy cập API bên ngoài như OpenAI hay Anthropic. Khi đó API key được lưu trong giá trị bí mật của HF
  • Thông thường để thực sự hoạt động trong phiên trình duyệt thì cần một dạng token nào đó. Vụ này có vẻ liên quan đến các token đã phải hủy, giống mật khẩu nhưng không hoàn toàn giống