https://www.inflearn.com/course/%EC%9E%90%EB%8F%99%EC%B0%A8-%EC%8B%A0%EC%9E%85-can%ED%86%B5%EC%8B%A0#curriculum

 - 무료

 - 빠르고 적은 메모리 사용

 - 대용량 텍스트파일 읽기 가능

 - glogg는 다양한 운영체제 지원

 - glogg 다운로드 링크

https://angangmoddi.tistory.com/96

Buffer OverFlow로 인한 프로그램의 비정상적인 실행을 막기 위한 대응 방안.

1. 스택 쉴드(Stack Shild)

 함수 호출시 스택에 저장되는 return address를 Global RET이라는 특수 스택에 저장한다.
 그리고 함수 종료시에 이 Global RET에 저장되어 있는 값과 스택의 return address를 비교해서

 두 값이 다르면, 프로그램을 종료시키는 방법이다.

2. ASLR(Address Space Layout Randomization)

 메모리공격을 어렵게 하기 위해서 스택, 힙, 라이브러리 등 데이터영역 주소들을 랜덤으로 프로세스
 주소 공간에 배치하여 실행시마다 데이터 주소가 바뀌도록 하는 방법이다.

3. 스택 가드(Stack Guard)

 스택내에서 return address와 변수 사이에 Canary Word를 저장해두고, 해당 값이 변경되었을 경우

 프로그램을 종료하여 메모리 공격을 방지하는 방법이다.

4. NX-bit(Non-executable stack)

 프로세서 명령어나 코드 또는 데이터 저장을 위한 메모리 영역을 따로 분리하는 기술이다.

 스택을 NX특성으로 설정하면, 지정된 메모리 공간은 데이터 저장을 위해서만 사용되고, 명령어는 실행할 수 없게된다.

 만약 이를 위반하고 명령어를 실행하려고 하면 프로그램을 종료하여 공격을 방지하는 방법이다.

https://www.kernelpanic.kr/16

1.1 Init이란

Init은 리눅스 커널 부팅이 완료된 뒤 실행되는 첫 번째 프로세스다. 또한 동시에 Init은 커널이 직접 실행하는 유일한 프로세스다. 따라서 Init은 부모 프로세스를 가지지 않는 유일한 프로세스인 동시에, Init을 제외한 나머지 모든 프로세스의 조상이 된다. 이러한 특징으로 인해 Init은 아래와 같은 작업들을 수행한다.

Init이 하는 일

위 그림과 같이 Init은 프로세스와 시스템의 초기화와 관리를 수행한다. 우선 Init은 등록된 서비스 혹은 initrc에 기록된 백그라운드 서비스와 시스템 서비스를 실행한다. 우선 우리가 리눅스 상에서 GUI를 사용할 수 있도록 GDM, LightDM 등의 디스플레이 매니저를 실행한다. 백그라운드 서비스로는 파일을 필요할 때 문맥에 맞게 가져올 수 있도록 분류, 그룹짓는 tracker-miner가 있으며, 시스템 서비스로는 네트워크 관리자인 NetworkManager, IPC 버스인 Dbus 등이 있다. 또한 Init은 시스템의 관리를 한다. 대표적으로 시스템 서비스, 커널 등에서 발생하는 로그를 한데 모아서 저널링 하는 기능이 있다. 마지막으로 Init은 데몬 프로세스나, 부모가 죽어서 고아가 된 프로세스의 부모가 된다. 이 덕분에 리눅스의 모든 프로세스는 (Init을 제외하고) 모두 부모 프로세스를 가지게 된다.

백그라운드 서비스와 시스템 서비스를 구분하는 명확한 기준은 없다. 여기서는 시스템 기능을 구성/관리하는 역할을 하는지, 어플리케이션 수준에서 동작하는지에 따라 임의 구분하였다.

단 이러한 작업들은 Init 프로세스 혼자서 수행하는 것은 아니고, 시스템 서비스들의 도움을 받아서 수행한다. 또한 위 그림은 Systemd를 기준으로 하였기 때문에 Upstart, SysV 등 다른 Init 시스템과 다른 부분이 있을 수 있다. (Init 시스템들에 대한 구분은 아래 "1.3 리눅스에서의 Init 시스템" 참조)

1.2 Init의 동작 플로우

Init의 동작 과정을 아주 단순화 하면 다음과 같다.

1. 파일 시스템 초기화 (파일 마운트, 스왑 디바이스 관리, 가상 파일 시스템 마운트 등)

2. 네트워크 및 기본적인 시스템 동작을 위한 시스템 서비스 실행

3. 백그라운드 서비스 실행

4. GUI 쉘 실행

위는 아주 개략화한 Init 프로그램의 동작이다. 리눅스 상에는 다양한 Init 프로그램이 있는데, 이들의 동작을 일반화 하기는 어렵다. 다음 포스트에서 대표적인 Init 프로세스인 Systemd를 다룰 때, Systemd의 동작 플로우에 대해 자세히 다루도록 하겠다.

1.3 리눅스에서의 Init 시스템

앞에서도 언급하였듯이 리눅스에는 다양한 Init 프로그램이 있다. 대표적으로는 오랜 역사를 가진 SysV, Ubuntu에서 사용되던 Upstart, 임베디드에서 종종 사용되는 runit, 그리고 가장 강력하며 오늘날 가장 널리 사용되는 Systemd가 있다. 각 Init 시스템은 아래와 같은 특징들을 가지고 있다.

이후 포스트에서는 가장 대중적이며, 많은 기능을 가지고 있는 Systemd에 대해서 좀 더 자세히 다루도록 하겠다.

https://goseungduk.tistory.com/29

MIPS를 사용할 일이 생겨서 현재 사용하는 Ubuntu 16.04 LTS 에 QEMU로 가상환경을 조성하기로 하였다.

우선 MIPS를 구동할 QEMU부터 설치하자.

sudo apt-get install qemu

이렇게 하면 MIPS 외에도 다른 하드웨어, 플랫폼을 위한 QEMU 구성요소가 설치된다.

(상당히 QEMU에서 지원하는 부분이 많다)

이제 QEMU를 설치했으니 구동시킬 커널과 이미지를 받아보자

커널

wget https://people.debian.org/~aurel32/qemu/mipsel/vmlinux-3.2.0-4-4kc-malta

이미지

wget https://people.debian.org/~aurel32/qemu/mipsel/debian_wheezy_mipsel_standard.qcow2

여기서 이제 QEMU 버전 문제 때문에 일부러 커널을 구버전으로 받아서 했다. 최신버전을 원하는 사람들은 여기를 찾아보라.

https://stackoverflow.com/questions/58181344/how-to-use-netdev-user-hostfwd-option-in-qemu/58183222#58183222

그리고 mips와 mipsel의 차이는 간단히말하면 mips에서 지원하지않던 명령어들(move 같은 것?)을 mipsel에서는 지원한다는 것이다. 크게 다르진 않다고 한다.

이제 구동시켜보자!!!

qemu-system-mipsel -M malta -kernel vmlinux-3.2.0-4-4kc-malta -hda debian_wheezy_mipsel_standard.qcow2 -append "root=/dev/sda1" -nographic -redir tcp:3131::22

qemu-system-i386 debian_squeeze_i386_standard.qcow2 -nographic -netdev user,id=root,hostfwd=tcp::32323-:22
i386도 가능하다

-M malta -kernel 뒤에는 받은 커널 이름과 버전을 인자로 주면 되고, -hda 뒤에는 debian 이미지 이름을 넣어주면 된다. -redir은 위에말대로 옛날 버전에서만 된다고 하니 유의하도록!

그러면 위와 같이 성공적으로 debian 리눅스가 켜진다.

ID : root / PW : root 로 로그인 하면된다.

apt-get 패키지 구성 유의사항

필자는 apt-get이 안먹혀서 굉장히 당황했다.

오류는 대강 install이나 update할 때 파일을 가져오는 url이 없다는 404 오류였다.. (?)

이 경우, apt-get 으로 받아오는 url(?)을 재설정 해줘야하는 것 같다.

debian 리눅스 상에서 /etc/apt/sources.list 에서 나머지 문장들은 다 주석처리 해버리고 이 문구를 추가하자.

deb http://archive.debian.org/debian/ wheezy main contrib non-free

아래는 필자의 /etc/apt/sources.list 파일

아무튼 이후는 알아서 디버깅을 하던 구동을 하던 마음대로 무한으로 즐기면 된다.

추가

• gdb-peda를 MIPS에서 써보자! : https://github.com/mutepigz/peda-mips

https://cpuu.postype.com/post/2069373

Radamsa는 Oulu University Secure Programming Group이 개발한 퍼즈 테스팅 도구이다. 이 도구를 활용하여 소프트웨어 제조사나 개인 개발자들이 보다 손쉽게 소프트웨어의 강건성(robustness) 테스트를 수행할 수 있도록 돕기 위한 취지로 개발되었다. 기존에 출시되어있던 유사한 프로그램들은 설치 자체가 굉장히 복잡하고, 개별 프로젝트에 적용하기 위해서 수많은 추가작업이 필요하다는 단점이 있었다. 이러한 문제점에 착안하여 새롭게 개발한 도구가 바로 Radamsa이다.

Radamsa는 커맨드라인 기반으로 작동할 수 있으며, 샘플 파일을 주입하면 자동으로 변이(mutated)된 결과물을 생산해준다. 그러므로 이 도구는 mutation-based fuzzer라고 구분할 수 있겠다. 

이 도구는 심지어 TCP Client 또는 서버로써 사용할 수도 있다. 즉, TCP 연결을 수립한 상태에서 서버 또는 클라이언트의 입장에서 mutation된 입력값을 송수신하게 만드는 것이다.

Radamsa는 하나의 패키지 안에 포함된 다수의 fuzzer를 통칭한다. 단순히 bit를 임의로 몇번 바꾸는 것에 그치지 않고, 샘플 파일의 구조를 분석하여 보다 색다른 퍼징 기법에 적용할 방안을 찾는다. 이러한 기술의 성과는 실제로 효과적이어서, real world의 다수의 소프트웨어에서 흥미로운 취약점들을 도출해내었다.

Radamsa는 무료로 사용할 수 있는 응용 프로그램이며, 필요한 경우 원본 소스코드를 다운로드 받아 각자의 용도에 받게 개조하여 사용하는 것 또한 허용된다. 소스코드는 MIT License를 따라 관리되고 있다.

사용법

Radamsa는 Windows 및 리눅스 용으로 prebuilt된 바이너리 형태가 제공되며, 자신의 환경에 알맞도록 직접 컴파일하여 사용할 수 있도록 소스코드 방식으로도 지원된다. 코드는 아래의 방법으로 얻을 수 있다.

*원래 Radamsa가 제공되던 페이지는 github였는데(https://github.com/aoh/radamsa), 2018년 6월 16일부로 gitlab(https://gitlab.com/akihe/radamsa) 으로 이전되었다는 안내가 게재되어 있다. 알만한 사람들은 알테지만 최근 Microsoft가 Github를 인수하였기 때문에 이와 관련해서 IT업계가 시끄러운 상황이고, 실제로 많은 개발자들이 gitlab으로 옮겨가고 있다고 하는데 아마 그 일환이라고 보는 개인적 소견.. (참고 : MS가 깃허브를 인수했는데, IT 업계가 왜 시끄러울까?) 

설치는 아래와 같이 가능하다(Ubuntu Linux 16.04 기준)

$ sudo apt-get install gcc make git wget

$ git clone https://gitlab.com/akihe/radamsa.git

$ cd radamsa/

$ make

$ sudo make install

대략적인 사용법이 적혀있는 help 문서가 있다.

https://gitlab.com/akihe/radamsa/blob/master/README.md 

간단히 예제를 보면..

$ echo "aaa" | radamsa

 aaaa

​

$ echo "aaa" | radamsa

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ▒▒

​

$ echo "aaa" | radamsa

aaa▒▒1▒3

​

$ echo "aaa" | radamsa

แbaa

​

$ echo "aaa" | radamsa

aaab

​

 위와 같이 echo "aaa" 명령어의 결과를 radamsa로 전달했더니 처음에는 a라는 문자가 하나 더 붙는 형태로 나타났지만 여러번 재수행할때마다 새로운 방식으로 결과물이 mutate되는 것을 확인할 수 있다. 기본적으로는 /dev/urandom을 사용해서 난수적 흐름을 주입하는 것으로 알려져 있다.

Radamsa는 퍼즈 테스팅을 자동화할 수 있도록 하기 위해 다양한 환경을 제공한다. 특히 command-line 파라미터를 이용해서 원하는 숫자값을 자동으로 계속 생성해낼 수 있다. 그리고 입력으로 주입되는 seed 값을 이용해서 지속적인 변화 흐름을 만들어낼 수 있다. 다만 target monitoring을 기본적으로 지원하지는 않는다. 개발진은 이를 도울 수 있는 shell script example을 readme 파일을 통해 간단히만 설명하고 있다. 이를 참고하여 사용자가 직접 관련 기능을 구현해야 한다.

Radamsa는 샘플파일을 이용해 mutation 기능을 수행한다. 따라서 mutation 기반이기 때문에 모델을 분석하여 data를 스스로 generating 하는 방식은 아니다.

더욱 자세한 설명은 아래의 논문을 참고하면 된다.

An Evaluation of Free Fuzzing Tools 에서 발췌한  Radamsa 도구 평과결과 요약

[Mikko, V. "An Evaluation of Free Fuzzing Tools." University of Oulu Department of Information Processing (2015).]

아래는 Radamsa의 사용 편리성을 언급한 대목이다.

Ease of use criterionPossible advantage

아래는 Radamsa를 통해 실용적으로 얼마나 많은 이득을 취할 수 있는지에 대한 평가이다

Practical features criterionPossible advantage

아래는 Radamsa가 퍼징하는 방식에 대한 설계적 탁월성을 뜻한다

Intelligence of the fuzzing criterionPossible advantage

결론

Radamsa는 아주 간단하면서도 꽤나 강력한 fuzzer이며, 개발자가 자신의 구미에 맞게 적절히 수정하여 사용할 수 있다는 장점을 가지고 있다. 스스로 적절한 퍼즈 테스팅 구조를 수립하고, 그에 알맞게 구현을 변경할 수 있는 개발자들에겐 굉장히 좋은 도구일 것이다. target application에 대한 monitoring 기능은 꼭 추가적으로 제작을 해서 사용하는 것이 좋을 것이다.

Persistent mode

두가지 방법이 있다.

• app.c 파일을 수정하는 방법
• AFL_LOOP 매크로를 for 반복 루프 내에 포함시킨다.

gint i;

for(i=0;filenames[i] != NULL; i++){
	if (run_loop){
		#ifdef __AFL_COMPILER
			while(__AFL_LOOP(1000)){
				file_open_from_command_line (gimp, filenames[i], as_new);
			}
			exit(0);

		#else
			file_open_from_command_line (gimp, filenames[i], as_new);
		#endif
		}

• AFL_LOOP를 xcf_load_invoker 함수 내에 포함시킨다.

--- ../xcf.c	2014-08-20 08:27:58.000000000 -0700
+++ ./app/xcf/xcf.c	2021-10-11 13:02:42.800831192 -0700
@@ -277,6 +277,10 @@
 
   filename = g_value_get_string (&args->values[1]);
 
+#ifdef __AFL_COMPILER
+  while(__AFL_LOOP(10000)){
+#endif
+
   info.fp = g_fopen (filename, "rb");
 
   if (info.fp)
@@ -366,6 +370,12 @@
   if (success)
     gimp_value_set_image (&return_vals->values[1], image);
 
+#ifdef __AFL_COMPILER
+  }
+#endif
+
+  exit(0);
+
   gimp_unset_busy (gimp);
 
   return return_vals;

첫 번째 방법은 다른 입력 형식도 타겟으로 할 수 있지만 두 번째 방법은 xcf만 대상으로 하므로 더 빠르게 버그를 찾을 수 있다.

https://ppiazi.tistory.com/entry/AFLAmerican-Fuzzy-Lop-Fuzzer-%EC%82%AC%EC%9A%A9%EA%B8%B0-binutils-%EB%8C%80%EC%83%81

https://rond-o.tistory.com/214

AFL

afl은 honggfuzz, afl, libfuzzer와 함께 소프트웨어 퍼징을 위한 대표적인 gery-box fuzzer다.

자세한 내용은 따로 정리할 것이며 여기서는 간단하게만 다룬다.

현재 오픈소스로 제공하고 있으며 whitepaper도 확인할 수 있다.

[링크] : afl open source, afl whitepaper

아래 내용은 논문 [The Art, Science, and Engineering of Fuzzing: A Survey]를 기반으로 정리한 내용이다. 논문 리뷰는 이 링크에서 확인할 수 있다.

Summary

• Grey-box Fuzzer

• Open-sourced

• In-memory Fuzzing

• Seed Scheduling

• Mutation

• Coverage-baesd Crash Traige

• Evolutionary Seed Pool Update

• Seed Pool Culling

Instrumentation

AFL은 한 가지 이상의 instrumentation 방법을 사용하는 대표적인 퍼저다.

• static instrumentation

afl 전용 컴파일러를 이용해 소스 코드 수준의 정적 instrument 코드를 삽입한다.

• dynamic instrumentation

실행 가능한 코드를 PUT 내부에서 instrument 하거나(default 옵션) 실행 가능한 코드를 PUT나 외부 라이브러리에서 instrument 한다(AFL_INST_LIBS 옵션).

* AFL_INST_LIBS 옵션은 실행되는 코드를 모두 instrument 하는 것인데, 외부 라이브러리의 코드에 대한 커버리지 정보도 포함할 수 있어서, 더 완전한 커버리지 정보를 제공한다. 이는 AFL이 외부 라이브러리 함수에서 추가적인 경로를 퍼징하도록 도와준다.

AFL과 그 하위(AFL 계보 퍼저들)의 퍼저는 PUT의 모든 branch instruction을 instrument해서 branch coverage를 계산한다

In-memory fuzzing

GUI처럼 복잡한 프로그램은 프로세스를 생성하고 입력을 전달하기까지 수 초가 소요된다. 이런 프로그램을 퍼징하기 위해 GUI 초기화가 완료된 후에 메모리 스냅샷(snapshot)을 찍는 접근 방식이 존재한다. 새로운 테스트 케이스를 퍼징하기 위해, 테스트 케이스를 메모리에 집접 쓰고 실행하기 전에, 메모리 스냅샷을 복원할 수 있다. 클라이언트-서버간의 상호 작용이 많은 네트워크 응용프로그램을 퍼징할 때도 이런 접근 방식을 사용할 수 있다.

AFL은 초기 실행의 코스트를 줄이기 위해 fork server를 사용한다. fork server는 모든 fuzz iteration에 대해 새로운 프로세스를 fork 한다. 즉 각 fuzz iteration마다 이미 초기화 과정이 끝난 상태의 프로세스를 fork 하여 퍼징할 수 있다.

Execution Feedback

AFL의 minset은 각 branch에 지수적(:logarithm)인 카운터가 있는 branch coverage를 기반으로 한다. 그 이유는 branch 카운터가 몇 배 차이로 다를 때만 차이가 있다고 인지하도록 설정한 것이다.

[AFL whitepaper의 "2) Detecting new behaviors"에서 확인할 수 있다.]

seed trimming

AFL은 어떤 시드가 동일한 커버리지를 달성하도록 유지하면서, 그 시드의 일부분을 제거하는 코드 커버리지 instrumentation을 사용한다.

FCS Algorithms

AFL은 FCS problem에 EA(Evolutionary Algorithm)을 사용한다. 즉 fitness의 가치가 있는 configuration set을 유지한다.

AFL은 control-flow edge를 실행하는 configuration 중, 가장 빠르고 가장 작은 configuration 입력을 포함하는 configuration을 가장 효과적(AFL에서는 favorite라는 용어를 사용)이라고 판단한다. AFL은 config 큐를 원형 큐(circular queue) 형태로 유지하면서 다음으로 효과적인 configuration을 선택하고, 일정한 횟수만큼 실행한다.

Mutation

AFL은 다양한 mutation 기법을 사용한다. 대표적인 방식은 다음과 같다.

Bit-Flipping, Arithmetic Mutation, Block-based Mutation, Dictionary-based Mutation

Triage (Coverage-based Deduplication)

AFL은 PUT의 각 실행에 대한 edge coverage를 기록하고 각 edge에 대한 대략적인 hit count를 측정하기 위해 효율적인 소스 코드 instrumentation을 사용한다. 주로 이 edge 커버리지 정보를 사용해 새로운 시드 파일을 선택한다.

게다가 이 방식은 독특한 중복 제거 기법으로 이어진다. 이전에 볼 수 없었던 edge를 커버했거나, 모든 이전 크래시들에 존재하던 edge를 커버하지 않은 경우 이를 unique한 크래시라고 간주한다.

Test case minimization

AFL은 crashing input의 크기를 줄이는 기술을 test case minimization라고 부른다.

AFL의 test case minimizer는 바이트를 0으로 설정하여 테스트 케이스의 길이를 줄인다. 

Evolutionary Seed Pool Update

AFL은 branch에 hit 한 횟수를 기록하여 fitness function의 정의를 구체화했다.

dact

dact는 특히 출력 파일의 크기를 작게 만들기 위해 입력 데이터의 블록 크기를 고려하여 가장 적합한 알고리즘을 선택하는 압축 도구다.

dact의 manpage는 아래와 같다.

[dact manpage] https://manpages.debian.org/testing/dact/dact.1.en.html

Fuzzing

Build dact

먼저 취약점이 있는 dact-0.8.42 버전의 바이너리를 준비하자.

• dact-0.8.42 binary

cd ~
wget https://fossies.org/linux/privat/dact-0.8.42.tar.gz
tar -xvf dact-0.8.42.tar.gz
mv dact-0.8.42  dact_dir

아래와 같이 빌드할 수 있다.

• dact build

  cd ~/dact_dir/
  make clean
  ./configure
  make
  
  mv ~/dact_dir/dact ~/dact_original

Use dact

-help 옵션으로 여러 옵션을 살펴볼 수 있다.

• dact usage

~/dact_original -help

몇 가지 주요 옵션만 살펴보자.

옵션 없이 입력 파일을 전달하면 압축해 준다.

-d 옵션과 함께 입력 파일을 전달하면 압축을 해제해 준다.

-c 옵션은 stdout으로 압축 또는 압축 해제 결과를 출력해 준다.

-f 옵션은 강제로 압축(해제)를 진행하는 옵션이다.

직접 사용해보자.

• use dact

cd ~/
echo hello > hello.txt
~/dact_original ~/hello.txt
cat ~/hello.txt.dct

rm ~/hello.txt
~/dact_original -d ~/hello.txt.dct
cat ~/hello.txt

압축했는데 dct 파일 포맷으로 인해 크기가 오히려 증가한 것을 알 수 있다.

• size

$ ls -alh ~/hello.txt*
-rw-r--r-- 1 topcue topcue  6 Feb 17 17:10 hello.txt
-rw-r--r-- 1 topcue topcue 67 Feb 17 17:08 hello.txt.dct

• dct format

$ xxd ~/hello.txt.dct

00000000: 4443 54c3 0008 2a00 0000 0000 0000 0600  DCT...*.........
00000010: 0000 0100 0000 0b00 0000 001a 0400 0968  ...............h
00000020: 656c 6c6f 2e74 7874 0000 0412 e602 1f01  ello.txt........
00000030: 0004 12e6 021f 000b 6865 6c6c 6f0a 0000  ........hello...
00000040: 0000 00                                  ...

Build dact with scan-build

먼저 동적 분석 도구인 scan-view를 써보기 위해 scan-build를 이용해 빌드 하자.

• scan-build: static analysis tool

sudo apt-get install -y clang clang-tools

cd ~/dact_dir/
scan-build ./configure
scan-build make

그러면 /tmp 디렉토리 하위에 분석 결과를 확인할 수 있는 html 파일이 생성된다.

• scan-view

ls /tmp
scan-view /tmp/scan-build-*/

• output

scan-view dact

의심 가는 버그 30가지를 알려주지만 심각한 취약점으로는 보이지 않는다.

build with AFL

AFL로 퍼징할 수 있도록 먼저 AFL을 빌드하자.

• build AFL Fuzzer

cd ~
wget http://lcamtuf.coredump.cx/afl/releases/afl-latest.tgz
tar -xvf afl-latest.tgz
mv afl-2*/ afl_dir/
cd ~/afl_dir/
make
sudo make install

아래와 같이 AFL 컴파일러를 이용해 dact를 빌드 하자.

• compile dact w/ afl-compiler

cd ~/dact_dir/
make clean
CC=~/afl_dir/afl-gcc ./configure
make

mv ~/dact_dir/dact ~/

Fuzz with AFL

퍼징할 때 dact의 입력을 전달하기 위해 in이라는 디렉토리를 만들고 입력으로 쓸 hello.txt.dct를 전달하자.

• set input directory

mkdir ~/in
mv ~/hello.txt.dct ~/in/

그리고 코어 덤프 생성을 위해 아래 명령어를 사용할 수 있다.

• for core

sudo sysctl -w kernel.core_pattern=core

이제 직접 퍼징해보자.

• fuzzing with afl

~/afl_dir/afl-fuzz -i ~/in -o ~/out -- ~/dact_afl -dcf

-i와 -o는 각각 input/output 디렉토리를 지정해 준 것이다. --은 타겟 프로그램의 이름과 인자를 전달하기 위함이다.

즉 -dcf 옵션으로 dact를 퍼징하겠다는 의미다.

퍼징을 시작하면 아래와 같이 초기화 작업 이후 깔끔한 모습으로 상황을 보여준다.

아래 사진은 11분간 퍼징을 했을 때 상황이다.

Fuzzing for 11 minutes

unique crash가 27개 발견되었다.

이제 퍼징을 멈추고 취약점 종류를 살펴보자.

• see crash

ls ~/out/crashes/

퍼징에 사용한 dact_afl 바이너리도 reproduce에 사용할 수 있지만, 더 많은 정보를 제공하는 ASAN을 이용하겠다.

아래와 같이 ASAN instrumentation 코드를 삽입하여 dact를 빌드 하자.

• build dact with ASAN

cd ~/dact_dir/
make clean
CC="clang -fsanitize=address" CXX="clang++ -fsanitize=address" ./configure
make

mv ~/dact_dir/dact ~/dact_asan

이렇게 빌드 한 dact_asan으로 crashing input을 실행할 경우 crash가 발생한 이유를 자세히 확인할 수 있다.

crash 원인만 간단히 살펴보기 위해 dact_asan을 이용해 crash log를 생성하자.

• make crash log w/ asan

for file in ~/out/crashes/*; do;
echo Input: $file >> ~/crash.log;
~/dact_asan -dcf $file 2>> ~/crash.log;
done;

아래와 같이 grep을 이용해 ASAN이 분류해 준 취약점 원인을 확인할 수 있다.

• grep ERR

grep ERROR ~/crash.log

crash log

이들 중 스택 버퍼 오버플로우만 필터링하자.

• grep stack-buffer-overflow

$ grep ERROR ~/crash.log | grep stack

==1355737==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffc9c54a180 at pc 0x0000004c9a75 bp 0x7ffc9c549870 sp 0x7ffc9c549868
==1355760==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffdec592a20 at pc 0x0000004c9a75 bp 0x7ffdec592110 sp 0x7ffdec592108

스택 버퍼 오버플로우 취약점을 트리거 하는 crashing input 두 개가 있다.

이들이 각각 어떤 파일인지 확인하기 위해 crash.log 파일을 열고 id를 확인하자.

• detail

vi ~/crash.log

# search string w/ command mode
/stack-buffer-overflow

crash log detail

==1355760==ERROR: 라인 위로 쭉 올라가면 파일명을 확인할 수 있다.

Input: /home/topcue/out/crashes/id:000026,sig:06,src:000027,op:havoc,rep:8
dact: read: No such file or directory
dact: read: No such file or directory
...
dact: read: No such file or directory
dact: read: No such file or directory
=================================================================
1721 ==1355760==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffdec592a20 at pc 0x0000004c9a75 bp 0x7ffdec592110 sp 0x7ffdec592108
1722 WRITE of size 8 at 0x7ffdec592a20 thread T0
1723     #0 0x4c9a74 in dact_process_file /home/topcue/dact-0.8.42/dact_common.c:478:40
1724     #1 0x4cdbf7 in main /home/topcue/dact-0.8.42/dact.c:689:8
1725     #2 0x7f38a1a330b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
1726     #3 0x41c4ad in _start (/home/topcue/dact_asan+0x41c4ad)

• crashing input filename

Input: /home/topcue/out/crashes/id:000026,sig:06,src:000027,op:havoc,rep:8
Input: /home/topcue/out/crashes/id:000017,sig:11,src:000000,op:havoc,rep:16

crash.log는 모든 crash의 정보가 포함되어 있기 때문에 보기 어렵다.

두 파일만 따로 가져와서 재현해보자.

$ ls ~/out/crashes/ | grep -e "id:000016" -e "id:000017"

id:000016,sig:06,src:000000,op:havoc,rep:4
id:000017,sig:11,src:000000,op:havoc,rep:16

• rename

cp ~/out/crashes/id:000016* ~/crash_1 
cp ~/out/crashes/id:000017* ~/crash_2

crash_1과 crash_2로 스택 버퍼 오버플로우를 재현하면 아래와 같다.

• reproduce crash_1

~/dact_asan -dcf ~/crash_1

crash_1 in crash log

• reproduce crash_2

~/dact_asan -dcf ~/crash_2

crash_2 in crash log

/home/topcue/dact-0.8.42/dact_common.c:478:40에 취약점이 있는 crash_2를 이용해 exploit할 것이다.

따라서 crash_2의 이름을 crash로 바꿔주자.

• rename crash

mv ~/crash_2 ~/crash

crash의 hex view는 다음과 같다.

• xxd crash

$ xxd ~/crash
00000000: 4443 54c3 0b08 2a00 0000 0000 0000 0605  DCT...*.........
00000010: 0003 0100 0000 0aeb 0000 b8b8 0400 0968  ...............h
00000020: 0000 6865 6c6c 6f0a 0000 0000 0004 1107  ..hello.........
00000030: 6865 6c6c 656c 6c6f 2e74 7874 0000 1013  hellello.txt....
00000040: 0402 1fe6 ff03 12e6 021f 0e0b 684f 6c12  ............hOl.
00000050: e602 1f00 0000 09

이제 crash를 이용해 다시 취약점을 트리거하고 화면에 출력된 결과를 분석해보자.

• reproduce crash

~/dact_asan -dcf ~/crash

결과는 아래와 같다.

• output (crash)

하나씩 해석해보자.

dact: read: No such file or directory
dact: read: No such file or directory
		...skip...
dact: read: No such file or directory
dact: read: No such file or directory

dact가 실행하면서 남긴 오류 메시지들이다.

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

address sanitizer가 출력한 구분선이며 이후 아래 모든 내용은 address sanitizer가 출력한 내용이다.

==1356226==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffa42eed60 at pc 0x0000004c9a75 bp 0x7fffa42ee450 sp 0x7fffa42ee448

ASAN이 감지한 취약점이 stack-based buffer overflow라는 사실을 알 수 있다.

또한 pc, bp, sp와 같은 레지스터 값을 출력해 준다.

WRITE of size 8 at 0x7fffa42eed60 thread T0
    #0 0x4c9a74 in dact_process_file /home/topcue/dact-0.8.42/dact_common.c:478:40
    #1 0x4cdbf7 in main /home/topcue/dact-0.8.42/dact.c:689:8
    #2 ...skip...

어떤 thread에서 버그가 발생했는지 알려준다.

그 아래는 스택을 backtrace 해주며 취약점이 존재하는 정확한 라인 넘버를 제시한다.→ dact_common.c:478

Address 0x7fffa42eed60 is located in stack of thread T0 at offset 2304 in frame
    #0 0x4c50ff in dact_process_file /home/topcue/dact-0.8.42/dact_common.c:249

  This frame has 16 object(s):
    [32, 36) 'cipher.addr'
    [48, 192) 'filestats' (line 250)
    [256, 2304) 'file_extd_urls' (line 252) <== Memory access at offset 2304 overflows this variable
    [2432, 2433) 'algo' (line 253)
    
		...skip...

    [2640, 2644) 'x' (line 265)
    [2656, 2664) 'offset' (line 266)

stack frame 정보를 제공한다. frame에 16개의 object들이 있으며 [256, 2304) 'file_extd_urls'의 256바이트부터 2303바이트까지 범위를 의미한다.

그런데 offset 2304에 접근하려 해서 overflow로 분류되었다.

Shadow bytes of crash

스택에 guard page를 넣어뒀는데 [f2]에 접근하다가 다른 object를 침범했다.

Conclusion

AFL을 이용해 dact 바이너리를 퍼징하고 crash를 생성했다.

이제 crash가 발생한 원인을 살펴보고 이를 이용해 exploit 해보자.