Passion

서버가 열려있길래 다른 문제도 풀어봄.

read /home/singi1/key :p

ADDR : challenge.b10s.org

PORT : 8899

SSH INFO

id : agent

pw : agent

바이너리를 받아 헥스레이로 오픈.

코드를 분석해보면

1) argv[1] 만큼 메모리 할당. 

2) argv[3] 를 할당 받은 메모리로 복사. 

3) argv[2] 만큼 다시 메모리 할당

4) printf 출력. -> format string bug

처음엔 free 하고 나면 할당받은 메모리 자체가 날라가는 줄 알아서 고민했는데

디버깅을 해보니 free 이후에도 힙에 쓰여진 값은 계속 유지되고 있었으며, 

free() 이후에 다시 malloc을 호출하면 처음에 할당받은 address를 그대로 재할당 받음.

결국 argv[3]에 payload를 넣으면 printf()로 heap의 내용을 출력할 때 fsb가 터진다는 것이 포인트.

취약점을 알았으니 공격해보자. 

먼저 서버 환경.

보이는 것처럼 랜덤 스택 &힙 &라이브러리. 

원래는 free@got 를 system 함수 주소로 overwrite해서 원하는 명령어를 실행시키려고 했으나 

브루트포스가 필요해서 패스.

다른 방법이 없을까 고민하다 문제 바이너리의 디스어셈블 코드를 보니 다음과 같았다.

마지막 free()의 파라미터로 eax를 esp로 집어넣는다. 

이 eax는 malloc으로 재 할당 받은 메모리를 가리키는 포인터로,

argv[3], 즉 페이로드가 있는 주소를 의미한다. eax 호출할 수 있는 gadget을 찾아보니 이런 놈이 보인다. 

그렇다면 free@got (0x0804a004)를 0x080485db로 바꿔주고 argv[3]에 쉘코드를 넣어놓으면 실행될 것이다. 

그전에 heap에 실행권한이 있는지 확인. 

다행히도 실행권한이 있다. 오예.

페이로드를 만들다 보면 랜덤스택인지라 런타임 때마다 argv의 주소가 바뀌어서 공격하기가 까다로울 것이다. 

이것은 heap spray와 유사하게 타겟 주소를 잔뜩 뿌려놓으면 해결된다. 

payload 구성

argv[1] : malloc으로 할당되는 사이즈. 넉넉하게 준다.  

argv[2] : 재할당될 사이즈 + free@got adress 반복 

argv[2] : shellcode(execve) + format string 

최종 payload.

///home/singi1/singi1 `python -c 'print "100000"+" 100000"+"\x04\xa0\x04\x08\x06\xa0\x04\x08"*11250+" "+"\x90\x90\x90\x90\x31\xc9\x8d\x41\x17\xcd\x80\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x8d\x41\x0b\x89\xe3\xcd\x80"+"%2023c%5000$hn%32215c%5001$hn"'`

문제를 풀때마다 느끼지만 난 정말 fsb가 싫다.