1 điểm bởi GN⁺ 2025-02-13 | 1 bình luận | Chia sẻ qua WhatsApp
  • Trong quá trình xem xét tài liệu nội bộ của People API của Google, tác giả phát hiện rằng khi chặn người dùng, hệ thống sử dụng 'ID hồ sơ', còn được gọi là 'Gaia ID đã bị làm rối', cùng với 'tên thay thế'
  • Xác nhận rằng khi chặn người dùng khác trên YouTube, Gaia ID của người đó có thể bị hiển thị trên https://myaccount.google.com/blocklist và từ đó bị lộ
  • Các Gaia ID này là định danh tài khoản Google, làm dấy lên khả năng có thể dùng chúng để tìm ra địa chỉ email của người dùng

Có thể mở rộng sang toàn bộ kênh YouTube

  • Không chỉ có thể kiểm tra Gaia ID của người dùng trong live chat, tác giả còn điều tra liệu có thể lấy thông tin này với mọi kênh YouTube hay không
  • Tác giả phát hiện rằng khi nhấp vào menu 'Xem thêm' của một kênh trên YouTube, sẽ phát sinh một yêu cầu cụ thể, và yêu cầu này chứa Gaia ID của kênh
  • Xác nhận rằng có thể lấy Gaia ID của kênh thông qua các yêu cầu này

Lấy địa chỉ email thông qua Pixel Recorder

  • Tác giả thử nghiệm liệu có thể chuyển đổi Gaia ID thành địa chỉ email thông qua một sản phẩm Google tên là Pixel Recorder hay không
  • Khi chia sẻ bản ghi âm, nếu nhập Gaia ID của người nhận thì hệ thống sẽ trả về địa chỉ email tương ứng
  • Từ đó xác nhận rằng có thể chuyển đổi Gaia ID thành địa chỉ email

Lấy địa chỉ email mà không thông báo cho nạn nhân

  • Có một vấn đề là khi chia sẻ bản ghi âm, email thông báo sẽ được gửi tới đối tượng
  • Tác giả phát hiện ra cách vượt qua bằng cách đặt tiêu đề bản ghi âm thật dài để email thông báo không được gửi đi

Toàn bộ chuỗi tấn công

  1. Lấy Gaia ID của kênh thông qua endpoint /get_item_context_menu của YouTube
  2. Dùng Pixel Recorder để chia sẻ một bản ghi âm có tiêu đề rất dài với mục tiêu, từ đó chuyển Gaia ID thành địa chỉ email
  3. Xóa mục tiêu khỏi danh sách chia sẻ để xóa dấu vết

Báo cáo và tiền thưởng

  • 2024-09-15: Báo cáo lỗ hổng cho Google
  • 2024-09-16: Google tiếp nhận báo cáo và phản hồi 'Nice catch!'
  • 2024-11-05: Hội đồng bảo mật của Google quyết định trao khoản thưởng $3,133
  • 2024-12-12: Nhận thêm $7,500, nâng tổng tiền thưởng lên $10,633
  • 2025-02-12: Lỗ hổng được công khai

1 bình luận

 
GN⁺ 2025-02-13
Ý kiến Hacker News
  • Tôi thấy tiêu đề này khá dễ gây hiểu nhầm. Dành cho những ai chưa đọc đến cuối bài: email bị lộ không khiến họ tốn chi phí nào, và họ đã nhận được khoản thưởng bug bounty 10.000 USD

  • Cứ khoảng mỗi tin nhắn thứ 3 trong chuỗi này lại có nội dung rằng Google trả quá ít cho lỗi này. Một vài điểm cơ bản về việc định giá lỗ hổng:

    • Lỗ hổng phía máy chủ được định giá thấp. Vì các nhà cung cấp không cạnh tranh với nhau
    • Các lỗi full-chain như Android/Chrome được giao dịch với giá hàng trăm nghìn USD. Vì Google phải cạnh tranh với một thị trường xám đã được thiết lập vững chắc
    • So sánh bug bounty với thị trường xám là khập khiễng. Google trả ít hơn rất nhiều so với thị trường xám vì họ không cần exploit đáng tin cậy
    • Các tác nhân đe dọa mua lỗ hổng phù hợp với quy trình kinh doanh hiện có của họ. Họ không suy đoán xem có thể làm gì với một lỗ hổng mới
  • Việc chi trả bounty nhìn chung không phải là đánh giá về mức độ sáng tạo hay thú vị của lỗi. Nhưng trong trường hợp này, 10.000 USD cho một lỗi web phía máy chủ có cảm giác là khá cao

  • Chiến lược kinh doanh của những người tìm loại lỗi này là tìm thật nhiều lỗi. Không giống như phát triển exploit iOS, nơi người ta đầu tư hàng tháng trời vào một exploit duy nhất

  • Việc này khá giống với nghiên cứu lỗ hổng mà tôi từng làm trong công việc gần đây. Nhưng nếu có ai làm việc này một cách chuyên nghiệp, tôi rất muốn nghe ý kiến của họ

  • Có rất nhiều câu chuyện về responsible disclosure, động cơ của nó và phần thưởng của nó. Nhưng không có mấy câu chuyện như một dữ liệu phản chứng cho danh tính vĩnh viễn tập trung

  • Mỗi khi tôi thấy một dịch vụ tự nhận là chỉ hoạt động với một liên kết duy nhất tới Real Identity™, tôi lại được nhắc rằng các nhà cung cấp thực ra không hề quan tâm đến việc bảo vệ người dùng

  • Hãy tưởng tượng bạn chỉ còn cách thêm vài bước nữa là có thể lập tức bóc danh tính một người đang tương tác trên YouTube. Đó mới là tác động thực sự của lỗi này

  • Thật tốt khi lỗi này đã được vá, nhưng tôi không nghĩ loại lỗi này sẽ sớm biến mất. Cần phải làm gì để khiến các nhà cung cấp và các công ty lớn nhận ra rằng kiểu thiết kế này là nguy hiểm?

  • Một phát hiện tuyệt vời! Tìm được lỗ hổng trong một dịch vụ nổi tiếng như thế này sẽ rất đẹp trong hồ sơ. Chúc mừng

  • "Áp dụng giảm 1 bậc so với mức cơ bản vì độ phức tạp cần thiết trong chuỗi tấn công" - điều này có phổ biến không?

  • Tôi chỉ từng tham gia một vài chương trình lỗ hổng, nhưng đa số đều trả ít hơn khi lỗi bảo mật quá đơn giản

  • Một người bình luận đã giải thích về việc số tiền bounty liên hệ thế nào với giá trị chợ đen. Giờ thì nhiều người có thể sẽ nghĩ rằng Google không coi trọng bảo mật đủ mức

  • Vì mục đích bảo mật, nên trả ít nhất có thể. Trả nhiều hơn sẽ làm tăng động lực tìm lỗi, và có thể cả thị trường chợ đen cũng tăng theo

  • Chiến lược GTO là chặn thị trường chợ đen với số tiền ít nhất có thể

  • Tôi đang tìm mục tiêu nghiên cứu trên Google và đang xem tài liệu khám phá Internal People API (Staging). Liệu thứ này có nên được công khai không?

  • Tôi ước gì có cách gửi email cho chủ sở hữu kênh YouTube. Đa số không có thông tin liên hệ qua email, và rất khó để liên hệ cho tài trợ hoặc các giao dịch khác

  • Tôi tự hỏi liệu Google có công bố lỗ hổng bảo mật nếu không được vá trong vòng 90 ngày hay không. Trong trường hợp này, phải mất 147 ngày mới được vá

  • Việc ngăn hệ thống email bị gửi đi là một vấn đề bổ sung. Một công ty lớn như Google đã phát triển rất nhiều sản phẩm, nhưng "bảo mật" vẫn mang cảm giác giả tạo. Từng dòng code đều có thể trở thành một lỗ hổng tiềm tàng