Lỗ hổng RCE trên Google DevSite: Bí mật bị rò rỉ cho phép thực thi mã từ xa

Nhà nghiên cứu bảo mật Simon Koeck đã phát hiện ra một lỗ hổng thực thi mã từ xa (RCE) nghiêm trọng trên nền tảng DevSite dùng chung của Google vào tháng 8 năm 2026. Lỗi này cho phép kẻ tấn công thực thi mã tùy ý trên các máy chủ lưu trữ tài liệu dành cho nhà phát triển của các dịch vụ như Firebase và Android bằng cách khai thác một cookie phiên Flask bị cấu hình sai. Google đã trao thưởng cho Koeck 90.000 USD sau khi xác nhận vấn đề ảnh hưởng đến nhiều tên miền con quan trọng.

Chuyện gì đã xảy ra

Koeck đang lập bản đồ luồng xác thực OAuth được sử dụng trên các trang web tài liệu dành cho nhà phát triển của Google, bao gồm developers.google.com. Ông nhận thấy rằng cookie phiên Flask được cấp trong quá trình bắt tay OAuth có kích thước bất thường lớn, khoảng 1.200 byte. Vì cookie Flask được ký nhưng không được mã hóa, ông đã giải mã payload để kiểm tra nội dung bên trong. Tại đó, ông tìm thấy một đối tượng được tuần tự hóa bằng pickle chứa một phiên bản oauth2client.client.OAuth2WebServerFlow. Quan trọng hơn, đối tượng này giữ client_id và client_secret của Google OAuth dưới dạng văn bản thuần túy.

Sự hiện diện của bí mật khách hàng trong một cookie phía client vốn đã là một phát hiện bảo mật đáng kể. Tuy nhiên, Koeck nhận ra những hàm ý còn sâu xa hơn khi ông thử nghiệm xem bí mật này có đồng thời được dùng làm SECRET_KEY của Flask để ký chính cookie đó hay không. Bằng cách suy ra khóa ký từ bí mật khách hàng bị lộ thông qua logic thư viện chuẩn itsdangerous của Flask, ông đã thành công trong việc tái tạo chữ ký của cookie ngoại tuyến. Điều này có nghĩa là máy chủ đang sử dụng một bí mật được lưu trữ ngay trong dữ liệu mà nó cố gắng bảo vệ để xác minh tính toàn vẹn của dữ liệu đó.

Với khả năng giả mạo các chữ ký phiên hợp lệ, Koeck có thể bỏ qua các biện pháp kiểm soát bảo mật dự kiến. Logic ứng dụng truy xuất đối tượng luồng OAuth từ phiên và giải mã nó bằng cách sử dụng pickle.loads(). Bởi vì mô-đun pickle của Python có thể thực thi mã tùy ý trong quá trình giải mã nếu gặp phải các opcode cụ thể, và vì Koeck giờ đây có thể tạo ra các cookie được ký hợp lệ, ông đã đạt được quyền thực thi mã từ xa không cần xác thực. Ông chứng minh điều này bằng cách chèn các payload khiến máy chủ tạm dừng (sleep) trong những khoảng thời gian nhất định, chứng minh rằng mã đang chạy ở backend mà không cần truy cập vào dữ liệu sản xuất nhạy cảm.

Cơ chế hoạt động

Lỗ hổng dựa vào chuỗi ba cấu hình sai cụ thể. Thứ nhất, ứng dụng lưu trữ thông tin đăng nhập nhạy cảm (bí mật khách hàng OAuth) trực tiếp trong cookie phiên của người dùng. Thứ hai, nó sử dụng chính bí mật khách hàng đó làm khóa mật mã để ký cookie phiên, tạo ra một vòng lặp phụ thuộc nơi khóa trở nên công khai với bất kỳ ai kiểm tra cookie. Thứ ba, ứng dụng giải mã dữ liệu do người dùng kiểm soát từ cookie bằng cách sử dụng mô-đun pickle của Python, vốn không an toàn về bản chất đối với đầu vào không đáng tin cậy vì nó cho phép khởi tạo đối tượng và gọi phương thức trong quá trình tải.

Flask sử dụng thư viện itsdangerous để ký cookie, thường suy ra một khóa ký cụ thể từ SECRET_KEY chính bằng cách sử dụng HMAC-SHA1. Koeck đã sao chép quá trình suy ra này cục bộ bằng cách sử dụng bí mật khách hàng bị rò rỉ. Sau khi xác nhận chữ ký khớp, ông tạo ra một cookie phiên mới. Ông chèn một payload pickle độc hại dưới khóa phiên mong đợi, ký nó bằng khóa đã suy ra và gửi nó đến máy chủ. Máy chủ xác minh chữ ký thành công, trích xuất pickle và thực thi các chỉ lệnh nhúng, chẳng hạn như gọi time.sleep().

Chi tiết chính

• Lỗ hổng tồn tại trên nền tảng DevSite dùng chung, ảnh hưởng đến developers.google.com, firebase.google.com, developer.android.com, source.android.com và docs.partner.android.com.
• Cookie phiên Flask chứa một đối tượng OAuth2WebServerFlow được tuần tự hóa bằng pickle với client_secret OAuth đang hoạt động dưới dạng văn bản thuần túy.
• client_secret OAuth được sử dụng làm SECRET_KEY của Flask để ký cookie phiên, cho phép kẻ tấn công giả mạo các phiên hợp lệ.
• Việc thực thi mã từ xa được chứng minh bằng các payload time.sleep(N), trong đó thời gian phản hồi của máy chủ khớp chính xác với thời lượng sleep được chèn.
• Google phân loại vấn đề này là RCE mức S0 (nghiêm trọng) và trao khoản tiền thưởng 90.000 USD, được tính bằng mức cơ sở 75.000 USD cộng với hệ số nhân 1,2x cho chất lượng báo cáo.
• Bản vá liên quan đến việc xoay vòng bí mật, tách biệt các khóa ký khỏi thông tin đăng nhập OAuth, lưu trữ các đối tượng luồng ở phía server và thay thế pickle bằng một định dạng dữ liệu an toàn.

Tại sao điều này quan trọng

Sự cố này nhấn mạnh những nguy hiểm của việc sử dụng các định dạng tuần tự hóa phức tạp như pickle cho dữ liệu vượt qua ranh giới tin cậy. Mặc dù pickle tiện lợi cho việc bảo toàn trạng thái đối tượng Python, nó không cung cấp cơ chế nào để hạn chế các lớp hoặc hàm có thể được gọi trong quá trình giải mã. Khi kết hợp với một khóa ký bị xâm phạm, nó trở thành đường dẫn trực tiếp đến việc thực thi mã từ xa. Các nhà phát triển thường giả định rằng cookie được ký là chống giả mạo, nhưng nếu khóa ký bị rò rỉ hoặc quản lý kém, đảm bảo đó hoàn toàn biến mất.

Đối với các nhóm kỹ thuật, đây là lời nhắc nhở phải kiểm toán cách quản lý và xoay vòng bí mật. Sử dụng một thông tin đăng nhập cho nhiều mục đích—chẳng hạn như cả xác thực API và ký phiên—sẽ tăng bán kính thiệt hại của một lần rò rỉ đơn lẻ. Nó cũng nhấn mạnh tầm quan trọng của việc giữ trạng thái nhạy cảm ở phía server. Cookie chỉ nên chứa các tham chiếu mờ đục hoặc dữ liệu tối thiểu, không nhạy cảm, đặc biệt khi xử lý các luồng xác thực liên quan đến các nhà cung cấp bên thứ ba như Google OAuth.

Bạn có thể làm gì

• Kiểm toán quản lý phiên của ứng dụng để đảm bảo các khóa ký khác biệt so với các thông tin đăng nhập khác như bí mật API hoặc token OAuth.
• Thay thế pickle bằng các định dạng tuần tự hóa an toàn như JSON hoặc Protocol Buffers cho bất kỳ dữ liệu nào di chuyển đến client hoặc vượt qua ranh giới tin cậy.
• Lưu trữ trạng thái nhạy cảm, chẳng hạn như các đối tượng luồng OAuth, trong các phiên hoặc cache phía server thay vì trong cookie phía client.
• Triển khai các chính sách bảo mật nội dung nghiêm ngặt và giám sát các mẫu độ trễ bất thường có thể chỉ ra các nỗ lực RCE mù dựa trên thời gian.
• Xoay vòng tất cả các bí mật bị lộ ngay lập tức nếu nghi ngờ có rò rỉ và vô hiệu hóa các phiên hiện có được ký bằng các khóa đó.
• Sử dụng các công cụ phân tích tĩnh để phát hiện việc sử dụng các phương pháp giải mã không an toàn như pickle.loads() trên đầu vào không đáng tin cậy.