holinder4S

## 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~~!!!!]

## Christmas CTF_2016(StupidRSA,misc,100pts)

[Summary]

1. 랜덤 문자열을 RSA암호화하여 던져주고 사용자 입력을 받은 후 인크립트하여 같은 문자열인지 검사.

2. N과 e가 주어진다.

3. p,q를 구해야 한다. => d를 구할 수 있음.

4. 랜덤이 랜덤이 아니다.

[Analysis] - server.py

위 파이썬 서버 소스코드를 간단하게 분석해보면 gmpy2 모듈을 import한 후 random_state()함수를 이용하여 random state를 세팅한다.

그리고 line number 66에서 GeneratePrime(BaseNumber, randomST)함수를 이용하여 p와 q를 생성하는데 이 때 BaseNumber의 값이 

너무 커서 p와 q의 값이 항상 일정한 것을 확인할 수 있다.



 사실 대회때 풀때는 nc로 해당 IP에 접속하니까 N값이 아래 [그림 1]과 같이 항상 같은 것을 알 수 있었고 이를 통해 p,q의 값이 계속

계속 같은 값으로 세팅될것이라 생각하고 server.py를 돌린 후 조금 수정하여 line number 39에 GenerateKeys()함수에 p,q를 프린트하는

코드를 집어넣고 p, q가 어떤 값인지 확인하였다. 따라서 N의 p, q 값을 구할 수 있었고 아래 exploit코드를 통해 encrypted_data를

복호화하여 plain_data를 보내 flag를 획득할 수 있었다.

[그림 1] N값 동일

[Exploit Code] - stupidrsa_exploit.py

## Christmas CTF_2016(NMS,misc,100pts)

[Summary]

1. 패킷 파일이 주어진다.

2. NMS 쿼리(snmp)의 취약한 설정이 되어 있는 서버를 찾아야 함. 

3. 패킷을 와이어샤크로 보면 IP대역이 딱 봐도 수상해 보이는 곳이 있음.(52.~~)

4. 패킷은 네트워크 관리자 PC내부에서 캡쳐되었기 때문에 snmp community string(password)가 평문으로 노출

5. snmp-check라는 툴 사용

[Analysis] 

 우선 문제를 보면 아래 [그림 1]과 같다.

[그림 1] 문제

문제는 네트워크 담당자 PC에 침투한 이후 해커가 내부에서 패킷을 캡처한 상황으로 가정하였고, 취약한 설정을 가진

서버를 찾았다고 한다. 그리고 해당 패킷 파일을 던져주는데 간단히 와이어샤크의 [Statistics] - [Conversation] 기능을 이용하여 TCP,

UDP세션을 살펴보던 중 UDP세션에서 다음 [그림 2]와 같은 161번 포트를 이용하는 snmp 쿼리를 확인할 수 있었다. 특별한 점은

다른 IP대역은 get request패킷만 보이는데 "52.39~ "의 IP대역은 get response패킷까지 보이면서 snmp 쿼리가

정상 동작하는 것을 확인할 수 있었다.(cf. 패킷을 잘 살펴보면 scanning을 한 것처럼 보임)(그림 3 참조)

[그림 2] UDP 세션들

[그림 3] SNMP 쿼리 (community string_평문 전송)

패킷을 잘 보면 snmpv2c를 사용하는 것을 알 수 있고 이 버젼은 보안기능이 들어있지 않아 패킷이 평문으로 전송되면서 패스워드를 평문으로

전송하는데 위에서 얻을 수 있는 community string은 "public"과 "idcmonitoradmin"이었고 이렇게 탈취한 해당 community string을

이용하여 snmp-check라는 툴을 돌린 결과 아래 [그림 4, 5]와 같이 flag가 뜨는 것을 확인 할 수 있었다.


[Get Flag~~!!!!] 

[그림 4] snmp-check 커맨드

[그림 5] snmp-check 결과 - flag획득

끝~!

## Holyshield CTF_2016(pwnme,pwn)

[Summary]

1. hex-ray가 안됨.

2. 쉘코드 실행이 가능하지만 seccomp sandbox가 적용되어 read, write, close(?)의 syscall만 허용됨.

3. flag를 open한 후 동적할당 받은 영역에 랜덤한 offset값(rand()함수를 이용)을 더한 후 그 곳에 저장.

4. write syscall을 이용하여 해당 flag가 박혀있는 주소를 찾아 그 곳의 flag를 출력하는 shellcode를 작성.

5. shellcode의 크기는 0x20이내여야 함.

[Analysis] - (https://drive.google.com/open?id=0B12bAVEUfDg7dmRuMDJsTTJzX3M) 문제 링크

 우선 server가 동작하고 있는 환경에서 server의 9091포트로 접속하면 아래와 같이 shellcode를 입력 받고 

잘못된 쉘코드를 입력하면 segmentation fault가 뜬다.

[그림 1] pwnme 바이너리 실행

이제 이 바이너리를 분석해보면 우선 shellcode를 실행하기 전 seccomp sandbox를 세팅하는 루틴을

아래 [그림 2]와 같이 확인할 수 있으며 그렇게 중요하진 않다.

[그림 2] seccomp sandbox 룰 추가

그리고 바이너리의 처음부터 살펴보면 signal(alram)을 세팅하여 특정 시간이 지나면 종료되도록 되어 있고, server.py를 보면 알수 있는데

쉘코드가 저장되어 있는 파일을 오픈하여 fgets()로 읽은 다음 메모리에 저장한다.(후에 이 쉘코드가 실행됨)

그런 다음 srand(time(NULL))을 이용하여 random seed값을 준 다음 rand함수를 호출하여 아래 [그림 3]과 같이 특정 연산을 수행한다.

[그림 3] flag가 올라갈 메모리 영역의 주소를 랜덤하게 만들기 위한 루틴

물론 이 연산을 파악하는 건 중요하지 않으므로 넘어가도록 하겠다. 이렇게 offset을 랜덤하게 설정한 후 var_4C변수에 저장을 한 다음 

"flag"라는 파일을 open한 다음 fgets()함수를 이용하여 값을 읽어들인 후 아래 [그림 4]와 같이 메모리에 적재 한다.

[그림 4] flag open & read

여기까지 다 끝내고 나면 마지막으로 "call eax"를 하여 shellcode를 실행시키는데 call eax를 실행하기 전 레지스터와 스택 상황을 보면

아래 [그림 5]와 같다.

[그림 5] shellcode 실행 전 스택 & 레지스터 상황

스택의 esp의 값인 0xbffff0f4에서 0x2326 offset만큼 더하면 동적할당 받은 힙 영역의 주소가 저장되어 있으며 이 주소에 앞에서 만든 

random offset값을 더한 곳에 실제 flag가 들어 있었다. 처음에는 random offset값이 스택영역에 저장되어 있을 줄 모르고 브루트 포싱을

이용하여 rand()를 깨보려고 했으나 범위도 크고 출력 server에서 0x6c만큼 read한 값을 주기 때문에 삽질을 많이 했다.

random_offset은 [그림 4]에서 봤듯이 ebp-0x4c에 위치해 있으므로 이 값을 읽어 들여와 malloc()으로 할당받은 힙 주소에 더하는 

쉘코드를 작성하여 write() syscall로 stdout에 출력하기만 하면 되었다.

[server.py]

[shellcode]

[Exploit Code] - pwnme_exploiyt.py

[Get Flag~~!!!!]

끝~!

## RC3 CTF_2016(IMS-hard,pwn,400pts)

[Summary]

1. OOB memory leak(stack) vuln -> canary leak, libc leak

2. NX, Stack Canary Bypass 

3. ROP exploit

4. Use libc-database -> libc version check

[Exploit Code]

## RC3 CTF_2016(IMS-easy,pwn,150pts)

[Summary]

1. OOB memory leak(stack) vuln

2. Shellcode Execute & EIP control

[Exploit Code]