D02/Docker 보안 강화 - 패치 관리 전략

OWASP(Open Web Application Security Project)은
인터넷 세상에서 발생가능한 가장 중요한 보안 취약점을 정리한 문서입니다.

Overview

Docker Container에 대한 OWASP TOP 10 보안 위협 중
두 번째 항목인 D02 - Patch Management Strategy에 대한 학습 내용을 담았습니다.

D01 - Secure User Mapping에서 언급한 바와 같이,
OWASP 최소 권한의 원칙에 따라 공격 표면을 최소화하는 것이 선행될 것입니다.
이후에 주기적인 패치로 OWASP Kwown Vulnerabilities[1]를 예방해야 합니다.

1. 컨테이너 이미지

2. 컨테이너 소프트웨어

3. 오케스트레이션 소프트웨어

4. 호스트 운영체제

위의 4가지 항목에 대해서 취약한 부분을 찾는 방법이 필요할 것으로 보입니다.

1. 컨테이너 이미지의 CVE를 찾기 위한 Docker Scout[S1], Trivy[S3]

   # 자동완성된 명령어 조회
   print -l ${(ko)commands}
   
   # trivy를 통해서 CVE 검사
   trivy fs $(which docker)

2. 컨테이너 소프트웨어의, 오케스트레이션 소프트웨어, 호스트 OS는 배포 플랫폼마다 다른 방식으로 자동화가 가능할 것으로 보입니다.

   Managed Host OS 등을 사용하는 등의 사례에 따라서 다른 접근법이 필요합니다.

또한 이를 실행할 정기 패치, 긴급 패치, 패치 모니터링, 패치 롤백 등의 자동화 시스템이 필요합니다. 전체적으로 D01에 비해서 시스템적인 항목들이 필요합니다.

모든 내용은 솔루션 참고사항(Solution. Ref.)와 보안 사례 참고사항(OWASP. Ref.)로 구분하였습니다.

Patch Management Strategy

인프라를 적시에 패치(Patch)하지 않으면
OWASP Top 10’s “Known Vulnerabilities”[1] 문제에 노출됩니다. 이 경우, 알려진 취약점을 통한 악용(Exploit)이 발생 가능합니다.

컨테이너는 구조적으로 VM 보다 취약하기에,
각종 악용(exploit) 기법의 여파가 크게 작동합니다.

일반적으로 컨테이너 환경의 최악의 악용 사례는 다음과 같습니다.

1. 호스트가 손상되어 공격자가 실행 중인 모든 컨테이너를 제어할 수 있음, 구체적으로 Kernel Exploit 발생이 가능함[2]

2. 오케스트레이션 툴이 손상되어 공격자가 소프트웨어가 관리 중인 모든 호스트의 모든 컨테이너를 제어할 수 있게 됨 [3], [4]

Kernel Exploit의 대표 사례인 Dirty COW Vulnerability[2]에서 Linux Kernel의 Race condition Issue[5]으로 인한 2가지 문제점을 다루고 있습니다.

1. Kernel Race Condition 환경에서 읽기 전용 마운트에 쓰기 작업이 가능할 수 있음

2. Kernel Race Condition 환경에서 사용자 네임스페이스 컨테이너에서 루트 네임스페이스에 엑세스 가능

물론 네트워크 엑세스 제한 (D04 후술) 및 Linux 커널은 시스템 호출 제한(D03 후술)을 통해서 Kernel Exploit에 추가 보안을 적용할 수 있습니다. 하지만 그 외의 Syscall은 Kernel Exploit에 취약하여 D02 Patch Management Startegy에 의존해야 합니다.

컨테이너 환경에서는 4가지 Patch Point가 존재하며,
그 중에서도 1번과 3번은 크게 Patch를 하기 어려운 부분이 존재합니다.

컨테이너 환경에서는 4가지 Patch Point가 존재합니다.

1. 컨테이너 이미지 : the container distribution

2. 컨테이너 소프트웨어 : Dowker, Containerd

3. 오케스트레이션 소프트웨어 : Kubernetes, Mesos, OpenShift

4. 호스트 운영체제 : OS

Strategy 수립하기

적합한 Patch Management Strategy에서는 다음의 기준이 존재해야 합니다.

1. 알려진 CVE 들을 리스트업

2. 보류 중인 패치를 정기적으로 적용할 시간 범위 (정기 패치)

3. Java의 log4j와 같이 치명적인 패치를 긴급으로 실행하기 위한 절차 (긴급 패치)

4. 패치 주기를 실행하고 성공 및 실패 여부의 모니터링

5. 패치 실행 및 롤백 전략

6. Host, Ochestration, Container Software 등의 재시작 전략

Patch Monitoring

심층 조사를 하지 않고 다음과 같이 호스트에 대한 주요 지표 확인이 가능합니다.

1. Uptime

2. Process Monitoring

   top
   # Trace ... dockerd, docker-containerd•, kube*

3. Last patch check

   # Linux
   rpn --qa --last
   tail -f /var/log/dpkg.log
   
   # RHEL/CentOS
   echo n | yum check-update
   
   # Suse/SLES
   zypper list-patches --severity import -g security
   
   # Debian/Ubuntu
   echo n | apt-get upgrade

4. Latch kernel/user updated

   ls -lrt /boot/vmlinu*
   uname -a

5. Check deleted files

   lsof +L1

Patch Monitoring Automation

OpenVAS[6]와 같은 Patch Monitoring Tools을 사용할 수 있습니다.

서비스마다 배포 플랫폼 및 세부 구조와 CI/CD 구성이 다르기에 각 구성마다 필요한 Patch Monitroing Tools을 탐색할 필요가 있다고 봅니다…

Solution Ref.

• [S1] Docker Scout

• [S2] Trivy

OWASP Ref.

• [1] Using Components with Known Vulnerabilitieis, OWASP’s Top 10 2017, A9

• [2] Dirty COW Vulnerability: Impact on Containers, Blog of Aquasec

• [3] The security footgun in etcd, Week default of etcd in CoreOS 2.1

• [4-1] CVE details on Kubernetes

• [4-2] CVE details on Ranchers

• [5] Race Condition Issue, Linux Kernel - index : kenrel/git/torvalds/linux.git

• [6] OpenVAS

• [7] OWASP TOP 10, Docker Security (github)