MCS 클라우드 플랫폼 보안 감사

스카이쉽 황혼 작성자: SeerLight

모든 서비스를 구축하려면 반드시 보안에 대한 지속적인 작업이 필요합니다. 보안은 제품 보안에 대한 지속적인 분석 및 개선, 취약점에 대한 뉴스 모니터링 등을 포함하는 지속적인 프로세스입니다. 감사를 포함합니다. 감사는 프로젝트에 몰입하지 않고 열린 마음을 갖고 있기 때문에 보안에 근본적으로 도움을 줄 수 있는 사내외 전문가에 의해 진행됩니다.

이 기사는 Mail.ru MCS(클라우드 솔루션) 팀이 클라우드 서비스를 테스트하는 데 도움을 준 외부 전문가의 가장 간단한 견해와 그들이 발견한 내용에 관한 것입니다. MCS는 '외부세력'으로 정보보안 분야 전문성이 높은 디지털보안업체를 선택했다. 그리고 이 기사에서는 외부 감사의 일부로 발견된 몇 가지 흥미로운 취약점을 분석하여 자체 클라우드 서비스를 만들 때 동일한 레이크를 방지할 수 있습니다.

Описание의 продукта

Mail.ru 클라우드 솔루션(MCS) 클라우드에 가상 인프라를 구축하기 위한 플랫폼입니다. 여기에는 IaaS, PaaS 및 개발자를 위한 기성 애플리케이션 이미지 마켓플레이스가 포함됩니다. MCS 아키텍처를 고려하여 다음 영역에서 제품의 안전성을 확인해야 했습니다.

• 가상화 환경의 인프라 보호: 하이퍼바이저, 라우팅, 방화벽;
• 고객의 가상 인프라 보호: 네트워크, SDN의 개인 네트워크를 포함하여 서로 격리됩니다.
• OpenStack 및 해당 개방형 구성 요소
• 자체 디자인의 S3;
• IAM: 역할 모델이 있는 다중 테넌트 프로젝트
• 비전(컴퓨터 비전): 이미지 작업 시 API 및 취약점
• 웹 인터페이스 및 고전적인 웹 공격;
• PaaS 구성요소의 취약점;
• 모든 구성 요소의 API입니다.

아마도 그것이 더 많은 역사에 필수적인 전부일 것입니다.

어떤 종류의 작업이 수행되었으며 왜 필요했습니까?

보안 감사는 개인 데이터 유출, 민감한 정보 수정 또는 서비스 가용성 중단으로 이어질 수 있는 취약성과 구성 오류를 식별하는 것을 목표로 합니다.

평균 1~2개월 동안 지속되는 작업 동안 감사자는 잠재적인 공격자의 행동을 반복하고 선택한 서비스의 클라이언트 및 서버 부분에서 취약점을 찾습니다. MCS 클라우드 플랫폼 감사 과정에서 다음과 같은 목표가 확인되었습니다.

1. 서비스 내 인증 분석. 이 구성요소의 취약점은 다른 사람의 계정에 즉시 침투하는 데 도움이 됩니다.
2. 서로 다른 계정 간의 역할 모델 및 액세스 제어를 연구합니다. 공격자에게는 다른 사람의 가상 머신에 액세스하는 능력이 바람직한 목표입니다.
3. 클라이언트측 취약점. XSS/CSRF/CRLF/등등. 악성링크를 통해 다른 사용자를 공격할 수 있나요?
4. 서버 측 취약점: RCE 및 모든 종류의 주입(SQL/XXE/SSRF 등). 서버 취약점은 일반적으로 찾기가 더 어렵지만 한 번에 많은 사용자가 손상될 수 있습니다.
5. 네트워크 수준에서 사용자 세그먼트 격리 분석. 공격자의 경우 격리가 부족하면 다른 사용자에 대한 공격 표면이 크게 늘어납니다.
6. 비즈니스 로직 분석. 기업을 속이고 무료로 가상 머신을 만드는 것이 가능합니까?

이 프로젝트에서는 "그레이박스" 모델에 따라 작업이 수행되었습니다. 감사자는 일반 사용자의 권한으로 서비스와 상호 작용했지만 부분적으로 API 소스 코드를 소유하고 개발자와 세부 사항을 명확히 할 기회를 가졌습니다. 이는 일반적으로 가장 편리하고 동시에 매우 현실적인 작업 모델입니다. 내부 정보는 공격자가 계속 수집할 수 있지만 시간 문제일 뿐입니다.

발견된 취약점

감사자가 다양한 페이로드(공격을 수행하는 데 사용되는 페이로드)를 임의의 장소로 보내기 전에 사물이 어떻게 작동하고 어떤 기능이 제공되는지 이해해야 합니다. 연구된 대부분의 장소에는 취약점이 없기 때문에 이것은 쓸모없는 연습처럼 보일 수 있습니다. 그러나 애플리케이션의 구조와 해당 작동 논리를 이해해야만 가장 복잡한 공격 벡터를 찾을 수 있습니다.

의심스러워 보이거나 어떤 면에서 다른 곳과 많이 다른 곳을 찾는 것이 중요합니다. 그리고 이런 방식으로 최초의 위험한 취약점이 발견되었습니다.

IDOR

IDOR(안전하지 않은 직접 개체 참조) 취약점은 비즈니스 논리에서 가장 일반적인 취약점 중 하나이며, 이로 인해 액세스가 실제로 허용되지 않는 개체에 대한 액세스 권한을 다른 사람이 얻을 수 있습니다. IDOR 취약점으로 인해 다양한 심각도의 사용자에 대한 정보를 얻을 수 있습니다.

IDOR 옵션 중 하나는 시스템 개체(사용자, 은행 계좌, 장바구니에 있는 항목)에 대한 액세스 식별자를 조작하여 해당 개체에 대한 작업을 수행하는 것입니다. 이는 가장 예측할 수 없는 결과를 초래합니다. 예를 들어, 자금 보낸 사람의 계정을 교체하여 다른 사용자로부터 자금을 훔칠 수 있는 가능성이 있습니다.

MCS의 경우 감사자들은 비보안 식별자와 관련된 IDOR 취약점을 최근 발견했습니다. 사용자의 개인 계정에서는 UUID 식별자를 사용하여 보안 전문가가 말했듯이 매우 안전하지 않은(즉, 무차별 대입 공격으로부터 보호되는) 것처럼 보이는 모든 개체에 액세스했습니다. 그러나 특정 엔터티의 경우 애플리케이션 사용자에 대한 정보를 얻기 위해 정기적으로 예측 가능한 숫자가 사용되는 것으로 밝혀졌습니다. 사용자 ID를 하나씩 변경하고 다시 요청을 보내 ACL(액세스 제어 목록, 프로세스 및 사용자에 대한 데이터 액세스 규칙)을 우회하여 정보를 얻는 것이 가능했다고 짐작할 수 있습니다.

서버 측 요청 위조(SSRF)

OpenSource 제품의 좋은 점은 발생하는 문제에 대한 자세한 기술 설명과 운이 좋으면 솔루션에 대한 설명이 포함된 수많은 포럼이 있다는 것입니다. 하지만 이 동전에는 이면이 있습니다. 알려진 취약점도 자세히 설명되어 있습니다. 예를 들어 OpenStack 포럼에는 취약점에 대한 훌륭한 설명이 있습니다. [XSS] и [SSRF], 어떤 이유로 든 아무도 서둘러 고치지 않습니다.

애플리케이션의 일반적인 기능은 서버가 클릭하는 링크를 사용자가 서버에 보내는 기능입니다(예: 지정된 소스에서 이미지 다운로드). 보안 도구가 링크 자체나 서버에서 사용자에게 반환되는 응답을 필터링하지 않으면 공격자가 이러한 기능을 쉽게 사용할 수 있습니다.

SSRF 취약점은 공격 개발을 크게 앞당길 수 있습니다. 공격자는 다음을 얻을 수 있습니다.

• 예를 들어 특정 네트워크 세그먼트를 통해서만 특정 프로토콜을 사용하여 공격받은 로컬 네트워크에 대한 제한된 액세스
• 애플리케이션 수준에서 전송 수준으로 다운그레이드가 가능한 경우 로컬 네트워크에 대한 전체 액세스 및 결과적으로 애플리케이션 수준에서 전체 로드 관리가 가능합니다.
• 서버의 로컬 파일을 읽을 수 있는 액세스(file:/// 구성표가 지원되는 경우)
• 그리고 훨씬 더.

SSRF 취약점은 OpenStack에서 오랫동안 알려져 왔으며 본질적으로 "맹인"입니다. 즉, 서버에 접속하면 서버로부터 응답을 받지 못하지만 요청 결과에 따라 다양한 유형의 오류/지연이 발생합니다. . 이를 기반으로 내부 네트워크의 호스트에서 포트 스캔을 수행할 수 있으며 그에 따른 모든 결과를 과소평가해서는 안 됩니다. 예를 들어, 회사 네트워크에서만 액세스할 수 있는 백오피스 API가 제품에 있을 수 있습니다. 문서(내부자도 잊지 마세요)를 통해 공격자는 SSRF를 사용하여 내부 메서드에 액세스할 수 있습니다. 예를 들어, 유용한 URL의 대략적인 목록을 얻을 수 있었다면 SSRF를 사용하여 해당 URL을 검토하고 요청을 실행할 수 있습니다. 즉, 상대적으로 말하면 계좌에서 계좌로 돈을 이체하거나 한도를 변경할 수 있습니다.

OpenStack에서 SSRF 취약점이 발견된 것은 이번이 처음이 아닙니다. 과거에는 직접 링크에서 VM ISO 이미지를 다운로드할 수 있었으며 이로 인해 비슷한 결과가 발생했습니다. 이 기능은 이제 OpenStack에서 제거되었습니다. 분명히 커뮤니티에서는 이것이 문제에 대한 가장 간단하고 신뢰할 수 있는 해결책이라고 생각했습니다.

그리고에 이 HackerOne 서비스(h1)의 공개 보고서에 따르면, 인스턴스 메타데이터를 읽을 수 있는 기능을 갖춘 더 이상 블라인드가 아닌 SSRF를 활용하면 전체 Shopify 인프라에 대한 루트 액세스가 가능해집니다.

MCS에서는 기능이 유사한 두 곳에서 SSRF 취약점이 발견됐으나 방화벽 등 보호 장치로 인해 악용이 거의 불가능했다. 어쨌든 MCS 팀은 커뮤니티를 기다리지 않고 이 문제를 해결했습니다.

쉘을 로드하는 대신 XSS

수백 개의 연구가 작성되었음에도 불구하고 해마다 XSS(교차 사이트 스크립팅) 공격이 여전히 가장 많이 발생하고 있습니다. 자주 접하는 웹 취약점(또는 공격?).

파일 업로드는 모든 보안 연구원이 선호하는 장소입니다. 침투 테스터라는 용어로 "쉘 로드"라는 용어로 임의의 스크립트(asp/jsp/php)를 로드하고 OS 명령을 실행할 수 있는 경우가 종종 있습니다. 그러나 이러한 취약점의 인기는 양방향으로 작용합니다. 즉, 취약점이 기억되고 이에 대한 해결책이 개발되므로 최근에는 "셸 로드" 확률이 XNUMX이 되는 경향이 있습니다.

공격팀(디지털시큐리티 대표)은 운이 좋았다. 좋습니다. 서버측 MCS에서 다운로드한 파일의 내용을 확인했는데 이미지만 허용되었습니다. 그러나 SVG는 그림이기도 합니다. SVG 이미지는 어떻게 위험할 수 있나요? JavaScript 코드 조각을 포함할 수 있기 때문입니다!

다운로드된 파일은 MCS 서비스의 모든 사용자가 사용할 수 있는 것으로 밝혀졌으며, 이는 다른 클라우드 사용자, 즉 관리자를 공격할 수 있음을 의미합니다.

피싱 로그인 양식에 대한 XSS 공격의 예

XSS 공격 악용의 예:

• 로드된 스크립트가 리소스 API에 즉시 액세스할 수 있다면 왜 세션을 도용하려고 합니까(특히 이제 HTTP 전용 쿠키가 어디에나 있고 js 스크립트를 사용하여 도용으로부터 보호되므로)? 이 경우 페이로드는 XHR 요청을 사용하여 서버 구성을 변경할 수 있습니다. 예를 들어 공격자의 공개 SSH 키를 추가하고 서버에 대한 SSH 액세스 권한을 얻을 수 있습니다.
• CSP 정책(콘텐츠 보호 정책)에서 JavaScript 삽입을 금지하는 경우 공격자는 이를 사용하지 않고도 통과할 수 있습니다. 순수 HTML을 사용하여 사이트에 대한 가짜 로그인 양식을 만들고 이 고급 피싱을 통해 관리자의 비밀번호를 훔칩니다. 사용자의 피싱 페이지는 동일한 URL로 끝나며 사용자가 이를 감지하기가 더 어렵습니다.
• 마지막으로 공격자는 다음과 같은 조치를 취할 수 있습니다. 클라이언트 DoS — 쿠키를 4KB보다 크게 설정합니다. 사용자는 링크를 한 번만 열면 되며 사용자가 특별히 브라우저를 정리하려고 생각할 때까지 전체 사이트에 액세스할 수 없게 됩니다. 대부분의 경우 웹 서버는 이러한 클라이언트를 수락하지 않습니다.

탐지된 또 다른 XSS의 예를 살펴보겠습니다. 이번에는 좀 더 영리한 익스플로잇을 사용합니다. MCS 서비스를 사용하면 방화벽 설정을 그룹으로 결합할 수 있습니다. 그룹 이름은 XSS가 감지된 곳이었습니다. 그 특징은 규칙 목록을 볼 때가 아니라 그룹을 삭제할 때 벡터가 즉시 트리거되지 않았다는 것입니다.

즉, 시나리오는 다음과 같이 나타났습니다. 공격자가 이름에 "load"가 포함된 방화벽 규칙을 생성하고 관리자는 잠시 후 이를 알아차리고 삭제 프로세스를 시작합니다. 그리고 이것이 악성 JS가 작동하는 곳입니다.

MCS 개발자가 업로드된 SVG 이미지에서 XSS로부터 보호하기 위해(생략할 수 없는 경우) 디지털 보안 팀은 다음을 권장합니다.

• 사용자가 업로드한 파일은 "쿠키"와 관련이 없는 별도의 도메인에 배치합니다. 스크립트는 다른 도메인의 컨텍스트에서 실행되며 MCS에 위협을 가하지 않습니다.
• 서버의 HTTP 응답에서 "Content-disposition: attachment" 헤더를 보냅니다. 그러면 파일이 브라우저에 의해 다운로드되고 실행되지 않습니다.

또한 이제 개발자가 XSS 악용 위험을 완화할 수 있는 다양한 방법이 있습니다.

• "HTTP Only" 플래그를 사용하면 악성 JavaScript가 세션 "쿠키" 헤더에 액세스할 수 없게 만들 수 있습니다.
• CSP 정책을 올바르게 구현했습니다. 공격자가 XSS를 악용하는 것을 훨씬 더 어렵게 만듭니다.
• Angular 또는 React와 같은 최신 템플릿 엔진은 사용자 데이터를 사용자 브라우저에 출력하기 전에 자동으로 삭제합니다.

이중 인증 취약점

계정 보안을 강화하려면 사용자에게 항상 2FA(XNUMX단계 인증)를 활성화하는 것이 좋습니다. 실제로 이는 사용자의 자격 증명이 손상된 경우 공격자가 서비스에 액세스하는 것을 방지하는 효과적인 방법입니다.

하지만 두 번째 인증 요소를 사용하면 항상 계정 안전이 보장되나요? 2FA 구현에는 다음과 같은 보안 문제가 있습니다.

• OTP 코드(일회성 코드)에 대한 무차별 검색. 운영의 단순성에도 불구하고 OTP 무차별 대입에 대한 보호 부족과 같은 오류는 대기업에서도 발생합니다. 슬랙 케이스, 페이스북 사례.
• 약한 생성 알고리즘(예: 다음 코드를 예측하는 기능)
• 자신의 휴대폰에서 다른 사람의 OTP를 요청하는 기능과 같은 논리적 오류는 다음과 같습니다. 있었다 Shopify에서.

MCS의 경우 Google Authenticator를 기반으로 2FA가 구현되며, 듀오. 프로토콜 자체는 이미 시간 테스트를 거쳤지만 애플리케이션 측의 코드 확인 구현은 확인해 볼 가치가 있습니다.

MCS 2FA는 여러 곳에서 사용됩니다.

• 사용자를 인증할 때. 무차별 대입에 대한 보호 기능이 있습니다. 사용자는 일회용 비밀번호를 몇 번만 입력하면 잠시 동안 입력이 차단됩니다. 이는 OTP의 무차별 선택 가능성을 차단합니다.
• 2FA를 수행하고 비활성화하기 위해 오프라인 백업 코드를 생성하는 경우. 여기서는 무차별 대입 보호가 구현되지 않았으므로 계정 및 활성 세션에 대한 비밀번호가 있는 경우 백업 코드를 재생성하거나 2FA를 완전히 비활성화할 수 있습니다.

백업코드가 OTP 애플리케이션에서 생성된 문자열 값과 동일한 범위에 위치했다는 점을 고려하면 단시간에 코드를 찾아낼 확률은 훨씬 높았다.

“Burp: Intruder” 도구를 사용하여 2FA를 비활성화하기 위한 OTP를 선택하는 과정

결과

전반적으로 MCS는 제품으로서 안전한 것으로 보입니다. 감사 중에 침투 테스트 팀은 클라이언트 VM 및 해당 데이터에 액세스할 수 없었으며 발견된 취약점은 MCS 팀에 의해 신속하게 수정되었습니다.

그러나 여기서 보안은 지속적인 작업이라는 점을 기억하는 것이 중요합니다. 서비스는 고정되어 있지 않으며 끊임없이 발전하고 있습니다. 그리고 취약점이 전혀 없는 제품을 개발하는 것은 불가능합니다. 그러나 제때에 찾아내고 재발 가능성을 최소화할 수 있습니다.

이제 언급된 MCS의 모든 취약점은 이미 수정되었습니다. 그리고 새로운 항목의 수를 최소한으로 유지하고 수명을 줄이기 위해 플랫폼 팀은 다음과 같은 작업을 계속합니다.

• 정기적으로 외부 회사의 감사를 실시합니다.
• 참여를 지원하고 발전시키다 Mail.ru 그룹 버그 바운티 프로그램에서;
• 보안에 종사하십시오. 🙂

출처 : habr.com