티빙 3954만 계정 유출…문제는 '해킹 기술'이 아니라 내부 통제였다

온라인동영상서비스(OTT) 티빙(TVING)에서 발생한 개인정보 유출 사고의 구체적인 원인이 드러났다. 공격자가 개발자의 접속키 하나를 확보한 뒤 개발환경을 거쳐 실제 서비스 운영환경과 개인정보 데이터베이스까지 단계적으로 침투한 것으로 조사됐다.

특히 이번 사고는 알려지지 않은 고난도 취약점 하나가 뚫리면서 발생한 사고라기보다 접속키 관리, 접근권한 통제, 비정상 행위 탐지, 로그 관리, 보안인력 운영 등 기업이 기본적으로 갖춰야 할 정보보호 체계가 여러 단계에서 동시에 작동하지 않은 사고라는 점에서 무겁게 볼 필요가 있다.

과학기술정보통신부 민관합동조사단은 3일 티빙 침해사고 조사 결과를 발표하고 활성화 계정과 휴면·탈퇴 계정 등을 포함해 총 3954만 개의 계정 정보가 유출된 것으로 확인했다고 밝혔다. 다만 동일인이 여러 계정을 보유한 경우가 포함돼 있어 이를 실제 피해자 3954만 명으로 해석해서는 안 된다. 한 이용자가 최대 13개 계정을 보유한 사례도 확인됐으며 정확한 개인정보 유출 인원은 개인정보보호위원회의 추가 조사를 통해 확정될 예정이다.

유출된 계정은 로그인 가능한 활성화 계정 약 2206만 개, 휴면 계정 약 850만 개, 탈퇴 계정 약 887만 개, 테스트 계정 약 11만 개다.

유출된 정보는 아이디와 성명, 생년월일, 휴대전화번호, 이메일 주소, 연계정보(CI) 등 20개 항목, 70종에 이른다. 비밀번호와 환불 계좌번호는 암호화된 상태로 유출됐으며 비밀번호는 평문 복호화가 불가능한 형태였던 것으로 조사됐다. 반면 일부 휴대전화번호와 이메일 주소는 암호화된 데이터와 암호화키가 함께 유출돼 공격자가 복호화할 수 있는 상태였다. 조사단은 이를 사실상 평문이 유출된 것과 같은 수준으로 판단했다.

개발자 접속키 하나에서 시작된 연쇄 침투

공격은 개발환경에서 시작됐다. 조사단에 따르면 공격자는 5월 29일부터 31일 사이 티빙 개발자가 보유하고 있던 '개발환경 접속키'를 사전에 탈취해 개발환경에 무단 접속했다.

이후 개발 프로젝트 361건, 약 30.35GB를 외부로 빼냈다. 유출된 프로젝트에는 이용자 맞춤형 콘텐츠 추천과 검색 알고리즘, 이용자 인증체계, 결제 관리, 유료서비스 운영과 관련된 소스코드 등 티빙의 핵심 기술자산이 포함돼 있었다.

문제는 그다음이었다. 유출된 소스코드 내부에는 실제 서비스 운영환경으로 접근할 수 있는 접속키들이 포함돼 있었다. 조사 결과 운영환경 접속키 43개가 소스코드에 존재했으며 공격자는 이 가운데 2개를 이용해 아마존웹서비스(AWS) 기반 운영환경으로 침투했다.

접속키는 별도의 안전한 저장소에서 관리되지 않았다. 일부는 소스코드에 그대로 적어 놓는 이른바 '하드코딩(hardcoding)' 방식으로 저장돼 있었고 일부 설정값 역시 별도의 암호화 없이 평문으로 관리됐다. 사내 메신저를 통한 접속키 공유 사례도 확인됐다.

개발환경과 운영환경을 분리하는 마지막 방어선도 제대로 작동하지 않았다.

이용자 개인정보가 저장된 DB 접속 아이디와 비밀번호까지 암호화되지 않은 평문 상태로 저장돼 있었다. 공격자는 운영환경에 진입한 뒤 이 정보를 확보해 개인정보 DB까지 접근할 수 있었다.

결과적으로 개발자 접속키 하나가 유출되자 개발 프로젝트 전체와 운영환경, 개인정보 DB까지 차례로 길이 열렸다. 보안에서는 하나의 계정이나 인증정보가 탈취되더라도 다음 시스템으로 이동하지 못하도록 권한을 제한하는 것이 기본 원칙이다. 이번 사고에서는 이런 다중 방어 구조가 제대로 작동하지 않았다.

첫 공격 막았지만 다음날 다시 뚫렸다

공격자가 처음부터 개인정보를 빼내는 데 성공한 것도 아니다.

5월 30일 공격자가 DB에서 대량의 정보를 가져가려 하자 DB 서버의 CPU 이용률이 100%까지 올라가면서 이상징후 알림이 발생했다. 티빙은 해당 작업을 차단했다.

문제는 이후 대응이었다. 공격자는 다음날인 31일 다른 운영환경 접속키를 이용해 다시 내부에 들어왔다. 이번에는 CPU 사용률이 크게 올라가지 않도록 작업량을 조절하면서 별도의 가상서버를 생성했다. 이후 약 24GB 규모의 이용자 정보를 가상서버에 저장한 뒤 외부 서버로 전송하고 흔적을 지우기 위해 해당 가상서버까지 삭제했다.

첫 번째 대량 조회 시도가 서버 부하로 탐지됐음에도 공격자의 권한과 이동 경로, 관련 접속키를 즉시 차단하지 못하면서 다음 공격을 허용한 셈이다.

단순한 CPU 사용량 이상 감지에 의존하고 네트워크와 데이터 흐름, 대량 DB 조회, 비정상 계정 사용 등을 실시간으로 탐지하고 차단하는 체계가 충분하지 않았다는 조사단의 지적이 나온 이유다.

2024년 이미 취약점 발견…개선하지 않았다

이번 조사에서 가장 비판적으로 봐야 할 부분은 티빙이 사고 이전부터 관련 문제를 알고 있었다는 점이다.

조사단에 따르면 티빙은 2024년 실시한 모의해킹에서 개발·운영환경 접속키가 소스코드에 그대로 포함되는 하드코딩 취약점을 이미 발견했다.

하지만 해당 문제에 대한 실질적인 개선 조치는 이루어지지 않았다. 결국 공격자는 사고 당시 소스코드에 남아 있던 운영환경 접속키를 이용해 실제 서비스 영역까지 침투했다.

보안 취약점은 발견하는 것보다 발견 이후 어떻게 조치했는지가 더 중요하다. 모의해킹에서 실제 공격으로 연결될 수 있는 문제를 찾아놓고도 장기간 방치했다면 이번 사고를 단순한 외부 공격자의 기술력만으로 설명하기 어렵다.

접근권한 설계 역시 허술했다. 모든 개발자가 전체 개발 프로젝트에 접근할 수 있는 구조가 운영된 것으로 조사됐다. 한 개발자의 접속키가 탈취됐을 때 피해가 해당 개발자의 업무 영역에서 끝나지 않고 전체 개발 프로젝트로 확산될 수 있었던 배경이다.

정보보호 인력도 조직 규모에 비해 충분했는지 따져볼 문제다. 조사 결과 티빙은 전체 임직원 265명, 개발인력 149명 규모였지만 외주인력을 제외한 정보보호 전담인력은 4명 내외였던 것으로 파악됐다.

시스템 로그 관리에도 허점이 있었다. 일부 신규 VPN 장비에는 6일 정도의 접속기록만 남아 있었던 것으로 조사됐다. 침해사고가 발생했을 때 최초 침투 경로와 공격자의 행위를 추적하려면 충분한 기간의 로그가 필요하지만 이를 확보하지 못하면 사고 원인 규명 자체가 어려워진다.

실제로 조사단은 개발자 단말기 9대를 포렌식(디지털 증거 분석) 분석하고 피싱, 악성코드 감염, 공급망 공격, 접속키 오남용, 취약점 악용 등 여러 가능성을 조사했지만 공격자가 최초 개발환경 접속키를 어떤 방식으로 탈취했는지는 확인하지 못했다. 현재 공격자와 유출 정보가 전송된 정확한 국가·서버 등에 대해서는 경찰 수사가 진행되고 있다.

사고 인지 후 신고도 늦어

침해사고 신고 과정에서도 문제가 확인됐다.

과기정통부는 티빙이 사고를 인지한 시점을 5월 31일 오전 10시 10분으로 판단했다. 그러나 한국인터넷진흥원(KISA)에 침해사고를 신고한 시점은 6월 1일 오후 3시 8분이었다.

정보통신망법은 침해사고를 인지한 경우 24시간 이내 신고하도록 하고 있다. 과기정통부는 티빙이 법정 신고기한을 넘긴 것으로 보고 최대 3000만 원의 과태료를 부과할 예정이다.

개인정보 유출과 관련해서는 개인정보보호위원회가 별도 조사를 진행 중이다. 개인정보위는 지난 6월 3일 티빙으로부터 유출 신고를 접수한 뒤 안전조치 의무와 개인정보 유출 통지·신고 의무 등 개인정보보호법 위반 여부를 조사하고 있다. 따라서 최종 개인정보 유출 인원과 티빙에 대한 개인정보보호법상 제재는 아직 확정되지 않았다.

티빙 "정보보호 투자 4배 확대"…고객 보상책도 발표

티빙은 정부 조사 결과가 발표된 3일 오후 공식 사과하고 보안 강화 대책과 고객 보상 방안을 공개했다.

티빙은 2030년까지 정보보호 투자를 직전 5년 대비 4배 수준으로 확대하고 제로 트러스트(Zero Trust) 기반 접근통제 체계를 구축하겠다고 밝혔다. AI 기반 이상징후 탐지와 실시간 대응체계를 고도화하고 CEO 직속 정보보호혁신 자문위원회를 신설하는 방안도 내놨다.

피해 고객에게는 해킹·피싱 등에 따른 사이버 금융사기를 1인당 최대 300만 원까지 보상하는 1년간의 안심보험과 5000원 상당의 티빙 포인트 등을 제공한다. 보상 패키지는 9월 7일부터 30일까지 신청을 받아 10월 6일부터 적용할 예정이다.

보안투자 확대와 피해자 지원은 필요한 조치다. 하지만 이번 사고에서 더 중요하게 봐야 할 것은 사고 이후 얼마를 투자하겠다는 약속보다 사고 이전의 보안 위험이 왜 방치됐는지를 밝히는 일이다.

2024년 모의해킹에서 이미 접속키 하드코딩 문제가 발견됐다. 접속키와 DB 접속정보는 평문으로 관리됐고 접근권한은 넓게 부여됐다. 첫 번째 대량 개인정보 조회가 시스템 부하를 일으켜 차단됐음에도 다음날 공격자의 우회 공격을 막지 못했다.

각각의 문제만 놓고 보면 새로운 보안기술이 있어야 발견할 수 있는 영역도 아니다. 자격증명 관리, 최소권한, 로그 보관, 대량 데이터 반출 탐지, 모의해킹 결과에 대한 후속조치 등 기본적인 정보보호 관리 영역에 속한다.

이번 사고를 단순히 "해킹을 당한 사고"로 정리해서는 안 되는 이유다.

공격자는 결국 기업 내부에서 열려 있는 길을 따라 움직였다. 최초 개발 접속키 탈취 경로는 아직 밝혀지지 않았지만 접속키 하나가 탈취된 이후 개발환경과 운영환경, 개인정보 DB까지 연속적으로 침투할 수 있었던 구조는 티빙이 관리해야 할 영역이었다.

정보보호 투자를 몇 배 늘릴 것인지도 중요하지만 앞으로는 발견된 취약점이 실제로 개선됐는지, 개발·운영환경의 자격증명이 안전하게 분리·관리되는지, 개발자 권한을 최소화했는지, 대규모 개인정보 조회와 반출을 실시간으로 탐지할 수 있는지 등을 외부에서도 검증할 수 있어야 한다.

3954만 개라는 숫자보다 더 주목해야 할 부분은 '왜 한 번의 접속키 탈취가 이처럼 큰 사고로 확대될 수 있었느냐'는 질문이다.

개인정보보호위원회의 최종 조사에서는 정확한 피해 규모뿐 아니라 탈퇴·휴면 계정을 포함한 개인정보 보관의 적정성, 접근통제와 암호화키 관리, 사고 대응 과정에서 개인정보보호법상 안전조치 의무가 제대로 이행됐는지도 면밀하게 확인할 필요가 있다.