[HackCTF] Baisc BOF 2

[HackCTF] Basic_BOF #2

Date	@Jan 04, 2020
Tags	report

1. 문제

2번 문제인 basic_bof2를 먼저 실행 시켜보면 다음과 같다

어떠한 동작을 하는 프로그램인지 확인하기 위해 직접 실행을 시켜보았다. hi라는 문자열을 입력하고 엔터를 치니까 다음과 같이 출력이 되었다.

이것만 봐서는 어떠한 동작을 하는 코드인지 모르기 때문에 아이다를 이용하여 바이너리를 뜯어보았다.

아이다의 hex-ray 기능을 이용하여 c언어 코드를 확인할 수 가 있었다.

7번째 라인에서 fgets를 통해 입력을 받는다. 133바이트 만큼 입력을 받을 수 있으므로 bof 가 일어날 가능성이 있다

2. 접근방법

4번째 라인에서 void 형 함수 포인터를 선언한 것을 알 수 있다.

6번째 라인에서 sup 라는 함수를 형변환을 통해 v5변수에 삽입하고,

8번째 라인에서 호출한다.

그렇다면 fgets를 통해 bof를 일으키고 v5 변수에 시스템 함수 같은 것을 오버라이트하면 될 것으로 보인다.

현재 메모리 구조는 다음과 같다

ebp 기준으로 0x8C 만큼 떨어진 곳에 1바이트 변수 s의 공간이 할당되어 있고, v5는 0xc 크기만큼 할당되어 있다.

fgets 함수가 133바이트 만큼 입력을 받을 수 있으므로, v5 영역에 원하는 값을 bof로 덮을 수 있다

그렇다면 다시 코드를 봐보자. 1번 문제와는 달리 해당 main문에는 쉘을 실행시키는 부분이 없다. 그렇다면 시스템 함수를 출제자가 제공 해줬는지 확인을 해볼 필요가 있다.

sup 함수 위에 shell 이라는 함수가 있다. 누가봐도 수상하기 때문에 해당함수를 확인 해보면 return 값으로 시스템함수를 실행시켜주는 것을 알 수 있다.

따라서 bof를 통해 v5변수를 해당 shell() 함수의 주소로 변경해주면 쉘을 획득할 수 있을 것이다.

ida 혹은 gdb를 통해 shell() 함수의 주소를 확인 가능하다

3. 풀이

4. 몰랐던 개념

2번까지 문제는 기초 문제이기 때문에 쉽게 풀렸다. 하지만 다른 write-up을 보는 도중 하나 알게 된 사실이 있다.

문제를 풀기전, 해당 바이너리에 적용되어 있는 보호기법을 먼저 확인 하는 것이 좋다

• 명령어 : checksec "파일명"

  

  1. Arch
     • 32비트 elf 파일
  2. RELRO
     • ELF 바이너리 또는 프로세스의 데이터 섹션을 보호하는 기술로써, 바이너리 컴파일시 해당 옵션을 주면, .ctors, .dtors, .jcr, .dynamic, .got 섹션이 읽기전용상태(Read-Only)가 된다.
  3. Stack canary
     • 랜덤 값인 카나리를 ebp와 지역 변수 사이에 위치시킨 뒤, 함수가 시작할 때 카나리 값을 저장하고, 함수가 끝나기 전에 카나리 값이 변조됐는지 여부를 체크한다.
  4. NX bit
     • 메모리에서 코드 실행이 되지 못하게 막는 것
  5. PIE
     • 라이브러리 함수를 호출할때 위치에 독립적인 실행파일, 즉 프로그램을 실행할 때마다 매핑되는 주소가 달라진다.

  보호기법에 대한 내용을 요약한 것으로, 따로 보호기법에 대한 내용을 정리해야겠다.