11탄은 golem이다. 코드를 살펴보자. golem 프로그램의 특징은 다음과 같다. 1. 인자값이 2개 이상일 것2. 2번째 인자값은 48번째 값이 \xbf이어야 함3. 2번째 인자값을 buffer 변수로 strcpy로 복사4. buffer 변수에 저장된 값들을 전부 0으로 초기화.5. buffer+48부터 0xbfffffff 까지 0으로 초기화. 즉 RET 값을 제외한 buffer 이후의 값들은 전부 0으로 초기화 하는 것이다. 여기서 LD_PRELOAD 를 사용하라는 조언을 받아 해당 용어를 찾아보았다. LD_PRELOAD는 공유 라이브러리의 위치를 저장하는 환경변수 이름이다. 그렇다면 공유 라이브러리를 활용해서 이 문제를 공격해야 한다는 것을 알 수 있다. 공유 라이브러리는 스택 영역이 아닌 공유..
우선 코드를 살펴보도록 하자. 우선 코드를 분석하면서 지켜야할 규칙에 대해 분석해보도록 하자. 1. 인자값이 2개 이상인가 (argc < 2) 2. 환경변수 사용 X (egghunter) 3. argv[1]의 길이가 48보다 클 경우 프로그램 종료 (check the length of argument) 4. buffer[40] 변수를 이용한 공격 무효 (buffer hunter) 5. 모든 argv의 값들 초기화 (ultra argv hunter) 인자값들과 변수를 이용한 공격을 무효화 시키게 되었다. 그렇다면 메모리에 쉘코드를 저장할 수 있는 공간이 어디 있는지 생각을 해보았다. 모든 프로그램은 메모리의 맨 마지막 부분에 여러 환경변수들과 해당 프로그램에 대한 정보를 저장하고 있다는 점을 착안하여 es..
우선 코드를 살펴보도록 하자. 여러 검사 기능들이 사라지고 1가지가 추가 되었다. 바로 argv[1]에서 [46]번 인덱스에 \xff가 들어가면 printf를 수행하지 않고 종료가 되도록 설정 되었다. 이러한 점을 피하여 strcpy 까지 접근 하여야 버퍼 오버플로우를 일으킬 수 있는 상황이 된다. 평소에 접근하는 메모리 주소값들이 전부 0xbfff~~~~이런 식으로 접근하였는데 스택에 메모리가 구성되는 점을 이용하여 문제를 해결해야 한다. 스택에는 사전에 선언된 변수에 대하여 저장이 되는데 그 위에는 argv에 대한 공간이 구성되어 있다. 따라서 argv의 값을 매우 긴 값을 넣게 된다면 쉘코드를 넣게 될 argv나 buffer에 대하여 메모리 주소가 0xbfff~~~~를 벗어날 수 있게 된다. 문제를..
우선 troll.c의 내용을 살펴보도록 하자. 내용을 살펴보면 이전내용을 유지한 채로 1가지 추가조건으로 인자값을 2개로 제한했다는 것을 알 수 있다. 따라서 argv[2]에 쉘코드를 심어서 진행할 수 없음을 알 수 있다. 이때의 공격 방법은 심볼릭 링크를 사용하여 argv[0]을 쉘코드를 심도록 하는 것이다. 이때 ln -s 명령어를 사용해야하는데 평소에 쓰던 25bytes 쉘코드를 사용할 경우에는 \x2f가 담긴 쉘코드를 사용하면 안된다. 왜냐하면 /로 인식하여 하위디렉토리를 찾기 때문이다. 따라서 \x2f가 들어있지 않은 쉘코드를 찾았다. \xeb\x11\x5e\x31\xc9\xb1\x32\x80\x6c\x0e\xff\x01\x80\xe9\x01\x75\xf6\xeb\x05\xe8\xea\xff\x..
우선 코드를 살펴보도록 하자. 이전의 코드에서 추가된 내용은argv[0]의 길이에 대해 검증을 하는 것이다. argv[0]의 길이가 77이 되어야 다음으로 넘어갈 수 있는데 이에 대한 해결 방법으로는 단순히 프로그램을 실행시킬 때 ./orge로 수행하는 것이 아니라 .///////////////////////////////...//orge로 77의 길이를 맞춰서 프로그램을 실행시키면 정상적으로 진행할 수 있다. 다른 부분은 이전 단계와 변한게 없으므로 이전 단계와 동일한 방법으로 공격을 수행한다. argv[2]에 쉘코드를 넣어두고 주소를 출력하도록 하여 다음 값을 얻을 수 있었고 다음 주소로 공격을 시도해보자. 다음단계 쉘을 취득한 모습을 확인할 수 있다.
우선 코드를 확인해보도록 하자. argv[1]의 길이에 대하여 검증하는 기능을 추가하여 RET 의 다음에 이어서 작성하는 공격법도 차단했음을 알 수 있다. 이를 공격하기 위한 방법으로 wolfman 단계에서 사용하였던 공격방법과 마찬가지로 argv[2]에 쉘코드를 입력하여 공격해보았다. argv[2]에 주소를 우선 확인하고 이에 대해 RET주소를 수정하였다. 정상적으로 공격이 되어 다음 단계의 쉘을 취득할 수 있었다.
우선 코드의 내용을 확인하자 egghunter에 이어 buffer hunter라는 기능이 추가되었다. buffer hunter의 경우에는 입buffer에 쉘코드를 입력하여 쉘을 유도하지 못하도록 추가된 기능이며 memset(buffer, 0, 40)으로 buffer의 내용물을 비워 쉘코드를 입력하여도 무용지물이 되도록 하였다. 이에 해결방법으로는 2가지를 찾을 수 있었다. 1. RET 바로 뒷부분의 주소에 shellcode를 기록2. argv[2] 인자값으로 쉘코드를 입력하여 해당 위치로 이동. 2번 방법을 선택하여 문제를 풀어보도록 하자. 우선 argv[2]의 주소를 알기위해 코드를 복사하여 argv[2]의 주소를 출력하도록 설정하였다. argv[2]의 주소는 0xbffffc71이라는 것을 알 수 있었..
해당 문제의 소스코드를 읽어보도록 하자. 코드의 내용을 간단하게 살펴보면 다음과 같다. 1. environ( 환경변수값들) 을 전부 0으로 초기화한다. 2. argv[1][47]에는 '\xbf'가 들어가야 한다. buffer에 주어진 사이즈는 40바이트로 환경변수에 저장하지 않고 버퍼에 쉘코드를 덮어씌우는 방식으로 공격을 수행해야 할 것으로 예상된다. gdb로 분석을 하기 위해서 복사를 한 뒤에 분석하도록 하겠다. 복사를 할 때는 메모리 주소에 영향을 끼치는 것을 줄이기 위해 프로그램 이름의 길이를 똑같이 해준다. 전체적은 코드를 파악해보도록 하자. 우선 스택의 사이즈를 확인해보면 2c(44) 바이트를 확보한 것을 알 수 있다. 즉, RET의 주소는 buffer의 시작점으로부터 48바이트 떨어진 곳에 있..
3탄의 코드를 살펴보도록 하자. gets로 직접 입력을 받는다. 하지만 문자길이에 대해 체크하지 않기때문에 여기서 버퍼 오버프롤우가 일어날 수 있게된다. 변수의 사이즈를 고려하여 직접 쉘코드를 덮어씌우는건 힘들것으로 추측되어 환경변수에 쉘코드를 저장하고 RET의 값을 쉘코드의 주소로 덮어씌우는 것을 목표로 한다. 스택의 사이즈가 16인 것을 보면 더미가 존재하지 않는 것을 알 수 있다. 따라서 buf[16]+SFP[4]+RET 로 이루어진 것을 추측할 수 있다. 환경변수에 등록한 쉘코드에 대한 주소를 확인해보자. 0xbffffee7인 것을 확인했으므로 RET의 위치에 해당 값을 덮어씌워주면 된다. 공격에 성공하여 다음단계로 넘어갈 수 있게되었다.
우선 제공된 소스를 살펴보도록 하겠다. 버퍼의 길이를 줄여 버퍼 자체에 쉘코드를 입력하는 방식의 공격을 막았다. 이를 피해 오버플로우를 일으킬 수 있는 방법으로는 1탄에서 해결했던 방법처럼 환경변수로 쉘코드를 등록한 후 환경변수의 메모리 주소를 RET에 덮어씌우는 것이다. 스택의 구조를 보면 이번에도 더미가 없는 것을 알 수 있다. 따라서 스택의 구조는 buf[16]+SFP[4]+RET이므로 RET의 위치까지 임의의 값을 입력하고 RET 값을 쉘코드를 등록한 환경변수의 주소로 덮어씌워주면 된다. 쉘코드의 주소는 0xbffffee3이므로 다음 값을 리틀 엔디안 형식으로 입력하면 된다.