이 글에서 흥미로운 점은, 대부분의 호스팅 제공업체나 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 같은 저가 호스팅 업체도 가장 저렴한 상품에 /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년 버전, 2023년 버전, 2021년 버전이 계속 반복됨. 어떤 버전이 더 웃긴지 고민함
이번 사례는 매우 창의적이고 멋지다고 생각함. Brutecat이 또 한 건 했음
Google이 이제 진짜 유령선처럼 느껴짐. $5,000 버그 바운티는 모욕 수준이고, 이런 소액으로 시작했다는 자체가 Google이 사용자 데이터 보호에 진지하지 않다는 결정적 증거 같음
버그 바운티 참여는 강제사항이 아님. 보상이 마음에 안 들면 그냥 안 하면 됨. 결국 이 프로그램들도 지속 가능한 모델 한계가 있음
Hacker News 의견
이 글에서 흥미로운 점은, 대부분의 호스팅 제공업체나 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 같은 저가 호스팅 업체도 가장 저렴한 상품에 /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년 버전, 2023년 버전, 2021년 버전이 계속 반복됨. 어떤 버전이 더 웃긴지 고민함
이번 사례는 매우 창의적이고 멋지다고 생각함. Brutecat이 또 한 건 했음
Google이 이제 진짜 유령선처럼 느껴짐. $5,000 버그 바운티는 모욕 수준이고, 이런 소액으로 시작했다는 자체가 Google이 사용자 데이터 보호에 진지하지 않다는 결정적 증거 같음