# 구글 사용자 전화번호 무차별 대입 공격(Bruteforcing the phone number of any Google user)

> Clean Markdown view of GeekNews topic #21372. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=21372](https://news.hada.io/topic?id=21372)
- GeekNews Markdown: [https://news.hada.io/topic/21372.md](https://news.hada.io/topic/21372.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-06-10T10:10:40+09:00
- Updated: 2025-06-10T10:10:40+09:00
- Original source: [brutecat.com](https://brutecat.com/articles/leaking-google-phones)
- Points: 1
- Comments: 1

## Topic Body

- **구글 계정 찾기** 폼을 우회하여 특정 사용자 이름과 연결된 전화번호가 존재하는지 확인 가능함
- **자바스크립트 비활성화** 환경에서도 봇가드(BotGuard) 토큰을 의도적으로 삽입하여, IP 제한을 우회하는 공격 방식 구현 가능함
- 네덜란드 등 일부 국가에서는 전화번호 포맷 특성상 **1백만 개 미만** 조합이 존재하여 현실적으로 **프록시와 IPv6** 회전을 통해 대규모 대입 가능함
- **구글 계정의 디스플레이 네임**을 Looker Studio를 이용해 피해자 임의 동작 없이 손쉽게 노출 가능함
- 이 취약점은 **구글에 보고 및 패치** 완료되었으며, 실제 공격 체인은 자동화로 매우 빠른 시간 내에 전화번호를 확인 가능함

---

### 개요

이 글은 구글 계정의 전화번호를 무차별 대입(브루트포스) 공격으로 알아내는 방법, 그 과정, 그리고 방어 측의 대응까지 자세히 다루는 실제 사례임. 일반적으로 계정 찾기/복구 폼은 Javascript 환경과 봇 방지 체계를 이용하여 남용을 차단함. 그러나, JS가 꺼진 환경+특정 패턴으로는 이 체계를 우회할 수 있음을 증명하고 있음.

### 조사 배경 및 방식

- 계정 사용자명을 찾는 구글 폼이 **자바스크립트 없이 동작**하는 점을 발견함
- 폼은 특정 **이름(Display Name)과 연동된 전화번호**의 존재 여부를 HTTP 요청 2개로 확인함
  - 1차 요청 : 전화번호 기반으로 ess 값(세션 토큰) 획득
  - 2차 요청 : ess와 이름(GivenName/FamilyName) 파라미터로 계정 존재 여부 판별
- 계정이 존재하면 `usernamerecovery/challenge` 리다이렉트, 없으면 `noaccountsfound` 리다이렉트로 응답

### IP 제한 우회(프록시, IPv6 활용)

- 초기에는 **IP별 레이트 리밋과 캡챠**로 무차별 대입이 불가했음
- 네덜란드 모바일 번호의 경우 100만개 조합(앞자리가 정해져 있음)으로 프록시 사용 시 현실적이고, 
- AWS/Vultr 등 클라우드의 **/64 IPv6 블록**을 활용해 요청마다 다른 주소로 회전 가능, 서버도 IPv6 지원함

### BotGuard 토큰 우회

- JS 폼에서는 **봇가드(BotGuard) 토큰**이 필요함
- No-JS 폼에서 `bgresponse=js_disabled` 파라미터 대신 JS 폼에서 수집한 토큰을 삽입하면 **불제한 제출** 가능
- 멀티스레드 툴을 제작, 대량 전화번호를 입력해 신속하게 **존재 계정** 탐지 가능

### 오탐 거르기(필터링)

- 동일 이름/번호 뒤 2자리 조건으로 여러 명이 걸릴 가능성 있음
- 임의의 랜덤 성(last name)을 입력해 다시 테스트함으로써 **오탐 여부**를 자동으로 필터링하는 로직 추가

### 국가별 전화번호 포맷 및 네임 정보 수집

- 복구 폼은 **전화번호 마스킹 포맷**만을 일부 제공함
- 각국 전화번호 패턴(national format)은 구글의 libphonenumbers 정보 조사로 파악 가능
- 피해자의 **디스플레이 네임**은 Looker Studio에서 소유권 변경 기능을 악용해 사용자 동작 없이 확인 가능

### 최적화 및 자동화

- libphonenumbers로 각국 Prefix/길이/유효성 검증 규칙 딕셔너리 생성
- Go 기반 chromedp로 **BotGuard 토큰 자동 발급 API** 제작, 실제 공격시 자동화 가능

### 실제 공격 절차

1. Looker Studio 소유권 이전으로 피해자 **이름(디스플레이 네임) 획득**
2. “비밀번호 찾기” 흐름에서 해당 이메일의 **전화번호 일부 마스킹** 수집
3. **gpb 툴**을 통해 이름, 마스킹, 국가 코드 기반으로 대입 공격 실행

### 시간 및 효율성

- 16 vcpu, 3000 스레드 서버 기준, 1초에 약 4만건 체크
- 국가별 번호 조합/힌트 길이에 따라 미국(20분), 영국(4분), 네덜란드(15초), 싱가포르(5초)면 충분
- 타 서비스에서 풀힌트 제공시(예: PayPal) 시간 더욱 단축

### 구글 및 패치 타임라인

- 2025.4.14 : 구글에 리포트, 4.25 패널서 감사 표시
- 2025.5 중 : **$5,000 버그바운티** 지급
- 2025.5 : No-JS 폼 점진적 중단 및 대응 조치 적용
- 2025.6.9 : 공식 취약점 공개

### 결론

이 사례는 **계정 복구 흐름, 전화번호 마스킹, 디스플레이 네임 등 여러 정보의 조합**만으로 대규모 자동화 공격이 가능함을 보여줌. 구글은 절차 내 취약점 보완 및 관련 폼을 폐쇄함으로써 대응을 완료함. 

문의는 신호/이메일(원문 참고)로 가능함

## Comments



### Comment 39901

- Author: neo
- Created: 2025-06-10T10:10:40+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=44224684) 
- 이 글에서 흥미로운 점은, 대부분의 호스팅 제공업체나 ISP가 최소한 하나의 /64 IPv6 블록을 제공한다는 사실임에도 불구하고, 여전히 대부분의 레이트 리밋이나 IP 차단은 단일 IP에 대해 적용된다는 점임. IPv6 환경에서는 전체 /64 블록을 기준으로 레이트 리밋이나 차단이 이뤄져야 한다고 생각함

  - 이런 문제를 관리해야 할 책임이 있거나 그걸로 돈을 벌고 있는 기업들조차 IPv6 관리에 있어 엉뚱한 대응을 하는 모습을 자주 봄. 내가 일하는 회사는 유명 CDN 서비스를 쓰고 있는데, 같은 /64 블록 내에서 접속해도 '이상한 IP에서 접속함' 같은 터무니없는 보안 알림을 받는 경우가 있음

  - IPv6 등장 이후로 기존 IP 차단 방식이 크게 무력화됐다고 생각함. 일반 가정용 인터넷 사용자라도 DHCPv6 Prefix Delegation으로 /56이나 /48 블록을 자동으로 받을 수 있음. 예를 들어 나는 Comcast를 통해 /56을 받았고, 이는 최대 65536개의 /64 블록으로 쪼갤 수 있음. IPv6에서 효과적인 IP 필터링을 하려면 기존 단일 IP 기반을 /64로 단순 교체하는 걸로는 부족함

  - /64 블록으로 레이트 리밋을 걸어도 충분하지 않을 수 있음. /48 블록을 받는 것도 너무 쉬움. 최적의 제어를 위해선 ASN별로 분류하고, 각 사업자가 어떻게 IP를 분배하는지까지 살펴 granularity를 조정하는 고민이 필요함

  - IPv6에서 /64 단위 레이트 리밋은 이미 업계에서 잘 알려져 있고, Google도 타 서비스에 적용하고 있음. 이건 IPv6 도입 시 제대로 기존 정책을 업데이트하지 않은 결과라고 판단함

  - [BuyVM](https://my.frantech.ca/cart.php?gid=37) 같은 저가 호스팅 업체도 가장 저렴한 상품에 /48 단위 주소를 제공함($2/월, 현재는 $7/월만 재고 있음). 그래서 수상한 운영자들이 애용하는 경향이 있음

- 예전에 페이스북에서 특정인의 전화번호를 찾으려고 비슷한 방법을 시도함. 비밀번호 재설정 과정에서 페이스북이 전화번호 대부분을 보여주길래, 그 숫자를 vcard 파일로 정리해서 내 폰에 불러온 뒤 사진으로 대조함. 이 방식이 예상 외로 효과적이었음

  - 구글 프로필 사진이나 구글 앱에도 비슷한 허점이 있음. 예를 들어 구글 지도 리뷰에 John Smith라고 뜨면, 여러 이메일 변형(johnsmith@gmail.com, smithjohn@gmail.com 등)을 행아웃에 추가하고 프로필 사진을 확인해서 동일인을 추적할 수 있음

  - 이런 이유로 내 실전화번호는 절대 입력하지 않음. 서비스 운영에 꼭 필요하지도 않으니까

- 한 사람이 장기간 동안 4만 건의 요청을 초당 서버에 날려도 리소스가 크게 치솟거나 경보가 울릴 일이 없었다는 점이 인상적임

  - 실제 알람이 울렸을 가능성도 있는데, 행동이 금방 중단되거나 상황이 빠르게 복구되어 엔지니어가 대시보드에 접근할 때쯤이면 이미 정상화됐을 수도 있음. 4만 QPS는 Focus나 Google API의 트래픽 규모에선 크게 튀지 않고, 다양한 IP 및 IPv6 /64 블록으로 분산되면 눈에 띄지 않게 넘어가는 경우도 있음. 이번 사례의 핵심은 모니터링이 아니라 JS 비활성화 플로우(이전 JS 활성화 플로우에서 빌린 토큰 사용)에 전혀 레이트 리밋이 없었다는 점이라고 봄

  - 혹시 봇넷을 썼을까 생각도 드는데, 요청마다 IP를 달리한 것 같기도 함

- 이런 유형의 버그 바운티는 보상 금액이 터무니없이 적은 편임. 안타까움

  - 보상을 자꾸 줄이면 결과적으론 자기 발등 찍는 격임

  - 이런 보안 이슈에 10만 달러 미만 지급은 정말 초라함

- 레거시 웹페이지를 유지·관리하는 일이 엄청난 부담임을 자주 느낌. 몇십 년 된 코드와 페이지까지 계속 유지해야 하는 사이트가 많고, 모든 조합을 테스트하는 것도 사실상 불가능함. Gmail 설정 안쪽을 파고들다 보면 아직도 2004년 스타일의 오래된 팝업이 뜨는 걸 직접 볼 수 있음

  - 버그 바운티 프로그램은 아주 효율적인 비용 활용 같음. 수천 달러만 들여도 극한의 엣지 케이스를 찾아주는 자발적 인력을 동원할 수 있음. 사내 인력을 쓴다면 훨씬 더 큰 비용이 들었을 거라 생각함

  - 이게 바로 기업들이 예전 서비스와 제품을 공격적으로 폐기하려 하는 가장 큰 이유임. “그냥 그대로 두면 되는 거 아니냐”라는 질문에 대한 답은, 결국 모든 레거시 서비스가 보안 구멍이 되기 때문임. 진짜 안전한 코드는 아예 없는 코드뿐임

  - 페이스북의 “톡” 기능 같은 걸 누가 담당하고 있는지 늘 궁금함

  - 대형 기업 내부에도 비슷한 레거시 인프라가 계속 굴러감. 예를 들어 내 친구는 글로벌 대기업 내에서 내부 링크 단축 앱을 유지보수하는데, 거의 사용량 폭주에도 노드 버전 업데이트 등 매우 단순한 이유로 매번 한두 건 티켓만 들어옴. 모니터링조차 정상 동작하지 않아도 버그 리포트가 드물 정도임

  - 최근에 나도 구글에서 예전(~2013년) Catull 로고가 뜨는 페이지를 만난 적이 있음

- “2025-05-15 – 패널이 $1,337 + 스웨그 지급. 근거: 익스플로잇 가능성 낮음(lol)”이라는 내용을 언급했는데, 실제로는 익스플로잇 가능성이 매우 높다고 생각함. 노출되는 전화번호 당사자는 많지 않을 수 있지만, 필요만 하면 사설탐정, 범죄자, 조사관 등 누구나 실제로 이 취약점을 활용할 거라 확신함

- 비밀번호 찾기 플로우에서 전화번호 일부를 힌트로 주는 것이 실제로는 보안 위험임을 이번에 새롭게 깨달음. 만약 여러 서비스가 각기 다른 순서로 마스킹된 전화번호/이메일 힌트를 제공한다면 위험도가 더 커짐

  - 위로가 될지 모르겠지만, 2FA 등 각종 이유로 수백/수천 개 서비스가 이미 내 전화번호를 수집했고, 동의 여부와 무관하게 상당수가 이미 유출됨. 실명-이메일-전화번호 조합은 거의 무조건 공개 데이터에 덤프된 상태임

  - 이런 정보들을 찾아주는 텔레그램 봇도 존재함. 이런 식으로 브루트포스 취약점이 드러나면 자동화 도구를 쓰던 이용자들도 불쾌함을 느끼는 듯함(EoG 봇이 대표적임)

  - 이런 개인 정보를 자동으로 모아주는 유료 서비스들도 이미 오래전부터 존재함. 이메일, 전화번호 등 다양한 정보가 여러 소스에서 쌓이고, 전 세계적으로 유인이 충분해 적극적으로 서비스 보안 허점을 공략함. 결국엔 대량 유출과 연결되는 구조임

  - 과거엔 한 회사 고객센터에 카드 뒷자리 4개를 물어보고, 그걸로 다른 회사 본인 인증을 풀어낸 소셜 엔지니어링 사례도 있었음

  - 나도 대학 시절, 신용카드도 이런 식으로 정보를 획득할 수 있다는 보안 연구자 발표를 들은 기억이 있음

- 2025년, 2023년, 2021년에도 “방지할 방법 없다”는 기사와 대규모 데이터 유출이 반복됨. [2025년 버전](https://qbix.com/blog/2025/06/06/%e2%80%9cno-way-to-prevent-this%e2%80%9d-says-only-industry-where-this-regularly-happens-posted-on-june-12-2023-by-qbix-2023-edition-in-the-hours-following-a-massive-data-leak-where-data-from-alm/), [2023년 버전](https://qbix.com/blog/2023/06/12/no-way-to-prevent-this-says-only-industry-where-this-regularly-happens-2/), [2021년 버전](https://qbix.com/blog/2023/06/12/no-way-to-prevent-this-says-only-industry-where-this-regularly-happens-2/)이 계속 반복됨. 어떤 버전이 더 웃긴지 고민함

- 이번 사례는 매우 창의적이고 멋지다고 생각함. Brutecat이 또 한 건 했음

- Google이 이제 진짜 유령선처럼 느껴짐. $5,000 버그 바운티는 모욕 수준이고, 이런 소액으로 시작했다는 자체가 Google이 사용자 데이터 보호에 진지하지 않다는 결정적 증거 같음

  - 버그 바운티 참여는 강제사항이 아님. 보상이 마음에 안 들면 그냥 안 하면 됨. 결국 이 프로그램들도 지속 가능한 모델 한계가 있음