제목 : RSAC 문제의 해석 - 클라우드의 교차 임시 취약성 공격 표면 분석

RSAC议题解读-云上跨租户漏洞攻击面分析​

Wiz의 보안 연구원 2 명은 2023 년 RSAC 회의에서 《Tackling the Recent Rise of Cross-Tenant Vulnerabilities》이라는 주제를 공유했습니다. 두 연구원은 신흥 공격 방향, 즉 교차 테넌트 취약점, 관련 개념, 그리고 Google Cloud 등의 대처에 대한 대처자 취약점을 도입했습니다.

1 相关概念​

1.1 多租户技术​

다중 테넌트 기술은 단일 애플리케이션 또는 서비스에서 여러 독립적 인 테넌트 또는 사용자를 동시에 지원하기 위해 클라우드 컴퓨팅 환경에서 널리 사용되는 아키텍처 설계 방법입니다.
전통적인 단일 테넌트 아키텍처에서 각 응용 프로그램 또는 서비스는 하나의 테넌트 만 제공합니다. 다중 테넌트 아키텍처에서 응용 프로그램 또는 서비스는 동시에 여러 세입자에게 서비스를 제공하도록 설계되었으며 각 임차인은 서로 독립적으로 서로 분리되어 서로를 방해하지 않습니다.
202305302102272.png-water_print

다중 테넌트 기술의 주요 기능은 자원 공유 및 격리입니다. 여러 임차인은 효율적인 리소스 활용을 달성하기 위해 하드웨어, 네트워크 및 소프트웨어 구성 요소를 포함한 동일한 인프라를 공유합니다. 동시에, 각 임차인 간의 데이터 및 운영 환경은 서로 분리되어 임차인 간의 보안 및 개인 정보를 보장합니다.
다중 테넌트 아키텍처는 일반적으로 서비스 (PAAS) 및 SAAS (Software as a Service)와 같은 클라우드 서비스 모델에서 널리 사용됩니다. 이 모델에서 클라우드 제공 업체는 여러 임차인에게 동일한 응용 프로그램 또는 서비스 인스턴스를 제공하며, 각각의 데이터 및 구성을 사용자 정의하고 관리 할 수 있습니다.

1.2 跨租户漏洞​

클라우드에서 다중 테넌트 기술이 널리 사용되는 시나리오에서, 교차 테넌트 취약점이 등장합니다. 교차 테넌트 취약점은 한 명의 테넌트가 다른 임차인의 데이터 또는 자원에 액세스하거나 방해 할 수있는 다중 테넌트 환경에 존재하는 보안 취약점입니다. 이 취약점은 심각한 보안 문제를 일으킬 수 있으며 공격자는 임차인 간 취약성을 통해 테넌트 데이터 또는 시스템 제어를 얻을 수 있으며, 세입자 간의 격리와 보안을 심각하게 손상시킬 수 있습니다.
202305302109644.png-water_print

2 租户隔离的实现方式​

2.1 逻辑隔离​

논리적 격리는 매우 간단한 세입자 격리 방법입니다. 임차인은 공유 데이터베이스 인스턴스에 전용 데이터베이스가 있습니다. 그러나 각 고객에게는 자체 자격 증명이있어 다른 사용자 간의 격리를 보장합니다.
202305302124451.png-water_print

이 격리 방법은 산업 실무에서 우수한 작동성을 가지고 있으며 소프트웨어 아키텍처는 간단하고 구현하기 쉽고 비용이 낮습니다. 그러나 일단 단일 고장 지점이 발생하면 데이터베이스 인스턴스에 따라 모든 임차인에게 영향을 미칩니다.
또한, 예를 들어 공격자가 데이터베이스를 손상 시키면 공격자가 현재 임차인의 권한에서 관리자의 권한으로 상승하면 공격자는 다른 임차인의 데이터에 액세스 할 수 있습니다. 또한 일부 운영 및 유지 보수 직원의 경우 데이터베이스 인스턴스를 구성 할 때 부적절한 구성 문제가 발생할 수 있습니다. 이 경우 공격자는 0 일을 사용하여 권한을 늘릴 필요조차 없으며 특정 오해를 남용하여 다른 사용자 데이터에 액세스 할 수 있습니다.
202305302134163.png-water_print

2.2 基于容器的隔离​

컨테이너 기반 분리는 상기 격리 방법에 비해 특정 장점이 있습니다. 이 분리 방법에서는 더 이상 여러 고객이 동일한 데이터베이스 인스턴스를 공유하지 않으며 각 고객은 고유 한 데이터베이스 인스턴스를 가지고 있으며 비교적 독립적 인 컨테이너에서 실행되며 여러 고객이 동일한 가상 머신을 공유 할 수 있습니다.
202305302148078.png-water_print

이 분리 방법은 또한 비교적 저렴하고 구현하기 쉽습니다. 공격자가 격리를 뚫고 싶을 때, 그는 두 가지 보안 경계, 즉 이전 방법과 동일한 데이터베이스의 첫 번째 레이어; 컨테이너의 두 번째 층. 공격자가 컨테이너에서 탈출하면 가상 머신에서 임의의 코드를 실행하여 다른 임차인의 컨테이너를보고 데이터에 액세스 할 수 있습니다.
이 격리 방법이 더 나은 접근법 인 것처럼 보이지만 이전 접근법에 비해 여전히 단점이 있습니다. 일부 보안 연구원들이 믿듯이, 컨테이너는 매우 강력한 보안 장벽으로 간주되지 않습니다. 가끔씩 Linux는 일부 커널 취약점을 발표하며 일부는 컨테이너로 탈출하는 데 사용될 수 있습니다.
Wiz 팀은 Alibaba Cloud 데이터베이스에 대한 보고서를 공개했으며 특정 세부 사항은 3 장에 설명되어 있습니다.
202305302159759.png-water_print

2.3 基于虚拟机的隔离​

임차인을 격리하는 세 번째 방법은 대부분의 서비스 제공 업체가하는 경향이 있습니다 : 가상 머신 기반 격리. 이 분리 접근 방식에서 각 임차인은 별도의 전용 가상 시스템에서 실행되는 자체 데이터베이스 인스턴스를 가지고 있습니다. 따라서 고객은 이제 이전 격리 방법과 같은 가상 시스템을 공유하는 대신 물리적 컴퓨팅 리소스를 공유합니다.
202305302203644.png-water_print

그림에서 볼 수 있듯이 공격자 가이 격리 방법을 깨고 싶다면 2 ~ 3 개의 보안 경계를 깰 필요가 있습니다. 첫 번째 계층은 확실히 데이터베이스 취약점이 필요하며 임의 코드를 실행할 수 있습니다. 두 번째 층은 컨테이너 이스케이프와 세 번째 레이어 가상 머신 취약성이 필요할 수 있습니다. 일반적으로 VM 탈출 취약성은 파기가 더 어렵습니다.
각 임차인에게 고유 한 전용 가상 머신이 있으면 클라우드 서비스 제공 업체 비용이 상당히 비쌉니다. 동시에 아키텍처는 유지하기가 어려워지고 있습니다. 격리 서비스가 강할수록 실제로 서비스를 디버깅하고 서비스 문제를 해결하는 것이 더 어려워집니다.

3 真实环境中的漏洞案例​

임차인 분리는 단지 컴퓨팅 리소스를 분리하는 것이 아닙니다. 다른 자원과 다른 자산이 있습니다. 먼저, 일반적인 임차인 격리 시스템에서 어떤 위험이 노출되는지 살펴 보겠습니다.
202305302215790.png-water_print

예를 들어 Kubernetes 또는 서비스 패브릭, 내부 API와 같은 오케스트레이터. 또한 일반적으로 호스팅되는 서비스는 공유 네트워크 환경에서 실행되며 데이터는 공유 네트워크를 통해 상호 작용할 수 있습니다. 또한 저장, 신원 인증 시설 등도 격리를 고려해야합니다.

3.1 阿里云 AnalyticDB for PostgreSQL​

클라우드 네이티브 데이터웨어 하우스 AnalyticDB PostgreSQL 버전은 대규모 온라인 데이터 분석 서비스를 제공 할 수있는 대규모 병렬 처리 (MPP) 데이터웨어 하우스 서비스입니다.
PostgreSQL에 대한 AnalyticDB에 대한 공격 체인은 다음과 같습니다.
Cronjob 타임 작업을 사용하여 컨테이너의 루트 권한에 대한 권한을 높이십시오.
포드 내용에서 PID 네임 스페이스 공유의 특성을 활용하여 POD의 인접한 권한있는 컨테이너로 가로로 이동하십시오.
권한이있는 컨테이너를 사용하여 호스트로 탈출하십시오.
호스트에서 Kubelet 자격 증명을 사용하여 키, Serviceaccount 및 POD를 포함한 민감한 리소스에 액세스하십시오.
수집 된 자격 증명을 사용하여 Alibaba Cloud 개인 컨테이너 이미지 저장소에 액세스하고 자격 증명 권한을보십시오.
테스트 후 자격 증명은 컨테이너 이미지 저장소에 대한 권한을 읽고 쓰여서 공급망 공격을 시작할 수 있습니다.
관련 기사는 취약성을 분석했으며 여기에는 설명되지 않습니다.

3.2 Azure Database for PostgreSQL​

Azure Database에서 PostgreSQL의 경우 다른 임차인 간의 데이터베이스는 네트워크에서 격리되어 있지 않으므로 두 세입자간에 네트워크 연결이 있음을 의미합니다. Wiz 연구원은 먼저 취약점을 통해 자체 데이터베이스에 액세스 할 수 있었으며 현재 컴퓨터는 다른 데이터베이스와 통신하고 SSL 인증서를 위조하고 다른 데이터베이스의 인증을 우회하여 다른 테넌트 데이터에 대한 전체 읽기 권한을 얻을 수 있기 때문입니다. 이 취약점에 대한 Microsoft의 수정은 임차인 간의 네트워크를 분리하여 임차인 간의 상대적 독립성을 보장하는 것입니다.
202305311630613.png-water_print

3.3 IBM Managed Databases​

IBM 관리 데이터베이스이 사례는 매우 흥미 롭습니다. 이 경우 IBM 서비스 아키텍처는 비교적 완전하고 리소스 분리는 잘 설계되었습니다. 각 임차인에는 특별한 Kubernetes 네임 스페이스가 있습니다.
202305311635747.png-water_print

그러나 연구원들은 컨테이너의 K8S API에 대한 네트워크 연결을 발견했습니다. 동시에, K8S 자체의 부적절한 구성으로 인해, 고급 서비스 계정은 현재 POD에 매달려 있으므로 토큰을 사용하여 K8S API에 요청을 보내고 K8S 관련 작업을 수행 할 수 있습니다. 연구원의 테스트 후, 토큰은 개인 저장소에서 이미지를 끌어낼 수있는 권한이 있습니다.
202305311642644.png-water_print

따라서 공격자는 미러 저장소의 모든 이미지를 얻을 수 있습니다.
202305311643565.png-water_print

이미지에는 소스 코드, 구성 등을 포함한 많은 양의 데이터가 포함되어 있습니다. 미러 컨텐츠를 분석하고 내부 CI/CD 서버 자격 증명을 읽고 읽기 및 쓰기 권한을 사용하여 공급망 공격을 구현할 수 있습니다.
202305311652381.png-water_print

3.4 其它案例​

저자는 회사 내 제품 라인에서 보안 테스트를 수행 할 때 유사한 보안 문제를 겪었습니다. 임차인은 제대로 격리되지 않기 때문에 많은 수의 임차인 권한 및 데이터를 얻는 문제가 발생합니다.
그들 중 하나를 예로 들어보십시오.
사이트에서 원격 컴퓨팅 리소스 (온라인 IDE)를 만들 때 사용자는 인트라넷에 VPN 구성 연결 이메일을 받게됩니다. VPN에 전화를 걸고 나서 그는 인트라넷이 검역되지 않았으며 네트워크가 임차인간에 상호 연결되어 있음을 발견했습니다.
인트라넷에 적용된 리소스 호스트에서 10.208.0.0/16 네트워크 세그먼트를 직접 스캔하여 분리 된 것을 발견했습니다. 그러나이 컴퓨터에서 VPN 세그먼트 172.36.0.0/16을 스캔하려고했는데 검역되지 않았다는 것을 알았습니다. 결과는 다음과 같습니다.
202305311709386.png-water_print

인트라넷에서 세입자 적용 기계를 예로 들어보십시오. 온라인 IDE에는 터미널 기능이 있으며 사용자의 권한을 확인하지 않으므로 명령을 실행할 수 있습니다. 온라인 IDE의 사용자는 DevKit 일반 사용자입니다.
202305311712370.png-water_print

정보 수집 후,이 호스트들은 모두 클라우드에 의해 전송 된 것으로 밝혀졌습니다. 쿼리 EC의 사용자 정의 데이터를 확인하고 초기 SSH 로그인 키를 찾으십시오.
1
CURL http://169.254.169.254/OpenStack/최신/User_Data
SSH의 일반 텍스트 비밀번호는 user_data에서 녹음 되었으며이 암호를 직접 사용하여 Root:으로 전환 할 수 있습니다.
202305311716874.png-water_print

이러한 방식으로, 각 임차인에게 수평으로 배치하고, 많은 수의 테넌트 리소스 머신의 루트 권한을 얻고, SSH에 로그인하여 기계에 저장된 다양한 리소스 파일을 얻을 수 있습니다.
 
뒤로
상단