Lỗ hổng thực thi mã từ xa trị giá 90.000 USD trong hệ thống tài liệu Google

Một chuyên gia bảo mật đã phát hiện lỗ hổng cho phép thực thi mã từ xa (RCE) trên nền tảng DevSite dùng chung của Google, ảnh hưởng đến nhiều tên miền như developers.google.com và firebase.google.com. Lỗ hổng xuất phát từ việc khóa ký session bị lộ ngay trong cookie, cho phép kẻ tấn công giả mạo cookie hợp lệ và lợi dụng hàm pickle.loads để chạy mã tùy ý. Google đã khắc phục và trao thưởng 90.000 USD.

Một nhà nghiên cứu bảo mật độc lập vừa công bố chi tiết về lỗ hổng thực thi mã từ xa (RCE) nghiêm trọng trên nền tảng tài liệu dành cho nhà phát triển của Google. Điều đáng chú ý là lỗ hổng này không nằm ở một ứng dụng đơn lẻ, mà ở DevSite — nền tảng dùng chung cho hàng loạt tên miền lớn của Google. Phần thưởng mà Google Bug Hunters chi trả lên tới 90.000 USD, mức cao hiếm thấy trong các chương trình săn lỗi.

Mọi chuyện bắt đầu khi nhà nghiên cứu rà soát luồng xác thực OAuth dùng chung trên các trang tài liệu của Google. Khi truy cập đường dẫn /oauth2authorize, máy chủ lập tức thiết lập một cookie session của Flask rồi chuyển hướng sang trang đăng nhập Google — không cần tài khoản.

Điểm bất thường nằm ở kích thước cookie: khoảng 1.200 byte, trong khi một cookie session thông thường chỉ cần vài trăm byte cho token CSRF và URL quay về. Khi giải mã, anh phát hiện một chi tiết chấn động:

Cookie chứa một đối tượng OAuth2WebServerFlow được tuần tự hóa bằng pickle
Trong đó có cả client_id và client_secret của Google nằm ở dạng văn bản thuần

Điều này đồng nghĩa bí mật xác thực OAuth của Google bị lộ ngay trong dữ liệu mà bất kỳ ai cũng đọc được.

Một bí mật, hai vai trò nguy hiểm

Tai họa thực sự đến từ việc Google dùng chính client_secret làm khóa ký session của Flask. Nhà nghiên cứu đã kiểm chứng điều này một cách bài bản thay vì chỉ phỏng đoán: anh tự tính lại chữ ký ngoại tuyến theo cơ chế dẫn xuất khóa cookie-session của thư viện itsdangerous, và kết quả khớp từng byte với chữ ký trên cookie thật.

"Khóa ký được lưu ngay bên trong chính đối tượng mà nó ký."

Nói cách khác, kẻ tấn công chỉ cần một GET request là có được chìa khóa để tự tạo cookie hợp lệ với bất kỳ nội dung nào.

Luồng xử lý callback của Google đọc lại đối tượng flow từ session và gọi pickle.loads() trên đó. Bản thân pickle vốn không an toàn: opcode REDUCE cho phép chỉ định một hàm bất kỳ kèm tham số, và quá trình giải nén sẽ gọi hàm đó ngay lập tức.

Kết hợp giữa khóa ký công khai và điểm gọi pickle.loads, nhà nghiên cứu có trong tay một lỗ hổng RCE không cần xác thực. Để chứng minh mà không gây hại, anh dùng payload time.sleep(N) và đo thời gian phản hồi:

time.sleep(0) → 0,207 giây
time.sleep(3) → 3,193 giây
time.sleep(5) → 5,194 giây
time.sleep(8) → 8,283 giây

Thời gian phản hồi tăng đúng theo con số trong cookie — bằng chứng không thể chối cãi rằng máy chủ Google đã thực sự gọi hàm với tham số do kẻ tấn công kiểm soát.

Phạm vi ảnh hưởng vượt xa một tên miền

Vì DevSite là nền tảng dùng chung, khóa lấy từ developers.google.com có thể ký session hợp lệ trên nhiều tên miền khác:

firebase.google.com
developer.android.com
source.android.com
docs.partner.android.com

Đây là minh chứng rõ ràng cho rủi ro khi các dịch vụ dùng chung hạ tầng nhưng không tách biệt bí mật.

Bốn lớp phòng thủ bị phá vỡ cùng lúc

Theo nhà nghiên cứu, lẽ ra chỉ cần một trong bốn biện pháp sau là đủ để chặn đứng chuỗi tấn công:

Xoay vòng cả hai client secret OAuth bị lộ và vô hiệu hóa mọi session đã ký bằng chúng
Cấp cho mỗi triển khai một SECRET_KEY Flask riêng, entropy cao, lưu ở phía máy chủ và không liên quan gì đến thông tin OAuth
Giữ đối tượng flow OAuth trên máy chủ, cookie chỉ chứa tham chiếu mờ, không chứa dữ liệu nhạy cảm
Loại bỏ pickle cho mọi dữ liệu đi qua ranh giới client, thay bằng định dạng dữ liệu thuần có kiểm tra lược đồ

Thật không may, cả bốn đều không được áp dụng, và chính sự trùng khớp đó tạo nên lỗ hổng.

Bài học cho nhà phát triển Việt Nam

Sự cố này là lời cảnh tỉnh cho các đội phát triển tại Việt Nam, đặc biệt những nhóm dùng Flask và lưu session phía client:

Tuyệt đối không dùng cùng một bí mật cho nhiều mục đích khác nhau
Không bao giờ để thông tin xác thực như client_secret lọt vào dữ liệu mà người dùng có thể đọc
Không dùng pickle để xử lý dữ liệu đến từ bên ngoài — đây là nguyên tắc bảo mật cơ bản nhưng thường bị bỏ qua
Với các hệ thống dùng chung hạ tầng, cần cách ly bí mật giữa các dịch vụ để một lỗi nhỏ không lan thành thảm họa diện rộng

Với các lập trình viên Việt Nam đang vận hành sản phẩm trên cloud, đây cũng là dịp rà soát lại cách mình quản lý SECRET_KEY và các thông tin xác thực bên thứ ba trong mã nguồn.

Dòng thời gian xử lý

Google đã phản hồi và khắc phục khá nhanh chóng:

6/8 — Báo cáo được gửi
7/8 — Phân loại, sau đó chấp nhận
27/8 — Quyết định mức thưởng: 90.000 USD (75.000 USD cơ bản × 1,2 nhờ chất lượng báo cáo xuất sắc)
7/10 — Hoàn tất khắc phục

Câu chuyện cho thấy các chương trình săn lỗi vẫn là kênh hiệu quả để phát hiện những sai sót nghiêm trọng mà kiểm thử nội bộ khó lòng bắt được.