26.400 thông tin xác thực cloud và AI còn hiệu lực lộ trên Gitee
Một nhà nghiên cứu phát hiện 26.400 thông tin xác thực còn hiệu lực trong các kho Gitee công khai sau khi quét 7,25 triệu repository. Phần lớn liên quan dịch vụ cloud và AI, nhấn mạnh nhu cầu xử lý rò rỉ secret như một sự cố bảo mật.
Một secret bị đưa lên repository công khai không nên chỉ được xem là lỗi vệ sinh mã nguồn. Nếu thông tin xác thực vẫn còn hiệu lực, người sao chép nó có thể sử dụng dịch vụ hoặc tài khoản liên quan, tùy thuộc vào quyền được cấp.
Theo The Hacker News, nhà nghiên cứu độc lập Ben Zimmermann đã quét 7,25 triệu repository công khai trên Gitee và kiểm tra các thông tin xác thực tìm được vào ngày 28/10. Kết quả cho thấy 26.400 thông tin xác thực vẫn còn hiệu lực, trong đó phần lớn là key dành cho dịch vụ cloud và AI.
Với SOC, đây là lời nhắc rõ ràng: một secret bị lộ có thể là một đường truy cập còn hoạt động. Việc xử lý cần bắt đầu như một incident, thay vì chờ đến đợt dọn dẹp mã nguồn tiếp theo.
Điều nguồn tin xác nhận — và những gì chưa thể kết luận
Gitee là dịch vụ lưu trữ mã nguồn tại Trung Quốc. Phát hiện nói trên cho thấy credential trong repository công khai có thể vẫn dùng được tại thời điểm được kiểm tra.
Tuy nhiên, thông tin được cung cấp không nêu:
Quyền cụ thể của từng credential.
Chủ sở hữu của các credential.
Dịch vụ hoặc tài khoản cụ thể bị ảnh hưởng.
Bằng chứng cho thấy các credential đã bị lạm dụng.
Vì vậy, không nên suy diễn rằng mọi secret bị lộ đều đồng nghĩa với xâm nhập nghiêm trọng. Mức độ rủi ro phải được đánh giá theo loại credential, quyền hạn, thời gian phơi lộ và nhật ký sử dụng thực tế.
SOC nên ưu tiên câu hỏi nào?
Khi nhận cảnh báo secret xuất hiện trên repository công khai, đội ứng phó có thể ưu tiên ba câu hỏi:
Credential có còn hiệu lực không?
Credential được cấp những quyền gì?
Có dấu hiệu sử dụng bất thường trong thời gian phơi lộ không?
Các câu hỏi này giúp phân biệt một chuỗi ký tự cần xác minh với một rủi ro truy cập cần cô lập khẩn cấp.
Quy trình xử lý đề xuất: thu hồi trước, điều tra song song
Nếu credential có khả năng còn hiệu lực, tổ chức nên cân nhắc xử lý theo thứ tự ưu tiên sau.
1. Mở incident và khoanh vùng
Ghi nhận repository, tệp, commit, thời điểm phát hiện và chủ sở hữu kỹ thuật của secret. Hạn chế sao chép nguyên văn credential vào ticket mở, nhóm chat đông người hoặc công cụ không được phê duyệt.
Việc xác minh nên dựa trên cơ chế quản trị, nhật ký hoặc quy trình được ủy quyền của tổ chức, thay vì tái sử dụng secret bị lộ.
2. Vô hiệu hóa hoặc xoay vòng credential
Xóa secret khỏi repository không làm các bản sao đã được tải xuống biến mất. Vì thế, nếu rủi ro được xác nhận hoặc đủ cao, ưu tiên là thu hồi, vô hiệu hóa hoặc xoay vòng thông tin xác thực.
Sau đó, đội vận hành cần cập nhật ứng dụng, pipeline hoặc môi trường liên quan bằng credential mới qua kênh quản lý secret phù hợp.
3. Rà soát nhật ký sử dụng
Việc xoay vòng không thay thế điều tra. SOC nên phối hợp với chủ sở hữu dịch vụ để rà soát nhật ký trong khoảng thời gian credential có thể đã bị công khai.
Các điểm cần đối chiếu có thể gồm:
Hoạt động sử dụng không khớp với hành vi dự kiến của ứng dụng.
Mức sử dụng dịch vụ tăng bất thường.
Hoạt động xảy ra ở thời điểm không phù hợp với lịch vận hành.
Các thay đổi bất thường liên quan đến tài khoản hoặc dịch vụ gắn với credential.
Mọi dấu hiệu cần được đánh giá trong ngữ cảnh vận hành thực tế, tránh kết luận chỉ dựa trên một chỉ báo đơn lẻ.
Đưa kiểm soát vào vòng đời phát triển
Phát hiện trên Gitee là lý do để doanh nghiệp rà soát phạm vi kiểm soát secret của chính mình, bao gồm cả repository công khai và các nền tảng mã nguồn ngoài danh mục chính thức.
Một chương trình phòng ngừa có thể bao gồm:
Quét secret trước khi commit, khi tạo pull request và định kỳ trên repository hiện có.
Bao phủ repository công khai, private và các kho mã cũ có rủi ro.
Xác định đầu mối chịu trách nhiệm đối với từng loại credential.
Lưu secret trong hệ thống quản lý chuyên dụng thay vì nhúng trực tiếp vào mã nguồn hoặc tệp cấu hình.
Áp dụng quyền tối thiểu cho credential.
Thiết lập quy trình thu hồi, xoay vòng và điều tra khi phát hiện rò rỉ.
Liên kết cảnh báo secret với quy trình incident response và nguồn log liên quan.
Với các dự án AI, tổ chức cũng nên xác định rõ dữ liệu và thông tin xác thực nào được phép đưa vào công cụ hỗ trợ phát triển. Secret, token và cấu hình nhạy cảm không nên được chia sẻ qua công cụ chưa được phê duyệt cho mục đích đó.
Checklist ngắn cho đội phòng thủ
[ ] Có quy trình xử lý riêng cho credential bị lộ.
[ ] Có đầu mối giữa SOC, AppSec, cloud/AI platform và chủ sở hữu ứng dụng.
[ ] Có cơ chế quét secret trên các repository có rủi ro.
[ ] Có khả năng vô hiệu hóa hoặc xoay vòng credential kịp thời.
[ ] Có log phù hợp để điều tra việc sử dụng credential.
[ ] Có quy tắc quản lý secret trong mã nguồn và công cụ AI dùng trong phát triển.
Con số 26.400 credential còn hiệu lực trong repository công khai không cho biết mức độ ảnh hưởng của từng trường hợp. Nhưng nó nhấn mạnh một nguyên tắc vận hành quan trọng: khi secret đã xuất hiện công khai, đội phòng thủ nên giả định rằng credential đó cần được xác minh và xử lý khẩn trương.