KDFS 2015 챌린지 후기

요즘에 두 학회에서 디지털 포렌식 챌린지를 주최하고 있다. 하나는 사단법인 한국포렌식학회에서 하는 "디지털 범인을 찾아라” 이고, 다른 하나는 한국 디지털 포렌식 학회에서 하는 “KDFS Challenge” 이다. 이 두 챌린지는 다른 해킹대회처럼 어떠한 키를 찾는 것보다는 증거를 찾는 것도 중요하지만, 증거를 찾는 과정이 얼마나 논리적인지를 확인하는 것 또한 중요하게 생각하고 있다. 사실 이 쪽을 공부해본 사람들은 알겠지만 증거가 될만한 데이터를 찾더라도 해당 데이터가 증거라는 것을 입증하지 않으면 의미 없는 데이터가 되버리다보니 챌린지에서도 이러한 부분을 중요시하게 생각하는 것이 맞다. (기존 해킹 대회에 포렌식을 카테고리로 넣으면 안되는 이유이기도 하다. 특히 이 대회 때문에 사람들이 포렌식은 툴만 있으면 되는 줄 암..)
여튼 두 챌린지 중 한 챌린지는 작년부터 대회의 퀄리티 문제로 말이 많아서 해도 별로 보람도 없을 듯하여, 작년에 ‘고도화된 이벤트 로그 파서 개발’ 챌린지를 냈던 KDFS를 참여해봤다. 원래 팀 챌린지인데 팀 구하기도 그렇도 업무 외 시간에 짬내서 하다보니 중간에 포기할 수도 있다는 생각에 그냥 혼자했다. (근데 16개 팀이나 제출했다고하니 난 이번 챌린지는 망한 것 같다 ㅋㅋ)

블로그 타이틀에 후기라고 썼지만 후기만 쓰면 내용이 별랑 없다보니(위에랑 아래 있는 아쉬운 점이 다니..) 챌린지 보고서를 작성할 때 보통 보고서와 다르게 좀 더 신경쓴 부분이 뭐가 있었는지를 써 두었다. 이 글을 보고 다른 분들도 자신이 좀 더 고려한 부분을 댓글로 달아주시면, 언젠지 모를 또 다른 챌린지에서 잘 써먹도록 하겠다 ;-p

보고서 작성 시 고려한 사항

올해 챌린지는 IoT 장비 중에 우리가 가장 흔하게 볼 수 있는 공유기를 대상으로 하였다. 침해당한 공유기의 펌웨어 이미지를 제공하고 참여자는 이미지를 분석하여 제시된 문제를 푸는 것이였다. 하지만 단순히 답만 적어 내면 안되고 과정을 중요시 여기다보니 논리성을 많이 따졌다.

위처럼 문제를 다 풀더라도 답만 적어서 제출하면 40점으로 광탈하게 된다. (그냥 문제만 풀던 학생들에게는 좀 짜증날 수도 있겠지만 사실 이렇게 해야 포렌식 챌린지다.) 이 것 때문에 은근히 보고서에 시간 투자가 많이 이루어지게 된다. 그러다보니 문제를 푸는 것도 푸는 것이지만 보고서의 구성을 잡는 것도 중요했다. 어떻게 잡을까 생각하다가 일단 다음과 같이 구성해보기로 했다.

• 요약 : 본 챌린지에 대한 요약 내용을 작성한다. 챌린지에 대한 소개와 뒤에 상세 분석 보고서의 내용을 토대로 침해 당한 시스템이 어떠한 악의적인 행위를 할 수 있는지를 한 쪽 분량으로 작성하였다. 본 보고서의 소개라고할까나..
• 문제 풀이 : 각 문제를 쓰고 그에 대한 답변지를 작성하였다. 보통 보고서 내용에 대해 잘 알지 못하는 사람(보통 회사에선 상급자가 되겠지)이 보도록 작성할 경우에는 보는 사람에게 필요한 내용만 앞 부분에 2~3쪽 정도로 상세보고서 내용을 요약한다. 본 챌린지에서는 문제가 여러개이므로 문제 풀이만을 다루는 장을 상세보고서 요약본으로 대체하였다.
• 상세 보고서 : 앞에 두 장을 작성하는데 필요한 모든 수행 내용을 논리적인 순서에 맞춰 작성한 내용을 다룬다. (보통 이 부분은 상급자가 잘 안본다.) 본 챌린지에서는 분석에 사용한 도구 목록부터 시작해서 각 도구를 활용해 분석한 일련의 과정을 다룬다. 보고서에서 가장 많은 비중을 차지한다.

뒷 장으로 갈 수록 내용이 디테일하다보니 내용이 채워지는 순서는 뒤에서부터이다. 보고서 작성 과정에서 약어나 생소한 키워드가 있다면, 각주를 통해 내용의 의미를 작성하였다. 참고한 자료의 경우에는 레퍼런스 장을 따로 만들어서 관리할까하다가 겨우 두 개밖에 안되서 각주로 같이 처리해버렸다. (원래는 논문처럼 따로 장을 만드는게 깔끔해서 좋긴 함.)

챌린지 문제 풀이 시 고려한 사항

본 챌린지 문제는 여러 개지만 결국 마지막 문제를 풀기 위한 일련의 과정이라고 볼 수 있다. 문제는 다음과 같다.

펌웨어 내의 악성코드를 찾고 악성 파일의 행위를 분석한 후, 악성코드가 공유기에 로드되는 이유(펌웨어 체크 루틴 취약점)를 찾고, 해결 방안을 제시하는 과정이다. 챌린지 대상 장비가 세상에 하나만 있는 장비도 아니고, 펌웨어 이미지를 제공안하는 것도 아니다보니 문제 자체는 어렵지 않았다(라고 하지만 중간에 이상한데서 삽질함..). 그럼 그냥 풀고 이래이래 풀었다고 쓰면 땡인가? 싶을 수 있는데 그게 포렌식에서는 그렇지 않다. 예를 들어, 분석 시작 시나 분석 과정 중에 나오는 새로운 분석 파일에 대해서는 파일의 고유 값을 생성(예. 해시)하여 보고서에 기록해두는 것(단순히 파일 이름만으로 하면 동일 파일 명을 가지는 변종이 동일한 행동을 한다는걸 보장할 순 없지 않는가.) 뿐만 아니라, 분석에 사용된 도구에 대한 정보도 기록해주는 것이 좋다.

한가지 더 예를 들어보면, 4번 문제(대책 제시)의 경우에는 분석 결과 기존 검증 루틴이 워낙 취약하다보니 이를 해결할 수 있는 방법을 제시하는 것이였다. 이러한 문제는 그냥 해결 방안만 작성하는 것보다는 근거가 되는 자료를 먼저 설명하고 이를 바탕으로 한 대책을 제시하는 것이 좋다고 생각했다. 나같은 경우에는 미군 임베디드 시스템 내용을 다루는 사이트에서 수정된 펌웨어를 적용하지 않게 하는 방안을 작성한 내용과 영국의 전자기기 설계 관련 사이트에 올라온 안전한 펌웨어 배포 방안을 근거로하여 방안을 작성하였다. 적어도 보고서 내용의 논리성은 갖춰야한다는 말이다.

챌린지 내용과는 상관없을 수 있는 (하지만 중요한) 부분도 식별하여 작성하였다. 분석을 해본 사람은 알겠지만 분석 과정에서 특정 URL에서 파일을 다운로드하는 행위를 한다. URL을 알았는데 문제에 없다고 해서 해당 주소를 분석하지 않는 것은 좀 아닌 것 같아서 다운로드 하는 파일을 올린 사용자에 대한 정보와 시각 정보 등을 추가적으로 작성하였다. (원래 침해대응 보고서라면 써야되는 부분일테니 말이다..)

챌린지의 아쉬운 점

나는 이번 챌린지에 매우 만족한다. 맨날 한다한다하면서 안한 임베디드 기기 분석을 챌린지 덕분에 할 수 있었기 때문이다. 하지만 한가지가 아쉬웠다. 침해를 역추적 하는 내용이 빠진 것이다. 공격자가 어떻게 침투했고 어떤 자료를 유출했을 지, 공격자는 누구로 생각되는지 등과 같은 내용이다. 이 부분이 없다보니 분석 보고서를 쓰는 과정에서도 뭔가가 빠진 듯한 기분을 계속 느낄 수 있었다.
내년도 챌린지에서는 이 부분이 보강되어 좀 더 나은 문제가 나왔으면 하며, 끝으로 문제 출제를 위해 노력하고 지금도 보고서 검토하느라 바쁠 플레인비트와 에스엔티웍스 에 감사의 말을 전한다 :-)