Tấn công vét cạn số điện thoại người dùng Google

• Biểu mẫu khôi phục tên người dùng không dùng JS của Google cho phép kiểm tra tổ hợp số điện thoại và tên hiển thị, từ đó tạo ra một chuỗi tấn công có thể tìm ra toàn bộ số điện thoại của một người dùng Google cụ thể
• Điểm cốt lõi là sự khác biệt trong chuyển hướng giữa /signin/usernamerecovery và /signin/usernamerecovery/lookup, cho phép phân biệt trạng thái không có tài khoản và có tài khoản
• Dù có giới hạn yêu cầu theo IP và CAPTCHA, khi đưa token BotGuard từ biểu mẫu JS vào bgresponse của biểu mẫu không JS thì yêu cầu vẫn hoạt động không bị giới hạn, kết hợp thêm xoay vòng IPv6
• Kẻ tấn công có thể lấy tên hiển thị tài khoản Google qua Looker Studio, rồi kết hợp với số điện thoại bị che trong luồng quên mật khẩu và định dạng số theo từng quốc gia để thu hẹp mạnh tập ứng viên
• Trên máy chủ 16 vCPU giá $0.30/giờ có thể thực hiện khoảng 40.000 lần kiểm tra mỗi giây, và Google đã gỡ bỏ hoàn toàn biểu mẫu khôi phục tên người dùng không JS vào ngày 2025-06-06 và trả tổng cộng $5,000

---

Lỗ hổng bắt đầu từ biểu mẫu khôi phục tên người dùng không JS

• Khi kiểm tra hoạt động của các dịch vụ Google trong trình duyệt đã tắt JavaScript, người ta phát hiện biểu mẫu khôi phục tên người dùng vẫn hoạt động
• Từ trước, biểu mẫu khôi phục tài khoản được cho là cần JavaScript vì phụ thuộc vào cơ chế phòng vệ kiểu BotGuard do đoạn mã JavaScript proof-of-work bị làm rối tạo ra
• Tuy nhiên, biểu mẫu không JS vẫn cung cấp một luồng cho phép kiểm tra xem email khôi phục hoặc số điện thoại có được liên kết với một tên hiển thị cụ thể hay không

Xác nhận sự tồn tại của tài khoản bằng hai yêu cầu

• Yêu cầu đầu tiên gửi số điện thoại tới /signin/usernamerecovery, rồi lấy giá trị ess gắn với số đó từ Location trong phản hồi
  • Cookie và giá trị gxf được lấy từ HTML của trang ban đầu
• Sau đó gửi tới /signin/usernamerecovery/lookup với ess, tên, họ và bgresponse=js_disabled
• Chuyển hướng trong phản hồi thay đổi, nên có thể xác định liệu có tài khoản Google mang số điện thoại và tên hiển thị đó hay không
  • Không có tài khoản: usernamerecovery/noaccountsfound
  • Có tài khoản: usernamerecovery/challenge

Giới hạn IP, IPv6 và vượt BotGuard

• Ở các lần thử ban đầu, sau vài yêu cầu thì địa chỉ IP bị giới hạn yêu cầu và CAPTCHA xuất hiện
• Trong ví dụ số di động Hà Lan, luồng quên mật khẩu đưa ra gợi ý như •• ••••••03
  • Vì số di động Hà Lan bắt đầu bằng 06, cần thử 6 chữ số còn lại, tức 10^6 = 1,000,000 ứng viên
• Các nhà cung cấp như Vultr cấp dải IPv6 /64, về lý thuyết có thể dùng 18,446,744,073,709,551,616 địa chỉ
• Một PoC được tạo ra bằng cách dùng ClientBuilder.local_address của reqwest để đặt một địa chỉ IPv6 ngẫu nhiên trong subnet cho mỗi yêu cầu
• Khi dùng biểu mẫu tắt JS từ IP datacenter thì CAPTCHA vẫn xuất hiện liên tục, nhưng khi đưa token BotGuard từ biểu mẫu khôi phục tài khoản có JS vào bgresponse của biểu mẫu không JS, yêu cầu lại được chấp nhận
  • Có vẻ token BotGuard đó trên biểu mẫu không JS không bị áp dụng giới hạn yêu cầu

Lọc các kết quả dương tính giả

• Kết quả chạy ban đầu chứa nhiều tài khoản có tên là Henry, họ trống và số điện thoại kết thúc bằng 03
• Trong trường hợp này, nếu tên là Henry thì dù họ là gì, hệ thống vẫn trả về usernamerecovery/challenge
• Để xác minh các kết quả có thể trúng, người ta kiểm tra lại với cùng tên nhưng dùng một họ ngẫu nhiên như 0fasfk1AFko1wf
  • Nếu vẫn ra kết quả trúng thì lọc đó là dương tính giả
• Khả năng tồn tại một người dùng Google khác có cùng tên hiển thị đầy đủ, cùng mã quốc gia và cùng hai chữ số cuối là thấp

Thu thập mã quốc gia và tên hiển thị

• Mặt nạ số điện thoại trong luồng quên mật khẩu có thể được dùng để suy đoán mã quốc gia
• Google dùng libphonenumber cho định dạng quốc gia của từng số
• Bằng cách thu thập các định dạng quốc gia đã bị che theo từng nước, người ta tạo ra mask.json
  • Nga, Hà Lan, Anh và Mỹ có các mẫu mặt nạ khác nhau
• Google đã đổi chính sách vào năm 2023 để chỉ hiển thị tên khi có tương tác trực tiếp với đối tượng, và đến tháng 4/2024, Internal People API đã ngừng hoàn toàn việc trả về tên hiển thị cho tài khoản chưa xác thực
• Tuy nhiên, nếu tạo một tài liệu Looker Studio và chuyển quyền sở hữu cho nạn nhân, thì tên hiển thị của nạn nhân sẽ bị lộ trên màn hình chính mà không cần tương tác từ họ

Tối ưu phạm vi ứng viên và công cụ

• Dùng khả năng kiểm tra số của libphonenumber để tạo format.json chứa tiền tố di động theo quốc gia, mã vùng đã biết và số chữ số
  • Ví dụ Hà Lan gồm mã quốc gia 31, mã vùng 61, 62, 63, 64, 65, 68, và số chữ số [7]
• Kiểm tra libphonenumber theo thời gian thực giúp giảm truy vấn Google API cho các số không hợp lệ
• Để tạo token BotGuard, một script Go dùng chromedp đã được viết
  • Có thể lấy bgToken bằng cách gọi http://localhost:7912/api/generate_bgtoken
• Toàn bộ chuỗi tấn công gồm ba bước
  • Rò rỉ tên hiển thị tài khoản Google qua Looker Studio
  • Lấy số điện thoại bị che từ luồng quên mật khẩu
  • Đưa tên hiển thị và số điện thoại bị che vào gpb để vét cạn toàn bộ số điện thoại

Hiệu năng vét cạn và thời gian ước tính

• Trên máy chủ giá $0.30/giờ và cấu hình phổ thông 16 vCPU, có thể đạt khoảng 40.000 lần kiểm tra mỗi giây
• Thời gian dự kiến khi luồng quên mật khẩu chỉ cho biết hai chữ số cuối:
  • Mỹ +1: 20 phút
  • Anh +44: 4 phút
  • Hà Lan +31: 15 giây
  • Singapore +65: 5 giây
• Nếu luồng đặt lại mật khẩu của dịch vụ khác như PayPal cho nhiều gợi ý chữ số hơn thì thời gian có thể giảm mạnh
  • Ví dụ: +14•••••1779

Dòng thời gian báo cáo và xử lý của Google

• 2025-04-14: Gửi báo cáo cho nhà cung cấp
• 2025-04-15: Nhà cung cấp tiếp nhận và phân loại báo cáo
• 2025-04-25: Phản hồi “Nice catch!”
• 2025-05-15: Hội đồng xác định mức thưởng $1,337 + swag
  • Cơ sở là đánh giá khả năng bị khai thác thấp, và vấn đề được công nhận là phương pháp luận liên quan đến lạm dụng có tác động cao
• 2025-05-15: Khiếu nại về lý do mức thưởng
  • Theo bảng Abuse VRP, probability/exploitability được quyết định dựa trên điều kiện tiên quyết của cuộc tấn công và việc nạn nhân có thể phát hiện bị khai thác hay không
  • Báo cáo nêu rõ cuộc tấn công này không có điều kiện tiên quyết và nạn nhân không thể phát hiện việc bị khai thác
• 2025-05-22: Hội đồng trả thêm $3,663, nâng tổng mức thưởng lên $5,000
  • Mức likelihood được nâng lên medium
• 2025-05-22: Nhà cung cấp xác nhận đã triển khai biện pháp giảm thiểu trong khi chờ gỡ bỏ endpoint trên toàn cầu
• 2025-05-22: Điều phối lịch công bố vào 2025-06-09
• 2025-06-06: Nhà cung cấp xác nhận đã gỡ bỏ hoàn toàn biểu mẫu khôi phục tên người dùng không JS
• 2025-06-09: Báo cáo được công bố