The Lord Of The BOF (FC3) // gate -> iron_golem

페도라캐슬 1층 iron_golem.c파일입니다

보시는바와 같이 저번 LOB의 첫번째문제인 gremlin과 문제가 같습니다.

딱 보면 디버거를 실행을 하지 않아도 bof을 할 수 있을정도로 매우 취약한 파일처럼 보입니다.

그러나 이 FC1층부터는 버전이 업데이트 되면서 메모리보호기법이 적용 되었는데요

1. 스택가드 : 더미 생성

  - 스택내에 함수의 변수 크기를 정확하게 예측하지 못하게 더미값을 추가합니다.

2. 아스키 아머

  - 라이브러리의 영역이 가장 낮은 영역으로 이동됨 ( 0x00번지에 위치 )

  - RTL을 이용 할 시 라이브러리 호출은 되지만 인자값을 맘대로 변형이 불가능함.

3. 랜덤스택 (ASLR  = Address Space Layout Randomization )

  - 실행을 할 때마다 메모리 주소가 바뀜. = 주소를 예측할 수 없다.

4. 비실행 스택 ( Non-Executable Stack )

  - 3번 같은경우 NOP코드를 매우많이깔면 예측은 못하더라도 찾을 수가 있음 그것을 막기위해서 데이터 자체를 실행 못하게 막음

이렇게 메모리 보호기법 4가지가 추가되면서 보기엔 매우 쉬워보이는 문제지만 간단하지는 않습니다. 

gdb를 살펴보면 sub esp 0x108 을 진행해 변수공간을 만든다

여기서 0x108은 10진수로 264가 되는데

c파일로 본 256바이트보다 8바이트가 더 추가되었다.

이것이 바로 스택가드 기능으로 8바이트의 더미코드가 추가 되었다고 볼 수 있습니다.

우선 힌트로 fake ebp를 이용하라고 나오므로

문제를 해결하기 위해 메모리값이 변하지않는 곳을 찾아야 합니다.

그래서 main문의 첫 라이브러리 호출함수의 GOT를 살펴보았습니다.

0x00730d50을 fake ebp로 설정을 했고.

쉘을 실행하기 위해 system함수를 이용하려 했으나 업데이트가 되면서 system으로 해도 권한이 오르질 않아

그래서 excel 함수를 이용하겠습니다.

buf + 더미 + ebp + eip값을 채운 모습

정상적으로 동작을 하는지 확인해본 결과

메인함수에서 leave를 통해 fake ebp값으로 정상적으로 변경되었으나

ret을 통해 excel함수에 점프하여 들어가 excel의 프롤로그에 의해 설정했던 ebp값이 초기화가 되었네요  

이를 방지하기 위해 execl 주소값을 +3 추가하여 프롤로그를 건너뛰게 만들었습니다.

다시 실행해 보았더니 정상적으로 동작하는것을 확인

이제 execl의 첫번째 인자의 값을 확인해보니

"\x68\x10" 

이것을 심볼릭링크를 통해 /bin/sh를 가르키게 하면 됩니다.

링크걸어주고

expolit을 해 쉘이 실행되었으나 권한 상승이 안되었다.

이것도 보호기법이 적용되어 setuid파일인데도 권한이 상승이 안되나 봅니다

따로 setreuid함수가 설정된 파일을 만들어 링크를 걸어도 되나

/bin/my-pass 에 링크를 걸어서 진행해 보겠습니다.

실행을 하니 setuid 상태에서 /bin/my-pass를 한 결과 다음 단계의 패스워드 얻을 수 있습니다.