SSo

이전 문제와 조금 비슷해보이면서 다른 것 같다.

일단 shell이라는 함수와 printit이라는 함수가 선언 되어 있다.

그리고 메인함수를 보면 포인터 변수가 printit을 가리킨다.

그리고 fgets를 사용해 stdin을 buf에 48바이트 입력한다.

이제 gdb로 확인해야겠다.

일단 변수로 할당된 버퍼의 크기는 56바이트다.

그리고 ebp-16에 printit의 주소를 mov하는것으로 보아 ebp-16이 포인터 call이 가리키는 값이 들어가는 것 같다.

일단 스택의 구조를 예상해보면 아래와 같다.

buf[20]

call[4]

crap[4]

buf[20]의 시작 위치가 ebp-56이고 call의 시작 주소는 ebp-16이다. 

56-16을 하면 40이다. 즉 40바이트가 buf에 할당된 사이즈고 그 다음 4바이트가 call이다.

call에 있는 주소를 실행하는 로직이므로 

40바이트를 무작위로 값을 주고 다음 4바이트에 실행시키고 싶은 함수의 주소를 넣어주면 되겠다.

다시말해 shell 함수의 주소로 오버플로우를 시켜주면 되겠다.

일단 shell함수의 주소를 찾았다.

이제 페이로드를 작성해 익스플로잇을 하면 된다.

클리어~

이번 문제는 fgets 함수를 사용하는 코드에 오버플로우를 일으키는 문제다.

fgets함수는 버퍼의 개수를 지정해주기 때문에 상대적으로 안전하지만 여기서는 지정된 버퍼보다 많은 바이트를 fgets함수로 저장할 수 있다.

우선 GDB로 열어봤다.

변수에 56바이트가 할당되었다.

각 변수들의 위치를 구해보면 buf에서 ebp까지의 거리가 56이고

*check에서 ebp까지의 거리는 16이다.

그러면 자연스럽게 buf와 *check의 거리는 40인것을 알 수 있다.

즉 버퍼에서 40바이트를 넘기면 오버플로우가 일어난다는 것이다.

그리고 fgets함수에 의해 0x2D 즉 45바이트를 넣을 수 있으니 5바이트는 더 넘길 수 있다는 의미다.

하지만 *check는 포인터변수이기 때문에 deadbeef라는 문자열이 있는 곳의 주소를 넣어줘야 한다.

내가 찾은 방법은 두 가지 방법이 있다.

첫번째 방법은 임시버퍼를 이용한 방법이다

두번째는 deadbeef라는 문자열이 있는 곳을 gdb로 잘 보면 친절하게 보여주고 있다. 그 주소를 넣어주면 된다.

먼저 첫번째 방법이다.

임시버퍼

임시버퍼를 이용하면 익스플로잇이 가능하다.

임시버퍼에는 상당히 많은 바이트를 넣어주면 저장이 된다. 그리고 주소가 변경이 되지 않고 고정이 되어 있어서 유용하게 페이로드를 넣고 사용할 수 있다.

일단 버퍼에 Nop sled를 200바이트를 주었다.

임시버퍼를 확인해보니 Nop 바이트가 정확히 들어가 있다.

페이로드는 일단 40바이트로 buf를 채우고 뒤에 4바이트를 0xdeadbeef가 있는 주소를 넣어주면 된다. 

gdb로 정확한 주소를 찾기 위해 일단 0xdeadbeef가 있는 주소가 있어야 할 자리에 AAAA를 넣고 Nop sled를 200바이트를 주고 0xdeadbeef가 있어야 할 자리에 BBBB를 넣고 확인했다.

BBBB가 있는 주소는 0x400170f4다 즉 AAAA위치에 0x400170f4를 넣고 BBBB에 0xdeadbeef를 넣으면 된다.

페이로드를 입력하니 문제가 풀렸다.

0xdeadbeef

gdb를 열어보면 0xedeadbeef랑 변수의 값과 비교하는 곳이 있다.

굳이 임시버퍼에 0xdeadbeef를 입력하지 않고 이 곳의 주소를 이용해 문제를 쉽게 풀 수 있다.

0xdeadbeef가 0x80484b2에 있다.

이제 buf에 40바이트를 넣고 추가적으로 4바이트에 0x80484b2를 넣으면 문제가 풀릴 것이다.

아주 간단하게 문제가 풀렸다.

문제 힌트다.

fgets로 버퍼의 수를 제한하고 있다. 하지만 그래도 버퍼의 크기보다 큰 사이즈의 값을 저정할 수 있으므로 오버플로우가 가능하다.

먼저 스택의 구조를 상상해보면 아래와 같다.

buf[20바이트]

check[4바이트]

crap[4바이트]

버퍼에 오버플로우를 일으켜 check에 0xdeadbeef를 넣으면 system함수가 실행되면서 문제가 풀릴것이다.

GDB로 버퍼의 크기를 일단 확인해봐야겠다.

56바이트를 버퍼에 할당했다. 일단 fgets 함수는 45바이트 까지만 퍼버의 값을 채워준다.

0xdeadbeef랑 비교하는 구문이 있는데 이곳의 위치는 ebp-16이다 즉 check변수의 위치라는 것이다.

buf의 시작위치는 ebp-56이고 check의 위치는 ebp-16이다. 

다시말해 buf에 40바이트 이상을 넣으면 오버플로우가 일어난다는 의미다.

간단하게 40바이트 뒤에 4바이트에 0xdeadbeef를 넣으면 system 함수를 실행할 수 있을 것이다.

쉘을 얻었다.

소스 힌트다.

변수가 두개 설정 되어있다.

버퍼의 크기는 0x418 즉 1048바이트로 설정되어있다.

long i가 먼저 선언되었으며 스택의 높은주소쪽에 위치할 것이다.

 ebp-12에 0x1234567을 mov하는것을 볼 수 있다. 버퍼를 넘치게해 ebp-12에 오버플로우를 일으키면 된다.

일단 1048바이트 뒤에 AAAA를 주어 확인해보니 ebp에 AAAA가 위치한다.

ebp-12에 0x1234567이 들어가야 하니까 바이트 수를 좀 줄여서 확인해봐야겠다.

1036바이트 뒤에 AAAA를 주니 ebp-12에 값이 들어갔다.

이제 RTL 페이로드를 작성해야겠다.

bin/sh의 주소를 구했다.

system함수의 주소를 구했다.

Payload

NOP sled [1036바이트] + 0x1234567 [4바이트] + NOP sled [12바이트] + SYSTEM 함수 주소 [4바이트] + NOP sled [4바이트] + /bin/sh 주소 [4바이트]

`python -c 'print "\x90"*1036+"\x67\x45\x23\x01"+"\x90"*12+"\xc0\xf2\x03\x42"+"\x90"*4+"\xa4\x7e\x12\x42"'`

쉘을 얻었다.

PHP Remote Code Execution 이 가능한 상황.pdf

문서 다운 받아서 보기

Ref : cfile5.uf.tistory.com/attach/213EE84355589F662024DD