또 한건의 대형 개인정보 유출사고가 발생했다. 그런데 해도 해도 너무한다. 이렇게 쉬운 방법으로 거대 통신사의 고객지원 웹사이트가 뚫리다니…. 지금껏 얼마나 많은 해커가 이 통신사의 개인정보를 무단으로 해킹해 유출시켰을지 모른다고 생각하니 참 한심하다 못해 어이가 없다. KT는 보안사고로 개인정보가 유출된 뒤 채 2년도 안돼 또 초대형 개인정보유출사고의 주범이 되는 불명예를 뒤집어 쓰게 되었다.
지금 KT 올레닷컴 사이트의 요금조회 페이지는 굳게 걸어닫혀 있다. 물론 죄송하단 안내 페이지는 열려있다.
굳게 닫혀있는 요금조회 및 개인정보 조회 페이지..
사실 KT 홈페이지가 해킹을 당해 1200만건의 개인정보가 유출되었다고 해서 “설마 올레 닷컴” 웹페이지일까 싶었다. 올레닷컴은 사실상 전국민이 사용하는 요금조회 및 개인정보 조회가 가능한 웹사이트다. 거의 전국민이 사용자다. KT는 유선과 무선의 통신서비스를 하고 있고 유선과 무선의 모든 고객과의 대화창구가 바로 “올레 닷컴”이다.
그런데 올레 닷컴에 접속해 보니 단번에 “아.. 올레 닷컴이 뚫렸구나..”라는걸 알 수 있었다. 아래의 메뉴들은 모두 접속이 불가능했다.
그렇다면 해커는 어떤 방법으로 올레닷컴에 접속해서 개인정보를 빼내간 것일까..??
경찰에서 발표한 바에 의하면 그 방법은 다음과 같다고 설명하고 있다.
해커들은 파로스 (Paros)라는 프로그램을 이용했다고 한다. 내 눈을 의심했다. paros는 웹 개발자들이 즐겨 사용하는 디버깅 도구이다. 그리고 이 디버깅 도구인 파로스를 이용해 “웹 브라우저에서 웹서버로 전송되는 데이터는 변조가 가능하다”라는 웹 취약점에 대한 공격 방법은 초보 개발자들도 알고 있는 “상식”이기 때문이다.
설마 KT가 그렇게 초보적인 공격에 조차 무방비인 상태로 올레닷컴 웹사이트를 그 오랜 시간동안 운영해 왔다는 말인가?
한심하다 못해 어이가 없어 할말을 잃을 지경이었다. 도대체 몇년 전 보안사고로 인해 새로 투자한 그 많은 돈은 어디로 갔단 말인가? 송소희양을 불러 “어이~없~소~~오~~ 어이~없~소~~~~”를 외치게 하고 싶다.
일부 언론에서 paros를 마치 강력한 해킹툴인 것 처럼 소개하고 있지만 paros는 주방도구인 “칼”과 같은 도구다. 개발에 사용하면 훌륭한 디버깅 도구로서 개발자들의 필수 소프트웨어이고 해킹에 사용하면 해킹을 도와주는 도구가 되는 “그냥 프로그램”일 뿐이다.
어찌됐든 Paros를 이용하여 해킹을 시도한 과정을 도식화 하면 다음과 같다.
해커의 해킹 과정을 위의 그림을 기준으로 설명하면 다음과 같다.
1. 해커는 올레 닷컴에 로그인 한다. 이때도 물론 남의 계정을 쓰지 않았을까 싶다.
2. 요금조회 및 개인정보 조회 페이지에서 로그인한 계정의 정보를 조회한다.
3. 해커는 미리 paros를 동작 시켜 웹브라우저에서 KT의 서버로 가는 요청(Request)을 가로채도록 설정(proxy)하고 paros에서 요청 (http request (get or post))을 가로채 요청 내에 있는 고객번호를 엉뚱한 고객번호로 변조한다. 경찰에 의하면 이 고객번호는 9자리의 번호로서 해커들은 무작위로 변조해 응답이 오는지를 확인했다고 한다.
4. paros에서 변조된 고객번호는 KT 서버로 넘어가 DB 에서 조회된다.
5. 응답은 웹브라우저로 전송된다. 이때 로그인한 고객 계정의 정보가 아니라 해커가 paros에서 변조한 고객번호의 정보다. 즉 피해자의 이름, 전화번호, 계좌번호 등이 되겠다.
6. 해커는 이과정을 자동화하는 간단한 프로그램을 작성해 매일 수만에서 수십만건씩 개인정보를 빼냈다.
사실 이런 방식의 해킹은 서버보안 관련 업무를 하고 있는 나로서도 참 난감할 수 밖에 없다. 웹페이지와 서버에서 구동되는 응용프로그램 소스코드 상의 취약성을 이용해 서버내의 파일이나 명령 등을 조작하지 않고 정삭적인 경로를 통해 정보만 빼내는 기법이기에 어찌할 도리가 없는 것이다. 서버보안 뿐만 아니다. 이러한 공격은 방화벽, 침입탐지시스템, DB보안솔루션, 웹 방화벽 등 다양한 보안장비를 갖추고 있어도 막을 도리가 없는 것이 현실이다. KT가 이런 보안 시스템을 도입하여 운영하고 있지 않았겠는가..?? (서버보안은 없는 걸로 알고 있지만…&nbs
해법은 개발자들이 시큐어코딩을 생활화 하는 것이다.
이런 공격에 대한 대응 방법은 웹페이지와 서버측의 조회 애플리케이션 소스 내부적으로 취약성을 제거하는 방법 밖에는 없는 것이 현실이다. 그래서 많은 보안 관련 단체나 정부 기관에서는 개발자들이 준수해야할 여러 프로그래밍 보안 기준들을 제시하고 있다.
그것이 바로 Secure Coding 이다. 여러 검색엔진에서 “시큐어코딩” 혹은 “secure coding”을 검색해 보면 다양한 자료들이 쏟아져나온다.
그리고 이미 정부에서는 시큐어코딩의 중요성을 인지하고 수년전부터 관련 컨퍼런스를 개최하는 등 방안 등을 수립하고 자체적으로 시큐어코딩 가이드 등을 제시하고 있다. 이와 관련하여 정리가 비교적 잘되어있는 블로그를 소개한다. (관련 링크)