차량 Penetration Test는 왜 일반 IT 해킹과 다를까?— 자동차 보안 테스트가 어려운 진짜 이유

차량 사이버보안 테스트·검증 시리즈

시리즈 전체 구성

1

이전 글

자동차 보안 테스트는 실제로 무엇을 할까?

ISO/SAE 21434 Clause 11 · 4가지 검증 유형 · 테스트 전체 구조

DONE

2

2편 · 지금 읽는 글

차량 Penetration Test는 왜 일반 IT 해킹과 다를까?

공격면 · CAN·UDS·Firmware · 물리 공격 · 차량 특화 방법론

NOW

3

3편 · 예정

차량 보안 테스트는 왜 완벽할 수 없을까?

Residual Risk · 현실적 한계 · PSIRT와 지속 운영

SOON

차량 보안 이야기를 하면 이런 말을 자주 듣습니다.

실제로 자주 나오는 말들

"차량 PenTest도 결국 해킹 아닌가요?"

"웹 모의해킹처럼 하면 되는 거 아닌가요?"

"CAN 패킷 좀 보내보면 끝 아닌가요?"

"차량 해킹은 그냥 OBD 꽂는 거 아닌가요?"

실제 차량 PenTest를 해보면 이 생각들이 금방 깨집니다. 구조가 다르고, 공격면이 다르고, 무엇보다 실패했을 때의 결과가 다릅니다.

차량은 단순한 소프트웨어 시스템이 아닙니다.

실시간 네트워크, 물리 ECU, Safety 시스템,
그리고 실제로 움직이는 하드웨어가 모두 연결되어 있습니다.

차량 PenTest는 "서비스 침투"보다
"차량 시스템 전체를 이해하는 과정"에 가깝습니다.

---

구조 자체가 다르다 — IT vs 차량

일반 IT PenTest	차량 PenTest
서버·웹앱·API 중심	ECU + 차량 네트워크 중심
TCP/IP 기반 통신	CAN·LIN·FlexRay·Ethernet 혼재
서비스 장애·데이터 탈취 영향	조향·제동·파워트레인 제어 영향 가능
소프트웨어 공격 중심	물리 PCB 접근 + 펌웨어 공격 포함
취약점 발견 후 빠른 패치	양산 이후 수정 비용·공수 매우 큼
테스트 환경 구성 비교적 쉬움	실차·전체 네트워크 없으면 재현 안 되는 경우 많음

⚠️ 가장 중요한 차이:
IT에서 취약점이 뚫리면 서비스 장애나 데이터 유출입니다. 차량에서는 브레이크·조향·파워트레인에 영향을 줄 수 있습니다. 그래서 테스트 자체도 통제된 환경에서, 사전에 범위와 절차를 명확히 정의하고 수행해야 합니다.

---

차량의 공격면은 생각보다 훨씬 넓다

많은 사람들이 차량 해킹 = OBD 포트 연결 정도로 생각합니다. 하지만 현대 차량의 공격면은 훨씬 광범위합니다.

📡 Telematics / OTA

LTE·Wi-Fi·Bluetooth 기반 원격 공격 가능. OTA 서버 탈취 시 차량 전체 영향

원격 공격 가능

🔌 OBD / Diagnostic

UDS Abuse, Security Access 우회, 권한 없는 Flash 시도

물리 접근 필요

📱 Mobile App / Backend

Cloud API 취약점, 인증 토큰 탈취, 원격 제어 기능 악용

원격 공격 가능

🧠 ECU Firmware

Reverse Engineering, 하드코딩 키 추출, Secure Boot 우회 시도

물리 접근 필요

🛠️ Debug Interface

JTAG·SWD·UART 통한 내부 접근, Flash Dump, 메모리 변조

물리 접근 필요

🚘 In-Vehicle Network

CAN Injection, Spoofing, Replay Attack, DoS 공격

내부 접근 필요

SDV 시대에는 공격면이 더 넓어졌습니다.
Cloud·App·OTA·Linux·Container·API까지 연결되면서 이제는 차량 자체보다 "차량 생태계 전체"가 공격면이 되고 있습니다.

---

차량 PenTest에서 실제로 수행하는 공격들

UN R155 Annex 5와 KISA 매뉴얼 기반으로 실제 차량 PenTest에서 다루는 주요 공격 유형입니다.

1. CAN Injection — 네트워크 레이어 공격

차량 내부 CAN 버스에 가짜 메시지를 주입합니다. 예전 차량은 메시지 인증이 없어 "누가 보냈는지" 확인하지 못했습니다.

CAN Injection 공격 흐름

CAN 버스
물리 접근

→

정상 메시지
ID·페이로드 분석

→

가짜 CAN
메시지 전송

→

ECU가 정상
메시지로 처리

→

차량 기능
오동작

→ SecOC 미적용 차량: 메시지 출처 검증 불가. 그래서 최근 CAN/SecOC 적용이 중요해졌습니다.

2. UDS Abuse — 진단 레이어 공격

진단 기능 자체를 악용합니다. UDS는 원래 정비·개발용이지만 Security Access 우회, 세션 Abuse가 가능하면 공격 경로가 됩니다.

실제 PenTest에서 UDS 관련 주요 점검 항목:

Seed 값 중복 여부 (TRNG 미사용 시 취약) / Security Access Retry 제한 확인 / 세션별 서비스 권한 분리 여부 / Unauthorized Flash 가능 여부 / 인증 없이 접근 가능한 위험 서비스 식별

3. Secure Boot 우회 시도 — 부팅 레이어 공격

Firmware 서명 검증 체계를 우회하는 공격입니다.

Secure Boot 우회 시도 흐름

Debug Interface
(JTAG 등) 접근

→

Flash Dump
획득

→

Public Key
위치 분석

→

Firmware
변조 시도

→

Boot 검증
우회 확인

→ HSM·Immutable Bootloader·Secure Debug 적용 여부가 이 공격의 성패를 가릅니다.

4. Fuzzing — 입력값 레이어 공격

비정상적인 입력을 자동으로 생성해서 시스템 오동작·충돌·취약점을 찾습니다.

📶

CAN·UDS Fuzzing

비정상 길이·ID·페이로드로 ECU 오동작 여부 확인. DoS 유발 시나리오 포함

CANalyzer Defensics AFL++

🌐

Automotive Ethernet Fuzzing

SOME/IP·DoIP 비정상 메시지, Flooding 공격, 페이로드 길이 불일치

Wireshark Scapy Vector CANoe

📡

외부 인터페이스 Fuzzing

Bluetooth L2CAP, USB Descriptor, 미디어 파일 파싱 취약점 확인

Btlejuice USB Fuzzer

5. 물리 PCB 공격 — 하드웨어 레이어 공격

이건 일반 IT PenTest에는 없는 차량만의 영역입니다.

✅ 차량 PenTest에서만 볼 수 있는 공격:

PCB 탐침(Probing)으로 Flash 신호 캡처 → 펌웨어 추출 / JTAG·SWD 포트 발견 → Debug 인터페이스 접근 / Logic Analyzer로 SPI·I2C 통신 분석 / 에폭시 제거 후 내부 회로 접근

그래서 OEM 요구사항에는 "PCB는 BGA·에폭시 처리로 프로빙 불가하게 설계해야 한다", "실크 표식 제거" 같은 물리 보안 요구사항이 들어갑니다.

---

차량 PenTest가 어려운 진짜 이유

현업에서 실제로 힘든 것들

실차 조건이 맞아야 동작하는 기능이 있다 — IGN 상태, Wake-up 조건, Gateway Routing 등 특정 조건에서만 활성화되는 기능이 있습니다. 벤치에서는 재현 안 되는 경우가 많습니다.

ECU 하나만으로 테스트가 안 되는 경우가 많다 — SecOC 검증, Gateway Routing, 인증 흐름이 여러 ECU에 걸쳐 있어 전체 네트워크가 있어야 하는 경우가 있습니다.

Safety 영향을 고려해야 한다 — 실차에서 조향·제동 관련 ECU를 공격하면 실제 위험이 생길 수 있습니다. 통제된 환경, 명확한 중단 조건, 복구 절차가 사전에 정의되어야 합니다.

양산 Firmware로 테스트해야 한다 — 개발 버전은 Debug 옵션이 열려 있고 Secure Boot가 비활성화된 경우가 있습니다. 반드시 양산 버전 설정과 동일한 상태로 최종 검증해야 합니다.

---

그래서 차량 PenTest는 두 가지를 동시에 요구한다

💻 일반 PenTest 역량

• 네트워크 공격 기법
• Fuzzing·취약점 분석
• 역공학(Reverse Engineering)
• 암호화 분석
• API·웹 보안

🚗 차량 도메인 이해

• CAN·LIN·Ethernet 구조
• UDS 진단 프로토콜
• ECU 부팅 과정
• OTA·Secure Boot 구조
• E/E Architecture
• Safety 개념 (ISO 26262)

차량 도메인 지식 없이 CAN 패킷을 아무리 잘 분석해도, 어떤 메시지가 어떤 ECU에서 어떤 역할을 하는지 모르면 공격 시나리오 자체를 만들 수 없습니다.

---

SDV 시대 — 이제 End-to-End 검증이 필요하다

예전 차량은 ECU 중심이었습니다. SDV 시대에는 전체 체인이 연결됩니다.

SDV 차량 보안 테스트 대상 범위

Cloud
Backend

↔

OTA
Server

↔

Mobile
App

↔

Vehicle
OS/Linux

↔

Domain
Controller

↔

ECU
Network

이제 차량 PenTest는 ECU 단품을 넘어 Cloud에서 ECU까지 이어지는 End-to-End 검증으로 확장되고 있습니다.

---

마무리

차량 Penetration Test는
"취약점 찾기 기술"보다,
"차량 시스템 전체를 얼마나 이해하고 있는가"에 더 가까운 영역입니다.

그래서 차량 PenTest는 해킹 기술 + 차량 도메인 이해가 동시에 필요합니다.

NEXT — 3편 예고

차량 보안 테스트는 왜 완벽할 수 없을까?

아무리 잘 테스트해도 모든 취약점을 찾을 수는 없습니다. Residual Risk를 어떻게 다루고, PSIRT와 지속 모니터링으로 어떻게 이어가는지 이야기합니다.

Residual Risk Risk Acceptance PSIRT 지속 모니터링 양산 후 보안 운영

핵심 요약

1

차량 PenTest는 구조·목적·위험이 일반 IT와 다르다 — 취약점이 Safety 문제로 이어질 수 있습니다

2

공격면이 OBD 하나가 아니다 — OTA·진단·App·Firmware·Debug·내부 네트워크 전체가 대상입니다

3

물리 PCB 공격은 차량만의 영역 — JTAG·Probing·Logic Analyzer는 일반 PenTest에 없는 기법입니다

4

해킹 기술 + 차량 도메인 이해 둘 다 필요 — 도메인 지식 없이는 공격 시나리오 자체를 만들 수 없습니다

5

SDV 시대에는 Cloud부터 ECU까지 End-to-End 검증이 필요 — ECU 단품만 보는 시대는 끝나가고 있습니다

차량PenTest 자동차보안테스트 CANInjection UDS보안 SecureBoot Fuzzing 차량사이버보안 PCB보안 ISO21434 SDV