목차
[연재 1]
1. 개요
2. 주요 내용
3. 방법론
4. 자동차 관련 취약점 - 건초 더미에서 바늘 찾기
4.1 심각도 vs. 관련성
4.2 악명 높은 공급망 취약점
[연재 2]
5. 노후화된 소프트웨어 관련 위험
6. 자동차 소프트웨어에 영향을 미치는 메모리 손상
7. 결론 |
5. 노후화된 소프트웨어 관련 위험
모든 소프트웨어는 오픈소스 소프트웨어, 상용 소프트웨어, 자체 제작된 독점 소프트웨어의 여부에 관계없이 사용되는데, 소프트웨어가 노후화될 경우 해당 소프트웨어를 개발한 개발업체의 지원이 중단되므로 더 이상 기능 개선, 안정성 업데이트, 보안 수정을 할 수 없게 된다. 또한 노후화된 소프트웨어의 최신 버전을 사용하기 위해서는 일부 소스코드를 수정해야 하므로, 이러한 추가 과정으로 인해 제품의 전체 개발 속도가 지연될 것을 우려하는 개발자도 적지 않다. 이러한 경우 노후화된 소프트웨어로 인한 문제점이 즉시 드러나지 않고 정상적으로 동작하게 된다면 해당 소프트웨어에 대한 버전 업데이트가 누락될 수 있다.
패키지 명칭 |
버전 일자 |
최신 출시일 |
노후화된 기간 |
익스플로잇 |
주요 CVE |
libxml2-1.1 |
1999.6.2 |
2019.10.30 |
20년 |
Exploit 1 |
2016-1834
2016-4448
2016-4658
2017-7376 |
glibc-2.2 |
2000.11.9 |
2021.2.1 |
20년 |
Exploit 2, Exploit 3, Exploit 4*, Exploit 5*, Exploit 6* |
2015-0235 |
ncurses-5.0 |
1999.10.29 |
2021.2.12 |
19년 |
|
|
glib-2.0 |
2002.4.13 |
2021.4.8 |
19년 |
|
|
mesa-6.3 |
2005.7.20 |
2021.4.7 |
16년 |
|
|
* DarkNet에서 사용 가능한 익스플로잇
표 4 - 자동차 소프트웨어에서 발견된 가장 오래된 5가지 패키지
그러나 노후화된 소프트웨어를 계속해서 사용할 경우 운영 상의 위험이 발생할 수 있다. 노후화된 기간이 길어질수록 수정 또는 패치가 너무 어렵거나 불가능한 상태가 될 수 있으며, 이와 관련된 위험은 자동차의 각 컴포넌트 및 기능을 위험에 빠뜨릴 수 있다.
사이벨리움은 조사를 통해 노후화된 소프트웨어의 위험성 분석을 수행했다. 사이벨리움에 의해 조사된 펌웨어 중 약 20년 동안 버전 업데이트가 이루어지지 않은 데다 중요한 CVE 취약점과 익스플로잇이 내재되어 있는 소프트웨어 패키지가 탐지되었다(
표 4). 이것은 매우 극단적인 예시지만, 사이벨리움의 연구에 따르면 분석된 ECU의 90% 이상이 5년 이상 노후한 소프트웨어 패키지를 포함하고 있으므로 취약점 악용에 노출될 가능성이 높은 것으로 나타났다.
KEY TAKEAWAYS
- 분석된 ECU 내의 소프트웨어 패키지 --- 90% 이상의 ECU가 5년 이상 노후화된 소프트웨어 패키지 포함
- 자동차 산업에서는 노후화된 소프트웨어를 사용하는 것이 일반적이기 때문에, 노후화된 소스코드로 인해 발생할 수 있는 위험을 해결하기 위한 정책을 수립할 필요가 있다.
- 소프트웨어 버전의 업데이트를 통한 취약점 완화는 합리적인 대처방안인 것처럼 보이지만, 실제로는 이것만으로 해결할 수 없는 수많은 문제점이 존재한다. 보안팀은 이러한 문제점을 해결하기 위해 소프트웨어의 패치, 구성 및 강화 메커니즘과 같은 다양한 대체 방법을 고려해야 한다.
6. 자동차 소프트웨어에 영향을 미치는 ‘메모리 손상’
사이벨리움의 연구에 따르면 자동차 소프트웨어에서 발견된 취약점 중 코딩 약점과 관련된 대부분의 취약점은 공개 CVE 취약점에 대한 기본 CWE (Common Weakness Enumeration) 취약점이거나 독점 코드의 코딩 약점 중 버퍼 오버플로, Null 역참조, Use-After-Free(UAF) 취약점, 아웃 바운드 쓰기(out-of-bound-writes)와 같은 메모리 변형 취약점처럼 메모리 손상과 관련된 것으로 나타났다.
이러한 취약점들은 모두 지난 수년 동안 컴퓨터 시스템에 영향을 미친 낮은 수준의 취약점이므로 보안성을 고려한 코드 개발 인식 제고를 통해 해결할 수 있다고 평가할 수 있지만, 사실상 보안 코드 관행만으로는 해결에 한계가 있다.
표 5 - 자동차 소프트웨어 관련 주요 CWE 취약점
표 5에서 확인할 수 있는 자동차 소프트웨어 관련 CWE 취약점 중 특히 4위를 차지한 ‘부적절한 입력 유효성 검사(Improper Input Validation, CWE-20)’ 관련 취약점은 다른 CWE 취약점과 달리 메모리 손상 유형의 취약점이 아니며 악용 가능성이 높기 때문에 특별히 주의를 기울여야 한다.
메모리 손상’이란?
메모리 손상(Memory Corruption)은 명시적인 할당없이 메모리가 변경될 때 컴퓨터 시스템에서 발생할 수 있는 취약점으로, 공격자가 임의의 코드를 실행할 수 있도록 하는 프로그래밍 오류로 인하여 메모리 위치와 관련된 내용이 수정된다. 대표적인 메모리 손상 관련 취약점으로는 버퍼 오버플로(Buffer Overflow), Use-After-Free, 더블 프리(Double Free) 취약점이 있다.
버퍼 오버플로
버퍼 오버플로(Buffer Overflow)는 데이터의 양이 메모리 버퍼의 저장 용량을 초과할 때 발생한다. 공격자는 임의로 응용 프로그램 상의 메모리를 덮어쓰고 프로그램의 실행 경로를 변경하고 파일을 손상시키거나 개인정보 유출을 트리거하는 방법 등을 통해 공격을 수행한다.
USE-AFTER-FREE 취약점
USE-AFTER-FREE 취약점은 응용 프로그램이 더 이상 할당되지 않은 메모리를 사용하려고 할 때 발생하는 메모리 손상 결함을 의미한다. 공격자는 해당 취약점을 악용하여 특정 코드에 대한 원격 실행 기반의 공격을 수행할 수 있다.
더블 프리 취약점
더블 프리(DOUBLE FREE) 취약점은 동일한 메모리 주소를 인수로 사용하여 메모리 블록을 두 번 이상 해제하거나 할당 해제할 때 발생하는 취약점이다. 이와 관련하여 공격자가 임의의 코드를 실행할 수 있는 write-what-where 조건이 발생할 수 있다.
|
‘입력 유효성 검사(Input validation)’는 코드 내에서의 동작 또는 다른 컴포넌트와의 통신 시 발생할 수 있는 잠재적인 위험을 테스트하는 기술이다. 소프트웨어에 대한 적절한 유효성 검사가 이루어지지 않을 경우 공격자가 특정한 입력 내역을 조작하여 응용 프로그램(Application)의 일부가 의도하지 않은 입력을 수신하여 제어 흐름, 리소스에 대한 임의 제어, 임의 코드 실행과 관련된 사항을 변경할 수 있다. 이러한 코딩 취약점의 익스플로잇 프로세스는 상대적으로 공격에 악용하는 것이 간단하고 역공학 기술과 관련된 전문적인 지식 및 경험이 많지 않은 초보 공격자도 비교적 손쉽게 공격을 수행할 수 있지만 그 공격으로 인한 피해는 심각할 수 있다.
KEY TAKEAWAYS
- 대부분의 자동차 ECU의 CWE 취약점은 메모리 손상과 관련이 있다.
- 제품 보안팀은 이와 관련하여 SDLC (Software Development Life Cycle) 전반에 걸쳐 지속적인 검증을 수행해야 한다.
- 자동차 솔루션을 통해 코딩과 관련된 취약점을 쉽게 식별할 수 있다.
- 개발팀 대상의 보안 인식 프로그램 또는 교육을 통해 안전한 코딩 모범 사례에 대한 교육을 수행할 필요가 있다.
7. 결론
오늘날의 자동차는 수많은 소프트웨어에 의해 작동한다. 사이벨리움은 이와 관련하여 소프트웨어 보안을 위한 소스코드의 품질 및 유지관리 영역에서 증가하고 있는 자동차 사이버 위험과 관련된 분석을 제공하기 위해 이 보고서를 작성했다. 자동차의 사이버 위험을 사전에 관리하기 위해서는 개발팀과 보안팀이 지속적으로 협력하고 보안 강화를 위한 지원정책을 수립하고 시행해야 한다.
이러한 보안 강화 지원 정책에는 소프트웨어 자산 인벤토리 생성, 안정적이고 시기적절한 취약점 데이터 식별 및 분석, 다양한 보안 위험의 영향을 받는 소스코드를 처리하는 방법 등에 대한 상세한 지침이 포함되어야 하며, 이를 통해 제조 및 특성에 대한 명확한 가시성을 확보할 수 있다. 자동차 OEM 및 제조업체는
다음 세부사항에 대한 점검을 통해 자동차 사이버 보안을 강화할 수 있다.
- 취약점 관리 프로그램을 위한 정확한 S-BOM(Software Bill of Materials) 식별과 구성요소 및 소프트웨어 사이의 상관관계를 분석한 ‘컨텍스트 데이터(Context Data)’를 사용하여 포괄적인 소프트웨어 자산 인벤토리 생성
- 가장 시급한 취약점에 대한 완화를 위한 우선순위 지정을 자동화할 수 있도록 소프트웨어 상관관계 인식 기반의 의사결정 수행
- 스마트 자동화 솔루션의 사용이 가능할 경우, 이를 통해 대규모 취약점을 효과적으로 관리
- 수년 전 발견된 취약점 뿐만 아니라 새롭게 발견된 취약점까지 자동차 공급망을 위협하고 있어 이에 대한 완화 필요
- 소프트웨어 버전의 업데이트, 패치 등을 고려한 취약점 완화 전략에 대한 재평가
- 노후화된 소프트웨어 사용으로 인한 잠재적인 위험을 해결하기 위한 정책 수립
- 알려진 취약점 및 코딩 오류로 인한 취약점 악용 공격 피해를 완화하기 위해 SDLC(Software Development Life Cycle) 전반에 걸쳐 지속적인 테스트 수행
- 개발팀을 위한 보안 교육 프로그램을 통해 메모리 손상 위험에 대한 인식을 제고하고 소프트웨어 개발 시 안전한 코딩 관행을 숙지할 수 있도록 촉진
[연재 1] 다시보기 >>>
<저작권자 © AEM. 무단전재 및 재배포, AI학습 이용 금지>