Test

#About

[그림 1] - Hell_fire.c 소스 코드 확인

#Solution

[그림 1]에서 확인할 수 있듯 해당 문제는 Remote BOF 문제이며 해당 리눅스 서버에서 사용하는 포트의 설정에서 7777포트를 확인해보았다

[그림 2] - 포트 설정 확인

hell_fire라는 이름의 7777번 포트가 설정되어 있는것을 확인할 수 있으며 또한 아래의 [그림 3]을 확인하면 해당 

바이너리 파일은 setuid가 설정되어 있지 않고 슈퍼데몬인 xinetd.d가 hell_fire 권한으로 문제를 실행하고 있다

[그림 3] - setuid 설정 확인

xinetd.d로 서비스하게 되면 자동으로 I/O를 연결시켜주어 Remote 셸코드를 사용하지 않아도 되며 /bin/sh를 해주는 것만으로도 셸을 획득할 수 있다

문제 풀이에 사용할 함수는 system이며, 이는 내부 루틴 중 do_system 함수를 사용하고 이는 또 내부 루틴 중 execve를 사용한다 아래의 과정을 살펴보자

[그림 4] - system 함수 디스어셈블링 결과 확인

[그림 5] - do_system 함수 디스어셈블링 결과 확인

위 [그림 4], [그림 5]에서 확인할 수 있듯, do_system 함수는 내부적으로 execve 함수를 호출하므로 do_system 함수를 

호출하게 되면 내부적으로 execve("/bin/sh","명령어");와 같은 효과를 가지게 되며 execve 함수에 필요한 명령어를 형성하는 부분은

[그림 5]의 0x00750784 부분이며 execve("/bin/sh",{"/home/dark_eyes/hell_fire",NULL},envp) 와 같이 형성 된다

따라서 아래와 같이 리턴 값을 do_system+1124 부분의 주소로 변조해주게 되면 아래와 같이 셸을 획득할 수 있다

[그림 6] - 셸 획득

#About

[그림 1] - dark_eyes.c 소스 코드 확인

#Solution

이전 문제와 달라진 점이라면 Fake EBP 기법의 사용을 막기위해, strcpy 함수가 진행되어 오버플로우가 발생하여 

SFP 값이 변조가 되었을 경우에 대비해 SFP 값을 복원해오는 과정을 거친다

[그림 2] - 복원 된 SFP 값 확인

위 그림은 함수의 에필로그 과정의 시작점인 leave에 중단점을 걸어둔 뒤, buffer 256byte + dummy 8byte의 총 264byte와 

변조할 EBP 값인 BBBB, 변조할 리턴 값인 CCCC를 넣은 상황이며, EBP 값이 변조 되지 않고 다시 복원된 것을 확인할 수 있다

이러한 상황에서 주어진 hint는 RET sleding이며, NOP Sleing이 아무런 동작을 하지 않는 0x90을 타고 흐르듯, 

RET sleding 역시 RET을 이용하여 메모리를 타고 흐르는 것과 비슷한 개념이라고 생각하면 쉬울 것이다

[그림 3] - 오버플로우에 필요한 ret 명령의 주소 및 execl 함수 주소 확인

위 그림은 [그림 2]에서 RET 값을 CCCC를 넣어주었던것과 달리, 계속 ret 명령이 위치한 주소를 넣어줌으로써 

pop eip를 계속적으로 수행하게 되고 결과적으로 스택에서 원하는 주소로 이동할 수 있게 된다.

execl 함수는 NULL 값으로 인자의 끝을 알리므로 execl 함수를 사용하기 위한 적절한 메모리 공간을 찾아야한다

[그림 4] - execl 함수가 위치할 스택 공간 확인

위 그림은 RET sleding 기법을 통해 execl 함수가 위치해야할 주소를 확인한 것이며 이는, 함수의 인자가 ebp+8, ebp+c, ...가

 되므로 실행 파일 이름은 ebp+8이 될 것이며 인자의 끝을 나타내는 0x00000000이 ebp+c에 위치하기 때문이다

먼저 ebp+8에 해당하는 주소에 위치하는 값을 확인하면 아래와 같다

[그림 5] - ebp+8 값 확인

확인 결과, 0x0083ed3c이며 이는 execl(0x0083ed3c,0x00000000)와 같이 실행될 것이므로, 아래와 같이 셸을 띄우는

 C 코드를 작성해주고 0x0083ed3c의 이름으로 심볼릭 링크를 걸어주었으며 그 과정은 아래와 같다

[그림 6] - 셸을 띄우는 C 코드 작성 및 컴파일

[그림 7] - 심볼릭 링크 설정

[그림 4]에서 확인할 수 있듯, RET sleding 기법을 통해 execl 함수를 적절한 인자가 위치하는 메모리 주소에 삽입시키기 

위해서는 ret 명령이 위치하는 주소를 세번 넣어준 뒤 execl 함수의 주소를 적어주면 되고 페이로드는 아래와 같다

[그림 8] - 최종 페이로드 확인

execl 주소 값 중 0x20이라는 값은 공백을 의미하여 에러가 출력되므로 에러를 방지하기 위해 페이로드 앞 뒤에 더블쿼터를 붙여주었다

#About

[그림 1] - iron_golem.c 소스 코드 확인

#Solution

[그림 2] - 메모리 보호 기법 NX(Non Executable stack) 및 Ascii Armor 설정 확인 

스택 영역이 가지는 권한 중 실행 권한이 미설정 되어 있음을 확인할 수 있고, 또한 Ascii Armor라 하여 라이브러리 영역의 최상위 1 바이트를

NULL 값을 넣어 줌으로써(ex : 0x00123456) RTL 공격 구성 시 연속적인 페이로드를 작성할 수 없게 만드는 기법을 확인할 수 있으며 

해당 파일을 확인한 경로에 대한 설명은 다음과 같다

/proc = 프로세스 정보를 보유하는 디렉터리

/proc/self = 현재 실행중인 프로세스의 디렉터리 표시

/proc/[pid]/maps = 고유 pid 값을 가지는 프로세스가 메모리 주소 공간에 맵핑된 정보 표시

또한 ALSR이라하여 스택의 주소 값을 랜덤하게 설정해줌으로써 셸 코드의 시작 주소 및 리턴 주소가 불분명해지고 

이로 인해 메모리 보호의 효과를 볼 수 있는 기법이 있으며 바로 아래에서 확인할 수 있다 

[그림 3] - 메모리 보호 기법 ASLR(Address Space Layout Randomiztion) 설정 확인

[그림 2]와 동일하게 확인 결과 메모리 주소 값이 변한 것을 확인할 수 있으며 이를 ASLR이라 한다

문제로 돌아와, [그림 1]의 소스를 확인하면 buffer에 256바이트를 할당하며, strcpy에서 오버플로우가 발생한다

[그림 4] - buffer 할당 크기 확인

실제로 256바이트를 할당하는지 확인해보았더니 0x108 즉, 264바이트를 할당함을 확인할 수 있었고 이는 dummy 8바이트가 붙음을 알 수 있다

따라서 스택의 구조를 표현하면 | buffer [256] | Dummy [8] | ebp [4] | RET [4] | 와 같아지며, 위에서 확인한 메모리 보호 기법으로 인해 LOB에서 사용하던 

셸 코드 삽입 및 리턴 주소 조작으로 인한 오버플로우 및 RTL 기법을 통한 리턴 주소에 연속적인 페이로드 작성을 할 수 없는 상황이다

hint를 확인하면 Fake ebp 기법을 이용하라 되어 있으며, ebp를 변조할 수 있다는 말은 ebp+4 영역을 참조하는 리턴 값을 

변조할 수 있다는 말과 같으며 이는 또한 ebp+8, ebp+c를 참조하는 인자 또한 변조할 수 있다는 말과 같아진다

ebp 값을 변조할 때 ASLR으로 인해 스택 영역의 주소가 계속 바뀌므로 GOT 영역이나 BSS 영역, 과 같이 주소가 변하지 않는 부분을 사용해야 하며

아래와 같이 readelf 명령을 이용하여 알고자하는 영역이 위치하는 주소를 확인할 수 있다

[그림 5] - readelf 명령을 통한 섹션 정보 확인

Ascii Armor로 인한 RTL을 할 수 없는 상황에서 먼저, 리턴 영역에 execl 함수를 넣어주고 Fake EBP 기법을 이용하면 

위에서 언급했듯 인자 값은 ebp+8, ebp+c, ... 로 확인하기 때문에 execl 함수의 인자 값을 컨트롤할 수 있게 된다

ebp 값을 변조해야할 부분은 주소 값이 변하지 않는 got 영역이 되어야하며 got 영역의 시작 주소는 

plt 영역에서 제일 처음 jmp하는 부분이며 [그림 5]에서 또한 확인할 수 있다

[그림 6] - GOT(Global Offset Table) 영역 확인

execl 함수는 int (excel const char * path, const char *arg0, ..., const char *argn, NULL);로 구성되기 때문에 위 [그림 6]과 매칭시켜보게 되면 

0x0804954c이 가리키는 값이 실행 파일명이 되며 세 번째 인자가 NULL이 되므로 인자로 사용하기에 적합한것을 확인할 수 있다

따.라.서 EBP가 위치해야할 곳은 GOT 영역주소 - 0x08이 되며 이는 거듭 설명하지만 인자가 ebp+8, ebp+c, ...에 의해 컨트롤되기 때문이다

GOT 영역의 시작주소는 0x08049618이며, 페이로드가 구성 될 때는 -0x08을 해주고 메모리 구성은 다음과 같아진다 

| buffer + dummy [264] | 0x08049610 | execl 함수 주소 + 3 | *0x0804954c | 0x00000000 |

이 때, execl 함수 주소 +3이 되는 이유는 excel 함수가 시작되며 진행되는 프롤로그 과정에 의해 ebp 값이 변하므로 

프롤로그 과정을 건너 뛰어야 하기 때문이다 ( 이때 생기는 의문은, 프롤로그 과정을 뛰어넘게 되면 함수의 흐름에 문제가 없는지 ? 궁금 )

또한 execl의 첫 번째 인자인 실행 파일이 가리키는 값을 확인 결과 아래와 같이 0x00000001이라는 값을 가지고 있음을 확인할 수 있다

[그림 7] - 실행 파일 명 확인

최종적으로 페이로드를 실행하게 되면 execl("1");이 실행될 것이며 이는 1이라는 파일을 실행하므로 

셸을 띄워줄 수 있게 끔 아래와 같이 shell.c를 작성해주고 심.볼.릭 링크를 통해 실행 흐름을 넘겨주면 된다

[그림 8] - shell.c 소스 코드 작성

(상) 소스코드 작성 (하) 심볼릭 링크 작성

[그림 9] - exploit