Lỗ hổng đến từ độ trễ lan truyền

Nguyên nhân của hiện tượng này nằm ở cách Google vận hành hạ tầng đám mây phân tán quy mô lớn. Khi một API key bị xóa, trạng thái thu hồi không được áp dụng đồng thời trên toàn bộ hệ thống xác thực.

Một số máy chủ cập nhật nhanh và từ chối khóa gần như ngay lập tức, trong khi các máy chủ khác có thể vẫn chấp nhận khóa cho đến khi thông tin xóa được lan truyền đầy đủ trong hệ thống.

Để kiểm chứng, Aikido tạo các API key mới, sau đó xóa chúng và liên tục gửi các yêu cầu xác thực. Trong 10 lần thử nghiệm, họ vẫn nhận được phản hồi xác thực thành công cho đến khi việc thu hồi được cập nhật hoàn toàn, dẫn đến khoảng thời gian hoạt động thêm từ 8–23 phút.

Điều này có nghĩa là một khóa đã "bị xóa" trên giao diện quản lý vẫn có thể hoạt động tạm thời ở một số phần của nền tảng.

Vì sao khoảng trễ này gây rủi ro

Trong các sự cố rò rỉ thông tin xác thực, việc thu hồi ngay lập tức là bước quan trọng để chặn truy cập trái phép. Tuy nhiên, độ trễ này tạo ra một khoảng thời gian mà kẻ tấn công vẫn có thể sử dụng khóa dù đội bảo mật tin rằng nó đã bị vô hiệu hóa.

Nếu một API key bị lộ trong giai đoạn đó, kẻ tấn công vẫn có thể:

• Truy cập các API đã bật trong dự án
• Gửi thêm yêu cầu API
• Gây phát sinh mức sử dụng và chi phí đám mây ngoài ý muốn

Các nhà nghiên cứu xác nhận hiện tượng này khi thử nghiệm với khóa dùng cho Gemini, và cũng thấy hành vi tương tự với các API khác của Google Cloud như BigQuery và Google Maps. Điều này cho thấy vấn đề nằm ở loại thông tin xác thực API key, không phải ở một dịch vụ cụ thể.

Phản hồi ban đầu từ Google

Theo báo cáo công bố, Google ban đầu xem đây là độ trễ lan truyền (propagation delay) bình thường trong một hệ thống phân tán, thay vì một lỗi bảo mật nghiêm trọng. Một số nguồn cho biết báo cáo ban đầu thậm chí đã bị đóng với trạng thái "won’t fix".

Tuy nhiên sau khi được xem xét lại, báo cáo sau đó đã được mở lại và được phân loại nội bộ là lỗi mức P0 — mức ưu tiên cao nhất để điều tra và xử lý.

Về mặt kỹ thuật, nguyên nhân gốc vẫn là quá trình cập nhật trạng thái thu hồi cần thời gian lan truyền qua nhiều hệ thống backend khác nhau của Google.

Các biện pháp phòng ngừa cho nhà phát triển

Cho đến khi hành vi thu hồi được đảm bảo diễn ra ngay lập tức, các đội phát triển và bảo mật nên giả định rằng việc xóa API key không chặn truy cập ngay lập tức.

Một số biện pháp thực tế gồm:

Xem việc xóa khóa là bước kiểm soát có độ trễ
Chuẩn bị cho một khoảng rủi ro tạm thời — khoảng tối đa 30 phút — trong đó khóa bị lộ vẫn có thể hoạt động.

Theo dõi log và chi phí sau khi thu hồi
Các yêu cầu API bất thường hoặc mức sử dụng tăng đột biến ngay sau khi xóa khóa có thể cho thấy khóa vẫn đang bị khai thác.

Giới hạn phạm vi API key
Google khuyến nghị áp dụng các hạn chế như chỉ cho phép từ địa chỉ IP nhất định, referrer cụ thể hoặc API cụ thể để giảm thiểu tác động nếu khóa bị lộ.

Luân phiên và thay thế thông tin xác thực
Thay vì chỉ xóa khóa, hãy tạo khóa mới và cập nhật ứng dụng sử dụng khóa mới càng nhanh càng tốt.

Bài học lớn hơn cho bảo mật đám mây

Phát hiện này nhấn mạnh một thực tế quan trọng của các hệ thống phân tán quy mô lớn: nhiều thay đổi cấu hình — bao gồm việc thu hồi thông tin xác thực — không có hiệu lực ngay lập tức trên toàn bộ hạ tầng.

Vì vậy, trong vận hành bảo mật, cần nhớ rằng: "đã xóa" không phải lúc nào cũng đồng nghĩa với "đã ngừng hoạt động ngay lập tức". Các quy trình ứng phó sự cố nên tính đến những khoảng trễ lan truyền ngắn khi thu hồi khóa hoặc thông tin xác thực nhạy cảm.

Lỗ hổng đến từ độ trễ lan truyền

Nguyên nhân của hiện tượng này nằm ở cách Google vận hành hạ tầng đám mây phân tán quy mô lớn. Khi một API key bị xóa, trạng thái thu hồi không được áp dụng đồng thời trên toàn bộ hệ thống xác thực.

Một số máy chủ cập nhật nhanh và từ chối khóa gần như ngay lập tức, trong khi các máy chủ khác có thể vẫn chấp nhận khóa cho đến khi thông tin xóa được lan truyền đầy đủ trong hệ thống.

Để kiểm chứng, Aikido tạo các API key mới, sau đó xóa chúng và liên tục gửi các yêu cầu xác thực. Trong 10 lần thử nghiệm, họ vẫn nhận được phản hồi xác thực thành công cho đến khi việc thu hồi được cập nhật hoàn toàn, dẫn đến khoảng thời gian hoạt động thêm từ 8–23 phút.

Điều này có nghĩa là một khóa đã "bị xóa" trên giao diện quản lý vẫn có thể hoạt động tạm thời ở một số phần của nền tảng.

Vì sao khoảng trễ này gây rủi ro

Trong các sự cố rò rỉ thông tin xác thực, việc thu hồi ngay lập tức là bước quan trọng để chặn truy cập trái phép. Tuy nhiên, độ trễ này tạo ra một khoảng thời gian mà kẻ tấn công vẫn có thể sử dụng khóa dù đội bảo mật tin rằng nó đã bị vô hiệu hóa.

Nếu một API key bị lộ trong giai đoạn đó, kẻ tấn công vẫn có thể:

• Truy cập các API đã bật trong dự án
• Gửi thêm yêu cầu API
• Gây phát sinh mức sử dụng và chi phí đám mây ngoài ý muốn

Các nhà nghiên cứu xác nhận hiện tượng này khi thử nghiệm với khóa dùng cho Gemini, và cũng thấy hành vi tương tự với các API khác của Google Cloud như BigQuery và Google Maps. Điều này cho thấy vấn đề nằm ở loại thông tin xác thực API key, không phải ở một dịch vụ cụ thể.

Phản hồi ban đầu từ Google

Theo báo cáo công bố, Google ban đầu xem đây là độ trễ lan truyền (propagation delay) bình thường trong một hệ thống phân tán, thay vì một lỗi bảo mật nghiêm trọng. Một số nguồn cho biết báo cáo ban đầu thậm chí đã bị đóng với trạng thái "won’t fix".

Tuy nhiên sau khi được xem xét lại, báo cáo sau đó đã được mở lại và được phân loại nội bộ là lỗi mức P0 — mức ưu tiên cao nhất để điều tra và xử lý.

Về mặt kỹ thuật, nguyên nhân gốc vẫn là quá trình cập nhật trạng thái thu hồi cần thời gian lan truyền qua nhiều hệ thống backend khác nhau của Google.

Các biện pháp phòng ngừa cho nhà phát triển

Cho đến khi hành vi thu hồi được đảm bảo diễn ra ngay lập tức, các đội phát triển và bảo mật nên giả định rằng việc xóa API key không chặn truy cập ngay lập tức.

Một số biện pháp thực tế gồm:

Xem việc xóa khóa là bước kiểm soát có độ trễ
Chuẩn bị cho một khoảng rủi ro tạm thời — khoảng tối đa 30 phút — trong đó khóa bị lộ vẫn có thể hoạt động.

Theo dõi log và chi phí sau khi thu hồi
Các yêu cầu API bất thường hoặc mức sử dụng tăng đột biến ngay sau khi xóa khóa có thể cho thấy khóa vẫn đang bị khai thác.

Giới hạn phạm vi API key
Google khuyến nghị áp dụng các hạn chế như chỉ cho phép từ địa chỉ IP nhất định, referrer cụ thể hoặc API cụ thể để giảm thiểu tác động nếu khóa bị lộ.

Luân phiên và thay thế thông tin xác thực
Thay vì chỉ xóa khóa, hãy tạo khóa mới và cập nhật ứng dụng sử dụng khóa mới càng nhanh càng tốt.

Bài học lớn hơn cho bảo mật đám mây

Phát hiện này nhấn mạnh một thực tế quan trọng của các hệ thống phân tán quy mô lớn: nhiều thay đổi cấu hình — bao gồm việc thu hồi thông tin xác thực — không có hiệu lực ngay lập tức trên toàn bộ hạ tầng.

Vì vậy, trong vận hành bảo mật, cần nhớ rằng: "đã xóa" không phải lúc nào cũng đồng nghĩa với "đã ngừng hoạt động ngay lập tức". Các quy trình ứng phó sự cố nên tính đến những khoảng trễ lan truyền ngắn khi thu hồi khóa hoặc thông tin xác thực nhạy cảm.