(57/500) pwnable.kr - ascii_easy

여행 다녀온 후 오랜만에 푼 문제이다.

문제는 ascii_easy !

문제 이름대로 쉬운? (다른문제에 비해)

(ascii_easy)

문제내용은 이렇다.

(문제 내용)

일단 접속하여 소스코드부터 확인하였다.

(소스코드)

소스코드를 보니 아스키문자인지 체크하는 함수가 들어있다.
인자로 아스키문자가 아니면 쫓겨난다.

그리고 취약한 함수를 대놓고 vuln 이름으로 만들어놓았다. 
이 부분을 버퍼 오버플로우하는 거구만! (다행히 스택카나리가 적용되어있지 않았다.)

그리고 주목되는? 부분이 있었다.

(중요부분)

???
libc-2.15.so 파일을 가져다가 통째로 메모리에 쿵 올린다.

mmap 함수를 gdb로 동작확인해보겠다.

(mmap 함수 인자)

인자를 보니 파일 내용이 덤프될 주소 0x5555e000 이 보인다.

함수를 실행하여 덤프된 주소를 보자!

(덤프된 내용)

처음에는 데이터가 매핑이 이상하게 되었나 싶었다. (여기서 조금 헤맸다.)
(위의 캡쳐 화면은 내가 so 파일을 헥스로 수정하여 그대로 저장시킨 값이다. 그래서 위처럼 나온것)

아래 내용은 hex모드로 so 파일을 연 것이다.

(so 파일)

여기서 30303030... 이 뭘까 싶었는데 내가 헥스로 수정하고 다시 제대로 저장해야하는데 그대로 저장을 시켜서 위 화면대로 저장이 된것이다... 그렇기 때문에 아래와 같이

00000000: ~~~~ 헥스모드에 나와있는 텍스트가 그대로 메모리에 올라간 것이다...

(헥스모드 상황)

그렇군! 여기서 파일의 데이터가 떡하니 올라가는 것을 확인했으니 그 다음부터는 고민 없이
이 파일에 Nop 코드와 쉘코드를 넣어주어 bof 시킨 후 ret 주소에 해당 쉘코드 주소를 넣어주면 된다.

사실 여기서 Nop 코드 없이 정확히 쉘코드 주소를 맞출 수 있기 때문에 필요없긴 하지만
그냥 넣었다.

테스트!
놉코드 100개와 A 10개를 넣어보았다.

(테스트!)

그 후 메모리 상황!

(메모리 모습)

그렇다면 내가 만들수 있는 아스키문자중 가장 작은 값이
55562121 -> UV!! 

이다. 그렇기에 해당 주소까지 놉이 몇개 필요한지 계산해본다.

(Nop 개수)

16진수로 4121 
10진수로 16673개가 필요하다.

놉코드를 4개 더 추가시켜서 ( 놉코드 안에 안착시키기 위해)

그 뒤에 쉘코드를 이어붙여준다.

(so 파일 구성)

이렇게 하고 UV!! (55562121) 주소로 가보면

(쉘코드)

놉코드와 쉘코드를 만날 수 있다.

이제 원본 파일에 링크를 걸어서 실행할 것이다.(원본파일에 setuid가 걸려있기 때문에!)

취약 함수를 오버플로우 시켜 (더미 32개) ret 주소에 UV!! 를 넣어준다. (엔디안에 맞춰서)

(공격 성공!)

쉘을 획득하였다.

의도된 풀이를 보니 execve 함수를 이용하여 풀게 되어있다. execve 함수 주소를 보니 우리가 구성할 수 있는 아스키코드 주소로 되어있는 걸 확인 할 수 있다.

(의도된 방법)