linux 에서 생성한 메모리 덤프 파일을 volatility 로 분석하기 :: profile 만들기, KASLR

이 글은

volatility 로 linux 파일 분석 시도 - linux 프로파일 만들기 - 그럼에도 생기는 문제[KASLR]

를 소개하며 해결하는 순서로 이루어진다.

 

 

volatility 로 메모리 덤프 파일을 분석하려면 해당 메모리 덤프 파일의 운영체제에 대한 프로파일이 있어야 한다.

volatility 에는 기본적으로 windows 에 대한 프로파일이 포함되어 있고,

windows 에 사용할 수 있는 플러그인들이 많기 때문에 기본적으로 메모리 덤프 파일 분석을 위해서라면 windows 가 더 수월할 수 있다.

 

그런데 나는 VMware 에 만든 가상머신이 Ubuntu 라서 그냥 그 머신의 메모리 덤프를 땄고,

분석하려고 시도하였다.

(그리고 매우 후회하였다)

 

해당 파일 이름은 file.vmem 이고 volatility 를 사용할 때 가장 기본적인 imageinfo 플러그인을 사용해서 어떤 운영체제인지 알려고 했으나,,,,

다음과 같은 메시지가 뜨고 종료되지 않았다.

해당 프로파일이 없어서 어떤 운영체제의 이미지 파일인지 검색을 못하고 있는 것이다.

 

 

그래서 처음에는 volatilityfoundation 에서 각종 프로파일을 제공하는 것 (github.com/volatilityfoundation/profiles 에서 보고 다운받을 수 있다)

을 찾아 다운받아서 실행하려고 했으나,

bash 버전 차이로 인해 제대로 작동하지 않았다.

결국 직접 프로파일을 만들기로 결정하였다.

 

 

----------Linux 프로파일 만들기---------

 

linux 프로파일은 module.dwarf 파일과 System.map 파일을 확보해서 압축하면 된다.

-module.dwarf : 커널의 데이터 구조에 대한 명세서. [volatility 를 통해 얻을 수 있음]

-System.map : 커널의 symbols 정보 [시스템 내에서 가지고 있음]

 

-기본 사항: volatility 가 설치되어 있어야 한다.

설치가 안되어있다면, 커멘트 창에서

$ git clone https://github.com/volatilityfoundation/volatility.git

 

 

-상세 과정:

1) 가상머신을 킨다.

2) volatility/tools/linux 폴더에서 make --> module.dwarf 파일 생성

$ cd volatility/tools/linux

$ make

3) uname(시스템 정보 출력) 확인 및 /boot 폴더에서 System.map 확인

$ uname -r

$ ls /boot

현재 시스템의 이름으로 되어있는 저 System.map 파일을 사용할 것이다.

 

4) zip 만들기 <최종>

$ zip [zipFileName].zip ./volatility/tools/linux/module.dwarf /boot/System.map-4.15.0-29-generic : 내 상황

$ zip $(lsb_release -i -s)_$(uname -r)_profile.zip ./volatility/tools/linux/module.dwarf /boot/System.map-$(uname -r) 

: 이 명령어를 그대로 쓰면 된다.

(lsb_release -i -s 은 리눅스 배포판 버전, uname -r 은 시스템 정보를 가져온다.)

 

이 명령어를 사용한 결과는 다음과 같고, Ubuntu_4.15.0-29-generic_profile.zip 파일이 생성되었다.

이제 프로파일이 생성된 것 !

 

-------------------------------------

 

 

생성한 프로파일 혹은 위의 volatilityfoundation 에서 제공하는 프로파일 zip 을 

C:\Python27\Lib\site-packages\volatility-2.6\volatility-master\volatility\plugins\overlays\linux

에 추가해주면 해당 버전의 리눅스에 대한 메모리 덤프 파일을 volatility 로 분석할 수 있게 된다.

(위의 경로는 사용자 설정마다 다를 수 있으니 전체적인 틀을 보고, 자신에 맞게 설정하면 된다.)

 

이 때 zip 파일을 그대로 넣으면 된다!

압축을 풀 필요 없음.

 

추가해준 후 volatility 에서 --info 를 통해 확인하면 성공적으로 프로파일이 적용됨을 확인할 수 있다.

(해당 프로파일 zip 파일 이름으로 출력이 된다.

위의 예시와는 다른 파일이니, 이 이미지는 성공적으로 프로파일을 추가했다는 것이라고 이해하면 된다.)

 

 

그런데 이렇게 했음에도 메모리 덤프 파일이 제대로 분석되지 않았다.

linux 플러그인을 (거의 모두) 사용해 보았음에도 아무런 결과가 나오지 않았다.

 

이유는 KASLR 때문이었다.. (정말 욕나올 뻔했다.)

 

 

---- KASLR: Kernel Address Space Layout Randomization ----

: kernel 의 이미지가 physical Memory 에 로딩되는 주소와 Virtual Address 로 매핑되는 주소를 각각 Randomize 해서 kernel 을 공격하는 해킹 기법으로부터 보호하는 수단

 

버전마다 KASLR 이 적용되는지 여부가 다르다.

 

1. KASLR 적용 여부 확인하기

 

$ sudo cat /proc/kallsyms

를 한 결과가 재부팅한 후에도 동일하면 KASLR 적용이 안되는 시스템이고, 다르면 KASLR 적용이 되는 시스템인 것이다.

 

kallsyms: Extract all kernel symbols for debugging

KASLR 가 적용된다면, kernel symbols 의 주소가 재부팅 후 달라지기 때문에 (KASLR 는 randomize 시키므로)

이를 통해 확인할 수 있다..

 

그러니 몇군데 주소를 캡쳐해두고 재부팅한 후, 그 부분의 주소를 확인하면 달라졌는지 쉽게 확인할 수 있다.

좌측: Before / 우측: After

나는 확인해본 결과, 위와 같이 주소가 달라짐을 확인 하고 절망 했다.

(그래도 다행히, 친구의 도움으로 해결할 수 있었다......!)

 

2. 해결: kernel parameter 에 nokaslr 추가하기

 

!!주의!!

kernel parameter 을 바꿀 때에는 주의해서 사용해야 하고,

이 포스팅에서 소개하는 방법은 현재 나의 시스템에 맞춘 것이니 자신의 시스템과 다르다면 더 알아보고 사용해야 한다.

그러니 KASLR 이 적용된 시스템의 해결 방법은 kernel parameter 에 nokaslr 을 추가하는 것이고

자신의 시스템에 맞춰서 kernel parameter 을 수정하여야 한다!

 

제대로 알아보지 않고 이 포스팅을 그대로 따랐다가는 불상사가 발생할 수 있음을 미리 경고합니다.

(실제로 저도 컴퓨터를 날릴 뻔했기에,, 이 포스팅을 그대로 따랐다가 발생하는 불상사는 책임지지 않습니다.

이건 저와 같은. 경우가 있으신 분께 도움이 되었으면 하는 마음에 작성합니다.)

-----

 

먼저

$ sudo vim /etc/default/grub

으로 vim 에디터로 kernel parameter 을 수정할 것이다.

 

열면 GRUB_DISTRIBUTOR 이 보일텐데, 거기에

GRUB_CMDLINE_LINUX_DEFAULT="nokaslr"

을 추가하는 것이 해결 방법인데, 이걸 그대로 적용했다가는 컴퓨터를 다 날릴 수도 있다...

 

왜냐면 나에겐 이미 GRUB_CMDLINE_LINUX_DEFAULT 요소가 있기 때문이다.

그래서 다음과 같이 해줘야 한다.

GRUB_CMDLINE_LINUX_DEFAULT="quiet nokaslr"

 

수정한 것을 저장해주고,

$ sudo update-grub

을 실행한 다음 이 명령이 정상적으로 끝나면 재부팅을 하면 된다.

 

재부팅할 때 이런 화면이 뜨면 성공했다고 보면 된다 .

(확실히 확인하려면 앞선 KASLR 적용 여부 확인법을 또 해보면 된다)

 

-------------------------------------

 

 

만약 KASLR 이 적용되었음을 확인한다면, 메모리 덤프 파일은 물론 프로파일도 다시 만들어야 한다. ㅎㅎ

 

그런데 그렇게 희망적이지는 않는 것이

이대로 진행하였음에도 volatility 에서 해당 메모리 파일을 분석하는데 나오는 정보가 거의 없었다.

무엇이 문제인지는 아직도 모르겠지만, linux_psscan 으로 실행한 것 외에는 나오는 정보가 없었다.

그래서 결국 다른 운영체제에서 메모리 덤프 파일을 새로 만들어 실습하였다.

그러니, linux 를 잘 아는 분이 아니라면 linux 에서 메모리 덤프 파일을 만들어서 volatility 로 분석하는 것은 개인적으론 추천드리지 않는다.

 

fin.

 

 

Ref.

[1] www.andreafortuna.org/2019/08/22/how-to-generate-a-volatility-profile-for-a-linux-system

[2] cpuu.postype.com/post/665132

[3] z49x2vmq.github.io/2018/01/14/kaslr/

.