tabbysable/poc-2020-8558Kubernetes CVE-2020-8558에 대한 정보 및 개념 증명 익스플로잇 포함.
CVE-2020-8558은 kube-proxy가 예상치 못하게 로컬호스트 바인딩된 호스트 서비스를 네트워크상의 다른 노드에서 접근 가능하게 만들기 때문에 공개된 Kubernetes 취약점입니다. '예상치 못하게'라는 표현을 강조하는 이유는 이 취약점이 구현 결함(버그)이 아닌 설계 결함(누락)에 기인하기 때문입니다. 코드는 말 그대로 의도한 대로 작동하지만, 우리 모두 그 결정의 보안적 함의를 인식하지 못했습니다.
호스트 프로세스가 127.0.0.1(로컬호스트) 주소를 통해 NodePort 서비스에 접근할 수 있도록 하기 위해 kube-proxy는 net.ipv4.conf.all.route_localnet=1 sysctl 설정을 합니다. 커널 문서에 따르면, 이 설정은 커널이 "루프백 주소를 화성인(martian)으로 간주하지 않도록" 만듭니다. 그 결과 이러한 주소가 네트워크상의 다른 노드에서 접근될 수 있습니다. 이는 유일한 보호 수단이 로컬호스트에 바인딩된 것뿐인 민감한 인증되지 않은 서비스를 운영 중이라면 큰 문제가 됩니다.
이 글을 쓰는 현재, Kubernetes 커뮤니티는 CVE-2020-8558을 해결할 최선의 방법을 계속 연구 중입니다. 두 가지 확실한 선택지는 처음부터 route_localnet sysctl을 설정하지 않는 것이거나, iptables를 사용하여 부적절하게 라우팅된 localnet 패킷을 차단하는 것입니다. 후자의 전략을 사용한 수정 사항은 kubelet >= 1.18.4, 1.17.7 또는 1.16.11에서 이미 릴리스되었습니다. 아래에 링크된 이 CVE에 대한 Kubernetes 이슈를 참고하여 직접 적용할 수도 있습니다.
net.ipv4.conf.all.route_localnet=1 설정이 CVE ID를 받을 만한 이유는 무엇일까요? 주로 IP 네트워크에 대한 우리의 직관을 위반하기 때문입니다.
적어도 1989년의 RFC 1122 이후로, 로컬호스트 네트워크 127.0.0.1/8의 패킷은 특별하게 취급되어 "호스트 외부에 나타나는 것"이 금지되었습니다. (이보다 더 이른 127/8의 특수 속성 참조를 알고 계신다면 Twitter로 연락 주십시오.) 모든 RFC 준수 호스트는 본질적으로 127.0.0.1(및 해당 네트워크의 다른 IP — 한 번도 해보지 않았다면 127.127.127.127에 핑을 보내보세요!)에 바인딩된 서비스에 대한 외부 접근을 차단하는 암시적이고 제거할 수 없는 방화벽 규칙을 가지고 있습니다. 우리는 그 동작에 의존하고 기대하게 되었습니다. 우리는 인증이나 암호화 없이 민감한 서비스를 자주 실행하고, 안전을 위해 로컬호스트에 바인딩합니다. 예를 들어, 평문 HTTP 백엔드, Redis 키-값 저장소, 그리고 잔재물인 Kubernetes API 서버의 안전하지 않은 포트는 일반적으로 이러한 방식으로 침입으로부터 보호됩니다. 우리는 이 동작에 너무 익숙해서 IP 호스트가 무엇을 의미하는지에 대한 직관적인 감각에 깊이 각인되어 있습니다. 이러한 관점에서 볼 때, 많은 전문가들이 이 결함을 오랫동안 간과한 것이 이해할 수 있습니다.
어떻게 작동하나요?
IP 주소를 가진 모든 개체를 "노드"라고 부르겠습니다. IP 패킷은 패킷 헤더의 소스 및 대상 IP 주소로 식별되는 한 노드에서 다른 노드로 전송됩니다. 모든 IP 노드는 라우터(RFC1122에서는 게이트웨이)이거나 호스트입니다. 주요 차이점은 호스트가 다른 사람의 주소로 향하는 패킷을 수신하면 무시한다는 것입니다. 라우터는 라우팅 테이블을 참조하여 패킷을 최종 목적지에 더 가깝게 전달하기 위해 재전송(포워딩)합니다. 호스트는 로컬로 연결된 일부 노드에 대해 알게 됩니다. 다른 노드에 접근하려면 로컬로 연결된 라우터에 패킷을 보내야 합니다. 이러한 로컬 연결은 점대점(PPP 링크 또는 일부 가상 네트워크와 같은) 또는 공유 매체(이더넷과 같은)일 수 있습니다.
우편함은 집과 지역 우체국 사이의 점대점 링크로 개념화할 수 있습니다. 점대점 링크를 통해 패킷을 라우팅하려면 호스트는 올바른 대상 주소를 적용하고 패킷을 전송하기만 하면 됩니다. (이는 OSI 모델의 계층 3에서 발생합니다.) 공유 매체 링크를 통해 패킷을 라우팅하려면 호스트는 먼저 공유 매체를 가로지르는 가상 점대점 회로를 구성해야 합니다. 이더넷/IP 네트워크에서는 OSI 모델의 계층 2에서 ARP를 통해 수행됩니다. 기본적으로 ARP 패킷을 전송할 수 있다면 다른 호스트에게 "이봐, 내가 여기 있어"라고 말할 수 있고, 그 호스트는 믿게 됩니다. (이것이 부적절하게 수행될 때 ARP 캐시 중독이라고 합니다.) 그런 다음 패킷에 적절한 이더넷 소스 및 대상 주소를 넣어 통신할 수 있습니다.
정상적인 노드는 RFC 1122 때문에 대상 주소가 127.0.0.1인 패킷을 절대 전송하지 않습니다. 정상적인 노드가 대상 주소가 127.0.0.1인 패킷을 수신하면 역시 RFC 1122 때문에 무시(드롭)합니다. net.ipv4.conf.all.route_localnet=1을 설정하면 이것이 변경되어 127.0.0.1 패킷이 특별하지 않은 것처럼 전송 및 수신될 수 있습니다.
따라서 공격자가 net.ipv4.conf.all.route_localnet=1이 설정된 대상 노드에 로컬 연결을 가지고 있다면, 공격자는 대상 주소가 127.0.0.1인 패킷을 보낼 수 있고, 대상 노드는 127.0.0.1이 완전히 정상적인 주소인 것처럼 적절히 응답합니다. 오늘날 대상 노드에 로컬 연결을 가지는 가장 일반적인 두 가지 방법은 대상과 동일한 이더넷 네트워크(브로드캐스트 도메인)에 있거나, 대상에서 실행 중인 컨테이너가 되는 것입니다.
정상적으로 구성된 경우 Linux는 공격자 노드가 127.0.0.1을 대상으로 하는 일반 패킷을 전송하는 것을 허용하지 않습니다. 이는 공격자의 Linux 노드를 재구성하거나(raw 소켓을 사용하여 패킷을 위조함으로써) 우회할 수 있습니다. raw 소켓은 CAP_NET_RAW Linux 커널 기능만 필요하며, 이는 권한이 없는 컨테이너에 기본적으로 부여됩니다. 이는 공격자가 제어하는 권한 없는 컨테이너가 CVE-2020-8558을 악용할 수 있음을 의미합니다.
간단히 말해, kube-proxy를 사용하거나 net.ipv4.conf.*.route_localnet으로 영리한 일을 하고 있다면 노출된 것입니다. 위협 모델링에 시간을 투자하여 해당 노출이 자신에게 얼마나 위험한지 판단하고 적절한 완화 전략을 계획해야 합니다.
기본적으로 net.ipv4.conf.all.route_localnet=1이 설정된 모든 Linux 호스트는 취약합니다. 그 취약점이 공격자에게 흥미로운지 여부는 여러 요인에 따라 달라집니다:
CVE-2020-8558을 평가하려면 다양한 능력을 가진 공격자를 상상하고 해당 공격자의 관점에서 이러한 질문에 답해야 합니다. (Adam Shostack의 책 "Threat Modeling: Designing for Security"에서 이 과정을 자세히 설명합니다.) 반드시 고려해야 할 두 가지 관련 공격자는 이더넷 네트워크에 노드가 있는 공격자와, 호스트에서 권한 없는 파드에서 코드를 실행할 수 있는 공격자입니다. 환경과 필요에 따라 고려해야 할 다른 흥미로운 공격자가 있을 수도 있습니다.
설명을 위해 부분적으로 작업된 예시를 들어보겠습니다:
호스트는 두 공격자 모두 확실히 접근 가능합니다. 각 경우에 그렇게 가정했습니다.
패킷은 필터링될 수도 있고 아닐 수도 있습니다. 확인해야 합니다. 많은 클라우드 환경과 엄격하게 관리되는 온프레미스 네트워크에서는 IP 대상이 네트워크에서 예상하는 이더넷 대상과 일치하지 않으면 패킷이 차단됩니다. 이것만으로도 노드가 있는 공격자에게는 게임 오버가 될 수 있습니다. 모든 노드에 (업데이트된 kubelet이 제공하는 것과 같은) 적절한 로컬 방화벽 규칙이 있으면 두 공격자 모두 실패하게 됩니다.
생각보다 더 많은 흥미로운 서비스가 있을 수 있습니다. 분명히 Kubernetes API 서버의 안전하지 않은 포트는 매우 매력적인 대상이며, 가능하면 비활성화해야 합니다. 127.0.0.0/8 네트워크의 IP 주소에 바인딩된 모든 프로세스를 조사하십시오: 강력한 인증이 있습니까? 그렇지 않다면 CVE-2020-8558을 통해 노출될 수 있습니다. 모든 정상적인 로컬호스트 서비스가 안전하더라도 일시적인 서비스도 문제가 될 수 있습니다. 예를 들어 SSH 포트 포워딩은 일시적인 승인된 목적을 위해 네트워크 제한을 우회하는 데 자주 사용됩니다. 기본적으로 SSH 포워딩된 포트는 로컬호스트에 바인딩되어 임시 접근이 승인된 사용자에게만 허용됩니다. CVE-2020-8558을 사용하면 이러한 "안전한" 포트 포워딩도 공격자가 사용할 수 있게 됩니다.
대상과 동일한 브로드캐스트 도메인에 있는 Linux 박스에서 root 권한이 있다고 가정하면, 다음 구성 설정을 통해 CVE-2020-8558을 악용할 수 있습니다:
ip addr add 127.0.0.2/8 dev lo
ip addr del 127.0.0.1/8 dev lo
ip route add 127.0.0.1/32 via YOUR-TARGET-HERE
sysctl net.ipv4.conf.all.route_localnet=1
일부 중요한 서비스(예: systemd-resolved)가 127.0.0.0/8 주소에서 실행되므로, 호스트를 손상시키지 않기 위해 새 주소를 추가합니다. 그런 다음 호스트는 기본 127.0.0.1/8 주소를 잊어버려야 합니다. 다음으로, 커널에게 127.0.0.1에 대한 트래픽을 대상으로 전선을 통해 라우팅하도록 지시합니다. 대상은 127.0.0.1에 접근하는 방법을 알고 있습니다. 마지막으로, 그렇지 않으면 이 구성이 작동하지 못하게 하는 악명 높은 sysctl을 설정합니다.
Raw 패킷을 전송하여 CVE-2020-8558을 테스트하는 간단한 Python 스크립트입니다. 이것은 scapy 원라이너일 수 있지만, 약간 더 편리한 기능을 추가하고 싶었습니다. 대상 127.0.0.1로 패킷을 보내고 응답이 있는지 확인합니다.
일반 TCP 또는 UDP 클라이언트 응용 프로그램이 위조된 패킷을 통해 원격 로컬호스트 IP와 통신할 수 있도록 하여 CVE-2020-8558을 악용하는 Python 스크립트입니다. 이 스크립트를 실행한 후, 일반 TCP 또는 UDP 클라이언트(예: kubectl 또는 nc)를 사용하여 가짜 대상(기본값 198.51.100.1)에 연결합니다.
가짜 대상은 패킷에 절대 응답하지 않는 IP 주소여야 하며, 해당 주소로의 경로는 대상에 접근하는 것과 동일한 인터페이스를 통해야 합니다. 일반적인 경우, 가짜 대상과 대상 모두 기본 게이트웨이 인터페이스를 통해 접근 가능하며, 큰 문제가 되지 않습니다.
이 스크립트는 raw 소켓을 사용하여 "로컬호스트" 패킷을 송수신하므로, 일반적인 권한 없는 컨테이너 내에서도 잘 작동합니다.
이 CVE에 대한 Kubernetes GitHub 이슈
Ian Coldwater, Brad Geesaman, Duffie Cooley, Laurent Bernaille에게 감사 인사를 전합니다. 여러분의 생각, 조언, 그리고 웃음에 감사드립니다. 행성을 경적 울려라!