라우터 TL-WR902AC를 예로 한 IoT 기기 블랙박스 퍼징

이 문서는 제 학기 논문의 HTML 버전으로, PDF는 여기에서 내려받을 수 있다.

서론

퍼징은 소프트웨어에서 버그를 찾는 "가장 효과적인 방법 중 하나"가 되었다. 이러한 주장이나 이와 유사한 주장으로 많은 최신 퍼징 관련 논문이 시작된다 [google-scholar]. "Internet of Vulnerable Things"라는 주제에 대한 지난 학기 논문의 주요 목표는 메모리 관련 버그를 찾은 다음 이 취약점에 대한 익스플로잇을 작성하는 것이었다. 우리는 펌웨어를 리버싱하여 취약점을 찾을 수 있었지만, 메모리 관련 버그는 발견되지 않았다. 바이너리를 수작업으로 리버싱하여 버퍼 오버플로를 찾는 것은 시간이 많이 걸릴 뿐만 아니라 많은 경험도 필요하다. 한편 퍼징은 이러한 메모리 관련 취약점을 찾는 "가장 효과적인 방법"이 되는 것을 목표로 한다. 예를 들어, Google은 오픈소스 소프트웨어를 지속적으로 퍼징하는 OSS-Fuzz를 도입했으며, 이미 1,000개 프로젝트에서 10,000개 이상의 취약점을 발견했다 [oss-fuzz].

이번 학기 논문의 목표는 다시 메모리 관련 취약점을 찾는 것이지만, 이번에는 퍼징을 사용하는 것이다. 목표 취약점은 관리자 자격 증명을 알지 못해도 네트워크를 통해 익스플로잇할 수 있어야 한다. 이 논문은 이 목표를 달성하는 방법을 설명한다. 이를 위해 이 논문은 두 부분으로 나뉜다. 첫 번째 부분은 유력한 대상을 찾는 방법, 사용할 수 있는 도구, 그리고 좋은 퍼징 대상이 무엇으로 구성되어야 하는지에 초점을 맞춘다. 두 번째 부분에서는 바이너리의 특정 함수를 퍼징할 수 있는 하니스를 개발하고 디버깅하는 방법을 설명한다. 그런 다음 개발된 하니스는 AFL++에서 대상 함수를 퍼징하는 데 사용된다. 다음에서는 간단한 배경을 소개하고 IoT 기기 퍼징에 관한 현재 최신 기술 수준이 어떠한지 설명한다.

이 학기 논문과 관련하여 생성된 모든 파일은 GitHub에 전체 공개되어 있으며 다음 URL에서 접근할 수 있다: otsmr/blackbox-fuzzing.

최신 기술 동향

IoT 기기를 퍼징하는 것은 오픈소스 프로젝트를 퍼징하는 것만큼 쉽지 않다. 소스 코드가 독점인 경우가 많아, 최상의 퍼징 성능을 위해 소스 코드를 계측하는 그레이박스 퍼징이 불가능하다 [afl-persistent]. 또한 CPU 아키텍처가 퍼저에 의해 기본적으로 지원되지 않는 경우가 많아 QEMU [qemu]와 같은 에뮬레이터가 필요하며, 이는 퍼징 속도도 저하시킨다 [afl-persistent]. 또 다른 문제는 하드웨어 주변기기로, 이는 일반적인 접근 방식의 개발을 어렵게 만든다. "Embedded Fuzzing: A Review of Challenges, Tools, and Solutions" [embedded-fuzzing] 논문은 하드웨어 기반 임베디드 퍼징과 같은 다양한 퍼징 전략에 대한 개요를 제공한다. 이러한 전략 대부분은 대상 프로그램의 소스 코드를 필요로 한다. 예를 들어 AFL과 같은 퍼저의 소스 코드를 ARM 기반 IoT 기기로 포팅하여 IoT 하드웨어에서 퍼저를 실행하는 경우가 있다. 기기 하드웨어에서 퍼저를 실행하는 것도 성능 문제가 있는데, IoT 기기는 일반 데스크톱 CPU보다 느린 저사양 CPU를 갖는 경우가 많기 때문이다. 이 논문에서 제시하는 또 다른 접근 방식은 에뮬레이션 기반 임베디드 퍼징이다. 단일 대상 프로그램을 에뮬레이터에서 실행하여 커버리지 기반 퍼징을 수행하거나 전체 시스템을 에뮬레이터에서 실행하는 방식이다.

위에서 언급한 접근 방식은 모두 에뮬레이터를 사용하거나 소스 코드를 계측하여 바이너리를 직접 대상으로 한다. 이러한 접근 방식은 단일 IoT 기기를 위해 특별히 제작되어야 하는 퍼징 환경이 필요하며 일반화하기 어렵다. 이를 위해 연구자들은 IoTFuzzer라는 프로그램을 만들었는데, 이는 "펌웨어 이미지에 대한 접근 없이 메모리 손상 취약점을 찾는 것 [iotfuzzer]."을 목표로 하는 자동화된 퍼징 프레임워크를 지향한다. IoTFuzzers는 대부분의 IoT 기기에 이를 제어하는 모바일 앱이 있고, 그러한 앱에는 기기와 통신하는 데 사용되는 프로토콜에 대한 정보가 포함되어 있다는 관찰에 기반한다. 그런 다음 이 프로그램은 프로그램별 로직을 식별하고 재사용하여 테스트 케이스를 변형함으로써 IoT 대상을 효과적으로 테스트한다 [iotfuzzer].

배경

하니스

하니스는 퍼저가 제공한 입력을 처리하는 일련의 API 호출을 설명한다. 하니스가 필요 없는 경우가 많은 일반 애플리케이션과 달리, 재사용 가능한 함수를 구현하는 라이브러리는 올바른 매개변수와 올바른 순서로 호출되어야 하므로 여러 공유 함수 호출 간의 상태가 유지될 수 있다. 상태 머신을 구축하지 않고 라이브러리를 무작위로 퍼징하는 것은 성공할 가능성이 낮으며, 반대로 라이브러리 종속성이 적용되지 않으면 많은 오탐 크래시가 발생하게 된다. 예를 들어 퍼저가 버퍼 크기 검사를 건너뛰어 가짜 버퍼 오버플로가 발생하는 경우가 이에 해당한다.

이 논문에서는 일반 애플리케이션을 퍼징하지만, 소켓 사용과 멀티스레딩의 하드웨어 종속성 때문에 이들에 대해서도 하니스를 만들어야 한다. 하니스는 바이너리의 컨텍스트에서 로드되며 대상 프로그램의 내부 함수를 호출할 수 있다. 이에 대한 예는 코드 10에서 확인할 수 있다.

코퍼스

"corpus"라는 용어는 유효한 입력 샘플 또는 테스트 케이스를 설명하며, 퍼징 과정에서 새로운 입력 데이터를 생성하기 위한 기본 참조 자료 역할을 한다. 코드 10에서 이는 예를 들어 HTTP 요청이 될 수 있다. 그런 다음 퍼저는 이 코퍼스를 활용하여 변형되거나 다양화된 테스트 케이스를 생성하며, 다양한 입력 시나리오를 탐색함으로써 소프트웨어 취약점 탐지를 돕는다.

유력한 대상 찾기

블랙박스 퍼징에서 가장 시간이 많이 걸리는 부분은 펌웨어에서 잠재적으로 취약한 함수를 찾는 것이다. 첫 번째 단계는 예를 들어 네트워크를 통해 접근 가능하거나, 안전하지 않은 함수를 사용하거나, 버퍼 오버플로 보호 기능인 스택 카나리와 같은 보안 기능이 활성화되어 있지 않은 흥미로운 바이너리를 찾는 것이다. 지난 논문 ([iovt])에서 이미 대상 라우터에서 펌웨어를 추출하는 방법과 잠재적으로 위험한 바이너리를 찾는 방법을 설명했다. 이를 위해 EMBA [emba] 도구가 사용되었다. EMBA는 펌웨어에서 발견된 모든 바이너리를 strcpy와 같은 안전하지 않은 함수의 수, 네트워크 접근, 그리고 스택 카나리나 NX-Bit와 같은 보안 보호 기능을 기준으로 순위를 매긴다. 이러한 요소들은 버퍼 오버플로를 익스플로잇할 때 중요해지며, 코드 1에서 확인할 수 있다.

```txt [+] STRCPY - top 10 results: 235 : libcmm.so : common linux file: no | No RELRO | No Canary | NX disabled | No Symbols | No Networking | 77 : wscd : common linux file: no | No RELRO | No Canary | NX disabled | No Symbols | Networking | [snip] 28 : httpd : common linux file: yes | RELRO | No Canary | NX enabled | No Symbols | Networking | 27 : cli : common linux file: no | No RELRO | No Canary | NX disabled | No Symbols | No Networking | ```

코드 1: 함수 strcpy의 안전하지 않은 사용에 대한 EMBA 결과.

본 논문의 목표는 관리자 자격 증명 없이 네트워크를 통해 악용할 수 있는 메모리 취약점을 찾는 것이므로, 취약한 함수는 네트워크를 통해 호출 가능해야 하며 제공된 사용자 입력과 직접 상호작용해야 합니다. 그러나 네트워크 상호작용이 있다고 해서 해당 바이너리가 네트워크를 통해 직접 접근 가능하다는 의미는 아닙니다. 어떤 바이너리가 수신 대기 중인지 확인하려면 [iovt]에서 이미 구축한 UART 루트 셸을 사용할 수 있습니다.

```txt ~ # netstat -tulpn Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:20002 0.0.0.0:* LISTEN 1045/tmpd tcp 0 0 0.0.0.0:1900 0.0.0.0:* LISTEN 1034/upnpd tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1027/httpd tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1224/dropbear udp 0 0 0.0.0.0:20002 0.0.0.0:* 1048/tdpd [...] ```

코드 2: UART 루트 셸을 사용하여 netstat 실행

바이너리 리버싱

가장 유망해 보이는 첫 번째 바이너리는 wscd입니다. 이 바이너리는 (libcmm.so 라이브러리를 제외하고) 가장 많은 안전하지 않은 strcpy 호출과 네트워크 상호작용을 가지며, wscd의 경우 이는 UPnP 장치에 연결하고 특정 포트에서 수신 대기하지 않음을 의미합니다. 나중에 살펴보겠지만, 퍼즈(fuzz)하기 쉬운 함수가 있어 이 바이너리가 이 논문에서 일반적인 절차를 설명하는 예제로 선택된 이유입니다. 리버싱 전에 UART 루트 셸을 사용하여 바이너리가 실행 중인지, 어떻게 시작되었는지 확인할 수 있습니다.

```txt $ ps PID USER VSZ STAT COMMAND 962 admin 1096 S wscd -i ra0 -m 1 -w /var/tmp/wsc_upnp/ 1018 admin 1080 S wscd_5G -i rai0 -m 1 -w /var/tmp/wsc_upnp_5G/ ```

코드 3: ps 명령을 사용하여 실행 중인 모든 프로그램 표시.

ps를 사용하면 바이너리가 실행 중인지뿐만 아니라 인수가 무엇인지도 확인할 수 있으며, 이는 잠재적 함수가 실제로 호출되는지 검증하는 데 중요합니다. 이러한 인수의 의미는 인수 없이 바이너리를 호출할 때 표시되는 CLI 도움말에서 확인할 수 있습니다.

```txt $ chroot root /qemu-mipsel-static /usr/bin/wscd Usage: wscd [-i infName] [-a ipaddress] [-p port] [-f descDoc] [-w webRootDir] -m UPnPOpMode -D [-d debugLevel] -h -i: Interface name this daemon will run wsc protocol(if not set, will use the default interface name - ra0) e.g.: ra0 -w: Filesystem path where descDoc and web files related to the device are stored e.g.: /etc/xml/ -m: UPnP system operation mode 1: Enable UPnP Device service(Support Enrolle or Proxy functions) 2: Enable UPnP Control Point service(Support Registratr function) 3: Enable both UPnP device service and Control Point services. [...] ```

코드 4: wscd 바이너리의 옵션.

코드 4에서 볼 수 있듯이 wscd는 "Enabled UPnP Device service"로 시작되는데, 이는 유망해 보입니다. 바이너리가 실제로 라우터에서 실행 중인지 확인한 후에는 Ghidra를 사용하여 바이너리를 분석하고 의심스러운 함수를 검색할 수 있습니다. 퍼징을 위해서는 파싱 함수가 특히 흥미로운데, 일반적으로 복잡하고, 파싱되는 입력에는 TCP 패킷이 페이로드의 길이를 포함하는 것처럼 포함된 데이터의 길이 필드가 있는 경우가 많기 때문입니다.