k0zel's lab

매번 pwnable 문제를 풀때 그러지만 엄한데서 삽질을 하며 시간을 날렸습니다...허허

역시 풀이의 방향성을 잡는게 가장 어렵고 중요한것같습니다.

2018.8.25.

어렵다 어려워

+ [Grotesque] aeg

+ [Grotesque] sudoku

+ [Grotesque] rootkit

+ [Grotesque] dos4fun

+ [Hacker's Secret] exploitable

+ [Rookiss] loveletter

몇달 전에 풀던 문젠데 로컬 환경에선 쉘 다 띄워놓고  일이 바빠서 문제 마무리를 못하고 있었네요.

풀면서 어려웠던 점(?)은 'Hacker's secret 문젠데 어떤 어려운 기법을 써야할까?'라는 생각때문에 문제를 어렵게 꼬아서 생각했던 것일까요

한문제 한문제 겨우겨우 풀고 있습니다...허허

이번 문제 풀이를 위한 의식의 흐름은

- DOSBox를 이용한 동적디버깅환경 구축

- 다양한 삽질? 을 통한 취약점 확인

- Dos opcode 분석을 통한 쉘코드 작성(사실 작성이라기보다 코드 재활용이라고 해야겠습니다)

인 것 같네요.

월요병을 물리치고 한 문제를 풀어서 기분이 좋습니다.

문제 풀이의 거의 한 80%는 라이브러리 덕이지만 

어쨋든 오늘 문제 풀이의 골자는 복잡한 문제 풀이를 위한 알고리즘 구현은 어렵지만 똑똑한 사람들이 라이브러리를 만들어놨고 그냥 잘쓰면 된다? 이겠네요.

막상 풀고 나서 보니까 별거 없는데 풀때는 왜그렇게 어려운지 모르겠습니다.

몇주만에 푼건지...

대충 정리해보자면

1. 생성된 바이너리 address 및 중요값 추출.

2. ANGR을 이용해 키값 확인

3. EIP 컨트롤, 취약점 공격...인데 아무래도 쓸 수 있는 버퍼의 크기가 크다보니 payload를 맘대로 구성하기 좋음

4. 실행권한 부여

5. /bin/sh 실행

이런거였겠죠?

문제 푸느라, 사실 삽질하느라 날아간 일요일을 기리며 허허...

주말저녁에 문제 풀고 writeup 쓰고 있는게 싱숭생숭하면서도 보람차네요(사실 풀고나면 별거 아니지만요)

======================================================

보호 기법 확인(checksec)

CANARY, NX 확인, 서버 환경 상 ASLR enable.

x86 binary, 실행 시 사용자의 입력을 받고 프로그램 종료.

겉보기엔 모르니 리버싱을 해봅시다

main() 에서 사용자 입력을 받아 한 글자씩 파싱. do_brainfuck() 함수 내부에서 각 case에 알맞는 기능을 처리

여기서 p 변수를 살펴보면 main() 에서 p = &tape 로 초기화하고 이때 값은 0x804a0a0 .

이 함수에서 p 의 값을 이용해 ++, --, putchar ... 등등 처리를 해주므로 이것을 이용해 볼 수 있겠다.

정성 들여 쓴글이 다 날라갔습니다 허허허

인생은 참 무엇인지... 최소한의 기록만 남겨야겠습니다.

======================================================

보호 기법 확인(checksec)

CANARY, NX 확인, 서버 환경 상 ASLR enable.

Canary 계산

Canary 계산을 위해 unix timestamp 값과 captcha 를 입력 받아 계산해주는 코드를 짰다. 대~~충

python 코드에서 위 프로그램 호출 후 return 된 값을 & 0xffffffff 해 4바이트 처리를 해 줌

EIP control 시도

Canary 및 return address 위치 확인을 위해 gdb로 메모리 분석

A*512 를 base64 encoding 후 입력 했을 때

Payload = A * 512 + Canary 4byte + A*12 + Return addr 4byte 

위 Payload 를 base64 encoding 해 입력하면 정상적으로 EIP control 이 될 것이고 로컬 테스트 완료 함

/bin/sh 실행 방법 구상

EIP control 은 됐고... 쉘은 어떻게 잡아야될 지 생각해보자

ASLR이 적용되어 있으므로

1. Memory leak  -> libc base addr 계산 -> system(/bin/sh) 실행

2. 고정된 주소(code, bss .... ) 사용

둘 중 하나의 방법을 사용해야 할텐데 main() 함수를 보면 다음과 같이 system() 을 call 하는 곳이 있다

이제 /bin/sh 문자열만 메모리에 올리고 주소만 알면 되는건데, 변수를 살펴보면 다음과 같이 고정된 주소를 사용하는 g_buf가 있다

근데 g_buf에 들어가는 값은 base64 encoding된 값이고, decoding된 값은 스택에 들어가서 주소가 유동적임

-  "/bin/sh\n00" + encoded value  로 payload를 구성해 보내볼까?

     :  base64 decoding 이 정상적으로 될 리 없음.

- 그냥 memory leak 할까...

     :  leak 없이 해보려고 했는데 약간 아쉬움?

- 설마 base64 encoding해 /bin/sh 문자열이 될 수 있나?

     :  /bin/sh 로 디코딩 시 패딩 에러... 발생해 /bin//sh 로 사용해 정상적으로 인코딩, 디코딩 되는 것을 확인함

     : base64 인코딩으로 NULL은 만들지 못하지만 Payload 제일 마지막에 붙이면 NULL 삽입 없이 되지 않을까

결과적으로 

Payload = A * 512 + Canary 4byte + addr_of_system_call + addr_of_/bin//sh + 0xfdb8a7fffb21

로 Payload 구성, base64 encoding된 값을 입력해 정상적으로 쉘 획득 함

공격 코드

바이너리 보안기법 검사(checksec.sh)

소스코드 확인

main() 에서 /dev/urandom을 이용해 8바이트 읽고 이것을 key 값으로 사용한다

이후 alloca를 이용해 0x12345 & key 만큼 메모리 할당하는데 fsb를 이용해 직접적으로 key 값에 접근하짐 못하게 하기위한 것 같다.

뭐 아무튼 fsb() 함수 내에서 다음과 같은 코드로 인해 format string bug가 발생

gdb를 이용해 fsb 발생 전, 후 스택 상태를 살펴보자 

GDB를 이용한 스택 값 확인

fsb() 에서 printf 하기 직전에 break point 설정

소스코드 상 사용자 입력은 data 영역(변수 buf)로 들어가기 때문에 스택에서 사용할 수 없다

하지만 위에서 빨간색으로 표시한 것과 같이

i) 스택의 특정 위치를 가리키는 포인터가 저장되어 있고

ii) 위 위치에 접근 가능하기 때문에

Double staged fsb를 사용할 수 있다

그럼 어디 메모리 주소를 쓰고 그 주소를 뭘로 덮을까

objdump 를 이용해 바이너리의 GOT 주소를 확인

for loop를 돌면서 printf를 호출해주기때문에 printf의 GOT 주소를 덮어주면 되겠고

control flow hijacking 해서 뛸 주소는

fsb() 내에서 execve(/bin/sh) 해주는 부분으로 뛰면 되겠다.

정리해보면 

i) 첫번째 fsb로 스택 내 0x804a004 값 쓰기

ii) 두번째 fsb로 0x804a004 값을 0x080486ab 로

(여기서 먼저 쓸 값보다 두번째 쓸 값이 작으므로 fsb 한번에 두개 값을 써야 하면 성가셔질뻔? 두번째 fsb사이의 값을 엄청 크게해서 0x1080486ab 로 만들어야하나? 어차피 여기선 4번 쓸 수 있기때문에 편함)

Exploit 진행 및 결과 확인

FSB 발생 확인

Exploit 코드