소프트웨어 버그 헌팅 - 3.1 (소스코드 검사 및 퍼징 실습)

소프트웨어 버그 헌팅 - 3.1 (소스코드 검사 및 퍼징 실습)
(소스코드 오디팅, 취약점 접근 방법 및 피치 퍼징 실습)

이번 포스팅에서는 피치 퍼징을 통해서 퍼징하는 방법을 실습해볼 것이다.

107.zip

Peach Crash Data.zip

peach-3.1.124-win-x86-release.zip

dotNetFx40_full_x86_x64

Gomplayer 2.1.3

KMplayer_3.3.0.33

mp4reader_v0.9.0.6

sdksetup

VCForPython27

VUplayersetup_2.44_US

xmlcopyeditor-1.2.1.3-64

파일을 준비하여 Win7으로 옮겨준다.
(3일차-실습자료-Peach-filefuzzing,설치파일,010Editorwin32installer08,107,Peach crash data)

---

소스코드 오디팅
버그, 보안결합 등을 찾기 위해 소스코드를 종합적으로 분석하는 광범위한 방법
API 기반 버그, 외부 자원과의 상호작용, 프로그래밍 구조 에러 등 문제가 될만한 부분을 중점적으로 공략
모든 코드를 다 보는 것은 불가능하며, 비효율적

API 기반 버그
API 자체가 보안상 결함이 있거나 잘못 사용할 경우 결함이 될 수 있는 '위험한' API의 사용 여부를 살펴보는 방법
- 잠재적으로 위협을 내포하고 있는 API : sprint(), strcpy(), strcat() 등
- 메모리 할당과 해제와 관련된 API : alloc(), malloc(), free() 등
- 다루기 힘들거나 구현이 복잡한 API : 스레드 관련 API, IPC관련 API 등

우리는 IDA Python 코드를 통해서 취약한 함수를 사용하는 곳을 찾아주는 스크립트를 구현하였음
(3.1 버전 확인)

프로그래밍 구조 에러
- 잘못된 프로그래밍 구조 설계로 인한 문제점
- 정수형 데이터의 범위, 음수 표현 여부
- 정수형 경계 문제에 취약한 로직 검사 루틴 구현
- 잘못된 경계값을 가지는 반복문
- 검증되지 않은 변수들

외부 리소스와의 상호 작용
- 애플리케이션이 외부 엔티티들과 위험한 상호 작용을 하는 경우 발생하는 문제
- RPC/COM/Pipe 또는 IPC 형태의 기능을 통해 권한을 상승을 처리하는 코드
- execve()/CreateProcess()와 같은 API를 통한 외부 프로그램 실행 - 환경 정보 오염, 정보누수 등
- 파일 상호 작용: 상위 디렉터리 처리 문자(..), 특수 파일(/dev, ipt0, ADS 등)

소스코드 검사 방법
- 모든 것은 사용자 입력으로부터 -> 네트워크, 파일,IPC 등 모든 부분을 확인 후 '주석'처리
- 메모리 관련 루틴은 반드시 체크 -> 메모리 할당, 크기 변경, 해제, 복사
- 누가 누구를 호출하는지 찾을 것(x-refs) -> 특히 위험한 함수를 호출하는 부분을 주목
- 찾아낸 버그는 반드시 검증 과정을 거쳐야함 -> 백트레이스 또는 인위적으로 오류 발생시키기
* 일단 위험하다고 알려진 부분부터 먼저 찾아보고, 그 다음 입구와 출구를 파악하고 마지막에 로직 검사

퍼징(Fuzzing) 이란
테스트 대상 내부에 존재하는 잠재적이며, 치명적인 결함을 발견하기 위해 비정상적인 혹은 예측 불가능한 입력값들을 주입하는 것으로 소프트웨어 테스팅 방법론의 일환으로 수행되는 기법이다.
또한, 퍼징은 테스트하고 있는 시스템의 소스 코드에 접근하지 않고 테스트를 수행하는 블랙박스 테스팅
기술의 하나로, 소프트웨어 생명 주기의 어떠한 단계에서도 사용할 수 있다.

퍼징 프로세스
대상 선정 - 분석 대상 소프트웨어의 어떤 부분을 공략할 것인가?
입력값 결정 - 정상적인 입력은 무엇이며, 비정상 입력은 무엇인가?
퍼징 데이터 생성 - 어떠한 값을 입력할 것인가?
퍼징 데이터 실행 - 데이터 생성과 실행은 동시에 이루어져야 한다.
예외 모니터링 - 크래시가 발생한 정확한 위치를 기록
공격 가능성 판단 - 크래시 발생 원인을 분석해 exploitbale 여부를 판단

퍼징 데이터 생성 방법
점검 대상의 포맷 구조 및 해당 구조의 이해 유무에 따라
- Dumb Fuzzing : 대상 소프트웨어 대한 기반 지식 없이 무작위 데이터를 삽입해 테스트하는 기법
- Smart Fuzzing : 대상 소프트웨어의 입력 데이터 처리 구조 및 포맷을 토대로 데이터를 생성
데이터 처리 방법에 따라
- Generation Fuzzing : 테스트에 사용할 데이터를 직접 생성해 입력으로 사용
- Mutation Fuzzing : 실제 데이터 샘플의 일부를 변형시켜 테스트 하는 방법

=> Dumb Fuzzing == Mutation Fuzzing
=> Smart Fuzzing == Generation Fuzzing

퍼징시 고려해야할 문제
- 샘플 변형시 경우의 수가 무한대일 경우에는 어떻게 해야하나
- 경우의 수가 너무 적어서 버그를 찾기도 전에 작업이 끝나면?
- Crash 발생 여부는 어떻게 발견?
- 너무 많은 Crash가 발생하면, 이것도 또 일인데
- 퍼징 작업에서 다룬 부분과 다루지 않은 부분은 어떻게 하는가?
- 퍼저의 성능은 어떤 기준으로 개선해야하나?
- 언제 그만둬야 하는가?

퍼저의 유형
- 파일 퍼저 : 파일 포맷을 대상으로 하는 퍼징 도구
- 네트워크 퍼저 : 네트워크 프로토콜을 대상으로 하는 퍼징 도구
- 메모리 퍼저 : 메모리의 특정 부분을 대상으로 하는 퍼징 도구
- 범용 퍼저 : COM, 공유 라이브러리 등 다양한 시스템을 대상으로 하는 퍼저(여러 기능 혼합)
- 커스텀 퍼저 : 특수한 파일 포맷 또는 네트워크 프로토콜을 대상으로 하는 퍼징 도구

---

퍼저 실습

아까 옮겼던 파일 중에서 010에디터 32비트 설치 - 원본파일과 변형파일 비교하기 위함

피치파일 퍼징 - win86 압축해제 / 콘솔창에서 실행할 예정

피치파일 퍼징폴더에 xml 폴더가 있는데 파일 구조가 몇개 있음

smaples에는 퍼징 돌릴 샘플 파일들이 존재한다.

설치파일 폴더로 가서 SDKsetup 설치 - 체크 항목들이 있는 곳에서 디버깅 툴즈(3번째꺼)빼고 다 해제

XMLcopy 에디터 설치(32비트)

곰플레이어 설치

mp4리더도 압축풀고 설치

다시 피치파일퍼징 폴더에 있는 피치(32bit)랑 샘플, xml을 C드라이브로 옮기자(콘솔에서 찾기 쉽게)

 

 

C드라이브 - Sample 폴더에 있는 mp4 파일을 mp4 리더로 드래그 드랍 해본다.

그럼 구조에 맞게 파싱을 해준다.

스마트 퍼징에 정확하게 넣을거면 여기에 나오는 값을 참고하여 진행하면 되고,

헤더 포맷에 맞게 설정해서 실행하면 된다.

010editor 에도 동일하게 mp4 샘플 파일을 올린다.

맨 앞에 box number만 볼 것이다. 00 00 00 18이 되어있다.

mp4 리더에서도 box size 00 00 00 18으로 확인할 수 있다.

박스 이름도 확인할 수 있다(ftyp)

메이저 버전과 마이너 버전도 확인할 수 있고 mp4리더에서도 확인 가능하다.

스마트 퍼징을 하려면 이런거 다 고려하여 핏 파일을 구성해야한다.

C - XML폴더에 들어가서 mp4 클릭하면 자동으로 copy editor로 바뀐다.

거기에에는 양식에 맞게 다 바꿔둔 부분이다.

할 수 있으면 이렇게 파싱하여 스마트 퍼징하면 좋겠지만 XML 맞추는데 많은 노력이 필요하다.

Peach Fuzzer
http://community.peachfuzzer.com/v3/DataModeling.html

피치 사이트에서 좀 더 많은 정보를 찾을 수 있다.

홈페이지에서 Peach Pits -> 데이터 모델링에 보면 들어가는 요소들을 확인할 수 있다.

XML 파일에서 요소를 클릭하면 요소의 특성을 볼 수있고, 파일의 특성에 맞게 변경해야한다.

XML파일의 Statemodel은 어떻게 돌릴 것인지 설정하는 것이다.
경로 수정할 것이 이므로 조금 바뀌어야한다.

XML파일의 Agent에서 우리는 로컬로 다 사용할 거라서 LocalAgent이다.

AGent 위에 모니터로 WinDbg를 쓰려고 아까 설치했다.

어떻게 수행할 것인지는 커맨드라인에 입력한다.

아래 Page Heap은 힙 디버깅이 쉽게할 수 있게 존재한다.

 

이후 설정 값을 조금 수정하여 퍼징을 실습해볼 것이다.

먼저 Statemodel에서 data 경로를 C-sample-samplemp4로 사용한다 (C:\samples\sample.mp4)

밑에 LocalAgent 에서 CommandLine을 변경한다 (C:\programfile\GRETECH\gomplayer\gom.exe fuzzed.mp4)

LocalAgent에서 WinDbgPath 경로를 바꿔준다.(C:\programfile\windowskits\8.1\Debuggers\x86\)
* 맨 뒤에 역 슬래쉬를 넣어줘야 잘 돌아감

아래에 있는 PageHeap에 있는 WinDbgPath도 변경한다.

 

이제 피치를 실행시켜 보자

CMD를 관리자로 실행하고 C에 있는 피치로 경로를 설정한다.

peach.exe -t C:\xml\mp4.xml

했을 때 No Errors found하면 설정 값에 이상이 없다는 것이고 -t 빼고 실행하면

자동으로 켜졌다가 꺼졌다가 한다.
(근데 이상없다고 해도 실행하면 잘 안됨 ㅎㅎ)

 

peachx86 - logs - status가 있다.

중간에 꺼졌을 때 거기서부터 다시 시작하고 싶으면 Status에서 Seed 값을 이용
peach.exe xml파일 --seed 시드번호 --skipto 생략번호(interaction)

덤프 퍼징하고 싶으면 mp4_1파일을 보면 된다(?)

 

크래쉬가 떴다고 하면 010 에디터에서 CTRL+M 누르면 오리지날 파일과 새 파일을 비교할 수있다.

기존의 sample.mp4 파일과 peach - logs - 폴더 - .initial.action.bin파일을 비교할 수 있다.

원본 파일과 변조 파일이 너무 다르면 퍼징이 발생해도 취약점 찾기가 어렵고, 안될 수도 있다.

 

원인 분석하는 방법을 소개해주기 위해서 두개의 파일을 가지고 왔다.

Peach Crash Data에서 OriginalSeed.mov와 MutatedSeed.mov가 있다.

해당 파일을 010 에디터에 넣어서 비교하면 2군데만 다른 것을 알 수 있고,

다른 곳이 적은데 크래쉬가 터졌으므로 찾아가기가 매우 쉽다.

1바이트씩 바꿔가면서 크래쉬가 뜨는지 안뜨는지 추적하면 원래 값으로 돌렸을 때

크래쉬가 발생하지 않는 부분이 생긴다. 그럼 그 부분이 직접적인 요인이 되는 것이다.

 

해당 크래쉬가 발생할 때 로그 보는 방법은 다음과 같다.

똑같은 폴더에 있는 Localagent_StackTrace 파일에서 맨 아래에 보면 Description이 있는데

읽을 수 없는 곳에서 읽으려고 해서 크래쉬가 터진 것을 알 수 있다.

Classification에서 보면 Unknown이라고 나와있지만, 크리티컬한 취약점이다.

해당 취약점은 Heap 취약점이라서 분석하기 힘들지만,

ESI(aaadfc75), EDI 레지스터에 010 에디터에서 변조되어 있던 값이 그대로 ESI, EDI에 박혀있어서

매우 찾기 쉬워진 취약점이다.

 

다시 107폴더에 있는 Local.Agent.Monitor.Windows~StaackTrace 파일을 보자

맨 민에서 보면 GSFU!라는 걸 볼 수 있는데 크래쉬 터진건 곰플레이어이지만 아이다에 곰플레이어를

올려도 터진 부분을 볼 수가 없다. 곰플레이어이 아닌 GSFU에서 크래쉬가 발생했기 때문이다.

곰플레이어에 정상 파일을 올려서 Dll 확인하고 BP잡고 비정상 파일을 올려서 확인하면 된다.

(어떻게 했는지 기억이 안난다...)