▲

데이트 앱을 해킹한 경험 (그리고 보안 연구자를 대하는 잘못된 방식)

 (alexschapiro.com)
1P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • Cerca라는 데이팅 앱에서 심각한 보안 취약점이 발견됨
  • OTP가 응답에 노출되어 전화번호만 알면 누구나 계정 접근 가능
  • 인증 없이 열려 있는 여러 API 엔드포인트에서 개인정보가 쉽게 유출됨
  • 사용자의 성적 취향, 메신저 내용, 신분증 등 민감 정보가 대량 노출됨
  • 서비스 측은 연구자의 책임감 있는 신고에도 적절한 대응 및 공지 미흡

보안을 진지하게 생각해야 하는 스타트업의 중요성

  • 최근 스타트업들이 시장 출시를 서두르는 과정에서 보안이 소홀해짐
  • 개인정보가 집중되는 데이팅 앱임에도 개발 및 운영 미숙으로 사용자가 위험에 노출됨

취약점 발견 및 알림 절차

  • 2025년 2월 23일, Cerca 측에 이메일로 보안 취약점 및 관련 문제를 설명함
  • 2월 24일엔 영상회의를 통해 상세 취약점, 대응 방안, 추후 절차를 논의함
  • Cerca 팀은 심각성 인지와 신속한 조치 약속, 사용자 알림 예정임을 전달함
  • 이후 여러 차례 진행 상황 문의를 보냈으나 4월 21일 현재 답변 및 공지 없음
  • 독립적으로 확인한 결과, 해당 취약점은 패치 완료 상태임

OTP 취약점 및 간단한 해킹 과정

  • 앱 로그인 과정에서 일회용 비밀번호(OTP)가 네트워크 응답에 그대로 노출됨
  • 공격자는 전화번호만 알면 누구나 계정에 쉽고 빠른 접근 가능임

API 엔드포인트 접근과 정보 유출

  • 앱 버전 헤더 입력만으로 모든 API 경로에 접속 가능함이 확인됨
  • /docs 엔드포인트를 통해 OpenAPI 문서 전체 노출이 이루어짐
  • Burp Suite 등 도구를 활용하여 앱 헤더·토큰 자동 주입으로 API 제어가 가능함
  • 일부 엔드포인트는 비즈니스 로직만 변경하지만, 핵심 엔드포인트들은 심각하게 개인정보를 반환함
  • user/{user_id} 등으로 개인정보, 전화번호, 심지어 계정 탈취까지 가능함

대량의 개인정보 및 신분증 정보 노출 현황

  • 개인정보 엔드포인트를 통해 성별, 도시, 생일, 학교이메일, 신분증 정보 등 PII가 대량 노출됨
  • 특히, national_id_verified 등 신분증 관련 필드에서 여권·주민등록증 이미지 등 민감 파일 접근 가능
  • 공격 스크립트로 6,117명의 사용자를 식별, 207명은 신분증 정보까지 입력한 상태임을 확인함
  • 예일대학교 소속임을 표시한 계정도 일부 포함됨
  • Cerca 공식 인스타그램 기준 첫 주 1만 명 사용자에 해당하는 규모임

실제 피해 위험과 문제의 심각성

  • 성적 취향, 대화 내용, 신분증 등 극도의 민감 정보가 누출되어 스토킹, 신원도용, 협박 등 심각한 피해 위험임
  • Cerca는 '암호화 등 업계 기준을 준수한다'고 안내했지만, 실제 운영 실태와는 맞지 않음
  • 사용자는 직접 검증할 수 없으므로, 앱 제공사의 적극적이고 책임감 있는 보안 관리가 필수임
  • 실질적으로 불특정 다수가 이미 대규모 개인정보를 탈취했을 가능성도 존재함

결론 및 책임 있는 보안 문화의 필요성

  • 누구나 쉽게 해킹할 수 있을 정도로 보안에 취약한 앱 운영은 심각한 사회적 문제임
  • 사용자 데이터 보호를 최우선 순위로 두지 않으면 실시간으로 피해가 발생할 수 있음
  • 보안 연구자의 신고에 적극적 대응 및 사용자 안내가 미흡했던 Cerca의 사례는 타산지석임
  • 더 안전한 인터넷 환경을 구축하기 위해 모든 개발사는 보안 체계 확립이 최우선임
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • 이 앱이 대학생들이 꽤 초급으로 만든 결과물임을 감안해도, 보안과 커뮤니케이션에 최선을 다해야 한다고 생각함. 그렇지만 어떤 큰 VC가 자금을 대는 성인 기업들도 이런 문제에 부딪혀서 비슷하게 행동하는 걸 보면 학생들에게 너무 가혹하게 굴 필요까진 없다는 생각이 있음. 기사 링크를 공유함

    • 나는 강하게 동의하지 않음. "모르는 상태였다"가 면죄부가 될 수 없음. 모르는 상태로 강행한 게 오히려 더 큰 문제임. 이건 미숙한 운전자가 면허 없이 사고를 내 사람을 다치게 한 것과 같음
    • 나도 Cerca 관련 정보를 얻으려다 출처 링크를 눌러봤는데, 2025년 4월의 기사로 약 두 달 전에 만든 앱을 칭찬하는 내용임. 이건 LLM이 환각해서 만들어낸 쓰레기 같은 느낌임. OP 말대로 Cerca 팀에 2월에 연락했다고 하는데, 런칭하자마자 발견된 취약점이거나 뭔가 이상한 상황 같음. 그래도 "두 달 된 취약점" + "두 달 된 학생 만든 서비스"라는 점이 있음
    • "Cerca Applications, LLC"라는 이름 아래 앱이 출시된다면, 우리가 학생이 만든 앱이라 좀더 봐줘야 한다는 걸 사람들이 어떻게 알 수 있을지 모르겠음
    • 이 학생들은 다른 공부를 하는 게 맞을 것 같음
    • 이건 그들을 변호하는 소리 같음. 대학생들이 만든 앱이면 무조건 봐줘야 한다는 식이면 안 됨. The Facebook도 처음엔 대학생들이 시작한 것임. Meta의 오랜 개인정보 남용과 데이터 보안 무시는 이미 오랜 역사가 됨. 그래서, 이런 행동은 변명될 수 없고, 창업자의 나이나 경험에 관계없이 제대로 규제되고 벌금을 부과해야만 해결된다고 생각함
    • 여권과 성적 취향 같은 민감 데이터를 다루려면, 데이터를 누설하고 있다는 지적을 듣고 최소한 응답해야 함. 이건 완전 대참사이고, 여기서 보안 부재는 절대 용납될 수 없는 수준임
    • 앱 보안에 아무것도 모른다면, 그냥 앱을 만들지 말아야 한다는 생각임. 감정적으로 토로하게 되는데, 친구들이 소개팅 앱 쓰는 걸 보면 그들의 정보가 노출되는 게 너무 끔찍함. 만든 사람들이 부끄러움을 느껴야 함. 보안 연구자 연락에도 답하지 않았다니 거기에 대해서도 부끄러움을 느껴야 함. 만약 내가 그런 식으로 무시당했다면 훨씬 직설적인 폭로글을 썼을 것임. 제발 앱 만들기 그만했으면 함

  • 개발자로 소규모 회사에 근무하면서 내 개인 책임에 대해 걱정되는 부분이 종종 있음. 많은 기업들이 PCI나 HIPAA와 같은 규제를 받지 않아도 되는 곳에서 운영되고 있음. 작은 조직에선 보안이 조직 전체의 과제가 아니라 엔지니어링 과제로 여겨짐. 제품팀은 기능, PM은 일정, QA는 버그에만 집중하고, 보안에 대해 목소리 내는 사람이 드묾. 엔지니어들은 할당된 일만 하면 된다는 분위기임. 엔지니어가 보안도 챙길 수 있으면 좋지만, 아니면 PM 등에게 비난도 들음. 그리고 항상 이런 소리가 들림. "이거 하는데 얼마나 걸려?", "실제로 그 일이 일어날 확률이 얼마나 되는데?", "일단 MVP 빨리 내고 나중에 보완하자" 등. 그래서 나는 직원으로서 회사가 시키는 일만 하게 됨. 하지만 해킹이나 유출로 회사가 피소될 때, 나만 "더 잘 알았어야 할" 엔지니어라고 해서 책임을 져야 할까 수시로 걱정됨

    • 사실상 엔지니어가 아니라 인증 서류에 서명하고 안전을 보장하는 사람이 아니니, 안전하지 않다고 입증돼도 책임지지 않을 거임
    • 만약 회사가 LLC나 Corp라면 'corporate veil'로 보호받게 됨. 기록상 범죄행위를 한 게 아니라면 책임질 일이 없음. 다만 모든 기업 규모에서 보안 표준 부재가 큰 문제임. 늘 새로운 기능 출시가 보안보다 더 중요하게 여겨짐
    • 작은 조직의 엔지니어로서 이런 리스크를 팀에 교육하고, 보안을 위한 개발 시간을 할애하도록 강하게 주장하는 게 우리 책임이라고 생각함. 쉽진 않지만 이 부분을 소홀히 하면 회사 자체가 위험해질 수 있음
    • 나 같으면 내 자신을 보호할 수 있을 만큼 법을 알고, 불법적인 요청에 대해선 서면으로 반박하고, 무시해도 된다는 승인도 꼭 서면으로 받겠음. 하지만 작은 스타트업에서 그것도 힘들 수 있음. 만약 합법적이지 않다고 느껴지면 그냥 퇴사하겠음
    • "명령받은대로 했다"는 방어 논리가 싫기는 하지만, 이런 경우 반드시 서면으로 남겨두는 게 좋음: 보안에 문제 있다고 메일 남기고, 상사가 "굳이 신경 쓰지 마라"는 식으로 답하는 증거 확보. 내가 알기로 평사원급 직원이 데이터 유출로 법적 책임을 지는 경우는 본 적 없음. 대개 누구도 책임지지 않고 회사만 상징적인 벌금 내고 끝남
    • 회사 임원이 아니라면 개인적 책임을 질 일은 없을 것으로 생각함
    • 내 경험상 그런 일은 없음

  • 연구자의 법적 책임을 줄이려면, 계정을 하나 더 만들거나 친구 동의하에 프로필을 만들어 접근권을 얻는 정도로도 충분하다고 생각함. 데이터를 실제로 긁어올 필요 없이, 예를 들어 내 id가 12345이고 친구 id가 12357이면, 중간 id로 다른 계정의 프로필에 접근 가능한 걸 증명할 수 있음. 이미 많은 사람들이 말했듯이, 수천 명의 개인정보 접근까지 할 필요 없이, 취약점을 입증하고 공개하는 수준이면 충분함

    • 이게 정보보안 연구자라면 누구나 아는 표준적이고 명확한 방식임. 민감한 정보를 긁어서 증명하고 싶을 수 있지만, 그건 불필요하며 오히려 위선적인 행동임

  • 이 글 자체가 꽤 혼란스럽게 느껴짐. OTP(일회용 비밀번호)를 받는 API가 단순해서 그냥 서버 응답으로 OTP가 노출돼 전화번호만 알면 누구나 계정에 접근 가능하다는 식임. API가 그냥 otp/휴대폰번호로 되어있고 OTP가 응답에 들어온다 했으니, 전화번호를 맞추기만 하면 코드도 받는 구조인 듯함. 그리고 스크립트로 사용자 ID를 나열해 1,000번 연속 빈 ID가 나오면 멈추게 해서 총 6,117명의 유저, 207명의 신분증 정보, 19명의 Yale 학생을 확인했다고 밝힘. 그런데 이 정도 동의 없이 남의 개인정보에 접근한 건 과거 weev가 AT&T 해킹했다가 감옥 간 것과 비슷함. 규모가 작더라도, 이런 연구는 법적으로 위험하며, 보안 연구자를 보호하지 않는 법 환경을 저자가 모르는 것 같아 우려됨

    • API가 otp/번호로 최종 OTP를 바로 되돌려줬다는 부분을 언급함. 전화번호만 맞추면 OTP를 곧장 받을 수 있는 구조라는 뜻임
    • Auernheimer 사건의 최초 고소장을 읽어보면, 거기에는 (이 사례와 달리) 범죄 의도를 입증하는 충분한 증거가 있었음. 그들은 실제로 개인정보를 외부에 공개했다는 혐의도 있었고, 이번 사안은 그 정도까지 같지는 않음

  • 나도 비슷한 경험이 있는데, 다른 소개팅 앱에서 버그를 알리려다 연락이 안 돼서 창업자 프로필을 "연락주세요"로 바꿔봤더니 백업으로 복구해버림. 몇 년 후 인스타 광고에서 그 앱을 보고 다시 시도해보니 여전히 똑같은 취약점이 존재했음. API 엔드포인트만 알면 누구나 어드민 권한, 모든 쪽지/매칭 접근 가능함. 다시 연락해봐야 할지 고민임

    • 연락해서 책임감 있는 개발자임을 밝히고 이슈만 공개하고 넘어가는 게 좋지 않을지 제안함

  • 여권이나 주소 같은 민감 정보를 앱에서 수집할 땐 정말 두 번 생각하게 만들어야 한다고 봄. "학생이 만든 앱이라 그렇다"며 대수롭지 않게 넘기면 안 되는 문제임

    • 영국 정부가 포르노 사이트 접근에 신분증을 의무화하려고 애쓰고 있는데, 그게 어떤 결과를 가져올지 기대하고 있음
    • 여권 등 신분증 정보를 입력받았다면, 입력 후엔 절대 외부에 노출될 필요가 없음. 유아이에서 신분증 데이터 보여주기 위한 API라면, 전체 번호 대신 마지막 몇 자릿수만 돌려주면 충분함. 데이팅 앱이라면 ID 인증 여부만 불린 타입이나 enum(인증 안 됨/여권/운전면허식)으로 반환해도 충분함. 항공사 앱처럼 ID별로 선택해야만 하는 시스템은 예외지만, 예를 들어 United 앱도 마지막 몇 자리만 보여주듯이 이런 식으로 내부 API도 제한되길 바람
    • GDPR(유럽 개인정보보호법) 참조하라고 링크를 공유함
    • 아예 정부가 운영하는 안전하고 개인적인 신원확인 서비스가 필요하다는 생각임. 아니면 Apple이나 Google 같은 ‘거의 정부’ 역할을 하는 기업이라도 맡아야 함
    • 웬만하면 타사 신원확인 서비스를 쓰는 게 일반적인데, 저런 서비스도 진짜로 신분증 이미지까지 앱에 넘기나 의문임

  • OTP를 API 응답에 그대로 반환하는 건 너무 황당한 상황임. 이유를 모르겠음

    • UI에서 입력값과 바로 비교할 수 있게 한 거임. 보안을 생각하지 않으면 그럴싸하게 들릴 수 있음. 데이팅 앱은 필요한 개인정보 범위가 엄청 커서, 이런 실수는 끔찍함
    • 이렇게 하면 데이터베이스 비용을 단번에 줄일 수 있음
    • OTP를 생성한 뒤 DB 혹은 캐시 응답을 바로 리턴해서 POC나 MVP에선 대충 이런 모델을 쓰다 보면 쉽게 간과할 수 있음
    • OTP가 "원타임패스워드 전송 요청에 대한 응답"에서 그대로 노출되는 것으로 보임. 이건 아마 프레임워크가 DB 객체 전체를 직렬화해서 HTTP로 반환하기 때문일 수 있음
    • HTTP 요청 한 번 아끼고 UX가 빨라지니 겉으론 좋아 보임. Pinterest도 예전 API에서 2FA 시크릿까지 포함한 모든 정보를 노출한 적 있음. 리포트하고 포상도 받았지만, 이런 실수가 빅테크에도 종종 일어남
    • 나도 이해가 안 됨. 폼 빌드를 간단하게 하려고 했던 실수라고밖에 생각이 안 듦

  • Yale Daily News에서 관련된 또 다른 기사 링크를 공유함

  • 개인정보를 핵폐기물 수준으로 위험하게 다루는 법이 생겼으면 하는 바람임. 유출될 경우 회사 파산은 물론 책임자들도 법적 위기를 겪게 해야 한다고 생각함. 지금은 사용자 데이터 수집이 너무 쉬울 뿐 아니라, 유출돼도 사과만 하고 그냥 넘어감

    • PII를 핵처럼 다루는 건 지나친 것 같음. 이메일 주소 같이 인증/연락에만 쓰는 건 별 문제아님
    • 화이트칼라형 감옥이라도 가야 제대로 관심을 끌 수 있을 것 같음

  • iOS에서 Charle's Proxy라는 툴을 이제야 알게 됨. 과거엔 직접 앱 바이너리에서 문자열 검색하며 펜테스팅을 했음. iOS 전용 앱 분석에선 정말 큰 도움이 될 듯함

    • 괜찮은 툴이라 추천함(단, SSL pinning 있으면 안 먹힘)
답변달기