LOB_11.skeleton->golem

golem.c의 내용인데 이제 buffer변수로부터 그 위쪽의 스텍을 전부 지워버린다.

메모리를 샅샅히 뒤져봤지만 더이상 입력값이 남아있을만한 공간이 없다.

결론부터 얘기하자면 이 문제는 LD_PRELOAD라는 환경변수를 이용해서 풀었다.

이 환경변수에 파일을 등록해주면 bash에서 프로그램 실행시 해당 파일을 먼저 라이브러리에 로딩해준다.

그리고 libc와 같은 이름의 함수가 있다고 해도 이 파일이 우선순위를 가진다.

쉽게말해서 golem 프로그램에서 사용하는 printf같은 함수를 등록해서 전혀 다른 기능을 하게끔 바꿔버릴 수도 있는 것이다.

printf의 기능을

void printf(){

setreuid(geteuid(), geteuid());

execve("/bin/sh", NULL, NULL);

}

이런식으로 바꿔줄 수도 있는 것이다.

하지만 안타깝게도 setuid가 걸린 프로그램에서는 제대로 동작하지 않는다.

그렇다고 완전히 무시되는 것은 아니고 파일명은 올라가게된다.

LD_PRELOAD에 이름이 쉘코드인 파일을 올려놓으면 프로그램이 실행되면서 어딘가에 쉘코드가 적재될 것이다.

그 주소가 buffer변수의 주소보다 낮은 주소에 올라간다면 stack destroyer의 영향을 받지 않아서 쉘코드를 실행시킬 수 있을 것이다.

그럼 우선 이름이 쉘코드인 라이브러리 파일을 만들어주자.

위와같이 gcc -shared -fPIC 옵션을 사용하면 LD_PRELOAD에 올라갈 파일을 만들어줄 수 있다.

어차피 setuid가 걸린 golem 프로그램에서는 라이브러리가 제대로 실행되지 않기 때문에 oxqo.c의 내용 자체는 별로 중요하지 않다. 이름을 쉘코드로 만들어서 메모리 어딘가에 올리는 것이 목적이다.

주의할점은 "\x2f"가 들어가지 않은 쉘코드를 사용했다는 점이다. 전처럼 디렉토리를 만들어서 해도 되지만 그냥 다양항 방식으로 해보기 위해 48바이트짜리 2f가 없는 쉘코드를 사용했다.

파일을 만들어준 다음 LD_PRELOAD 환경변수에 등록해줬다.

이제 원본 golem프로그램을 복사해와서 동적분석을 통해 쉘코드가 어디에 올라가는지 살펴보자.

main의 프롤로그가 끝나고 나서 살펴보니 ebp의 주소가 0xbffffaa8이다.

저부분을 기준으로 0xbfffffff부분까지 뒷쪽은 전부 memset되어 버릴테니 저것보다 낮은 주소를 검색해보자.

gdb 버전이 높다면 find 명령어를 사용해도 되지만..  사용할수 없을 경우 이런식으로 변수를 이용해서 검색할 수 있다.

ebp주소부터 1씩 빼가면서 쉘코드의 앞부분과 일치하는지 살펴본 결과 0xbffff68a부분에 쉘코드가 로드된 것을 볼 수 있다.

복사본 golem에서 저주소로 리턴을 주고 공격하자 segmetationfalt가 뜬다. 아마 gdb에서 실행될때와 주소차이가 좀 있는듯.

core파일을 분석해서 정확한 주소를 알아냈다. 0xbffff64a

찾는방법은 위와 동일하게 메모리를 가르키는 변수를 하나 주고 감소시키면서 찾았다.

성공했다.

자세히 보면 tmp 폴더에서 ../golem으로 원본파일을 실행시킨 것이 보이는데 LD_PRELOAD=./쉘코드 이런식으로 입력을 해줘서 원본이 있는 폴더에서 실행시키자 로드할 파일을 못찾는 사태가 발생했다. 원래부터 LD_PRELOAD에 전체경로를 입력했으면 이렇게 안해도 되었으나... 포스팅의 완성도가 조금 떨어진다는것 빼고는 별 다를점은 없으므로 패스

끝-