100만 달러 규모의 Vercel 샌드박스 챌린지 결과 보고

지난 8월에 저희는 보안 연구원들을 초대하여 Vercel Sandbox에서 탈출을 시도할 수 있는 기회를 열었습니다. 또한, 사이버 보안 전문가인 Trail of Bits와 협력하여 소스 코드 및 보안 아키텍처를 검토했습니다.Vercel Sandbox를 위한 100만 달러 해커 챌린지

챌린지의 요약은 다음과 같습니다:

보고된 내용 중 고객 데이터에 접근한 사례는 없었습니다. 가장 심각했던 발견은 상위(upstream) 리눅스 커널의 결함이었습니다.

가장 중요한 보고서는 3일째에 도착했습니다.

HackerOne 연구원인 (pwn.ai)는 특별한 접근 권한이 없는 표준 샌드박스 환경에서 작업하며 리눅스 커널의 네트워킹 스택 결함을 발견했습니다. Paulos는 마이크로VM(microVM) 내부에서 전송된 특수하게 제작된 패킷을 통해 세 가지 다른 공격이 가능하다는 것을 알아냈습니다:Paulos Yibelo

첫 번째 공격에서는, 샌드박스가 여러 테넌트와 공유하는 머신인 호스트의 메모리가 게스트가 인터넷을 통해 전송하는 패킷에 나타나는 현상이 발견되었습니다. 이 현상은 게스트가 계속해서 데이터를 전송하는 한 지속적으로 발생할 수 있습니다.

이 공격은 Vercel 프로덕션 샌드박스를 대상으로 시연되었습니다.

연구원은 또한 특정 패킷을 보내 호스트를 손상시킬 수 있다는 점도 발견했습니다.

첫째, 두 개의 패킷을 전송하여 연구원 자신의 KVM 및 Firecracker 머신과 Vercel Sandbox 구성이 일치하는 환경에서 호스트 머신을 충돌시켜 모든 샌드박스를 다운시키는 것이 가능했습니다. 둘째, 동일한 결함을 사용하여 호스트에서 완전한 관리자 권한으로 명령을 실행할 수 있었으며, 이는 샌드박스의 격리 경계를 벗어나는(breaking out) 것을 의미합니다.

패킷 관련 충돌 및 코드 실행 공격은 연구원 자신의 KVM 및 Firecracker 머신과 Vercel Sandbox 구성이 일치하는 환경에서 시연되었습니다.

거의 모든 주요 클라우드 제공업체는 고객 워크로드를 이와 동일한 리눅스 커널 계층에서 격리하고 있으므로, 어떤 결함이라도 공유 인프라 위험(shared-infrastructure risk)으로 간주됩니다.

알림을 받은 직후, 우리는 연구원과 협력하여 취약점을 이해하고 완화하는 작업을 진행했으며, AWS 및 다른 업계 파트너들과 함께 수정 사항의 우선순위를 정하고 Vercel 고객 및 커널을 사용하는 다른 개발자들이 안전한지 확인했습니다.

연구원은 또한 커널 유지 관리자들에게 연락하여 그들과 협력해 후보 패치를 만들었습니다. 수정 사항은 비공개 검토 단계에 있으며 CVE는 아직 대기 중이므로, 패치가 공개될 때까지 추가 세부 정보를 게시하지 않을 것입니다. 우리는 이 취약점이 별도로 공개되었기 때문에 그 존재를 밝히고 있습니다.

HackerOne 챌린지는 모든 연구원에게 바운티를 제공했지만, 우리는 내부 평가와 독립적인 조사를 포함하도록 프로그램 범위를 확장했습니다.

공개 바운티를 시작하기 전에, 우리는 Vercel Sandbox를 생성하고 유지 관리하는 엔지니어들의 지원을 받아 전체 소스 접근 권한으로 내부 실시간 보안 평가를 수행했습니다. 또한 Trail of Bits와 협력하여 두 명의 엔지니어를 투입해 우리의 보안 아키텍처를 평가하게 했습니다.

모든 발견이 외부에서 온 것은 아니었습니다. Vercel 인턴인 Marcos Hernanez가 Linux device-mapper 스토리지 계층에서 크로스 테넌트 데이터 유출을 발견했습니다. 이 취약점은 임의의 샌드박스가 이전에 삭제된 샌드박스로부터 재활용된 디스크 블록을 읽을 수 있게 했습니다.

Trail of Bits는 우리의 소스 코드 내부에서 네 엔지니어 주(engineer-weeks)를 보내며, 저장소에 대한 전체 접근 권한과 두 개의 기업 테스트 팀을 활용했습니다. 그들은 20개의 발견 사항을 전달했고, 각 항목은 테스트되고 확인되었으며 정확한 코드를 참조하여 기록되었습니다.

그들은 또한 아키텍처 검토를 수행했으며 우리의 가상화 경계가 견고하다고 결론지었습니다. 각 샌드박스는 전용 게스트 커널을 가진 자체 Firecracker microVM에서 실행되며, 디바이스 모델은 의도적으로 작습니다. 어떤 게스트도 호스트나 다른 테넌트와 실행 중인 커널을 공유하지 않습니다.

이러한 기반 위에 그들은 세 가지 구조적 권장 사항을 제시했고, 우리는 이를 구현했습니다:

2주 동안 1,285건의 보고서를 받았습니다. 이러한 양은 연구자들이 이제 AI 속도로 탐색하기 때문에 가능했습니다.

보고서 카테고리별 분석은 다음과 같습니다:

저희의 보고서 분류 과정에서 다음 사항들을 검증했습니다:

버그 바운티로 총 $242,000를 지급했습니다.

중간(medium), 낮음(Low), 정보 제공적(Informative) 발견 사항들은 방화벽 규칙이 문서화된 것과 다르게 작동했거나, 필드가 필요 이상으로 게스트(guest)를 신뢰하는 것 같은 작은 정책 경계상의 허점들이었습니다.

가장 심각한 발견은 Linux 커널의 제로데이 결함이었으며, 보고서에는 고객 파일, 비밀 정보 또는 애플리케이션 데이터를 읽었다는 내용은 없었습니다.

저희는 보고서들의 이질성(heterogeneity)에 가장 깊은 인상을 받았습니다. 연구자들이 서로 다른 설정과 각기 다른 집착을 가지고 접근했다는 것이 명확했습니다. 어떤 사람들은 리눅스 네임스페이스(Linux namespaces)를 분명히 알고 에이전트를 커널 경계로 곧장 유도했습니다. 또 다른 사람들은 네트워크 정책을 겨냥했고, 많은 사람들은 저희가 메뉴에 올릴 거라고 생각지 못한 영역들을 공략했습니다.

바로 이러한 다양성이 공개 챌린지를 통해 자금을 지원하는 것입니다. 이 보고서 중 흥미로운 예시를 하나 소개합니다.

이 보고서는 챌린지 첫날 제출된 것으로, 내부 평가와 화이트박스(white-box) 참여 이후에도 저희가 왜 공개 버그 바운티를 운영하는지에 대한 가장 좋아하는 사례입니다.

샌드박스를 스냅샷(snapshot)할 때, 컨트롤 플레인(control plane)은 스냅샷 데이터가 어디에 저장되었는지 기록해야 합니다: {storage_url, size, checksum}. 연구자가 발견한 결함은 미묘했습니다. 그 답변이 게스트 내부에서 실행되는 소프트웨어에서 나왔고, 호스트(host)에서 실행되는 서비스들이 이를 신뢰했다는 점입니다. 이것은 신뢰 경계 위반(trust-boundary violation)입니다. 게스트는 저희 고객들(그리고 해커들)이 신뢰할 수 없는 코드를 실행하는 곳이므로, 호스트가 그 말을 권위 있는 것으로 받아들일 수는 없습니다.`}```jsoncoyn{

연구원은 각 계정이 다른 계정의 파일을 읽고 수정할 수 있음을 시연했으며, 해시를 사용하여 결과를 검증하고 테스트 리소스를 보존하여 우리가 발견 내용을 독립적으로 재현할 수 있도록 했습니다.

이 공격의 한계가 중요합니다. 특정 피해자를 대상으로 스와핑을 하려면 그 피해자의 내부 스냅샷 저장 키(internal snapshot storage key)를 알아야 하는데, 이는 플랫폼이 스냅샷당 생성하는 임의의 96비트 식별자이며 API를 통해 절대 노출되지 않습니다. 이 키가 나타나는 유일한 곳은 피해자 자신의 샌드박스 내부입니다. 연구원은 두 계정 모두를 소유하고 있었기 때문에 이러한 증명이 가능했으며, 외부인이 다른 테넌트를 대상으로 삼을 수 있는 경로는 입증되지 않았습니다. 하지만 비밀이 비밀로 유지되는 것에 의존하는 경계는 진정한 경계가 아니므로, 우리는 여전히 이를 최우선 수정 사항으로 다루었습니다.

Trail of Bits도 자체 평가에서 동일한 근본 원인(root cause)을 지적했으며, 이는 우리가 완전히 다른 두 각도에서 발견된 내용이 실제로 중요하고 발견 가능한 사실임을 알려주었습니다.

수정 사항은 일주일 내에 배포되었고, 제어 평면(control plane)은 이제 모든 스냅샷 객체를 생성한 프로젝트에 바인딩하며 다른 것을 거부합니다. 스냅샷 생성은 게스트가 접근할 수 있는 환경에서 호스트 측 서비스로 이동했으며, 저장 경로는 엄격하게 검증된 URL을 가진 프로젝트 범위(project-scoped)를 따릅니다.

제로데이 취약점이든 중복 발견이든 보고서를 제출한 모든 연구원에게 감사드립니다. 챌린지에서 발견된 모든 기술은 Vercel Sandbox에서 실행되는 워크로드를 보호하는 방법에 정보를 제공합니다.

또한 포괄적인 내부 조사와 지도를 제공해 준 Trail of Bits에도 감사를 전합니다.

Vercel Sandbox에 대한 더 많은 정보는 원래 챌린지 공지에서 확인하고, 문서(documentation)를 참고하십시오.

더 읽기

• 2주 동안 1,285개의 리포트 제출

  • $242,000 상당의 바운티 지급
  • Linux 커널 제로데이 취약점 1건 발견

• 당사의 컨트롤 플레인(control plane)은 마이크로VM 내부에서 실행되는 소프트웨어가 반환하는 값을 수용했으며, 이 값들은 모두 테넌트 입력값입니다. 경계를 넘는 모든 것은 서버 측에서 파생되거나 게스트가 접근할 수 없는 키로 서명되어야 합니다.게스트에 대한 신뢰를 찾고 제거하십시오.

  • Egress enforcement(외부 전송 제한)는 동일한 네트워크 정책을 독립적으로 구문 분석하는 여러 하위 시스템에 분산되어 있었으며, 항상 일치하지 않았습니다. 이제 데이터 유형별로 하나의 표준화 루틴(canonicalization routine)을 사용하고, 결정당 하나의 컴포넌트를 사용하며, 정책이 변경될 때 연결을 재검증합니다.하나의 정책, 하나의 결정자입니다.
  • 공격자가 가상화 소프트웨어를 악용할 경우 피해를 제한하기 위해 각 샌드박스 주변 보호 기능을 강화했습니다. 호스트 커널은 최신 상태로 유지하고, 중첩 가상화(nested virtualization)는 비활성화했으며, Firecracker의 jailer를 사용하여 각 마이크로VM 프로세스를 제한된 권한으로 실행하고 나머지 호스트와 격리합니다.다음 제로데이도 가정하십시오.

• 877개 중복 항목

  • 319개 해당 없음(not applicable)
  • 57개 유효(valid)
  • 32개 정보 제공(informative)

• 1건의 Critical 취약점 발견

  • 5건의 High 취약점 발견
  • 9건의 Medium 취약점 발견
  • 42건의 Low 취약점 발견
  • 32건의 Informative 취약점 발견

커널 제로데이

Vercel 샌드박스 압력 테스트 접근 방식

화이트박스 심층 분석

Vercel 샌드박스 발견 사항

연구 커뮤니티에 감사드립니다

1. 호스트 메모리를 네트워크를 통해 유출
   • 호스트 머신 충돌 및 호스트에서 코드 실행

호스트 메모리 유출

호스트 충돌 및 호스트에서 코드 실행

커널 취약점 책임감 있는 공개

크로스-테넌트 디스크 스냅샷 복원 (제한 사항 포함)