Strix tìm thấy token GitHub admin của Baseten chỉ trong 25 phút

Một công ty bảo mật đã dùng agent AI của mình để quét hệ thống Baseten trước khi quyết định tin tưởng giao dữ liệu cho nền tảng suy luận AI này. Chỉ sau 25 phút, agent tìm ra một token GitHub cá nhân còn hiệu lực với quyền admin trên nhiều kho mã nguồn quan trọng của Baseten. Sự việc cho thấy những lỗ hổng từ ảnh container cũ có thể âm thầm tồn tại suốt nhiều năm và trở thành cửa ngõ nguy hiểm cho kẻ tấn công.

Bối cảnh: Kiểm tra bảo mật trước khi tin tưởng

Công ty bảo mật Strix đang cân nhắc sử dụng Baseten – một nền tảng suy luận AI được định giá 13 tỷ USD – để chạy các mô hình của mình. Nhưng vì là công ty bảo mật, họ quyết định quét hệ thống của Baseten trước, nhằm phát hiện sớm các vấn đề nghiêm trọng trước khi phụ thuộc vào dịch vụ.

Họ hướng agent tự động Strix vào tên miền *.baseten.co mà không cung cấp thông tin đăng nhập hay mã nguồn. Kết quả: Strix tìm thấy một token truy cập cá nhân GitHub (PAT) đang hoạt động của tài khoản basetenbot, có quyền admin và push trên repo sản phẩm chính, repo GitOps điều khiển cluster, và tap Homebrew của Baseten.

Minh họa token bị phát hiện

Cách Strix phát hiện lỗ hổng

Strix bắt đầu bằng bước trinh sát (recon): liệt kê host, tra cứu log chứng chỉ, vẽ bản đồ bề mặt tấn công. Từ đó nó tìm thấy một Harbor registry tại gcp-us-east4-zlw.registry.baseten.co.

Harbor lưu trữ ảnh container và nhóm các repository thành project. Một project trong số đó là công khai. Không cần token hay xác thực, Strix có thể liệt kê repository, lấy token pull ẩn danh, và tải về manifest cùng blob của ảnh – bao gồm ảnh baseten/baseten-app.

Strix quyết định pull ảnh về xem có gì bên trong. Cặp khóa AWS đầu tiên tìm thấy đã hết hiệu lực. Nhưng sau khi chạy TruffleHog và kiểm tra trực tiếp config của ảnh, nó phát hiện một token GitHub cá nhân nằm trong trường history[].created_by.

Điểm mấu chốt: ảnh Docker không chỉ có các lớp filesystem mà còn có config chứa lịch sử build. Xóa file chứa thông tin xác thực không giúp gì nếu lịch sử build vẫn còn một bản sao khác của token.

Token được dùng để gọi GET /user trên GitHub và trả về mã 200 với tên tài khoản basetenbot. Bước build chứa token có dấu thời gian ngày 3/3/2023 – nghĩa là token vẫn hoạt động sau hơn ba năm.

Mức độ truy cập đáng báo động

Sau khi xác minh, Strix kiểm tra các quyền cụ thể của token bằng request chỉ đọc:

• basetenlabs/baseten: admin, push – đây là mã nguồn sản phẩm chính
• basetenlabs/flux-cd: admin, push – repo GitOps điều khiển hạ tầng cluster
• basetenlabs/homebrew-tap: admin, push – kênh phân phối CLI
• basetenlabs/release-platform, basevibe, trainers, baseten-dbt: quyền đọc/ghi riêng tư

Quyền admin trên flux-cd đặc biệt nguy hiểm vì đây là GitOps: repo chứa trạng thái mong muốn của cluster, và Flux sẽ áp dụng trạng thái đó vào hạ tầng thật. Kẻ tấn công có thể chuyển từ một token build bị rò rỉ sang thay đổi hạ tầng production.

Minh họa quyền truy cập GitHub

Nguyên nhân và bài học

Lỗi bắt nguồn từ một mẫu Dockerfile quen thuộc: truyền token qua build argument để fetch dependency riêng tư từ GitHub. Docker ghi lại build argument đó trong metadata và lịch sử của ảnh – trong trường hợp này là giá trị token thật. Thêm vào đó, lệnh git config --global còn ghi URL đã xác thực vào file cấu hình Git, khiến token bị lưu lại trong ảnh.

Cách khắc phục đúng:

• Dùng BuildKit secret mount và xác thực tạm thời, không lưu credential
• Kiểm tra cả các lớp filesystem lẫn lịch sử build của ảnh
• Thu hồi token cũ – sửa Dockerfile không giúp gì với ảnh đã bị tải về trước đó
• Giới hạn quyền và đặt thời hạn cho token build

Phản hồi từ Baseten

Baseten đã xử lý sự việc chuyên nghiệp và nhanh chóng:

• 13/7, 23:10: Strix báo cáo token, project Harbor công khai và các quyền repository
• 14/7, buổi sáng: Baseten chuyển project Harbor sang riêng tư
• 14/7, 16:34: Đội bảo mật Baseten xác nhận mức độ nghiêm trọng là critical, đã thu hồi token
• 17/7: Baseten đóng các phát hiện còn lại

Đáng chú ý, Strix không được yêu cầu tìm Harbor hay gợi ý về token – nó tự hoàn thành toàn bộ quá trình trong khoảng 25 phút.

Lời khuyên cho doanh nghiệp

Sự việc này là lời cảnh tỉnh cho bất kỳ ai vận hành container và dùng GitHub:

• Kiểm tra xem người khác có thể pull gì mà không cần đăng nhập, kể cả tag cũ
• Đọc lịch sử build bằng docker history --no-trunc hoặc kiểm tra trường history[].created_by
• Loại bỏ secret khỏi build argument, dùng secret mount
• Kiểm tra token build thực sự có thể làm gì và giới hạn quyền, đặt thời hạn
• Chủ động chạy các công cụ như Strix để tự tấn công hệ thống của mình trước khi kẻ xấu làm điều đó

Khi một agent AI có thể tìm ra token admin còn sống trong một ảnh cũ chỉ trong 25 phút, tốt hơn hết là bạn nên tự tìm ra nó trước.