[논문리뷰] - Cross Container Attacks: The Bewildered eBPF on Clouds

Title : Cross Container Attacks: The Bewildered eBPF on Clouds
Publish : USENIX Security Symposium 2023
Author : Yi He and Roland Guo, Tsinghua University and BNRist; Yunlong Xing, George Mason University; Xijia Che, Tsinghua University and BNRist; Kun Sun, George Mason University; Zhuotao Liu, Ke Xu, and Qi Li, Tsinghua University
Date : August 9–11, 2023

Title : Cross Container Attacks: The Bewildered eBPF on Clouds
Publish : USENIX Security Symposium 2023
Author : Yi He and Roland Guo, Tsinghua University and BNRist; Yunlong Xing, George Mason University; Xijia Che, Tsinghua University and BNRist; Kun Sun, George Mason University; Zhuotao Liu, Ke Xu, and Qi Li, Tsinghua University
Date : August 9–11, 2023

Abstract

eBPF(extended Berkely Packet Filter)는 사용자 프로그램을 커널 공간에서 직접 실행함으로써 커널 기능을 확장할 수 있도록 강력하고 유연한 커널 인터페이스를 제공한다. 이는 컨테이너 보안, 네트워크 관리, 시스템 관찰을 향상시키기 위해 클라우드 서비스 분야에서 광범위하게 사용되어 왔다. 그러나, 광범위하게 논의된 공격적인 eBPF가 컨테이너에 새로운 공격 표면을 가져올 수 있음을 발견했다. eBPF 추적 기능을 통해, 공격자는 컨테이너 고립을 깨뜨릴 수 있을 뿐만 아니라, 민감한 데이터를 훔치거나, DoS 공격, 컨테이너 탈출(Container Escape)등을 통해 호스트를 공격할 수 있다. 본 논문에서, eBPF 기반 컨테이너 간 공격을 연구하고, 실제 서비스에서의 보안 임팩트를 밝혀낸다. eBPF 공격을 통해 연구자들은 다섯 개의 온라인 Jupyter/Interactive Shell 서비스와 GCP(Google Cloud Platform)의 Cloud shell을 성공적으로 침해했다. 또한, 주요 클라우드 벤더 3곳에서 제공하는 k8s 서비스가 공격자들이 eBPF를 통해 컨테이너를 탈출시킨 후 노드 사이 공격을 시작하는데 악용될 수 있음을 찾았다. 구체적으로, 알리바바의 k8s 서비스에서 공격자들은 과도한 권한을 가지는 클라우드 메트릭 또는 management Pods를 악용함으로써 전체 클러스터를 침해할 수 있다. 불행히도, 컨테이너의 eBPF 공격은 거의 알려지지 않았으며, 기존의 침입 탐지 시스템(IDS, Intrusion Detection System)을 통해서 쉽게 발견되지 않는다. 또한 기존 eBPF 권한 모델(eBPF Permission Model)은 eBPF 자체를 제한할 수 없을 뿐만 아니라, 공유 커널 환경에서 안전한 사용을 보장할 수 없다. 이를 위해 연구자들은 컨테이너 사이 공격에 대응하기 위해 새로운 eBPF 권한 모델을 제안한다.

1 Introduction

eBPF는 커널 내 eBPF 가상 머신을 통해 userspace 코드 (eBPF 프로그램)을 커널에서 안전하고 효율적으로 실행하는 것을 목표로 하는 리눅스 커널 기능이다. eBPF 프로그램은 커널 데이터를 읽을 수 있고, 또한 커널 함수를 eBPF helpers를 통해 호출할 수 있다. eBPF 프로그램을 커널에서 직접 실행함으로써, 사용자들은 커널 상태를 얻을 수 있고, 유저 스페이스로 데이터를 복사하지 않고 커널 인터페이스를 조작할 수 있다. 이는 결과적으로 더 좋은 성능과 관찰성을 얻을 수 있다. 커널 안정성을 위해, eBPF 프로그램은 고정된 위치에서만 실행이 허용되며, 악의적인 행동(무한 루프 및 outbounds read/write 작업)을 방지하기 위해 eBPF verifier를 통해 유효성을 검증받는다. 그러나 일부 공격적인 eBPF 기능들 (예시 : 다른 프로세스에 메모리 쓰기를 허용하는 bpf_probe_write_user 헬퍼 함수)이 2016년부터 커널에 추가되었으며, 이들은 사용자 공간 프로세스에 잠재적 위협을 가할 수 있다. (즉, 프로세스 사이 격리를 위반할 수 있음) 이러한 기능들은 2019년 커뮤니티에 의해 위험한 것으로 처음 밝혀졌고, 몇몇 연구들은 eBPF 기반 악성 malware나 rootkits 개발 가능성을 보여주었다. 한편, 컨테이너 환경에서 이러한 eBPF 공격적 기능들의 보안 영향은 아직 탐구되지 않았으며, 그들의 위협은 커뮤니티에서 잘 이해되지 않고 있다. eBPF는 기존 클라우드 네이티브 세계에서 Cilium, Falco, Calico와 같은 컨테이너용 성능 프로파일링, 네트워크 관리, 보안 모니터링 도구를 구현하기 위해 광범위하게 사용되고 있다. 과거에는 컨테이너 환경에서 eBPF 사용의 보안 위험이 주로 새로운 커널 취약점을 가져와 컨테이너 탈출로 이어질 가능성으로 여겨졌다. 그러나 연구자들은 eBPF 커널 취약점을 악용하지 않더라도 eBPF의 정상적인 기능이 컨테이너에 새로운 공격 표면을 가져올 수 있음을 발견했다. 특히, eBPF tracing 프로그램은 컨테이너의 UID와 PID 네임스페이스 기능에도 제한되지 않으며, 호스트 VM이나 다른 컨테이너에서 실행되는 프로세스를 포함하여 전체 시스템의 프로세스를 모니터링할 수 있다. 결과적으로, 리눅스 호스트에서의 공격적인 eBPF 커널 기능은 컨테이너 안에서도 악용되어 컨테이너 외부 프로세스에도 악영향을 줄 수 있다. 본 논문에서 연구자들은 컨테이너 환경에서 eBPF 공격 벡터의 위험성을 조사하고, 실제 서비스에 대한 위험도를 측정한다. 연구자들의 연구는 알려진 eBPF 공격이 컨테이너 외부의 프로세스에 해를 끼칠 수 있음을 밝혀낸다. 예를 들어 다른 프로세스를 종료시켜 피해자 프로세스에 DoS 공격을 시작하거나, 다른 프로세스의 메모리/열린 파일을 읽어 민감한 정보를 탈취하거나, 프로세스 하이재킹을 통한 악성 명령 실행 등 공격등의 공격이다. 더 나아가, 컨테이너 외부의 특권 프로세스를 하이재킹함으로써, 공격자는 로컬 컨테이너에서 탈출할 수 있다. 구체적으로 기존 프로세스 하이재킹 솔루션들이 자원격리로 인해 컨테이너에서 작동하지 않기 때문에, 연구자들은 CVE-2022-42150과 같은 새로운 eBPF 기반 컨테이너 탈출 접근법을 제안한다. 또한 연구자들은 eBPF가 피해 컨테이너와 동일한 VM에 배포된 비보안 Pod를 남용하여 k8s 클러스터의 악용을 도와줌을 발견하였다. eBPF 위협은 대부분 컨테이너에게 부여되지 않을 수 있는 CAP_SYS_ADMIN 기능을 요구하기 때문에 컨테이너 커뮤니티의 충분한 관심을 끌지 못했다. 그럼에도 불구하고 연구자들은 Docker Hub repository를 분석하여 2.5% 이상의 컨테이너가 eBPF 공격에 필요한 권한을 가지고 있음을 발견했다. 이러한 컨테이너들이 노출되면, 공격자들은 컨테이너를 탈출시킬 수 있을 뿐만 아니라, eBPF 공격을 통해 k8s 클러스터를 침해할 수 있다.

실제 영향을 이해하기 위해 연구자들은 실제로 사례 연구를 수행하고, 실제 온라인 컨테이너 환경에서의 exploit을 탐구한다. 우리는 컨테이너 기반의 온라인 서비스(온라인 프로그래밍 플랫폼과 같이 사용자가 자신의 프로그램을 실행할 수 있는 서비스, 예시 aws의 ecs) 와 컨테이너 기반의 클라우드 제품을 모두 조사한다. 연구자들의 실험 결과는 11개의 온라인 프로그래밍 플랫폼 중 4개의 Jupyter Notebook 서비스와 1개의 온라인 대화형 프로그래밍 강좌 서비스를 포함하여 5개가 eBPF를 실행할 수 있음을 보여준다. 우리는 컨테이너 외부의 다양한 프로세스를 하이재킹하여 eBPF를 통해 5개의 플랫폼 모두의 컨테이너에서 성공적으로 탈출했다. 더욱이 이들 서비스 중 2개가 공유 커널 컨테이너 환경에 배포되어 있기 때문에, 우리는 다른 사용자의 컨테이너를 더 악용하여 데이터를 탈취하거나 트로이안과 같은 악성 프로그램을 심을 수 있다. 나머지 3개의 플랫폼은 단일 사용자에게 전용 VM을 할당하는 컨테이너로 배포되어 있었다. 이들은 여전히 사용자 능력을 제한하기 위해 컨테이너에 의존하고 있지만 이는 컨테이너 탈출이 성공된다면, 우회될 수 있다. (예를 들어 Colab은 사용자가 ssh를 통해 직접 연결하는 것을 허용하지 않는다 - 즉, 서비스 사용자의 직접적인 시스템 접근을 차단하기 위해 컨테이너 기반의 제한을 사용하지만, eBPF를 통해 컨테이너 탈출을 성공한다면, 보안 정책이 무력화될 수 있음을 보여줌.) 연구자들은 주요 클라우드 벤더의 k8s 클러스터 제품에서 노드 사이 공격을 검토한다. 3개의 k8s 제품이 과도한 권한을 가진 Operator Pod를 가진 비보안 노드를 포함하고 있다. 이들 노드 중 어느 하나라도 eBPF 공격자에 의해 침해되면, 공격자들은 이 노드의 모든 Pod의 서비스 계정을 남용하여 다른 노드들을 악용할 수 있다. (서비스 계정 : pod에서 k8s api 서버와 통신하기 위해 사용하는 인증 정보) 구체적으로 알리바바 ACK 클러스터에서, 데이터 백업, 네트워크 프록시, 성능 메트릭(예시 : prometheus pod) 위해 배포된 일부 강력한 Operator Pod를 악용함으로써, 공격자들은 전체 클러스터를 침해할 수 있다. Azure와 AWS의 k8s 서비스에서 공격자들은 클러스터 관리 Pod를 남용하여 여러 노드를 침해할 수 있지만, 이러한 Pod들이 제한된 노드에만 영향을 줄 수 있었기에, 전체 클러스터를 제한할 수 없었다.

게다가, eBPF 공격은 기존 방어 도구에서 사용하는 시스템 추적 결과를 방해할 수 있기 때문에, 은밀하고 탐지하기 더 어렵다. (eBPF는 커널 수준에서 작동하기 때문) 기존 보안 도구들은 그들의 위협 모델에 eBPF를 통한 공격 방지를 포함하지 않았기 때문에, 다른 컨테이너의 악성 eBPF 프로그램에 의해 침해될 수도 있다. eBPF 권한을 가진 컨테이너가 공격자에게 노출되면, 공격자들은 컨테이너에서 탈출하고 클라우드 보안 도구에 의해 감지되지 않고 k8s 클러스터를 더 악용할 수 있다. 리눅스의 기존 기능들은 eBPF 기능을 전체적으로 비활성화하거나 활성화할 수 있기 때문에, eBPF 남용을 방지할 수 없다. eBPF를 전역적으로 비활성화하는 것은 실행 불가능하다. 왜냐하면 일부 사용자나, systemd와 같은 시스템 서비스는 여전히 eBPF를 필요로 하기 때문이다. 특히 eBPF가 NVMe 드라이버 확장, 커널 락 수정, OS나 프로그램 취약점의 핫피싱과 같은 상황에서 적용되었을 때는 더 eBPF를 비활성화하기 어렵다. eBPF 공격 완화하는 한 가지 잠재적 대응책은 신뢰할 수 있는 프로그램만이 eBPF 기능을 사용할 수 있도록 허용하는 세밀한 eBPF 접근 제어 메커니즘을 배포하는 것이다. (예를 들어 LSM, Linux Security Model 기반 도구 - SELinux, AppArmor) 그러나 일부 유명한 eBPF 보안 도구(예시 : Datadog 등)가 여전히 eBPF 기능을 필요로 하기 때문에, 사용자들은 결국 일부 프로그램이 이러한 기능을 사용하도록 허용할 수 있어 공급망 공격을 허용하게 된다. (공급망 공격 : 신뢰할 수 있는 소프트웨어나 서비스를 통해 악성 코드를 유입시키는 공격 방식) 이러한 문제를 해결하기 위해 연구자들은 프로그램이 사용 가능한 eBPF 기능에 대한 세밀한 제어를 제공할 뿐만 아니라, 피해 프로세스가 eBPF 악성 코드에 의해 침해되는 것을 적극적으로 보호하는 새로운 eBPF 권한 모델을 제안한다.

Contributions.

본 논문에서 연구자들은 컨테이너에서의 공격적 eBPF 기능을 조사하고, 컨테이너 탈출 공격과 k8s 클러스터의 노드 간 공격을 위한 새로운 eBPF 기반 공격 벡터를 발견한다. 실제 영향을 이해하기 위해 연구자들은 다양한 클라우드 서비스를 연구하고 5개의 취약한 온라인 서비스를 발견한다. 우리는 기존 클라우드 보안 제품이 eBPF에 의해 악용될 수 있으며, 3개의 클라우드 벤더의 기본 k8s 클러스터가 제안되 노드 간 공격에 취약함을 발견한다. 이러한 우려를 해결하기 위해 우리는 기존 LSM 기반 솔루션보다 더 나은 성능과 보안을 제공할 것으로 기대되는 새로운 eBPF 권한 모델을 제한한다.

Ethical Consideration.

이 연구 동안 우리는 모든 대상 플랫폼의 버그 바운티 규정을 검토하고 우리의 연구가 그들의 규칙을 준수하도록 보장한다. 첫 번째로, 일반적인 쉘 명령을 실행하여 플랫폼이 eBPF 권한을 가지고 있는지 확인한다. eBPF를 실행할 수 있는 플랫폼에 대해서는 공유 커널 컨테이너를 사용하는지, VM 격리 컨테이너를 사용하는지 추가로 식별한다. 공유 커널 컨테이너의 경우, 우리는 서비스 제공업체에 알리고 그들이 제공한 테스트 환경에서 공격을 수행한다. 사용자의 Jupyter 컨테이너를 전용 VM 내에서 격리한 Google Cloud Shell, Colab, Datalore, Gradient를 포함한 다른 플랫폼의 경우, 우리의 공격은 우리 자신의 VM에서 발생하며, 다른 사용자에게 영향을 주지 않는다. 5.2에서 논의된 클라우드 제품의 경우, 우리는 4개 벤더에게 이러한 사실을 알렸다. 그들의 탄력적 서버리스 함수는 컨테이너가 eBPF를 지원하지 않기 때문에, 우리는 우리의 사설 VM에서 그들의 k8s 제품을 악용하는 데 집중하며, 모든 테스트는 다른 사람에게 영향을 주지 않는다.

2 Background and Motivation

2.1 eBPF and its Offensive Features

범용 RISC 명령어 집합을 가진 범용 커널 내부 VM을 제공함으로써, eBPF는 클래식 BPF(cBPF, seccomp)의 보완으로 2014년 리눅스 커널 3.18에 도입되었다. eBPF RISC 명령어는 LLVM 툴체인을 사용하여 다양한 프론트엔드 언어(C, Rust)로부터 컴파일될 수 있다. 사용자 공간 프로그램은 다양한 eBPF 프로그램 유형을 특정 커널 하위시스템에 설치하여, 네트워크 흐름 제어를 위한 XDP(eXpress Data Path : 네트워크 드라이버 수준에서 패킷을 처리하는 고성능 기술)/TC(Traffic Control : 네트워크 트래픽 제어 시스템), 보안 강화를 위한 LSM, 성능 분석이나 디버깅을 위해 커널 함수를 훅하는 KProbe(커널 함수 실행 지점에 동적으로 코드 삽입하는 디버깅 메커니즘)와 같은 커널 기능을 확장할 수 있다.

eBPF는 커널 메모리를 조작하거나, 무한 루프를 통해 자원을 고갈시켜 eBPF 코드가 커널을 손상시키는 것을 방지하기 위해 정적 분석 기반 검증기를 사용한다. 그러나 사용자 공간에 제공되는 일부 문제적인 eBPF 기능들은 악성 eBPF 프로그램이 네트워크 패킷을 조작하고, 프로세스를 종료시키고, 다른 프로세스의 메모리에 접근하고 수정하며, 시스템콜의 인수느 반환 코드를 수정할 수 있게 한다. 리눅스 호스트에서 eBPF를 실행하는 것은 루트 권한을 필요로 하기 때문에, 이러한 강력한 기능들은 사후 악용 공격을 쉽게 만든다. (post-exploitation attacks, 사후 악용 공격 : 공격자가 이미 시스템에 침투한 후 권한 확대, 지속성 유지, 데이터 탈취 등을 위해 수행하는 공격 단계를 의미함) 기존 연구들은 주로 악성 행동을 은닉하여 Linux rootkits를 향상시키기 위해 이러한 공격적 기능들을 악용하는데 집중한다. 컨테이너 환경에서 그들의 위험은 아직 연구가 되지 않은 상태로 남아있다. (즉, 리눅스 호스트에서만 연구가 되고, 컨테이너 환경에선 연구가 부족함)

컨테이너 내부에서 사용자의 능력은 CPU와 메모리 할당을 위한 Cgroups, UID/PID 프로세스 격리를 위한 네임스페이스, 시스템 호출 제한을 위한 Seccomp, 파일 시스템 격리를 위한 chroot와 같은 다양한 보안 메커니즘에 의해 제한된다. 그러나 eBPF 추적 기능이 이러한 격리를 깨뜨려 모든 프로세스를 탐지할 수 있음을 발견했다. 이는 악성 eBPF 프로그램이 알려진 eBPF 공격 벡터를 사용하여 컨테이너 외부의 프로세스를 악용할 수 있게 한다. 불행히도 이 위험은 컨테이너와 커널 커뮤니티에 의해 완전히 이해되고 있지 않다.

2.2 A Running Example of eBPF Attakcs

Figure 1: eBPF 기반 컨테이너 간 공격의 실행 예시

2.3 Limitations in eBPF Access Control

리눅스 커널 배포판에서 소켓 필터와 cgroup 프로그램은 특권이 있어야 함. 현재 eBPF access control 모델은 오직 하나의 permission만 지원함 -> CAP_SYS_ADMIN 이는 매우 위험한 권한이기에, linux 5.6 이상부터 eBPF 특권을 디커플링함. CAP_BPF를 사용함으로 bpf syscall 허용 가능. 그리고 bpf 프로그램 설치를 위해 CAP_PERFMON or CAP_NET_ADMIN 필요로 함. 이는 표에 나온 내용 방지 가능.

그러나 분할된 특권도 eBPF 기반의 DoS 공격 및 정보 훔침은 방지할 수 없음. 공격자는 여전히 eBPF 기반의 멜웨어 생성 가능. eBPF 사용 증가는 유저가 이상한 eBPF 프로그램 설치하는 리스크 상승시킴. eBPF 기반의 위험은 아직 이해 x. 몇 컨테이너 서비스는 실수로 eBPF 퍼미션 허용 가능. 다양한 이유로 ..(파일 시스템 등) 현재의 eBPG 퍼미션 모델은 신뢰x eBPF 프로그램(오용 혹은 공격적인)을 막을 수 없다. 우리는 기능 억제/새로운 권한을 통해 문제 해결하려 함.

3 Threat Model

환경 가정은 다음과 같다.

컨테이너 환경
sidecar 컨테이너에서 eBPF 프로그램 트레이싱(kprobe) 실행하고, CAP_SYS_ADMIN 있다고 가정. (현재 CAP_BPF거의 사용 x)

Appendix

A. eBPF Offensive Features

eBPF를 통해 커널 상태, 네트워크 패킷 수정, user space 프로그램을 변경할 수 있을 뿐만 아니라, 특정 eBPF 기능은 공격자들에 의해 오용당하면 Linux 호스트와 컨테이너에 위험하다. 소켓 필터와 cgroup 등의 일반 eBPF 프로그램 (CGROUP_SKB)은 권한이 필요없는데 소켓 패킷을 사용자 공간으로 복사하기 위한 필터 규칙 설정만 설정하고, 시스템을 변경하지 않기 때문이다. 그러나 대부분 리눅스 배포판은 비특권 사용자가 eBPF의 커널 취약점을 악용하지 못하도록 이러한 기능을 비활성화함. 다른 eBPF 프로그램 타입은 모두 권한이 필요하고, 오직 특권 유저만 사용할 수 있다. 그들은 커널 정보 획득, network data path 관리, 다른 프로세스에 영향을 주는 공격적인 작업을 수행할 수 있다.

eBPF XDP and TC Program : eBPF XDP와 TC(Traffic Control) 프로그램은 패킷 드랍,패킷 리다이렉트, 패킷 수정과 같은 패킷 프로세싱을 위해 네트워크 인터페이스에 사용됨. 이러한 기능들은 네트워크 연결을 가로채기 때문에, 유저 공간의 프로세스에 영향을 준다. 이는 컨테이너에서 실행되기에, 그들은 호스트나 다른 컨테이너에 접근할 수 없다.

eBPF LIRC Program : eBPF LIRC 프로그램은 eBPF를 통해 맞춤형 적외선 디코딩 혹은 인코딩 확장을 구현할 수 있다. 이 기능을 통해 공격자들은 키보드 이벤트를 주입할 수 있다. 다행히도 이는 대부분 리눅스 배포판에서 비활성화 되어 있다.

eBPF LSM Program : 과거에 LSM 훅은 리눅스 커널 모듈을 통해 설치될 수 없었다. eBPF LSM 프로그램은 LSM 훅을 설치하는 새로운 방식을 소개하고, access control을 정의하고, eBPF 코드를 통해 정책을 설정한다. 이러한 기능은 컨테이너 내부에서 다른 컨테이너와 호스트를 포함하는 전체 커널을 관리하기 위해 사용될 수 있다.

eBPF KProbe/KretProbe and Tracepoint Program(tracing-features) : eBPF KProbe/Tracing 프로그램은 특정 시스템 콜 혹은 커널 함수에에 붙을 수 있고, 프로세스에 의해 호출되는 모든 시스템 콜 혹은 함수에 트리거되어진다. 이러한 프로그램은 외부 프로세스에 cross-container affect이 가능한 eBPF 헬퍼 함수를 제공한다.

eBPF UProbe : eBPF UProbe 프로그램은 유저 스페이스 공간에 훅을 설치하는 것을 가능하게 한다. 그러나 프로그램의 바이너리 파일으로부터 심볼을 얻어야 하기 때문에 이는 컨테이너 내부의 프로세스에만 훅을 걸 수 있다.

B. Detailed Exploits for Local Containers

B.1 Dos Attack

SEC("raw_tracepoint/sys_enter")
int tp_enter(struct bpf_raw_tracepoint_args*ctx) {
  if (!is_target_process()) {
    bpf_send_signal(SIGKILL);
  }
  return 0;
}

D1: Killing process by sending signals

위 코드를 통해, 악의적인 eBPF tracing 프로그램은 컨테이너 밖의 임의의 프로세스가 eBPF 훅을 트리거하는 상황에서 그 프로세스를 죽이기 위해 SIGKILL 시그널을 보낼 수 있다. 이 시그널은 커널으로부터 수신되고, 루트 유저 권한 아래에 프로세스는 종료된다.

D2: Abusing LSM rules to crash processes

eBPF LSM 서브시스템은 사용자가 다양한 LSM 훅에 eBPF 프로그램을 붙이는 것을 허락하여, 파일, 프로세스, 네트워크 에 대한 권한 체크를 할 수 있게 한다. LSM 훅이 있는 커널 함수가 호출되면, 커널은 해당 LSM 훅에 연결된 eBPF 프로그램을 실행하여 현재 함수 호출이 허용되는지 여부를 결정한다.

D3: Altering system call arguments or return code

iago Attack : 악의적인 커널이 시스템 콜 반환 값을 조작하여 보호된 프로세스가 자기 이익에 반하는 동작을 유도하는 공격

iago Attack과 유사하게 피해자 프로세스의 시스템콜 인수가 시스템 콜에 들어가거나 나올 때, eBPF Tracing program에 의해 수정 가능함. 공격자는 유효하지 않은 시스템 콜 인수를 통과시킴으로 프로세스를 기능적으로 방해 가능. 게다가 악의적인 eBPF tracing 프로그램은 커널의 에러 주입 기능을 악용 가능한데, 이를 통해 그들의 리턴 값을 변경함으로써, 이는 피해자 프로세스가 어떤 시스템콜을 부르는 것을 막음.

B.2 Information Theft Attack

SEC(“raw_tracepoint/sys_exit”)의 의미

B.3 Container Escape Attacks

먼저 공격자는 자신의 로컬 환경에서 ROP 공격에 필요한 가젯의 위치를 분석한다. 즉 offset을 얻는다. 이제 피해자의 libc.so의 base 주소만 알면, offset을 알기 때문에 gadget을 실행할 수 있다. 이후 공격자는 read system call을 통해 피해자의 스택에 ROP 페이로드를 작성할 수 있다. syscall을 읽은 후 리턴한 프로그램에서 ROP Payload가 트리거된 후, 악성 커맨드가 실행된다. 즉 공격자는, eBPF 프로그램으로 시스템 콜을 감지하고, 이를 통해 libc 라이브러리의 base address를 획득한 후, 악성 페이로드를 삽입한다. 이를 통해 컨테이너 escape를 수행하는 것이다.

E3: Shellcode injection during mprotect system call

최신 리눅스의 NX(Non-eXecutable) 보호 기법 하에서도 여전히 쉘코드 공격이 실행 가능하다. 일부 프로그램은 실행 중, 메모리의 실행/쓰기 속성을 변경해야 할 필요가 있다. 예를 들어 node.js/chrome와 같은 프로그램이 예시인데, 이들은 JIT 컴파일을 통해 바이너리 코드를 힙에 저장하고, 런타임 동안 실행 가능하게 변경된다. 또한 UPX 패커 프로그램도 메모리 안에 있는 실제 프로그램을 언패킹 후, 쓰기 메모리 영역을 오로지 실행 가능만 하도록 변경해야 한다. eBPF 프로그램의 도움과 함께, 우리는 메모리가 쓰기 전용에서 실행 전용으로 변경되기 이전에 , 쉘코드를 삽입하는 타이밍을 포착할 수 있다. 메모리 속성은 mprotect 시스템 콜에 의해 변경되므로, 모든 프로세스의 mprotect 시스템 콜에 후킹하는 eBPF 트레이스포인트 프로그램을 사용할 수 있으며, 이를 통해 메모리가 읽기 전용으로 변경되기 전에 쉘코드를 주입할 수 있다. 만약 영향을 받는 프로세스가 루트 유저에 의해 실행된다면, 공격자는 이 루트 프로세스를 하이재킹함으로, container escape가 가능하다.

E4: Forging credentials to login as root via SSH

sudo와 ssh 패스워드 증명은 접근 제어 설정을 읽을 필요가 있다. 공격자는 프로세스의 read 시스템 콜을 하이재킹함으로 파일을 위조할 수 있을 뿐만 아니라, 가짜 비밀번호를 삽입할 수 있다. 따라서 sudo와 ssh는 속여지고, 공격자는 호스트에 로그인을 하거나, root를 가짜 비밀번호로 변경할 수 있다. 비록 공격자가 컨테이너 안의 루트 퍼미션을 가지고 있다 하더라도, 그들은 real root 퍼미션을 가지기 위해 호스트에 로그인해야 할 필요가 있다. 따라서, 이 공격은 ssh 로그인을 위한 접근 가능한 호스트의 IP가 필요하다.

C Bypass the Defenders’ Kernel Modules

Time of check to time of use (TOCTOU)

방어자는 커널 모듈으로부터 많은 양의 tracing 메시지를 받는다. cpu 사용량을 줄이기 위해, 방어자는 일반적으로 메시지를 주기적으로 처리하고, 스캔 이후 다른 OS 태스크가 작업하도록 양보한다. AliYunDun은 6초마다 한 번씩 스캔한다. 로그 버퍼 (trace pipe, eBPF 링버퍼 맵, perf events)가 다 차면, 기존의 로그는 새로운 로그로 덮어써진다. 공격자는 AliYunDun이 트레이스 pipe (로그)를 다 읽고, 로그를 체킹한 이후 공격을 수행할 수 있다. 이를 위해 먼저, 로그 버퍼를 다 뒤엎는 다수의 정상 행위를 생성한 후, bpf를 호출하여 악성 eBPF 프로그램을 로딩하는 등.. 악성 행위를 수행한다. 메시지가 사라졌기 때문에, 이러한 민감 이벤트들은 방어자에 의해 무시당한다.

Hook Order Interference Attack

그림 11과 같이, 공격자들은 같은 공간에서 defender의 hook 뒤에 자신의 hook을 설치할 수 있다. 방어자에 의해 체크된 이후 system arguments 침해를 통해, 공격자들은 정상 프로세스에 악성 페이로드를 삽입할 수 있다. 실제로 공격을 숨기기 위해 체크 전 악성을 정상으로 변경하는 훅과, 체킹 후 이를 다시 악성으로 변경하는 두개의 훅을 사용할 수 있다. 이 공격은 KProbe나 Tracepoint 훅을 사용하는 대부분의 방어자에게 효과적이다. 같은 훅 포인트에서, 공격자는 RawTracepoint 훅을 설치할 수 있는데, 이는 방어자의 KProbe나 Tracepoint 훅 이전에 정의되는 훅이다. 그리고 방어자들의 훅 이후 트리거되는 같은 타입의 훅 또한 설치할 수 있다. 그러나 방어자가 RawTracepoint 훅을 사용한다면, 공격자는 방어자들의 훅 이전에 그들의 훅을 설치하기 위해, 방어자의 프로세스를 죽여야 한다. 이 공격은 시스템 콜 자체를 숨기는 것이 아닌, 시스템 콜 arguments를 숨기는 것이다. 따라서 방어자는 여전히 시스템 콜 시퀀스를 확인할 수 있다.

D Reasons for Insecure Container Configs

앞서 언급한 세 가지 불안전한 컨테이너 설정을 사용하는 근본적인 원인들을 추가로 살펴본다. 첫 번째로, 일부 컨테이너는 시스템 마운트나 네트워크 설정 변경과 같은 커널 수준의 작업을 수행하기 위해 커널 수준 권한이 필요하다. 구체적으로 telegraf는 다른 도커 컨테이너를 모니터링하기 위해 docker socket (docker.sock)을 필요로 하고, dynatrace/oneagent는 환경 자격 증명을 위해 특권 권한을 사용한다. 그리고 Docker in Docker (DinD)는 네트워크 설정을 위해 CAP_SYS_ADMIN을 활용한다. 두 번째로, 컨테이너를 고립 환경으로 만들기 위한 컨테이너 내부 보안 도구가 설치되고, 그들은 호스트 시스템에 접근해야 할 필요가 있다. 예를 들어 newrelic/nrsysmond는 New Relic’s free Linux Service Monitor를 실행하기 위해 특권 권한과 docker.sock을 요청한다. 셋째, 몇 컨테이너는 호스트 시스템의 이슈를 해결하거나 디버깅하기 위해 특권 권한이 필요하다. 예를 들어 Cross는 타겟 플랫폼이 Android arch_32bit일 때, 특권 컨테이너 안에서 빌드하는데, 이유는 특권 권한이 없는 도커는 thumb instructions와 toolchain을 지원하지 않기 때문이다. 그리고 빅 데이터 서빙 엔진 Vespa또한 perf를 위한 커널 감시용 특권 컨테이너가 필요하기 때문이다.

Canal Mesh: A Cloud-Scale Sidecar-Free Multi-Tenant Service Mesh Architecture