# 나는 취약점을 발견했다. 그들은 변호사를 찾았다 > Clean Markdown view of GeekNews topic #26866. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26866](https://news.hada.io/topic?id=26866) - GeekNews Markdown: [https://news.hada.io/topic/26866.md](https://news.hada.io/topic/26866.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-21T14:33:05+09:00 - Updated: 2026-02-21T14:33:05+09:00 - Original source: [dixken.de](https://dixken.de/blog/i-found-a-vulnerability-they-found-a-lawyer) - Points: 2 - Comments: 1 ## Topic Body - 다이빙 강사이자 플랫폼 엔지니어인 작성자가 **다이빙 보험사 회원 포털의 심각한 보안 취약점**을 발견함 - 포털이 **순차적 사용자 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년에도, **단순한 취약점 제보가 법적 위협으로 이어지는 현실**이 존재함 ## Comments ### Comment 51536 - Author: neo - Created: 2026-02-21T14:33:06+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47092578) - 다른 사람들도 **단조 증가하는 사용자 ID**를 찾아 테스트했다가 감옥에 간 사례가 있음 그런 식으로 테스트하는 순간 **CFAA 위반 위험**이 생김 이미 ID가 단조 증가하고 기본 비밀번호가 설정된 걸 알았다면, 그 시점에서 바로 취약점을 보고했어야 함 테스트를 실행한 순간 법을 어긴 셈이 될 수 있음 지금 글을 쓰는 건 사실상 자백과 같으니, 변호사를 선임하고 관련 법을 공부해야 함 - 법적 전문성은 없지만 세 가지 생각이 있음 1) **합법적 공개 절차**가 너무 어렵다면, 결국 범죄자를 통해서만 취약점을 알게 될 것임 2) 다른 산업처럼 건축가가 빌딩 결함을 발견했다고 소송당하는 구조라면 말이 안 됨. 다만 사이버 보안은 결함을 아는 것 자체가 위험을 높인다는 점이 다름 3) 무작위로 지나가던 사람이 감사를 하는 건 너무 불안정함. 웹사이트가 내 **PII(개인식별정보)** 를 요구한다면, 나는 그 정보의 보안을 요구할 권리가 있어야 함 보험사 같은 곳은 반드시 사이버 감사를 받도록 법으로 정하고, 화이트햇 해커를 보호하며, 사용자들이 집단소송을 할 수 있게 해야 함 그렇게 되면 기본적인 취약점이 사라지고, 변호사보다 소프트웨어 엔지니어가 더 경제적인 존재가 될 것임 - 다른 산업에는 법적 책임을 지는 **전문 엔지니어 제도**가 있음 CS 분야도 AI 시대에 이런 방향으로 갈지 궁금함 전문 엔지니어는 설계 승인과 검사를 담당하며, 안전을 보장하는 핵심 역할을 함 그만큼 권한과 책임이 크고, 보수도 높음 - 다른 산업에서는 설계자가 **보험과 면허**를 가지고 있음 초보 개발자의 오픈소스 활동을 막고 싶진 않지만, 대규모 개인정보나 돈을 다루는 사이트는 **인증된 소프트웨어 엔지니어**가 서명하도록 해야 한다고 생각함 그래야 경영진의 무리한 요구를 막을 힘이 생김 물론 Boeing이나 Volkswagen 사례를 보면 완벽한 해결책은 아님 - 어떤 나라에서는 **진실이라도 명예훼손**이 될 수 있음 즉, 당국에 보고하는 것과 언론에 공개하는 건 전혀 다른 문제임 특히 **몰타** 같은 곳에서는 조직범죄와 부패가 심해, 이런 일을 공개한 사람은 ‘우연한 사고’를 당할 수도 있음 - 나는 각 서비스마다 다른 이메일 주소를 씀 15년 전쯤 **diversalertnetwork** 주소로 스팸을 받기 시작했음 DAN에 침해 사실을 알렸더니, 비밀번호 변경 안내 메일만 받았음 형사 고소를 당하지 않은 게 다행이라고 생각함 - 그건 해킹이었거나, 회사가 **제3자에게 데이터를 판매**했을 수도 있음 - 나도 비슷한 경험이 있음. 포르투갈 항공사 전용 이메일로 스팸이 오기 시작했는데, 회사는 아무 답도 안 했음 - 작성자가 조직 이름을 밝히길 두려워하는 걸 보면, **법적 위협이 효과적이었다**는 뜻임 - 혹은 다이빙 커뮤니티에서는 “몰타에 본사를 둔 다이버 보험사”라는 표현만으로도 **DAN Europe**을 암시하는 것일 수 있음 - 글의 단서들을 보면, 국제 다이빙 보험사 중 몰타에 등록된 곳은 **DAN Europe**뿐이라 거의 확실함 - 물론, 그가 얻은 정보를 **블랙햇에게 팔았을 가능성**도 배제할 수 없음 - “데이터 삭제 확인서에 서명하라”는 요구에 대해, 왜 서명했는지 의문임 회사는 협력보다는 **통제**를 원한 것처럼 보임 - 하지만 상대가 내 조건에 동의하게 만들면, 그들의 통제 전략을 무력화하고 **법적 구속력**을 갖게 됨 - 보안 연구자들이 취약점을 보고했다가 **법적 위협을 받는 패턴**은 수십 년째 반복되고 있음 정부와 기업은 사이버보안의 중요성을 말하지만, 실제로는 연구자에게 적대적임 이런 부당한 대응을 막는 **입법**이 필요함 관련 사례는 [이 링크](https://news.ycombinator.com/item?id=46814614)에서 볼 수 있음 - 혹시 이 사건의 대상이 **DAN Europe**과 그 자회사 **IDA Insurance Limited**인지 궁금함 - 다른 댓글에서 이미 그렇게 추론했음 - 독일에서는 이런 식으로 스크립트를 돌려 다른 사람의 데이터를 접근하는 건 **불법**임 남의 차 문이 열려 있다고 해서 들어가 시동을 걸 수 없는 것과 같음 관련 법적 해설은 [이 글](https://www.nilsbecker.de/rechtliche-grauzonen-fuer-ethische...) 참고 - 그렇다면 법이 바뀌어야 함. 이런 수준의 보안 무관심은 **선의의 제보자**나 **대형 유출** 없이는 절대 개선되지 않음 - 나도 동의함. 어디서 멈춰야 할지 알아야 함 사이트를 정상적으로 사용하는 범위 내에서 스크린샷을 찍고 보고하는 건 괜찮지만, **파이썬 스크립트로 데이터 수집**을 하면 선을 넘는 것임 마치 은행 문이 열려 있는 걸 보고 경찰에 신고하는 대신 안으로 들어가는 것과 같음 - 범죄자가 그 틈을 악용하지 않기를 바람 - 작년에 한 대형 행사 티켓 시스템에서 취약점을 발견했음 이메일로 받은 티켓 링크가 **순차적인 주문번호의 base64 인코딩**이었음 즉, 다른 사람의 티켓도 쉽게 다운로드할 수 있었음 주최 측과 개발사에 메일을 보냈지만 아무 반응도 없었고, 지금도 그대로 열려 있음 올해 행사 때 고쳐졌는지 지켜볼 예정임 - 사용자 ID가 순차적이고 기본 비밀번호가 동일했다면, 진짜 취약점은 **“보안 담당자가 존재한다는 가정”** 이었음 요즘 ‘책임 있는 공개’란 결국 **회사가 변호사를 고용할 시간을 벌어주는 일**에 불과함