level15
- 소스코드의 7 행에서 fgets 함수를 통해 44(40+4) 바이트 만큼 버퍼를 복사한다.
- 소스코드의 14~18 행에서 check 포인터 변수의 값이 0xdeadbeef 이면 setreuid 함수와 system 함수를 통해 level16(3096) 권한의 쉘을 획득할 수 있다.
- check 포인터 변수 앞까지 Dummy 데이터 (40)로 덮고 check 포인터 변수의 값을 0xdeadbeef 가 위치한 환경변수로 변조함으로써 level16(3096) 권한의 쉘을 획득하였다.
1. #include <stdio.h>
2.
3. main()
4. { int crap;
5. int * check;
6. char buf[20];
7. fgets(buf,45,stdin);
8. if (*check==0xdeadbeef)
9. {
10. setreuid(3096,3096);
11. system("/bin/sh");
12. }
13. }
14.
15.
- setuid 가 설정되어 있으면 gdb 가 동작하지 않기 떄문에 tmp 디렉토리에 cp 명령을 이용하여 복사한다.
- attackme 소스코드 7행을 보면 fgets 함수를 통해 stdin(Standard Input) 에서 입력받은 버퍼를 buf 배열에 최대 45바이트만큼 복사한다.
- FTZ LEVEL14 와 같이 소스코드 상에서는 buf 배열 크기가 20 이지만 실제로 20 이상의 버퍼가 할당되어 있을것이다.(자세한 내용 참조 : http://mdkstudy.tistory.com/41)
- 또한, 소스코드 8~12행에서 check 포인터 변수의 값이 0xdeadbeef 이면 setreuid 함수와 system 함수를 통해 level15(3095) 권한의 쉘을 획득할 수 있다.
- 그러나 check 포인터 변수의 입력을 받는곳이 없기 때문에 fgets 함수를 통해 buf 배열의 크기 이상을 복사함으써 check 변수의 값을 변조시켜야한다.
- 이제 소스코드를 통해 전체적인 흐름은 파악했으니 gdb 를 이용해 실행시켜보면서 동적 분석을 진행한다.
- gdb 에 실행파일을 로드한 뒤 main 함수의 ret 와 check 변수의 값이 0xdeadbeef 인지를 검사하는 루틴에 브레이크포인트를 걸고 실행한다.
- bp(BreakPoint) 가 걸리고 esp 를 확인해보면 필자가 넣은 "A" 20바이트가 입력된것을 확인할 수 있다.
- 그러나, check 포인터 변수의 값을 변조시켜야 하므로 20 바이트 + 20바이트를 추가로 덮어야지 check 포인터를 변조 할 수 있다.
- check 포인터 변수가 정상적으로 변조된 것을 확인하였으니 bash2 프로세스를 실행시키고 환경변수 EGG 에 0xdeadbeef 를 넣어준다.
- EGG 환경변수를 등록하고 0xdeadbeef 의 주소 위치를 구한다.
- findegg 실행파일을 이용해 주소를 구했지만 정확하지 않을 수 있기 때문에 gdb 를 이용해 정확한 주소인지 확인을 한다.
- gdb 를 통해 확인을 해보면 오차가 있다.
- 이제 정확한 환경변수의 위치를 알아냈으니 payload 를 작성하고 exploit 을 한다.
- payload 를 작성하고 exploit 을 해보았지만 실패했다.
- 이유를 알아내기 위해 ulimit -c unlimited 명령을 통해 Segmentation Fault 에러가 발생할 경우 core 덤프 파일을 남기게 했다.
- attackme 파일을 강제로 Segmentation Fault 를 일으키기 위해 정상적이지 않은 주소를 비교(cmp) 하게 했다.
- Segmentation Fault 에러가 발생하면 core 덤프 파일이 생기었으니 gdb 를 통해 메모리를 확인할 수 있다.
- gdb 를 통해 core 덤프 파일을 보면 필자가 앞서 구한 환경변수의 위치가 달라진 것을 확인할 수 있다.
- 이제 core 덤프 파일에서 획득한 주소를 통해 exploit 을 할 수 있다.
python -c 'print "A"*40 + "\x94\xfc\xff\xbf"' > payload
(cat payload;cat) | ./attackme
