Đăng nhập Google OAuth không thể được bảo vệ nếu ai đó mua lại tên miền của startup đã thất bại

• Một lỗ hổng bảo mật trong Google OAuth tạo ra điểm yếu nghiêm trọng trong quy trình xác thực "Sign in with Google"
  • Sau khi mua lại tên miền của một startup đã thất bại, kẻ tấn công có thể tái tạo các tài khoản email của tên miền đó để đăng nhập vào các dịch vụ SaaS
  • Có thể truy cập các dịch vụ chứa dữ liệu nhạy cảm:
    • Slack, ChatGPT, Notion, Zoom, hệ thống HR (bao gồm số an sinh xã hội)
  • Ban đầu Google từ chối sửa lỗi và cho rằng đây là "hành vi như thiết kế"
• Nguyên nhân gốc rễ của vấn đề: Google OAuth không thể phát hiện việc thay đổi quyền sở hữu tên miền
  • Khi tên miền đổi chủ, chủ sở hữu mới có thể đăng nhập vào tài khoản của nhân viên cũ với cùng các thông tin nhận dạng (claims)
• Các thông tin nhận dạng mặc định được sử dụng:
  • hd (miền được lưu trữ): chứa thông tin tên miền (ví dụ: example.com)
  • email: chứa địa chỉ email của người dùng (ví dụ: [e-mail])
• Nếu nhà cung cấp dịch vụ phụ thuộc vào hai thông tin này, việc đổi chủ tên miền sẽ vẫn cho phép truy cập cùng một tài khoản
• Quy mô của vấn đề
  • 6 triệu người Mỹ đang làm việc tại các startup
  • 90% startup thất bại
  • 50% startup thất bại sử dụng Google Workspaces
• Khoảng 100.000 tên miền của startup đã thất bại hiện có thể được mua lại
• Trung bình mỗi tên miền có 10 nhân viên và dùng 10 dịch vụ SaaS → có khả năng hơn 10 triệu tài khoản chứa dữ liệu nhạy cảm

Giải pháp được đề xuất và phản ứng của Google

• Các giải pháp đã được đề xuất với Google:
  1. ID người dùng duy nhất: thêm mã định danh người dùng duy nhất không thay đổi theo thời gian
  2. ID Workspace duy nhất: thêm mã định danh Workspace duy nhất gắn với tên miền
• Phản ứng ban đầu của Google:
  • Báo cáo vào tháng 9/2024 → bị đóng với lý do "không thể sửa"
  • Sau bài trình bày tại hội nghị Shmoocon tháng 12/2024, Google xem xét lại vấn đề
  • Trả thưởng bug bounty $1,337 và bắt đầu triển khai sửa lỗi
• Hiện tại, nếu Google không sửa thì không thể giải quyết tận gốc vấn đề này
• Một số dịch vụ còn trả về danh sách toàn bộ người dùng nếu tên miền khớp, khiến lỗ hổng càng nghiêm trọng hơn
• Ngay cả khi dùng mật khẩu thay vì đăng nhập bằng Google, tài khoản vẫn có thể bị đặt lại mật khẩu
  • Các startup thường bắt buộc dùng SSO và 2FA thay cho xác thực bằng mật khẩu
  • Nhà cung cấp dịch vụ cần yêu cầu xác thực bổ sung khi đặt lại mật khẩu (mã SMS, xác minh thẻ tín dụng)

Kết luận: vấn đề mang tính nền tảng trong bảo mật Google OAuth

• Lỗi trong cách triển khai OAuth của Google có thể dẫn đến chiếm đoạt tài khoản khi quyền sở hữu tên miền thay đổi
• Google đã bắt đầu sửa lỗi, nhưng giải pháp căn bản vẫn chưa hoàn tất
• Ở thời điểm hiện tại, dữ liệu và tài khoản của hàng triệu người Mỹ vẫn đang bị đặt vào tình trạng rủi ro

[sixmen]

Tôi nghĩ đây là lỗi từ phía người dùng: họ đã dùng email gắn với tên miền làm phương thức xác thực, rồi từ bỏ tên miền đó nhưng không vô hiệu hóa đúng cách các SaaS liên quan; vậy chuyện này cũng nên được xem là một lỗ hổng bảo mật sao?

[kargnas]

Trong dịch vụ tôi đang xây dựng, tôi đã chặn trước vấn đề này, nhưng dù vậy tôi vẫn đồng cảm với ý kiến này.
Nếu đây là vấn đề thì phải xem cả việc đăng nhập và đăng ký thông qua email thông thường cũng đều là vấn đề. Tất cả đều dùng email làm ID duy nhất, và việc xác minh để tìm lại mật khẩu cũng đều kiểm tra quyền sở hữu qua email.

Một cách cực đoan, giả sử các tên miền nổi tiếng như gmail.com hay hotmail.com bị tấn công và quyền cấu hình DNS của tên miền rơi vào tay hacker, thì đương nhiên việc tài khoản trên mọi dịch vụ SaaS trên toàn thế giới bị đặt vào rủi ro là điều hết sức hiển nhiên.

[GN⁺]

Ý kiến Hacker News

• Tình huống DankStartup đóng cửa và tên miền bị người khác mua lại để truy cập vào các tài khoản hiện có dường như là vấn đề trách nhiệm của DankStartup, Microsoft và OpenAI

  • Mô tả đây là lỗ hổng của OAuth là không phù hợp

• Trong triển khai OpenID của Google, cách đúng là xác thực bằng claim sub

  • Cần có luồng xử lý cho trường hợp claim sub thay đổi
  • 'ID người dùng duy nhất không thay đổi' được đề xuất thực chất không khác gì claim sub

• Đây là vấn đề mang tính nền tảng của cách tiếp cận phụ thuộc vào DNS: sau khi tên miền hết hạn, chủ sở hữu mới có thể có quyền hạn của chủ cũ

  • Đây là vấn đề có thể xảy ra trong các hệ thống xác thực phụ thuộc vào địa chỉ email hoặc DNS

• Google OAuth không có lỗ hổng; nếu mua lại tên miền thì bạn sẽ sở hữu mọi địa chỉ email thuộc tên miền đó

  • Kể cả không dùng Google OAuth thì kết quả tương tự vẫn có thể xảy ra

• Chia sẻ trải nghiệm trước đây với trường hợp thehunt.com, nơi sau khi mua lại tên miền có thể truy cập mọi dịch vụ

  • Đề xuất ý tưởng startup giám sát trạng thái tên miền để ngăn ngừa các mối đe dọa bảo mật

• Đây là vấn đề của các dịch vụ không dùng trường sub; nên dùng trường sub để định danh người dùng

  • Có thể kiếm tiền bằng cách gửi báo cáo lỗ hổng cho các dịch vụ không sử dụng trường sub

• Đề xuất Google triển khai hai định danh bất biến trong OpenID Connect

  • Claim sub và một ID Workspace duy nhất gắn với tên miền

• Trường hợp claim sub thay đổi trong Google OAuth là hiếm; có thể là vấn đề trong cách dịch vụ triển khai

• Chia sẻ trường hợp truy cập email sau khi mua lại tên miền

  • Vấn đề đã được giải quyết thông qua kết nối nội bộ với Google

• Tuyên bố "hàng triệu tài khoản" dựa trên giả định rằng các startup thất bại không vô hiệu hóa các tài khoản SaaS của họ