Vercel 해킹 사고 — 서드파티 AI OAuth 앱 탈취로 내부 침투, 환경변수 평문 노출

• Vercel이 내부 시스템 침해 사고를 공식 확인함 — 공격자가 "ShinyHunters"를 자처하며 해킹 포럼에서 탈취 데이터를 판매 중
  • 포럼 글에는 employee accounts, 내부 deployment 접근 키, API 키(NPM 토큰·GitHub 토큰 포함) 판매 문구가 올라옴
  • 증빙으로 직원 580명의 이름/Vercel 이메일/계정 상태/활동 타임스탬프가 담긴 텍스트 파일과 내부 Enterprise 대시보드 스크린샷이 공개됨
  • 텔레그램에서는 공격자가 200만 달러 몸값 협상 중이라고 주장 (Vercel은 미확인)
• 자칭 ShinyHunters라지만, 최근 ShinyHunters 공격에 연루된 다른 행위자들은 이번 건과 무관하다고 BleepingComputer에 부인함
  • 즉, 같은 브랜드를 쓰는 서로 다른 팀일 가능성 — 커뮤니티 내 credit 다툼 느낌
• Vercel 서비스 자체는 영향 없음 — Next.js, Turbopack 등 오픈소스 프로젝트도 안전하다고 못박음

침투 경로 — 서드파티 AI 도구의 OAuth 앱이 첫 단추

• CEO Guillermo Rauch가 X에서 공개한 상세: 최초 침투는 Context.ai라는 AI 플랫폼의 보안사고 경유
  • Context.ai가 뚫리면서 Vercel 직원의 Google Workspace 계정이 compromise 됨
  • 공격자는 이 계정을 발판으로 Vercel 내부 환경까지 권한을 확장함
• 문제의 OAuth 앱 ID까지 공개됨 — 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
  • Google Workspace 관리자라면 지금 당장 이 OAuth 앱이 승인돼 있는지 확인해보는 걸 권장

sequenceDiagram
    participant 공격자
    participant ContextAI as Context.ai(OAuth 앱)
    participant 직원계정 as Vercel 직원 Workspace 계정
    participant Vercel as Vercel 내부 환경
    공격자->>ContextAI: Context.ai 시스템 침해
    ContextAI->>직원계정: OAuth 권한 탈취
    공격자->>직원계정: Google Workspace 계정 접근
    직원계정->>Vercel: 내부 환경으로 권한 에스컬레이션
    공격자->>Vercel: non-sensitive 환경변수 enumerate
    Vercel-->>공격자: 평문 저장된 변수값 노출

핵심 실책 — "non-sensitive" 플래그 환경변수의 평문 저장

• Rauch의 설명: 모든 고객 환경변수는 기본적으로 at-rest 암호화 되지만, 예외적으로 "non-sensitive"로 지정한 변수는 암호화되지 않음
  • 원래 의도는 "민감하지 않은 정보만 담는 칸"이라는 개발자 편의용 옵션
  • 공격자가 이 변수들을 enumerate 하면서 추가 접근 경로를 확보함
• 즉, 개발자가 "이건 안 민감하니까" 하고 넣은 값들 중에 실제로는 민감했던 것들이 있었다는 얘기
  • 토큰 prefix, 내부 URL, API endpoint 같은 게 이런 식으로 새는 전형적인 경로
• Vercel은 대시보드에 환경변수 오버뷰 페이지와 민감 변수 관리 UI를 업데이트해서 롤아웃함

Vercel이 고객에게 권고한 조치

• 환경변수 전체 감사 — 민감 정보가 non-sensitive로 섞여 있는지 점검
• sensitive environment variable 기능 활성화로 at-rest 암호화 강제
• 필요 시 secret rotation
• Google Workspace 관리자는 문제의 OAuth 앱 승인 여부 확인

기술 맥락

이번 사고의 기술적 뿌리는 OAuth 기반 서드파티 통합의 확산이에요. Google Workspace에 붙이는 AI 도구들이 수십 개씩 있고, 각각이 Workspace 계정 권한 일부를 위임받아 쓰거든요. Context.ai 같은 AI 플랫폼 하나가 뚫리면, 그 OAuth 토큰으로 연결된 모든 조직의 Workspace가 도미노처럼 영향을 받는 구조예요. 그래서 이번 건의 교훈은 "내부 보안 잘 챙기는 걸로는 부족하다"는 거예요 — 써드파티 앱 카탈로그를 주기적으로 정리하고, 불필요한 OAuth 승인은 즉시 회수해야 해요.

두 번째 포인트는 at-rest encryption 디폴트의 중요성이에요. Vercel은 환경변수를 기본적으로 암호화하지만, 개발자 편의를 위해 "이건 민감하지 않음" 옵션을 뒀거든요. 이런 opt-out 형태의 보안 옵션은 늘 위험해요. 개발자는 급할 때 "뭐 이건 괜찮겠지" 하면서 체크하는데, 실제로 공격자 관점에서는 URL·endpoint·토큰 prefix 조각조각이 다 유용한 정찰 정보예요. 그래서 요즘은 "secret은 무조건 암호화, 비밀 아닌 것만 명시적으로 public으로 표시" 하는 allow-list 방식이 권장돼요.

마지막으로 권한 에스컬레이션 방지가 핵심이에요. Workspace 계정 하나가 뚫린 것만으로 프로덕션 환경까지 들어갔다는 건, 내부 접근 권한이 수평적으로 너무 넓게 퍼져 있었다는 뜻이거든요. zero-trust 관점에서는 개별 엔지니어 계정이 프로덕션 secret을 직접 볼 수 있으면 안 되고, 꼭 필요할 때만 just-in-time으로 임시 권한을 부여해야 해요. 이번 사고처럼 하나 뚫리면 전체가 위험해지는 걸 막으려면요.