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

 (alexschapiro.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Cerca Dating App은 전화번호 기반 로그인과 노출된 API가 맞물려, OTP 응답에 인증 코드가 포함되고 개인정보 조회까지 이어질 수 있는 위험한 상태였음
  • api.cercadating.com은 앱 버전 헤더를 붙이면 /docs의 openapi.json으로 엔드포인트가 드러났고, 일부 요청은 강제 매칭 같은 비즈니스 로직까지 조작할 수 있었음
  • user/{user_id}는 유효한 사용자 ID만으로 이름, 위치, 생년월일, 학교, 전화번호, 이메일, 프로필 상태 등 PII를 반환해 OTP 취약점과 결합될 경우 계정 탈취로 이어질 수 있었음
  • 계정 접근 후에는 제출된 사용자에 한해 여권 또는 신분증 정보, 셀피 URL, 사적인 메시지까지 접근 가능했으며, 확인 스크립트로 사용자 6,117명, ID 정보 입력자 207명, Yale 학생 표시 사용자 19명을 찾았음
  • 취약점은 2025년 2월 23일 Cerca에 제보되고 2월 24일 통화까지 진행됐지만, 4월 21일 공개 시점까지 후속 답변과 사용자 통지는 없었고 패치 여부만 독립적으로 확인됨

제보 이후 끊긴 대응

  • Cerca Dating App은 사적인 메시지, 여권 정보, 성적 선호, 기타 개인정보가 노출될 수 있는 데이트 앱 보안 취약점을 갖고 있었음
  • 취약점 발견 후 2025년 2월 23일 Cerca 팀에 이메일로 제보했고, 다음 날 영상 통화에서 취약점, 완화 방안, 후속 조치를 논의함
  • Cerca 팀은 문제의 심각성을 인정하고 책임 있는 공개에 감사하며, 취약점 해결과 영향을 받은 사용자 통지를 약속함
  • 이후 3월 5일과 3월 13일에 수정 및 사용자 통지 계획 업데이트를 요청했지만, 2025년 4월 21일 공개 시점까지 답변이 없었음
  • 공개 전 취약점이 패치됐다는 점은 독립적으로 확인됐고, 이를 바탕으로 공개가 이뤄짐

OTP 로그인에서 시작된 계정 접근

  • 앱은 전화번호로 코드를 보내는 OTP 기반 로그인만 사용함
  • 네트워크 요청을 확인하기 위해 iPhone 앱에서 Charles Proxy를 사용해 앱 요청을 가로챔
  • OTP를 트리거하는 응답 안에 일회용 비밀번호가 직접 포함돼 있었음
  • 이 구조에서는 사용자의 전화번호만 알면 해당 계정에 접근할 수 있었음
  • 계정 보유자의 전화번호를 알아내는 별도 경로가 필요해 API 엔드포인트 탐색으로 이어짐

OpenAPI 문서로 드러난 엔드포인트

  • api.cercadating.com에 대해 디렉터리 퍼저를 사용해 경로를 열거함
  • 앱 관련 헤더 없이는 사이트의 어떤 부분에도 접근할 수 없었음
  • Gobuster에 해당 헤더를 붙여 요청하자 /docs 엔드포인트를 찾았고, 여기서 openapi.json이 제공됨
  • Burp Suite의 match-and-replace 기능으로 앱 버전 헤더와 Charles Proxy에서 추출한 bearer token을 항상 붙이도록 설정함
  • 일부 보호되지 않은 엔드포인트는 비즈니스 로직에 영향을 줬고, 두 사람을 강제로 매칭시키는 요청도 가능했음

사용자 프로필과 개인정보 노출

  • user/{user_id} 엔드포인트는 유효한 사용자 ID를 받으면 다양한 개인정보를 반환함
  • 응답에는 다음 정보가 포함됨
    • 이름, 성별, 관심 성별, 도시, 위도·경도
    • 학교 이메일과 인증 상태, 업계, 직업, 생년월일, 키
    • 학교 ID와 학교 이름, 프로필 완성 여부
    • 국적 ID 인증 여부, 모바일·이메일 인증 여부
    • 프리미엄 상태, 계정 활성·일시중지·온보딩 상태
    • 전화번호, 이메일, 사용자 ID, 검색 잔여 횟수
    • 프로필 이미지, 매칭 선호, 사용자 프롬프트, 상호 연락처 정보, 생성·수정 시각, 나이 등
  • Python 스크립트로 유효한 사용자 ID를 찾아 사용자 데이터를 대량 열거할 수 있었음
  • 반환된 전화번호는 OTP 취약점과 결합돼 전체 계정 접근에 사용될 수 있었음
  • OTP 로그인 없이도 사용자 개인정보가 노출되는 상태였음

신분증과 사적인 메시지까지 이어진 접근

  • national_id_verified 필드는 여권 또는 신분증 정보가 시스템에 저장된다는 점을 보여줌
  • 신분증 관련 응답에는 다음 정보가 포함됨
    • verification_type: PASSPORT
    • document_number
    • front_side_url
    • back_side_url
    • selfie_url
    • 상태, ID, 사용자 ID
  • 이 정보는 로그인한 사용자에게만 제공되지만, OTP 취약점 때문에 임의 사용자로 로그인할 수 있는 상태였음
  • 제출된 사용자에 대해서는 누구의 ID 정보든 볼 수 있는 구조였지만, 실제로 그렇게 하지는 않았다고 밝힘
  • 잠재적 데이트 상대와의 개인 메시지도 볼 수 있었고, 제출된 경우 여권 정보까지 접근 가능했음

확인된 노출 규모

  • 빠른 스크립트로 정보를 얻을 수 있는 사용자 수, Yale 학생으로 등록된 사용자 수, ID 정보를 입력한 사용자 수를 집계함
  • 스크립트는 유효한 사용자 ID를 세다가 1,000개 연속으로 유효한 ID를 찾지 못하면 중지하는 방식이었음
  • 이 방식은 더 많은 사용자가 있을 가능성을 배제하지 않음
  • Cerca는 첫 주 사용자 수를 1만 명이라고 밝혔음
  • 확인된 수치는 다음과 같음
    • 사용자 6,117명
    • ID 정보를 입력한 사용자 207명
    • Yale 학생이라고 표시한 사용자 19명

개인정보 보호 약속과 실제 위험

  • Cerca의 개인정보 처리방침은 “암호화와 기타 업계 표준 조치로 데이터를 보호한다”고 말함
  • 실제 취약점 상태와 비교하면 이 문구는 오해의 소지가 있음
  • 노출 대상에는 성적 선호, 사적인 메시지, 다양한 개인정보가 포함될 수 있었음
  • 악의적 사용자가 해당 정보에 접근하면 신원 도용, 스토킹, 협박 같은 결과로 이어질 수 있음
  • 데이트 앱은 민감한 데이터를 다루기 때문에, 앱 출시 속도보다 사용자 데이터 보안이 우선돼야 함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 앱은 대학생들이 만든 꽤 초기 수준의 프로젝트로 보임. 보안과 커뮤니케이션 관행을 제대로 지키려고 최선을 다해야 하는 건 맞지만, 비슷한 문제에서 대형 VC 투자받은 “어른 회사”들도 엉망으로 대응하는 걸 생각하면 너무 가혹하게 몰아붙이고 싶지는 않음
    https://georgetownvoice.com/2025/04/06/georgetown-students-c...

    • 강하게 반대함. “뭘 하는지 몰랐으니 너무 심하게 판단하지 말자”는 말은 이상함. 뭘 하는지 몰랐는데도 출시까지 진행한 것이라면 감경 요소가 아니라 가중 요소에 가깝다고 봄
      운전자가 사고로 사람을 죽였는데 알고 보니 면허도 없었던 경우와 비슷함
    • “Cerca” 정보를 찾다가 같은 링크를 봤는데, 2025년 4월 글이고 두 달 전에 만든 앱을 칭찬하는 내용이라 LLM 환각 같은 쓰레기 글처럼 보임
      원글은 2월에 Cerca 팀에 연락했다고 되어 있으니, 출시일에 발견된 결함이거나 뭔가 이상한 구조임. 어쨌든 “두 달 된 취약점”이자 “두 달 된 학생 제작 앱/서비스”임
    • 앱이 Cerca Applications, LLC 명의로 출시되어 있으면, 그냥 봐줘야 할 스크립트 키디 몇 명인지 어떻게 알 수 있겠음
    • 이 사람들은 아마 다른 전공을 공부하는 게 나을 듯함
    • 일리 있는 말이지만 그래도 이건 너무함. 비밀이어야 하는 OTP를 응답 본문에 돌려주지 않는 건 숙련 개발자든 고등학생이든 상식에 가까움
      게다가 재미로 만든 물건이 아니라 상업 제품임. 앱 내 구매가 Cerca App $9.99, Cerca App 3 month $9.99, 10 Swipes $2.99, 3 Swipes $0.99, 5 swipes $1.99, 3 Searches $1.99, 10 Searches $3.99, 5 Searches $2.99로 올라와 있음

  • 작은 회사 엔지니어로서 가끔 내 개인 책임이 걱정됨. PCI나 HIPAA가 적용되지 않는 비규제 업종에서 운영되는 회사가 너무 많고, 작은 조직에서는 보안이 조직 차원의 의무가 아니라 그냥 엔지니어링 관심사로 밀려남
    제품팀은 기능, PM은 일정, QA는 버그 찾기에 집중하고, 보안에 대해 합리적으로 목소리 내는 사람은 드묾. 엔지니어는 보드에 올라온 작업을 끝내는 것 이상을 기대받지 않음. 일정에 영향 없이 안전하게 만들 수 있으면 좋지만, 아니면 PM 등에게 압박을 받게 됨
    “그거 얼마나 걸리는데?”, “실제로 그런 일이 생길 위험이 얼마나 되는데?”, “나중에 보안 처리하고 일단 MVP부터 고객에게 내보내자” 같은 말을 듣게 됨. 직원으로서는 고용주가 시키는 일을 하는데, 해킹이나 데이터 유출로 회사가 소송당하면 “알았어야 했던” 유일한 사람이라는 이유로 내가 개인적으로 책임지게 되는 건가 싶음

    • 엄밀히 말하면 진짜 공학 엔지니어는 아님. 안전을 인증하는 설계 도면에 서명하지도 않을 것이고, 안전하지 않다고 입증되어도 그 책임을 지지는 않을 것임
    • LLC나 법인이라면 범죄 행위를 했다고 문서로 남겨둔 게 아닌 한 법인격의 장막으로 보호될 가능성이 큼
      다만 규모를 막론하고 조직 전반의 보안 기준 부족은 한심함. 좋은 보안 관행을 보장하는 것보다 새 기능 출시가 항상 앞서는 듯함
    • 개인적으로는 스스로를 보호할 만큼 법을 알고, 불법적인 것에는 서면으로 반대하고, 무시하라는 지시도 서면 승인으로 받아두고 싶음
      다만 스타트업에서 개발자가 한두 명뿐이면 이것조차 어렵다는 건 이해함. 합법적인 일을 추구하지 않는다고 느껴지면 나는 떠날 것 같음
    • 작은 조직의 엔지니어라면 나머지 팀에게 이런 보안 위험을 교육하고, 이를 완화할 엔지니어링 시간을 확보하도록 밀어붙이는 책임이 있다고 봄
      쉽지는 않지만, 진지하게 다루지 않으면 사업 자체를 가라앉힐 수 있는 중요한 일임
    • “명령을 따랐을 뿐”이라는 방어 논리를 싫어하긴 하지만, 이런 경우라면 반드시 서면 기록을 남겨야 함
      보안 부족에 대한 우려를 제기한 이메일 기록과, 상사가 신경 쓰지 말라고 답한 기록이 필요함. 어느 지역인지는 모르겠지만, 일반 직원 개인이 데이터 유출에 법적 책임을 진 사례는 알지 못함. 보통 데이터 유출에는 아무도 실질적 결과를 겪지 않고, 회사가 형식적인 벌금만 내고 넘어가는 경우가 많음

  • 연구자로서 법적 노출을 줄이려면 두 번째 계정을 만들거나 친구에게 프로필을 만들게 하고 접근 동의를 받는 정도로 충분했을 듯함
    열거 취약점을 증명하려고 실제로 데이터를 긁어올 필요는 없음. 내 ID가 12345이고 친구가 가입해서 12357을 받았다면, 어떤 사용자의 ID든 찾아서 프로필에 접근할 수 있다는 증거로 충분함
    다른 사람들이 말했듯, 취약점을 검증하고 공개하는 데 다른 사용자들의 개인식별정보를 그만큼 많이 접근할 필요는 없음

    • 이게 대부분의 보안 연구자가 무시하는 표준적이고 명백한 방식임
      개인식별정보가 보호되길 원하면서도 그걸 긁어와서 증명하는 건 불필요하고 위선적임

  • 글이 꽤 혼란스러움. OTP 기반 로그인에서 일회용 비밀번호 요청 응답에 OTP가 그대로 들어온다는 부분은 설명이 부족하지만, 아마 api.cercadating.com/otp/ 같은 API라서 전화번호를 추측하면 해당 번호를 소유하지 않아도 OTP 코드를 받을 수 있다는 뜻으로 보임
    또 1,000개 연속 ID에서 유효 사용자가 없으면 멈추는 스크립트로 6,117명, 신분증 정보를 넣은 207명, Yale 학생이라고 주장한 19명을 찾았다고 하는데, 이게 얼마나 위험한지 작성자가 아는지 모르겠음. 사실상 weev가 AT&T를 침해했던 방식과 비슷하고 그는 감옥에 갔음[0]
    더 큰 회사와 더 큰 유출이긴 했지만, 보안 구멍을 이용해 수천 명의 데이터를 무단 접근했다고 공개적으로 자랑하지는 않을 것 같음. 도덕성을 판단하려는 건 아니고, 보안 연구자가 경고할 여지는 있어야 한다고 보지만, 법은 보안 연구자에게 상당히 불리함
    [0] https://en.wikipedia.org/wiki/Goatse_Security#AT&T/iPad_emai...

    • 전화번호 추측을 언급했고, OTP를 보내는 API 호출이 말 그대로 OTP를 반환한다고 되어 있음
    • Auernheimer 사건의 원 고소장을 읽어보면, 검찰은 여기에는 없을 가능성이 큰 광범위한 고의성 증거를 갖고 있었음
      그 사건의 피고들은 기반 개인식별정보를 공개했다는 혐의도 받았는데, 여기서는 그런 일이 있었던 것처럼 보이지 않음

  • 다른 데이팅 앱에서 비슷한 일을 겪었는데, 그쪽은 끝내 답이 없었음. 창업자의 관심을 끌려고 그의 소개글을 “연락 달라”는 문구로 바꿨더니 백업을 복원하더라
    몇 년 뒤 Instagram 광고를 보고 문제가 아직 있는지 확인해 봤는데, 여전히 있었음. 앱-프록시-서버로 쉽게 찾을 수 있는 API 엔드포인트만 알면 누구나 전체 관리자 권한을 갖고 모든 메시지와 매칭 등에 접근할 수 있는 구조였음
    다시 가서 한 번 더 시도해야 하나 싶음

    • 책임 있는 개발자답게 연락처로 취약점 공개만 하고 넘어가면 되지 않나 싶음

  • 여권이나 주소처럼 민감한 정보를 받기 전에는 사람들이 두 번 생각하도록 강제해야 함. 이런 일은 그냥 아이들이 앱 만든 것으로 치부하고 넘길 수 없음

    • 여권이나 다른 신분증 정보는 입력 이후에 공개적으로 노출할 이유가 전혀 없음. UI에 보여주려고 API로 데이터를 가져와야 한다 해도 전체 여권/신분증 번호를 포함할 필요는 없고, 최소한 마지막 몇 자리만 보내도록 가릴 수 있음
      데이팅 사이트라면 API는 신분증 상태에 대해 verified/not-verified 불리언이나 ‘not-verified’, ‘passport’, ‘drivers-license’ 같은 열거값만 반환해도 충분함. 클라이언트/UI에 세부 정보를 표시할 실제 필요가 없음
      항공사 앱처럼 출입국 목적의 신분 문서를 선택해야 하는 경우는 예외적으로 더 많은 정보를 보여줄 수 있지만, United 앱처럼 여권 번호 마지막 몇 자리만 보여주면 됨. 내부 API로도 그 정도만 보내길 바람
    • 영국 정부는 포르노 사이트 접근에 신분증 확인을 의무화하려고 열심인데, 그게 자기들 얼굴에 터지는 날이 기대됨
    • 정부가 운영하는 안전하고 사적인 신원 확인 서비스 같은 게 있어야 함
      아니면 Apple이나 Google처럼 “정부 비슷한” 곳이라도 맡을 수 있음
    • GDPR을 보면 됨
      https://en.wikipedia.org/wiki/General_Data_Protection_Regula...
    • 서드파티 신원 확인 서비스를 쓰지 않았던 건가? 보통 앱들은 그런 식으로 처리하던데. 설마 그런 서드파티 서비스가 실제 이미지 같은 신분증 원본을 앱에 그대로 넘겨주는 건 아니겠지?

  • 요청 API 응답에서 OTP를 반환한다는 건 말이 안 됨. 왜 그렇게 했을까?

    • UI가 사용자가 입력한 값이 맞는지 확인하게 하려고 그랬을 수 있음
      보안을 생각하지 않으면 매우 그럴듯하고 명백한 해결책이긴 함. 데이팅 앱은 필수적으로 개인식별정보가 많아서 만들기 가장 위험한 종류의 앱 중 하나인데, 이건 끔찍함
    • OTP를 생성하고 저장한 뒤 데이터베이스나 캐시 등의 응답을 그대로 반환했을 가능성이 있음
      빠른 개념증명이나 MVP에서는 시간을 아끼려고 저장 모델을 API 응답으로 그대로 쓰는 경우가 많아서, 쉽게 놓칠 수 있음
    • 데이터베이스 비용을 없애는 간단한 한 가지 비법임
    • HTTP 요청 하나를 줄이고 사용자 경험도 빨라짐. 싫어할 이유가 뭐가 있겠음?
      Pinterest의 새 API가 나왔을 때 OAuth 연동을 쓰는 모든 앱에 사용자 정보를 전부 뿌리고 있었고, 2단계 인증 비밀값까지 포함되어 있었음. 신고해서 포상금을 받았지만, 이런 짓은 더 잘 알아야 할 대기업 API에서도 생김
    • OTP가 “일회용 비밀번호를 트리거한 응답”에서 보내진 것으로 보임
      프레임워크 탓일 가능성이 있음. 아마 데이터베이스에 넣는 객체를 ORM이나 다른 저장 시스템에서 바로 직렬화해서 HTTP 응답으로 돌려주는 구조였을 것 같음

  • https://yaledailynews.com/blog/2025/04/24/yale-student-expos...
    이 건에 대한 다른 기사임

    • “개발자는 모범 관행을 써야 하지만 충분하지 않을 수도 있다. 데이터를 안전하게 지키는 것은 미해결 문제다”라니, 아 그렇구나. 어쩔 수 없겠네

  • 개인식별정보 저장을 핵폐기물 저장만큼 위험하게 만드는 법이 있었으면 함. 유출되면 회사는 거의 확실히 파산하고, 책임자들은 법적 위험에 처해야 함
    인센티브를 제대로 맞추는 가장 좋은 방법이 이거라고 봄. 지금은 사용자 정보를 가능한 한 많이 저장하는 데 따른 단점이 거의 없음. 데이터 유출? 사과 트윗 하나 올리고 계속 가면 됨

    • 개인식별정보를 핵폐기물처럼 취급하자는 건 조금 극단적이라고 봄. 개인식별정보에는 인증과 연락 목적의 이메일 주소처럼 비교적 무해한 데이터도 포함됨
    • 화이트칼라 감옥이 필요할지도 모르겠음
      그래야 이 문제가 마땅히 받아야 할 주목을 받을 수 있을 듯함

  • “아무 응답도 받지 못했다”면, 침묵이 계속되면 90일 뒤 취약점을 공개하겠다고 알릴 때임

    • 그건 회사보다 무고한 사용자에게 더 큰 처벌이 됨
    • 여기에는 취약점이라고 할 것도 없음. 그냥 대놓고 열려 있는 상태임
    • 그렇게 하면 소송당하고 형사 고발까지 당하기 좋은 길임
답변달기