1P by GN⁺ 18시간전 | ★ favorite | 댓글 1개
  • 다이빙 강사이자 플랫폼 엔지니어인 작성자가 다이빙 보험사 회원 포털의 심각한 보안 취약점을 발견함
  • 포털이 순차적 사용자 ID와 동일한 기본 비밀번호를 사용해, 누구나 단순한 조합으로 다른 회원의 개인정보에 접근 가능했음
  • 문제를 CSIRT Malta와 해당 기관에 동시에 신고했으나, 기관은 감사 대신 법률 대리인을 통해 형사 책임 가능성을 경고
  • 작성자는 비밀유지 서약(NDA) 요구를 거부하고, 데이터 삭제만 확인하는 수정 선언문을 제안했으나 기관은 명예 훼손 가능성을 이유로 재차 위협함
  • 사건은 책임 있는 취약점 공개 절차의 중요성과 법적 위협이 연구자 보호를 위축시키는 현실을 드러냄

취약점 발견

  • 코스타리카 코코스섬 다이빙 여행 중, 다이빙 보험사 회원 포털의 구조적 결함을 발견
    • 강사가 학생을 등록하면 시스템이 순차적 숫자 ID와 변경되지 않는 기본 비밀번호를 생성
    • 다수 사용자가 비밀번호를 변경하지 않아 다른 회원의 전체 개인정보(이름, 주소, 생년월일, 연락처 등)에 접근 가능
  • 비밀번호 변경 강제, 로그인 제한, MFA 등 기본 보안 조치가 전혀 없었음
  • 일부 계정에는 미성년자(14세) 의 정보도 포함되어 있었음
  • 작성자는 최소한의 접근으로 문제를 확인 후 즉시 중단하고, 모든 수집 데이터는 영구 삭제

검증 및 증명

  • Python requests로 시도했으나 세션 구조가 복잡해 Selenium을 이용한 브라우저 자동화로 검증
    • 단순히 사용자 ID와 기본 비밀번호를 입력하면 로그인 가능
    • 자동화 스크립트는 비기능적 예시 코드로 공개되어 있으며, 실제 식별자는 모두 삭제됨
  • 출력 예시에는 이름, 이메일, 주소, 생년월일 등 전체 프로필 데이터가 포함됨
  • 이 과정에서 여러 미성년자 계정이 동일한 방식으로 노출됨이 확인됨

취약점 공개 절차

  • 2025년 4월 28일에 취약점을 공식 보고하고, 30일의 수정 유예 기간을 설정
  • CSIRT Malta와 해당 기관에 동시에 이메일로 통보
    • 보고서에는 문제 요약, GDPR 위반 가능성, 스크린샷, 암호화된 PoC 링크 포함
    • 7일 내 접수 확인, 30일 내 수정 요청
  • 이는 국가 취약점 공개 정책(NCVDP) 에 부합하는 표준 절차

기관의 대응

  • 이틀 후, IT팀이 아닌 데이터 보호 담당 변호사(DPO 법률사무소) 로부터 회신
    • 비밀번호 초기화와 2FA 도입을 언급했으나, 정부 기관에 먼저 알린 점을 문제 삼음
    • 작성자의 행위가 몰타 형법상 범죄일 수 있다며 법적 책임 가능성을 경고
  • 기관은 비밀유지 선언문 서명을 요구하며, 여권 사본 제출과 당일 서명 기한을 제시
    • 선언문에는 “이 선언의 내용을 비밀로 유지한다”는 조항 포함, 사실상 NDA(비밀유지계약) 형태
  • 이후 “친절한 알림”, “긴급 알림” 등 반복적 서명 요청이 이어짐

연구자의 거부와 반박

  • 작성자는 비밀유지 조항 서명 거부, 대신 데이터 삭제 확인만 포함한 수정 선언문 제안
    • CSIRT Malta 통보는 공식 절차의 일부이며, 공개 후 분석은 보안 업계의 표준 관행임을 명시
  • 기관은 형법 제337E조(컴퓨터 남용) 를 인용하며, 해외에서 행해진 행위도 몰타 내 범죄로 간주될 수 있다고 경고
  • 또한 블로그나 컨퍼런스에서 기관명을 언급할 경우 명예 훼손 및 손해배상 청구 가능성을 통보
  • 현재 취약점은 수정되었으며, 기본 비밀번호 초기화 및 2FA 도입이 진행 중
  • 그러나 GDPR 제33·34조에 따른 피해자 통보 여부는 확인되지 않음

책임 전가와 GDPR 위반

  • 기관은 “비밀번호 변경은 사용자 책임”이라 주장
  • 그러나 GDPR 제5(1)(f)제24(1) 에 따라 데이터 컨트롤러가 적절한 기술·관리적 조치를 취해야 함
  • 동일한 기본 비밀번호와 순차적 ID는 명백히 부적절한 보안 조치에 해당

반복되는 패턴

  • 보안 연구자가 취약점을 책임 있게 공개하면 법적 위협을 받는 ‘냉각 효과(Chilling Effect)’ 가 여전히 존재
  • 법률 대응은 오히려 평판을 악화시키며, 문제는 취약점 자체가 아니라 조직의 대응 방식

올바른 대응 절차

  • 보고 접수 및 수정
  • 연구자에 대한 감사 표시
  • CVD(Coordinated Vulnerability Disclosure) 정책 수립
  • 피해 사용자 통보, 특히 미성년자 보호
  • NDA로 침묵 강요 금지

조직과 연구자를 위한 조언

  • 조직은 security.txt 등 명확한 공개 절차를 마련하고, 연구자에게 감사해야 함
  • 연구자는 국가 CSIRT 참여, 모든 기록 보존, 데이터 삭제 후 비밀유지 거부를 실천해야 함
  • NIS2 지침은 EU 내에서 책임 있는 취약점 공개를 장려함
  • 여전히 2026년에도, 단순한 취약점 제보가 법적 위협으로 이어지는 현실이 존재함
Hacker News 의견들
  • 다른 사람들도 단조 증가하는 사용자 ID를 찾아 테스트했다가 감옥에 간 사례가 있음
    그런 식으로 테스트하는 순간 CFAA 위반 위험이 생김
    이미 ID가 단조 증가하고 기본 비밀번호가 설정된 걸 알았다면, 그 시점에서 바로 취약점을 보고했어야 함
    테스트를 실행한 순간 법을 어긴 셈이 될 수 있음
    지금 글을 쓰는 건 사실상 자백과 같으니, 변호사를 선임하고 관련 법을 공부해야 함

  • 법적 전문성은 없지만 세 가지 생각이 있음

    1. 합법적 공개 절차가 너무 어렵다면, 결국 범죄자를 통해서만 취약점을 알게 될 것임
    2. 다른 산업처럼 건축가가 빌딩 결함을 발견했다고 소송당하는 구조라면 말이 안 됨. 다만 사이버 보안은 결함을 아는 것 자체가 위험을 높인다는 점이 다름
    3. 무작위로 지나가던 사람이 감사를 하는 건 너무 불안정함. 웹사이트가 내 PII(개인식별정보) 를 요구한다면, 나는 그 정보의 보안을 요구할 권리가 있어야 함
      보험사 같은 곳은 반드시 사이버 감사를 받도록 법으로 정하고, 화이트햇 해커를 보호하며, 사용자들이 집단소송을 할 수 있게 해야 함
      그렇게 되면 기본적인 취약점이 사라지고, 변호사보다 소프트웨어 엔지니어가 더 경제적인 존재가 될 것임
    • 다른 산업에는 법적 책임을 지는 전문 엔지니어 제도가 있음
      CS 분야도 AI 시대에 이런 방향으로 갈지 궁금함
      전문 엔지니어는 설계 승인과 검사를 담당하며, 안전을 보장하는 핵심 역할을 함
      그만큼 권한과 책임이 크고, 보수도 높음
    • 다른 산업에서는 설계자가 보험과 면허를 가지고 있음
      초보 개발자의 오픈소스 활동을 막고 싶진 않지만, 대규모 개인정보나 돈을 다루는 사이트는 인증된 소프트웨어 엔지니어가 서명하도록 해야 한다고 생각함
      그래야 경영진의 무리한 요구를 막을 힘이 생김
      물론 Boeing이나 Volkswagen 사례를 보면 완벽한 해결책은 아님
    • 어떤 나라에서는 진실이라도 명예훼손이 될 수 있음
      즉, 당국에 보고하는 것과 언론에 공개하는 건 전혀 다른 문제임
      특히 몰타 같은 곳에서는 조직범죄와 부패가 심해, 이런 일을 공개한 사람은 ‘우연한 사고’를 당할 수도 있음
  • 나는 각 서비스마다 다른 이메일 주소를 씀
    15년 전쯤 diversalertnetwork 주소로 스팸을 받기 시작했음
    DAN에 침해 사실을 알렸더니, 비밀번호 변경 안내 메일만 받았음
    형사 고소를 당하지 않은 게 다행이라고 생각함

    • 그건 해킹이었거나, 회사가 제3자에게 데이터를 판매했을 수도 있음
    • 나도 비슷한 경험이 있음. 포르투갈 항공사 전용 이메일로 스팸이 오기 시작했는데, 회사는 아무 답도 안 했음
  • 작성자가 조직 이름을 밝히길 두려워하는 걸 보면, 법적 위협이 효과적이었다는 뜻임

    • 혹은 다이빙 커뮤니티에서는 “몰타에 본사를 둔 다이버 보험사”라는 표현만으로도 DAN Europe을 암시하는 것일 수 있음
    • 글의 단서들을 보면, 국제 다이빙 보험사 중 몰타에 등록된 곳은 DAN Europe뿐이라 거의 확실함
    • 물론, 그가 얻은 정보를 블랙햇에게 팔았을 가능성도 배제할 수 없음
  • “데이터 삭제 확인서에 서명하라”는 요구에 대해, 왜 서명했는지 의문임
    회사는 협력보다는 통제를 원한 것처럼 보임

    • 하지만 상대가 내 조건에 동의하게 만들면, 그들의 통제 전략을 무력화하고 법적 구속력을 갖게 됨
  • 보안 연구자들이 취약점을 보고했다가 법적 위협을 받는 패턴은 수십 년째 반복되고 있음
    정부와 기업은 사이버보안의 중요성을 말하지만, 실제로는 연구자에게 적대적임
    이런 부당한 대응을 막는 입법이 필요함
    관련 사례는 이 링크에서 볼 수 있음

  • 혹시 이 사건의 대상이 DAN Europe과 그 자회사 IDA Insurance Limited인지 궁금함

    • 다른 댓글에서 이미 그렇게 추론했음
  • 독일에서는 이런 식으로 스크립트를 돌려 다른 사람의 데이터를 접근하는 건 불법
    남의 차 문이 열려 있다고 해서 들어가 시동을 걸 수 없는 것과 같음
    관련 법적 해설은 이 글 참고

    • 그렇다면 법이 바뀌어야 함. 이런 수준의 보안 무관심은 선의의 제보자대형 유출 없이는 절대 개선되지 않음
    • 나도 동의함. 어디서 멈춰야 할지 알아야 함
      사이트를 정상적으로 사용하는 범위 내에서 스크린샷을 찍고 보고하는 건 괜찮지만, 파이썬 스크립트로 데이터 수집을 하면 선을 넘는 것임
      마치 은행 문이 열려 있는 걸 보고 경찰에 신고하는 대신 안으로 들어가는 것과 같음
    • 범죄자가 그 틈을 악용하지 않기를 바람
  • 작년에 한 대형 행사 티켓 시스템에서 취약점을 발견했음
    이메일로 받은 티켓 링크가 순차적인 주문번호의 base64 인코딩이었음
    즉, 다른 사람의 티켓도 쉽게 다운로드할 수 있었음
    주최 측과 개발사에 메일을 보냈지만 아무 반응도 없었고, 지금도 그대로 열려 있음
    올해 행사 때 고쳐졌는지 지켜볼 예정임

  • 사용자 ID가 순차적이고 기본 비밀번호가 동일했다면, 진짜 취약점은 “보안 담당자가 존재한다는 가정” 이었음
    요즘 ‘책임 있는 공개’란 결국 회사가 변호사를 고용할 시간을 벌어주는 일에 불과함