Git-Syncing 문제: 쿠버네티스의 명령어 주입 취약점 탐색
핵심 요약
Akamai의 연구원 토머 펠레드(Tomer Peled)는 잠재적인 명령어 주입을 허용하는 쿠버네티스의 사이드카 프로젝트 git-sync 에서 설계 취약점을 발견했습니다. 펠레드는 DEF CON 2024에서 이 리서치 결과를 발표할 예정입니다.
이 설계 취약점으로 인해 파드의 모든 파일( 서비스 계정 토큰 포함)의 데이터 탈취 또는 git_sync 사용자 권한으로 명령어 실행이 발생할 수 있습니다.
공격자가 이 취약점을 악용하려면 클러스터에 YAML 파일을 적용하기만 하면 되는데, 이는 낮은 권한으로 수행할 수 있는 작업입니다.
이 취약점은 모든 플랫폼(Amazon EKS[Elastic Kubernetes Service], AKS[Azure Kubernetes Service], GKE[Google Kubernetes Engine], Linode 등)의 기본 설치 쿠버네티스에서 악용될 수 있습니다.
이 블로그 게시물에서는 개념 증명 (PoC) YAML 파일과 잠재적인 영향을 보여주는 데모를 제공합니다.
이 설계 취약점에 대해 CVE가 지정되지 않았기 때문에 이에 대한 패치는 없으며 여전히 악용이 가능합니다.
쿠버네티스팀은 이러한 공격 기법에 대한 인식을 높이기 위해 이 리서치를 공유하도록 권장했습니다.
서론
쿠버네티스는 명령어 주입 취약점이 낯설지 않습니다. 2023년에만 일곱 개의 취약점이 발견되었으며 그중에는 자체적으로 발견한 취약점도 포함되어 있습니다. 입력 위생화 문제로 인해 Akamai는 부수적인 공격 기법을 더 깊이 조사하게 되었습니다. ‘이 공격 기법이 쿠버네티스의 메인 프로젝트에만 고유한 것인가? 아니면 더 널리 퍼져 있는 것인가?’ 취약점이 숨어 있을 수 있는 쿠버네티스와 관련된 몇 가지 사이드카 프로젝트가 있는데, 여기에는 git-sync가 포함됩니다.
git-sync 프로젝트는 CI/CD 솔루션을 통해 수동으로 변경하는 대신 포드와 git 리포지토리를 연결해 사이트 및 서버 간에 변경 사항을 자동으로 동기화하기 위한 것입니다. 예를 들어, 사용자는 이 기능을 사용해 nginx 포드를 통해 노출하려는 파일이 포함된 리포지토리와 nginx 포드를 연결할 수 있습니다.
이 블로그 게시물에서는 설계 취약점의 세부 사항, 이를 허용하는 쿠버네티스 소스 코드의 문제 및 몇 가지 방어 방법을 살펴봅니다. 또한 이번 발견에 대한 쿠버네티스의 대응 에 대해서도 논의할 것입니다.
공격 기법 세부 정보
git-sync 사용 페이지를 살펴보면 사용자가 필요에 따라 git-sync를 사용자 맞춤화할 수 있도록 가능한 한 많은 설정 매개변수를 지원한다는 것을 알 수 있습니다. 이는 공격자가 악용할 수 있는 잠재적으로 큰 공격표면을 허용합니다(그림 1).
쿠버네티스 프레임워크는 컨테이너 네트워크 인터페이스 설정부터 포드 관리, 심지어 비밀 처리에 이르기까지 기본적으로 모든 것에 YAML 파일을 사용하므로 YAML 내의 취약점은 매우 심각할 수 있습니다. 이 경우, 원격 리포지토리(또는 공격자)에 연결하기 위해 git-sync를 사용하는 포드를 생성할 수 있습니다.
그림 2는 git-sync로 포드를 배포하는 설정 YAML 파일의 예시입니다.
잠재적인 공격 기법으로 가장 눈에 띄는 두 개의 파라미터는 GITSYNC_GIT 와 GITSYNC_PASSWORD였습니다.
공식 git-sync 문서에 따르면, GITSYNC_PASSWORD_FILE 은 ‘ git 인증에 사용할 비밀번호 또는 개인 접속 토큰(github 문서 참조)을 읽을 파일 (--username 참조)입니다.‘라고 설명되어 있습니다. 이는 포드의 다른 파일 또는 accesstoken 데이터가 유출되었을 가능성을 의미합니다.
GITSYNC_GIT 는 (다시 공식 문서에서) ‘실행할 git 명령어(주로 테스트용으로 PATH 검색에 따라 다름)’입니다. 기본값은 "git"이며 이는 git 대신 실행할 바이너리를 선택해 클러스터에서 코드 실행에 사용할 수 있음을 의미합니다.
제안된 공격 체인
위의 정보를 염두에 두고 Akamai는 이론을 증명하기 시작했습니다. 공격자가 악용할 수 있는 몇 가지 공격 기법이 있다고 생각합니다.
은밀한 코드 실행
YAML 파일을 적용한 후, 방어자의 눈에는 git-sync가 원격 서버와 통신하는 것이므로 외부에서 통신하는 것이 신뢰할 수 있다고 가정하는 것이 합리적입니다. 따라서 공격자는 명령어 실행에 대한 보너스로 보안 조치를 우회할 수 있습니다.
그림 4는 git-sync 사용자로 XMrig 크립토마이너를 시작하는 잠재적 공격에 대한 POC입니다.
이제 네트워크 관리자가 기존 포드와 회사 네트워크 외부의 통신을 감사할 때, git-sync 사용자가 외부 서버와 통신하는 것을 보게 될 가능성이 높습니다.
데이터 탈취
편집 권한이 있는 공격자는 git-sync 배포를 편집해 GITSYNC_PASSWORD_FILE 매개변수를 변경하거나 추가해 포드의 아무 파일이나 가리키도록 할 수 있습니다. 이렇게 하면 git-sync가 다음번에 git 리포지토리에 연결할 때 인증 수단으로 파일을 전송하게 됩니다.
공격자가 git 리포지토리 위치도 수정하고 의사 리포지토리 서버를 설정하면, 다음에 포드 내에서 git-sync 프로세스를 배포할 때 GITSYNC_PASSWORD_FILE 매개변수의 파일을 포드에서 자신의 머신으로 전송합니다. GITSYNC_PASSWORD_FILE에 필요한 파일 경로나 권한에는 제한이 없습니다.
리스크가 높은 탈취는 상상하기 어렵지 않습니다. 다음을 고려해 보세요. 공격자는 이 기법을 사용해 포드의 접속 토큰을 가져올 수 있으며, 이를 통해 git-sync 포드로 가장해 클러스터와 상호 작용을 할 수 있습니다(그림 5).
공개와 쿠버네티스의 대응
Akamai는 원래 2023년 12월에 이번 발견을 쿠버네티스팀에 공개했습니다. 쿠버네티스 팀은 논의한 결과 YAML 편집이 권한이 높은 작업으로 간주 되므로 보안 임곗값을 넘지 않는 것으로 결정했습니다. 그러나 Akamai의 관점에서 볼 때, 포드에 대한 편집 작업은 권한이 있는 작업으로 간주되지만 이 기술을 사용하면 측면 이동이 여전히 가능합니다. 무결성 손실에 대한 우려도 있었습니다. 공격자는 마치 정상적인 git-sync 사용자처럼 정보를 훔칠 수 있습니다.
GITSYNC_GIT의 문제에 대해 쿠버네티스팀은 이러한 종류의 작업에 필요한 권한이 낮다는 것을 인정했지만, 낮은 권한의 작업이 유해한 행동으로 이어질 것이라고 생각하지 않았습니다. 그러나 Akamai는 설명한 설계 취약점으로 인해 공격자가 ID를 스푸핑하면서 명령어를 실행할 수 있으며, 클러스터에 대한 낮은 권한이 유해한 행동을 막는 유일한 장벽이라고 생각합니다. 이 공격 흐름은 클러스터에 사전 승인된 git-sync 통신이 있는 기업에서 특히 위험합니다.
두 경우 모두 쿠버네티스는 ‘관리자가 사용자에게 노출되는 표면 영역에 대해 신중하게 생각하도록 상기시키는 데 도움이 되므로’ 이 매우 가치 있는 리서치를 온라인으로 공유하도록 권장했습니다.
방어
이 블로그 게시물에 설명된 공격 기법은 쿠버네티스팀에서 취약점으로 간주하지 않으므로 이에 대한 패치는 없을 것입니다. 따라서 이러한 ‘기능’이 허용하는 공격표면을 줄이기 위해 몇 가지 잠재적인 방어 조치를 권장합니다.
첫째, 기업을 떠나는 통신, 특히 쿠버네티스 포드에서 발생하는 통신에 대한 모니터링을 강화하세요. 정밀성이 가능하다면 git-sync 포드에 더욱 주의를 기울이세요.
둘째, 어떤 명령어가 실행되고 있는지 확인하기 위해 git-sync 포드를 감사하는 것이 좋습니다. 이는 다음 명령어로 수행할 수 있습니다.
kubectl describe pod <git-sync-pod>
예를 들어, 그림 4에 표시된 크립토마이너에서 이 명령어를 실행하면, 특히 인자 값이 ‘git’이 아닌 경우를 탐지했을 때 빨간색 플래그가 발생하는 –git 인자를 볼 수 있습니다(그림 6).
이 감사는 일반적인 보안 관행이므로, git-sync 포드뿐 아니라 모든 포드에서 이 명령어를 실행하는 것이 좋습니다.
또한 Akamai는 제안한 공격 기법 중 하나를 탐지할 수 있는 OPA 룰을 작성했는데, 이 공격은 git 바이너리를 악성 페이로드로 대체합니다.
package kubernetes.admission
deny[msg] {
input.request.kind.kind == "<Deployment/Pod>"
path := input.request.object.spec.env.name
contains(path, "GITSYNC_GIT")
msg := sprintf("Gitsync binary parameter detected, possible payload alteration, verify new binary ", [path])
}
결론
이 블로그 게시물에서는 git-sync 쿠버네티스 사이드카 프로젝트에서 두 가지 공격 기법을 보여주었습니다. 두 가지 기법 모두 입력 위생화가 부족하기 때문에 사용자 입력 위생화에 대한 강력한 방어가 필요하다는 것을 강조합니다. 앞서 설명한 것처럼 이러한 쿠버네티스 위생화 문제는 git-sync에만 국한된 문제가 아닙니다.
방어자들은 기업 내 gitsync 사용자의 비정상적인 행동을 주의 깊게 살펴봐야 합니다. 이러한 공격 기법은 기업에 매우 큰 영향을 미칠 수 있으므로 인식을 높이고 보안 관리자가 잠재적 위험에 대해 알 수 있도록 돕는 것이 중요합니다.
Akamai Security Intelligence Group은 이와 같은 위협을 지속적으로 리서치하고 고객과 보안 커뮤니티 전반을 위해 보고서를 작성할 것입니다. 현재 진행 중인 리서치에 대한 실시간 업데이트를 확인하려면 Akamai Security Intelligence Group을 X (기존의 Twitter)에서 팔로우하세요.
결과에 대한 의견은 일치하지 않지만, Akamai는 쿠버네티스팀의 대응과 논의에 감사드립니다.