해커가 마이크로소프트 클라우드에 있는 전 세계 고객 데이터베이스를 통째로 여는 ‘마스터키’를 손에 넣는다면 어떤 일이 벌어질까요? 다행히 이번엔 실제로 벌어지지 않았습니다. 하지만 그런 키가 실제로 존재했고, 무려 8개월 동안 이론적으로는 작동할 수 있는 상태였다는 사실이 지난 30일 공개됐습니다. 이름은 ‘코스모스이스케이프(CosmosEscape)’. 마이크로소프트의 대표 클라우드 데이터베이스 서비스인 애저 코스모스DB(Azure Cosmos DB)를 겨냥한 코스모스DB 취약점입니다.
그저께 다룬 브링크스 홈 해킹, 어제 다룬 미국 수도 시설 사고와 마찬가지로 이번에도 겨냥당한 건 ‘눈에 잘 안 보이는 인프라’라는 공통점이 있습니다. 다만 이번엔 실제 침해가 일어난 게 아니라, 보안 연구팀이 먼저 찾아내 마이크로소프트와 함께 조용히 막아낸 사례라는 점이 다릅니다.
그렘린 API 하나로 시작된 침입 경로
이 취약점을 발견한 곳은 클라우드 보안업체 위즈(Wiz)입니다. 코스모스DB가 지원하는 여러 쿼리 언어 중 그래프 데이터를 다루는 ‘그렘린(Gremlin)’을 테스트하던 중, 연구팀은 이상한 .NET 오류 메시지를 발견했습니다. 보통 그렘린 서버는 JVM 기반인데, 이 오류는 코스모스DB가 자체 개발한 그렘린 엔진을 쓰고 있다는 걸 암시했습니다.
문제는 여기서 시작됩니다. 이 엔진은 그렘린 쿼리를 .NET 코드로 변환해 제한된 환경(샌드박스) 안에서 실행하는데, 이 제한이 ‘.NET 리플렉션’이라는 기법까지는 막지 못했습니다. 연구팀은 이 틈을 이용해 파일을 읽고 쓰는 수준을 넘어 임의 코드까지 실행하는 데 성공했습니다. 자기 소유의 데이터베이스에 쿼리 하나를 던졌을 뿐인데, 코스모스DB의 내부 서버에서 명령어가 실행된 겁니다.
이렇게 확보한 코드 실행 권한으로 도달한 곳이 ‘DB 게이트웨이’라는 다중 테넌트 서버였습니다. 이 서버는 고객의 쿼리를 대신 처리해주는 역할을 하는데, 그 과정에서 대상 계정의 ‘프라이머리 키'(해당 계정 전체에 대한 완전한 읽기·쓰기 권한)를 가져올 수 있었습니다. 문제는 이 키를 가져오는 서명키 자체가 특정 계정 하나에 묶여 있지 않았다는 점입니다. 리전과 테넌트, SQL·몽고DB·카산드라·그렘린 같은 API 종류를 가리지 않고 통했습니다. 위즈는 이 서명키를 ‘코스모스 마스터키’라고 이름 붙였습니다.
여기에 더해 이 마스터키는 ‘컨피그 스토어’라는 계정 디렉터리까지 열 수 있었습니다. 여기엔 구독 ID, 테넌트 ID 같은 식별자가 저장돼 있어서, 특정 회사나 조직의 계정을 콕 집어 찾아낸 다음 그 계정의 키를 요청하는 것도 이론상 가능했습니다.
팀즈·코파일럿까지 위험했던 이유
코스모스DB는 마이크로소프트 자사 서비스에서도 폭넓게 쓰이는 인프라입니다. 마이크로소프트 엔트라ID, 팀즈의 메시지 데이터, 코파일럿의 대화 기록까지 이 서비스 위에 저장된다고 마이크로소프트 자체 기술 문서에 나와 있습니다. 위즈는 이런 내부 서비스의 데이터베이스도 이론상 접근 대상이었을 수 있다고 밝혔지만, 실제로 접근했다고 보고하지는 않았습니다.
네트워크가 외부와 격리된 이른바 ‘프라이빗’ 계정도 예외는 아니었습니다. 네트워크 격리 자체를 DB 게이트웨이가 담당하는 구조였다 보니, 게이트웨이가 뚫리면 격리 설정도 함께 무력화될 수 있었던 셈입니다. 클라우드는 여러 층으로 쌓여 있고, 코스모스DB처럼 맨 아래 인프라 층에 구멍이 나면 그 위에 올라간 모든 서비스가 함께 흔들릴 수 있다는 걸 보여주는 사례입니다.
8개월의 타임라인
위즈는 2025년 11월 20일 이 취약점을 마이크로소프트에 신고했고, 마이크로소프트는 접수 당일 이를 인지했습니다. 이틀 뒤인 11월 22일에는 문제가 된 그렘린 진입점을 차단하는 임시 조치를 48시간 만에 배포했습니다. 이후 마이크로소프트는 근본적인 아키텍처 개편 작업에 들어갔고, 2026년 7월 전 리전에 걸쳐 이 작업을 마무리하면서 마스터키 자체를 완전히 없앴습니다. 그리고 7월 30일, 위즈가 기술적인 세부 내용을 공개했습니다. 다음 주인 8월 6일에는 블랙햇 USA 컨퍼런스에서 전체 공격 체인이 공개될 예정입니다.
마이크로소프트는 접근 로그를 전수 조사한 결과 위즈의 테스트 활동 외에 다른 무단 접근 흔적은 발견되지 않았다고 밝혔습니다. 고객 데이터에 접근한 정황도 없었다고 하고요. 그래서 마이크로소프트는 코스모스DB를 쓰는 고객이 따로 취해야 할 조치는 없다고 공지했습니다. 이 발표를 그대로 믿는다면, 지금 당장 뭔가를 확인하거나 바꿀 필요는 없다는 뜻입니다.
침묵하지 않은 8개월
이번 주에 다룬 다른 사고들과 비교하면 흥미로운 지점이 하나 있습니다. 며칠 전 다룬 EY나 앞서 다룬 수노(Suno) 사고는 실제 침해가 있었는데도 회사가 몇 달간 이를 외부에 알리지 않아서 문제가 됐죠. 이번 코스모스DB 건도 신고부터 공개까지 똑같이 8개월이 걸렸지만 성격은 정반대입니다. 실제 피해가 없는 상태에서, 마이크로소프트와 위즈가 완전한 수정을 끝낼 때까지 일부러 세부 내용을 감춘 ‘책임있는 공개(Responsible Disclosure)’ 관행을 지킨 결과였으니까요. 같은 ‘몇 개월간 비공개’라도 이유에 따라 전혀 다른 이야기가 될 수 있다는 걸 보여주는 사례입니다.
물론 이번 사고에도 아쉬운 지점은 있습니다. 코스모스DB의 그렘린 엔진이 정확히 언제부터 이런 구조로 운영됐는지, 즉 노출 가능 기간이 언제부터였는지는 공개된 자료만으로는 알 수 없습니다. 위즈와 마이크로소프트 모두 로그 조사 대상 기간을 구체적으로 밝히지 않았고요. “지금까지 확인된 바로는 문제없다”는 것과 “처음부터 문제없었다”는 건 조금 다른 이야기이기도 합니다.
출처
함께 보면 좋은 글
- 미국 수도 시설 해킹, 미네소타 등 7개 주 30여 곳 동시에 뚫렸다
- 브링크스 홈 해킹, 전화 한 통에 세일즈포스 정보 490만 건 털렸다
- EY 해킹, 세무자료 유출 최소 1,366명…내일 전면 공개 예고
국내 기업 금융 보안 조직 8년차. 취약점 진단과 보안 기획 업무를 하며, 업계 밖에서는 잘 안 보이는 보안 이야기를 정리하고 있습니다. 개인 자격으로 쓰며 소속 조직과 무관합니다.