0x.Wargame/ftz.hackerschool
-
-
0x19.ftz level200x.Wargame/ftz.hackerschool 2017. 9. 24. 17:23
0x19.ftz level20 역대 ftz중에 난이도가 젤 높았던, 쉘을 땄을 때 성취감이 가장 높았던 문제였다. fgets가 바이트를 체크하기에 기존에 사용했던 버퍼 오버플로우 공격을 하기에는 무리가 있어보인다. 그런데 printf 부분을 보면 포맷 스트링(format string) 취약점이 보인다. 바로 시도해보았다. %x를 사용했더니 값들이 나온다. 12바이트 떨어진 곳부터 스택이 시작한다는 것을 추측할 수 있었다. 메모리의 구조를 구상하자면 이와 같을 것이다. 0x0000004f 0x40152460 0x40098500 char bleh[80] dummy SFP RET 우리가 지금부터 할 일은 직접 메모리에 쉘 코드가 있는 주소를 쓰는 작업을 할 것이다. 그럼 어떤 방법으로 쉘 코드을 넣을 호출 지..
-
0x18.ftz level190x.Wargame/ftz.hackerschool 2017. 9. 23. 00:47
0x18.ftz level19 푸는 방법이 아주 다양한 문제였다. 기존의 환경변수를 활용한 방법부터 공유 라이브러리 system을 사용하여 버퍼 오버플로우를 하는 방법도 있는데, 내가 사용한 방법은 setreuid에 대한 어셈블리 코드를 만들어서 기존의 쉘 앞에 추가하여 환경변수를 이용한 방법이다. 문제는 이전과 아주 흡사하다. 오히려 18번에 비해서 너무나 짧아서 이질감이 들기까지 한다. 눈썰미가 좋은 편이라면 setreuid함수가 없다는 것을 찾았을 것이다. 이것은 우리에게 큰 시련을 준다. 바로 쉘 코드로 setreuid(3100,3100)을 제작해야하기 때문이다. # (setreuid(3100,3100) 쉘 코드 제작 쉘 코드는 다음과 같은 순서대로 제작할 것이다. 1) 함수의 시스템 콜 번호 확..
-
0x17.ftz level180x.Wargame/ftz.hackerschool 2017. 9. 21. 00:00
0x17.ftz level18 계속 미루고 미루다가 이제서야 18번 문제에 대한 포스팅을 적게 되었다 ㅠ. 힌트를 보면 예전과는 사뭇다르게 아주 길고 복잡해보인다. 처음보는 용어들이 등장하는데, 그 용어들에 대해서 간단하게 정리해두겠다. fd_set fds FD 변수 선언(디스크립터) FD_ZERO(&fds) fd_set의 모든 비트를 지움 FD_SET(STDIN_FILENO, &fds) 키보드의 입력값을 fds로 설정 FD_ISSET *fdset 중 소켓 fd에 해당하는 비트가 세트되어 있으면 양수값의 fd 리턴 긴 코드의 내용을 간단히 요약해보자면, string 배열이 100바이트의 크기로 선언이되고 그 뒤를 따라 x, count변수가 선언되고, fds 변수가 선언된다. 프로그램이 실행되면 Enter..
-
0x16.ftz level170x.Wargame/ftz.hackerschool 2017. 9. 6. 21:33
0x16.ftz level17 버퍼 오버플로우 문제이고, 맥북을 구매하고 처음으로 풀이를 작성하는 워게임 문제이다. 16번 문제라 거의 똑같지만 16번 문제에 있단 쉘 코드 실행부분이 없다는 것을 알 수 있다, 즉, 직접 쉘 코드를 실행시켜야 한다는 것을 의미한다. gdb로 뜯어보아도 달라진 점은 없는 것으로보아 기존의 문제들처럼 환경변수를 활용하면 쉽게 풀릴 것 같다. 환경변수를 export하였고, 아래의 소스코드를 활요하여 메모리에서의 주소를 확인해보았다. 근데 여기에서 문제점이 발생하였다. getenv를 통해 환경변수의 주소값을 구하는 과정에서 코드의 내용을 담고있는 파일 이름의 길이에 따라 다른 결과값이 출력된다는 것이다. 위와 같이 파일이름에 따라 다른 결과값이 출력된다. 이는 환경변수 선언시에..
-
0x15.ftz level 160x.Wargame/ftz.hackerschool 2017. 8. 14. 11:21
0x15.ftz level 16 또 다시 버퍼오버플로우 문제이다. 버퍼의 크기가 20인데 입력 값은 48을 받는다. 조금 다른 점은 call 함수 포인터를 통해 printit 함수의 값을 받는다는 것이다. shell 함수가 존재하는 것으로 보아, call 포인터 함수의 주소값을 printit 함수의 주소에서 shell 함수의 주소로 변경하면 되는 것으로 보인다. 디스어셈블 해보면 0x38 즉, 56바이트의 공간이 할당 되어 있다는 것을 알 수있다. 이는 버퍼의 크기 20 + 일정량의 dummy + crap 4바이트 + call 함수 포인터 4바이트를 합친 값이 된다. 다시 말해, 28바이트 만큼의 dummy 값이 존재한다고 말할 수 있다. 또한 힌트의 코드에서 fgets 다음에 call을 하는 것으로 보..
-
0x14.ftz level 150x.Wargame/ftz.hackerschool 2017. 8. 7. 12:59
0x14.ftz level 15 이번에도 leve 14와 비슷한 문제가 나왔다. 딱 봐도 전형적인 버퍼오버플로우 문제인데, 스택가드가 있으며 그 스택가드가 값이 아닌 포인터를 활용한다는 것을 알 수 있다. 디스어셈블을 해보면 0x38만큼의 크기가 할당되었다는 것과 cmpl구문을 통해 포인터를 통해 값을 비교한다는 것을 알 수 있다. fgets는 0xffffffc8부터 저장이 되므로 0xfffffff0 - 0xfffffc을 하면 40바이트가 나오는 것을 알 수 있다. 이를 통해 20바이트의 buf와 20바이트의 dummy값 이후에 check 4바이트가 온다는 것을 알 수 있고, 아래와 같이 확인하였다. 0xbffffca0가 buf의 시작주소이고, check의 시작주소가 0xbffffcc8인데 포인터이기 때..
-
0x13.ftz level 140x.Wargame/ftz.hackerschool 2017. 8. 2. 11:22
0x13.ftz level 14 드디어 쉘 코드를 작성하지 않아도 되는 문제가 나왔다. 힌트를 보니 또 버퍼오버플로우(BOF) 문제라는 사실을 알 수 있다. buf의 크기가 20인데 fgets는 45만큼을 받기때문이다. 또한 check라는 변수의 내용을 검사하는 것으로보아 check의 내용만 deadbeef로 바꾼다면 쉘 권한을 딸 수 있기에 쉘 코드를 따로 작성할 필요가 없어 보인다. 언제나 그렇듯 dummy의 크기를 확인해야 한다. 보니 더미의 크기를 합쳐서 0x38 즉, 56만큼의 공간이 할당되어 있다는 것을 알 수 있고, 입력값이 0xffffffc8에서부터 저장된다는 것도 알 수 있다. 좀 더 내려가보면 deadbeef를 cmp하는 구문을 찾을 수 있는데 0xfffffff0위치부터 비교한다는 것을..