싸이코 말단해커의 보안공부. 1일 1pwn

18번은 길었는데 19번은 매우 짧다...

ret 주소에 다음 단계로 넘어가는 쉘코드의 주소를 입력해주면 된다.

기존에 썼던 에그쉘은 setreuid 가 없는 쉘코드였다. 따라서 필자는 아래 사이트의 쉘코드를 빌려왔다. 

(http://kali-km.tistory.com/entry/FTZ-Level19-Chaining-RTL-Calls) 

"\x31\xc0\x31\xdb\x31\xc9\x66\xbb\x1c\x0c\x66\xb9\x1c\x0c\xb0\x46\xcd\x80\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x89\xc2\xb0\x0b\xcd\x80"

총 44개의 더미 뒤 ret 주소가 존재한다.

페이로드는 다음과 같다.

여태껏 ftz중에 가장 긴 코드이다.

쉽게 설명하면 shellout 함수를 호출할 수 있게 check에 0xdeadbeef가 존재하면 된다.

저번처럼 buf가 먼저 선언이 되어있어 버퍼오버플로우를 하더라도 check변수를 건들 수 는 없다.

그렇게 고민을 하던 중 switch case 문장을 살펴보니

string[count] = x 를 넣어주는 작업이 있다. count를 마이너스로 만든다음에 스택의 주소 반대로 갈 수만 있다면!!? 될 거 같다.

페이로드에 0x08을 입력해 check 변수의 주소의 값만큼 마이너스하면서 가서 거기에 deadbeef를 입력해주면 되지 않을까?

레벨 17이다.

전 문제랑 비슷한데 shell함수가 따로 없어서 주소를 입력할 수가 없게 되어있다.

그리고 버퍼에 입력을 받고 setreuid 함수가 다시 레벨 17로 가게 만드는 것 같다.

shell 함수가 없으면 우리가 11,12번 풀때처럼 환경변수에 저장해서 그 주소를 입력해주는 방식을 생각해 보았다.

전 문제들과 동일하게 버퍼에 40바이트를 입력해준 이후에 주소를 입력해주면 될 것 같다.

에그쉘과 getenv 함수를 짜서 입력해보자.

16이다. 조금만 더 힘을내자!!

함수 포인터라는 개념을 아는가? 그냥 함수형태의 포인터다.

void(*call) () = printit; 을 넣어두는 곳인데.

call()을 호출해서 결국 뭔가를 입력하면 buf에 넣어주고 Hello there!을 출력해준다.

buf에 20개 이상의 입력값을 통해서 call함수에 작성되있는 printit() 주소를 shell()주소로 바꿔버리자.

메인함수는 이렇게 짜여있다.

전에서도 봤다싶이 mov DWORD PTR [ebp-16], 0x8048500    call은 ebp 에서 16바이트 떨어있다.

  lea eax, [ebp-56] 이 것을 확인해보면 40개의 버퍼 이용한다.

즉 40 바이트 이후에 call함수의 주소를 불러주면 된다!!ㅎㅎ

페이로드는 다음과 같다.

buf에 40개의 A + shell()의 주소

shell의 주소를 입력한다.

0x080484d0을 넣어주면 된다.

끝!

레벨 15!

전 번 문제와 같지만 check에 포인터를 이용했기 때문에 check가 가리키는 곳에 0xdeadbeef가 존재해야 한다.

여러가지 시나리오를 생각해보았다.

1. buf의 크기를 넘겨 check 메모리부분을 건드릴 수 있다면 buf배열의 처음을 0xdeadbeef로 채워주고 buf주소를 가리키면 될 것이다.

2. 0xdeadbeef가 만약 메모리 어딘가에 적혀있다면 그 부분을 가리켜주는 것이다. (아마 하드코딩되어있다면...?)

일단 디버깅으로 확인을 해보아서 뭐가 편한지 확인해보자.

빠르게 tmp로 옮겨 디버깅을 해보자..

우리가 관심있는 cmp (if문)에 breakpoint를 걸어놓고

A 20개를 입력해보고 확인해보자.

그 전에 약간 관심을 가져야 하는 부분은 바로 ebp-16 이다. 이부분이 바로 check 부분일 것이다.

ebp -16위치가 우리가 원하는 check부분을 확인하고

결국 우리는 $ebp-16위치에 있는 0xbfffe9d8 이 값을 0xdeadbeef가 있는 다른 주소로 덮어써주면 된다.

세보면 마지막 0x41414141 뒤로 20개 더 있으니까

페이로드는

40개의 A + 0xdeadbeef가 있는 어느 주소 

로 이루어주면 된다.

0xdeadbeef과 일단 있는지 확인해보자.

필자는 main함수를 확인해보아서 변수에 존재하는지 보려했는데 있다...!!

저기!! 걸쳐있는 beef와 dead가 보이는가!!

0x080484b2로 확인을 해주면 된다. 여기가 우리의 페이로드에 들어갈 주소가 된다....!!!!

짜보면..

아마 이번 문제는 이렇게 푸는것이 훨씬 쉬웠을 것이다.

1번 시나리오 대로 풀어보니 자꾸 주소가 바뀌는 문제점이 있었다.

14번은 전 문제와 비슷하게 check 메모리에다가 0xdeadbeef를 넣어주면 된다!

fgets가 20보다 큰 수를 사용자에게 받을 수 있게 만든 것이 버퍼오버플로우 가능성을 보여준다.

재빨리 gdb로 까보자

어셈블리를 살펴보면 cmp구문 ebp-16과 비교한다. 딱봐도 ebp-16에 0xdeadbeef를 작성해주면 된다.

일단 우리는 if문에 관심이 있다

breakpoint를 main+29에 걸어보고 run 시켜서 20개만 가볍게 채워보자

기존의 20개의 buf 외에 20개의 뭔가가 더있고 그 후에 0xbfffe348위치에 check 변수 (0xdeadbeef를 덮어야할) 메모리가 할당되어 있다.

즉 페이로드는 buf에 40개 + 0xdeadbeef 형태로 넣어주면 된다.

12번에서 풀었던 pipe 형식으로 넘겨주자.

13단계이다.

힌트를 보면 버퍼 오버플로우를 나름(?) 막는다고 변수 i를 설정하여 해커가 이 부분까지 덮어서 1234567이 아니라 변조가 되면, 프로세스를 종료시키는 형태로 만들었다.

하지만 우리는 메모리 상 i 위치를 알아서 이부분만 1234567로 덮어서 버퍼오버플로우를 일으키면 해결될 일이다.

i가 들어가는 위치를 알아보자. gdb로!

우리가 관심있는 곳은 if문이므로 if문 main+69에 breakpoint를 걸자.

그리고 buf의 양인 1024개를 채워넣어보자.

x/100x $esp로 확인하고 쭉쭉 넘겨보면 buf가 끝나는 지점이 보인다.

대충 0x01234567이 보이고 그러는데 잘 구별이 안간다.

그렇다면!!!!!  ebp(sfp)를 확인하는 명령어로

위치를 확인하면 구조를 더 뚜렷히 확인을 할 수 있다.

더미가 시작하는 곳은 0xbfffd8c0부분부터 봐라!!

1024개의 버퍼 + 12개의 더미 + 0x01234567(여기가 i) + 12개의 더미 + $ebp(sfp) + RET 어드레스!!!(쉘코드주소 주입하자!)

페이로드를 짜보자

끝!