Hack Google bằng AI để kiếm 700 triệu won

• Một nghiên cứu bảo mật đã để AI tự động liên tục chọc thử các API của Google, qua đó thu về 500.000 USD tiền thưởng bug bounty chỉ trong 3 tháng
• Kết hợp API key thu thập từ hơn 60.000 ứng dụng Android với API specification (discovery document) của Google, họ thu thập được hơn 1.500 API để đưa vào diện kiểm thử, bao gồm cả những API ít được biết đến bên ngoài
• Kết nối công cụ kiểm thử API với AI dựa trên Claude để nó gửi request như con người và tự động tìm ra các lỗ hổng kiểm soát truy cập thiếu bước kiểm tra quyền
• Phát hiện nhiều lỗ hổng nghiêm trọng như chiếm đoạt tài khoản Google Voice, rò rỉ video riêng tư trên YouTube, lộ khóa Widevine DRM, truy vết danh tính chủ sở hữu thiết bị Nest
• Phần lớn không bắt nguồn từ kỹ thuật tấn công tinh vi mà từ những lỗi cơ bản lặp đi lặp lại như thiếu kiểm tra quyền, API không cần xác thực, môi trường test để lộ nguyên dữ liệu thật

---

Điểm khởi đầu của nghiên cứu

• Tháng 10/2025, nhân dịp được mời tham dự bugSWAT Mexico, tác giả quay lại tập trung nghiên cứu Google; việc có thể xem được một phần mã nguồn của Google là điểm đặc biệt khơi gợi hứng thú
• Trong 1 năm trước đó, khi làm các dự án nhỏ với Claude, tác giả nhận thấy có nhiều tiềm năng để dùng AI kiểm thử tự động API của Google ở quy mô lớn
• Điểm vào cốt lõi là discovery document — tài liệu kiểu Swagger của Google, mô tả toàn bộ endpoint, parameter và method theo cách máy có thể đọc được
  • Có những cái công khai như YouTube Data API, nhưng cũng tồn tại với các API nội bộ như Internal People API
  • Một số có thể truy cập trực tiếp, nhưng đa số cần API key hợp lệ

Thu thập API key

• Nhiều trường hợp một key tìm được ở một service lại được bật cho nhiều API khác trong cùng project GCP, nên càng gom được nhiều key thì phạm vi API có thể truy cập càng rộng
• Tác giả hợp tác với người bạn Michael để thu thập key
  • Tải xuống và giải nén 61.200 Android APK gồm mọi phiên bản của mọi ứng dụng Google, rồi tìm kiếm API key trong đó
  • Dùng extension dựa trên Chrome Debugger API để chặn traffic, truy cập hơn 2.800 Google web domain đã biết và thu thập key từ request theo thời gian thực
  • Đồng thời giải mã các ứng dụng Google trên iOS (IPA) và phân tích các binary Google có thể thu thập được

• Chỉ giữ lại key của Google

  • Để tuân thủ phạm vi VRP, dùng Cloud Marketplace API để truy vấn thông tin project gắn với key và loại bỏ key không thuộc Google
  • Khi dùng key với API không có quyền, lỗi trả về sẽ làm lộ số project (ví dụ: "...in project 244648151629...")
  • Truy vấn số này sẽ cho biết domain chủ sở hữu project qua trường company, nhờ đó loại bỏ mọi key không thuộc google.com (cũng như các công ty được mua lại như nest.com, fitbit.com, wing.com)

Tìm các domain API Google còn hoạt động

• Kết hợp domain do extension ghi lại, brute-force dựa trên từ khóa và certificate transparency log để thu được danh sách domain ứng viên
• Gửi request tới từng domain; nếu header Server là một trong ESF, GSE, scaffolding on HTTPServer2 thì coi đó là Google API hợp lệ đang hoạt động

Cào cả các spec bị ẩn

• Tháng 7/2025, Google đã gỡ đường dẫn /$discovery/rest khỏi phần lớn API, nhưng một số trường hợp vẫn có thể lách qua

• Endpoint bị ẩn bằng Visibility Label

  • Một số project bật visibility label, nên chỉ khi truyền parameter labels mới truy cập được các endpoint ẩn
  • Nếu lấy spec của Service Management API không có label thì chỉ 253KB, nhưng thêm ?labels=GOOGLE_INTERNAL thì tăng lên 329KB, làm lộ ra lượng lớn tài liệu ẩn
  • Mỗi lần chỉ nhận được một label, nên phải thử lượng request khổng lồ với mọi tổ hợp label, mọi key và mọi API
• Bằng cách đó, họ thu thập được spec của hơn 1.500 API, rồi kết hợp với tài liệu tích lũy từ nghiên cứu trước để chuẩn bị cho kiểm thử tự động bằng AI

Giải quyết vấn đề xác thực

• API key giải quyết được phần “quyền truy cập”, nhưng nhiều endpoint còn yêu cầu riêng phần xác thực (authentication) để biết người gọi là ai
• Bearer token bị ràng buộc với project GCP, nên nếu trộn với API key sẽ phát sinh lỗi “khác project”, và không có cách bypass đã biết

• First Party Authentication (FPA)

  • Nhiều API hỗ trợ cơ chế xác thực riêng của Google là FPA, và nó hoạt động cùng với API key
  • Request web sẽ mang Cookie của session và giá trị Authorization được tính từ đó, rồi gửi tới host *.clients6.google.com
  • Một số API như drivefrontend-pa còn yêu cầu header FPA v2 đầy đủ hơn, đưa cả định danh người dùng như email vào hàm băm
  • Michael phát hiện một sourcemap mà Google đã vô tình làm lộ trong một thời gian, từ đó lấy được mã tạo header FPA v2 trong thư viện nội bộ gapix

• Cấu trúc token và Gaia ID

  • Token có dạng <timestamp>_<hash>_<identifier_key>, với đầu vào SHA1 là "email:gaiaId timestamp sessionCookie origin"
  • identifier_key chỉ có ba loại là e (email), u (Gaia ID đã làm rối), a (domain Workspace); các ký tự khác bị backend bỏ qua
  • Gaia là viết tắt của Google Accounts and ID Administration; mọi tài khoản đều có Gaia ID tuần tự chưa làm rối (ví dụ: 131337133377) và một ID dài đã làm rối

• Whitelist origin và hạn chế của key

  • Nhiều API có danh sách Origin được phép; nếu dùng origin không nằm trong danh sách thì sẽ trả về lỗi SESSION_COOKIE_INVALID, dễ bị hiểu nhầm là lỗi cookie
  • Key có bốn loại hạn chế là Server, Browser, Android, iOS; Browser cần Referer, iOS cần X-Ios-Bundle-Identifier, Android cần X-Android-Package khớp với dấu vân tay chứng chỉ
  • Khi thu thập key, các giá trị này cũng được lưu lại để tích hợp vào cùng chương trình brute-force
  • Các origin *.corp.google.com không bị giới hạn, nên những API như vậy nhiều khả năng là API nội bộ không định công khai và thường nhiều bug — có một trường hợp đem lại 9.000 USD nhờ lỗ hổng kiểm soát truy cập

Lập bản đồ luồng request và tự xây công cụ test

• Tác giả viết chương trình để phân loại request bị chặn ở bước nào (diễn giải method → kiểm tra key hợp lệ → hạn chế key → xác thực → kiểm tra origin → label...), từ đó có được bảng đối chiếu key nào dùng được với API nào
• API Explorer của Google chỉ hỗ trợ API công khai và không mở cho trường hợp này, nên tác giả tự xây một API Explorer riêng hỗ trợ cả FPA v2 trong khoảng một tuần
  • Parse spec ở phía client để tự động dựng JSON request/response hợp lệ và cung cấp UI để thử nhanh payload tùy ý
  • Endpoint dùng trong demo là lỗi kiểm soát truy cập làm lộ assignedTams (quản lý tài khoản kỹ thuật), được thưởng 6.000 USD

Cấu hình kiểm thử tự động bằng AI

• Mục tiêu là để AI tự động phát hiện các vấn đề kiểm soát truy cập cơ bản, sau đó con người mở rộng thành các lỗ hổng nghiêm trọng hơn
• Mã parse JSON ở frontend được nối với AI qua công cụ MCP để AI có thể test API như con người

• Kỹ hơn, im lặng hơn

  • Ban đầu AI chỉ chọc thử vài lần rồi kết thúc sớm, nên tác giả thêm Ralph Wiggum loop để buộc nó phải test ít nhất một lần mọi endpoint mới được dừng
  • Trước tiên phân loại endpoint thành các nhóm logic, test theo từng nhóm và chia sẻ phát hiện của nhóm trước cho nhóm sau
  • Đơn giản hóa input của probe_api xoay quanh endpoint, path, body, còn phần xác thực FPA phức tạp được backend xử lý để AI chỉ tập trung viết payload
  • Vì mỗi key có thể cho phản hồi khác nhau, hệ thống tự động gửi cùng một request bằng mọi key rồi gom các phản hồi giống nhau bằng hàm băm
  • Các lỗi khó hiểu như Method not found được dịch thành MISSING_REQUIRED_VISIBILITY_LABEL để tránh làm AI bối rối

• Xử lý nhiễu và bài toán xác minh

  • Lúc đầu bug thật bị chìm giữa 90% nhiễu, nên hai vấn đề lớn nhất là khó xác minh và quá nhiều false positive
  • Báo cáo được gắn operation ID trỏ tới request thực tế, để frontend có thể tái hiện bằng nút “Play” và tạo bằng chứng không thể thao túng
  • Tác giả mất hơn một tháng tinh chỉnh system prompt để làm rõ tiêu chí báo cáo — chỉ nhận những trường hợp truy cập được dữ liệu của người dùng khác hoặc nhận 2xx ở nơi lẽ ra phải là 4xx; liệt kê sự tồn tại (existence enumeration) đơn thuần bị loại khỏi nhóm lỗ hổng
  • Sau đó AI đạt độ chính xác trên 50% trong việc phát hiện hàng loạt bug; giới hạn duy nhất còn lại là số lượng API key đang có

Các lỗ hổng chính được phát hiện

• Trong chưa đầy 3 tháng, hệ thống phát hiện lượng bug trị giá khoảng 500.000 USD; dưới đây là các trường hợp tiêu biểu đã được vá

• Chiếm đoạt tài khoản Google Voice

  • gfibervoice-pa hoàn toàn không có kiểm soát truy cập; chỉ với một dòng curl không cần xác thực, ai biết unobfuscated Gaia ID của nạn nhân đều có thể dump toàn bộ PII như số điện thoại, địa chỉ nhận thông báo
  • Trong response còn có thể thấy số điện thoại khôi phục tài khoản Google của nạn nhân (chỉ lộ trong một số điều kiện nhất định, chi tiết Google không công khai)
  • Còn có endpoint cho phép ép gán số Voice vào tài khoản bất kỳ (dù trả lỗi 500 thì số vẫn được thêm thật), và cả endpoint có khả năng dẫn tới SIM swap
  • Được phân loại P0/S0, vá trong vài giờ và thưởng 20.000 USD
  • Ngay sau khi vá, tác giả còn phát hiện lộ zhandler chỉ dành cho intranet như /btz; nếu vào được /flagz thì có thể trích xuất API key từ service đang chạy

• Chiếm đoạt tài khoản AdExchange

  • Phát hiện endpoint có thể dump toàn bộ danh sách tài khoản AdExchange chỉ bằng một request
  • Một endpoint tài khoản bị chặn ở production lại hoạt động không kiểm soát truy cập trên môi trường staging, trong khi staging này trỏ vào dữ liệu production thật
  • Thậm chí có thể tự thêm mình làm ADMIN vào tài khoản bất kỳ; tổng hai báo cáo được thưởng 30.000 USD

• eldar.corp.google.com

  • API của Eldar, một site nội bộ dành cho Googler để quản lý đánh giá quyền riêng tư, bị lộ ra bên ngoài, cho phép người không phải Googler xem thông tin nhạy cảm như yêu cầu truy cập log nội bộ
  • Sau khi bị chặn, tác giả còn thông báo thêm rằng vẫn có thể tới được qua địa chỉ sandbox khác; tổng thưởng 26.674 USD

• Rò rỉ video riêng tư trên YouTube

  • Tên asset được tạo khi upload video có dạng Auto generated asset - <video_id>, nên chỉ cần search là có thể lộ ID video riêng tư và xem được video
  • Nếu gửi request mỗi 30 giây, có thể lấy được feed thời gian thực của các video riêng tư do đối tác upload — đây là mối đe dọa thực tế có thể bị lạm dụng để đặt cược nội gián trên thị trường dự đoán khi doanh nghiệp tải trước video công bố sản phẩm ở chế độ riêng tư
  • Được thưởng 12.000 USD (chất lượng báo cáo xuất sắc)

• Lộ khóa Widevine DRM

  • API cổng đối tác của Widevine, hệ thống DRM quy mô lớn nhất thế giới được Disney, Netflix... sử dụng, lại cho truy cập công khai
  • Có thể dump toàn bộ danh sách tổ chức, xem và giải mã khóa PGP/AES của một tổ chức cụ thể, thậm chí tự thêm mình vào tổ chức bất kỳ để quản lý thiết bị
  • Được thưởng 16.004,40 USD (chất lượng báo cáo xuất sắc)

• plx.corp.google.com

  • API DataHub nền tảng của PLX, nền tảng phân tích nội bộ chỉ dành cho nhân viên, bị lộ ra ngoài và cho phép xem metadata bảng thông tin nhân sự đang hoạt động
  • Từ API staging, dùng setIamPolicy để tự thêm mình làm admin dataset, rồi dump dữ liệu YouTube mật, bao gồm cả bảng lên tới 2,1PB
  • Được công nhận P0/S0 trong vòng 1 giờ; hai lỗ hổng mỗi lỗ hổng thưởng 12.000 USD

Lỗ hổng cross-tenant trong Translation Hub

• Sản phẩm quản lý dịch tài liệu quy mô lớn Translation Hub có nhiều vấn đề kiểm soát truy cập
• ListOperations hoạt động mà không cần OAuth token, làm lộ tên service account nội bộ, tên bucket GCS và tên bảng nội bộ
• Chỉ với bearer token của bất kỳ tài khoản Google nào cũng có thể xem dữ liệu của project khác như email dịch giả, tên file mật của công việc
• Nếu dùng UpdateProjectConfig đổi cấu hình của nạn nhân sang một đường dẫn GCS tùy ý, có thể lạm dụng quyền của service account dùng chung để trích xuất object GCS riêng tư dưới dạng base64
• Tổng ba bug được thưởng 36.500 USD

YouTube TV CMS

• Trong API dành cho tài khoản YouTube CMS có thể strike, claim, monetize video tùy ý, endpoint campaign hoàn toàn không kiểm tra quan hệ với người gọi
• GET /v1/campaigns dump toàn cục mọi campaign trong hệ thống mà không hề scope, và chỉ cần biết ID là có thể sửa, sao chép hoặc xóa
• Hệ quả phụ là làm lộ email nhạy cảm của các tài khoản CMS; được thưởng 24.000 USD (chất lượng báo cáo xuất sắc)

Vertex AI Search for Commerce

• conversationalSearchCustomizationConfig của sản phẩm tìm kiếm/gợi ý bán lẻ cho phép đọc và sửa cấu hình của project bất kỳ mà không có kiểm soát truy cập
• Khi đọc, nó làm lộ system prompt (model preamble) của khách hàng cùng các ví dụ phân loại có ghi chú chính sách nội bộ
• Khi ghi, có thể tiêm payload prompt injection vào system prompt của AI tìm kiếm đối diện khách hàng; được thưởng 30.000 USD

GraphQL của Cloud Console

• Ngay cả các service nội bộ không công khai trên Internet cũng có thể bị chạm tới gián tiếp qua bề mặt proxy; Cloud Console (codename Pantheon) dùng GraphQL để proxy backend gRPC

• Bypass kiểm tra chữ ký

  • Mỗi request đều kiểm tra chữ ký truy vấn (querySignature) để chống sửa đổi, nhưng tác giả phát hiện query không cần xác thực trên môi trường staging không hề kiểm tra chữ ký
  • Dùng introspection để cào 3.448 schema và lưu trữ trên GitHub, rồi đưa khái niệm “query path” vào hạ tầng fuzzing AI sẵn có để tích hợp GraphQL

• Log request của App Engine

  • GetDashboardAppStats trả về log App Engine 24 giờ của project bất kỳ mà không kiểm tra IAM, thậm chí không cần xác thực
  • Vì URL request có thể chứa link reset mật khẩu, token..., lỗi này được thưởng 18.000 USD và gán CVE-2026-8934

• Vertex Assistant

  • Sau khi phân tích 5GB frontend JS, tác giả xác định được tính năng thử nghiệm ẩn Vertex Assistant và bật cờ tính năng cưỡng bức qua DevTools
  • Toàn bộ query liên quan đều hoạt động không cần xác thực, chỉ cần userId; chỉ biết email mục tiêu là có thể xem và sửa danh sách session cùng toàn bộ lịch sử hội thoại, được thưởng 30.000 USD

• Tín dụng thanh toán của Maps Platform

  • ListBillingAccountCredits hoạt động mà không kiểm tra quyền; với wildcard có thể lấy thông tin credit của nhiều khách hàng
  • PII của khách hàng do nhân viên Google nhập khi phê duyệt bị lộ nguyên vẹn trong trường justification; được thưởng 12.000 USD

Kết luận và bài học

• Trong 3 tháng, cấu hình này đem về hơn 500.000 USD bounty, và những gì được công bố mới chỉ là một phần
• Phần lớn bug của Google không đòi hỏi exploit tinh vi mà đòi hỏi sự kiên trì; cùng một kiểu sai hỏng lặp đi lặp lại khắp nơi — thiếu kiểm tra IAM, GraphQL không xác thực, endpoint debug trong production, sandbox trỏ vào dữ liệu thật
• Vai trò của AI không nằm ở sự mới lạ mà ở việc không biết mệt khi lặp đi lặp lại việc kiểm chứng những điều hiển nhiên trên một bề mặt quá rộng để con người tự làm tới cùng
• Những điểm rút ra chính
  • Hệ thống tái hiện bằng operation_id là yếu tố quyết định giúp workflow hiệu quả — nếu không có xác nhận một cú nhấp, đầu ra của AI chỉ là nhiễu vô dụng
  • Khi có được discovery doc, GraphQL SDL và proto, AI có thể hiểu được đầu vào cần thiết để kiểm thử một cách có ý nghĩa
  • Bề mặt server-side của Google được chuẩn hóa rất cao, nên nếu trừu tượng hóa các đặc thù hạ tầng khỏi AI thì có thể tập trung hơn vào việc test API thật

[j2sus91]

Đúng là một kiểu kiếm tiền hoàn toàn mới của vibe coding.