Reddit

Critical RCE Alert: Full takeover of HashiCorp Vault and OpenBao. OpenBao is patched. Vault remains exposed

HashiCorp Vault·OpenBao에서 인증 없이 원격 코드 실행 — OpenBao는 패치, Vault는 여전히 취약

ControlPlane은 OpenBao에서 인증 없이 시작해 원격 코드 실행까지 이어지는 취약점 조합을 공개했습니다. OpenBao는 v2.6.3과 v2.7.0에서 수정했지만, 글 게시 시점에 HashiCorp Vault는 아직 패치되지 않았다고 밝혔습니다.

에디터 노트

비밀을 지키는 금고가 털렸다는 게 이 기사의 표면입니다. 더 심각한 건 그 다음입니다. OpenBao는 패치했지만 Vault는 아직 취약합니다. 코드를 공유하는 포크 사이인데 공개 조정 합의는 없습니다. 같은 구멍을 공유하면서 서로에게 알리지 않는 구조입니다. 네 개의 취약점은 각각 제보됐지만, 엮이자 인증 없는 원격 코드 실행이 됐습니다. 개별 CVSS 점수만 보고 우선순위를 매기면 놓치는 게 바로 이런 체인입니다. 금고를 쓴다면 지금 확인할 건 하나입니다. 우리 Vault가 외부에서 닿는가.

AI 요약

ControlPlane은 OpenBao 커뮤니티와 함께 인증되지 않은 접근을 원격 코드 실행(RCE)으로 연결하는 공격 경로를 수정했다고 밝혔습니다. 이번 릴리스는 여러 해 동안 OpenBao와 Vault에 남아 있던 취약점도 함께 다룹니다. 공개된 공격 체인은 독립적으로 제보된 취약점 네 건을 엮었으며, OpenBao는 v2.6.3과 v2.7.0에서 수정했습니다. 글 게시 시점에 HashiCorp Vault는 아직 수정되지 않았다고 설명합니다.

SPIFFE 인증 환경에서 시작하는 공격

글은 SPIFFE(Secure Production Identity Framework for Everyone) 자격 증명과 OpenBao의 Certificate Auth, PKI를 함께 쓰는 환경을 사례로 듭니다. 서비스 프로비저너는 애플리케이션용 인증 역할을 만들고, 애플리케이션은 OpenBao가 발급한 인증서로 비밀 정보를 읽습니다. 이때 제한된 권한만 가진 프로비저너와 샌드박스 네임스페이스가 공격의 출발점이 됩니다.

공격자는 먼저 PKI의 ACME 검증 우회 취약점으로 자신이 고른 URI SAN을 담은 인증서와 키를 얻습니다. 이를 이용해 서비스 프로비저너로 인증한 뒤, 비정규 URL 경로를 이용한 ACL 우회로 관리자 역할의 URI SAN 조건을 바꿉니다. 관리자로 다시 인증하면 네임스페이스 경계를 넘어 루트 네임스페이스의 정책에 접근하도록 토큰 정책을 수정할 수 있습니다. 마지막으로 Raft 스냅샷 복원 권한을 얻어 공격자가 만든 스냅샷을 복원하고, 자신의 키로 노드를 해제해 원격 코드 실행에 이릅니다.

공격 체인을 이룬 취약점

  • GHSA-j6wc-jpvg-xfxq, CVSS v4 9.4: 스냅샷 복원을 통한 원격 코드 실행입니다.
  • GHSA-x8fg-h69x-p28f, CVSS v4 8.2: PKI의 ACME 검증을 우회합니다. URI SAN 검증이 필요한 SPIFFE 인증서 환경에서 악용될 수 있습니다.
  • GHSA-mjch-vcw3-hhmf, CVSS v4 7.7: 네임스페이스 사이의 정책 접근을 허용합니다.
  • GHSA-fg5x-7whg-6c28, CVSS v4 7.6: 비정규 URL을 이용해 ACL 거부 규칙을 우회합니다.

ControlPlane은 이번 RCE가 지난해 공개된 취약점보다 영향 범위가 크다고 설명합니다. 플러그인 디렉터리에 파일을 쓰거나 설정된 플러그인 경로를 이용하지 않아도 기존 바이너리를 실행 대상으로 삼습니다. 공격자는 여러 바이너리 경로와 SHA-256 체크섬 후보를 한 번의 시도에 넣을 수 있습니다. Raft 스냅샷 강제 복원 API에 접근할 수 있는 환경이라면 스토리지 백엔드 조작을 통해 공격 경로가 열릴 수 있다고 덧붙입니다.

대응과 공개 일정

가장 확실한 대응은 OpenBao를 패치 버전으로 업그레이드하는 것입니다. 플러그인을 전부 끄거나 BAO_DISABLE_PUBLIC_ACME 환경 변수로 ACME에 외부 계정 바인딩(EAB)을 요구하는 우회책도 제시했지만, 각각 기존 플러그인 사용을 막거나 운영 설정을 바꾸는 부담이 있습니다. ACME 취약점은 조직에서 URI SAN을 얼마나 사용하는지에 따라 영향이 달라집니다.

취약점은 9월 4일부터 17일 사이 여러 연구자가 제보했고, OpenBao는 9월 23일 v2.6.3과 v2.7.0을 배포했습니다. ControlPlane은 다음 날 전체 공격 체인의 개념 증명(PoC)을 만들었다고 밝혔습니다. HashiCorp와 OpenBao 사이에 상호 공개 조정 합의가 없어 Vault 이용자는 수정 사항이 마련되지 않은 채 영향을 받았다고 글은 지적합니다. 공개된 취약점 다수는 AI가 발견했거나 AI 발견으로 추정되지만, 오탐과 문제 범위를 과소평가한 사례도 있었다고 덧붙입니다.

Reddit 반응

  • @u/thrilla_gorilla — 이 특정 구성으로 스택을 실제 운영하는 두 조직은 정말 곤란해지겠네요.
    • @u/real-cipherboy — 결국 상황에 달렸습니다. 해당 릴리스에는 공격자가 다른 곳으로 이동할 때 쓸 도구가 더 있습니다. RCE 자체는 꽤 일반적이라 거의 모든 이용자에게 영향을 줍니다. HashiCorp가 공식 지원하는 스토리지 백엔드는 Raft와 경우에 따라 Consul뿐이라 그 부분의 영향도 상당합니다. 인증 없이 공격을 시작하는 부분은 아마 더 적은 이용자에게 해당합니다.
  • @u/dlp_randombk — 이건 ‘OpenBao와 Vault’ 문제인가요, 아니면 ‘OpenBao 또는 Vault’ 문제인가요? 기본 독립형 구성의 Vault도 영향을 받나요?
    • @u/GrandWizardZippy — OpenBao는 HashiCorp Vault의 오픈소스 포크입니다. OpenBao와 Vault를 함께 쓰는 게 아닙니다. 수정: 글에도 Vault는 여전히 취약하고 OpenBao는 이미 패치됐다고 분명히 나와 있습니다.

원문: ControlPlane / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗