라떼군 이야기
"취약점을 제보했더니 변호사가 찾아왔습니다": 보안 제보가 법적 협박으로 돌아온 이야기
TL;DR 한 엔지니어가 다이빙 보험사의 치명적인 보안 허점(순차적 ID와 공통 비밀번호)을 발견하고 책임감 있게 제보했으나, 회사는 감사 대신 법적 대응을 예고하며 침묵을 강요했습니다. 심지어 회사는 보안 실패의 원인을 ‘비밀번호를 바꾸지 않은 사용자 탓’으로 돌리는 적반하장의 태도를 보였습니다.
보안 취약점을 발견했을 때 기업은 어떻게 반응해야 할까요? 이상적으로는 제보자에게 감사하고 신속히 문제를 해결해야 하지만, 현실은 그렇지 않은 경우가 많습니다. 다이빙 강사이자 플랫폼 엔지니어인 필자가 겪은 이번 사건은 기업이 보안 이슈를 기술적 개선의 기회가 아닌 ‘법적 리스크’로만 해석할 때 어떤 일이 벌어지는지, 그리고 그것이 왜 위험한지를 적나라하게 보여줍니다.
핵심 내용
필자는 보험사 포털이 순차적인 숫자 ID(예: 1001, 1002…)와 모든 계정에 동일한 ‘기본 비밀번호’를 사용하고 있어, 누구나 타인의 민감한 개인정보(미성년자 포함)를 볼 수 있다는 사실을 발견했습니다. 그는 표준 절차에 따라 몰타 당국(CSIRT)과 회사에 제보했으나, 회사는 당국에 신고했다는 이유로 ‘불공정한 책임’을 언급하며 형사 고발 가능성을 시사했습니다. 그들은 제보자에게 사실 발설 금지(NDA) 서명을 강요했고, 심지어 “비밀번호를 변경하지 않은 것은 사용자 책임"이라며 GDPR의 기본 원칙인 ‘설계에 의한 프라이버시(Privacy by Design)‘를 정면으로 부정했습니다.
기술적 인사이트
기술적으로 이 취약점은 가장 기초적인 수준의 실패인 IDOR(부적절한 접근 제어)와 하드코딩된 자격 증명의 결합입니다. 하지만 더 중요한 기술적/윤리적 인사이트는 ‘책임감 있는 공개(Responsible Disclosure)‘를 대하는 기업의 태도에 있습니다. 시스템이 강제하지 않은 보안 조치(비밀번호 변경)의 책임을 사용자에게 전가하는 것은 현대 보안 엔지니어링 원칙에 위배됩니다. 또한, 제보자를 위협하여 입을 막으려는 시도는 단기적으로는 평판을 방어하는 것처럼 보일지 모르나, 장기적으로는 ‘화이트해커’들의 제보 의지를 꺾어 기업을 실제 악의적인 공격에 더 취약하게 만드는 결과를 초래합니다.
시사점
개발자들에게는 사용자 ID에 예측 가능한 순차적 정수 대신 UUID를 사용하고, 초기 비밀번호는 반드시 첫 로그인 시 변경하도록 강제해야 한다는 명확한 교훈을 줍니다. 기업 경영진과 법무팀에게는 보안 제보자를 잠재적 범죄자가 아닌 협력자로 인식해야 함을 시사합니다. 법적 위협으로 입을 막으려는 시도는 ‘스트라이샌드 효과’를 불러일으켜, 오히려 기업의 기술적 무능함과 비윤리적 태도를 전 세계에 알리는 결과를 낳을 수 있습니다.
“우리는 취약점을 찾았고, 그들은 변호사를 찾았다"는 제목이 시사하듯, 선의의 제보자가 법적 위험을 감수해야 하는 현실은 여전히 씁쓸합니다. 여러분의 조직은 보안 제보를 받으면 ‘감사합니다’라고 말할 준비가 되어 있나요, 아니면 변호사를 부를 준비가 되어 있나요?