문제확인

우선 바로 hint를 확인하여 소스코드를 보면 아래와 같이, 지금까지의 소스보다 긴 것을 확인 할 수가 있다. 하지만 여기서 잡아야 할 것은 난잡한 다른 코드가 아닌 count의 값을 감소시켜주는 swith문을 확인 할 수가 있어야한다. 아래 코드에서 보는 것과 같이 "\x08"이 입력될 경우 count의 1 감소하는 것을 확인 할 수가 있다.

스택의 구조를 아래와 같이 확인을 해볼 경우 <Low>  fds[132] - count[4] - x[4] - Check[4] - string[0] ~ string[100] - SFP -RET  <High> 이러한 형태로 나타나는 것을 확인 할 수가 있다. 여기서 우리가 알아야할 것은 기존의 string과 같은 역할을 하는 변수의 위치가 Low 쪽에 위치하기에 우리는 버퍼를 덮어 씌울 수가 있었지만 여기서는 string이 Check보다 위쪽에 있기에 덮어 씌울 수가 없다. 하지만 우리가 알아야 할 것은 바로 포인터 변수의 이동이다. 바로 count-1을 통하여 우리는 버퍼를 이동 시킬 수가 있고 바로 그 조건이 위의 붉은 상자 안에 있는 값이다. 

공격

따라서 우리는 count의 값을 4번 이동 시켜 check에 0xdeadbeef의 값을 주어야 한다. 따라서 페이로드는 아래와 같다.

참고 : http://geundi.tistory.com/131

문제 확인

이제 벌써 17번 문제이다. 끝이 보이고 있으니 마저 풀이를 계속하여보자. 아래의 소스와 같이 16번 문제와는 다르게 Shell()이라는 함수가 존재하지 않고 main()에 setreuid가 존재하고 있는 것을 확인 할 수가 있다. 따라서 우리는 *call 포인터변수를 통하여 printit()가 아니라 우리가 쉘코드를 메모리에 올려 그 메모리의 주소를 가리키도록 해야 이 문제에서 쉘을 획득 할 수가 있다.

GDB를 통하여 디스어셈블링을 해본다면 우선 main()에서 0x38만큼의 스택이 할당 되는 것을 확인 할 수가 있다. 또한 이전의 문제들을 통하여 우리는 스택의 구조를 짐작 할 수가 있다. 우선 Buf[20] - Dummy[20] - *Call[4] - Crap[4] - Dummy[8] - SFP - RET 의 순으로 할당이 되는 것을 알 수가 있다. 하지만 여기선 fgets를 통하여 48바이트 만큼만 전달을 할 수가 있기에 우리는 RET를 통한 공격을 할 수가 없다.

우선 브레이크지점을 형성 한 후 메모리의 상태를 확인 하여 보자. 아래와 같이 0xbfffe080에서부터 buf가 시작이 되며 그 후에 0xbfffe0a8에 *call과 crap이 순차적으로 있는 것을 확인 할 수가 있다. 

공격

환경변수를 통하여 공격을 진행하여 보자. 아래와 같이 페이로드를 입력한 후에 공격을 시도하면 공격에 성공하는 것을 확인 할 수가 있다.

Shell_Code[25Byte] : 

"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x89\xc2\xb0\x0b\xcd\x80"

의문점

아래와 같이 메모리를 확인할떄 A를 40개 만큼 줄경우 *call 위치에 0x804000a가 들어가는 것을 확인 할 수가 있으며, 만약 44만큼 A를 줄경우 Crap으ㅢ 위치에 0x804000a가 들어가므로 인하여 세그먼트 폴트를 일으켜 실행을 할 수가 없었다.

문제확인

바로 문제를 확인하여 보자. main()에서와 보는 것과 같이 printit를 호출한다. 하지만 여기서 shell()을 호출하도록 유도를 해야 쉘을 획득 할 수 있다는 것을 알 수가 있다. 여기서 *call 은 포인터 변수임을 잊지 말아야 한다.

우선 GDB를 통하여 프로그램을 분석해본다면 아래와 같이 shell() , printit(), main()의 순으로 되어있는 것을 확인 할 수가 있다. 여기서 확인 할 것은 main() 함수에 0x38만큼 스택이 할당 되는 것을 확인 할 수가 있다. 

정확한 위치를 확인 하기 위하여 아래와 같이 입력을 하여 새로운 attackme_2를 만들어주자. 여기서 달라진 것이라 함은 crap에 "AAAA"라는 값을 주는 것으로 정확한 crap의 위치를 확인하기 위하여 일부러 넣어 준 것이다.

gdb를 통하여 확인을 한 결과 우선 buf에 20만큼의 "A"를 넣어준다. 그리고 우리는 buf[20]이 할당 될 경우 dummy가 20만큼 추가로 할당 되는 것을 이미 여러 문제에서 확인을 할 수가 있었다. 이제 여기서 buf[20] + Dummy[20] + 호출주소값[4] - Crap[4] - Dummy[8] - SFP - RET 가 할당 되는 것을 알 수가 있다. 이제 호출주소값이 전달되는 위치에 shell()의 주소를 넘겨주면 된다

<Uttackme에서의 메모리>

<실제 Attackme에서의 메모리>

공격

문제확인

우선 문제를 확인하여 보자. 레벨14와 비슷하지만 check 변수가 포인터 변수임에서 차이가 난다. 여기서 중요한 것은 포인터 변수는 그 변수가 메모리의 주소를 가리키고 있으며 그 주소의 값이 0xdeadbeef를 나타내어야 쉘을 획득 할 수 가 있는 문제이다. 

GDB를 통하여 확인을 해본다면, 스택에 0x38( = 56 ) 만큼이 할당 되는 것을 확인 할 수가 있다. 이를 통해 우리는 어느정도 유추를 할 수가 있지만 정확한 *check변수의 위치를 알아야 한다.

아래와 같이 코딩을 한 후에 실행을 하면 Buf[20] - Dummy[20] - Check[4] - Crap[4] - Dummy[8] - SFP[4] - RET[4] 가 스택에 놓여있는 것을 확인 할 수가 있다.

여기서 우리는 더 명확하게 Buf주소를 *check의 주소에 올리는 방법을 통하여 공격을 할 수 있는 지를 확인해보자. 아래와 같이 &buf의 주소를 보면 계속 변화하는 ASLR의 형태를 띄고 있는 것을 확인 할 수가 있다. 따라서 우리는 환경변수를 이용하거나 하드코딩의 방법을 이용하여야 한다.

Hard Coding

하드코딩이란 코딩시에 그 숫자나 문자열이 그대로 입력이 되어있는 것으로 이러한 방법을 통하여 풀 수 있는 문제가 은근히 많다는 것을 유의하여야 한다. 아래와 같이 GDB를 통하여 x/16x main을 확인하면 main+34의 부분에 키 값이 그대로 하드코딩 되어 있는 것을 확인 할 수가 있다.

EGG Shell

환경변수를 이용한 방법은 사실 여러번 실패를 하였다. 기존의 export EGG=`python -c 'print "\xef\xbe\xad\xde"'`를 이용한 방법의 경우는 실패 하였지만, 아래와 같은 방법으로 환경변수를 입력해 주었을때는 쉘을 획득 하는데에 성공을 하였다. 구체적인 이유는 알지 못하지만 일단 페이로드를 첨부한다.

문제확인

우선 hint 파일을 먼저 확인을 해보면 buf[20]과 check, crap이 스택에 할당 되는 것을 확인 할 수가 있다. 그리고 check의 값이 0xdeadbeef 일 경우에 쉘을 획득 할 수 있는 소스이다. 이또한 fgets를 통하여 45바이트 만큼만 전달이 될 수 있기에 BOF를 방지하고 있다. 이제 GDB를 통하여 메모리를 확인 하여 보자.

DIsas을 통하여 확인 하였을때 0x38 == 50 바이트 만큼이 스택에 할당 되는 것을 확인 할 수가 있다. 하지만 여기서 우리는 Check라는 정확한 위치를 찾아야 하기 떄문에 우리는 더미가 얼마나 할당이 되는 지를 확인 할 수가 있어야 한다. 그렇기에 distance.c라는 프로그램을 우리가 작성하여 확인을 해보자.

아래와 같이 컴파일을 한 후에 실행을 하였을 경우 Buf[20] + Dummy[20] + Check[4] + Crap[4] + Dummy[20] + SFP + RET 라는 것을 확인 할 수가 있다. 이제 이를 통하여 우리는 공격을 시도 할 수가 있다.

공격

Buf[20]과 Dummy[20]을 무작위 값으로 채운후에 Checkdp 0xdeadbeef를 씌어준다면 공격은 성공한다. 그리고 여기서 또한 cat을 붙여줌으로 인하여 입출력을 유지 하여야 한다는 것에 유의하여야 한다.

Level13의 힌트를 확인하면 아래와 같은 소스가 출력이 된다. 인자를 입력 받고 그 인자를 buf에 복사하여 넣는 것으로 strcpy가 취약점이 있는 함수의 위치이다. 그리고 i 의 값 0x1234567이 변화 될경우 "Warnning Buffer Overflow !!!를 출력하며 그대로 프로그램이 종료가 된다. 여기서 i 와 같은 것을 바로 Stack Guard 라고 부른다. 이제 이 프로그램을 GDB로 분석하여 보자 디버깅 권한을 위하여 cp 명령어를 통하여 tmp 로 복사한 후에 분석을 시작하면 된다. 

아래 사진과 같이 프롤로그에서 0x418(1048)만큼의 스택이 할당 되는 것을 확인 할 수가 있다. 그렇다면 스택의 구조는 1048 + SFP + RET 라는 것을 이제는 충분히 예상 할 수가 있다. 하지만 여기서 중요한 것은 바로 i의 값이 변하면 안된다는 것이다. 그렇다면 i의 값을 찾기위해서 디버깅을 계속 실행하여 보자.

i를 찾기 위하여 buf[1024]에 A의 값을 넣고 BP를 걸어 실행을 해보자. r `python -c 'print "A"*1024'`를 입력하여 준다. 그리고 esp의 값을 확인하여 보면 아래와 같이 A(ASCII:41)의 값이 연속적으로 잘 입력된 것을 확인 할 수가 있다. 그렇게 쭉 따라 내려가보자.

0xbfffefc0로부터 "41"의 값이 입력되어서 0xbffff3c0 바로 전까지 "41"이 입력 된 것을 확인 할 수가 있다. 그리고 붉게 표시한 부분에 바로 i의 값이 저장이 되어있는 것을 확인 할 수가 있다. 그렇게 총 1048만큼 버퍼 뒤에는 SFP와 RET가 위치하고 있는 것을 확인 할 수가 있다. 이제 이 값은 유지한 채로 공격을 진행하여 보자.

RTL

디버깅을 통하여 system()과 exit()의 주소를 구한 다음에 "/bin/sh"의 주소를 구하여 공격을 진행하면 된다. 명령어에 대한 설명을 하자면 우선 i 의 값을 유지하기 위하여 i 바로 앞까지 1036만큼은 A로 채워주고 그 후 기존의 i 값을 다시 써준 후에 RET까지의 이동을 위하여 A를 12바이트 더 추가하여 준다. 그 후 system() 함수의 주소를 입력하여 주고 잘못된 종류로 인하여 로그에 기록이 되지 않게 하기 위하여 exit()의 주소를 넣어주고 그 후에 "/bin/sh"의 주소를 넣어 주면 쉽게 공격에 성공 한 것을 확인 할 수가 있다.

ENV-EGG Shell

에그쉘의 경우는 추가적인 설명을 하지는 않겠다.

문제확인

이번 문제도 level11과 비슷한 문제로 풀 수가 있다. 일단 tmp로 파일을 복사하여 디버깅을 해보자.

이전 문제와 같이 0x108 만큼의 버퍼를 채우고 RET에 새로운 주소값을 채우면 된다.

EGG Shell을 이용한 방법

Egg쉘을 이용한 방법의 경우 아래와 같이 쉽다.

Shell Code = "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x89\xc2\xb0\x0b\xcd\x80"

getaddr.c

#include <stdio.h>

main(){

char *p=getenv("EGG");

printf("Address : %p\n",p);}

RTL ( Return to Libc)을 이용한 방법

RTL은 리턴 주소를 공유 라이브러리 함수의 주소로 적어 해당 함수를 실행시키는 방법이다. 스택의 구조에서 system()함수를 ret에 덮어 씀으로 인하여 프로세스가 종료되고 리턴할 때 system()함수로 가게 된다. 그리고 system()함수가 끝나게 되면 그 다음 4바이트가 리턴주소이기 떄문에 정상적으로 종료될 수 있게 하기 위하여 exit()를 붙여준다.

system()는 쉘을 실행할수가 있고 인자로 /bin/sh를 넣어주면 된다.

결국 ----str[256]-dummy[8]-SFP[4]-RET[4]    >>> ---A[256]-A[8]-A[4]-System()[4]-exit()[4]-"/bin/sh"[4]로 덮어준다고 볼 수 있다.

아래에는 system() 의 안에 있는 /bin/sh 문자열의 주소를 구하는 코드이다.

Cat을 붙이는 이유

Pipe( | ) 사용시 왼쪽 프로그램의 stdout이 오른쪽 프로그램의 stdin으로 들어가게 되는데 python 이 실행되고 종료되면서 pipe broken 오류로 인하여 종료가 일어난다 따라서 사용자의 입력을 출력해주는 cat이나 te를 이용하여 stdin을 유지 시켜야한다.

<분명히 캡쳐를 한 것인데, 출처를 잊어버렸..>

BackDoor 생성

위의 방법들을 통하여 쉘을 얻은 후에 추가적으로 입력을 해주면 아래와 같이 Backdoor를 생성 할 수가 있다.

참고

http://smleenull.tistory.com/276          //RTL

http://peonix120.tistory.com/3            //RTL

문제 확인

나중에 디버깅을 하는데 있어서 권한이 없으므로 cp 명령어를 통하여 tmp 폴더로 복사를 하여 분석을 한다.

Disas을 통하여 보았을때 Dummy 8바이트가 추가로 붙은 것을 확인 할 수가 있으며, 스텍을 그림으로 나타내면 아래와 같은 모양이 된다.

Buffer Over Flow를 통한 풀이

*RET에 넣을 주소를 구하여보자. 아래의 코드에서 25Byte의 Shell Code는 B로 대입을 하고 A는 NOP, C에는 나중에 넣을 RET의 크기 만큼 대입을 하여 x/256x $ESP를 통하여 RET에 넣을 주소를 구하는 과정이다. 여기에서 주의해야 할 사항으로는 ` , ' , " 의 사용에 유의하여야 한다는 것이다.

여기서 우리는 0xbffffadc의 주소를 RET로 사용 할 것이다. 그리고 공격에 쓰일 25Byte의 쉘코드는 인터넷을 통하여 쉽게 구할 수가 있다.

"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x89\xc2\xb0\x0b\xcd\x80"

*여기서 유의 해야할 사항으로는 `,',"을 헷갈리지 않고 사용하는 것과 \x90이 \xc2로 치환될 경우가 있는 UTF-8을 대신하여 en_US를 사용하여야 한다. 이를 위해서는 콘솔에 다음과 같이 입력을 하여야한다. "export LANG=en_US "

환경 변수를 이용한 풀이

이번에는 환경변수를 이용한 풀이를 하여보자. 우선 환경변수를 등록하여 준다.그 후 아래와 같이 하면 된다.

Format String Attack

포멧스트링에서 가장 대표적으로 언급되는 중요한 호출 시점이란 main() 함수의 소멸자이다. 소멸자란 main()함수가 종료되는 시점에 소멸자가 호출된다고 볼수 있는데, 이러한 소멸자 역할을 수행하는 함수를 셸코드로 흐름을 바꿀수 있다면 셸이 떨어진다는 의미이다. nm 명령어를 통하여 함수의 소멸자를 찾아보자.

여기서 중요한 소멸자 함수는 바로 0x08049610에 위치하여 있는 __DTOR_END__ 함수이다. 이제 공격에 앞서 위의 방법과 같이 환경변수를 등록하여 주고 이제 이 값의 위치를 셸코드가 들어 있는 환경변수의 위치로 바꾸어주면 된다.

우리가 공격해야 할 주소는 소멸자가 있는 __DTOR_END__(0x08049610) 이고 덮어써야할 셸 코드 주소는 0xbffffc69이다. 여기서 마지막에 있는 명령어에 대하여 설명을 하자면, 우선 __DTOR_END__의 주소와 Half Word(2Byte) 뒤의 주소를 두번씩 입력하고 있다. 이렇게 하면 char str[256] 배열에 이 주소값이 들어 갈 것이다.

그리고 %8x%8x%8x%64577c%n%50070c%n :  %8x 지정자를 이용해 8바이트 단위의 출력 포멧을 만들면서 포인터를 3자리 앞으로 옮겼다. 즉 %8x 지정자 3개로 인해 포인터가 str 배열 바로 앞으로 이동한다. 그리고 %c 지정자때문에 포인터가 한번 더 이동해서 str배열을 가리키게 된다.

여기서 64577의 값은 "0xFC69"를 10진수로 변환한 후에 다른 입력된 값(40byte)를 빼주는 것이다. 그래야 앞의 40Byte와 더해져서 0xFC69가 스트링에 입력이 될 수 있기 떄문이다. 그리고 50070은 0xBFFF를 입력하기 위한 값으로 0x1BFFF-0xFC69를 빼준 값이다.