[논문리뷰] - A Container Security Survey: Exploits, Attacks, and Defenses

Title : A Container Security Survey: Exploits, Attacks, and Defenses
Publish : ACM Computing Surveys
Author : OMAR JARKAS, The University of Queensland, Brisbane, Australia RYAN KO, The University of Queensland, Saint Lucia, Australia NAIPENG DONG, The University of Queensland, Saint Lucia, A ustralia REDOWAN MAHMUD, Curtin University, Perth, Australia
Date : 20 February 2025

Abstract

컨테이너화는 자원 소비를 줄이고, 확장성을 높이며, 오케스트레이션을 단순화함으로써 클라우드 컴퓨팅의 효율성을 향상시키지만, 전통적인 가상머신에 비해 공유된 리눅스 커널과 낮은 격리 수준으로 인해 보안 취약점을 유발함. 이러한 특징들은 자원 효율적이긴 하지만 소프트웨어 취약점에 대한 공격 표면을 증가시켜 잠재적인 침해헤 더 취약해지고, 커널을 공유하기 때문에 동일 호스트 내 모든 컨테이너를 위험에 빠뜨릴 수 있다. 이 논문에서 200개 이상의 컨테이너 관련 취약점을 분석하여 이를 11개의 공격 벡터와 47개의 익스플로잇 유형으로 분류하였다. 특히 복잡한 멀티테넌트 클라우드 환경에서 취약점을 해당 익스플로잇 및 대응 전략과 매핑함으로써 컨테이너 보안을 강화시킨다.

1 Introduction

클라우드 컴퓨팅은 확장 가능하고 유연한 리소스를 제공하며, 가상화는 이러한 리소스 사용을 최적화하는 핵심 기술이다. 컨테이너화는 가상화 기술을 한 단계 더 발전시킨 것으로, 확장성을 향상시키고 필요한 리소스를 줄여준다. 컨테이너들은 단일 커널을 공유하므로 애플리케이션을 위한 별도의 OS가 필요하지 않다. 하지만 이러한 공유 커널 모델 및 종속성 중첩 문제는 컨테이너 간의 격리를 약화시키고 공격 가능성을 높임.

2 Background

하이퍼바이저 기반 가상화 (Hypervisor-based virtualization)를 통해 VM을 생성하면 이는 하나의 완전한 물리적 컴퓨터처럼 동작하며 단일 하드웨어 위에서 여러 OS 실행이 가능. 강력한 격리를 제공하지만, 효율성/확장성이 낮음 (오버헤드 발생)
컨테이너화 : 애플리케이션과 그에 필요한 구성 요소들을 캡슐화 및 호스트 OS 커널 공유 -> 개별 OS 설치할 필요가 없음 -> 리소스 활용도 개선. 그러나 공유 커널 아키텍처는 공격 표면이 증가하고, 권한 상승 공격에 취약해짐. 따라서 애플리케이션 계층부터 커널 및 컨테이너 엔진에 이르기까지 위험 완화를 위한 소프트웨어/하드웨어 기반 보안 솔루션 필요.

아래 그림(Figure 1)은 컨테이너화 환경을 그림으로 표현함

alt text

L1 (Orchestration Layer) : K8s와 같은 플랫폼에서 컨테이너 운영을 관리하고, 컨테이너화된 애플리케이션의 배포/확장/관리를 자동화하여 효율적인 리소스 사용 및 고가용성을 보장하지만 중심적인 (권한을 필요로 하는 작업이 많기 때문) 역할 때문에 보안 위협에 노출되기 쉬움.

L1 해결책 : 클러스터 및 컨트롤 플레인 보호, 최소 권한 원칙 적용, 네트워크 설정 강화, 강력한 인증 및 인가 구현, 지속적인 모니터링 필요

L2 (Application Layer) : 애플리케이션의 코드, 종속성, 런타임 구성요소 실행 공간. 컨테이너가 격리된 공간을 제공하지만 코드 결함 및 종속성 겨냥 공격에 취약. 안전하지 않은 코딩 관행, 패치되지 않은 구성 요소, 부적절한 입력값 검증, 설정 오류 등을 통해 데이터 유출 및 임의 코드 실행 (ACE, Arbitary Code Execution) 유발 가능

L2 해결책 : 안전한 개발 관행, 종속성 관리, 엄격한 입력값 검증, 안전한 설정 필요

L3 (Engine and Runtime Layer) : 컨테이너 운영의 핵심. 엔진(ex. Docker)과 런타임(ex. runc, containerd)은 네임스페이스 및 cgroups를 통해 격리를 구현하며, 이미지 생성부터 실행까지의 컨테이너의 생명 주기를 관리. 그러나 호스트 커널과의 상호작용이 있기 때문에 권한 상승 및 컨테이너 escape와 같은 공격 벡터 유발 가능.

L3 해결책 : 컨테이너 이미지 무결성 보장, 최소 권한 원칙 적용, 엔진 및 런타임 설정을 통한 행위 제한, API(ex: Docker API) 보안 확보, 엔진 및 런타임 및 관련 종속성에 대한 정기적 업데이트 필요, L3 계층을 통한 공격을 막기 위해 호스트 커널 강화 필요

L4 (Host Layer) : 컨테이너가 호스트 커널을 공유하기 때문에 컨테이너화된 환경의 보안에서 매우 중요한 역할을 함. 네임스페이스 격리는 모든 공격 벡터에 완벽하지 않음. 각 네임스페이스 유형에 따라 맞춤형 완화 전략 필요. 상태와 구성이 빠르게 변하는 컨테이너의 일시적인 특성 (K8s의 pod)은 L4 보안을 어렵게 함.

L4 해결책 : 엄격한 접근 제어, 컨테이너 전용 보안 도구, 엄격한 컨테이너 구성 및 관리, 모니터링 및 실시간 분석 필수. 신뢰 실행 환경 (Trusted Execution Environments, TEEs), 신뢰 도메인 (trusted domains)와 같은 기술 사용, 무결성 보장을 위한 신뢰 플랫폼 구현 등의 하드웨어 기반의 보안을 통해 보안 강화 가능

L5 (Hardware Layer) : CPU, 메모리 등 운영에 필수적인 하드웨어 구성. 하드웨어의 취약점이 클라우드 컴퓨팅 및 컨테이너 환경에서 애플리케이션의 무결성과 격리를 손상시킬 수 있음. speculative execution이나 정교/복잡한 캐시 계층 구조와 같은 하드웨어 발전은 효율성은 커지지만, 보안 문제 가능. -> meltdown, speculative attack 유발 가능. 즉, 프로세서 최적화 기술을 악용하여 정보 유출 및 보안 우회, 코드 무단 실행 등 공격 가능 -> 멀티테넌트 환경에서 심각한 문제 가능.

L5 해결책 : 설계 개선, 펌웨어 업데이트 필요. OS는 커널 페이지 테이블 격리와 같은 보호 장치 도입해야 함. 안전한 코딩 및 사이드 채널 공격 위험 줄이는 설정(하이퍼스레딩 조정) 필요

3 Attacks, Exploits and Vulnerabilities

200개 이상의 컨테이너 취약점을 11가지 공격 유형(A) 및 그에 해당하는 익스플로잇(E)으로 분석. 아래 그림은 계층별 공격 및 익스플로잇의 시각화.

alt text

3.1 Orchestration Layer (L1)

Orchestration Attacks A1

E1 악성 바이너리를 통한 부적절한 처리 : 오케스트레이션 명령어를 통해 컨테이너와 호스트 간의 파일 전송 상황에서 보안 위험 초래. 합법적인 바이너리 (ex: tar)를 악성 버전으로 교체하여 임의 코드 실행 및 시스템 변조 가능. 관련 CVE로는 CVE-2019-11246, CVE-2019-11249 존재
E2 컨트롤 플레인 우회 : API 서버와 같은 컨트롤 플레인 구성 요소의 취약점을 대상으로 함. 무단 접근, 권한 상승, DoS로 이어져 공격자가 시스템 제어권 탈취 가능. 관련 CVE로는 CVE-2020-8552, CVE-2021-25735, CVE-2018-1002105, CVE-2023-3978, CVE-2020-8559 존재 -> 부적절한 요청 속도 제한, 검증되지 않은 리디렉션, 잘못된 TLS 인증서 처리, 불충분한 웹훅 검증
E3 입력 및 파싱 오류 : YAML, JSON의 부정확한 파싱으로 인한 보안 문제. CPU나 메모리에 과부하를 주어 DoS 유발. 관련 CVE로는 CVE-2019-11254, CVE-2021-25738 존재 -> YAML 로드 시, 안전하지 않은 역직렬화를 통해 임의 코드 실행 가능
E4 파일 조작 : 컨테이너 환경에서 볼륨, 파일 권한, 심볼릭 링크, 임시 저장소의 부적절한 처리에서 비롯됨. K8s에서 /etc/hosts와 같이 pod가 생성한 파일의 디스크 사용량을 제한하지 못해 CVE-2020-8557 발생. CVE-2019-1002101, CVE-2017-1002102는 안전하지 않은 볼륨 관리를 통해 임의의 파일을 삭제하거나 호스트 파일 시스템에 무단으로 접근할 수 있는 위험을 보여줌.
E5 비인가 접근 및 secret 탈취 : 특정 취약점으로 인해 민감한 데이터와 기능이 노출되는 경우. 관련 CVE로는 CVE-2020-8565 (부적절한 로깅으로 인해 로그 파일에 토큰 노출), CVE-2024-25742 (ingress nginx의 커스텀 스니펫 오용을 통해 클러스터 시크릿에 접근), CVE-2020-8558 (kubelet의 kube-proxy 결함으로 인해 127.0.0.1만 접근 가능한 서비스가 주변 호스트들에 노출)
E6 오버레이 네트워크 암호화 : 가상 LAN에서 컨테이너 간 안전한 통신에 필수적인 오버레이 네트워크 암호화의 취약점을 통해 공격 수행. 관련 CVE로는 CVE-2023-28840, CVE-2023-28841, CVE-2023-28842 존재 -> 잘못된 규칙 우선순위로 인해 암호화되지 않은 데이터그램이 보안을 우회하는 문제, 보안 네트워크에서 암호화되지 않은 데이터 전송이 가능해지는 문제, 잘못된 커널 구성으로 인해 평문 데이터그램이 허용되어 데이터 유출 및 DoS 유발 -> 암호화 메커니즘의 신중한 설계, 구성, 검증 필요
E7 트래픽 조작 및 리디렉션 : 무단 트래픽 제어, 리디렉션, 조작 허용하는 취약점에서 발생. CVE-2020-10749는 IPv6의 라우터 광고를 악용하여 MITM 수행. CVE-2021-25737은 pod 트래픽을 노드의 비공개 네트워크로 리디렉션. CVE-2022-3172, CVE-2020-8554는 ClusterIP 설정 오류로 인한 무단 URL 리디렉션 및 트래픽 가로채기와 연관. CVE-2021-25740, CVE-2022-3294는 confused deputy (혼동된 대리인) 공격 수행. 이는 공격자가 합법적인 권한을 가진 개체를 속여 트래픽을 잘못된 곳으로 보내거나, 무단 리소스에 접근하게 하는 공격. 이를 통해 공격자가 컨트롤 플레인의 네트워크 상태를 조작하거나 보안 엔드포인트를 침해할 수 있게 함. 강력한 네트워크 정책, 트래픽 암호화, 서비스 메시 아키텍처, 엄격한 보안 엔드포인트 필요

3.2 Application Layer (L2)

Application-level Attacks A2

E8 입력값 조작 : 원격 임의 코드 실행 유발하기 위해 악의적인 입력값 조작 및 주입 가능. 컨테이너 환경에서의 이러한 입력값 조작을 통해 무단 접근, 데이터 손상, 권한 상승, 호스트 장악 초래 가능
E9 부적절한 파일 처리 : 결함 있는 파일 처리 방식과 부적절한 접근 제어에서 비롯 -> 시스템을 악의적인 행위자의 조작에 노출. CVE-2016-1240, CVE-2016-1247, CVE-2016-9566에서 심볼릭 링크 공격을 통해 파일 작업을 잘못된 경로로 유도하여 권한 상승. 이를 통해 전체 호스트 시스템 및 클러스터까지 위협 가능
E10 오버플로우 :
E11 코드 주입 :
E12 기본 설정 오류 :

3.3 Engine Layer (L3)

3.3.1 Image Integrity Attacks A3

E13 베이스 이미지 전파 : 컨테이너 베이스 이미지에 내재된 위험 강조 -> 시스템 전반에 걸친 취약점 유발 가능. 오래된 Docker image tag에 취약점이 있을 수 있음. 관련 CVE로는 CVE-2020-35467, CVE-2020-35197 존재
E14 이미지 스푸핑 : 컨테이너 관리에서의 식별 및 검증 약점을 통해 공격 가능 -> 레지스트리 스푸핑, 경로 탐색, 이미지 캐시 포이즈닝, DoS 공격 가능.
E15 빌드 조작 : 이미지의 빌드, 추출, 조작 단계에서 발생하는 취약점. 악성 코드 주입, 권한 상승, 무단 명령 실행 야기함. 이를 방지하기 위해 소스 코드, 바이너리, 아카이브의 무결성 확인 필요.
E16 레지스트리 처리 오류 : 컨테이너 이미지 레지스트리의 취약점으로 무단 권한 상승, DoS, 임의 코드 실행, 안전하지 않은 통신 프로토콜 악용으로 이어짐.

3.3.2 Container Run-time Environment A4

E17 보안 정책 처리 오류 : 부적절한 구성, 느슨한 보안 정책 관리, LSM, AppArmor 프로파일, 마운트 타켓 등의 보안 메커니즘의 잘못된 핸들링으로 인한 컨테이너 무결성 손상 유발. CVE-2015-3631을 통해 Docker Engine의 LSM 및 docker_t 정책이 어떻게 권한 상승에 악용될 수 있는지 보여줌. CVE-2016-8867은 악성 이미지에 의해 Docker Engine의 사용자 권한 우회가 가능해짐. CVE-2017-6507은 AppArmor 프로파일 우회 및 잘못된 처리를 보여줌 -> 올바른 구성 및 보안 정책 필요성 강조
E18 권한 오류 :
E19 데몬 중단 :

[논문리뷰] - 유니커널 Canal Mesh: A Cloud-Scale Sidecar-Free Multi-Tenant Service Mesh Architecture