해커스쿨 FTZ level14

level14 --- what that nigga want?

우선 level14의 디렉터리를 확인한다.

attackme라는 의심스러운 파일이 존재한다. attackme는 level15의 권한을 가지고 있고, setuid가 걸려있는 파일이다.

우리가 공격할 대상이 attackme일 가능성이 크다고 생각하고 hint를 보자.

hint를 보니 우리가 쉘 코드를 삽입하여 쉘을 띄우는 것이 아니다.

check == 0xdeadbeef가 되면 프로그램이 자체적으로 쉘을 띄워준다.

int check; 변수는 초기화 되지 않았지만 우리가 버퍼 오버플로우를 통해서 0xdeadbeef로 write하면 된다.

지금까지 공부한 것을 바탕으로 gdb를 통해 attackme를 분석해보자.

우리는 int crap, int check, char buf[20]을 통해 0x1C(28) byte를 사용할것이라고 예상할 수 있다.

하지만 프로그램을 분석해본 결과 0x38(56) byte를 사용하고 있다.

왜 추가적인 메모리가 사용되었을까?

그것은 최적화를 위해 gcc가 삽입한 공간이다. 우리는 이러한 공간을 dummy라고 부른다.

dummy가 28 byte가사용되었는데 정확히 어느 공간에 몇 바이트 할당 되었는지 알 수 없다.

따라서 예제 코드를 통해서 dummy가 어디에 삽입되는지 확인해보자.

#include <stdio.h>
#include <unistd.h>
 
int main()
{
        int crap;
        int check;
        char buf[20];
        fgets(buf, 45, stdin);
 
        if(check==0xdeadbeef)
        {
                setreuid(3095, 3095);
                system("/bin/sh");
        }
 
   printf(" Input is: %x\n &buf: %p\n &check:%p\n &crap :%p\n", buf, buf, &check, &crap);
}
 

위 소스를 컴파일 해서 실행하면 아래와 같이 나온다.

buf와 check 사이에 0x14(20) byte가 사용될 것이라고 예상했는데 0x28(40) byte가 사용되었다.

여기서 0x14(20) byte의 dummy가 사용되었음을 알 수 있다.

그림으로 그려보면 아래와 같이 나타낼 수 있다.

우리는 check에 0xdeadbeef를 write하면 되니, 40 byte의 의미 없는 값을 write하고 이어서 0xdeadbeef를 write하면 쉘을 딸 수 있다.

예제 소스가 아닌 우리가 공격해야할 대상인 attackme를 분석해보자.

우리는 check(0xbffe148)을 0xdeadbeef로 덮어쓰면 공격에 성공할 것이다.