[Lord of BOF] Level 13 (darkknight -> bugbear)

1. 문제의 힌트 확인

level13(darkknight)에 접속하여 ls 명령어로 디렉토리의 파일 목록을 살펴보자

[그림1]darkknight 계정의 디렉토리 목록

 

 

suid가 걸려있는 bugbear에서 쉘을 실행시켜야 할 것이다. vi를 통해 bugbear의 소스코드를 살펴보자.

[그림2]bugbear의 소스 코드

 

RTL1이라고 힌트가 제시되어 있다. RTL에 대해 알아보자

 

2. RTL (Return To Libc)

이 기법은 일반적인 BOF로 스택에서 코드가 실행되는 것을 막은 non-executable stack 보호기법이 나오고 나서 제안된 방법이다. return address를 libc 영역(공유라이브러리)으로 점프시켜서 원하는 libc함수를 실행한다. 예를 들어 printf함수를 사용했다고 하면 실제로 이 함수를 정의하고 있는 /lib/libc.so.6파일이 이 영역에 적재된다. 여기서 중요한 점은 printf함수 하나만 사용을 하더라고 /lib/libc.so.6파일이 통째로 메모리에 적재된다. 그러므로 이 파일에서 원하는 함수의 주소를 끄집어내서 RET주소에 넣어주게 되면 그 함수를 실행할 수 있다. 간단하게 그림으로 나타내면 이렇다.

[그림3] RTL 기법

 

 

3. 실제

다시 darkknight의 소스 코드를 보자.

[그림4] bugbear의 소스 코드

 

 

인자가 없을 때는 argv error라고 출력을 하고 프로그램을 종료하고, 인자가 있을 때는 첫 번째 인자의 48번째 인자를 확인하여 '\xbf'인 경우에 stack betrayed you!!라고 출력을 하고 프로그램을 종료한다. 이 모든 것을 통과했을 때 비로소 BOF에 취약한 strcpy함수를 수행하고 printf함수를 수행하게 된다.

스택의 구조는 이러할 것이다.

[그림5] main의 스택 구조

 

 

첫 번째 인자가 buffer에 들어갈 것이므로 argv[1][47]은 RET주소의 맨 앞 한 바이트가 될 것이다. 이것을 RTL 기법대로 libc 영역으로 보내면 될 것이다. 아마 libc영역은 주소의 맨 앞 한 바이트가 '\xbf'가 아니라서 저런 조건을 걸어 놓은 것 같다. gdb를 통해 system함수가 어디에 위치하고 있는지 살펴보자.

[그림6] gdb를 통해 system함수의 주소를 찾는 과정

 

 

그렇다면 일단 RET을 system함수로 보내는 공격 코드는 ./bugbear `python -c'print"A"*44+"\xe0\x8a\x05\x40"'`이 될 것이다. 하지만 이것만으로는 부족하다. system함수의 인자가 없기 때문이다. 그러므로 추가로 인자를 보내주어야 한다. system함수는 인자에 있는 명령을 수행하게 되는데 우리가 수행할 명령은 /bin/sh이다. /bin/sh의 주소를 찾아주는 프로그램을 작성하자.

[그림7] /bin/sh 문자열의 주소를 찾아주는 프로그램의 소스 코드

 

 

system함수의 주소부터 시작해서 "/bin/sh"와 매치되는 주소를 찾아서 출력해준다. 컴파일하고 프로그램을 실행하면 /bin/sh의 주소가 나온다.

[그림8] /bin/sh의 문자열의 주소

 

 

이제 이것들을 종합하여 최종 공격코드를 구성하면 된다.

./bugbear `python –c'print"A"*44+"\xe0\x8a\x05\x40"+"AAAA"+"\xf9\xbf\x0f\x40"'`

 

공격해보자.

[그림9] 최종 공격코드

 

 

[그림10] 쉘이 작동한 모습

 

 

쉘이 작동하였다!

 

 

id 명령어를 통해 권한을 살펴보자.

[그림11] id 명령어를 통해 권한 조회

 

 

권한이 상승한 것을 볼 수 있다.

 

my-pass 명령어를 통해 다음 단계의 패스워드를 획득하자.

[그림12] 다음 단계의 패스워드