지난 번 글에서, 리눅스 운영체제 상에서 메모리를 포렌식분석할 때 프로파일이 필요하다는 점을 설명하였다.

(참고 : 리눅스 메모리 분석시 프로파일 설정)


기본적으로 볼라틸리티를 설치하면 윈도우 관련 프로파일만 포함되어 있으며, 리눅스 쪽은 직접 구해야 한다. 다행히도 볼라틸리티 개발자들은 Github를 통해 많은 프로파일을 제공하고 있다. 그럼에도 불구하고 Linux의 경우 워낙 배포판의 종류가 많으므로 가장 대표적인 CentOS, Debian, Fedora, OpenSUSE, RedHat, Ubuntu 시스템 정도만 제공되고 있다. 또한 32bit용과 64bit 용을 구분하여 각 버젼별로 제공하고 있다.


그러나 유명 배포판 리눅스가 아닌 경우에는 어떻게 할 것인가? 


본 포스팅에서는 프로파일이 공개되어 있지 않은 임의의 리눅스에서 해당 시스템의 프로파일을 직접 만드는 방법을 다룬다.


우선 타겟으로 삼을 OS를 정하도록 하자. 이미 보편적으로 많이 사용되고 있는 리눅스라면 그냥 공식 깃허브에서 다운로드 할 수 있으므로, 되도록 아직까지 널리 알려지지 않은 리눅스 배포판으로 실험을 하여 성공하는 과정을 보여주고자 한다. 마침 한국시간으로 2017년 4월 26일 오늘, Kali Linux 2017.1  버전이 출시되었다.  다운로드 페이지에서 Kali Linux 설치 iso 를 다운로드하여 설치해보자. (자세한 설치 과정은 생략한다.) 필자는 kali-linux-2017.1-amd64.iso 파일을 기준으로 진행하였다.

사실 Kali Linux 사용이 목적이라면 그냥 VBox나 가상머신 형태로 제공되는 이미지를 통해 별다른 복잡한 설치과정 없이 바로 실행할 수 있다. 그러나 메모리 포렌식을 위한 테스팅 결과(필자는 이 글을 작성하며 최소 10번이상 재설치를 반복하였다), 외부에서 다운로드받은 VM이미지의 경우 메모리 추출에서 오류가 발생하는 경우가 잦았으며, 본인이 직접 OS부터 설치한 경우의 VM은 오류 발생 빈도가 현저히 적었다. 이것은 경험에 기초한 것이기 때문에 정확히 왜 그런지는 잘 모르겠다. 볼라틸리티 또는 LiME 의 문제점이거나, 가상화 소프트웨어의 문제일 수 있다. 

어쨌든 설치를 마쳤다. 보통은 초기설치시 root 패스워드를 설정하게 되어 있다. 만약 설정한 적이 없는데도 이미 root계정이 생성되어있다면 기본 비밀번호는 toor이다. 로그인해보자.

설치된 칼리 리눅스 2017 버전이 정상적으로 작동한다. 아마 현시점까지 칼리리눅스 2017에 대한 메모리 프로파일을 추출한 사람은 없을것이다. ㅋㅋ


자 그럼 시작해보자. 아래 명령어로 관련된 도구를 설치하자. 칼리 리눅스에는 관련 도구들이 이미 설치되어 있지만, 혹시 별도의 다른 리눅스로 수행하시는 분들은 아래의 패키지를 apt-get으로 설치하시면 된다. 만약 Debian/Ubuntu 계열이 아닌 Fedora 등의 리눅스라면 yum install 로도 설치가 가능하다.

다음으로 커널 모듈을 빌드하기 위한 header 정보가 필요하다. `uname -r`옵션을 사용하여 아래와 같이 입력하면 설치가 된다. (이미 설치되어 있다면 패스~)


이제 volatility 가 설치된 디렉토리 하위에서 tools을 확인하면 된다. 칼리리눅스에는 기본적으로 volatility가 설치되어 있기 때문에 /usr/share/volatility/tools/linux 의 경로로 가면 된다. 만약 git clone을 통해 직접 설치하였다면 해당 위치 기준으로 ~/volatility/tools/linux 의 경로에 있을 것이다.

해당 디렉토리에서 make 입력한다. 작업결과 module.dwarf 라는 파일이 생성된다. 이것은 일명 vtypes라고 부르며 해당 커널의 데이터구조에 관한 명세서이다. 


또한 분석할 커널에 대한 Symbol 정보를 담고 있는 System.map 파일이 필요하다. 해당 파일은 대부분 /boot/ 디렉토리에서 찾을 수 있으며, Kali linux의 경우 System.map-4.9.0-kali3-amd64 라는 이름으로 저장되어 있다. 각자가 테스트하는 환경에서 /boot/디렉토리에 있는 System.map 파일을 조사해보기 바란다. 


module.dwarf 파일과 System.map 파일을 모두 입수하였다면, 이것을 압축해야 한다. 압축은 커맨드라인에서 zip 명령어를 사용하고, 압축하고자 하는 파일들의 경로와 함께 입력하면 된다. 

위의 명령어를 실행한 결과 아래와 같이 Kali-Linux-2017.zip 이라는 파일이 생성되었다.

해당 파일을 분석하고자 하는 포렌식 워크스테이션으로 옮긴다. 파일전송은 sftp나 scp 프로토콜을 이용하면 되고, 네트워크 환경구축이 복잡한 경우 그냥 usb로 옮겨도 된다. 단, 실제 포렌식 상황이라면 무결성 훼손에 유의해야 하므로 주의할 것. 그리고 옮겨진 프로파일 파일의 해시값을 검사해서 확인하는 것도 좋을듯하다.


일반적으로 git을 통해 설치한 volatility 환경이라면 profile을 저장할 경로는 /volatility/volatility/plugins/overlays/linux/이다. 여기에 Kali-Linux-2017.zip 파일을 옮겨둔다. 별도로 압축을 해제할 필요없이 그냥 zip 상태로 두면 된다.


이제 volatility를 실행해서 --info 옵션으로 확인해보면, LinuxKali-Linux-2017x64 라는 새로운 프로파일이 정상적으로 추가되어있는 것을 확인할 수 있다.

이제는 본격적으로 메모리를 덤프하고, 해당 프로파일을 적용하여 포렌식을 수행하면 된다. 메모리를 덤프하는 방법은 [리눅스 포렌식 분석을 위한 메모리 추출 - LiME] 을 참고할 것.


이제 덤프한 파일에 방금 생성한 프로파일을 적용해서 메모리 포렌식을 해보자. 

그런데 필자가 며칠간 삽질하면서 겪어보니, 프로파일도 정상적으로 만들었고 덤프도 분명히 성공했는데 이상하게 볼라틸리티에서 분석이 되지 않는 경우가 자주 발생하였다. 구체적인 원인 파악을 위해 일주일동안 각종 Linux distro(Ubuntu 16.04, Kali 2017, Fedora, CentOS 등등)에 대해 노가다로 탐구를 해본 결과 볼라틸리티 기능에 버그가 있는 것을 알 수 있었다. 해당 부분에 대하여 volatility profiles 의 공식 github에 이슈를 제기하였고, 볼라틸리티의 핵심 개발자인 Andrew Case 등과 함께 논의하였다. 확인 결과 가상화 소프트웨어인 Virtual Box 등의 성능상 결함이 원인이 될 수 있다는 것을 확인하였고, VMware Workstation 등의 상용 VM을 사용하면 증상이 완화되는 것을 알 수 있었다. 또한, Linux Kernel 4.4 이후의 버전에서는 볼라틸리티의 소스코드 안에 DW_AT_byte_size를 체크하지 못하는 버그가 포함되어 있다는 것을 알 수 있었다. (참고 #1, #2) 해당 문제점을 패치하는 방법을 공개하고자 한다. (아마 향후에는 볼라틸리티에서 공식 패치가 나올 것으로 예상하지만, 현재의 2.6버전에서는 직접 패치해야 한다.)


다음과 같은 오류가 발생하면서 볼라틸리티에서 메모리 분석이 안되는 경우, DW_AT_declaration flag를 수정하여야 한다.

볼라틸리티가 설치된 디렉토리 안에서 /volatility/dwarf.py 파일을 수정하는 방법이다. 

204번째 줄의 코드를 (수정 전)

이렇게 수정한다(수정 후)

이렇게 수정하였다면 더이상 DW_AT_byte_size 관련한 KeyError는 발생하지 않을 것이다.


다만, 4.8 이상의 커널에서는 kernel address space layout randomization(이하 KASLR)이 적용되어서 현재 분석이 원활하지 않을 수 있다. 보통 이러한 문제의 경우 아래와 같은 메시지가 표출되며 분석이 진행되지 않는다.

이 문제를 해결하기 위한 Github Pull Request가 bneuburg라는 개발자의 주도로 진행 중이다. 관련해서는 Linux 4.8 KASLR support라는 게시물을 참고하면 좋겠다. bneuburg는 이 주제에 열정적인 노력을 다하여 관련된 전용 플러그인의 형태로 kaslr_shift.py을 개발하였다. 원래는 그 결과물을 Volatility Plugin Contest에 출품하려는 계획이었으나 올해 가을까지 공개를 늦춘다면 이 부분에서 손해를 보는 사람들이 많을 것이라 판단했는지 보다 일찍 코드를 공개한 것이라고 한다. 볼라틸리티 개발자인 Andrew Case가 매우 깊은 관심을 가지자, 기회가 된다면 논문등의 형식으로 제출할 예정이라고 답변하였다. 어쨌든, 조만간 이런 복잡한 삽질(?)을 하지 않고도 편리하게 이용할 수 있는 날이 머지않아 올 것 같다.


너무나 쉽게 생각하고 작성하던 글이 뜻밖의 버그를 만나서 일주일 이상 소요되고 말았다. 안타깝게도 현재 4.9 버전의 커널에 대한 메모리 포렌식 분석을 위한 준비과정이 상당히 쉽지 않은 상황이지만, Ubuntu 16.04와 Kali Linux 2017.01 버전에 대한 메모리 포렌식을 성공적으로 수행하였다.

Ubuntu 14.04 (Kernel 4.4)
Ubuntu 14.04 (Kernel 4.4)
Kali Linux 2017.1 (Kernel 4.9)
Kali Linux 2017.1 (Kernel 4.9)

추후 4.9 이상의 커널에서 보다 쉽게 볼라틸리티 분석이 가능한 방법이 나오면 본 포스팅을 다시 업데이트 하도록 하겠다.

CPUU님의 창작활동을 응원하고 싶으세요?