차량 관제 해킹, 에이전트 시대 API 보안의 경고

데이터 유출이 아니라 운행 통제의 문제다

보안 연구자 Eaton이 공개한 My Eicher 해킹 보고서는 VE Commercial Vehicles의 차량 관제 플랫폼에서 심각한 API 취약점이 발견됐다고 설명한다. 글에 따르면 숨겨진 내부 및 관리자 API가 인증 없이 노출됐고, 고객과 사용자, 차량, 문서, OTP 관련 데이터에 접근할 수 있었다. 연구자는 계정 탈취를 통해 한 사용자나 회사의 전체 차량 플릿을 통제할 수 있었다고 밝혔다. 원문은 2024년 발표 기준 27만5000대 차량과 11만5000명 고객이 등록됐다고 언급하면서, API에서 보인 숫자는 고객 74만8000명, 사용자 17만4000명, 차량 67만6000대 등으로 더 컸다고 덧붙인다.

이 사건은 단순한 웹 취약점이 아니다. My Eicher 소개 페이지는 상용차 고객을 위한 플릿 관리와 GPS 추적을 전면에 둔다. 차량 위치, 계기판, 지오펜스, 운행 정보가 API 뒤에 있다면 잘못된 인증 설계는 물리 세계의 운영 리스크가 된다. OWASP API Security Top 10이 반복해서 경고해 온 인증, 객체 권한, 민감 데이터 노출 문제가 그대로 드러난 사례다. CISA의 ICS 보안 권고 체계는 운영기술과 연결된 시스템의 취약점 관리가 일반 IT보다 더 무겁다는 사실을 상기시킨다.

에이전트가 붙으면 API 취약점은 더 빨리 악용된다

AI 에이전트는 API 문서를 읽고 호출 순서를 추론하는 데 강하다. 사람이 웹앱 자바스크립트를 뒤져 엔드포인트를 찾던 일을, 에이전트는 더 빠르게 반복할 수 있다. 이번 사례처럼 경로를 거슬러 올라갔을 때 API 목록이 드러나고, OTP 조회 엔드포인트까지 열려 있다면 자동화된 탐색은 위험을 크게 키운다. 에이전트 시대 API는 더 명시적이어야 한다는 좋은 API 계약을 말했지만, 보안 관점에서는 "명시성"과 "노출"을 혼동하지 않는 것이 핵심이다.

허깅페이스 침해, AI 보안평가의 새 경계선에서 다룬 것처럼 AI 보안은 모델이 공격할 수 있느냐의 문제가 아니라, 자동화된 공격 루프가 실제 시스템과 만나는 방식의 문제다. 차량 관제, 병원, 공장, 물류처럼 물리 시스템과 연결된 API는 특히 더 엄격해야 한다. AI가 방어자에게만 주어지는 도구라는 가정은 더 이상 통하지 않는다.

한국 모빌리티와 제조 기업의 체크리스트

국내에서도 차량 관제, 물류 배차, 장비 원격 모니터링, 공장 설비 관리가 SaaS로 이동하고 있다. 이런 시스템은 고객 포털과 모바일 앱을 갖고 있어 일반 웹 보안처럼 보이지만, 실제로는 운영기술 보안에 가깝다. 위치 정보와 운행 데이터는 개인정보와 영업비밀이고, 제어 명령은 안전 문제로 이어질 수 있다.

첫째, 모바일 앱 API를 공개 API처럼 다뤄야 한다. 앱 안에 숨겨진 엔드포인트는 숨겨진 것이 아니다. 둘째, OTP와 세션 토큰은 조회 가능한 리소스가 되어서는 안 된다. 셋째, 고객과 차량 단위의 객체 권한 검사를 모든 요청에서 수행해야 한다. 넷째, 대량 조회와 대량 명령은 사람 승인과 감사 로그를 남겨야 한다. 다섯째, 보안 연구자 신고 채널을 명확히 운영해야 한다. OpenVM 버그, AI 보안감사의 실전 경계선이 보여준 것처럼 취약점 발견 자체보다 빠른 접수와 수정 체계가 신뢰를 만든다.

AI 방어도 API 권한 모델 위에서만 작동한다

Microsoft와 여러 보안 기업은 에이전트형 취약점 탐지와 자동 패치를 내세운다. 그러나 방어 에이전트가 아무리 좋아도 기본 권한 모델이 무너지면 소용없다. API는 "누가 어떤 객체에 어떤 행위를 할 수 있는가"를 매번 확인해야 한다. 그 확인이 없다면 에이전트는 오히려 취약점의 탐색 속도를 높인다.

따라서 이번 사건의 교훈은 에이전트를 막자는 것이 아니다. 에이전트를 붙이기 전에 API를 에이전트가 악용해도 버틸 만큼 단단하게 만들자는 것이다. 내부 API와 관리자 API는 네트워크 경계, 인증, 권한, 로깅, 레이트 리밋이 함께 있어야 한다. AI 시대의 API 보안은 문서화와 자동화 친화성을 갖추되, 권한 경계는 더 작고 반복적으로 확인하는 방향으로 가야 한다.

자주 묻는 질문

Q1: 이 취약점은 AI 때문에 생긴 문제인가요?

A: 아니다. 전통적인 API 보안 실패다. 다만 AI 에이전트가 비슷한 취약점을 더 빠르게 찾고 조합할 수 있어 중요성이 커졌다.

Q2: 가장 심각한 부분은 무엇인가요?

A: 인증 없는 내부 API와 OTP 조회가 결합돼 계정 탈취와 플릿 접근으로 이어질 수 있었다는 점이다.

Q3: 차량 데이터만 노출돼도 큰 문제인가요?

A: 그렇다. 위치, 운행, 운전자, 문서 정보는 개인정보와 영업비밀이며 물리적 안전 리스크와 연결된다.

Q4: 기업은 무엇부터 점검해야 하나요?

A: API 목록 노출, 객체 권한 검사, OTP 저장 방식, 관리자 API 접근 경계, 감사 로그를 우선 점검해야 한다.

Q5: AI 보안 도구로 해결할 수 있나요?

A: 탐지에는 도움이 되지만 기본 권한 모델을 대신하지 못한다. 설계와 운영 통제가 먼저다.