▲

GN⁺: Google OAuth 로그인은 실패한 스타트업 도메인을 사버리는 경우 보호 불가능

 (trufflesecurity.com)
6P by neo 1달전 | ★ favorite | 댓글 3개
  • Google OAuth의 보안 결함으로 "Sign in with Google" 인증 과정에 심각한 취약점이 있음
    • 실패한 스타트업의 도메인을 구매한 후, 해당 도메인 이메일 계정을 재구성해 SaaS 서비스에 로그인 가능
    • 민감한 데이터가 포함된 서비스 접근 가능:
      • Slack, ChatGPT, Notion, Zoom, HR 시스템(사회보장번호 포함)
    • Google은 초기 보고 시 "의도된 동작"이라며 수정 거부
  • 문제의 근본 원인: Google OAuth는 도메인 소유권 변경을 감지하지 못함
    • 도메인 변경 시, 새 소유자가 이전 직원 계정에 동일한 자격(claims)으로 로그인 가능
  • 사용되는 기본 자격 정보:
    • hd (호스팅 도메인): 도메인 정보 포함 (예: example.com)
    • email: 사용자의 이메일 주소 포함 (예: user@example.com)
  • 서비스 제공자가 이 두 정보에 의존하면 도메인 소유권 변경 시 동일한 계정 접근 허용
  • 문제의 규모
    • 6백만 명의 미국인이 스타트업에서 근무 중
    • 90%의 스타트업이 실패
    • 실패한 스타트업의 50%가 Google Workspaces 사용
  • 약 100,000개의 실패한 스타트업 도메인이 구매 가능
  • 평균적으로 도메인당 10명의 직원과 10개의 SaaS 서비스 사용 → 1,000만 개 이상의 계정에 민감 데이터 포함 가능성

해결책 제안 및 Google의 대응

  • Google에 제안된 해결책:
    1. 사용자 고유 ID: 시간이 지나도 변경되지 않는 고유 사용자 식별자 추가
    2. 워크스페이스 고유 ID: 도메인과 연결된 고유 워크스페이스 식별자 추가
  • Google의 초기 대응:
    • 2024년 9월 보고 → "수정 불가"로 종료
    • 2024년 12월 Shmoocon 컨퍼런스 발표 후 Google이 다시 문제 재검토
    • $1,337의 버그바운티 지급 및 수정 작업 시작
  • 현재로서는 Google의 수정 없이는 근본적인 문제 해결 불가능
  • 일부 서비스는 도메인 일치 시 모든 사용자 목록 반환하므로 취약성이 더 악화됨
  • 구글 로그인 대신 비밀번호를 사용했다 해도 재설정 가능함
    • 스타트업은 비밀번호 인증 대신 SSO와 2FA 강제 적용
    • 서비스 제공자는 비밀번호 재설정 시 추가 인증 요구(SMS 코드, 신용카드 확인)

결론: Google OAuth 보안의 근본적 문제

  • Google의 OAuth 구현 결함으로 인해 도메인 소유권 변경 시 계정 탈취 가능
  • Google의 수정 작업이 시작되었으나, 아직 근본적 해결책은 미완료
  • 현재로서는 수백만 미국인의 데이터와 계정이 위험에 노출
▲
sixmen 1달전  [-]

저는 도메인이 포함된 이메일을 인증 수단으로 사용하다가 도메인을 포기하면서 관련된 SaaS를 제대로 폐기하지 않은 사용자측 잘못이라는 생각이 드는데, 이것도 보안 결함이라고 봐야 하는 걸까요.?

답변달기
▲
kargnas 1달전  [-]

제가 만드는 서비스에서는 이 이슈를 사전에 막아뒀지만, 그럼에도 불구하고 이 의견에 공감합니다.
이것이 문제라면 일반적인 이메일을 통한 로그인 및 가입도 다 문제라고 봐야합니다. 모두 다 이메일을 고유 아이디로 사용하고 있고 비밀번호 찾기 인증도 모두 이메일로 소유 확인을 하니까요.

극단적으로, gmail.com, hotmail.com 같은 유명한 도메인이 해킹당해서 도메인의 DNS 설정 권한이 해커에게 넘어갔다고 가정했을 때, 당연히 전세계의 모든 SaaS의 계정들이 위험해지는건 매우 당연합니다.

답변달기
▲
neo 1달전  [-]
Hacker News 의견

  • DankStartup가 사업을 접고 도메인을 다른 사람이 인수하여 기존 계정에 접근할 수 있는 상황은 DankStartup, Microsoft, OpenAI의 책임 문제로 보임

    • OAuth의 취약점으로 설명하는 것은 적절하지 않음

  • Google의 OpenID 구현에서 sub 클레임을 사용하여 인증하는 것이 올바른 방법임

    • sub 클레임이 변경될 경우를 대비한 흐름이 필요함
    • 제안된 '변경되지 않는 고유 사용자 ID'는 sub 클레임과 다르지 않음

  • DNS에 의존하는 방식의 근본적인 문제로, 도메인 만료 후 새로운 소유자가 이전 소유자의 권한을 가질 수 있음

    • 이메일 주소나 DNS에 의존하는 인증 시스템에서 발생할 수 있는 문제임

  • Google OAuth에 취약점이 없으며, 도메인을 인수하면 해당 도메인의 모든 이메일 주소를 소유하게 됨

    • Google OAuth를 사용하지 않더라도 동일한 결과가 발생할 수 있음

  • 과거 thehunt.com 사례에서 도메인 인수 후 모든 서비스에 접근 가능했던 경험 공유

    • 도메인 상태를 모니터링하여 보안 위협을 방지하는 스타트업 아이디어 제안

  • sub 필드를 사용하지 않는 서비스의 문제로, 사용자 식별에 sub 필드를 사용해야 함

    • sub 필드를 사용하지 않는 서비스에 취약점 보고서를 제출하여 수익을 창출할 수 있음

  • Google의 OpenID Connect에서 두 개의 불변 식별자를 구현하는 제안

    • sub 클레임과 도메인에 연결된 고유 워크스페이스 ID

  • Google OAuth에서 sub 클레임이 변경되는 경우는 드물며, 서비스 구현의 문제일 가능성이 있음

  • 도메인 인수 후 이메일 접근 사례 공유

    • Google과의 내부 연결을 통해 문제 해결

  • "수백만 개의 계정"이라는 주장은 실패한 스타트업이 SAAS 계정을 비활성화하지 않는다는 가정에 기반함

답변달기