Lỗi bảo mật trị giá 90.000 USD của Google: Tái sử dụng bí mật OAuth và giải mã pickle

Simon Köck, kỹ sư phần mềm tại Otark GmbH, đã phát hiện một lỗ hổng nghiêm trọng cho phép thực thi mã từ xa (RCE) trong cơ sở hạ tầng DevSite của Google vào tháng 8 năm 2026. Lỗ hổng này cho phép kẻ tấn công không cần xác thực có thể thực thi mã tùy ý trên các máy chủ lưu trữ developers.google.com và các trang tài liệu liên quan. Google đánh giá vấn đề này ở mức S0, mức độ nghiêm trọng cao nhất, và trả cho Köck khoản tiền thưởng 90.000 USD, tuy nhiên phải mất hai tháng để triển khai bản vá.

Chuyện gì đã xảy ra

Lỗ hổng tồn tại trong DevSite, nền tảng chung cung cấp dịch vụ cho bảy tên miền tài liệu dành cho nhà phát triển của Google. Köck xác định rằng ứng dụng lưu trữ một đối tượng OAuth2WebServerFlow đã được tuần tự hóa từ thư viện oauth2client cũ (deprecated) bên trong cookie phiên Flask. Cấu hình này vô tình tiết lộ bí mật khách hàng OAuth (OAuth client secret) trong dữ liệu cookie. Nghiêm trọng hơn, Google đã tái sử dụng chính bí mật khách hàng OAuth đó làm khóa ký cho các phiên Flask.

Vì bí mật vừa bị lộ trong cookie lại vừa được dùng để ký cookie đó, Köck có thể tái tạo chữ ký ngoại tuyến. Điều này cho phép anh giả mạo các cookie phiên hợp lệ mà máy chủ sẽ chấp nhận mà không kiểm tra. Anh chứng minh rằng các phiên giả mạo được chấp nhận trên cả bảy tên miền bị ảnh hưởng, vốn phụ thuộc vào hai khóa ký khác nhau. Anh đã thực thi thành công mã chứng minh khái niệm (proof-of-concept) trên ba máy chủ trong số đó: developers.google.com, docs.partner.android.com và web.dev.

Köck xác nhận khả năng thực thi mã từ xa không cần xác thực bằng cách gửi payload Python sleep và đo độ trễ phản hồi. Anh cố ý tránh chạy các lệnh chạm vào tệp, thông tin đăng nhập hoặc dịch vụ nội bộ để ngăn ngừa thiệt hại thực tế. Google trao cho anh khoản thanh toán cơ bản 75.000 USD cho lỗi RCE mức S0 trong phân lớp ứng dụng thông thường, nhân với hệ số 1,2 do chất lượng báo cáo xuất sắc.

Cơ chế hoạt động

Chuỗi khai thác dựa vào sự đồng thời của ba điểm yếu bảo mật cụ thể. Thứ nhất, ứng dụng tiết lộ một giá trị bí mật bên trong cookie phía máy khách. Thứ hai, cùng bí mật đó được tái sử dụng làm khóa ký mật mã cho phiên, cho phép kẻ tấn công tạo chữ ký hợp lệ cho các cookie đã bị sửa đổi. Thứ ba, ứng dụng sử dụng mô-đun pickle của Python để giải mã (deserialize) dữ liệu phiên trong quá trình gọi lại OAuth.

Pickle được biết là không an toàn khi xử lý dữ liệu không đáng tin cậy vì nó có thể thực thi mã tùy ý trong quá trình giải mã. Bằng cách thay thế đối tượng flow hợp pháp trong cookie bằng payload pickle độc hại và ký nó bằng bí mật bị lộ, Köck buộc máy chủ thực thi mã của anh khi xử lý phiên. Việc khắc phục bất kỳ một trong ba vấn đề này—che giấu bí mật, sử dụng khóa ký riêng biệt, hoặc tránh dùng pickle—sẽ đều phá vỡ chuỗi tấn công.

Chi tiết chính

• Hệ thống bị ảnh hưởng: Bảy tên miền tài liệu dành cho nhà phát triển của Google, bao gồm developers.google.com, docs.partner.android.com và web.dev.
• Loại lỗ hổng: Thực thi mã từ xa không cần xác thực thông qua giải mã không an toàn và tái sử dụng khóa.
• Nguyên nhân gốc rễ: Tái sử dụng bí mật khách hàng OAuth làm khóa ký phiên Flask và việc sử dụng pickle của Python cho dữ liệu phiên.
• Mức độ nghiêm trọng: Được Google đánh giá ở mức S0, mức cao nhất trên thang đo độ nghiêm trọng của họ.
• Tiền thưởng: 90.000 USD đã được chi trả cho nhà nghiên cứu Simon Köck.
• Thời gian khắc phục: Báo cáo vào ngày 6 tháng 8 năm 2026; bản vá được triển khai vào ngày 7 tháng 10 năm 2026.

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

Đối với các đội ngũ kỹ thuật, sự cố này nhấn mạnh những nguy hiểm của việc tái sử dụng khóa mật mã và phụ thuộc vào các thư viện cũ. Sử dụng một bí mật cho nhiều mục đích, chẳng hạn như xác thực và ký phiên, tạo ra một điểm thất bại đơn lẻ (single point of failure). Nếu một cách sử dụng làm lộ bí mật, tất cả các biện pháp bảo vệ khác dựa trên bí mật đó sẽ sụp đổ. Ngoài ra, việc tiếp tục sử dụng các thư viện cũ như oauth2client thay vì các lựa chọn hiện đại như google-auth có thể đưa các mẫu thiết kế lỗi thời (anti-patterns) và lỗ hổng đã biết vào cơ sở hạ tầng mới.

Khoảng trống hai tháng giữa việc phê duyệt tiền thưởng và triển khai bản vá cũng đặt ra lo ngại về vận hành. Mặc dù Google không giải thích lý do chậm trễ, những khoảng thời gian như vậy khiến hệ thống vẫn bị phơi nhiễm trước khả năng khai thác sau khi nhà cung cấp đã biết về lỗ hổng. Các nhà nghiên cứu bảo mật thường lo lắng về việc liệu các biện pháp giảm thiểu tạm thời có được áp dụng hay không, đặc biệt khi phạm vi ảnh hưởng đầy đủ chưa rõ ràng. Trong trường hợp này, vẫn chưa rõ liệu kẻ tấn công có thể truy cập vào hệ thống giao tiếp dịch vụ-với-dịch vụ Stubby nội bộ của Google hoặc sửa đổi nội dung tài liệu cho các cuộc tấn công chuỗi cung ứng hay không.

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

• Kiểm toán các ứng dụng của bạn để tìm mọi trường hợp tái sử dụng bí mật giữa các chức năng mật mã khác nhau, chẳng hạn như ký và mã hóa.
• Thay thế mô-đun pickle của Python 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 có nguồn gốc từ người dùng.
• Di chuyển khỏi các thư viện cũ, chẳng hạn như oauth2client, sang các lựa chọn thay thế được hỗ trợ như google-auth.
• Đảm bảo rằng các khóa ký phiên khác biệt so với bí mật khách hàng OAuth và các thông tin đăng nhập xác thực khác.
• Triển khai quét tự động để tìm các mẫu giải mã không an toàn trong mã nguồn của bạn.
• Thiết lập các mục tiêu dịch vụ rõ ràng (SLO) cho thời gian khắc phục lỗ hổng nhằm giảm thiểu các cửa sổ phơi nhiễm.