Plummmm♪

이번 문제는 버그베어!? bugbear.c를 열어보겠음. if(argv[1][47] == '\xbf') { printf("stack betrayed you!!\n"); exit(0) } 이 부분을 봅시다. ?? 지금 까지 있던 문제들은 모두 스택 영역에서만 코드를 실행할 수 있도록 했는데 이건 정반대로 스택 영역에서 코드 실행을 금지시키고 있다. NX-bit 옵션을 준다는 얘기. 즉 RTL(Return-to-Libc)를 사용해야 된다는 말. 코드 상단에 주석에도 친절하게도 RTL 이라고 해뒀네. 포스팅을 읽고 왔다고 가정하고 문제 풀이를 진행하겠다. 일단 우리가 구해야 하는건 1. 라이브러리의 SYSTEM함수 주소 2. SYSTEM 함수 내부의 "/bin/sh" 문자열 위치 를 알아야 한다. 먼저 시스템..

이번에는 이름이 다크나이트..후덜덜 소스파일을 열어보자. 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..

orge.c 를 열어보자. 친절하게 //here is changed 라고 써있다. argv[0]의 길이를 검사하는 알고리즘이 적용되어 있음. argv[0]은 다들 알다시피 파일명이 들어가는 자리이다. 우리가 공격을 할때 ./orge [페이로드] 이런식으로 공격을 하니까 일단 저대로 하면 argv[0]은 6바이트가 들어갈 것임. 문제에서는 77바이트를 요구하였으니.. 심볼릭 링크를 이용하여 파일 이름을 75글자로 하면 요구사항에 맞춰질 것이다. [77바이트] = [./] [75바이트 아무문자] argv[2]의 주소를 찾을건데, 저번과 마찬가지로 printf("%x\n",argv[2]); 를 이용하여 찾는다. orge를 복사해서 주소를 찾을 때 복사하는 파일도 똑같이 심볼릭링크를 걸어줘야된다. argv[0]..

darkelf.c 를 열어보겠음. 아까 level5 소스에서 argv[1]의 길이 체크하는 알고리즘이 추가되었다.. argv[2]에 올리는 공격이 또 먹힐 것 같다 ㅡㅡ; 별로 의미가 없다.. 어차피 원래 쓰던 페이로드가 48바이트 였으니까;; 0xbffe7bc 에 argv[2] 주소가 있는 듯함. argv[2] 주소찾을 때 일단 페이로드 ( argv[2]주소를 몰라도 갯수만 맞춰서)를 인자로 주고 main 아무데나 브레이크포인트를 걸어서 위와 같이 찾아보았다. 아 근데;; 세그먼트 폴트가 일어남; 그래서 그냥 //buffer hunter 위에 printf("%x\n",argv[2]); 를 추가했다. 그리고 나서 돌려봄.. 또 주소차이가 나네. 다시 저 주소로 페이로드를 구성해서 공격해보겠음. ./dar..

orc.c를 열어보자. //buffer hunter 까지는 앞에 goblin 문제와 소스가 동일하다. 궁금하다면 goblin 풀이 포스팅을 보시길.. buffer hunter에 대해서 memset(buffer,0,40); 소스가 추가된다. memset함수는 앞전에 설명했듯이 초기화 시키는 것.. buffer의 주소부터 40만큼 0을 채워넣는다는 얘기다. 이전 공격과 마찬가지로.. argv[2]에 셸코드를 넣으면 RET위에 셸코드가 올라가는 것이므로 버퍼가 초기화 되어도 굳이 문제될것이 없다.. 설명안해도 될거라..생각된다. goblin과 똑같다.. 페이로드는 ./wolfman `perl -e 'print "\x90"x44,"\xd0\x75\xfe\xbf"'` `perl -e 'print "\x90"x10..

먼저 orc.c 를 열어보자. 오크란다;ㅎㅎ 이전 문제들 보단 소스가 꽤나 복잡다. 약간 소스 해석이 필요할 듯 싶다. 쭉쭉 읽히지 않음.. extern char **environ : 먼저 extern은 환경변수의 주소값을 저장하는 것이다. 환경변수에 관련된 내용이 나올 것이라 예상함. if(argc