격리 불가: 쿠버네티스의 명령 주입 취약점 발견
편집 및 추가 설명: 트리샤 하워드(Tricia Howard)
핵심 요약
최근 Akamai 보안 연구원 토머 펠레드(Tomer Peled)는 쿠버네티스에서 CVSS 점수 8.8로 CVE-2023-3676이 부여된 심각한 수준의 취약점을 발견했습니다.
이후 안전하지 않은 함수 호출과 사용자 입력 위생화 부족이라는 동일한 근본 원인을 공유하는 두 가지 취약점이 추가로 확인되었습니다.
이 취약점을 악용하면 쿠버네티스 클러스터 내의 모든 Windows 엔드포인트에서 SYSTEM 권한으로 원격 코드를 실행할 수 있습니다. 공격자가 이 취약점을 악용하려면 클러스터에 악성 YAML 파일을 적용해야 합니다.
이 취약점은 쿠버네티스의 기본 설치에서 악용될 수 있으며, 온프레미스 배포와 Azure Kubernetes Service 모두를 대상으로 테스트되었습니다.
Akamai는 이 취약점을 차단하기 위한 개념 증명(PoC) YAML 파일과 OPA 룰을 제공합니다.
서론
YAML(YAML Ain't Markup Language)은 주로 설정 파일에 사용되는 JSON과 유사한 데이터 직렬화 언어입니다. 따라서 기업이 컨테이너화된 애플리케이션의 배포, 확장, 관리를 자동화할 수 있도록 지원하는 새로운 유비쿼터스 컨테이너 오케스트레이션 시스템인 쿠버네티스에서 상당히 중요한 역할을 합니다. 쿠버네티스 프레임워크는 컨테이너 네트워크 인터페이스 설정부터 포드 관리, 심지어 비밀 처리에 이르기까지 기본적으로 모든 프로세스에 YAML 파일을 사용합니다.
쿠버네티스의 YAML 파일은 최근 몇 년간 리서치 대상이었습니다. 쿠버네티스의 클러스터 설정이 YAML에 의존한다는 점을 고려할 때, 특히 깊이 살펴볼 만한 주제입니다.
이전에는 YAML과 쿠버네티스가 어떻게 악용되었나요?
2022년, YAML 파일의 파서로 알려진 SnakeYAML의 생성자 내부에서 CVE-2022-1471이 발견되었습니다. 이 취약점으로 인해 안전하지 않은 오브젝트를 생성할 수 있었고, 이를 사용하는 취약한 애플리케이션에서 코드가 실행될 수 있었습니다. YAML 파일이 미칠 수 있는 영향을 보여주는 또 다른 예는 쿠버네티스 보안 팀에서 작성한 CVE-2021-25749에 대한 CVE 권고에서 확인할 수 있습니다. 이 취약점을 통해 공격자는 YAML 파일의 이름 철자를 잘못 입력하는 방법으로, 루트 실행 권한이 있는 사용자에 대한 검증을 우회할 수 있습니다.
쿠버네티스에 대한 리서치의 일환으로 CVE-2017-1002101 과 CVE-2021-25741을발견했습니다. 이 취약점들은 공격자가 경합 조건과 symlink를 YAML 파일의 subPath 하위 속성과 함께 이용해 컨테이너 외부의 권한 있는 데이터에 접속하는 방법을 보여주었습니다.
이러한 과거의 취약점을 통해 쿠버네티스 코드베이스에서 경로 처리의 방향을 모색하게 되었고, 결국 오늘 논의하는 취약점을 발견하게 되었습니다.
이 블로그 게시물에서는 ‘적용’ 권한(쿠버네티스 API와 상호 작용하는 데 필요한 권한)을 가진 공격자가 시스템 권한을 가진 원격 Windows 시스템에서 실행될 코드를 어떻게 삽입할 수 있는지 보여드리겠습니다.
취약점 세부 정보
팟(pod)이 생성되면 사용자는 팟과 호스트 간에 공유 디렉터리를 생성할 수 있습니다. 이 기능은 볼륨이라 불리며, 팟의 컨테이너를 통해 웹 사이트를 서비스할 때 유용합니다. 호스트와 공유되는 디렉터리에서 사이트 파일을 공유하고 싶을 때 이 방법을 사용하면 사이트 레이아웃을 원하는 대로 변경할 수 있고, 사이트가 포함된 이미지를 매번 다시 컴파일하지 않아도 됩니다.
볼륨 활성화는 팟의 YAML 파일에 볼륨 매개변수를 포함하면 됩니다. 볼륨을 마운트할 위치는 mountPath (컨테이너 내 위치)와 hostPath (호스트 내 위치)에 나열됩니다.
가장 중요한 것은subPath 하위 속성을 사용해 선택한 위치에 공유 디렉터리나 파일을 마운트할 수 있다는 것입니다. 그림 1에서 볼륨에 관한 모든 속성을 볼 수 있습니다.
그림 1: YAML 볼륨 설정
YAML 파일의 구문 분석은 노드에서 컨테이너화된 애플리케이션의 실행을 담당하는 쿠버네티스의 중앙 서비스인 kubelet에 수행됩니다. CVE-2021-25741에 대한 패치의 일환으로, kubelet은 YAML 파일의 모든 매개변수의 유효성을 검사하고 내부 함수 “isLinkPath"를 호출해 subPath 매개변수 사용으로 인해 symlink가 생성되지 않도록 합니다. 이 함수는 그림 2에 표시되어 있습니다.
그림 2: symlink 경로를 확인하는 subpath 함수
이 함수는 사용자가 YAML 파일에서 제공한 하위 경로를 매개변수로 받습니다. 그런 다음 이 경로를 사용해 경로 종류(즉, symlink인지 아닌지)를 결정하기 위한 PowerShell 명령을 만듭니다. 그런 다음 형식이 지정된 PowerShell 명령은 “exec.Command" 함수 호출에 의해 즉시 호출됩니다.
정제되지 않은 사용자 제공 입력과 결합된 “exec.Command”의 존재는 명령 주입 기회를 강력히 암시합니다.
PowerShell에서는 사용자가 문자열 내부 값을 사용 전에 평가할 수 있습니다. 이 작업은 문자열에 $(<experssion_to_be_evaluated>)를 추가해 수행할 수 있습니다(그림 3).
PS> echo “the value of 1+1 is $(1+1)
Output:
the value of 1+1 is 2
그림 3: 문자열 내에서 표현식을 평가하는 PowerShell 예제
이 예제는 매우 간단하지만 실제로는 괄호 사이에 모든 PowerShell 명령, 즉 $(Start-Process cmd), $(Invoke-Expression exp), 기타 PowerShell 처리 등이 삽입될 수 있습니다.
공격자는 이 하위 경로 평가를 악용해 취약한 코드에 도달하고 원격 노드에서 SYSTEM 권한 (kubelet의 자체 컨텍스트)으로원하는 명령을 실행하여 클러스터의 모든 Windows 노드를 제어할 수 있습니다. 그림 4는 악성 하위 경로 값을 보여줍니다.
그림 4: subPath 매개 변수 내에 명령 주입이 있는 YAML 파일
패치 분석
쿠버네티스 팀은 사용자 입력 대신 환경 변수에서 매개변수를 전달하는 방식으로 이 취약점 클래스를 패치하기로 했습니다(그림 5). 이러한 방식으로 값을 전달하면 매개변수가 문자열로 취급되므로 PowerShell에서 표현식으로 평가되지 않습니다.
그림 5: CVE-2023-3676의 패치된 함수
모든 쿠버네티스가 취약한가요?
위에서 언급했듯이, 1.28 이하의 모든 쿠버네티스 버전은 이 CVE에 취약합니다. 클러스터의 노드 중 하나가 Windows 노드인지 확인하는 방법에는 여러 가지가 있습니다. 한 가지 방법은 그림 6의 명령을 실행하는 것입니다.
kubectl get nodes -o wide --show-labels | grep “os=windows” 출력: akswin000000 Ready agent 4d17h v1.26.6 agentpool=win,beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=windows… akswin000001 Ready agent 4d17h v1.26.6 agentpool=win,beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=windows… |
그림 6: 클러스터의 노드 중 하나가 Windows 노드인지 확인하는 kubectl 명령
방어
패치는 이 취약점으로부터 여러분을 보호하기 위한 가장 신뢰할 수 있는 방법입니다. Akamai는 패치를 적용할 수 없는 경우를 고려해 이 취약점으로부터 보호할 수 있는 여러 가지 방법을 설명했으며, 사용자는 자신의 환경에 가장 적합한 방법을 선택할 수 있습니다.
이전 솔루션
CVE-2023-3676의 경우, 쿠버네티스 관리자는 Volume.Subpath사용을 비활성화할 수 있습니다. 이렇게 하면 클러스터가 이 취약점으로부터 안전하지만, 프로덕션 클러스터에 중요한 메커니즘이 비활성화되는 경우가 발생하기도 합니다.
OPA
OPA(Open Source Agent)는 사용자가 노드에 들어오고 나가는 트래픽에 대한 데이터를 수신하고 수신된 데이터에 대해 정책 기반 조치를 취할 수 있도록 하는 오픈 소스 에이전트입니다. OPA는 엔진의 언어로 Rego를 사용하며, 관리자는 이를 통해 특정 YAML 파일의 구축을 차단하는 룰을 생성할 수 있습니다. 그림 7은 악성 하위 경로를 가진 팟의 생성을 거부하는 룰을 보여줍니다.
package kubernetes.admission
deny[msg] {
input.request.kind.kind == "Pod"
path := input.request.object.spec.containers.volumeMounts.subPath
not startswith(path, "$(")
msg := sprintf("malicious path: %v was found", [path])
}
그림 7: 그림 7: 악성 하위 경로를 가진 팟 생성을 차단하는 룰
RBAC는
사용자가 누구인지에 따라 사용자 작업을 세그멘테이션하는 방법입니다. 예를 들어, 각 사용자는 자신의 네임스페이스에서만 팟를 생성하거나 허용된 네임스페이스에 대한 정보만 볼 수 있습니다. 이렇게 하면 클러스터에서 작업을 수행할 수 있는 사용자 수를 제한하고, 악용할 수 있는 관련 권한이 있는 사용자에게 주의를 집중하는 데 도움이 될 수 있습니다.
결론
CVE-2023-3676은 낮은 권한을 요구하기 때문에, 공격자가 이용하기도 쉽습니다. 즉 노드에 접속하고 권한을 적용하기만 하면 됩니다. 이 블로그 게시물에서 설명했듯이, 이 취약점을 성공적으로 악용하면 시스템 권한이 있는 컴퓨터의 모든 Windows 노드에서 원격으로 코드를 실행할 수 있게 됩니다.
영향력이 크고 악용이 쉽기 때문에 기업에서 이 공격(및 유사한 공격)을 받을 가능성도 높을 것입니다. 사실 이 취약점의 유일한 제한 요소는 그 범위인데, 오늘날 그다지 인기가 없는 Windows 노드로 제한되어 있습니다.
관리자는 이러한 취약점이 악용되는 것을 방지하기 위해 가능한 최신 버전으로 쿠버네티스 클러스터를 패치해야 합니다. 즉시 패치를 적용할 수 없는 경우, 위에서 설명한 방법 중 하나를 사용해 이 취약점을 방어할 것을 권장합니다.
Akamai는 매우 신속하게 대응하고 원활하게 소통해 주신 쿠버네티스 팀에 감사의 말씀을 드립니다.
공개 타임라인
2023/07/13 - 쿠버네티스 팀에 취약점 공개
2023/07/19 - 쿠버네티스 팀에서 CVE 지정
2023/08/23 - 쿠버네티스, CVE 수정 사항 배포
2023/09/13 - 블로그 게시
