[ftz] level 13: have no clue

13_스택 가드

 

√ 스택 가드(Stack Guard)

: BOF의 방어책으로 제시된 방법 중 하나

- BOF는 애플리케이션 개발자들의 실수

ex. strncpy() 대신 strcpy()를 쓴다든지

 

char str[256]

Stack Guard

SFP

RET

 

- BOF시켜서 RET을 변조하게 되면, 당연히 스택 가드 영역도 함께 다른 값으로 변주될 수밖에 없다.

>> Stack Guard 값이 바뀌었다 = BOF 공격이 일어났다

 

 

√ 문제 분석

- i 변수가 0x1234567이어야 if절을 통과하고 BOF 공격에 성공할 수 있다.

: 스택 가드 값을 설정

 

√ gdb로 소스코드 분석

procedure prelude 과정

- 함수 프롤로그 부분

- main+3> stack에 1048bytes 확보

: buf[1024]+dummy[24]

- main+9> ebp-12에 0x1234567 넣음

>> i = 0x1234567

 

>> setreuid(3094, 3094)

 

- ebp+8(argc)과 1을 비교

less or equal일 경우, main+69로 JMP

- EAX(ebp+12 = argv[1])을 stack에 PUSH

- ebp-1048의 주소값을 EAX에 입력

>> strcpy(ebp-1048, ebp+12)

 

- ebp-12(i)와 0x1234567 비교: 스택 가드의 값을 검사

같으면 main+109로 JMP

- 다른 경우

>> printf("Warnning: ~ ")

>> kill(0, 11): 프로세스에 Segmentation Fault 에러 전달

11(SIGSEGV)

 

buf[1024]

dummy[12]

i[4]

dummy[8]

SFP[4]

RET[4]

 

√ 공격

- 성공 조건

1. argc 2개 이상

2. i = 0x1234567

 

* 페이로드

buf[1024] + dummy[12] + 0x1234567 + dummy[8] + SFP[4] + buf 주소

 

>> NOP[200] + SHELL CODE[24] + NOP[812] + 0x1234567 + NOP[12] + buf 주소

 

cmp 부분에 bp를 걸어두고, 검사에 걸리지 않게 했다.

buf 배열의 시작 주소: 0xbfffe6b0

 

>> 그러나 스택 메모리 주소가 계속 바뀌기 때문에 또 환경변수를 이용하기로 했다.

 

- 환경변수 SHELL에 셸코드 설정

 

getenv.c

- 환경변수 SHELL 주소를 print하는 getenv.c 작성

 

- 환경변수 주소: 0xbffff9e9

 

* 공격

buf[1024] + dummy[12] + 0x1234567 + dummy[8] + SFP[4] + 환경변수 주소

페이로드: NOP[1036] + 0x1234567 + NOP[12] + 0xbffff9e9

 

** 공격 시 파이프로 인자 전달하는 방식이 먹힐때도, 안 먹힐때도 있는 것 같다.

 

Level 14 Password = what that nigga want?

 

 

++ 추가 정리

- 0xbfffdd3c 주소에 스택가드 값이 있음을 볼 수 있다.

 

* 스택 가드 우회하는 방법

스택가드 변수 값이 있을 0xbfffdd3c 주소에 0x01234567을 정확히 덮어쓰면 된다.