[5주차][6주차] CVE-2017-13028 취약점 분석

 

https://github.com/antonio-morales/Fuzzing101/tree/main/Exercise%203

Fuzzing101/Exercise 3 at main · antonio-morales/Fuzzing101

 

이 취약점 분석의 목표는 TCPdump 4.9.2에서 CVE-2017-13028에 대한 크래시/PoC를 찾는 것이다.

 

TCPdump란?

명령 줄에서 실행하는 일반적인 패킷 스니퍼

 

CVE-2017-13028은 BOOTP 패킷(부트스트랩 프로토콜)을 통해 발생할 수 있는 범위를 벗어난 읽기 취약점이다.

범위를 벗어난 읽기는 프로그램이 의도한 버퍼의 끝을 지나거나 시작 전에 데이터를 읽을 때 발생하는 취약점이다.

그 결과, 원격 공격자가 서비스를 거부하거나 프로세스 메모리에서 잠재적으로 민감한 정보를 얻을 수 있다.

 

(권장 실행 환경은 ubuntu 20.04 버전이다.)

 

실습

 

 

타겟 다운로드&빌드

 

 

cd $HOME
mkdir fuzzing_tcpdump && cd fuzzing_tcpdump/

 

먼저 퍼징하려는 프로젝트에 대한 새 디렉토리를 만든다.

 

wget https://github.com/the-tcpdump-group/tcpdump/archive/refs/tags/tcpdump-4.9.1.tar.gz
tar -xzvf tcpdump-4.9.1.tar.gz

 

tcpdump-4.9.1.tar.gz를 다운로드하고 압축 해제한다. Fuzzing101에서는 4.9.2 버전을 설치하라고 하지만 CVE-2017-13028은 4.9.1 버전에서 패치되었기 때문에 4.9.2 이전 버전을 설치해주어야 한다.

(나는 인증서 오류가 생겨 --no-check-certificate 명령어를 추가해주었다.)

 

wget https://github.com/the-tcpdump-group/libpcap/archive/refs/tags/libpcap-1.8.0.tar.gz
tar -xzvf libpcap-1.8.0.tar.gz

 

TCPdump가 패킷을 캡처하기 위해 사용하는 라이브러리 libpcap-1.8.0.tar.gz를 다운로드하고 압축 해제한다.

 

mv libpcap-libpcap-1.8.0 libpcap-1.8.0

 

libpcap은 TCPdump와 같은 경로에 존재해야 하기 때문에 이름을 변경해준다.

 

cd $HOME/fuzzing_tcpdump/libpcap-1.8.0/
./configure --enable-shared=no
make

 

libpcap 빌드 및 설치

 

cd $HOME/fuzzing_tcpdump/tcpdump-tcpdump-4.9.1/
./configure --prefix="$HOME/fuzzing_tcpdump/install/"
make
make install

 

tcpdump 빌드 및 설치

 

$HOME/fuzzing_tcpdump/install/sbin/tcpdump -h

 

정상적으로 작동하는지 시험을 해준다. tcpdump와 libpcap 버전이 일치해야 한다.

 

 

Seed Corpus

 

$HOME/fuzzing_tcpdump/install/sbin/tcpdump -vvvvXX -ee -nn -r ./tests/geneve.pcap

 

./tests 폴더에 있는 .pcap 파일을 찾고 실행한다.

 

• -vvvv : 패킷정보를 자세하게 출력, -v가 많을 수록 많은 정보 출력
• -XX : 패킷 데이터를 16진수와 ASCII문자로 함께 출력
• -ee : 이더넷 헤더를 자세하게 출력
• -nn : 호스트 및 포트 번호를 DNS이름으로 해석하지 않고 숫자 형태로 표시
• -r './crash1' : tcpdump가 읽어오는 파일을 crash1 으로 함.

 

 

ASan

 

AddressSanitizer(ASan) 는 C 및 C++용 빠른 메모리 오류 감지기다. 원래는 Google(Konstantin Serebryany, Derek Bruening, Alexander Potapenko, Dmitry Vyukov)에서 개발했으며 2011년 5월에 처음 출시되었다.

컴파일러 계측 모듈과 런타임 라이브러리로 구성되어 있다. 이 도구는 힙, 스택 및 글로벌 객체에 대한 범위를 벗어난 액세스와 사용 후 해제, 이중 해제 및 메모리 누수 버그를 찾을 수 있다.

AddressSanitizer는 오픈 소스이며 3.1 버전부터 LLVM 컴파일러 툴 체인과 통합되었다. 원래는 LLVM 프로젝트로 개발되었지만 GCC로 이식되었고 GCC 버전 >= 4.8에 포함되었다고 한다.

 

 

ASan을 활성화하여 빌드

 

rm -r $HOME/fuzzing_tcpdump/install
cd $HOME/fuzzing_tcpdump/libpcap-1.8.0/
make clean

cd $HOME/fuzzing_tcpdump/tcpdump-tcpdump-4.9.2/
make clean

 

이제 tcpdump를 asan이 가능하도록 빌드한다. 이전에 컴파일된 모든 개체 파일과 실행 파일을 정리한다.

 

 

나는 여기서부터 오류가 났다.

cd $HOME/fuzzing_tcpdump/libpcap-1.8.0/
export LLVM_CONFIG="llvm-config-11"
CC=afl-clang-lto ./configure --enable-shared=no --prefix="$HOME/fuzzing_tcpdump/install/"
AFL_USE_ASAN=1 make

cd $HOME/fuzzing_tcpdump/tcpdump-tcpdump-4.9.1/
AFL_USE_ASAN=1 CC=afl-clang-lto ./configure --prefix="$HOME/fuzzing_tcpdump/install/"
AFL_USE_ASAN=1 make
AFL_USE_ASAN=1 make install

 

ASAN이 활성화된 tcpdump 및 libpcap를 빌드한다.

 

나는 tcpdump를 빌드하는 과정에서 오류가 났는데 afl-clang-lto의 환경 설정이 제대로 되지 않았다는게 내 추측이다.

afl의 설치를 확인하고 afl++를 재설치 해봤지만 오류가 해결되지 않았다.

afl-clang-lto 컴파일러를 사용하고 있는데, 컴파일러가 제대로 설정되지 않았거나 설치되지 않은 경우일 수 있다고해서 찾아봤지만 별다른 해결 방안을 찾지 못하여 일단 여기서 종료하였다. +필수패키지가 설치되지 않았다는 이유도 보여 시도해봤지만 이 이유는 아닌 것 같다.

 

 

퍼징

afl-fuzz -m none -i $HOME/fuzzing_tcpdump/tcpdump-tcpdump-4.9.1/tests/ -o $HOME/fuzzing_tcpdump/out/ -s 123 -- $HOME/fuzzing_tcpdump/install/sbin/tcpdump -vvvvXX -ee -nn -r @@

 

afl를 실행하여 퍼징을 시작한다. 

* 64비트 시스템의 ASAN은 많은 가상 메모리를 요청한다. 그래서 AFL에서 메모리 제한을 비활성화하는 플래그 "-m none"을 설정해준다.

 

 

이 이후 크래시 분석을 진행하면 된다.

 

 

방어 방법

 

다른 과제를 하다가 본 방안 중 하나인데 이 취약점에서도 IDS(침입 탐지 시스템) 설정을 통해 비정상적인 BOOTP 트래픽을 탐지하고, 모니터링을 통해 위험한 패킷 접근을 조기에 발견해 대응할 수 있도록 하면 좋을 것 같다.

 

 

공격이 쓰인 사례

 

공격이 쓰인 실제 사례는 구체적으로 찾을 수 없었다. 비슷한 취약점으로는 CVE-2014-9140와 같은 취약점이 있다. 이 취약점은 잘못된 패킷에 의해 발생하는 메모리 손상 문제로, 공격자가 특정한 유형의 패킷을 보내 tcpdump 프로세스를 충돌시키거나 예상치 못한 행동을 유발할 수 있다.

 

 

 

 

실패한 부분부터 재시도

 

에러를 무시하고 진행해봤다.

 

 

여기서도 에러 없이 진행

 

 

 

이렇게 떠서 퍼징에 성공한 줄 알았지만..

 

 

아무래도 앞 에러를 해결하지 않아서 퍼징을 수행하지는 못하였다.

 

..나와있는 다른 분의 글을 보고 나타나는 크래시 분석을 간단하게 정리해보겠다.

 

 

 

ndo->ndo_snapend = sp + h->caplen;

 

해당 멤버를 위와 같이 계산한다고 한다.

 

캡처된 길이인 caplen 멤버를 확인해보면 0x35로 실제 길이보다 작고 이 길이는 pcap 헤더에서 설정할 수 있다.

 

따라서 이 취약점은 데이터가 들어갈 공간이 충분히 할당되지 않았음에도 바운드 체크를 하지 않고, 오프셋 연산으로 데이터를 접근하려고 시도하다가 오버리드가 발생하는 취약점이다.

 

해결방안 >> 해당 값을 넉넉하게 설정해주면 취약점이 발생하지 않는다.

 

ND_TCHECK(bp->bp_flags);
	ND_PRINT((ndo, ", Flags [%s]",
		  bittok2str(bootp_flag_values, "none", EXTRACT_16BITS(&bp->bp_flags))));

 

ND_TCHECK 매크로는 매개변수의 주소값이 snapend를 넘지 않았는지 확인하는 매크로이며 패치는 위와 같이 나온다.

 

참고

https://lourcode.kr/posts/CVE-2017-13028(tcpdump)-%EB%B6%84%EC%84%9D/

CVE-2017-13028(tcpdump) 분석

 

 

(내가 분석한 내용이 아니라 틀린 부분도 정확하지 않은 부분도 있을 수 있음.)