Kubernetes에서 권한 승격하여 OpenShift 제품 및 서비스의 중요한 데이터에 대한 액세스 허용 취약점 - CVE-2018-1002105

Public Date:
Updated -
Status
Resolved
Impact
Critical

kubernetes에서 권한을 상승시키고 OpenShift 제품 및 서비스의 중요한 데이터에 대한 액세스를 허용하는 보안 취약점이 발견되었습니다.   이 문제점은 CVE-2018-1002105 로 지정되어 있으며 심각한 보안 영향을 미치는 것으로 분류하고 있습니다.

OpenShift Container Platform의 모든 3.x 버전에서 공격자는 이 취약점을 악용하여 일반 사용자 권한 (다중 실행 컨테이너 인스턴스)으로 실행되도록 예약된 컴퓨팅 노드의 pod에 액세스할 수 있습니다.  이러한 액세스 권한에는 모든 비밀정보, pod, 환경 변수, 실행중인 pod / 컨테이너 프로세스 및 영구 볼륨에 대한 액세스가 포함됩니다.

또한 OpenShift Container Platform 3.6 이상 버전에서는 이 취약점으로 인해 집계된 API 서버에서 호스팅되는 모든 API에 대한 cluster-admin 수준의 액세스가 허용됩니다.  'metrics-service' 및 'servicecatalog' 모두 공격 대상에 포함됩니다. 서비스 카탈로그에 대한 Cluster-admin 수준의 액세스를 통해 관련 권한이 없는 사용자의 권한이 승격되어 모든 네임스페이스와 노드에서 중개형 서비스를 만들 수 있습니다. 이로 인해 공격자가 악성 코드를 시스템에 배포하거나 기존 중개형 서비스를 변경할 수 있습니다.

OpenShift Dedicated 환경의 경우 pod exec/attach/portforward 권한을 갖는 일반 사용자는 해당 pod를 실행할 수 있는 모든 컴퓨팅 노드에서 cluster-level 관리 권한을 얻을 수 있습니다.  여기에는 실행중인 모든 워크로드, 현재의 모든 비밀 데이터, 로그 등에 대한 exec 액세스가 포함됩니다.   

배경 정보

OpenShift API 서버는 모든 OpenShift Container Platform 설치 환경에 포함되어 있으며 클러스터의 모든 관리 작업을 처리하는데 사용됩니다. 일반적으로 관리자와 개발자는 API를 직접 호출하지 않고 대신 API 서버를 호출하는 'oc' 바이너리를 사용합니다.

API 서버는 다음 oc 명령을 비롯한 다양한 기능을 제공합니다.

  • oc exec
  • oc port-forward
  • oc rsh

API 서버는 해당 기능을 구현하기 위해 컴퓨팅 노드에서 실행 중인 kubelet 에 대한 역방향 프록시 역할을 수행합니다. 위의 명령을 수행하기 위해 kubelet에 연결되면 websocket 연결을 열어 관리자 또는 개발자가 원래 호출에서 stdin, stdout 또는 stderr에 연결합니다. 보다 자세한 내용은 Remote Commands section of the OpenShift Container Platform 3.11 architecture guide에서 참조하십시오.

API 서버는 Kubernetes의 API 통합 기능을 구현할 때 역방향 프록시로도 작동합니다. API 통합을 사용하면 추가 API (Application Programming Interfaces)를 코어 API 서버에 설치할 수 있습니다. 이러한 추가 API는 업스트림 Kubernetes에서 API 확장이라고 합니다. API 확장을 통해 OpenShift Container Platform 3의 기능을 확장할 수 있습니다.

감사 인사

Red Hat은 이 보안 취약점을 보고해 주신 Kubernetes 제품 보안팀에 감사의 말씀을 전합니다. 업스트림에서 보안 취약점의 첫 번째 보고자인 Darren Shepherd에게도 감사의 말씀을 전합니다.

참고 자료

Kubernetes Announce List

동영상: Kubernetes Privilege Flaw Escallation Explained by Red Hat

블로그: The Kubernetes privilege escalation flaw: Innovation still needs IT security expertise

블로그: Understanding the critical Kubernetes privilege escalation flaw in OpenShift 3


영향을 받는 제품

Red Hat Product Security는 CVE-2018-1002105로 지정된 보안 이슈를 심각한 (Critical) 영향을 미치는 것으로 분류하고 있습니다.

다음의 Red Hat 제품 버전이 영향을 받습니다.

  • Red Hat OpenShift Container Platform 3.x
  • Red Hat OpenShift Online
  • Red Hat OpenShift Dedicated

공격 내용 및 영향

OpenShift API 서버는 OpenShift Container Platform 3 API 요청을 처리하는 구성 요소입니다. OpenShift API 서버는 'upgradeawarehandler'유형의 취약성이 있습니다. 이 유형은 컴퓨팅 노드 및 API 확장으로 추가된 다른 서비스에 대해 역방향 프록시 역할을 합니다. 역방향 프록시의 취약점으로 인해 오류가 발생했을 때 다운 스트림 서비스에서 연결을 닫을 수 없습니다. 이로 인해 사용자는 API 호출하여 권한을 상승시킬 수 있습니다.

이 취약점을 악용하여 OpenShift Container Platform, OpenShift Online 또는 OpenShift Dedicated를 공격하는 두 가지 방법이 있습니다. 첫 번째 방법은 일반 사용자에게 부여되는 pod exec, attach, portforward 권한을 악용하는 것이고 두 번째 방법은 OpenShift Container Platform 3.6 이상에서 서비스 카탈로그 및 추가된 새로운 기능에 액세스할 수 있는 API 확장 기능을 공격하는 것입니다.

사용자가 pod exec/attach/portforward 권한을 가지고 있는 경우 권한을 cluster-admin으로 상승시킬 수 있으며 컴퓨팅 노드 Kubelet API에 대한 API 호출을 실행할 수 있습니다. Kubelet API에 대한 API 호출을 통해 사용자가 호스트 파일 시스템에 대한 읽기/ 쓰기 액세스 권한이 있는 컨테이너를 포함하여 권한이 있는 pod와 동일한 노드에서 실행중인 컨테이너에 exec할 수 있게 합니다.

두 번째 공격은 권한을 필요로 하지 않고 OpenShift Container Platform, OpenShift Online, OpenShift Dedicated에서 'metrics-server'및 'servicecatalog'에 사용되는 API 확장 기능을 악용하는 것입니다. 인증되지 않은 사용자는 'servicecatalog'를 포함하여 클러스터에 배포 된 모든 API 확장에 대해 cluster-admin 권한을 얻을 수 있습니다. 'servicecatalog'를 사용하는 클러스터 관리자 액세스를 통해 모든 네임 스페이스와 노드에서 서비스 브로커를 만들 수 있습니다.  

취약점 진단

설치된 OpenShift Container Platform의 버전을 확인하려면 다음과 같이 API 서버에 http 요청을 보냅니다 (참고 : URL은 웹 콘솔 URL과 동일함)

   curl https://openshift.example.com:8443/version/openshift | grep gitVersion

*포트 값은 설정에 따라 결정됩니다.

다른 방법으로는 ‘oc’ 명령을 사용하여 로그인한 경우 다음 명령으로 버전을 확인할 수 있습니다:

   oc version

아래에 나열된 것보다 이전 OpenShift Container Platform 버전은 취약점의 영향을 받습니다.

  • v3.11.43-1
  • v3.10.72-1
  • v3.9.51-1
  • v3.8.44-1
  • v3.7.72-1
  • v3.6.173.0.140-1
  • v3.5.5.31.80-1
  • v3.4.1.44.57-1
  • v3.3.1.46.45-1
  • v3.2.1.34-2

해결 방법

영향을 받는 Red Hat 제품 버전을 사용하는 고객은 패치가 릴리스되는 대로 바로 업데이트할 것을 강력히 권장합니다.  

OpenShift Online (Starter, Pro)이 수정되었습니다.  OpenShift Dedicated를 사용하는 고객은 지원 담당자에게 문의하여 시스템 상태 및 업데이트 일정을 확인하시기 바랍니다.  

영향을 받는 제품 업데이트

제품패키지 권고/업데이트
OpenShift Container Platform v3.11kubernetesRHSA-2018:3537
OpenShift Container Platform v3.10kubernetesRHSA-2018:3549
OpenShift Container Platform v3.11kubernetesRHSA-2018:2908
OpenShift Container Platform v3.8kubernetesRHSA-2018:3551
OpenShift Container Platform v3.7kubernetesRHSA-2018:2906
OpenShift Container Platform v3.6kubernetesRHSA-2018:3598
OpenShift Container Platform v3.5kubernetesRHSA-2018:3624
OpenShift Container Platform v3.4kubernetesRHSA-2018:3752
OpenShift Container Platform v3.3kubernetesRHSA-2018:3754
OpenShift Container Platform v3.2kubernetesRHSA-2018:3742


완화 방법

OpenShift Container Platform 3.2 버전 이상에서 문제점을 해결하기 위한 업데이트를 사용할 수 있습니다.    

최신 버전으로 업데이트한 사용자는 추가 완화 조치를 적용할 필요가 없습니다. 그러나 업데이트를 적용할 수 없는 경우 문제를 완화하는 것이 좋습니다.  

pod exec/attach/port-forward 공격 완화 (OCP 3.2->3.11)

기본 admin으로 전환하고 다음과 같이 pod attach/exec/port-forward 권한으로 역할을 편집합니다.

$oc edit clusterrole admin

‘rbac.authorization.kubernetes.io/autoupdate’ 주석을 false 값으로 추가하고 pod attach/exec/portforward 권한을 제거합니다. 예:

apiVersion: v1
kind: ClusterRole
metadata:
   annotations:
      openshift.io/description: A user that has edit rights within the project and can
        change the project's membership.
   creationTimestamp: 2018-11-21T01:34:04Z
   name: admin
   resourceVersion: "148192"
   selfLink: /oapi/v1/clusterroles/admin
   uid: 87dd0306-ed2d-11e8-9456-fa163e65ec84
rules:
- apiGroups:
  - ""
   attributeRestrictions: null
   resources:
  - pods
  - pods/proxy
   verbs:

이러한 권한을 갖는 '편집'역할에 대해서도 동일한 작업을 수행하십시오.

프로젝트의 단일 사용자의 경우 :

사용자에게 할당된 역할을 확인하십시오. 이 경우 admin 역할은 quicklab 사용자에게 할당됩니다.
 
$ oc project myproj
$ oc adm policy who-can get pods/exec
Namespace: test
Verb:      get
Resource:  pods/exec
 
Users:  quicklab
        system:admin
        system:serviceaccount:kube-system:generic-garbage-collector
        system:serviceaccount:kube-system:namespace-controller
 
Groups: system:cluster-admins
        system:masters
 
 
$ oc get rolebindings
NAME                    ROLE                    USERS      GROUPS                          SERVICE ACCOUNTS   SUBJECTS
admin           /admin          quicklab                                                      
system:deployers        /system:deployer                                                   deployer           
system:image-builders   /system:image-builder                                              builder            
system:image-pullers    /system:image-puller               system:serviceaccounts:myproj
$ oc export clusterrole admin > admin-mitigate.yml

'rbac.authorization.kubernetes.io/autoupdate'주석을 false 값으로 추가하고 이름을 변경하고 pod attach/exec/portforward 권한을 제거하여 admin-mitigate.yml을 편집하십시오. 예:

apiVersion: v1
kind: ClusterRole
metadata:
  annotations:
    openshift.io/description: A user that has edit rights within the project and can
      change the project's membership.
    rbac.authorization.kubernetes.io/autoupdate: "false"
  creationTimestamp: null
  name: admin-mitigate
rules:
- apiGroups:
  - ""
  attributeRestrictions: null
  resources:
  - pods
  - pods/proxy
  verbs:
   ...

새로운 설정으로 새 역할을 만듭니다.

$ cat admin-mitigate.yml | oc create -f -

다음 권한을 원하지 않는 사용자에게 이 역할을 할당하십시오.

$ oc adm policy remove-role-from-user admin quicklab
role "admin" removed: "quicklab"
$oc adm policy add-role-to-user admin-mitigate quicklab
role “admin-mitigate’”added: “quicklab”

API 확장에 대한 공격 완화 (OCP 3.6 -> 3.11)

클러스터를 패치된 버전으로 업그레이드할 때까지 API 확장 공격을 완화하려면 영향을 받는 API 확장을 제거합니다. 서비스 삭제에 의해 중요 기능이 손실되지 않도록 각 서비스를 신중하게 검토하십시오. 서비스 삭제에 의해 중요 기능에 영향을 주는 경우 네트워크 기능 사용 제한과 같은 다른 옵션을 선택해야 합니다.

다음의 방법으로 비활성화해야 하는 서비스 목록을 가져옵니다.

$ oc get apiservices -o=custom-columns=NAME:.metadata.name,SERVICE:.spec.service,STATUS:.status.conditions[0].type,VALUE:.status.conditions[0].status | grep -v '<nil>'

예를 들어 OCP 3.11의 경우 서비스에는 다음이 포함될 수 있습니다.

이름 서비스 상태
v1beta1.servicecatalog.k8s.io map[name:apiserver namespace:kube-service-catalog]AvailableTrue

출력에 나열된 서비스를 비활성화합니다. 예 :

$ oc delete svc apiserver -n kube-service-catalog

이 예에서 service-catalog를 다시 활성화하려면 openshift-service-catalog playbook을 실행하십시오. 다른 서비스를 다시 사용 가능하게 설정하는 방법은 제품 설명서에서 참조하십시오.

$ ansible-playbook [-i /path/to/inventory]
/usr/share/ansible/openshift-ansible/playbooks/openshift-service-catalog/config.yml

Subscriber exclusive content

A Red Hat subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.

Current Customers and Partners

Log in for full access

Log In