이준석 "쿠팡 사태, 안일한 보안 아키텍처가 불러온 인재"
"대학교 2학년 수업에서 알려주는 설계 원칙 간과"
이준석 개혁신당 대표는 2일 쿠팡의 수천만명 개인정보 유출 사태와 관련, "안일한 보안 아키텍처가 불러온 예견된 인재(人災)임이 오늘 질의를 통해 명확히 드러났다"고 밝혔다.
이 대표는 이날 페이스북을 통해 "오늘 과방위 질의를 통해 쿠팡의 인증 키 유출이 왜 수천만명 규모의 대규모 개인정보 유출로 이어졌는지 규명해냈다"며 이같이 말했다.
그러면서 "시작은 키 탈취였지만 그 키를 만능키로 만들어준 것은 잘못된 유저-인증시스템 설계였다"며 "대학교 2학년 수준의 수업에서 알려주는 설계 원칙을 간과했던 것"이라고 지적했다.
그는 구체적으로 "제가 쿠팡 CISO Brett Matthes와의 질의를 통해 파악한 바 적어보면 아래와 같다"며 조목조목 문제점을 지적했다.
우선 "쿠팡 측은 처음에 '인증 토큰을 만드는 키(Key)가 탈취된 것이 문제'라고 해명했다"며 "하지만 저는 그 설명을 듣고 강한 의문이 들었다. '아무리 키가 털렸다 한들, 해커가 수천만 명의 사용자 계정을 뚫으려면 각 사용자의 이메일 주소를 다 알고 있어야 대입해 볼 수 있는 것 아닌가? 그 방대한 이메일 리스트는 애초에 어떻게 확보했는가?' 이 의문을 풀기 위해 질의를 이어갔고, 결국 쿠팡 보안 시스템의 치명적인 구조적 결함 두 가지를 밝혀냈다"고 말했다.
첫째, "이메일이 아니라 '1, 2, 3...' 숫자만 알면 됐다. 확인 결과, 쿠팡은 내부 데이터베이스의 사용자 식별값(Primary Key)을 암호화된 난수나 랜덤 값이 아닌, 순서대로 1씩 늘어나는 정수(Auto Increment Integer)로 설정해두고 있었다. 즉, 해커는 굳이 이메일을 알아낼 필요가 없었다. 그저 숫자 1부터 차례대로 대입만 하면, 모든 사용자의 계정을 특정할 수 있었던 것"이라며 "만약 이를 예측 불가능한 값으로만 설계했더라도, 키가 탈취된 것만으로는 수천만 명의 정보가 통째로 털리는 일은 막을 수 있었을 것"이라고 지적했다.
둘째, "내부에서만 써야 할 문이 밖으로 열려 있었다. 숫자(PK)만 넣으면 인증 토큰을 내어주는 이런 API는, 보통 시스템 내부의 마이크로서비스(Microservices) 간 통신에나 사용되어야 하는 것"이라며 "서로 신뢰하는 내부 서버끼리만 쓰고 닫아뒀어야 할 이 API가, 황당하게도 일반 인터넷에서 누구나 접근 가능한(Public) 상태로 열려 있었다"고 지적했다.
그는 "결국 이번 사태는 단순한 '관리자 키 분실' 사고가 아니다. "누구나 예측 가능한 번호표를 달아놓고, 직원 전용 출입구를 활짝 열어둔 것"과 다름없는, 안일한 보안 아키텍처가 불러온 예견된 인재(人災)임이 오늘 질의를 통해 명확히 드러났다"며 "국민의 데이터를 다루는 거대 플랫폼이 이런 기초적인 보안 설계를 놓치고 있었다는 점, 매우 뼈아픈 대목이다. 끝까지 책임을 묻고 근본적인 대책을 챙기겠다"고 했다.
이 대표는 이날 페이스북을 통해 "오늘 과방위 질의를 통해 쿠팡의 인증 키 유출이 왜 수천만명 규모의 대규모 개인정보 유출로 이어졌는지 규명해냈다"며 이같이 말했다.
그러면서 "시작은 키 탈취였지만 그 키를 만능키로 만들어준 것은 잘못된 유저-인증시스템 설계였다"며 "대학교 2학년 수준의 수업에서 알려주는 설계 원칙을 간과했던 것"이라고 지적했다.
그는 구체적으로 "제가 쿠팡 CISO Brett Matthes와의 질의를 통해 파악한 바 적어보면 아래와 같다"며 조목조목 문제점을 지적했다.
우선 "쿠팡 측은 처음에 '인증 토큰을 만드는 키(Key)가 탈취된 것이 문제'라고 해명했다"며 "하지만 저는 그 설명을 듣고 강한 의문이 들었다. '아무리 키가 털렸다 한들, 해커가 수천만 명의 사용자 계정을 뚫으려면 각 사용자의 이메일 주소를 다 알고 있어야 대입해 볼 수 있는 것 아닌가? 그 방대한 이메일 리스트는 애초에 어떻게 확보했는가?' 이 의문을 풀기 위해 질의를 이어갔고, 결국 쿠팡 보안 시스템의 치명적인 구조적 결함 두 가지를 밝혀냈다"고 말했다.
첫째, "이메일이 아니라 '1, 2, 3...' 숫자만 알면 됐다. 확인 결과, 쿠팡은 내부 데이터베이스의 사용자 식별값(Primary Key)을 암호화된 난수나 랜덤 값이 아닌, 순서대로 1씩 늘어나는 정수(Auto Increment Integer)로 설정해두고 있었다. 즉, 해커는 굳이 이메일을 알아낼 필요가 없었다. 그저 숫자 1부터 차례대로 대입만 하면, 모든 사용자의 계정을 특정할 수 있었던 것"이라며 "만약 이를 예측 불가능한 값으로만 설계했더라도, 키가 탈취된 것만으로는 수천만 명의 정보가 통째로 털리는 일은 막을 수 있었을 것"이라고 지적했다.
둘째, "내부에서만 써야 할 문이 밖으로 열려 있었다. 숫자(PK)만 넣으면 인증 토큰을 내어주는 이런 API는, 보통 시스템 내부의 마이크로서비스(Microservices) 간 통신에나 사용되어야 하는 것"이라며 "서로 신뢰하는 내부 서버끼리만 쓰고 닫아뒀어야 할 이 API가, 황당하게도 일반 인터넷에서 누구나 접근 가능한(Public) 상태로 열려 있었다"고 지적했다.
그는 "결국 이번 사태는 단순한 '관리자 키 분실' 사고가 아니다. "누구나 예측 가능한 번호표를 달아놓고, 직원 전용 출입구를 활짝 열어둔 것"과 다름없는, 안일한 보안 아키텍처가 불러온 예견된 인재(人災)임이 오늘 질의를 통해 명확히 드러났다"며 "국민의 데이터를 다루는 거대 플랫폼이 이런 기초적인 보안 설계를 놓치고 있었다는 점, 매우 뼈아픈 대목이다. 끝까지 책임을 묻고 근본적인 대책을 챙기겠다"고 했다.
<저작권자ⓒ뷰스앤뉴스. 무단전재-재배포금지>








