# “슈퍼 보안”을 표방한 메신저 앱, 모든 사용자의 전화번호 유출 > Clean Markdown view of GeekNews topic #25105. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25105](https://news.hada.io/topic?id=25105) - GeekNews Markdown: [https://news.hada.io/topic/25105.md](https://news.hada.io/topic/25105.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-12-16T09:56:52+09:00 - Updated: 2025-12-16T09:56:52+09:00 - Original source: [ericdaigle.ca](https://ericdaigle.ca/posts/super-secure-maga-messaging-app-leaks-everyones-phone-number/) - Points: 1 - Comments: 1 ## Topic Body - **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이 노출**, 보안 기능이 사실상 무력화됨 - 이는 **보안 마케팅과 실제 구현의 괴리**를 보여주는 대표적 사례로 평가됨 ## Comments ### Comment 47809 - Author: neo - Created: 2025-12-16T09:56:52+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46279123) - Signal의 **암호화된 전화번호 조회 시스템**이 흥미로움 서버가 하드웨어 암호화된 RAM에서 비트 단위 XOR 연산을 사용해 번호를 조회하기 때문에, 시스템을 가장 낮은 수준에서 들여다봐도 요청한 전화번호가 존재하는지 여부를 알 수 없음 물론 **rate limiting**은 별도의 중요한 문제임. 보안 시스템을 만들 때는 커버해야 할 **엣지 케이스**가 정말 많음 - 이런 방식이 멋지다고 생각하지 않음. 애초에 **보안 메신저**라면 개인 식별자인 전화번호를 요구하지 않아야 함 - 정부가 모든 전화번호에 대한 조회 요청을 보내면 Signal이 이를 막을 수 있는지 궁금함 Matrix 같은 **비상업적·프라이버시 중심 플랫폼**에서는 이런 매핑 자체를 불가능하게 해야 함 예를 들어, 사용자가 자신의 연락처 목록에 있는 사람만 자신을 찾을 수 있도록, 각 사용자 쌍의 전화번호를 해시한 값을 업로드하는 방식 제안 장점은 해시 공간이 넓어 역추적이 어렵고, 사용자가 **발견 허용 범위**를 직접 정할 수 있음 단점은 공격자가 모든 번호 조합을 생성해 연락처 관계를 추출할 수 있고, 정부는 SMS 인증을 가로채 이를 악용할 수도 있음 - 서버가 하드웨어 암호화된 RAM에서 XOR을 사용한다는 부분이 흥미로움. 이에 대한 **추가 자료**가 있는지 궁금함 - 여전히 전화번호를 요구하는 게 아쉬움. 최근에야 **username 기능**이 추가되어 번호 노출을 피할 수 있게 되었지만, 여전히 SIM 기반 계정이라는 점이 꺼림칙함 - 하지만 우리가 직접 **Signal 서버를 빌드해 운영**할 수 없으니, 실제로 서버가 이런 처리를 하는지 확신할 수 없음 - 사용자 객체의 `pin` 필드가 의심스러움 아마도 **opt-out 직렬화 라이브러리**를 써서 생긴 문제일 가능성이 있음. 기본적으로 객체 전체를 직렬화하기 때문에, 개발자가 특정 필드를 제외하는 설정을 깜빡하면 그대로 노출됨 혹은 서버에서 단순히 JS 딕셔너리를 쓰다가 응답 전 필드를 제거하지 않았을 수도 있음 이 취약점은 **비엔나 대학 연구팀 논문**에서 언급된 오래된 문제로, 2016년 Telegram에서도 동일한 방식으로 악용되어 이란 정부가 1,500만 명의 사용자 전화번호를 수집했음 관련 링크: [Telegram 블로그](https://telegram.org/blog/15million-reuters) - 예전 직장에서 코드 감사를 하며 이런 **직렬화 취약점**을 곳곳에서 발견했음. 개발자들은 이런 라이브러리를 이제 그만 써야 함 - 이런 문제는 정말 흔함. **민감한 필드**가 클라이언트로 전송되는데, UI에서는 보이지 않으니 아무도 눈치채지 못함 - PIN이 노출된 것도 문제지만, **평문 저장**이라는 점이 더 심각함. 비밀번호처럼 강력한 해시 알고리즘으로 처리했어야 함 - 요즘 보안 취약점의 대부분은 단순히 예상치 못한 방식으로 **HTTP 엔드포인트를 호출**하는 것에서 비롯됨 2025년에 해킹이라 하면 복잡한 기술을 떠올리지만, 실제로는 **rate limiting조차 없는 API**를 배포하는 게 현실임. Nginx 설정 한 줄이면 해결될 문제임 - “Nginx 설정 한 줄이면 된다”는 말에 대해, “그게 Docker 튜토리얼에 없어서 뭔지 모른다”는 식의 반응이 떠오름 - 소프트웨어 개발은 발전했지만, **보안 개발 원칙**은 거의 성장하지 못했음 대부분의 목표는 사용자 마찰을 줄이고 **상업적 효율성**을 높이는 것임. 많은 개발자들이 XSS나 SSRF 같은 기본적인 취약점을 모른 채 기능만 구현함 - 단순한 설정이라도 **존재 자체를 알아야** 적용할 수 있음 - 예전엔 자동화된 내부 보안 스캔이 쓸모없다고 생각했지만, 실제로 기본적인 설정을 빠뜨리는 사례를 보고 나서는 필수라고 느낌 Docker 포트 매핑 실수나 CSP 누락 같은 **기초적인 보안 실수**가 너무 흔함 - 하지만 rate limiting만으로는 충분하지 않음. 공격자는 **IP를 분산**시켜 병렬 요청을 보낼 수 있음 - “최고의 블로그 글만 독자들에게 제공하고 싶다”는 문장을 보고, 글쓴이와 **유사한 성향의 사람**을 찾은 기분이 들었음 - Freedom Chat®이 기자가 그룹 채팅에 참여하지 못하게 하는 기능이 있는지 궁금함. 농담 반 진담 반으로 **DoD 친구**를 위해 묻는 중임 - 올해만 해도 “보안 앱”이 사용자 데이터를 다루다 **유출한 사례**가 여러 번 있었음 기억나는 것만 해도 20센트어치(=4건) 정도지만, 아마 더 많을 것 같음 관련 사례: [1](https://news.ycombinator.com/item?id=44684373), [2](https://news.ycombinator.com/item?id=43964937), [3](https://news.ycombinator.com/item?id=45985036) - 이번 사건을 계기로 **Facebook Messenger 외부로 나가는 움직임**이 중요하다고 생각함 - 그리고 우리가 아는 건 그중 일부일 뿐임 - 작년에 **GOP 구직 게시판**을 우연히 봤는데, 지원서가 구인 공고와 같은 검색 인덱스에 저장되어 있었음 “bob”이라고 검색하니 지원자들의 **이력서와 답변**이 그대로 노출되어 충격이었음 - 어떤 사이트였는지 궁금함 - Anom 사건 이후로는 “**honeypot**”보다 더 적절한 단어가 필요함 진짜 안전한 메신저는 이런 방식으로는 나오지 않을 것임. 하지만 마케팅은 계속되고, 매번 새로운 사용자들이 끌려들어옴 - 요즘은 **실패가 곧 기능이 되는 세상**임 데이터 유출이 너무 자주 일어나서 이제는 사람들도 무감각해짐. 집단소송 보상도 결국 **개인정보를 더 제공**하는 과정이 되어버림 예측시장, 암호화폐 등도 결국 **참여자에게 손해를 주는 구조적 실패**를 ‘성공’처럼 포장하는 느낌임 - “Petepot”이라는 새 단어 제안이 나옴 - Freedom Chat이 “문제 수정 완료”라고 공지했지만, **정말 수정된 건지 의문**임 - “모바일 앱 개발 경험은 없지만, 똑똑하니까 어렵지 않을 거라 생각했다”는 문장이 실제 인용이라면, 거의 **스탠드업 코미디 대사**처럼 들림