CVE-2025-1974 — IngressNightmare (ingress-nginx)

소개

이 문서는 Kubernetes용 ingress-nginx 구성 요소(validating admission controller)에 영향을 미치는 CVE-2025-1974 취약점에 대한 연구를 제공합니다.
CVE-2025-1974는 ingress-nginx 프로세스 컨텍스트에서 인증되지 않은 원격 코드 실행(RCE) 을 나타내는 치명적인 취약점(CVSS 3.1 9.8)입니다. 공격자가 pod 네트워크에 접근할 수 있거나(또는 validating webhook에 AdmissionReview를 전달할 수 있는 경우) 컨트롤러 pod에서 임의 코드 실행을 달성할 수 있으며, 이는 잠재적으로 Secrets 노출과 클러스터 탈취로 이어질 수 있습니다.

Ingress-nginx는 Kubernetes에서 가장 널리 사용되는 Ingress 컨트롤러 중 하나이며(수십 퍼센트의 클러스터에서 사용되는 것으로 추정됨) 따라서 이 취약점의 실질적 영향은 매우 큽니다. 설명, 기술 분석 및 공식 수정 권장 사항은 Kubernetes, Wiz 연구원들 및 여러 벤더 블로그를 통해 공개되었습니다.

보고서 목적

CVE-2025-1974를 단계별로 분석하고 write-up에 필요한 자료를 준비합니다:

자료 수집 및 구조화. 공식 advisories, 연구 write-ups, 벤더 분석을 수집하고 핵심 기술 세부 사항과 PoC 방향을 도출합니다.
취약점의 본질과 영향 이해. 근본 원인(root cause), 공격 체인 및 가능한 결과(RCE → Secrets 노출 → 클러스터 탈취)를 설명합니다.
CPE 및 구성 조건 식별. 취약점이 유효한 Kubernetes/ingress-nginx의 버전/패키지와 구성을 나열합니다.
랩에서 안전하게 테스트하기 위한 권장 사항과 대규모 점검 시 위험 최소화 방안을 제공합니다.

⚠️ 면책 조항

본 연구는 오직 교육 및 윤리적 목적으로만 수행되며 테스트/통제된 환경을 대상으로 합니다.
어떠한 경우에도 소유자의 서면 허가 없이 타인의 클러스터나 공개적으로 접근 가능한 인스턴스에 대해 익스플로잇/PoC를 실행하지 마십시오. 완전히 작동하는 "weaponized" PoC를 공개적으로 게시하면 악용 위험이 크게 증가합니다. 공개 부분에서는 safe-PoC와 방법론을 제시하는 것이 좋습니다. (공식 advisories와 벤더들도 익스플로잇 배포 시 주의를 강조합니다.)

CPE 및 구성 조건

cpe:2.3:a:kubernetes:ingress-nginx_controller:<version> — 취약한 ingress-nginx 버전 (advisories에 구체적인 버전이 명시되어 있음; 최종 게시 시 값을 업데이트하세요).
취약한 컨트롤러를 포함하는 공급업체/배포판:
- 지정된 패치 버전까지의 ingress-nginx를 사용하는 RKE2 / Rancher 배포판.
- 취약한 ingress-nginx를 사용하는 Harvester 버전 (벤더 KB에 특정 affected builds가 포함되어 있음).
- ingress-nginx가 별도로 설치된 사용자 클러스터(Helm chart/manifest) — chart/image 버전을 확인해야 함.

취약점이 유효한 구성 조건:

취약한 ingress-nginx 버전 (advisories에 명시된 릴리스/패치 이전). 정확한 버전 번호는 NVD 및 벤더 advisories를 참조하십시오.
Validating admission webhook이 pod 네트워크 외부에서 접근 가능한 경우 — webhook이 외부에서 접근 가능하면(예: 공개 endpoint, 공급자가 서비스를 잘못 노출한 경우) 익스플로잇이 원격으로 실행될 수 있습니다. Wiz 및 다른 연구원들은 수많은 공개 노출 사례를 지적했습니다.
NetworkPolicy / pod 네트워크 격리 부재: 공격자가 손상된 pod에서 클러스터 네트워크로 요청을 보낼 수 있다면, 이는 익스플로잇에 충분합니다.
Admission controller 앞의 추가 검증/ACL 부재: 추가 필터/ingress-proxy 인증은 위험을 줄일 수 있습니다.
ingress-nginx 컨테이너 내에 광범위한 권한과 Secrets 접근 권한을 가진 서비스 계정이 존재하는 경우 — 기본적으로 컨트롤러는 종종 광범위한 권한을 가진 serviceAccount를 마운트하며, 이는 성공적인 익스플로잇 시 영향을 증가시킵니다.

취약점 세부 정보

간단한 요약.
이 취약점은 Ingress-NGINX 컨트롤러의 Validating Admission Controller 구성 요소에서 발견되었으며, 이 구성 요소가 수신된 Ingress / AdmissionReview를 기반으로 임시 NGINX 구성을 생성하고 검증하는 방식과 관련이 있습니다. 처리 과정에서 컨트롤러는 nginx.conf를 생성하고 구성 검증(nginx -t)을 실행합니다. Ingress/AdmissionReview 필드의 살균(sanitization)이 충분하지 않을 경우, 공격자는 특수하게 준비된 조각을 주입하여 생성된 구성(config)에 포함시키고, 결과적으로 컨트롤러 프로세스 내에서 명령 실행, 즉 ingress-nginx pod에서의 원격 코드 실행(RCE)을 유발할 수 있습니다.

주요 기술적 사항

진입점. 컨트롤러의 validating webhook이 수신하는 AdmissionReview/Ingress 객체는 NGINX 구성 생성(annotation 필드, backend 설정 등 포함)을 위한 입력 데이터가 됩니다.
익스플로잇 메커니즘. 악의적으로 구성된 Ingress 또는 직접적인 AdmissionReview는 구성 템플릿/조각에 공격자가 제어하는 문자열을 주입할 수 있습니다. 이러한 nginx.conf를 검사/로드할 때 검증 프로세스(nginx -t) 및 이후의 구성 파일 작업은 컨트롤러 컨텍스트에서 임의 코드 실행, 파일 쓰기/실행 또는 명령 실행으로 이어질 수 있습니다.
필요 조건. 성공적인 익스플로잇에는 다음이 필요합니다: 취약한 ingress-nginx 버전; validating webhook에 AdmissionReview를 전달할 수 있는 능력(pod 네트워크 접근 또는 직접 네트워크 접근); NetworkPolicy, RBAC 제한 또는 추가 webhook 인증과 같은 보완 조치 부재. 일부 시나리오에서는 crafted AdmissionReview를 webhook에 직접 전송하여 Create/Update 권한을 우회할 수 있습니다.

admission

위험성 — 익스플로잇의 영향

성공적인 익스플로잇은 ingress-nginx 컨테이너에서 코드 실행을 가능하게 하며, 일반적으로 다음을 허용합니다:

컨트롤러의 serviceAccount 토큰을 획득하고 Kubernetes API에 접근;
접근 가능한 namespace의 Secrets 및 기타 기밀 정보 읽기;
클러스터 리소스 생성/수정 및 접근 범위 확대(권한 상승, lateral movement);
일부 경우 클러스터 전체 탈취.

동작 및 탐지 관찰 사항

컨트롤러가 정상적으로 작동할 때 Admission Controller로의 요청 흐름은 일반적으로 없습니다. validating webhook는 클러스터 내부에서 작동하는 내부 구성 요소입니다. 익스플로잇 중에는 네트워크 맵(예: Luntry)에서 ingress-nginx-controller-admission 및 ingress-nginx-controller 서비스로 비정상적인 소스(보고서에서는 alpine과 같은 컨테이너)로부터의 수신 연결이 나타나는 변칙이 관찰되며, 이는 정상적인 작동 중에는 발생하지 않아야 합니다.
클러스터 네트워크 맵을 분석하면 마이크로서비스 간의 상호 작용을 파악할 수 있습니다. 네임스페이스에서 ingress-nginx Deployment를 선택하면 수신/발신 연결을 볼 수 있습니다. 공격 시점에 admission-endpoint로의 수신 연결이 나타나는 것은 명백한 침해 지표입니다.
익스플로잇 시도를 탐지하려면 다음을 모니터링하는 것이 유용합니다: validating webhook에 대한 POST 요청, 비정형 Ingress 객체 생성, nginx -t 호출 및 컨트롤러의 갑작스러운 재시작, 그리고 ingress-nginx 프로세스의 예기치 않은 파일 쓰기 작업.

맥락: NGINX Ingress 컨트롤러란 무엇이며 왜 중요한가

Ingress-NGINX는 Kubernetes에서 가장 널리 사용되는 Ingress 컨트롤러 중 하나입니다(서비스에 대한 외부 접근을 구성하는 데 널리 사용됨). 이 컨트롤러는 리버스 프록시 역할을 하며, 일련의 Ingress 규칙을 기반으로 외부 트래픽을 수신하여 해당 Service/Pod로 프록시합니다. Ingress-NGINX 프로젝트는 매우 인기가 높으며 인터넷에 노출된 클러스터에서 상당한 설치 비중을 차지합니다.

Ingress-NGINX는 Kubernetes 문서에서 Ingress 컨트롤러의 표준 예로 제시됩니다. 추정에 따르면 공개된 클러스터의 상당 부분이 이를 사용하며, 일부 연구에 따르면 공개적으로 접근 가능한 클러스터의 약 41%가 Ingress-NGINX를 사용합니다. 광범위한 보급과 트래픽 라우팅에서의 핵심 역할 때문에 이 구성 요소의 취약점은 실질적 영향이 매우 큽니다.

Validating webhook이 매력적인 공격 벡터가 되는 이유

기본적으로 컨트롤러의 validating webhook는 Kubernetes 네트워크 공간 내에서 접근 가능하며, 해당 주소(예: validate.nginx.ingress.kubernetes.io)로 요청할 때 추가 인증이 필요 없는 경우가 많습니다. 따라서 클러스터 내부에서 접근하기 쉽습니다.
조합: 컨트롤러의 광범위한 보급 + 네트워크 접근 가능성 + 잠재적으로 광범위한 서비스 계정 권한 = 효과적인 침해 경로를 제공하는 치명적인 조합입니다.
실제로 클러스터에 대한 "첫 번째 진입점"을 확보하는 것은 그리 어렵지 않습니다. 애플리케이션에는 개별 컨테이너를 손상시키는 취약점이 자주 존재하며, 공격자는 해당 컨테이너에서 내부 webhook에 접근할 수 있습니다. 또한 웹 애플리케이션의 악용 가능한 SSRF 유형 취약점은 클러스터 네트워크 내부로 요청을 시작하고 이러한 webhook를 활용하는 데 자주 사용됩니다.

익스플로잇 체인 요약 (개요)

공격자는 pod 네트워크로 요청을 보내거나 validating webhook에 직접 접근할 수 있는 능력을 확보합니다.
특정 필드에 적절한 필터링을 거치지 않은 악성 문자열이 포함된 특수하게 crafted된 Ingress / AdmissionReview가 구성됩니다.
컨트롤러는 이러한 입력을 기반으로 nginx.conf를 생성하고 nginx -t / 기타 검증 작업을 실행합니다.
주입된 조각은 컨트롤러 프로세스 컨텍스트에서 명령/스크립트 실행 또는 파일 쓰기/실행으로 이어집니다.
코드 실행에 성공하면 공격자는 serviceAccount 토큰을 추출하고 Kubernetes API에 접근하여 클러스터 내 이동과 권한 상승을 계속합니다.

다른 취약점과의 연계 관련 참고 사항

이러한 취약점은 다른 결함과 결합될 때 특히 위험합니다. 손상된 pod(또는 공개 애플리케이션의 SSRF) + 노출된 validating webhook는 전체 시스템을 완전히 장악할 높은 확률을 제공합니다. 따라서 인시던트 분석은 ingress-nginx 버전뿐만 아니라 의존성 체인과 잠재적 벡터를 고려해야 합니다.