Cảnh báo: Lỗ hổng ‘GitLost’ cho phép kẻ tấn công đánh cắp dữ liệu từ GitHub private repo

Một kỹ thuật tấn công mới có tên gọi GitLost vừa được các chuyên gia tại Noma Security công bố, cho thấy cách thức một issue công khai có thể đánh lừa GitHub Agentic Workflows để rò rỉ nội dung từ các private repository của tổ chức.

Cơ chế tấn công GitLost

Điểm đáng chú ý của GitLost là kẻ tấn công không cần quyền truy cập vào hệ thống, không cần đánh cắp thông tin đăng nhập (credentials), mà chỉ cần tạo một issue trông có vẻ bình thường trên một repository công khai. Nếu tổ chức đó đã cấp cho AI agent quyền truy cập đọc (read access) trên toàn bộ các repository (bao gồm cả private), agent có thể bị thao túng để trích xuất dữ liệu nhạy cảm và đăng tải lên các bình luận công khai.

Về bản chất, đây là một dạng indirect prompt injection. AI agent không thể phân biệt rạch ròi giữa chỉ dẫn từ chủ sở hữu và các chỉ dẫn độc hại được ẩn giấu trong nội dung mà nó đọc được. Trong thử nghiệm của Noma, chỉ cần thêm một từ khóa đơn giản như “Additionally” vào trước câu lệnh độc hại là đủ để vượt qua các bộ lọc bảo mật (guardrails) hiện có của GitHub.

Tại sao GitLost lại nguy hiểm?

Theo Sasi Levi, Trưởng nhóm nghiên cứu bảo mật tại Noma, GitLost không chỉ dừng lại ở việc thao túng phản hồi của AI mà là thao túng hành động của agent dựa trên các quyền hạn được cấp. Agent ở đây đóng vai trò như một tác nhân có đầy đủ quyền hạn nằm trong hạ tầng CI/CD, có khả năng tiếp cận dữ liệu mà kẻ tấn công thông thường không thể thấy.

Đây được coi là một “bộ ba sát thủ” (lethal trifecta) trong bảo mật AI:

• Agent có quyền truy cập dữ liệu riêng tư.
• Agent xử lý nội dung đầu vào không đáng tin cậy từ bên ngoài.
• Agent có khả năng xuất dữ liệu ra môi trường công khai.

Khuyến nghị bảo mật

Vì đây được coi là hạn chế về mặt cấu trúc (architectural limitation) hơn là một lỗi phần mềm thông thường, các chuyên gia khuyến cáo người dùng cần thực hiện các biện pháp phòng ngừa:

• Giới hạn phạm vi quyền hạn (Scope): Thay vì cấp quyền truy cập toàn bộ tổ chức (org-wide), hãy giới hạn token của agent chỉ trong phạm vi repository cụ thể mà nó cần xử lý.
• Kiểm soát đầu ra: Hạn chế khả năng đăng bài của các workflow công khai và thiết lập quy trình phê duyệt thủ công (human review) trước khi nội dung được xuất bản.
• Lọc nội dung: Cẩn trọng với các nguồn dữ liệu đầu vào mà agent được phép đọc.

Các bộ lọc bảo mật hiện nay chỉ đóng vai trò là lớp phòng thủ bổ sung, không phải là ranh giới an toàn tuyệt đối. Do đó, việc cô lập quyền hạn và thiết lập quy trình kiểm soát chặt chẽ vẫn là ưu tiên hàng đầu cho các tổ chức sử dụng AI agent trong quy trình phát triển phần mềm.

Nguồn tham khảo: The Hacker News