차량 모의해킹(Penetration Test)는 실제로 뭘 할까?

차량 보안 기술

TARA에서 위협을 분석하고, 보안 기능을 구현하고, V&V로 검증했습니다.
그런데 개발팀이 스스로 만든 것을 스스로 검증하면 한계가 있습니다.

그래서 등장하는 것이 Penetration Test(모의해킹)입니다.
실제 공격자처럼 생각하고, 실제 공격 기법으로 차량을 공격해보는 것입니다.

"차량 Pentest가 뭔지는 알겠는데, 실제로 어떻게 진행되는 건가요?"
현장에서 자주 받는 질문입니다.
오늘은 개념부터 현업 현실까지 풀어봅니다.

차량 Penetration Test란 무엇인가

Penetration Test(침투 테스트, 모의해킹)는 허가된 보안 전문가가 실제 공격 기법을 사용해 시스템의 취약점을 찾아내는 활동입니다. "방어가 잘 됐는지 확인하는 V&V"와 달리, "실제 공격자라면 어떻게 뚫을 수 있는지"를 검증합니다.

차량 Pentest는 IT 시스템 Pentest와 다른 점이 있습니다. 단순히 소프트웨어 취약점을 찾는 것을 넘어, CAN 버스 메시지 조작·물리적 포트 공격·OTA 채널 위변조·하드웨어 칩 분석까지 포함합니다.

구분	IT 시스템 Pentest	차량 Pentest
공격 대상	웹·서버·네트워크·앱	ECU·CAN 버스·OBD-II·OTA·V2X·인포테인먼트
필요 장비	노트북, 네트워크 장비	차량 실물 또는 HIL, CAN 분석기, 오실로스코프, 납땜 장비
공격 경로	주로 네트워크	물리(OBD·JTAG)·무선(BT·Wi-Fi·LTE)·CAN·OTA 복합
기능 안전 고려	불필요	필수 — 브레이크·조향 ECU 공격 시 실제 차량 위험
테스트 환경	스테이징 서버로 가능	실제 차량 또는 HIL/SIL 환경 필요
규제 연계	ISO 27001 등	ISO 21434, R155 VTA 증거로 제출

차량 Pentest가 일반 IT Pentest보다 어려운 가장 큰 이유는 기능 안전입니다. 웹 서버를 다운시키는 공격은 IT에서 비교적 안전하게 테스트할 수 있지만, 차량 브레이크 ECU를 공격하는 테스트는 실제 차량이나 이를 충분히 재현하는 테스트 환경이 필요합니다. 그래서 차량 Pentest는 HIL(Hardware-in-the-Loop) 환경에서 진행하는 경우가 많습니다.

차량 Pentest의 공격 표면

차량 Pentest에서 테스터가 바라보는 공격 표면은 크게 여섯 가지 영역입니다.

🔌 물리적 인터페이스

OBD-II 포트 — 진단 채널 직접 접근

JTAG/SWD — ECU 디버그 포트

UART/SPI/I2C — 보드 레벨 인터페이스

USB — 인포테인먼트 외부 입력

📡 무선 인터페이스

Bluetooth — 스마트폰 연동, BLE 공격

Wi-Fi — 소프트 AP, 중간자 공격

LTE/5G — 텔레매틱스 원격 공격

TPMS — 타이어 압력 센서 무선

🚌 내부 네트워크

CAN 버스 — 메시지 스니핑·주입·Fuzzing

CAN FD — 고속 CAN 공격

LIN — 저속 바디 네트워크

Ethernet — 최신 차량 내부망

🔄 OTA / 백엔드

OTA 채널 — 패키지 변조·중간자 공격

클라우드 API — 인증 우회·권한 탈취

원격 진단 — DoIP 보안

키 서버 — 인증서 관리 취약점

📱 모바일 앱 연동

스마트폰 앱 API — 인증·세션 관리

원격 잠금·시동 기능

앱 내 저장 데이터

앱-차량 간 BLE 통신

⚙️ ECU 펌웨어

펌웨어 덤프·리버싱

Secure Boot 우회 시도

Security Access 알고리즘 분석

HSM 부채널 공격

차량 Pentest는 어떻게 진행되는가 — 5단계

1

범위 정의 (Scoping)

무엇을 테스트할지, 어디까지 공격을 허용할지를 먼저 정합니다. 차량 전체를 한 번에 테스트하는 경우도 있지만, 특정 ECU·특정 기능·특정 공격 경로로 범위를 제한하는 경우가 더 많습니다. TARA 결과를 기반으로 높은 위험도의 위협 시나리오를 우선 선정합니다.

현업 포인트

범위를 제대로 정의하지 않으면 Pentest가 끝도 없이 늘어납니다. OEM과 Tier-1이 사전에 테스트 대상, 사용 장비, 허용 공격 기법, 일정을 문서로 합의해야 합니다. 이 문서가 나중에 VTA 증거로도 쓰입니다.

2

정보 수집 및 분석 (Reconnaissance)

공격자 관점에서 대상 시스템을 파악합니다. 차량 기술 문서, ECU 사양, 통신 프로토콜, 네트워크 구조를 분석합니다. CAN 버스에 연결해 메시지를 스니핑하거나, OBD-II로 지원 서비스 목록을 스캔하기도 합니다.

현업 포인트

화이트박스(내부 정보 제공), 그레이박스(일부 제공), 블랙박스(정보 없음) 방식으로 나뉩니다. VTA용 Pentest는 대부분 그레이박스로 진행합니다. 설계 문서를 제공하지 않으면 테스트 시간이 지나치게 길어지고, 다 제공하면 실제 공격자 시나리오와 멀어집니다.

3

취약점 분석 및 공격 (Exploitation)

실제 공격 기법을 사용해 취약점을 찾고 익스플로잇합니다. CAN 메시지 Fuzzing, Security Access 브루트 포스 시도, OTA 패키지 변조, Secure Boot 우회 시도, 펌웨어 덤프·리버싱 등이 포함됩니다. 취약점이 발견되면 실제 영향도를 확인하기 위해 추가 공격을 진행합니다.

현업 포인트

차량 Pentest에서 가장 어려운 단계입니다. 기능 안전 ECU(브레이크·조향)를 대상으로 공격할 때는 실차가 아닌 HIL 환경에서 진행해야 합니다. 공격 성공 시 차량이 비정상 동작할 수 있으므로 물리적 안전 장치도 필요합니다. 이 단계에서 테스터의 차량 도메인 지식이 결과 품질을 결정합니다.

4

보고서 작성 (Reporting)

발견된 취약점을 문서화합니다. 취약점 설명, 재현 절차, 영향도, 위험도(CVSS 또는 자체 기준), 권고 조치가 포함됩니다. VTA 제출용 보고서는 TARA 위협 시나리오와 매핑되어야 합니다. "어떤 위협 시나리오에서 예상한 취약점이 실제로 발견됐는가, 혹은 발견되지 않았는가"가 핵심입니다.

현업 포인트

보고서 형식이 OEM마다 다릅니다. 단순 취약점 목록이 아니라 TARA 추적성, 재현 환경, 공격 도구, 증거 스크린샷까지 요구하는 OEM도 있습니다. 처음부터 OEM이 요구하는 형식을 확인하지 않으면 보고서를 다시 써야 하는 상황이 생깁니다.

5

재테스트 (Retest)

발견된 취약점이 수정됐는지 확인합니다. 패치 후 동일한 공격이 더 이상 통하지 않는지, 패치 과정에서 새로운 취약점이 생기지 않았는지를 검증합니다. Retest 결과도 VTA 제출 증거에 포함됩니다.

현업 포인트

Retest 일정이 전체 Pentest 일정에서 빠지는 경우가 많습니다. 처음 Pentest 완료 후 "이제 끝"이라고 생각하다가 Retest가 VTA 일정에 포함된다는 걸 뒤늦게 알고 일정이 밀리는 상황이 생깁니다. Pentest 계획 단계에서 Retest 일정까지 미리 잡아둬야 합니다.

취약점이 발견되면 어떻게 처리하는가

취약점이 발견됐다고 모두 즉시 수정해야 하는 건 아닙니다. 각 취약점의 위험도와 수정 가능성을 평가해 처리 방향을 결정합니다.

취약점 발견 후 처리 흐름

취약점 발견

→

심각도·영향도 평가

→

처리 방향 결정

↓

수정 (Fix)
패치 후 Retest

또는

허용 (Accept)
근거 문서화 필수

또는

완화 (Mitigate)
보완 대책 추가

VTA 심사에서 자주 문제가 되는 것이 "허용(Accept)"한 취약점입니다. 취약점을 수정하지 않고 허용했다면 왜 허용했는지, 어떤 근거로 위험을 감수하기로 결정했는지를 TARA와 연결해서 문서화해야 합니다. 근거 없는 허용은 심사에서 반드시 지적됩니다.

TARA와 Pentest는 어떻게 연결되는가

Pentest는 TARA와 독립적인 활동이 아닙니다. TARA에서 "공격 가능성이 높고 영향도가 큰" 위협 시나리오를 Pentest의 우선 대상으로 삼아야 하고, Pentest 결과는 TARA의 가정이 맞았는지를 검증하는 역할을 합니다.

TARA에서 "공격자가 OBD-II를 통해 Security Access를 우회할 가능성 — Medium"으로 평가했다면, Pentest에서 실제로 그 공격을 시도해야 합니다. 공격이 성공했다면 TARA의 위험도 평가가 낮았던 것이고 재평가가 필요합니다. 공격이 실패했다면 보안 대책이 효과적임을 증명한 것입니다. 이 연결이 VTA 증거의 핵심입니다.

반대로 TARA에서 다루지 않은 취약점이 Pentest에서 발견되면 어떻게 될까요? 그것은 TARA의 범위나 깊이가 부족했다는 신호입니다. 발견된 취약점을 TARA에 추가하고 위험도를 재평가하는 과정이 필요합니다. TARA는 Pentest 이후에도 살아있는 문서여야 하는 이유입니다.

실제로 자주 발견되는 취약점들

차량 Pentest 현장에서 만나는 취약점은 생각보다 화려하지 않습니다. 대부분은 "기본 보안 기능이 빠져 있거나, 구현이 느슨한 경우"입니다. 엄청난 제로데이보다 이런 기초 결함이 훨씬 자주 발견됩니다.

취약점 유형	설명	관련 보안 기능
Default / Weak Seed-Key	단순하거나 알려진 알고리즘, 브루트 포스로 Key 계산 가능	Security Access
JTAG/SWD 열림	디버그 포트가 양산 ECU에서도 비활성화되지 않음. 메모리 덤프·키 추출 가능	Secure Boot, HSM
Secure Boot 미적용	서명 없는 펌웨어가 정상 실행됨. OTA로 악성 코드 설치 가능	Secure Boot
SecOC 미적용	CAN 메시지 인증 없음. 임의 메시지 주입으로 ECU 제어 가능	SecOC
Rate Limit 없음	연속 실패 잠금 없어 브루트 포스 가능. Security Access 무력화	Security Access
Replay 공격 허용	Freshness Counter 없어 정상 메시지를 캡처 후 재전송 가능	SecOC, Anti-Replay
Gateway 필터링 허점	인포테인먼트 → 파워트레인 도메인 메시지가 게이트웨이를 통과함	SGW, Domain Isolation

이 목록을 보면 공통점이 보입니다. 대부분 이 블로그에서 이미 다룬 보안 기술들이 빠져 있거나 제대로 구현되지 않은 경우입니다. Secure Boot, SecOC, HSM, SGW — 이것들이 제대로 있었다면 발견되지 않았을 취약점들입니다.

최근 OEM이 더 주목하는 것 — Exploit Chain

최근 OEM들은 단일 취약점 하나보다 여러 취약점이 연결되어 만들어지는 공격 체인(Exploit Chain)을 더 중요하게 봅니다. 개별 취약점은 심각도가 낮더라도, 연결하면 치명적인 공격 경로가 만들어질 수 있기 때문입니다.

Exploit Chain 예시 — 인포테인먼트에서 파워트레인까지

BLE 취약점
인포테인먼트 진입

→

SecOC 미적용
CAN 메시지 주입

→

Gateway 허점
파워트레인 도달

→

엔진 ECU 제어
Safety 영향

BLE 취약점 하나만 보면 "인포테인먼트 접근" 수준입니다. 하지만 SecOC가 없고 Gateway 필터링에 허점이 있다면, 그 BLE 취약점이 파워트레인 ECU 제어로 이어집니다. 이 연결을 찾아내는 것이 현재 차량 Pentest의 핵심 목표 중 하나입니다.

현업에서는 실제로 이렇게 경험한다

차량 Pentest 전문 인력이 부족하다 — IT 보안 전문가는 많지만, 차량 CAN 버스·ECU 구조·UDS 프로토콜·Secure Boot를 이해하면서 Pentest를 수행할 수 있는 인력은 드뭅니다. 차량 도메인 지식 없이 IT Pentest 방법론만 갖고 차량을 테스트하면 중요한 취약점을 놓치거나, 위험한 공격을 잘못 수행해 장비를 망가뜨리는 경우가 생깁니다.

HIL 환경 구축이 생각보다 크다 — 안전 관련 ECU를 포함한 Pentest를 실차 없이 하려면 HIL 환경이 필요합니다. HIL 구축 비용과 시간이 상당하고, 실제 차량 동작을 완전히 재현하기 어렵습니다. 그래서 초기 탐색적 테스트는 HIL로, 최종 확인은 실차로 하는 혼합 방식을 쓰는 경우가 많습니다.

Pentest 시점이 너무 늦는 경우가 많다 — 개발 완료 직전에 Pentest를 시작하면 취약점이 발견됐을 때 수정할 시간이 없습니다. 설계 단계의 아키텍처 리뷰(화이트박스)로 시작해서, 구현 단계에서 단위 테스트 수준 Pentest, 통합 단계에서 본격 Pentest를 하는 방식이 이상적입니다. Pentest를 "개발 완료 후 체크"가 아니라 "개발 과정의 일부"로 봐야 합니다.

Pentest 결과와 TARA 연결이 VTA에서 핵심이다 — OEM 심사에서 "이 취약점이 TARA의 어느 위협 시나리오와 연결되는가"를 묻습니다. Pentest 보고서와 TARA 문서가 서로 연결되지 않으면 증거 자료로서의 가치가 반감됩니다. Pentest 계획 단계부터 TARA 위협 시나리오 ID를 참조하는 방식으로 작성하는 게 좋습니다.

Fuzzing은 Pentest의 핵심 도구지만 노이즈가 많다 — CAN 버스 Fuzzing, UDS 서비스 Fuzzing은 차량 Pentest에서 자주 쓰이는 기법입니다. 하지만 무작위 입력을 대량으로 넣다 보면 ECU가 예상치 않게 리셋되거나, 의도치 않은 동작이 발생하는 경우가 있습니다. Fuzzing 수행 중 ECU 상태를 모니터링하고 비정상 동작을 기록하는 체계가 필요합니다.

마무리

Penetration Test는 "보안이 잘 됐는지 확인"이 아닙니다.
"실제 공격자라면 어떻게 뚫는지"를 먼저 찾아내는 것입니다.
그래야 방어를 강화할 수 있습니다.

차량 Pentest는 TARA에서 시작해서 Retest로 끝나는 연속된 활동입니다. 그 과정에서 발견되는 취약점은 위협이 아니라 개선의 기회입니다. 그리고 그 모든 과정이 문서로 남아야 VTA의 증거가 됩니다.

핵심 요약

• 차량 Pentest는 실제 공격 기법으로 취약점을 찾는 활동 — V&V와 다르다
• IT Pentest와 달리 물리·무선·CAN·OTA·모바일앱·펌웨어 복합 공격 표면을 다룬다
• 기능 안전 ECU 테스트는 HIL 환경 필수 — 실차 공격은 실제 위험 발생 가능
• 5단계: 범위 정의 → 정보 수집 → 취약점 공격 → 보고서 → 재테스트
• 발견된 취약점은 수정·허용·완화 중 선택 — 허용 시 반드시 근거 문서화
• 실제로는 제로데이보다 기본 보안 기능 미구현이 더 자주 발견된다 — Secure Boot·SecOC·Rate Limit 등
• 최근 OEM은 단일 취약점보다 여러 취약점이 연결된 Exploit Chain을 더 중요하게 본다
• Pentest 결과는 TARA와 연결되어야 VTA 증거로 의미가 있다
• Pentest는 개발 완료 후가 아니라 개발 과정 전반에 걸쳐 수행해야 한다
• TARA에서 다루지 않은 취약점 발견 시 TARA 재검토가 필요하다

차량Pentest 모의해킹 PenetrationTest 차량사이버보안 ISO21434 TARA ECU보안 CAN버스 Fuzzing VTA 차량보안기술 HIL