CHIPSEC을 활용한 UEFI 펌웨어 감사은(는) 무엇을 하나요?
승인된 사용만 허용: CHIPSEC은 커널 드라이버를 로드하고 저수준 하드웨어 레지스터, SPI 플래시, SMM을 읽고 씁니다. 소유하거나 명시적으로 평가 권한을 부여받은 시스템, 가급적 전용 테스트 하드웨어에서만 실행하십시오. 오용(특히 쓰기/수정 모듈)은 시스템을 손상시킬 수 있습니다. 프로덕션 시스템에서 쓰기 가능 모듈을 절대 실행하지 마십시오.
개요
CHIPSEC은 Intel의 Advanced Threat Research 팀이 만든 오픈소스 플랫폼 보안 평가 프레임워크입니다. 부트킷과 펌웨어 임플란트가 존재하는 운영 체제 아래 계층인 x86 플랫폼 펌웨어 및 하드웨어의 저수준 보안 구성을 검사합니다. CHIPSEC은 서명된 커널 드라이버(Linux, Windows, 또는 UEFI 셸에서 실행 가능)를 로드하여 하드웨어 레지스터, 모델별 레지스터(MSR), PCI 구성 공간, SPI 플래시, UEFI 변수를 읽고 쓴 다음, 플랫폼의 방어 잠금이 실제로 활성화되었는지 확인하는 자동화된 테스트 스위트를 실행합니다.
CHIPSEC이 해결하는 위협은 MITRE ATT&CK T1542.001 — Pre-OS Boot: System Firmware입니다. 공격자는 시스템 펌웨어(SPI 플래시의 BIOS/UEFI 이미지)를 수정하여 은밀하고 지속적이며 OS에서 생존 가능한 제어권을 얻습니다. 펌웨어 임플란트는 OS 재설치 및 디스크 교체 후에도 지속되며 대부분의 EDR에 보이지 않습니다. CHIPSEC의 가치는 이러한 임플란트를 방지하는 전제 조건을 확인하는 데 있습니다: SPI 플래시 BIOS 영역이 쓰기 보호되었는지(BIOS_CNTL BLE/SMM_BWP, SPI 보호 범위), 플래시 설명자가 영역 접근을 잠그는지, SMRAM/SMRR이 구성되었는지, Secure Boot 변수가 보호되는지 등을 확인합니다. 또한 오프라인 포렌식 비교를 위해 SPI 플래시를 덤프합니다.
출처: Intel/CHIPSEC 프로젝트 (https://github.com/chipsec/chipsec), CHIPSEC 문서 (https://chipsec.github.io/).
사용 시기
- 새 노트북/서버 플랫폼 또는 플릿 이미지의 기준 펌웨어 보안 평가
- BIOS 쓰기 보호 및 SPI 플래시 잠금이 OEM에 의해 올바르게 활성화되었는지 확인
- 펌웨어 포렌식: 알려진 정상 이미지와 비교하기 위해 SPI 플래시 덤프
- Secure Boot 변수 보호 및 S3 부트 스크립트 보호 검증
- 펌웨어 임플란트 또는 이를 가능하게 하는 잘못된 구성의 증거 탐색
전제 조건
- 대상 x86 플랫폼(Intel 또는 AMD)에 대한 물리적 또는 관리자/루트 액세스
- Linux(루트) 또는 Windows(관리자), 또는 UEFI 셸 환경
- 커널 드라이버를 로드할 수 있는 능력(Secure Boot가 CHIPSEC 드라이버를 허용해야 하거나, 제한된 검사를 위해
--no_driver사용) - Python 3.8+ 및 Linux 커널 모듈을 위한 C 컴파일러/빌드 도구
- 전용 테스트 하드웨어를 강력히 권장
CHIPSEC 설치:
# PyPI에서 설치
pip install chipsec
# 또는 소스에서 설치(커널 헬퍼/드라이버 빌드)
git clone https://github.com/chipsec/chipsec
cd chipsec
python setup.py install # 빌드 및 설치, Linux 드라이버 포함
# 확인
sudo chipsec_main --help
sudo chipsec_util --help
목표
- 자동화된 전체 플랫폼 보안 테스트 스위트 실행 및 PASS/FAIL/WARNING 해석
- BIOS 쓰기 보호(BIOS_CNTL) 및 SPI 보호 범위 확인
- SPI 플래시 설명자가 영역 읽기/쓰기 액세스를 잠그는지 확인
- SMRAM/SMRR 및 SMI 핸들러 보호 확인
- Secure Boot 변수 보호 및 S3 부트 스크립트 보호 확인
- SPI 플래시 덤프 및 오프라인 분석을 위한 디코딩
- UEFI 변수 열거 및 비정상/예상치 못한 항목 감지
MITRE ATT&CK 매핑
| 기술 ID | 이름 | 전술 |
|---|---|---|
| T1542.001 | Pre-OS Boot: System Firmware | 지속성 / 방어 우회 |
CHIPSEC은 승인되지 않은 펌웨어 수정을 방지하는 제어 기능이 활성화되었는지 확인하여 T1542.001을 방어합니다. common.bios_wp(BIOS가 쓰기 보호되지 않음) 또는 chipsec.modules.common.spi_lock(플래시 설명자가 잠금 해제됨)에서 FAIL이 발생하면 OS 권한이 있는 공격자가 SPI 플래시를 다시 쓰고 지속적인 펌웨어를 이식할 수 있음을 의미하며, 이는 정확히 이 기술의 전제 조건입니다.
워크플로
1단계: 전체 자동화된 테스트 스위트 실행
chipsec_main을 모듈 인수 없이 실행하면 감지된 플랫폼에 대해 적용 가능한 모든 보안 검사를 실행하고 PASS/FAIL/WARNING/INFORMATION 결과 요약을 출력합니다.
sudo chipsec_main
# 보고/비교를 위해 기계 판독 가능 출력 저장
sudo chipsec_main -j results.json -x results.xml -l chipsec.log
2단계: 코어 펌웨어 보호 모듈 개별 실행
common 모듈 그룹에는 OEM 독립적인 보안 검사가 포함되어 있습니다. 그룹 또는 특정 모듈을 실행합니다:
# 전체 common 그룹 실행
sudo chipsec_main -m common
# BIOS 쓰기 보호: BIOS_CNTL BLE/SMM_BWP 및 SPI 보호 범위 확인
sudo chipsec_main -m common.bios_wp
# SPI 플래시 설명자 잠금(FLOCKDN) — 플래시 영역 액세스가 잠겼습니까?
sudo chipsec_main -m common.spi_lock
# SMRR 프로그래밍 — 캐시 기반 공격으로부터 SMRAM 보호
sudo chipsec_main -m common.smrr
# SMM BIOS 쓰기 보호
sudo chipsec_main -m common.smm
# S3 재개 부트 스크립트 보호(부트스크립트 테이블 공격 방지)
sudo chipsec_main -m common.uefi.s3bootscript
3단계: Secure Boot 변수 보호 확인
# Secure Boot UEFI 변수가 적절히 보호되었는지 확인
sudo chipsec_main -m common.secureboot.variables
# 변수의 쓰기 보호를 적극적으로 테스트하려면(테스트 하드웨어 전용):
sudo chipsec_main -m common.secureboot.variables -a modify
4단계: SPI 플래시 영역 액세스 권한 검사
# SPI 플래시 영역, 설명자, 액세스 권한 보고
sudo chipsec_util spi info
# SPI 액세스 제어 모듈 확인
sudo chipsec_main -m common.spi_access
5단계: 오프라인 포렌식을 위해 SPI 플래시 덤프
플래시를 덤프하면 펌웨어 볼륨을 디코딩하고 알려진 정상 OEM 이미지와 비교할 수 있습니다.
# 전체 SPI 플래시를 파일로 덤프
sudo chipsec_util spi dump rom.bin
# 덤프된 이미지 디코딩: 펌웨어 볼륨, 파일, NVRAM 변수 등 추출
sudo chipsec_util decode rom.bin
6단계: UEFI 변수 열거 및 분류
# 런타임 인터페이스에서 모든 UEFI 변수 나열
sudo chipsec_util uefi var-list
# SPI 이미지에서 직접 변수 나열(오프라인)
sudo chipsec_util uefi var-find PK
sudo chipsec_util uefi var-read db <GUID> db.bin
# UEFI 펌웨어 구조 디코딩
sudo chipsec_util uefi decode rom.bin
7단계: 커널 드라이버 없이 제한된 평가
드라이버를 로드할 수 없는 경우(강화된 Secure Boot), 일부 검사는 읽기 전용으로 계속 실행됩니다.
sudo chipsec_main -n # --no_driver: 드라이버가 필요한 검사 건너뛰기
sudo chipsec_main -p <PLATFORM> # 자동 감지 실패 시 플랫폼 코드 강제 지정
8단계: 결과 분류 및 보고
- FAIL
bios_wp/spi_lock→ 펌웨어가 OS에서 다시 쓸 수 있음: T1542.001에 대한 높은 위험. - FAIL
secureboot.variables→ Secure Boot 정책이 변조될 수 있음. spi dump를 OEM의 알려진 정상 이미지와 비교(펌웨어 볼륨 해시)하여 승인되지 않은 수정을 감지.- 보고서에 플랫폼, BIOS 버전, 모든 FAIL/WARNING과 관련 레지스터 값을 기록.
도구 및 리소스
| 도구 | 목적 | 출처 |
|---|---|---|
| chipsec_main | 자동화된 플랫폼 보안 테스트 스위트 | https://github.com/chipsec/chipsec |
| chipsec_util | 수동 하드웨어/펌웨어 액세스(spi, uefi, decode) | https://chipsec.github.io/ |
| UEFITool | 덤프된 UEFI 이미지의 GUI/CLI 파싱 | https://github.com/LongSoft/UEFITool |
| Binarly fwhunt | 펌웨어 취약점/임플란트 탐지 규칙 | https://github.com/binarly-io/fwhunt-scan |
| NSA UEFI Secure Boot 가이드 | 강화 참조 | https://media.defense.gov/ |
핵심 모듈 참조
| 모듈 | 검사 항목 |
|---|---|
| common.bios_wp | BIOS_CNTL BLE / SMM_BWP 및 SPI 보호 범위 |
| common.spi_lock | SPI 플래시 설명자 FLOCKDN |
| common.spi_access | SPI 플래시 영역 읽기/쓰기 권한 |
| common.smrr | 시스템 관리 범위 레지스터 프로그래밍 |
| common.smm | SMM BIOS 쓰기 보호 |
| common.secureboot.variables | Secure Boot 변수 보호 |
| common.uefi.s3bootscript | S3 재개 부트 스크립트 보호 |
검증 기준
- CHIPSEC 설치 및 드라이버 로드(또는 로드되지 않은 경우
-n문서화) - 전체
chipsec_main스위트 실행 및 JSON/XML/로그 출력 저장 -
common.bios_wp결과 해석(쓰기 보호 상태) -
common.spi_lock/spi_access결과 해석(설명자 잠금) - SMRR/SMM 모듈 결과 기록
- Secure Boot 변수 보호 확인
- SPI 플래시 덤프 및 오프라인 분석을 위한 디코딩
- UEFI 변수 열거 및 분류
- 모든 FAIL/WARNING 결과를 플랫폼/BIOS 버전과 함께 문서화
- 쓰기/수정 모듈을 프로덕션 하드웨어에서 실행하지 않음