▲

“슈퍼 보안”을 표방한 메신저 앱, 모든 사용자의 전화번호 유출

 (ericdaigle.ca)
1P by GN⁺ 13시간전 | ★ favorite | 댓글 1개
  • Freedom Chat이라는 MAGA(미국 보수 진영) 테마의 메신저 앱이 사용자 전화번호와 PIN 코드를 노출하는 심각한 취약점이 발견됨
  • 앱은 Converso라는 이전 프로젝트의 후속작으로, 과거에도 암호화 구현 오류와 데이터 노출 문제가 있었음
  • 분석 결과, 채널 기능을 통해 모든 회원의 PIN 코드가 다른 사용자에게 전송되고, 연락처 동기화 API를 통해 전화번호-UID 매칭이 가능함
  • 연구자는 속도 제한(rate limiting) 이 전혀 없어, 하루 만에 모든 Freedom Chat 사용자 전화번호를 수집할 수 있었음을 확인
  • 이 사건은 “보안을 강조하는” 앱이 오히려 기본적인 개인정보 보호조차 실패한 사례로 지적됨

Converso에서 Freedom Chat으로의 전환

  • 2023년 출시된 Converso는 “서버 없는 탈중앙 구조”와 “최신 E2EE”를 주장했으나, 연구자 crnković의 분석으로 모든 주장이 허위로 드러남
    • 실제로는 중앙 서버와 제3자 암호화 서비스(Seald) 를 사용하며, 암호화 키가 공개 정보로부터 유도 가능
    • 모든 메시지가 공개 Firebase 버킷에 업로드되어 누구나 열람 가능
  • 이후 CEO Tanner Haas는 앱을 철수하고, “보수 진영의 프라이버시 우려”를 이유로 Freedom Chat으로 리브랜딩
    • 그는 “비판을 수용하고 개선하라”는 교훈을 언급했으나, 보안 문제는 반복됨

Freedom Chat의 구조와 기능

  • 앱은 전화번호 기반 가입과 2FA 코드 인증을 사용하며, PIN 설정은 선택 사항
  • 주요 기능은 1:1 채팅과 채널(Channels) 로, Telegram과 유사한 구조
  • 앱은 스크린샷 차단 기능을 내세우며 “보안 기능”으로 홍보했으나, 실제 보안성과는 무관

PIN 코드 유출

  • /channel API 요청 결과, 채널 멤버 1,519명의 사용자 객체(user object) 에 PIN 필드가 포함되어 있음
    • 각 사용자의 UID, Seald 키, 생성일 등과 함께 6자리 PIN 코드가 평문으로 노출
  • 새 계정을 생성한 후 확인한 결과, 본인 PIN이 그대로 응답 데이터에 포함되어 있음
  • 즉, 기본 채널에 남아 있는 모든 사용자의 PIN이 다른 사용자에게 노출되는 구조

전화번호 매칭 취약점

  • /user/numbers API는 WhatsApp과 동일한 방식으로 연락처 존재 여부를 확인
    • 요청에 포함된 번호 중 Freedom Chat 사용자일 경우, UID와 Seald 키를 반환
  • 연구자는 이 API가 속도 제한이 전혀 없음을 확인, 모든 미국 전화번호를 순차적으로 테스트 가능
    • 결과적으로 전화번호-UID 매칭이 가능하며, 앞서 노출된 UID-PIN 데이터와 결합하면 전화번호-PIN 매핑 완성

전체 사용자 데이터 유출 실험

  • 연구자는 Python 스크립트를 작성해 모든 북미 전화번호(7자리 조합 × 지역번호) 를 자동 요청
    • 요청당 40,000개 번호를 전송하며, 평균 응답 시간은 약 1.5초
    • 27시간 동안 모든 요청이 성공적으로 처리되어 모든 Freedom Chat 사용자 전화번호 수집 완료
  • 서버는 속도 제한이나 차단 조치 없이 응답, 완전한 데이터 열람 가능 상태였음

대응 및 후속 조치

  • 2025-11-23: 취약점 발견
  • 2025-12-04: TechCrunch 기자 Zack Whittaker가 Freedom Chat에 취약점 공개
  • 2025-12-05: Freedom Chat 측은 “PIN은 메시지 복원용이 아니며, 이미 감사 절차를 진행 중”이라 해명
  • 2025-12-09: 문제 수정 완료 통보
  • 2025-12-11: 본 보고서와 TechCrunch 기사 동시 공개

핵심 교훈

  • Freedom Chat은 “슈퍼 보안”을 표방했지만, 기본적인 인증·속도 제한·데이터 보호 설계가 부재
  • 결과적으로 모든 사용자 전화번호와 PIN이 노출, 보안 기능이 사실상 무력화됨
  • 이는 보안 마케팅과 실제 구현의 괴리를 보여주는 대표적 사례로 평가됨
▲
GN⁺ 13시간전  [-]
Hacker News 의견들

  • Signal의 암호화된 전화번호 조회 시스템이 흥미로움
    서버가 하드웨어 암호화된 RAM에서 비트 단위 XOR 연산을 사용해 번호를 조회하기 때문에, 시스템을 가장 낮은 수준에서 들여다봐도 요청한 전화번호가 존재하는지 여부를 알 수 없음
    물론 rate limiting은 별도의 중요한 문제임. 보안 시스템을 만들 때는 커버해야 할 엣지 케이스가 정말 많음

    • 이런 방식이 멋지다고 생각하지 않음. 애초에 보안 메신저라면 개인 식별자인 전화번호를 요구하지 않아야 함
    • 정부가 모든 전화번호에 대한 조회 요청을 보내면 Signal이 이를 막을 수 있는지 궁금함
      Matrix 같은 비상업적·프라이버시 중심 플랫폼에서는 이런 매핑 자체를 불가능하게 해야 함
      예를 들어, 사용자가 자신의 연락처 목록에 있는 사람만 자신을 찾을 수 있도록, 각 사용자 쌍의 전화번호를 해시한 값을 업로드하는 방식 제안
      장점은 해시 공간이 넓어 역추적이 어렵고, 사용자가 발견 허용 범위를 직접 정할 수 있음
      단점은 공격자가 모든 번호 조합을 생성해 연락처 관계를 추출할 수 있고, 정부는 SMS 인증을 가로채 이를 악용할 수도 있음
    • 서버가 하드웨어 암호화된 RAM에서 XOR을 사용한다는 부분이 흥미로움. 이에 대한 추가 자료가 있는지 궁금함
    • 여전히 전화번호를 요구하는 게 아쉬움. 최근에야 username 기능이 추가되어 번호 노출을 피할 수 있게 되었지만, 여전히 SIM 기반 계정이라는 점이 꺼림칙함
    • 하지만 우리가 직접 Signal 서버를 빌드해 운영할 수 없으니, 실제로 서버가 이런 처리를 하는지 확신할 수 없음

  • 사용자 객체의 pin 필드가 의심스러움
    아마도 opt-out 직렬화 라이브러리를 써서 생긴 문제일 가능성이 있음. 기본적으로 객체 전체를 직렬화하기 때문에, 개발자가 특정 필드를 제외하는 설정을 깜빡하면 그대로 노출됨
    혹은 서버에서 단순히 JS 딕셔너리를 쓰다가 응답 전 필드를 제거하지 않았을 수도 있음
    이 취약점은 비엔나 대학 연구팀 논문에서 언급된 오래된 문제로, 2016년 Telegram에서도 동일한 방식으로 악용되어 이란 정부가 1,500만 명의 사용자 전화번호를 수집했음
    관련 링크: Telegram 블로그

    • 예전 직장에서 코드 감사를 하며 이런 직렬화 취약점을 곳곳에서 발견했음. 개발자들은 이런 라이브러리를 이제 그만 써야 함
    • 이런 문제는 정말 흔함. 민감한 필드가 클라이언트로 전송되는데, UI에서는 보이지 않으니 아무도 눈치채지 못함
    • PIN이 노출된 것도 문제지만, 평문 저장이라는 점이 더 심각함. 비밀번호처럼 강력한 해시 알고리즘으로 처리했어야 함

  • 요즘 보안 취약점의 대부분은 단순히 예상치 못한 방식으로 HTTP 엔드포인트를 호출하는 것에서 비롯됨
    2025년에 해킹이라 하면 복잡한 기술을 떠올리지만, 실제로는 rate limiting조차 없는 API를 배포하는 게 현실임. Nginx 설정 한 줄이면 해결될 문제임

    • “Nginx 설정 한 줄이면 된다”는 말에 대해, “그게 Docker 튜토리얼에 없어서 뭔지 모른다”는 식의 반응이 떠오름
    • 소프트웨어 개발은 발전했지만, 보안 개발 원칙은 거의 성장하지 못했음
      대부분의 목표는 사용자 마찰을 줄이고 상업적 효율성을 높이는 것임. 많은 개발자들이 XSS나 SSRF 같은 기본적인 취약점을 모른 채 기능만 구현함
    • 단순한 설정이라도 존재 자체를 알아야 적용할 수 있음
    • 예전엔 자동화된 내부 보안 스캔이 쓸모없다고 생각했지만, 실제로 기본적인 설정을 빠뜨리는 사례를 보고 나서는 필수라고 느낌
      Docker 포트 매핑 실수나 CSP 누락 같은 기초적인 보안 실수가 너무 흔함
    • 하지만 rate limiting만으로는 충분하지 않음. 공격자는 IP를 분산시켜 병렬 요청을 보낼 수 있음

  • “최고의 블로그 글만 독자들에게 제공하고 싶다”는 문장을 보고, 글쓴이와 유사한 성향의 사람을 찾은 기분이 들었음

  • Freedom Chat®이 기자가 그룹 채팅에 참여하지 못하게 하는 기능이 있는지 궁금함. 농담 반 진담 반으로 DoD 친구를 위해 묻는 중임

  • 올해만 해도 “보안 앱”이 사용자 데이터를 다루다 유출한 사례가 여러 번 있었음
    기억나는 것만 해도 20센트어치(=4건) 정도지만, 아마 더 많을 것 같음
    관련 사례: 1, 2, 3

    • 이번 사건을 계기로 Facebook Messenger 외부로 나가는 움직임이 중요하다고 생각함
    • 그리고 우리가 아는 건 그중 일부일 뿐임

  • 작년에 GOP 구직 게시판을 우연히 봤는데, 지원서가 구인 공고와 같은 검색 인덱스에 저장되어 있었음
    “bob”이라고 검색하니 지원자들의 이력서와 답변이 그대로 노출되어 충격이었음

    • 어떤 사이트였는지 궁금함

  • Anom 사건 이후로는 “honeypot”보다 더 적절한 단어가 필요함
    진짜 안전한 메신저는 이런 방식으로는 나오지 않을 것임. 하지만 마케팅은 계속되고, 매번 새로운 사용자들이 끌려들어옴

    • 요즘은 실패가 곧 기능이 되는 세상임
      데이터 유출이 너무 자주 일어나서 이제는 사람들도 무감각해짐. 집단소송 보상도 결국 개인정보를 더 제공하는 과정이 되어버림
      예측시장, 암호화폐 등도 결국 참여자에게 손해를 주는 구조적 실패를 ‘성공’처럼 포장하는 느낌임
    • “Petepot”이라는 새 단어 제안이 나옴

  • Freedom Chat이 “문제 수정 완료”라고 공지했지만, 정말 수정된 건지 의문임

  • “모바일 앱 개발 경험은 없지만, 똑똑하니까 어렵지 않을 거라 생각했다”는 문장이 실제 인용이라면, 거의 스탠드업 코미디 대사처럼 들림

답변달기