배경지식

Polling

• 하나의 장치/프로그램이 충돌 회피 또는 동기화 처리 등을 목적으로 다른 장치/프로그램의 상태를 주기적으로 검사하여 일정한 조건을 만족할 때 송수신 등의 자료처리를 하는 방식
• 이 방식은 버스, 멀티포인트 형태와 같이 여러 개의 장치가 동일 회선을 사용하는 상황에서 주로 사용됨. 서버의 제어 장치/프로그램은 순차적으로 각 단말 장치/프로그램에 회선을 사용하기 원하는지 물어봄
• 클라이언트 프로그램이 동기 활동으로 외부 장치의 상태를 적극적으로 샘플링하는 것을 의미. i/o 측면에서 가장 자주 사용되고, 이를 software-drive i/o라고 함.
• 하드웨어 구현의 좋은 예는 워치독 타이머

Digest

• 원본 데이터의 요약 또는 집약된 표현
• 해시함수의 결과물
  - 해시 함수는 어떤 길이의 데이터든지 고정된 길이의 고유한 값을 출력하는 함수. 해시 함수를 통해 생성된 고유한 값이 바로 digest

Persistent Memory

• 지속성 메모리
• 데이터 전원이 꺼진 후에도 유지할 수 있는 메모리 형태
• 전통적인 RAM과 하드 드라이브 또는 SSD 사이의 간극을 메우는 기술
  - RAM처럼 빠른 접근 속도를 제공하면서도, 하드 드라이브나 SSD처럼 데이터를 영속적으로 저장할 수 있음

Isomorphsim

• 아이소모피즘
• 두개의 구조나 시스템이 서로 같다는 의미
• 두가지 구조가 서로 일대일 대응 관계에 있고, 이 대응 관계를 유지하면서도 해당 구조의 연산이나 속성을 보전하는 경우를 가리킴
• 예) 두개의 그래프가 있을 때, 이 두 그래프의 노드와 연결 방식이 완전히 동일하다면, 이 두 그래프는 아이소모피즘 관계에 있다고 할 수 있음

---

Abstract

• 취약한 펌웨어 인증 과정에서 새로운 공격 발생
• 메모리 corruption bug와 다르게, 펌웨어 업데이트의 수많은 취약점은 (기존 펌웨어 분석 방법이 적용되지 않는) 불완전하거나 잘못된 검증 단계에서 비롯됨
• 그래서 ChkUp 제안
  - cross-language inter-process control flow anaysis와 프로그램 슬라이싱을 이용해서 펌웨어 업데이트 동안의 프로그램 실행 경로를 resolve할 수 있음
  - 이러한 경로들로 ChkUp은 취약점들을 검증하면서 펌웨어 인증 과정을 알아냄
• ChkUp을 12,000개 펌웨어 이미지에서 종합적인 분석 수행
• 33개 device faimiles의 150개 펌웨어 이미지에서, 0-day와 n-day 취약점을 일으킬 수 있는 alert 검증
• CVE ID 25개와 1개의 PSV ID assign 받음

Introduction

Firmware Update Security

• 기존 펌웨어 취약성 탐지 방법은 종종 사용자 제어 입력에서 안전하지 않은 싱크로의 호출을 식별하거나, 일반적인 취약 패턴 또는 알려진 사양의 deviation을 사용하여 버그를 찾는 데 중점을 둠
• 그러나 펌웨어 업데이트 취약성은 종종 multi-stage 업데이트 과정에 걸친 문제의 조합에서 발생하여 고유한 문제를 제기함
• 이는 취약한 패턴의 체계적인 분류나 포괄적인 사양의 부재로 악화됨

Our Solution - ChkUp

• 펌웨어 업데이트 취약점 check 접근
  - missing verification, improper verification
• chkup은 펌웨어 업데이트 과정에서 프로그램 실행경로 찾고, 업데이트 과정에서 인증 단계의 체인을 식별함.
• chkup은 취약점 탐지를 위해 여러 펌웨어 업데이트 단계에 걸쳐 취약한 패턴을 summarize함
• 위 두 과정에서, 펌웨어 업데이트 메카니즘의 존재하는 구현은 새로운 기술을 필요로 하는 챌린지가 있다는 것을 찾아냄.

1. Diverse System Components Supporting Firmware Update
   • 많은 리눅스 기반 펌웨어 이미지는 웹 서버의 프론트 엔드와 백 엔드 모두에 걸쳐 있는 소프트웨어 업데이트 실행 경로에서 프론트 엔드 프로그램, 스크립트 및 바이너리와 같은 다양한 유형의 프로그램을 호출
   • 프로세스간 통신(IPC) 메커니즘은 모두 달라서, 펌웨어 업데이트에 관여하는 컴포넌트의 다양성을 야기함
   • 이 문제들을 해결하기 위해, inter-process update flow graph(UFG)를 생성하는 기술을 향상시킴
   1. entry 프로그램은 먼저 일반적인 코드 패턴과 펌웨어 업데이트 과정에서 프론트와 백엔드를 연결해주는 의미론적인 정보를 사용해서 식별됨
   2. cross-language control flow들은 개별적인 프로그램(i.e., front-end programs, scripts, and binaries)의 제어 흐름을 연결하고 해당 IPC들을 resolve함으로써 추출됨
   3. 이러한 cross-language cross-program control flow graph에, 펌웨어 업데이트 실행 경로들은 펌웨어 update-specific semantics와 함께 백워드 프로그램 슬라이싱을 사용하여 resolve됨
2. Verificationi Procedure Recognition
   • 펌웨어 업데이트는 크립토그래픽 서명 증명부터 장비의 ID와 버전 비교까지, 많은 체크와 인증을 포함한 복잡한 절차임
   • 업데이트 절차는 모든 검증 단계(예를 들어, 서명 검증 또는 버전 업데이트 정책 준수) 및 그 구성이 적절하게 구현될 때에만 안전한 것으로 간주됨
   • 하지만, 펌웨어 업데이트는 표준화된 사양을 가지고 있지도 않고, 여러 프로그래밍 언어로 구현됨 ⇒ 실행 경로에서 많은 함수들로부터 이들을 식별해내기 어렵게하면서, 다양한 인증 구현을 필요로 함
   • 해결법
     - chkup은 DFG isomorphism 기반의 semantic 유사도 매칭을 사용해서 펌웨어 인증 절차를 식별함
     - 이 과정에서 오버헤드를 줄이기 위해
     1. 실행 경로 내 함수들은 유사도 스코어로 랭킹이 매겨지고, 이 유사도 스코어는 구문적/구조적 피쳐 모두 사용하여 계산됨
     2. 높은 유사도 스코어를 가진 함수들은 DFG isomorphism기반 분석을 위해 우선순위가 매겨짐
3. Vulnerability Validation
   • 정적 분석은 많은 FP를 발생할 수 있음. 이건 더 나아가 검증이 필요함
   • 그러나, 펌웨어 업데이트 절차는 종종 각각의 고유한 함수와 호출 파라미터를 갖는 일련의 검증 단계를 포함함
   • 체인에서 한 단계 나중에 테스트하기 위해서는, 첫 번째 여러 단계를 통과할 수 있는 input 및 환경을 생성해야 함
   • 검증을 단순화하기 위해서, 저자는 semi-automated 동적 메소드를 제시해서, 에뮬레잇이 가능한 펌웨어 이미지에 대한 alert을 검증했음.
   • 즉, 잠재적으로 취약한 절차의 실행을 보장하기 위해 펌웨어 패치를 사용함
   • 해당 alert의 검증은 악의적인 펌웨어 이미지를 주입한 후에 업데이트 행동 기반으로 검사됨

Evaluation and Findings

• 리얼 월드의 취약점에 더 깊은 이해를 얻기 위해, chkup을 12000 펌웨어 이미지에 돌림.
  - MD5 사용과 같은 약한 검증 알고리즘이 우세함
• 그리고 나서, 랜덤으로 선택한 펌웨어 이미지 150개에 취약점 검증 수행
  - 이 에뮬레잇 가능한 펌웨어 이미지에 대해, PoC들을 만듦으로써 동적 검증 수행
  - 남은 펌웨어 이미지들에 대해, 수동 분석 수행해서 이들의 alert 검증함
• 논문의 결과는 TPR 86.7%, FPR 5.3%를 보여주고, 33개 device family의 펌웨어 이미지에서 0-/n-day 취약점 모두를 찾아냄
• 25개 CVE ID와 1개 PSV ID assign됨
• 취약점 exploitability(악용 가능성)를 증명하기 위해, 펌웨어 다운그레이드와 펌웨엉 수정 공격을 시연함

Contributions

• A systematization of firmware update security
  - 일반적인 펌웨어 업데이트 과정을 4 단계로 프레임화했고, 펌웨어 업데이트와 관련된 CVE report 381개를 분석하고 카테고라이징함으로써 각 단계에서 보안 이슈를 시험했음
• A new approach for update vulnerability detection
  - chkup이라는 새로운 펌웨어 업데이트 취약점 식별 접근법 제시
  - 이는, 세가지 기술적 문제를 해결함
  - diverse components in update paths
  - verification procedure recognition
  - vulnerability validation
• Vulneratbilities on real-world firmware
  - chkup을 12000개 펌웨어 이미지에서 실행하고, PoC 조합을 사용해서 그들 중 150개 alert을 검증했음
  - 논문의 결과는 TPR 86.7%, FPR 5.3%를 보여주고, 33개 device family의 펌웨어 이미지에서 0-/n-day 취약점 모두를 찾아냄
  - 25개 CVE ID와 1개 PSV ID assign됨

Firmware Update Security Systematization

2.1 Challenges of Firmware Updates

• 증가하는 CVE들의 유행 뿐 아니라, 새롭게 떠오르는 임베디드 시스템에 구체적인 문제들에 기여함
• 이 문제들은 아래를 포함함 => 다양한 업데이트 펌웨어 메커니즘과 취약점 증가에 기여
  - 증가된 connectivity로 인한 확장된 공격 surface
  - 임베디드 시스템의 복잡성 증가
  - 긴 product life cycle
  - 임베디드 장비의 제한된 자원
  -

2.2 Update Workflow and Vulnerabilities

• 전형적인 펌웨어 업데이트 워크플로우는 4가지 단계를 가지고 있음(figure 2)
• ![[Pasted image 20240125124252.png]]

Generation Phase

• 이 단계의 목표는 펌웨어 이미지를 생성하고, 그들을 사용가능하게 하는 것임

1. 저자는 새로운 펌웨어 이미지와 manifest를 develop함. manifest는 펌웨어 digest, 버전, 디바이스 ID를 포함한 펌웨어 메타데이터를 포함하고 있음
2. 펌웨어 이미지와 manifest는 디지털 서명으로 서명됨
3. 서명된 펌웨어 이미지와 manifest는 소프트웨어 공급 체인을 통해 펌웨어 서버로 전달됨
   • 저자는 공급 체인에서 trusted parties를 통해 펌웨어를 서버로 업로드함

• during 이 단계, 외부 공격자들은 공급 체인 공격을 수행해서 인증서를 steal할 수 있고, 소프트웨어 개발 툴이나 인프라스트럭쳐를 손상시킬 수 있음
  - 이런 공격들의 root cause: 주요 자산과 인프라스트럭처에 대한 부적절한 액세스 컨트롤
• 공급 체인과 관련된 취약점들이 최근 몇년간 많이 보고됐고, 리얼 월드에서 이 취약점들의 보안 영향도 증명이 됐음
• 미국 정부와 3만개 이상의 공공/개인 기관들(MS, intel, fireeye)은 큰 규모의 소프트웨어 공급 체인 공격을 무서워함 => SolarWinds hack in 2020
  - 사이버 범죄자들은 orion IT management software를 손상키기고, 공급 체인을 통해 백도어를 포함한 악의적인 소프트웨어 업데이트를 유저들에게 퍼뜨림
• 핵심1: 공급 체인 취약점은 상당한 risk이고, 종종 부적절한 access control로 부터 발생함. 적절한 on-device 인증이 없으면, 손상된 펌웨어는 디바이스에 설치되고, 이 디바이스의 제어를 읽게 됨.

Delivery Phase

• 새로운 펌웨어 이미지를 서버에서 대상 디바이스로 전송하는 단계
• update agent라는 펌웨어 요소는 persistent 메모리 내 새로운 이미지에 대해 다운로드, 검증, 저장을 다룸
• 일반적으로, 새로운 펌웨어는 세가지 방식으로 전달됨
  - 펌웨어 서버가 직접적으로 펌웨어와 매니페시트를 디바이스의 update agent에게 push함
  - update agent는 업데이트를 폴링하여 사용할 수 있게 되면 업데이트를 다운로드함
  - 펌웨어 서버는 디바이스 유저/관리자에게 notify함. 이들은 수동으로 업데이트를 다운로드하고 update agent에 업로드함
• 통신 채널 측면에서, delivery interface의 흔한 메서드들
  - application layer 프로토콜(e.g., HTTP, FTP)
  - 무선 미디어(e.g., Wi-Fi, Bluetooth Low Energy)
  - 물리적 인터페이스(e.g., USB, removable memory card)
• 몇몇 low-end, bare-metal 디바이스의 경우 스마트폰의 companion 앱이 펌웨어 업데이트를 지원함
  - 새로운 펌웨어는 애플리케이션 계층 프로토콜을 통해 펌웨어 서버 내에 번들링되거나 앱에 의해 펌웨어 서버로부터 가져올 수 있음
  - 그러면, notification, 폴링, 다운로딩을 위해 이런 앱들은 무선 미디어를 통해 디바이스와 통신함
  - 앱들이 펌웨어를 전송하기 위한 중개자 역할을 하는 반면, 업데이트들을 미리 검증할 수도 있다는 점에 주목할 필요가 있음
• 이러한 조기 검증은 불필요한 후속 on-device 처리를 방지하기 위해, 유효하지 않은 업데이트를 걸러낼 수 있음
• secure한 통신 채널은 전달받은 펌웨어 이미지의 confidentialilty와 integrity에 중요함
• insecure한 전송은 주로 크립토그래픽 프로토콜의 부족 또는 하드코딩된 키들의 사용으로부터 발생하고, 시스템이 machine-in-the-mniddle(MITM) 공격에 노출됨
  - 예) CVE-2020-25233은 통신의 하드코딩된 RSA 키의 사용으로부터 바라생함
• 모바일 앱(such as CVE-2018-3928)
  - 펌웨어 서버 또는 장치 중 어느 하나와 불안정한 통신을 가질 수 있으며, 이 경우 통신 보안 검사가 불충분하면 코드 실행 취약점으로 이어질 수 있음
• 통신 채널만 걱정할게 아니라, 적절한 보안 검증의 부족도 걱정해야함
  - 예) 유출된 통신 키가 있더라도, 강력한 펌웨어 확인 메커니즘이 구축되어 있다면, 업데이트 중 악성 펌웨어 교체를 방지할 수 있음
• 핵심2: 펌웨어 전송 보안은 주로 통신 채널과 디바이스 유저/관리자에 의존함. 만약 둘다 insecure하면, 적절한 on-device 검증이 구축되어 있지 않으면, 디바이스는 손상된 펌웨어를 받게됨.

Verification Phase

• 전달받은 펌웨어의 authenticity, integrity, freshness, compatibility 보장하는 단계
• update agent가 일련의 검증 절차 수행한 후에, persistent memory에서 이미지를 저장함
  - 펌웨어 authenticcity: 펌웨어의 전자서명을 검증함으로써 보장
  - 펌웨어 integrity: 매니페스트에 포함된 digest를 확인함으로써 검증됨
  - freshness, compatibility: 매니페스트에 있는 버전과 디바이스 ID에 따라 메타데이터를 확인함으로써 검증됨
• 논문의 CVE 분석에 기반한 CWE 카테고리에서 펌웨어 업데이트와 관련된 취약점 top 10 (table 1)
  - ![[Pasted image 20240125141700.png]]
  - 47.67% 차지하는 상위 8개 카테고리는 펌웨어 업데이트에 대해 주로 missing verification 이나 inproper verification 메소드를 포함함
  - 이러한 문제로 인해 공격자는 업데이트 중에 일반 펌웨어를 악성 펌웨어로 교체할 수 있음
  - 예) CVE-2018-10988은 펌웨어 업데이트에 사용되는 쉘 스크립트에서 전자 서명 검증이 부족해서 발생함
  - 누락되거나 부적절한 integrity 검증: 펌웨어 corruption을 발생할 수 있음
  - 예) 펌웨어 integrity(무결성) 검사를 위해 쉽게 우회할 수 있는(bypassable) 내부 체크섬을 사용하는 것은 문제가 있음
  - 누락되거나 부적절한 freshness 검증: 펌웨어 다운그레이드 공격 가능
  - 부적절한 compatibility 검증: 디바이스에 DoS 공격 가능
  - 예) CVE-2018-3891의 root cause: 버전 검증을 수행할 때, 정수 비교 연산자가 문자열 비교에 잘못 사용되는 논리적 결함(logic flaw)
  - 예) CVE-2020-10831: 임의의 펌웨어가 불충분한 검증으로 인해 설치됨
• 핵심3: 검증 과정의 어떤 단계에서든 누락되거나 부적절한 구현은 임베디드 디바이스에 의도치 않은 펌웨어의 설치를 발생시킴

Installation Phase

• 새로운 펌웨어를 설치하고 실행하는 단계
• 검증 후에, 새로운 펌웨어는 디바이스의 persistent memory에 저장되고, 재부팅 시 활성화(activate)됨

1. bootloader는 디바이스가 시작할 때, 새로운 펌웨어 이미지를 디바이스 메모리 내 올바른 오프셋으로 옮김
2. bootloader는 펌웨어 검사가 실행된 후에, 새로운 펌웨어 이미지를 실행함
   • 하지만, 이 검사는 종종 미완성이고, insecure해서, 내부 체크섬에 의존함

• 이 단계에서의 대부분의 취약점은 전형적인 소프트웨어 버그임(command injection, memory corruption bugs)
• 이 단계에서 실행되는 펌웨어 업데이트와 관련된 command들은 유저 인풋으로부터 파라미터를 accept함
• 만약, 공격자가 이러한 파라미터를 조작하고, 이 파라미터들이 취약한 함수(예: 시스템, strcpy)에 의해 사용되면, command injection (e.g., CVE-2019-5155) or memory corruption (e.g., CVE-2021-22675) attacks 발생 가능
• 핵심4: 펌웨어 설치 중에 부트로더에서 불완전한 펌웨어 검사 절차가 일반적이며, 따라서 펌웨어 업데이트의 보안은 update agent 내의 검증 메커니즘에 의존하게 됨

Summary

• 보안 취약점들은 펌웨어 업데이트 절차의 어떤 부분에서든 일어날 수 있음
• 디바이스의 update agent의 강력한 펌웨어 검증 메커니즘이 다른 단계에서 발생하는 대부분의 취약점들을 완화시킴
• 그래서, 논문의 연구는 주로 검증 단계 내에서 취약점을 식별하는 데에 초점 맞춤

Threat Model and Overview

Threat Model

• chkup은 OS기반 펌웨어에서 펌웨어 업데이트 취약점을 발견하는데에 초점(특히, 우세한 리눅스 기반의 펌웨어)
  - chkup은 대부분의 우세한 펌웨어 업데이트 취약점들을 발견할 수 있음(authenticity, integrity, freshness, compatibility의 누락되거나 부적절한 검증 포함)
• 기존 연구들[19, 34, 36, 59, 83]을 align해서, 펌웨어 소스 코드 액세스가 없다고 가정하여 ChkUp을 바이너리 기반 취약성 탐지 접근 방식으로 만듦
• chkup의 잠재적 유저들: vendor에 통지하려는 보안 연구원이거나 디바이스에 대한 추가 보안 정보를 얻으려는 end-user
  - 소스 코드 분석이 바이너리 및 런타임 수준의 세부 정보를 간과할 수 있으므로, 소스 코드에 액세스할 수 있는 벤더도 특히 취약성의 악용 가능성을 조사할 때 이점을 얻을 수 있음
• 침입 탐지 시스템이나 멀웨어 디텍터와 마찬가지로, 심층적인 도메인 전문 지식은 경고를 더욱 정교화하는 데 가치가 있음을 증명하는게 중요함

Overview of ChkUp

• ChkUp의 high-level 아이디어
  1. 펌웨어 코드베이스로부터 펌웨어 업데이트 프로그램 실행 경로를 정적으로 추출
  2. 요약된 취약점 패턴을 기반으로 이러한 경로를 따라 잠재적인 취약점을 정확하게 파악
  3. 동적 취약점 검증 수행해서 false alert 줄임
• 하지만, 섹션 1에서 말했듯, 세가지 주요 챌린지들을 해결해서 이 아이디어를 구현해야함
  - C1. Diverse Programs in Update Paths during the extraction of firmware update execution paths
  - C2. Verification Procedure Recognition for matching vulnerability patterns
  - C3. Vulnerability Validation to reduce false alerts.
• 이 챌린지들 해결하기 위해, chkup을 제안함(figure 3)
  - ![[Pasted image 20240125151106.png]]
  - C1 해결
  1. 서로 다른 프로그래밍 언어로 작성된 프로그램 간의 제어 흐름 정보를 캡처하는 UFG 생성
  2. 백워드 프로그램 슬라이싱 수행해서, 펌웨어 업데이트 실행 경로 결ㅊ정(섹션 4.1)
  - C2 해결
  1. 구문/구조적 feature 추출해서 함수 매칭
  2. 더 정교한 DFG isomorphism 적용해서 펌웨어 업데이트 실행 경로에서 검증 체인들 식별(섹션 4.2)
  3. 실행 경로와 정교한 검증 과정으로 조사해서, 정의된 기준에 따라 취약점 찾아냄(섹션 4.3)
  - C3 해결
  - 패칭 기반 메소드
  - 패치를 통해 execution dependency가 우회된 후, 생성된 PoC를 사용하여 취약한 절차를 테스트하는 방법(섹션 4.4)

Design of ChkUp

4.1 Execution Path Recovery

UFG Definition

• karonte
  - karonte에서의 바이너리 의존성 그래프(BDG)는 펌웨어 이미지 내의 바이너리 간의 데이터 의존성을 모델링함. 이것은 펌웨어 엄데이트 취약점 탐지에 중요함
• however
  - 정확한 펌웨어 업데이트 실행 경로 복구는 추가적인 정보 필요함
  - 펌웨어 업데이트와 관련된 프로그램의 프로세스 내부/프로세스 간의 제어 흐름을 결정하기 위해
  - 추가적인 정보: 제어 흐름, IPCs, 다양한 언어의 프로그램에 걸친 프로그램 호출
• therfore
  - BDG를 기반으로 이러한 요구 사항을 수용하기 위해 UFG를 도입
• G: UFG는 펌웨어와 관련된 프로그램의 기본 블록 레벨에서, 프로세스 내부/프로세스 간의 제어 흐름 정보를 캡쳐하는 directed graph
  - UFG 정의: G=(V,E)
  - V: 펌웨어 업데이트 절차를 포함한 프론트 엔드 프로그램, 스크립트, 바이너리에서 추출된 기본 블록들의 집합
  - E: 기본 블록 간의 directed edges(e ∈ E)
  - 각 엣지들 e = ([v1, p1],[v2, p2], c)
  - 위 수식은 프로그램 p1의 기본블록 v1이 실행 흐름을 전송하거나 p2프로그램의 기본블록 v2와 데이터를 공유하는 것을 나타내고, c는 엣지의 타입을 나타내는 flag임
  - c의 값
  - 0: 프로세스 내부 제어 흐름 엣지들
  - 1: IPC 관계
  - 2: 프로그램 호출 관계

Update Entry Findings :: 엔트리 프로그램 식별

• 펌웨어를 receive하는 것은 디바이스 측에서 업데이트 절차의 첫번째 단계임
  - UFG의 엔트리 노드: 이 작업을 담당하는 노드임
  - 엔트리 프로그램: 엔트리 노드를 포함하는 프로그램
• 웹 기반 업데이트 인터페이스를 포함하는 펌웨어에 대해, 엔트리 프로그램은 프론트엔트 펌웨어 업데이트 유틸리티일 수 있음
• 엔트리 프로그램을 식별하기 위해, 저자는 static pattern-matching 접근법 사용
  - 펌웨어 업데이트 메커니즘이 다른 벤더들 간 크게 다른 문제를 해결하기 위해,
  - 수동적으로 많은 펌웨어 이미지를 분석하고, 펌웨어 업데이트 엔트리 프로그램을 다른 것들로부터 구별하는 패턴을 식별함
  - 이러한 엔트리 프로그램은 항상 인식 가능한 코드 패턴을 포함함
  - 예) 펌웨어 이미지를 업로드하기 위한 프론트엔드 프로그램은 <input type="file"...> 패턴을 사용
  - 예) 펌웨어 이미지를 다운로드 받는 스크립트나 바이너리는 wget ... 패턴을 사용
  - 엔트리 프로그램은 종종 펌웨어 업데이트와 관련된 함수 및 변수 이름(e.g., fw_version 및 fw_ upload)뿐만 아니라 공통 정보 단어를 포함하는 프롬프트 메시지를 표시함
• 이런 조사들을 기반으로, 저자는 사전 정의된 패턴 중 가장 많은 수와 일치하는 프로그램을 엔트리 프로그램으로 식별함

Cross-language Control Flow Analysis

• 엔트리 프로그램을 식별한 후에는 전달받은 펌웨어 이미지를 처리하기 위한 프로그램을 찾아야함
  - 이러한 프로그램은 다른 형태(바이너리, 쉘 스크립)로 나타날 수 있음
• 펌웨어 업데이트 중에 실행되는 프로그램의 제어 흐름에 대해 완전한 insight를 얻기 위해, cross-language 제어 흐름 분석은 중요함
• 하지만, 최근 경로 탐색 기반의 취약점 탐지 메소드들은 capacity가 부족함
• 이 문제를 해결하기 위해, 저자는 펌웨어 업데이트에 일반적으로 사용되는 다양한 프로그램 유형(즉, 자바스크립트와 쌍을 이루는 HTML, 셸 스크립트 및 바이너리)의 제어 흐름 로직, IPC 패러다임 및 프로그램 호출 패러다임을 해석 ⇒ UFG 구성
  1. 콜 그래프(CG)와 엔트리 프로그램의 프로시저 간 제어 흐름 그래프(CFG)를 구축하고 엔트리 프로그램에서의 IPC(즉, 소켓, 파일, 시그널, 환경 변수, NVRAM, 공유 메모리) 및 프로그램 호출 패러다임 식별
  2. 지원되는 프로그램 타입들과 IPC 패러다임들은 수동적인 펌웨어 분석으로 결정되고, 그들의 generlizability(일반화 가능성)는 많은 수의 펌웨어 이미지를 사용하여 경험적으로 측정됨
  3. 그러면, 엔트리 프로그램과 다른 관련된 프로그램들 간의 제어 의존성을 나타내는 dependency 엣지들이 생성됨
  4. 그 프로시저는 재귀적인 방법으로 반복되면서, 각 새로 생성된 프로그램의 CFG가 구축되고, IPC와 프로그램 호출 패러다임이 식별됨
• IPC 패러다임(nvram)과 이들 사이의 프로그램 호출 패러다임(eval)의 발견을 통한 두 프로그램의 커넥션(listing 1)
  - ![[Pasted image 20240125163508.png|450]]
  - 업데이트 관련 프로그램이 더 이상 발견되지 않으면 UFG 구축이 완료

Function-level Backward Slicing

• 구축된 UFG로, 함수 레벨의 백워드 프로그램 슬라이싱을 사용해서 펌웨어 업데이트 절차를 위한 프로그램의 가능한 실행 경로들을 결정함
• 전형적으로, 펌웨어 업데이트 절차는 새로운 펌웨어를 실행하기 위해 재부팅으로 끝남
• 그래서, 저자는 UFG에서 리부트 기능에 대한 호출, 특히 리부트 바이너리를 트리거하는 호출을 찾아 백워드 슬라이싱의 대상으로 설정
• 백워드 슬라이싱은 프로그램 전반과 내부에서 절차 간 제어 흐름을 따라서, 펌웨어 receiving 함수부터 시작해서, reboot 함수로 끝나는 모든 실행 가능한 경로들을 결정함
• 이러한 경로들은 잠재적인 펌웨어 업데이트 실행 경로를 나타냄
• 하지만, 어떠한 경로 기반 탐색 분석을 써도, 이 실행 경로 복구 방법은 경로 폭발과 경로 누락 문제가 발생할 수 있음
• 그래서, 저자는 경로 폭발 문제를 해결하기 위해 5가지 전략을 사용함
  1. 기본 라이브러리 스킵
  2. 빌트인 유틸리티 스킵
  3. 타임아웃 사용
  4. 프롬프트를 사용하여 경로 필터링
  - 실패한 펌웨어 업데이트의 오류 메시지를 기반으로 필터링하여 실행 경로를 개선하여 장치 재부팅을 야기한다.
  5. 경로 merging
  - 더 자세한 내용은 Appendix A.1

4.2 Verification Procedure Recognition

Two-stage Approach Overview

• 주요 함수는 펌웨어 검증에 사용되는 함수임(integrity 검증을 위한 hash 함수)
• 논문의 수동 분석은, 검증 절차가 모두 유사한 함수 집합을 달성하려고 하기 때문에, 종종 유사한 주요 함수 집합을 사용한다는 것을 보여줌
• 더불어, 리턴 변수나 pass-by-reference 인자 같은 함수로부터 온 값들은 종종 조건식으로 흘러 들어감
  - 그럼, 이 식들은 어떤 조건부 분기를 취할지에 영향을 미침
  - 예) 펌웨어 integrtiy를 검증할 때 예시를 볼 수 있음(listing 2)
  - ![[Pasted image 20240125165249.png]]
  - hash 함수의 리턴 값은 조건식에 사용돼서, 검증 결과를 결정함

1. 검증 절차를 식별하기 위해, 저자는 일반적인 주요 함수로부터 함수 서명들의 corpus를 구축함
2. 실행 경로들의 검증 절차들을 두가지 stage로 식별함
   1. 효율적인 함수 유사도 매칭: 관련없는 함수들을 빠르게 걸러냄
   2. 검증 절차 체인 식별: 정확한 식별을 위한 향상된 semantic 분석 사용

Efficient Function Similarity Matching

• first stage
• 목표: 구문/구조적 피쳐로 함수를 rank 매겨서 검증 절차 체인들 식별의 효율성 향상시키기
• Kim[39]
  - numeric 구문/구조적 피처의 사용으로 더 복잡한 딥러닝 기반 방법과 비슷한 정확도를 달성
  - 그래서, numeric 피처들의 조합은 두가지 이유로 선택됨(table 4 in Appendix A.2)
  1. 이러한 피처들은 복잡한 semantic 코드 분석 없이도 효율적으로 추출됨
  2. 이러한 피처들의 조합은 다양한 아키텍처, 컴파일러 유형 및 코드 스트립핑에 걸쳐 강력하고, 높은 판별 능력을 달성할 수 있음
  - 이러한 피처에 대한 컴파일러 최적화의 영향은 안정적이고 산업 표준 컴파일러 옵션이 일반적으로 사용되는 임베디드 시스템에서 덜 중요하며, 이를 통해 피처의 견고성을 보장한다는 점에 주목할 필요가 있음
• 저자는 함수 호출 수 및 키 문자열과 같은 추상 구문 트리(AST)의 속성을 포함하여 코드의 중간 표현(IR)에서 구문 피처를 얻음
• 구조적 피처들은 CFG에서 얻음. 여기에는 기본블록, 엣지, 분기들의 수가 포함됨
• 이렇게 추출된 특징들을 이용해서, 실행 경로에 있는 함수들과 corpus안에 있는 함수들 간의 유사도 점수들은 그 특징 값들 간의 상대적인 차이에 기반하여 계산됨
  - 이 스코어들은 더 높은 유사도 스코어를 가진 함수들을 우선순위를 매김으로써 두번째 스테이지에서 효율성을 향상시킴
• 임계값(논문에서는 0.5)보다 낮은, 유사한 스코어를 가진 함수 쌍들은 필터링 됨. 유사도 가능서이 희박하기 때문
  - 추출한 피처들과 유사도 스코어의 수학적 구조와 유사도 임계값 결정의 더 자세한 내용은 Appendix A.2

Verification Procedure Chain Identification

데이터 흐름 그래프(DFG)는 데이터와 산술 및 논리 연산 사이의 관계를 나타낼 수 있으며 암호화 원시 식별 기법에 사용된다[47, 51]. 정확한 시맨틱스 분석을 통해 핵심 함수를 추가로 식별하기 위해 DFG 하위 그래프 동형화를 사용한다. 함수 시맨틱스 외에도 주요 함수의 반환 변수 및 참조 전달 인수의 사용 패턴은 검증 절차 일치의 FP를 줄이는 것으로 간주된다. 통찰력은 키 함수의 반환 변수 또는 인수가 종종 조건식으로 공급된다는 것이다. 그런 다음 이 식은 실행할 조건부 분기를 결정하고 검증 절차의 통과 또는 실패 상태를 나타낸다. 함수 md5_verify_digest의 반환 변수가 무결성 검증을 통과했는지 여부를 결정하는 데 사용되는 목록 2에서 예를 볼 수 있다.
저희는 모든 실행 경로에서 검증 절차 체인을 검색합니다. 각 실행 경로에 대해 다양한 유형의 검증 절차가 연속적으로 식별됩니다. 진위 검증과 같은 검증 절차를 식별하기 위해 먼저 유사도 점수가 가장 높은 함수 쌍(f, f')을 선택하고, 여기서 f는 실행 경로에서, f'는 말뭉치에서 진위 검증을 위한 핵심 함수입니다. 그런 다음 함수 f의 DFG를 구성하고 정규화하여 개발자, 컴파일러 최적화 또는 기계 코드 번역에 의해 도입된 변형을 제거합니다. DFG를 사용하면 Ullman의 알고리즘 [71]을 사용하여 f'의 그래프 시그니처와 동형인 f의 DFG에서 하위 그래프를 검색하여 함수 f와 f'가 기능적으로 동등한지 확인할 수 있습니다. 일치하는 것이 발견되면 함수 f는 의미론적으로 함수 f'와 동등한 것으로 간주됩니다. 그런 다음 f의 반환 변수 및 통과 참조 인수에 대해 reaching-definition 분석을 수행하여 데이터 흐름 슬라이스를 얻습니다. 반환 변수 또는 인수가 조건식으로 흐르면 검증 절차가 식별되는 것으로 간주됩니다. 유사도 점수 임계값을 초과하는 나머지 함수 쌍이 없으면 일치하지 않으면 다음 함수 쌍이 다음으로 높은 유사도 점수를 갖는 것으로 프로세스를 계속합니다. 두 번째 단계가 완료되면 모든 실행 경로의 검증 절차 체인이 식별되고 추가로 검토할 준비가 됩니다.

• DFG는 데이터와 수학적/논리적 연산 간의 관계를 나타내고, 크립토그래픽 primitive 식별 기술에 사용됨
• 정확한 sematics 분석을 가진 주요 함수들을 더 식별하기 위해, DFG 서브그래프 isomorphsim을 적용함
• 함수 semantics 외에도 주요 함수의 리턴 변수와 pass-by-reference 인자의 사용 패턴도 검증 절차 매칭의 FP를 줄이기 위해 고려됨
• 인사이트: 주요 함수의 리턴 변수 또는 인자들은 종종 조건 식으로 흘러 들어감
  - 그럼 이 식은 조건 분기를 결정해서, 검증 절차의 pass/fail 상태를 실행하고, 표시함
  - 예) md5_verify_digest 함수의 리턴 변수가 integrity 검증에서 pass 되는지 결정함 (listing 2)
• 저자는 모든 실행 경로의 검증 절차 체인을 탐색함
  - 각 실행 경로에 대해, 검증 절차의 다양한 타입이 성공적으로 식별됨
  1. 검증 절차를 식별하기 위해(such as authenticity 검증), 저자는 가장 높은 유사도 스코어를 가지는 함수 쌍(f, f')를 선택함
  - f: 실행경로에서 왔고; f': corpus 내 authenticity 검증을 위한 주요 함수임
  2. 함수 f의 DFG는 개발자, 컴파일러 최적화 또는 기계 코드 번역에 의해 도입된 변형을 제거하면서, 그것의 기본 의미를 보존하기 위해 구축되고 정규화됨
  3. DFG로, 저자는 f'의 그래프 서명과 isomorphic한 f의 DFG에서 서브그래프를 탐색함으로써, f와 f'가 기능적으로 유사한지 검증(Ullmann’s algorithm 사용)
  4. 만약 매치를 찾았다면, 함수 f는 함수 f'와 semantical하게 동등하다고 고려됨
  5. f의 리턴 변수와 pass-by-reference 인자에서 reaching-definition 분석 수행해서, data-flow 슬라이스 얻음
  6. 만약 리턴 변수나 인자가 조건식으로 흘러들어가면, 검증 절차는 식별됐다고 고려됨
  7. 이 과정은 유사도 점수 임계값을 초과하는, 남은 함수 쌍이 없는 한, 매치가 발견되지 않으면, 다음으로 높은 유사도 점수를 갖는 다음 함수 쌍으로 계속됨
  8. 두 번째 단계가 완료되면, 모든 실행 경로의 검증 절차 체인이 식별되고, 추가로 검사할 준비가 된 것임

Corpus Creation

• 주요 함수는 기본 라이브러리 함수이거나 proprietary(독점적인) 함수임

1. authenticity 및 integrity 검사를 담당하는 함수는 종종 잘 구축된 라이브러리에서 표준 암호화 루틴을 캡슐화함
2. 1번이 끝나면, 일반적으로 임베디드 시스템에서 사용되는 라이브러리의 오픈소스 크립토그래픽 함수를 수집함
3. freshness와 capability 검사에 사용된 함수가 독점적이더라도, 논문의 분석에 기반하여 같은 디바이스 패밀리 내에서 유사도를 공유함
   • 이들은 다양한 주요 벤더의 펌웨어 이미지를 리버스 엔지니어링해서 얻을 수 있음
4. 모든 함수들을 두개로 카테고라이징함
   1. 적절한 크립토그래픽 알고리즘을 적용했거나, 보호된 검증 정보를 assess한 것들
   2. 그렇지 않은 것들(섹션 4.3)
5. 피쳐 벡터와 그래프 표현으로 구성된 함수 서명 추출하기
   • 피쳐 벡터는 구문/구조 분석을 통해 도출, 그래프 표현은 DFG를 구축/정규화/프루닝한 후에 생성됨
   • normalization은 중복되는 노드와 엣지를 제거하고, 이어서 검증 프로세스와 무관한 요소를 제거하기 위한 가지치기의 역할
   • 이 접근법은 기존 연구에서 흔히 사용됐음(가능한 광범위한 구현에 걸쳐 정확한 기능 일치를 보장하기 위해)

• 프로세스는 필수적인 검증 데이터를 보유하고 있는 변수나 인자를 정확히 파악해야 함
  - 이들을 타겟으로 설정한 후, 프로그램 슬라이싱을 실행하여 모든 관련 노드 및 엣지를 유지함
  - 더 자세한 corpus 확률은 Appendix A.3

• corpus를 생성한 이유는 뭐야?
  - Corpus를 생성한 이유는 ChkUp에서 사용되는 key functions을 수집하고, 이를 기반으로 firmware update verification procedures를 인식하기 위해서입니다. 이를 위해, open-source cryptographic functions과 reverse engineering을 통해 얻은 proprietary functions을 수집하고, 이를 두 가지 카테고리로 분류하여 function signatures를 추출합니다. 이를 통해, ChkUp은 firmware update execution paths에서 verification procedures를 인식하고, 이를 기반으로 vulnerabilities를 발견할 수 있습니다.

• 조금 더 빨리 함수를 찾아서 검증 절차를 식별하기 위해서 corpus를 생성한거야?
  - 네, 맞습니다. ChkUp에서는 key functions을 수집하고, 이를 기반으로 efficient function similarity matching을 수행하여 빠르게 검증 절차를 식별할 수 있도록 합니다. 이를 위해, corpus를 생성하여 function signatures를 추출하고, 이를 이용하여 실행 경로에서 verification procedures를 인식합니다. 이를 통해, ChkUp은 빠르게 검증 절차를 식별하고, 이를 기반으로 vulnerabilities를 발견할 수 있습니다.

4.3 Vulnerability Discovery

Vulnerability Discovery Criteria

• 저자는 네가지 속성의 적절한 검증 절차의 구현 deviation을 검사하는데 초점
  - authenticity, integrity, freshness, compatibility
• 대부분의 검증 단계 취약점을 위한 검증 account의 부족이 있더라도, 검증 절차의 부적절한 구현 또한 insecure하고 explotiable한 검증 절차를 발생 시킴
• 논문에서는
  - 부적절한 authenticity 검증의 root casue: symmetric 크립토그래픽 알고리즘(HMAC, CMA, Poly1305)의 사용으로부터 발생함
  - 부적절한 integrity 검증의 root casue: 약한 digest 검증 알고리즘(CRC, SHA1, MD5)
  - freshness와 compatibility 검증: 펌웨어 버전과 compatible한 디바이스 ID를 포함한 검증 정보는 보호받지 않는 데이터 소스(e.g., 펌웨어 이미지의 파일명)로부터 추출될 때, 검증은 insecure함

Vulnerability Discovery Process

1. 관련된 검증 절차와 실행 경로 모두 검사함으로써 취약점 식별
   • 만약 펌웨어 이미지가 하나의 실행 경로를 포함한다면, 그 경로에 초점 맞춤
   • 여러 경로를 가진 펌웨어에 대해서는, 가장 적절한 검증 절차를 가진 경로를 선택함 -> 이는 종종 철저한 검증을 나타냄
   • 이 방법들은 FP를 줄이고, 더 보수적인 취약점 식별을 보장함
2. 취약점 탐지는 이전에 정의된 기준에 따라 단독 또는 선택된 경로에서 수행됨
   • 누락된 검증 취약점들을 식별하기 위해, 저자는 실행 경로 내 authenticity, integrity, freshness, compatibility를 위한 검증 절차의 존재를 확인함
   • 부적절한 검증 취약점들을 탐지하기 위해, 저자는 실행 경로 내 해당 검증 절차에서 부적절한 함수들의 사용을 검사함
3. 일부 펌웨어 이미지는 취약한 알고리즘을 사용하여 빠른 무결성 검사를 수행하고, 이어서 디지털 서명/MAC 알고리즘에 기초하여 authencity 및 integrity에 대한 보다 철저한 검증을 수행함
4. 논문은, 해당 전자 서명/MAC에서 사용된 알고리즘 또한 insecure할 때, 부적절한 integrity 검증이라고 alert report

4.4 Vulnerability Validation

PoC Creation

PoC 생성 : 이 연구에서는 테스트 중인 보안 속성을 특별히 위반하는 PoC 입력을 제공하여 경고를 동적으로 확인합니다. 즉, 펌웨어 업데이트 절차가 재부팅 단계에 도달하는지 관찰합니다. 만약 그렇다면 취약점이 존재하고, 그렇지 않다면 경고는 FP(False Positive, 잘못된 양성)입니다.

예를 들어, 호환성 검증이 누락된 경우를 확인하기 위해, 동일한 장치 패밀리에서 호환되지 않는 버전으로 정상 펌웨어를 대체합니다. 하지만 이 과정에서 다른 속성이 변경될 수도 있어 원인 분석을 복잡하게만듭니다. 따라서 ChkUp은 이 문제를 완화하기 위해 테스트 펌웨어를 패치하고 재패키징하여 테스트 중인 속성과 검증 절차의 실행 경로를 일치시킵니다.

요약하자면, 이 연구에서는 펌웨어의 보안 취약점을 확인하기 위해 PoC를 생성하고, 이를 통해 경고의 유효성을 확인합니다. 이 과정에서 테스트 중인 보안 속성을 위반하는 특정 입력을 제공하고, 이로 인해 펌웨어 업데이트 절차가 재부팅 단계에 도달하는지 관찰합니다. 이를 통해 보안 취약점의 존재 여부를 확인합니다.
1. test를 통해 보안 속성을 위반하는 PoC 인풋을 feed함으로써 동적으로 laert를 검증함
2. 펌웨어 업데이트 절차가 아직 reboot 단계에 도달한건지 검사
1. 만약 그렇다면, 취약점 존재
2. 그렇지 않으면, 이 alert은 FP
3. PoC 이미지는 alert 타입에 따라 바뀜(table 2)
- ![[Pasted image 20240126110410.png]]
4. 누락된 compatibility 검증을 검증하기 위해, 일반 펌웨어를 동일한 디바이스 제품군의 호환되지 않는(incompatible) 버전으로 교체

• 하지만, 이 절차는 또한 다른 속성을 변경하여 root cause 분석을 복잡하게 할 수 있음
  - 예) 선택한 펌웨어 이미지가 부적절한 버전 넘버를 포함할수도 있음
  - 이러한 이슈를 완화시키기 위해, chkkup은 테스팅 펌웨어를 패치하고 repack해서, 테스트에서 속성을 가진 검증 절차의 실행 경로를 align함

Patch Generation

• 테스트 중인 특정 속성의 취약성 검증을 방해할 수 있는 검증 절차를 생략하기 위해 패치를 적용
• 패칭은 프로그램 타입에 따라 소스코드나 바이너리 수준에서 수행됨
• 코드를 추가하지 않고 조건식을 invert(반전)시켜 본질적으로 그 반대(e.g., equal to not equal)의 비교를 변경함
• TP-Link 펌웨어 이미지의 compatibility 검증 절차의 디셈블리와 디컴파일된 코드(listing 4 in Appendix A.4)
  - 이 절차는 getProductVer() 함수를 사용하여 현재 제품 ID를 가져오고, 파일 body(본문)에서 새 펌웨어의 호환(compatible) 제품 ID를 추출
  - ID 비교는 bne(branch if not equal) 명령어로 수행됨
  - PoC 펌웨어를 가진 검증을 우회하기 위해, bne명령어를 beq로 대체
  - 대부분의 검증 절차가 직접적인 조건식을 사용하더라도, 일부는 다양한 논리 연산자와 여러 변수를 포함한 복잡한 조건을 포함함
• 이러한 복잡성은 비교를 부정하는 것과 같은 간단한 방법들을 효과적으로 만들지 못함
  - 이를 해결하기 위해서
  1. 일반 이미지를 가진 성공적인 펌웨어 업데이트를 수행하고, 조건식을 포함한 변수들의 값들을 기록함
  2. 정적 value-flow 분석을 수행해서, 이러한 변수들로부터 백워드 tracing을 하고, 이들의 값들이 정의된 명령어를 식별함
• 이러한 명령어들은 일반적으로 같은 함수 내에 있음을 나타내어 복잡한 제어 흐름 복구의 필요성을 배제함
• 마지막으로, 기록된 값들과 식별된 명령어로, 이전에 기록된 값을 사용하기 위해 in-place binary rewriting 기법을 사용하고, 교체(replacement)가 interst한 펌웨어 실행 단계에만 적용되도록 조건을 포함

Implementation

• ChkUp은 ARM, MIPS, PowerPC를 포함한 다양한 아키텍처에서 리눅스 기반 및 다른 임베디드 OS 기반 펌웨어 이미지를 모두 지원하도록 프로토타입화되었음
• Execution Path Recovery 모듈
  - 각 펌웨어 이미지를 위한 UFG를 300초 타임아웃 내에서 효과적으로 구축했음
  - NetworkX를 이용한 각 UFG를 directed graph로 나타냄
  - 다양한 프로그램의 제어 흐름은 바이너리를 위한 angr와 같은 툴들로 분석됨
  - IPC와 프로그램 호출 패러다임은 KARONTE의 CPF 모듈 기반으로 식별되고, 자바스크립트와 쉡 스크립트를 지원하기 위해서 확장됨
  - UFG 구축 이후에, 실행 경로 복구는 함수 레벨에서 NetworkX의 Simple Paths 모듈을 사용하여 수행됨
• Verification Procedure Recognition 모듈
  - numeric한 피처들은 소스코드(자바스크립트, 쉘 스크립트), CFG, 디스어셈블/디컴파일된 코드(Ghidra 사용)로부터 추출됨
  - Meijer로부터 정규화된 룰들을 사용하여 DFG를 구축하고 정규화할 때,DFG 서브그래프 isomorphism을 위해 Ullmann의 알고리즘을 적용해서 검증 절차 식별함
• Vulnerability Discovery 모듈
  - 이전 두개의 모듈에 기반하고, 설명된 criteria와 프로세스를 사용하여 취약점 탐지 수행함
• Vulnerability Validation 모듈
  - Firmadyne은 처음에 동적 분석에 사용되고, 만약 에뮬레이션이 성공적이지 못하면, 더 향상된 FirmAE를 적용함
• 추가로, Ghidra와 Firmware-mod-kit은 펌웨어 이미지를 패치와 repack 하기 위해 사용됨

Evaluation

• chkup의 세가지 주요 모듈의 효과성 평가
  - Execution Path Recovery, Verification Procedure Recognition, Vulnerability Validation

Datasets

• IoT 벤더 웹사이트에서 157,141개 펌웨어 이미지 수집해서, 111,958개로 unpack 성공
• large-scale 분석을 위해
  - DL: 8개 메이저 벤더에서 12,000개 펌웨어 이미지 랜덤으로 샘플링해서 생성(Netgear, TP-Link, D-Link, TRENDnet, Asus, Ubiquiti, Zyxel, Linksys)
• chkup의 효과성 평가, alert 검증을 위해
  - DG(ground truth dataset): DL로부터 샘플링해서 생성
• DG에서의 펌웨어 이미지에 대한 근거자료(ground truth) 구축은 4명의 보안 전문가들이 수작업 분석을 통해 수행
  - 데이터셋 구축과 수동 분석에 대한 디테일(Appendix B.1, Appendix B.2)

Experimental Environment

• Ubuntu 18.04 LTS OS server
• AMD EPYC 7302P CPU with 64GB of RAM

6.1 Effectiveness of Execution Path Recovery

• 이 모듈의 효과는 복구된 실행 경로의 정확성 뿐만 아니라 업데이트 항목 발견의 정확성에 의해 평가됨

Accuracy of Update Entry Finding

• 업데이트 엔트리 프로그램은 3가지 패턴을 사용하여 식별
  1. P1: prompt message
  2. P2: variable and function name
  3. P3: common code
• 각 유형들의 패턴 효과성을 평가하기 위해, 다양한 설정(P1 없이, P2 없이, P3 없이, 모든 패턴)에서 식별된 입력 프로그램의 정확성을 평가하는 절제 연구를 수행
• DG의 각 벤더의 펌웨어 평가 결과는 Figure 4a
  - ![[Pasted image 20240126144035.png]]
  - highest accuracy: 모든 패턴 사용
  - lowest accuracy: P2없이 적용됐을 때
  - P2가 이 절차에서 가장 중요하다는 걸 알 수 있음
  - 대부분 벤더의 펌웨어 이미지에 걸쳐, 이 존재가 상당한 퍼포먼스 하락을 야기했기 때문
  - P1과 P3의 영향은 벤더사마다 다름
  - P1은 TP-Link, TRENDnet, Zyxel에서는 펌웨어 이미지에 상당한 영향을 미치고, P3는 Netgear, Asus에서 중요함
  - 모든 패턴 사용했을 때
  - 식별은 대부분의 펌웨어 이미지의 업데이트 엔트리 프로그램을 정확하게 식별함으로써 그 견고성을 입증함
  - 9개의 Netgear 펌웨어 이미지는 제한된 의미 정보로 인해 업데이트 항목이 잘못 식별되었음
  - 하지만, 이러한 잘못 식별된 프로그램의 대부분은 여전히 펌웨어 업데이트와 관련되어 있지만 펌웨어 전달 이외의 업데이트 역할을 처리함

Correctness of Execution Path Recovery

• DG의 펌웨어 이미지에 이 모듈을 실행할 때, chkup은 각 이미지에 대해 평균 126초를 소요함(figure 4c)
  - ![[Pasted image 20240126144735.png]]
  - 생성된 150개 UFG 중
  - 122개: 펌웨어 업데이트 sound하고 complete함
  - 136개: sound만 함(UFG의 모든 엣지들은 업데이트 절차에서 제어 흐름이나 IPC 패러다임을 나타내기 때문)
  - 하지만, 7개 Asus, 4개 D-Link, 3개 Zyxel 펌웨어 이미지들의 UFG는 unsound해서, 관련 없는 IPC 패러다임이 생성됨
  - 133개 UFG들은 complete하고, 관련된 모든 제어 흐름과 IPC 패러다임 포함함
  - 하지만, 9개 Netgear 펌웨어 이미지의 UFG는 incomplete(업데이트 엔트리 잘못 식별했기 때문)
  - 위에서 언급한 Zyxel 펌웨어 이미지의 3개의 UFG도 incomplete함(업데이트 엔트리와 백엔드 핸들러 간의 미스매치 때문)
  - 나머지(5개 TP-Link 펌웨어 이미지)는 incomplete(UFG 구축에서 타임아웃 발생 때문)
• sound하고 complete한 UFG들은 항상 올바른 경로를 복구함
• unsound 혹은 incomplete한 UFG들은 백워드 슬라이싱 과정에서 올바르지 않은 경로를 발생시키거나, 올바른 경로를 간과해버림
  - 예) Zyxel 펌웨어의 3개의 unsound하고 incomplete한 UFG들은 다른 장치 관리 기능(e.g., 새로운 구성 적용)을 위해 의도된 reboot 함수 호출만 포함한다.
• 그럼에도 불구하고, 대부분의 잘못된 경로는 취약점 발견 프로세스에 영향을 미치지 않는데, 이는 비교적 불완전한 검증 절차를 포함하고 있고, 취약점 발견 과정에서 올바른 경로가 발견되는 한 걸러지기 때문
• 간과된 모든 올바른 경로들은 reboot 단계를 포함하고, 완전한 UFG들이 구축되기만 하면, 식별됨

6.2 Effectiveness of Procedure Recognition

• DG에서 이 모듈을 평가할 때, chkup은 평균 216.1초 내에서 각 펌웨어 이미지에 대해 검증 절차 식별(figure 4c)
• 검증 절차의 다른 카테고리 식별한 결과(figure 4b)
  - ![[Pasted image 20240126153801 1.png]]
  - 각 카테고리 내 8개 컬럼은 Netgear, TP-Link, D-Link, TRENDnet, Asus, Zyxel, Linksys, Ubiquiti의 펌웨어 이미지 결과를 나타냄
  - 461개 TP, 45개 FN, 17FP
  - 논문의 분석에 따르면, 일부 실행 경로에는 펌웨어 authenticity 확인 절차가 실제로 없기 때문에, 더 적은 authenticity 확인 절차가 인식된다.
• chkup은 가장 높은 integrity 검증 정확성을 가짐
  - 벤더들은 minor하거나 커스텀이 없는 MD5_Update같은 표준 함수들을 자주 사용하기 때문

False Result Discussion

• FP와 FN들은 주로 부정확한 실행 경로와 주요 함수의 잘못 식별때문에 발생함
• 논문의 분석에 따르면, 부정확한 실행 경로는 23개의 FN과 6개의 FP 발생
  - 검증 절차가 포함되지 않거나, 관련없는 코드가 검증 절차로 잘못 식별되기 때문
  - 예) 펌웨어 업데이트와는 다른, 장치 관리 functionality는 2개의 D-Link DAP 펌웨어 이미지의 UFG에 포함되어 있으며, authenticity 검증 절차로 잘못 인식됨
• 나머지 FN과 FP들은 주로 흔하지 않은 주요 함수를 사용하거나 실행경로 내 비슷한 semantic들을 가진 함수를 포함해서 발생함
• 6개 FN은 확인 절차의 식별을 안내하는 휴리스틱에서 벗어나는 것에서 발생함
  - 3개는 Zyxel NBG-series 이미지임
  - digest 계산 함수의 리턴 변수들과 인자들이 조건식으로 넘어가지 않기때문
  - 다른 3개는 Netgear R-series 이미지의 버전 파싱에서 유사한 이슈가 보임
• 더 분석한 결과
  - 이러한 이미지들은 유저 인터페이스에서 digest나 파싱된 펌웨어 버전을 나타내서 수동적인 검증이 필요함
• 일부 FN과 FP가 있더라도, 모듈은 대부분의 케이스에서 효과적임

6.3 Effectiveness of Vulnerability Validation

• 이 모듈 효과성 검증을 위해, DG에 대한 성공률을 평가하고 펌웨어 패치 결과를 분석하고, DL의 1,200개 추가적인 펌웨어 에서 scalability 측정함

Success Rate of Vulnerability Validation

• DG에서 Vulnerability Discovery 실행 후에, 총 271개 alert 발생
  - 119개는 DG의 에뮬레잇 가능한 72개 펌웨어 이미지에서 발생. 이는 Vulenrability Validation 모듈과 호환(compatible)됨
  - 90개: PoC를 수행하기 위한 테스트 환경 조성을 위한 패치 적용이 필요
  - 69개: 해당 펌웨어 이미지에 vulnerability validation 모듈을 적용하면, 패치된 펌웨어 이미지의 성공적인 생성 결과
  - 패치된 펌웨어 이미지를 만드는 데 장애물은 주로 최첨단 펌웨어 repacking 도구에 의해 지원되지 않는 흔하지 않은 파일 시스템의 사용을 포함한 다양한 펌웨어 구현에서 비롯됨
  - 이 repack된 펌웨어 이미지들을 에뮬레잇하고, 겨우 런타임 펌웨어 시그니처 확인의 위반으로 인한 10개의 실행 실패를 찾아냄
  - 88개: 패치된 펌웨어 이미지와 원본 펌웨어 이미지 모두에서 총 88개의 테스트 환경이 성공적으로 생성됨
• PoC 생성을 수행한 후, 73개의 PoC가 성공적으로 수행되었으며 해당 경보는 TP로 간주됨
• 실패 사례를 조사한 결과 6개는 실제로 FP이고 9개는 TP로 추정됨

Patching Result Analysis

• 실패한 PoC 생성은, alert이 FP이거나 펌웨어 패치 중에 발생하는 문제로 인해 발생할 수 있음
• chkup에서의 패치 생성은 세가지 단계
  1. 우회를 위한 검증 절차 식별
  2. 수정을 위한 코드 세그먼트 선택
  3. 패치된 펌웨어 적용
• 첫번째 단계의 식별이 부정확한 경우, 후속 패치는 프로그램 공간의 추가 탐색을 가능하게 하지 않을 수 있으며, 이는 FN으로 이어질 수 있음
  - 실패한 15개 PoC 케이스 중에서, 9개는 이런 문제로 발생함
  - 최근 프로토타입에서는 구현되지 않았지만, 프로그램 실행을 모니터링하여 알려진 올바른 펌웨어와 잘못된 실행 펌웨어를 구별함으로써 이 문제를 완화할 수 있음
• 정확한 검증 절차가 확인되더라도 잘못된 코드 위치에서 논리를 휴리스틱적으로 부정하는 것과 같은 문제가 발생할 수 있음
  - 이는 misidentification의 문제와 마찬가지로 해결할 수 있음
  - 그러나 알려진 펌웨어 유형에 대해 잘 작동하는 휴리스틱을 사용했기 때문에 이러한 경우는 발생하지 않았음
• 마지막으로, 패치된 펌웨어의 배포는 펌웨어 재패킹 및 에뮬레이션의 어려움으로 인해 항상 실행 가능한 것은 아님
• 이러한 과제에 대한 더 깊은 분석은 나중에 제공됨

Scalability of Vulnerability Validation

• 취약성 검증 모듈의 확장성은 펌웨어 이미지를 에뮬레이션하고 리패킹하는 기능과 밀접하게 관련되어 있음
• 이를 평가하기 위해 DL의 10%에 해당하는 1,200개의 펌웨어 이미지를 랜 샘플로 분석하였다.
• 초기 에뮬레이션 테스트에서 44.1%의 이미지가 성공적으로 에뮬레이션되었으며 따라서 이 모듈에 적용할 수 있음을 보여주었다.
• 특히 D-Link 펌웨어는 가장 높은 에뮬레이션 성공률을 보인 반면 Ubiquiti 펌웨어는 가장 낮은 에뮬레이션 성공률을 보였다.
• 에뮬레이트 가능한 이미지의 경우 72.2%의 리패킹 성공률을 달성
• SquashFS나 CramFS와 같이 일반적인 파일 시스템만큼 광범위하게 지원되지 않는 파일 시스템의 존재는 성공적인 재패킹을 방해하는 가장 중요한 요인이었다.
• 최종적으로 리패키지된 펌웨어 이미지 중 82.7%가 에뮬레이션에 성공하였다.
• 대부분의 실패의 주된 이유는 런타임 펌웨어 서명 검사였다.

Vulnerability Discovery Results

7.1 Alerts on Real-world Firmware

Alert Analysis

• ChkUp을 사용하여 DL의 잠재적인 취약성을 식별하고 경보 분포를 분석했다.
• 성능 면에서는 ChkUp이 펌웨어 이미지의 93.4%를 각각 600초 이내에 처리했다.
• UFG 구축 중 타임아웃은 펌웨어 이미지의 3.4%에서 관찰된 연장된 분석 시간에 기여하였다.
• ChkUp은 10,670개의 펌웨어 이미지에 대한 실행 경로를 해결하고 15,132개의 경고를 생성했다.
• 그림 5는 DL의 주요 장치 유형에 대한 취약 검증 유형별 경보 분포를 보여준다.
• 특히 경보의 상당 부분은 두 가지 주요 원인으로 인해 다양한 네트워크 장치(예: 라우터 및 스위치) 및 카메라의 펌웨어에서 발생한다
  - 1) 종종 공개적으로 접근 가능한 펌웨어 이미지를 갖는 네트워크 장치 및 카메라는 IoT 시장의 상당한 점유율을 차지한다(공개적인 펌웨어 이미지);
  - 2) 많은 장치들이 펌웨어 기반을 위해 취약한 코드를 재사용하고 효과적인 보안 향상이 부족하여 새로운 버전과 이전 버전 모두에 걸쳐 지속적인 취약점이 발생했다.(많은 디바이스에서 취약점 재사용)
• ChkUp에서 보고된 가장 일반적인 보안 문제는 취약한 무결성 검증 절차와 관련이 있음
• 예를 들어 네트워크 스위치 펌웨어에 대한 경고 중 절반 이상이 이 문제와 관련이 있음
• 이러한 경고는 대부분 CRC 및 MD5와 같은 취약한 알고리즘을 사용하는 것을 강조한다.
• 취약한 인증 확인은 또한 다양한 디바이스 유형, 특히 라우터를 위협한다
• 검증의 부재가 주된 우려이지만 대칭형 디지털 서명의 사용도 광범위하다.
• freshness 및 호환성 검증과 관련된 경보는 덜 일반적이지만 카메라 및 네트워크 확장기는 다른 장치보다 이러한 경보를 더 많이 표시한다.
• 가장 빈번한 문제는 펌웨어 업데이트 인터페이스에서 버전 또는 장치 ID를 확인하기 위해 파일 이름과 같은 보호되지 않은 데이터를 사용하는 것과 관련이 있다

Invalid and Outlier Result Discussion

• ChkUp의 결과에서 무효 사례는 주로 ChkUp이 실행 경로를 해결할 수 없는 1,330개의 펌웨어 이미지로 구성되었다
• 더 이상적인 경우는 4개의 경고를 발생시킨 589개의 펌웨어 이미지로, 대부분의 이미지가 일반적으로 최대 3개의 경고를 발생시켰기 때문에 흔하지 않았다.
• 우리는 임의의 10% 표본을 조사하여 이러한 결과를 더 깊이 조사했다.
• 우리는 실행 경로 복구에서 133건의 실패 사례에 대해 두 가지 주요 원인이 나타났음을 발견했다
  - 32.3%는 엔트리 프로그램의 오인식에서 비롯되었고, 29.3%는 UFG 건설 중 타임아웃에서 발생했다
  - 나머지 문제들은 주로 특이한 IPC 구현이나 특정 펌웨어 업데이트 단계에 사용되는 PHP와 같은 지원되지 않는 프로그래밍 언어 때문이었다.
• 올바른 UFG 구성에도 불구하고 슬라이싱 대상으로 재부팅 기능을 사용하면 경로 식별에 실패하는 경우를 발견하지 못했다.
• 또한 4개의 경보로 59개 펌웨어 이미지의 검증 절차를 점검하여 유효성을 확인하였다.
  - 이 중 39.0%는 안전하지 않은 업데이트 메커니즘을 가지고 있는 것으로 나타났고, 나머지 펌웨어에는 주로 잘못된 실행 경로와 검증 절차로 인해 발생하는 FP가 포함되어 있다.
• 중요한 것은 검증 절차를 잘못 파악한 핵심적인 이유는 펌웨어 이미지와 말뭉치 간의 기능 불일치 때문이었다.
• ChkUp이 간과한 대부분의 절차는 가치 대 조건 휴리스틱을 준수하지만 일부는 그렇지 않다.
• 우리가 진짜로 확인한 이러한 이상치에 대해, 우리는 휴리스틱 매칭에서 제외하고 예외를 제공했다.

7.2 Real-world Vulnerabilities

• 경고를 확인하는 것은 시간이 많이 걸리고 노동 집약적이므로 DG에서 가져온 150개의 펌웨어 이미지에 중점을 두었다
• 우리는 에뮬레이트 가능한 펌웨어를 위해 취약성 검증 모듈을 사용했고 나머지 부분은 우리의 근거 자료로 수동으로 검증했다.
• FN을 파악하기 위해 모든 펌웨어 이미지를 ground truth를 이용하여 평가하였다. 그 결과는 Table 3과 같다.
• 전체적으로 TPR은 86.7%, FPR은 5.3%로 ChkUp이 취약성 탐지에 효과가 있음을 보여준다.
• 대부분의 FP와 FN은 우리가 평가에서 논의한 바와 같이 실행 경로 복구 및 검증 절차 인식 모듈에서 발생했다.
• Asus 펌웨어 이미지에 대한 TP는 n-day 취약점(즉, CVE-2014-2718, CVE-2020-15498 및 CVE-2021-3166)인 반면, 29개의 다른 디바이스 패밀리에 대한 TP는 공개되지 않았다.
• 우리는 또한 우리가 발견한 것을 공급업체에 보고하고 승인을 받았다. 작성 시점에 25개의 CVE ID와 1개의 PSV ID가 할당되었다.
• 주목할 점은 대다수가 CWE-345와 CWE-20의 범주에 속한다는 것이다. 이러한 결과는 우리의 체계화와 일치하며, 이 두 범주가 가장 일반적이라는 것을 나타낸다. CVE/PSV에 대한 자세한 내용은 우리 프로젝트 웹사이트에서 확인할 수 있다

Vulnerability Analysis

• 취약점 유형과 관련해서는 부적절한 무결성 검증이 39.0%가 CRC, 23.8%가 MD5를 사용하는 것으로 나타나 가장 빈번한 이슈로 나타났다.
• 누락되거나 부적절한 인증 확인 문제가 만연해 있다
• 예를 들어, TP-Link WR-시리즈 장치로부터의 펌웨어에서, 펌웨어 업데이트에서 인증 확인을 위한 RSA 서명이 존재하지만, 서명은 펌웨어 헤더를 보호하지 않는다.
• 더욱이, MD5 합 값도 헤더에 저장된다.
• 따라서, 공격자는 검증을 우회할 수 있는 악성 펌웨어 이미지를 만들기 위해 헤더 내용을 수정하고 해시 값을 재계산하여 원본을 대체할 수 있다.
• 또한 신선도와 호환성에서 취약성이 덜 확인되었으며, 대부분 보호되지 않은 정보의 사용에 뿌리를 두고 있다.
• 예를 들어, D-Link DAP-시리즈 장치의 펌웨어 버전 검증은 새로운 펌웨어 이미지의 파일명으로부터 버전을 추출하여 현재 버전과 비교하는 것이다
• 파일 이름에 진정성과 무결성 보호가 없기 때문에 공격자는 파일 이름을 변경하여 검증을 우회하고 장치에 취약한 펌웨어 이미지를 도입할 수 있다.

7.3 Case Studies

목록 3은 Netgear WNR 시리즈 라우터의 펌웨어 이미지 내 펌웨어 검증 흐름을 보여준다. 이 장치들은 수동 펌웨어 업데이트를 위한 웹 인터페이스를 제공한다. upgrade.js의 3번 라인부터 10번 라인까지 인터페이스 전단에서는 이미 취약한 것으로 식별한 방법인 업로드된 파일의 파일 이름을 검사하여 호환성과 새로움을 모두 검증한다. 이러한 검증을 통과한 후, 백엔드 셸 스크립트 webupgrade.sh 은 추가 검증을 진행한다. webupgrade.sh 의 2번 라인부터 6번 라인까지 펌웨어 헤더를 검사하여 호환성을 확인한다. 따라서 펌웨어 무결성이 보장되는 한 호환성은 보장될 수 있다. webupgrade.sh 에서는 이진 mychecksum을 통해 무결성 검증이 수행된다. 검사 시 mychecksum은 이 검증을 위해 약한 CRC 알고리즘을 사용한다. 특히 인증 검증은 없다. 결과적으로 이러한 취약한 검증 절차는 펌웨어 업데이트 메커니즘을 실제 악용에 취약하게 만든다.
실제 악용. 저희는 Netgear WNR 시리즈 라우터를 대상으로 펌웨어 다운그레이드 공격과 펌웨어 수정 공격의 두 가지 악용 가능성을 보여줍니다. 이러한 공격 시나리오에서는 공격자와 대상 장치가 동일한 네트워크 환경을 공유합니다. 펌웨어 제공을 위한 통신에 암호화되지 않은 HTTP가 사용된다는 점을 감안할 때, 공격자는 펌웨어 업데이트 인터페이스에 직접 액세스하거나 네트워크를 스니핑하여 MITM 공격을 시작할 수 있습니다. 특히 예비 수동 펌웨어 분석에서 상당수의 공개 펌웨어 이미지에 업데이트 인터페이스에 대한 TLS가 부족하다는 것을 발견하여 실제 환경에서 이러한 공격의 실현 가능성을 강조했습니다.
A1. 펌웨어 다운그레이드 공격: 업로드된 파일의 파일명을 확인하여 펌웨어의 신선도를 결정하기 때문에 공격자는 파일명에 있는 버전 필드를 합법적인 펌웨어에 맞게 변경하여 기존 펌웨어 이미지를 사용하여 악성 펌웨어 이미지를 만들 수 있다. 그런 다음 웹 인터페이스를 통해 악성 펌웨어 이미지를 업로드하거나 MITM을 통해 양성 펌웨어 이미지를 대체할 수 있다. 이후 펌웨어는 취약점이 있는 안전하지 않은 기존 버전으로 대체되어 더욱 악용될 수 있다.
A2. 펌웨어 수정 공격: 펌웨어 무결성 검증이 CRC 체크섬을 기반으로 하므로 공격자는 체크섬 값을 일관되게 유지하면서 수정된 펌웨어 이미지를 생성할 수 있습니다. 그러나 호환성 검증을 위한 헤더의 디바이스 ID와 같은 일부 필드는 다른 검증 절차가 성공적으로 진행되도록 변경되지 않은 상태로 유지되어야 합니다. 공격자는 펌웨어 하향 등급 공격에서 언급된 것과 동일한 방식으로 디바이스에 악성 펌웨어를 도입할 수 있습니다. 이 공격을 통해 악성 펌웨어를 신중하게 조작하면 백도어, 멀웨어 및 DoS 공격을 포함한 다양한 추가 공격이 도입될 수 있습니다.
![[Pasted image 20240130194429.png]]

Real-world Exploits

• Netgear WNR 시리즈 라우터를 대상으로 펌웨어 다운그레이드 공격과 펌웨어 수정 공격이라는 두 가지 이점을 만들어 이러한 취약성의 악용 가능성을 보여준다.
• 이러한 공격 시나리오에서 공격자와 타겟 디바이스는 모두 동일한 네트워크 환경을 공유한다.
• 펌웨어 제공을 위한 통신이 암호화되지 않은 HTTP를 사용한다는 점을 고려할 때, 공격자는 펌웨어 업데이트 인터페이스에 직접 액세스하거나 네트워크를 스니핑하여 MITM 공격을 시작할 수 있다.
• 특히, 예비 수동 펌웨어 분석 중 상당수의 공개 펌웨어 이미지에 업데이트 인터페이스용 TLS가 부족하다는 것을 발견하여 실제 환경에서 이러한 공격의 가능성을 강조했다.

A1. Firmware Downgrade Attack:

• 펌웨어 신선도는 업로드된 파일의 파일명을 확인하여 결정되므로, 공격자는 파일명 내의 버전 필드를 합법적인 것과 일치하도록 변경하여 레거시 펌웨어 이미지를 이용하여 악성 펌웨어 이미지를 만들 수 있다.
• 그런 다음 웹 인터페이스를 통해 악성 펌웨어 이미지를 업로드하거나 MITM을 통해 양성 펌웨어 이미지를 대체할 수 있다. 이후 펌웨어는 취약점이 있는 안전하지 않은 레거시 버전으로 대체되며, 이는 더욱 악용될 수 있다.

A2. Firmware Modification Attack:

• 펌웨어 무결성 검증은 CRC 체크섬을 기반으로 하므로 공격자는 체크섬 값을 일관되게 유지하면서 수정된 펌웨어 이미지를 생성할 수 있다.
• 그러나 호환성 검증을 위한 헤더의 장치 ID와 같은 일부 필드는 다른 검증 절차가 성공적으로 진행되도록 하기 위해 변경되지 않은 채로 유지될 필요가 있다.
• 공격자는 펌웨어 다운그레이드 공격에서 언급된 것과 동일한 방식으로 악성 펌웨어를 디바이스에 도입할 수 있다.
• 이번 공격으로 악성 펌웨어가 치밀하게 조작되면 백도어, 멀웨어, DoS 공격 등 다양한 추가 공격이 도입될 수 있다.

Discussion

Security Impacts of Heuristics

• 휴리스틱 접근법은 수동 역공학을 통해 발견된 공통 패턴을 포착한다
• 유사한 패턴을 갖는 펌웨어 이미지에는 효과적이지만, 상이한 시스템에 걸쳐 일반화될 수 있는 근본적인 문제를 포착할 수 없다.
• ChkUp의 맥락에서 펌웨어 업데이트 경로의 진입과 종료를 휴리스틱하게 식별하려는 우리의 접근 방식은 맞춤형 펌웨어에서 실패하여 분석이 시작되지 않을 수 있다.
• 또한, 암호 함수로부터의 정보 흐름을 이용하여 업데이트 단계를 식별하는 우리의 휴리스틱 접근법은 정확한 업데이트 단계 코드를 추출하는 데 실패할 수 있다.
• 평가 결과, 그러한 휴리스틱은 파격적인 디자인에서 실패할 수 있음을 발견했다.

Limitations of Static and Dynamic Analysis

• 정적 분석과 동적 분석 사이에는 상충 관계가 존재한다.
• 그러나 적절하게 조합하여 사용할 경우 분석의 완성도와 건전성 사이에서 좋은 균형을 제공한다.
• ChkUp의 맥락에서 정적 분석의 핵심적인 장점은 펌웨어를 에뮬레이션할 필요가 없다는 점이며, 이는 여전히 공개된 연구 과제로 남아 있다.
• 예를 들어, DG에서 150개의 펌웨어 이미지 중 72개만이 최첨단 펌웨어 에뮬레이터를 사용하여 에뮬레이션 가능하다.
• 베어 메탈 펌웨어의 경우 에뮬레이션 속도가 더 낮다.
• 정적 분석의 또 다른 장점은 버그에 도달하기 위한 입력을 만드는 것이 매우 어려운 더 깊은 버그를 감지하는 능력이다.
• 예를 들어 39개의 펌웨어 이미지는 버그 확인 절차를 진행하기 전에 암호 서명을 확인한다.
• 그러나 정적 분석은 종종 많은 잘못된 경보를 발생시킨다.
• 이를 완화하기 위해 ChkUp은 동적 분석을 활용하여 기본적이지만 검증 수준을 제공하려고 시도한다.
• 에뮬레이션의 문제 외에도 동적 분석은 한 번에 하나의 경로에 대한 검증만 허용하여 탐색의 폭을 제한한다.
• ChkUp의 경우 성공 여부는 패치 적용이 올바르게 수행되는지 여부에 달려 있지만, 논의된 바와 같이 항상 그렇지는 않다.

Extensibility of ChkUp

• 펌웨어 업데이트 취약성 외에도, 우리의 기술은 결함 있는 펌웨어 기능 구현(예를 들어, 암호화 기능)과 같은 취약성을 감지할 수 있다.
• 말뭉치에 잘못된 기능 서명을 추가함으로써 올바르게 구현된 대응물이 있더라도 취약한 기능이 더 높은 유사도 점수를 기반으로 해당 서명과 일치하도록 하여 결함 있는 구현의 사용을 정확하게 파악할 수 있다.
• ChkUp은 파일 시스템을 갖춘 멀티 아키텍처 Linux 및 기타 내장 OS 펌웨어에 맞게 조정되었다
• 베어 메탈 펌웨어 분석은 기본 해상도를 해결하는 것과 같은 어려움을 가지고 있지만, 대부분은 언어 간 제어/데이터 흐름 분석을 필요로 하지 않는다.
• ChkUp은 FirmXray[77]의 방법을 통합하고 코퍼스를 업데이트함으로써 베어 메탈 펌웨어도 처리할 수 있었다.
• 우리의 기술은 벤더별 기술이 아니다. ChkUp이 펌웨어 유형을 지원하면 분석할 수 있다.
• FP가 발생할 수 있지만 시스템은 펌웨어 업데이트 경로와 같은 통찰력을 제공할 수 있다.
• 말뭉치를 확장하면 ChkUp의 정확도를 더욱 향상시킬 수 있다

Related Work

Firmware Update Security

• 최근 연구에 따르면 펌웨어 또는 소프트웨어 업데이트 메커니즘의 보안 문제가 밝혀졌다[15, 17, 21, 57, 63, 70]
• 특히, HTTP와 같은 비보안 프로토콜의 보편적인 사용은 업데이트 프로세스를 MITM 및 백도어 공격에 노출시킬 수 있다[17, 63].
• 또한, 업데이트 절차의 취약점을 이용하여 입증된 펌웨어 수정 공격이 있다[21, 70].
• 학계와 인터넷 공학 태스크 포스(IETF)는 안전한 펌웨어 업데이트 전략을 개발하고 효율적인 핫패칭 솔루션을 개발함으로써 이러한 우려를 해결하고 있다[46, 53]

Vulnerability Detection in Firmware

• 펌웨어 취약성 탐지는 크게 세 가지 범주로 나뉜다
• 첫 번째 그룹[37, 40, 68, 77, 82, 87]은 사양과 실제 구현 간의 불일치를 식별하여 취약점을 감지한다.
  - 예를 들어, FirmXRAY[77]는 사양 지식을 사용하여 블루투스 계층 취약성을 밝혀낸다.
• 두 번째 범주는 취약한 실행 경로를 탐색하기 위해 얼룩 분석[19, 27, 59, 83, 85]과 기호 실행[25, 32, 34, 36, 65]과 같은 방법을 사용한다.
  - 예를 들어, Karonte[59]는 사용자가 제어하는 안전하지 않은 입력 싱크를 정확하게 파악하여 메모리 손상 취약성을 목표로 한다
• 세 번째 범주는 패턴 매칭[20, 38, 44, 81]과 코드 유사성 검사[23, 24, 28, 33, 39, 41, 49, 50, 64, 75, 79, 88]를 포함하며, 절차 유사성을 사용하는 FirmUP[24]와 같이 알려진 패턴 또는 취약한 코드를 매칭하여 취약점을 탐지한다.
• 우리의 연구는 특히 여러 단계의 특성과 펌웨어 업데이트의 고유한 의미론으로 인해 구별되는 펌웨어 업데이트 취약성을 대상으로 한다

Cryptographic Misuse Detection

• 암호 API 오용 탐지는 암호 프리미티브의 잘못된 사용으로 인해 발생할 수 있는 잠재적인 취약성을 식별하기 위한 기술이다[16].
• 일반적인 아이디어는 암호 API로 전달되는 파라미터가 미리 정의된 규칙을 충족하는지 확인하는 것이다[26, 29, 31, 45, 56, 58, 67, 85].
• ChkUp은 시스템 목표, 보안 영향 및 기술적 관점에서 기존의 암호 오용 탐지 연구와 차이가 있다.
• 보안 목표와 관련하여 ChkUp은 펌웨어 업데이트 보안에 초점을 맞추어 근본적으로 뚜렷한 초점을 제공한다.
• 우리의 접근 방식은 개별 암호화 취약점을 분석하는 대신 펌웨어 업데이트 생태계를 체계화하고 보안 분석을 수행하여 공격 표면을 매핑하여 상당한 양의 비암호화 공격 벡터를 밝혀내는 것이다.
• ChkUp은 보안 영향의 관점에서 펌웨어 업데이트 취약점에 대한 검색을 자동화할 수 있는 새로운 방법을 제공하며, 암호 오용과 다운그레이드 공격과 같은 비암호 관련 취약점을 모두 포괄한다.
• ChkUp은 기술적 관점에서 프로세스 간 호출의 긴 시퀀스를 식별하고 펌웨어 업데이트별 의미 버그를 발견하고 검증하는 것을 포함하여 새로운 과제를 해결한다.

Conclusion

• 본 논문에서는 업데이트 중 누락 및 부적절한 검증을 포함하여 펌웨어 업데이트 취약성을 탐지하기 위한 새로운 접근법인 ChkUp을 제시한다.
• 구체적으로 ChkUp은 크로스 언어간 프로세스 제어 흐름 분석 및 프로그램 슬라이싱을 통해 펌웨어 업데이트 실행 경로를 해결한다.
• 그런 다음 구문론, 구조론, 의미론적 프로그램 분석을 통해 펌웨어 검증 절차를 파악한다.
• 해당 실행 경로와 함께 이러한 절차는 취약점을 탐지하기 위해 정의된 기준에 따라 추가로 검사된다.
• 잘못된 긍정을 줄이기 위해 에뮬레이트 가능한 펌웨어 이미지에 대한 경고는 패치 기반 방법으로 동적으로 검증되는 반면 다른 것들은 수동으로 검증된다.
• ChkUp은 12,000개의 펌웨어 이미지를 분석하기 위해 구현되고 사용되며, 이후 33개의 디바이스 패밀리의 150개의 펌웨어 이미지에 대한 경고를 검증한다.
• 결과는 ChkUp이 0일 및 n일 취약성을 식별할 수 있으며, 이로 인해 25개의 CVE ID와 1개의 PSV ID가 할당됨을 보여준다.