ingress-nginx 에서 새로 발견된 인젝션 지점 셋과 하지 말아야 할 조치

[관점]

국내에서 관리형 쿠버네티스를 쓰는 조직은 인그레스 컨트롤러도 사업자가 관리한다고 전제하는 경우가 있다. 책임 공유 모델상 워커 노드 위에 직접 배포한 컴포넌트는 사용자 영역이다.

그래서 패치에 앞서 계약서와 아키텍처 문서에서 이 경계가 어디인지부터 확인해야 한다. 완화 조치만 해 두고 패치를 미루는 선택은 아직 알려지지 않은 인젝션 지점 앞에서 무력하다는 점도 함께 짚어 둘 필요가 있다.

들어가며

Wiz 가 처음 IngressNightmare 를 공개했을 때, 이들은 쿠버네티스에서 널리 쓰이는 ingress-nginx 컨트롤러에서 발견된 일련의 취약점 체인(CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, CVE-2025-1974)을 드러냈다. 인증되지 않은 공격자가 ingress-nginx 파드 내부에서 완전한 원격 코드 실행(RCE)으로 권한을 상승시킬 수 있으며, 이는 쿠버네티스 클러스터 전체의 침해로 이어진다는 것이 그 내용이었다.

조직이 새로운 공격 벡터를 이해하고 조치할 수 있도록 돕는 것이 Pentera Labs 의 임무인 만큼, 우리는 자체 랩 환경에서 이 CVE 들을 재현해 보기로 하였다. 그런데 놀랍게도, 최초 공개에서 다루지 않은 세 개의 추가 인젝션 지점을 금세 발견하게 되었다.

Wiz 팀이 초기의 무거운 작업을 감당하며 훌륭하게 판을 깔아 주었지만, 이번에 발견된 새 취약점들은 그와는 다른, 그리고 경각심을 주는 사실 하나를 드러낸다. 모든 공격 경로가 처음부터 알려져 있는 것은 아니다. 일단 공격자가 네트워크 내부에 들어오면, 내부 확산과 권한 상승을 위한 수많은 새로운 가능성이 그들 앞에 열린다. 그리고 공격자들이 그것을 탐색하고 찾아내려 할 것이라는 점은 확신해도 좋다.

대상 독자

보안 연구원 및 레드팀 — 새로운 공격 기법과 리서치 기법의 탐구에 참여한다
블루팀 — 잠재적 위협을 신속히 완화하고, 방어 체계를 검증하며, 공격 표면 전반에 걸쳐 견고한 보안 태세를 유지한다
DevOps — 안전한 쿠버네티스 운영 관행의 중요성을 이해하고, 자신들의 운영 관행이 유사한 취약점을 예방하도록 한다
CISO — 부상하는 위협에 대한 정보를 지속 파악하고, 조직에 미칠 잠재적 리스크를 이해한다

요약 — 새로 발견된 3개의 인젝션 지점

Wiz 의 리서치를 기반으로, Pentera Labs 연구진은 ingress-nginx 에서 다음 세 개의 인젝션 지점을 발견하였다.

**permanent-redirect 어노테이션** — 업스트림으로 데이터를 전송하는 대신 영구 리다이렉트를 반환할 수 있게 한다
**server-alias 어노테이션** — nginx 설정의 server 정의에 하나 이상의 별칭(alias)을 정의할 수 있게 한다
**rewrite-target 어노테이션** — 백엔드 서비스가 Ingress 경로와 다른 URL 을 기대하는 경우 요청 경로를 재작성할 수 있게 한다

쿠버네티스 측 제보 및 대응

Pentera Labs 에서 투명성, 책임 있는 취약점 공개, 그리고 더 안전한 생태계에 기여하는 것은 핵심 가치다. ingress-nginx 컨트롤러에서 기존에 문서화되지 않은 인젝션 지점 세 곳을 발견한 뒤, 우리는 2025년 4월 22일 쿠버네티스 프로젝트 팀에 책임 있는 방식으로 이를 제보하였다. 아울러 이 취약점들이 Wiz 가 발견한 결함에 대해 원래 배포되었던 동일한 패치(v1.12.1) 로 효과적으로 완화된다는 점도 함께 전달하였다.

쿠버네티스 팀은 우리의 제보를 확인하였고 조사할 시간을 요청하였다. 이후 한 달 가까이 여러 차례 후속 문의를 했음에도 추가 업데이트를 받지 못하였으며, 이에 우리는 별도의 지시가 없는 한 6월 9일에 조사 결과를 공개하겠다고 통보하였다.

우리는 이 리서치를 공개하는 것이 매우 중요하다고 판단한다. v1.12.1 패치를 적용한 조직이라면 이 취약점들로부터 보호되지만, 상당수의 팀이 우리가 식별한 추가 인젝션 지점의 존재를 모른 채 완화 조치에만 의존하고 있을 수 있다. 이런 조직들은 패치를 적용하지 않았다면 여전히 취약한 상태로 남아 있을 수 있다. 우리의 목표는 방어자들이 리스크의 전체 범위를 온전히 파악하고 그에 맞게 대응할 역량을 갖추도록 하는 것이다.

자사 해당 여부

조직이 1.12.1 이전 버전의 ingress-nginx 를 사용하고 있다면 영향을 받을 수 있다.

영향

공격자가 이 취약점들을 악용하면 애플리케이션이 오픈 리다이렉트(open redirect), 호스트 헤더 스푸핑(host header spoofing), 경로 조작(path manipulation) 취약점에 노출될 수 있다. 보안이 미흡하거나 멀티테넌트로 운영되는 환경에서는, 공격자가 라우팅 규칙을 우회하거나, 사용자를 악성 사이트로 리다이렉트하거나, 의도하지 않은 백엔드 서비스에 접근하는 것이 가능해질 수 있다.

완화 방안과 금지 사항

이 취약점들을 완화하는 최선의 방법은 ingress-nginx 를 최신 버전(1.12.1 이상)으로 업데이트하는 것이다. Wiz 가 발견한 인젝션 벡터와 우리가 새로 밝혀낸 벡터 모두 이후 버전에서 패치되었다. 따라서 nginx 를 업데이트하는 것만으로 우리가 시연한 모든 기법으로부터 보호받을 수 있다.

한편, 보안팀에게 밸리데이션 웹훅(validation webhook)을 삭제하라고 안내하는 조치 권고를 여러 곳에서 보았다. 이는 이 취약점들이 어드미션 웹훅이 외부에 노출되어 있다는 점에 의존한다는 사실에서 비롯된 발상이다.

그렇게 하지 말 것을 강력히 권고한다.

이 웹훅들은 잘못된 형식이거나 안전하지 않은 리소스 — 예컨대 위험한 Ingress 설정 — 가 API 서버에 의해 수용되지 않도록 막는 규칙을 강제한다. 웹훅이 없으면 사용자가 핵심적인 안전 검증을 우회할 수 있게 되고, 이는 다음과 같은 결과로 이어질 수 있다.

트래픽 오라우팅(misrouting)
내부 서비스 노출
나아가 클러스터 전체 침해

다시 말해, 어드미션 객체가 검증되지 않게 되어 클러스터가 위험에 방치된다.

앞서 언급한 대로, 권고되는 조치 방안은 ingress-nginx 를 버전 1.12.1 이상으로 업데이트하는 것이다.

보안팀에게 남는 과제

IngressNightmare 취약점 체인은 보안이 단지 CVE 를 패치하는 문제가 아니라는 점을 일깨우는 중요한 사례다. 오히려 보안은 공격자가 어떻게 사고하는지 이해하고, 그에 맞춰 자신의 환경을 지속적으로 테스트역할이다. 공격자는 공개된 정보에서 멈추지 않는다. 일단 환경 내부에 들어오면 그들은 탐색하고, 실험하고, 어떤 설정상의 허점이든 악용한다. 이번 신규 취약점 발견은 하나의 취약점이 얼마나 쉽게 클러스터 전체의 침해로 번질 수 있는지를 보여준다.

국내 적용 관점

첫째, 관리형 쿠버네티스를 쓴다고 해서 ingress-nginx 까지 클라우드 사업자가 패치해 주지는 않다. EKS·GKE·NCP Kubernetes Service·KT Cloud 등 국내에서 많이 쓰이는 관리형 K8s 에서 사업자가 책임지는 범위는 통상 컨트롤 플레인이며, 워커 노드 위에 사용자가 직접 배포한 인그레스 컨트롤러는 책임 공유 모델상 사용자 책임 영역에 놓이는 경우가 일반적이다. 원문이 제시한 조치는 「ingress-nginx 를 1.12.1 이상으로 올릴 것」 단 하나이므로, 우선 자사 클러스터의 인그레스 컨트롤러가 누구의 책임으로 관리되고 있는지 계약서와 아키텍처 문서상 명확히 정리되어 있는지부터 확인해야 한다.

둘째, 헬름 차트로 한 번 설치한 뒤 버전을 방치하는 관행이 이번 건의 실질적 노출 원인이 된다. 인그레스 컨트롤러는 한 번 붙여 놓으면 트래픽이 정상적으로 흐르는 한 손댈 일이 없는 컴포넌트이고, 그래서 애플리케이션은 주 단위로 배포되는 조직에서도 인그레스 차트 버전은 도입 시점 그대로인 사례가 드물지 않다. 원문이 경계하는 지점도 정확히 여기이다 — 완화 조치만 해 두고 패치를 미룬 조직은 알려지지 않은 추가 인젝션 지점 앞에서 여전히 취약한다. 애플리케이션 배포 파이프라인과 별개로 플랫폼 컴포넌트의 버전 인벤토리와 갱신 주기를 별도로 관리할 것을 권한다.

관리형 쿠버네티스의 책임 경계 3층 Deloitte One Cyber & Resilience

셋째, 「클러스터 내부는 신뢰 구간」이라는 전제가 이 취약점의 파급력을 키운다. 원문은 공격자가 일단 내부에 들어오면 내부 확산과 권한 상승의 경로를 스스로 찾아낸다는 점을 반복해 강조한다. 국내에서도 클러스터 내부 통신은 mTLS 나 네트워크 폴리시 없이 평문·전면 허용으로 두고, 경계 방화벽에서만 통제하는 구성이 여전히 많다. 인그레스 컨트롤러 파드는 통상 광범위한 권한의 서비스 계정을 갖고 클러스터 전역의 Ingress 객체를 읽으므로, 이 파드 하나의 장악이 곧 클러스터 전반의 문제로 확대될 수 있다는 점을 리스크 평가에 반영해야 한다.

넷째, 조치 과정에서 어드미션 웹훅을 삭제하는 우회는 선택하지 말아야 한다. 원문이 별도의 절을 할애해 강하게 경고하는 부분이다. 국내 금융권처럼 망분리 환경에서 컨테이너를 도입하는 조직은 외부 이미지 레지스트리 접근이 제한되어 버전 업그레이드 자체가 변경관리 심의를 거쳐야 하는 경우가 많고, 그 지연을 메우려 웹훅 비활성화 같은 임시 조치로 넘어가려는 유인이 발생한다. 그러나 웹훅을 제거하면 잘못된 Ingress 설정에 대한 검증 자체가 사라져 트래픽 오라우팅과 내부 서비스 노출이라는 별개의 리스크를 새로 떠안게 된다. 폐쇄망 레지스트리에 1.12.1 이상 이미지를 선반영하는 절차를 변경관리와 병행해 설계하는 편이 안전하다.

출처 · Pentera (Pentera Labs), IngressNightmare Returns: 3 New Injection Points and How to Keep Attackers Out (2025-06-09, Ron Okopnik (Cyber Security Researcher, Pentera))