Phân Tích Chi Tiết: 3 Lỗ Hổng Bảo Mật Nghiêm Trọng Trong Grok Build CLI

Một nhà nghiên cứu bảo mật độc lập tại Cereblab (@cereblab) đã thực hiện một cuộc kiểm tra chi tiết ở lớp mạng (wire-level teardown) có thể tái lập đối với Grok Build CLI phiên bản 0.2.93 của xAI bằng công cụ mitmproxy, và công bố toàn bộ phân tích dưới dạng GitHub Gist . Cuộc phân tích đã phát hiện ra ba lỗ hổng bảo mật lớn, mâu thuẫn trực tiếp với định vị "tập trung vào máy cục bộ" (local-first) cũng như vi phạm kỳ vọng về quyền riêng tư dữ liệu của nhà phát triển.

Hành Vi Rò Rỉ Dữ Liệu Mâu Thuẫn Với Tiếp Thị "Local-First"

Nhà nghiên cứu đã xác định hai luồng dữ liệu khác nhau về bản chất rời khỏi máy của nhà phát triển :

• Luồng tương tác mô hình (

  POST /v1/responses

  ): các tệp mà tác nhân (agent) đã mở được tuần tự hóa thành các yêu cầu mô hình. Đây là hành vi được mong đợi từ một tác nhân mã hóa đám mây.
• Luồng lưu trữ (

  POST /v1/storage

  ): toàn bộ kho lưu trữ được đóng gói độc lập dưới dạng git bundle và được tải lên theo từng khối khoảng 75 MB tới một bucket Google Cloud Storage có tên là grok-code-session-traces .

Sự chênh lệch về quy mô đã chứng minh việc tải lên không bị thúc đẩy bởi những gì tác nhân đọc. Trên một kho lưu trữ thử nghiệm có dung lượng 12 GB, luồng lưu trữ đã di chuyển 5,10 GiB qua 73 khối (tất cả đều nhận HTTP 200), trong khi luồng tương tác mô hình chỉ di chuyển 192 KB — một tỷ lệ ~27.800:1 . Thậm chí khi được nhắc "chỉ trả lời OK, không đọc bất kỳ tệp nào", công cụ vẫn tải lên toàn bộ kho dưới dạng git bundle; việc clone git bundle bị chặn đã khôi phục lại một tệp (src/_probe/never_read_canary.txt) mà tác nhân đã được yêu cầu rõ ràng là không được mở, cùng với toàn bộ lịch sử commit Git .

Các Loại Bí Mật Và Tệp Được Truyền Mà Không Bị Che Giấu

• Các tệp .env chứa API key, mật khẩu cơ sở dữ liệu và các thông tin xác thực khác đã được truyền nguyên văn, không có bất kỳ biện pháp che giấu hay làm mờ nào qua cả hai luồng . Trong các thử nghiệm có kiểm soát, một tệp 48 KB chứa thông tin xác thực cơ sở dữ liệu và API key đã xuất hiện rõ ràng trong phần thân của yêu cầu .
• Mọi tệp được theo dõi trong kho lưu trữ, cộng với toàn bộ lịch sử Git (tất cả các commit, nhánh, thẻ) đều được đóng gói và tải lên . Điều này có nghĩa là các bí mật đã bị xóa từ nhiều tháng trước nhưng sau đó đã được thay đổi vẫn có thể tồn tại trong dữ liệu được tải lên.
• Cơ chế tải lên được xác định là một thư viện Rust nội bộ của hãng thứ nhất (xai-data-collector) có trong tệp nhị phân, với các đường dẫn mã nguồn như crates/codegen/xai-data-collector/src/gcs.rs và crates/codegen/xai-grok-shell/src/upload/ .
• Trên một cơ sở mã thực tế 12 GB gồm các tệp ngẫu nhiên chưa từng được đọc, điểm cuối lưu trữ đã chấp nhận tải lên mà không có bất kỳ sự từ chối nào dựa trên kích thước; các phản hồi không phải 200 duy nhất là lỗi hạn mức sử dụng mô hình (402/429), không phải lỗi lưu trữ .

Sự Thất Bại Của Tùy Chọn Từ Chối (Opt-Out)

Nhà nghiên cứu đã thử nghiệm tùy chọn quyền riêng tư "Cải thiện mô hình" (Improve the model) và phát hiện ra rằng nó không ngăn được việc tải lên .

• Sau khi tắt tùy chọn và khởi động lại, điểm cuối cài đặt máy chủ vẫn trả về

  trace_upload_enabled: true

  .
• Luồng lưu trữ vẫn tiếp tục chấp nhận các tải lên git bundle dạng khối với phản hồi HTTP 200 .
• Một tùy chọn cấu hình disable_codebase_upload=true tồn tại trong cài đặt harness, nhưng mối quan hệ của nó với hành vi phía máy chủ không được ghi lại và các thử nghiệm của nhà nghiên cứu cho thấy máy chủ không tôn trọng các tùy chọn phía máy khách .

Các Biện Pháp Giảm Thiểu Được Đề Xuất Cho Nhà Phát Triển Bị Ảnh Hưởng

Nhà nghiên cứu ban đầu và các hãng phân tích tiếp theo khuyến nghị như sau :

Các hành động ngay lập tức cho các nhóm đã sử dụng Grok Build CLI trên kho lưu trữ riêng:

• Thay đổi tất cả thông tin xác thực đã tồn tại trong bất kỳ tệp .env, tệp cấu hình hoặc lịch sử git nào trong các kho lưu trữ đã sử dụng với Grok Build, vì chúng có thể đã được truyền đi và lưu trữ trong bucket GCS grok-code-session-traces .
• Kiểm tra lịch sử git để tìm các bí mật có thể đã tồn tại trong bất kỳ commit nào trong quá khứ, vì CLI đã gửi toàn bộ lịch sử commit .
• Giả định rằng dữ liệu đã được lưu trữ, không chỉ được truyền đi — máy chủ đã trả về HTTP 200 cho tất cả các yêu cầu lưu trữ, xác nhận việc chấp nhận dữ liệu .
• Yêu cầu xAI giải thích liệu bucket đã bị xóa chưa, các kiểm soát truy cập nào đã tồn tại và liệu một Thỏa thuận Xử lý Dữ liệu (DPA) có bao gồm nó hay không (không có thỏa thuận nào được công bố tại thời điểm tiết lộ) .

Các biện pháp giảm thiểu kiến trúc cho bất kỳ tác nhân mã hóa nào:

• Chạy các tác nhân trong container/VM chỉ gắn kết thư mục tác vụ, không có thư mục home, không có SSH agent, không có Docker socket và không có thư mục thông tin xác thực đám mây nào được hiển thị .
• Triển khai kiểm soát egress: cho phép các điểm cuối suy luận mô hình và các máy chủ xác thực, nhưng từ chối các tải lên đối tượng lưu trữ chung trực tiếp. Cảnh báo khi các luồng chuyển vượt quá 100 MB .
• Sử dụng tính năng chụp gói toàn bộ máy chủ, ghi nhật ký DNS và đo từ xa mạng điểm cuối để phát hiện các bản tải lên bởi các tiến trình điều phối nền mà bộ đếm byte ở nền trước sẽ bỏ qua .
• Kiểm tra các lời nhắc tối thiểu và tối đa dưới sự chụp gói — các trường hợp tác nhân được yêu cầu không đọc tệp là rất quan trọng để phát hiện hành vi rò rỉ dữ liệu vượt ra ngoài cửa sổ ngữ cảnh .
• Chạy ít nhất ba trường hợp lời nhắc: (1) "chỉ trả lời OK, không đọc bất kỳ tệp nào," (2) đọc một tệp cụ thể, (3) kiểm tra ngôn ngữ dự án — sau đó so sánh byte trên mỗi điểm cuối .