Wargame

cobolt로 로그인하면 goblin 문제를 볼 수 있다. goblin 문제를 실행해본다면 입력을 받은 뒤, 입력을 받은 값을 똑같이 출력해준다. 소스코드를 확인해보면 bof에 취약한 대표적인 함수인 gets 함수로 입력을 받는다. 이 gets 함수는 입력 값의 길이에 제한을 두지 않기 때문에, 입력 값이 저장되는 buffer 변수의 크기인 16byte 이상 입력을 한다면 overflow가 발생한다. 딱봐도 쉘 코드를 buffer에 삽입하기에는 공간이 부족하기 때문에 환경변수를 이용해야 될 것 같다고 생각했다. 일단 buffer가 16byte 크기고 다른 변수들은 존재하지 않기 때문에 굳이 gdb로 열어볼 필요 없이 blind 상태로도 exploit이 가능할 것 같았다. buffer의 크기가 16byte..

gate 문제를 풀 때 wsl telnet을 이용해 접속했다가 쉘이 얻어지지 않는 문제가 생겨, 이번에는 putty로 접속했다. 문제 파일 cobolt와 소스코드 cobolt.c가 주어져 있다. 문제 파일을 실행해보니 인자를 받는 것을 알 수 있었다. 많은 '1'을 인자로 주니 Segmentation fault가 터진 것을 보아 bof 취약점이 있을 가능성이 높다. 소스코드를 확인해보면 인자 값을 strcpy 함수로 16byte 크기의 buffer에 복사해주는데, gate 때와 마찬가지로 길이를 검증하는 로직이나 함수를 사용하지 않는다. 따라서 인자 값으로 16byte보다 긴 값을 준다면 overflow가 발생한다. gate와 마찬가지로 buf에 쉘 코드를 삽입한 뒤 ret를 buf의 주소로 조작해 쉘을..

wsl ubuntu에서 telnet을 이용해서 접속해봤다. 1단계 id와 pw는 gate/gate다. ls 명령어로 무슨 파일이 있는지 확인해봤다. gremlin, gremlin.c라는 문제 파일과 그 소스코드가 존재하는 것을 알 수 있다. gremlincp 파일은 풀이 과정에서 디버깅을 위해 gremlin 파일을 복사한 것이다. 권한을 확인해보면 gremlin 파일에는 gremlin 계정으로 setuid가 걸려있다. 이 문제 파일을 공격한다면 gremlin 권한으로 된 쉘을 얻을 수 있을 것이다. int main(int argc, char *argv[]) { char buffer[256]; if(argc < 2){ printf("argv error\n"); exit(0); } strcpy(buffer,..

LOB를 할 때 정상적으로 exploit이 될 만한 코드도 안되는 경우가 있는데, 그 이유는 lob의 bash 버전이 낮기 때문에 \xff를 \x00으로 처리하기 때문이다. 이 말인 즉슨 ret를 \xff가 들어가는 주소로 변조한다 가정하면, 이 \xff는 \x00으로 인식되기 때문에 \xff가 입력되는 순간 더 이상의 입력을 받지 않게 된다. 따라서 정상적인 공격이 힘들어지는 것이다. 해결 방법은 간단하다. root/hackerschoolbof로 로그인한 후 vi /etc/passwd를 입력해 vi 에디터로 진입하고 :를 입력 후 %s/bash/bash2/를 입력해준다면 bash 버전이 2로 바뀌게 되면서 원활한 문제 풀이가 가능해진다. -login- id : root pw : hackerschoolb..

보호되어 있는 글입니다.

level19로 로그인한 후 hint를 확인해보면 소스코드가 나온다. 전 단계에서 많은 양의 코드를 보여줬기에 19 level은 더 많거나 복잡할 줄 알았지만 예상보다 간단했다. 소스코드도 작고 대놓고 gets 함수가 보여서 bof가 일어남을 알 수 있다. 공격은 gets를 통해 overflow를 일으켜 ret를 쉘 코드가 들어간 환경변수의 주소로 변조하면 될 것 같다. 이번 단계는 setuid가 없기 때문에 setuid가 포함된 쉘 코드를 써야겠다. main의 함수 프롤로그 부분과 gets 함수 부분에 bp를 걸고 실행한다면 ret와 buf의 스택 주소를 알 수 있다. ret : 0xbffff45c buf : 0xbffff430 따라서 ret와 buf 사이의 거리는 44byte인 것을 알 수 있다. r..

level18로 로그인하고 힌트를 보면 굉장히 긴 코드가 나온다. 다른 level에 없던 긴 코드에 조금 쫄았으나, 취약점은 굉장히 간단하다. #include #include #include #include void shellout(void); int main() { char string[100]; int check; int x = 0; int count = 0; fd_set fds; printf("Enter your command: "); fflush(stdout); while(1) { if(count >= 100) printf("what are you trying to do?\n"); if(check == 0xdeadbeef) shellout(); else { FD_ZERO(&fds); FD_SET(..

level17로 로그인한 후 hint 파일을 확인해보면, 역시 소스코드가 주어져 있다. level16과 마찬가지로 call에 printit가 들어가고 fgets를 통해 overflow가 일어나는데, 이번에는 shell을 얻게 해주는 함수가 없다. shell을 얻게 해주는 함수가 없으므로 쉘 코드를 환경변수에 삽입한 뒤 주소를 구한 뒤, stack overflow를 통해 call의 값을 쉘 코드가 들어간 환경변수의 주소로 변조해주면 될 것 같다. export 명령어로 쉘 코드를 환경변수에 등록한 뒤 미리 빌드해둔 tmp 폴더 내 env 파일을 실행해서 쉘 코드가 들어 있는 환경변수의 주소를 구했다.(앞에 \x90을 추가해준 이유는 \x90 없이 쉘 코드만 넣어준다면 제대로 쉘이 얻어지지 않기 때문이다.) ..

level16으로 로그인한 후 hint 파일을 확인하면 마찬가지로 소스코드가 주어져 있다. 이번에는 shell을 얻게 해주는 shell 함수가 있어서 ret overwrite인가 했는데, 그게 아니라 bof를 통해 call 포인터의 값을 shell 함수의 주소로 변조하는 것이었다. 소스코드를 확인해보면 void형 포인터 변수 call에 printit 함수의 주소를 넣어주는데, 프로그램의 마지막에서 이 call에 들어 있는 주소의 함수를 실행해 준다. 참고로 이 printit 함수는 "Hello there!\n"를 출력시켜주는 기능을 한다. 마찬가지로 fgets 함수로 buf의 크기보다 큰 48byte 입력을 받는데, 여기서 buf의 크기는 20byte이므로 28byte의 overflow가 일어난다. 이를..

level15로 로그인한 후 hint 파일을 확인하면 level14의 힌트 코드와 비슷한 코드가 나온다. 다른 점은 0xdeadbeef와 비교하는 대상이 check의 값이 아닌 포인터를 써줘서 check의 값이 가리키는 주소의 값이다. 마찬가지로 buf의 크기는 20이지만 fgets 함수를 통해 45byte만큼 입력을 받기 때문에 25byte overflow 된다. 원래는 hint 파일의 소스 코드를 복사해 tmp 폴더에서 새 파일을 빌드하고 디버깅했지만, 이번 문제의 경우 주소가 굉장히 중요하므로 똑같은 환경에서 분석하기 위해 cp 명령어로 문제 파일을 tmp 폴더에 복사했다. (처음에는 멋모르고 복사해서 새로 빌드했다가 주소 값이 안 맞아 exploit에 난항을 겪었다) gdb를 통해 buf와 che..