최신 클라우드 서비스 제공업체 (CSP) 취약점 동향과 보안 대응 (2022 ~ 2023년)
개요
클라우드 시장은 지속적으로 확장되고 있고, 다수의 기업들이 최신 트렌드를 따라 클라우드 서비스를 적극 활용하고 있습니다. 그러나 이러한 발전이 이루어짐에 따라, 클라우드 보안 이슈도 끊임없이 나타나고 있습니다.
이와 관련한 보안 이슈는 클라우드 서비스에 배포한 애플리케이션이 원인이 되는 이슈가 많으나, 클라우드 서비스 제공업체(Cloud Service Provider, CSP)자체에서 발생하는 취약점도 적지 않습니다. 특히 CSP 자체의 취약점은 공급망 공격(Supply Chain Attack)으로도 이어질 수 있는 만큼, 그 파장이 IT 산업 전반에 영향을 미치기도 합니다.
본 포스트에서는 최근에 발생했던 CSP 취약점들을 통해 (1) 최신 CSP 취약점들의 동향과 특징을 파악하고 이를 통해 클라우드 (2) 보안 연구자, CSP, 그리고 사용자 측면의 흥미로운 인사이트들을 제공하고자 합니다.
Cloud Service Provider (CSP)에 대해
클라우드 컴퓨팅은 21세기를 대표하는 IT 기술 중 하나로 가상 서버, 데이터베이스, 애플리케이션 개발 및 배포, 보안 등 IT 전 분야에 걸친 다양한 서비스를 제공하고 있습니다. 클라우드 서비스가 제공하는 높은 가용성, 탄력성, 편의성, 비용 절감 효과 등은 많은 기업이 클라우드 기술을 도입하게 되는 이유입니다. 최근에는 클라우드 서비스 시장의 변화가 더욱 급격히 일어나고 있습니다. 아마존과 구글, 마이크로소프트, 그리고 알리바바까지 거대 IT 기업들이 시장에 뛰어들면서 CSP들의 매출도 큰 폭으로 증가하고 있습니다. [1]Synergy Research Group의 통계에 따르면, CSP들의 매출이 올해 1분기에만 630억 달러, 한화 84조에 이르며, 이는 작년에 비해 100억 달러 이상 증가한 것으로 3대 주요 CSP인 아마존, 마이크로소프트, 구글이 전체 매출의 65%를 차지하고 있습니다.
한편, 클라우드 기술 및 사용량의 폭발적인 증가와 함께 관련된 보안 위협도 나날이 증가하고 있습니다. [2]Venafi가 2022년 1,101명의 기업 및 조직 내의 보안 의사 결정자를 대상으로 설문 조사를 진행한 결과, 81%의 조직이 1년 이내 클라우드와 관련된 보안 사고를 경험했으며, 그중 절반 이상(45%)의 조직이 최소 4건 이상의 사고를 겪었다고 답했습니다. 실제로 이러한 서비스를 제공하는 CSP들 뿐만 아니라 드롭박스, 링크드인, 애플을 비롯한 다수의 거대 IT기업들이 클라우드와 관련된 취약점을 악용한 공격으로 자산 탈취, 고객 개인정보 유출 등의 큰 피해를 입기도 했습니다.
또한 2023년 상반기 마이크로소프트 Azure와 알리바바 클라우드를 비롯한 주요 CSP들에서 크리티컬한 취약점이 다수 발견되어, 클라우드 보안 문제에 대한 우려가 높아지고 있습니다. 특히 Azure에서 발견된 [3]Bingbang, 그리고 알리바바 클라우드에서 발견된 [4]BrokenSesame 사례는 각각 클라우드 사용자의 인증 토큰 유출과 사용자 전체에 대한 공급망 공격으로 이어질 수 있는 심각한 취약점으로, CSP의 잘못된 기본 설정 등으로 인해 해당 서비스 사용자 입장에서는 대처할 수 있는 방법이 전혀 없었다는 점에서 큰 충격을 주었습니다.
이러한 취약점들이 모두 직접적인 보안 사고로 이어진 것은 아니지만, 현재 IT 산업의 근간으로 자리 잡은 클라우드 서비스들이 취약점에 노출되어 있다는 사실만으로도 우리에게 클라우드 보안 위협과 그 대책에 대해 재고할 필요성을 절감케 합니다.
따라서 저희는 2022년부터 2023년 상반기까지 공식적으로 알려진 최신 CSP 취약점 사례들을 조사하고 취약점 유형, 심각도, 벤더와 같은 3가지 척도로부터 도출된 통계를 기반으로 비교 분석을 진행해 보았습니다. 이를 통해 CSP 취약점들에 대해 보안 연구자 입자에서 어떤 부분에 초점을 두고 연구를 진행해야 할지, 그리고 CSP의 입장에서 취약점이 자주 발생하는 부분을 파악하고 나아가 좀 더 안전한 설계를 고려할 수 있도록 저희가 찾은 흥미로운 인사이트들을 공유하고자 합니다.
2022 ~ 2023 년도 최신 CSP 취약점 통계
아래 통계에서 사용한 취약점 유형으로 일반적인 취약점 분류 시스템인 CWE(Common Weakness Enumeration)를 참고하였으며, CSP의 특징적인 취약점들은 OWASP(Open Worldwide Application Security Project)의 기준을 참고하여 그 분류를 선정하였습니다.
2022년 1월부터 2023년 1분기까지 발견된 CSP 취약점 약 60건을 취약점 유형별로 분류한 결과, 미흡한 설정으로 발생한 취약점(Misconfiguration) 이 26.5%로 가장 많았고 다음으로 부적절한 인증 및 인가(Improper authentication & authorization)가 20.5%, 컨테이너나 샌드박스 등이 제대로 격리되지 않아서 발생한 격리 문제(Isolation failure)가 12%로 뒤를 이었습니다.
Top 1. 미흡한 설정(misconfiguration)
가장 많은 취약점은 미흡한 설정으로 발생하였습니다. 클라우드를 이용하여 서비스를 배포하는 기업의 경우에도 미흡한 설정 문제로 고초를 겪지만, CSP의 경우에도 미흡한 설정으로 인해 초과된 권한 부여나 API 접근 등에 대한 로깅이 제대로 되지 않는 등의 문제를 겪습니다. 특히 잘못된 권한 부여 문제가 가장 심각도가 높고, 발생 빈도 또한 잦았습니다.
벤더별 취약점 개수에 대한 통계를 확인해보면 역시 사용자 및 매출 기준으로 현재 CSP들 중 Top3로 꼽을 수 있는, 마이크로소프트 Azure, 아마존 AWS, 구글 GCP가 보고된 취약점 개수 기준으로도 Top3를 기록하고 있음을 알 수 있습니다.
시장에서 선두를 달리고 있는 해당 벤더들의 서비스에서 보고된 취약점 개수가 더 많다는 점으로부터 단편적으로는 해당 서비스들이 그만큼 많은 취약점에 노출되어 있다고 볼수도 있으나, 한편으로는 더 많은 보안 연구자들이 해당 클라우드 서비스들의 보안에 대해 주시하고 있다는 점과 더불어 벤더들이 외부의 보안 및 취약점 연구자들에게 좀 더 개방적이며 취약점들에 대해 더 빠르게 대응하고 있다고도 볼 수 있습니다.
저희는 벤더별 취약점 개수에 대한 통계에 그치지 않고 해당 Top3 벤더에 대해 각 벤더별로 어떠한 유형의 취약점들이 발생했는지에 대한 통계를 도출하여 추가적인 인사이트를 얻고자 했습니다. 수집한 취약점 데이터가 2022년부터 2023년 상반기까지의 최신 취약점들로 제한되어 있어 통계의 방향성이 다소 불분명하지만, 벤더 모두에서 미흡한 설정 문제가 가장 주요한 취약점임을 다시 한 번 확인할 수 있습니다.
특히 AWS에서 10개 이상의 설정 관련 취약점이 발견되었는데, 다양한 기능과 설정을 제공하는 클라우드 서비스에서 설정 미흡 취약점이 주를 이루는 것은 크게 놀라운 일이 아닙니다. 하지만 AWS 클라우드 서비스에서 발생한 해당 유형의 취약점들을 구체적으로 살펴본 결과 대부분의 취약점들이 IAM 정책의 기본 설정 문제였습니다. 그 예시로 [5]Overprivileged CodeBuild default ECR IAM policy와 같이 CSP에서 특정 클라우드 서비스에 대하여 기본 권한으로 제공하는 IAM(Identity and Access Management) 설정이 잘못되어 컴포넌트에 초과된 권한이 할당된 문제를 비롯하여, AWS Aurora PostgreSQL 컨테이너에서 특정 명령어 및 파일 시스템에 대한 접근 제어 문제로 인한 [6]AWS 내부 서비스 IAM 크레덴셜 노출 사례와 퍼블릭 NPM 저장소에서 패키지 오리진에 대한 검증 부재로 악성 패키지 삽입 및 공급망 공격이 가능했던 [7]AWS CodeArtifact 취약점 사례 등이 있습니다. 이를 통해 미흡한 접근 제어 설정이 CSP의 내부 자산 노출 및 클라우드 서비스 사용자 전체에 대한 공격으로 이어질 수 있으며, AWS 클라우드 서비스에서 이와 같은 IAM 관련 미흡한 설정 문제를 더 주의 깊게 살펴봐야 한다는 점을 의미합니다.
Top 2. 부적절한 인증 및 인가 (improper authentication & authorization)
부적절한 인증 및 인가 문제도 적지않은 비율을 차지합니다. 클라우드 컴포넌트 및 서비스 API 권한 검증이 미흡하거나 부재하여 인증되지 않은 사용자가 API에 접근 가능하거나, 클라우드 컴포넌트에서 사용되는 서비스 바이너리가 root 권한으로 실행되는 등의 취약점이 이에 해당합니다. [8]ECR Public vulnerability in undocumented API는 문서 상에 없는 API가 공개적으로 노출되어 공격자로 하여금 ECR (Elastic Container Registry)에 이미지나 태그 등을 악의적으로 변경할 수 있었습니다. 또한 [9]AttachMe도 특정 API에 대한 인가 로직 부재로 공격자가 임의의 클라우드 사용자의 볼륨을 공격자의 인스턴스에 붙일 수 있는 심각한 취약점이었습니다. 이와 같이 인증 및 인가와 관련된 보안 취약점은 일반적인 컴퓨팅 환경뿐 아니라, 다양한 계층 및 격리 구조를 가지는 클라우드 환경에서 더 큰 피해를 야기할 수 있습니다.
Top 3. 격리 문제 (isolation failure)
가장 높은 3가지 취약점을 심각도 순으로 나열해보면 미흡한 설정 문제나 부적절한 인증 및 인가는 여러 심각도에 걸쳐 고루 발생하는 반면에, 상대적으로 격리 문제의 경우 취약점의 위험도와 파급력이 높은 Critical, High에 주로 분포된 것을 확인할 수 있습니다. 실제로 격리 문제의 가장 최신 사례인 [4]BrokenSesame를 보면, 테넌트가 명확히 격리되어 있지 않아 Cloud DB 인스턴스에서 발생한 취약점을 시작으로 모든 클라우드 사용자에게 영향을 미치는 공급망 공격으로 심화되었습니다. 이처럼 미흡한 격리 문제는 단순히 하나의 컴포넌트, 인스턴스에서 발생한 취약점을 공급망 공격와 같은 다수의 이용자에게 심각한 영향을 미칠 수 있는 공격으로 변모하게 합니다.
이외에도 클라우드 서비스는 3rd party 컴포넌트를 CSP에서 인스턴스 형태나 애플리케이션 형태로 사용할 수 있도록 제공합니다. 이러한 3rd party 컴포넌트 취약점으로 인해 CSP의 공격 표면도 같이 증가했으며, XSS(Cross Site Scripting), SSRF(Server Side Request Forgery) 등 일반적인 온프레미스 서버에서도 발생하는 취약점이 CSP 콘솔과 같은 곳에서 발생하는 것을 확인하였습니다.
CSP 특징적인 취약점 발생 배경과 대응
본문에서 CSP에서 발생했던 취약점들의 통계를 통해 어떤 취약점이 주로 발생하는지 알아보았습니다. CSP에서는 일반적인 온프레미스 서버에서 발생하는 취약점 뿐만 아니라 CSP에서만 특징적으로 발생하는 취약점을 확인할 수 있었습니다. 특히 CSP의 특징적인 취약점이 일반적인 취약점에 비해 심각도가 높고, 발생 비율이 높은 것을 확인할 수 있었습니다. 아래에서는 CSP에서 유독 자주 발생하는 취약점 유형은 CSP의 어떤 특징 때문인지 알아보고, 이에 대한 CSP 벤더들의 대응 방안을 살펴봅니다.
CSP 특징적인 취약점 발생 배경
1. 기본으로 제공되는 설정
CSP는 클라우드라는 특성상 온프레미스 서버와 달리 인프라 구축에 필요한 이용자의 노동을 최소화하고 수천 또는 수백만의 이용자에게 동일하게 확장 가능한 컴포넌트를 제공합니다. 따라서 손쉬운 확장을 위해 설정이 필요한 모든 컴포넌트에 대하여 기본 설정을 제공하고 있습니다. 클라우드 이용자 입장에서 서버 이전을 위해 CSP를 선정할 때에도 기본 설정 제공 수준이 편의성의 척도로 작용하기도 하는 만큼, CSP 입장에서는 고객의 편의를 위해 기본 설정을 제공할 수 밖에 없습니다. 그러나 이러한 기본 설정은 클라우드 이용자에게 편의를 제공하는 반면에 기본 설정이 잘못되어 있는 경우에는 공격자에게 고객 데이터가 노출되거나 서버가 탈취되는 등 심각한 보안 위험을 초래할 수 있습니다.
2. 논리적 격리
CSP는 본인들이 가진 컴퓨팅 리소스를 고객들에게 인스턴스 형태로 대여해주는 서비스를 제공합니다. 클라우드 환경에서는 온프레미스 환경에 비해 훨씬 많은 고객들의 접근을 상정하기 때문에 고객들이 상호 간 리소스에 접근하거나 데이터를 노출하지 않도록 보호하기 위해 리소스 격리가 필요하고, 비용 및 편의성을 고려하여 물리적 격리보다는 논리적 격리인 가상화나 네트워크 격리하는 등의 방법을 사용합니다. 격리 수준은 인스턴스나 애플리케이션의 상호 작용 빈도, 중요도 등에 따라 달라지지만, 만약 이러한 컴포넌트의 성격에 따른 우회 가능성을 고려하지 않고 격리가 불충분한 수준으로 적용되어 있다면 하나의 인스턴스에 대한 공격을 시작으로 측면 이동(Lateral Movement)을 통해 다른 테넌트, 나아가 CSP 전체를 장악할 만큼의 파급력을 가진 공격에 취약할 수 있습니다.
3. 타사 소프트웨어를 사용한 컴포넌트 제공
클라우드 이용자들은 인프라 이전을 위해 CSP를 선택할 때 본인들이 사용하고 있는 타사 소프트웨어(3rd Party Software)들을 모두 CSP에서 제공하는지, 호환성을 중요한 기준으로 꼽습니다. 이에 따라 CSP는 다양한 타사 서비스를 인스턴스나 애플리케이션의 형태로 클라우드 서비스로 사용할 수 있도록 제공합니다. 만약 타사 소프트웨어에 취약점이 발생하면 같은 소프트웨어를 클라우드 형태로 지원하는 CSP도 동일한 취약점이 있을 수 있습니다. 뿐만 아니라 타사 소프트웨어를 클라우드 서비스 형태로 제공하기 위해 CSP에서 자체적으로 구현한 코드에 취약점이 있거나, [10]타사 소프트웨어 업데이트를 용이하게 하기 위해 구현한 서비스에 취약점이 발견되는 사례도 있습니다.
이처럼 일반적인 온프레미스 환경과 다르게 클라우드 환경의 특성때문에 추가되는 공격 표면이 생기기 때문에 클라우드 보안 연구의 방향성을 결정하거나 CSP가 취약점 대응시에 위와 같이 클라우드 환경 특성에 기반한 취약점에 좀 더 무게를 둘 필요가 있습니다.
CSP의 클라우드 특성을 고려한 대응 방안
CSP는 그들이 제공하는 서비스의 보안성, 안전성을 위해 클라우드 이용자들이 서비스의 보안성 증진에 기여할 수 있도록 취약점 연구에 대한 오픈마인드를 가지고 버그바운티를 진행하고 있고, 그 결과 다양한 취약점들이 발견 및 패치될 뿐 아니라 클라우드 보안에 대한 연구가 활발히 진행되고 있습니다.
실제로 일반적인 환경에서 발생하는 취약점 뿐만 아니라 위와 같은 클라우드의 특성을 고려한 취약점의 연구와 보완을 위해 클라우드 보안 리서치 그룹과의 파트너쉽을 맺어 연구를 함께하고 있습니다.
클라우드의 특성상 이용자에게 자율성을 부여할수록 CSP의 관리 범위에서 벗어나기 때문에, CSP가 안전한 도구를 제공하기 위해 노력하더라도 이용자의 서비스 설정, 구현에 따라 클라우드 애플리케이션에 취약점이 발생하는 경우가 있습니다. 때문에 CSP는 더욱 안전한 클라우드 환경을 위해 [11]공동 책임 모델 (Shared Responsibility Model, SRM)을 제시하고 있습니다. 공동 책임 모델은 서비스에 따라 사용자와 제공자가 각각 어떤 책임을 갖는지 나타내는 모델입니다. 클라우드 애플리케이션의 보안 책임은 클라우드 사용자와 클라우드 제공자 모두에게 있으며, 클라우드 제공자는 사용자에게 안전한 도구를 제공할 책임이 있고, 사용자는 그 도구를 안전하게 사용할 책임이 있습니다. CSP는 공동책임 모델을 통해 이용자에게 클라우드 서비스 설정의 자율성을 보장하되, 서비스의 보안성을 유지해야한다는 책임을 이용자와 같이 부담하고자 합니다. 따라서 CSP 뿐 아니라 이용자 측면에서도 클라우드를 사용할 때에는 보안적으로 안전한 구성을 영위해야할 필요가 있습니다.
결론
지금까지 저희는 CSP가 제공하는 다양한 클라우드 서비스에서 발견된 최신 취약점 60여 건에 대해 3가지 기준을 바탕으로 도출한 통계를 분석하고, 분석을 통해 얻을 수 있었던 다양한 인사이트에 대해 알아보았습니다. 특히 현재 클라우드 사용자 측면의 위협에 대한 OWASP의 [12]Cloud-Native Application Security Top 10가 논의중에 있으나 CSP 자체의 취약점에 대해서는 취약점 유형 분류 및 위험도 평가에 일반적으로 사용되는 OWASP Top 10과 같은 표준이 존재하지 않는 상황입니다. 따라서 저희는 일반적인 컴퓨팅 환경에서 발생하는 취약점 유형과 더불어 IAM 정책의 미흡한 설정, 격리 문제와 같은 클라우드 서비스의 특징적인 취약점 유형으로 수집한 취약점들을 분류하고 이에 대해 보안 연구자와 클라우드 서비스를 제공하는 CSP들이 새롭게 고찰해 볼 수 있는 기회를 제공하고자 하였습니다.
우선 클라우드 보안 연구자들은 위에서 제공한 인사이트에 따라 CSP가 제공하는 클라우드 서비스의 특징적인 취약점과 해당 취약점이 자주 발생하는 컴포넌트 및 기능을 중심으로 취약점 및 보안 대책 연구에 대한 방향성을 설정할 수 있습니다. 실제로 [13]Wiz, [14]Orca Security, [15]Lightspin 등 다수의 오펜시브 그룹들이 위와 같은 방식으로 CSP 취약점 연구를 진행하고 있으며, 티오리 Security Assessment팀에서도 클라우드 보안에 관심을 가지고 지속적인 연구 및 자동화를 위해 노력하고 있습니다.
CSP 업체는 저희가 제시한 바와 유사하게 통계를 바탕으로 해당 클라우드 서비스에서 자주 발생한 취약점과 컴포넌트 등을 인지하고 이에 대한 안전한 설계와 보안성 검증 강화에 대해 제고할 수 있습니다. CSP는 특히 통계에서 확인한 취약점 유형 Top3를 중점적으로 고려해야하며 XSS, SQL Injection, Command Injection 등과 같은 일반적인 취약점도 클라우드 서비스의 특징적인 취약점과 함께 악용되어 더 큰 규모의 보안 문제를 일으킬 수 있으므로 해당 취약점들에 대한 높은 수준의 보안성 검증과 방어 대책 수립이 필요합니다.
한편 클라우드 사용자 측면에서는 클라우드 인프라 설계 또는 이전시 CSP 선정에 있어서 사용성, 호환성, 용이성과 더불어 해당 클라우드 서비스의 보안성을 함께 고려해야 합니다. 특히 앞서 언급한 바와 같이 클라우드 사용자 또한 CSP의 공동 책임 모델에 따라 애플리케이션에 대한 보안 책임을 지고 있습니다. 따라서 사용자는 보안성이 뛰어난 CSP를 선정하는 것뿐만 아니라, CSPM(Cloud Security Posture Management) 도구나 서비스 등을 활용하여 클라우드 인프라에 영향을 미칠 수 있는 CSP 취약점을 신속히 파악하고 그로 인한 위협에 적극적으로 대응해야 합니다.
저희가 분석한 취약점들은 CSP들과 해당 취약점을 발견한 연구원 등에 의해 공개된 자료들을 기반으로 수집되었습니다. 그러나, 일부 취약점은 높은 파급력 및 다른 이유로 인해 취약한 제품 또는 컴포넌트 정보 이외의 기술적인 세부사항이 공개되지 않았거나, 취약점 제보 이후 공식적인 언급 없이 CSP에 의해 패치된 경우도 존재했습니다. 따라서 저희가 수집한 취약점 이외에도 다양한 취약점이 존재할 수 있으며, 아직까지 공개되지 않았거나 알려지지 않은 공격 벡터가 존재할 수 있습니다. 따라서 이에 대한 보안 연구가 더욱 활발하게 이뤄져야 합니다.
About Theori Security Assessment
티오리 Security Assessment팀은 실제 해커들의 오펜시브 보안 감사 서비스를 통해 고객의 서비스와 인프라스트럭처를 안전하게 함으로써 비즈니스를 보호합니다. 특히, 더욱 안전한 세상을 위해 난제급 사이버보안 문제들을 해결하는 것을 즐기며, 오펜시브 사이버보안의 리더로서, 공격자보다 한발 앞서 대응하고 불가능하다고 여겨지는 문제를 기술중심적으로 해결합니다.
Security Assessment팀의 오펜시브 보안 감사 서비스에 대해 더 궁금하시다면? contact@theori.io 로 문의 바랍니다.
Reference
https://venafi.com/blog/81-companies-have-had-had-cloud-security-incident-last-year-venafi-research/
https://www.wiz.io/blog/azure-active-directory-bing-misconfiguration
https://blog.lightspin.io/aws-rds-critical-security-vulnerability
https://zego.engineering/dependency-confusion-in-aws-codeartifact-86b9ff68963d
https://unit42.paloaltonetworks.com/aws-log4shell-hot-patch-vulnerabilities/
공동 책임 모델
a. AWS: https://aws.amazon.com/ko/compliance/shared-responsibility-model/
b. MS Azure: https://learn.microsoft.com/ko-kr/azure/security/fundamentals/shared-responsibility
c. GCP: https://cloud.google.com/architecture/framework/security/shared-responsibility-shared-fate?hl=kohttps://owasp.org/www-project-cloud-native-application-security-top-10/
