Security

MS, 애저 엔트라ID의 초고위험도 취약점 패치 완료

문가용 기자

Published: 17:11, 24 Sep 2025 (Updated: 12:42, 05 Oct 2025)

💡

Editor's Pick
- 이전에 액티브 디렉토리라 불렸던 엔트라 ID
- 인증 토큰과 오래된 API의 설계 오류 결합하면 무서운 일 발생
- 클라우드에의 종속성 문제, 깊이 고민해야

MS가 애저(Azure)에서 발견된 보안 취약점을 패치했다. 하지만 패치 이후 연구를 통해 해당 취약점이 이전에 알려진 것보다 훨씬 더 위험한 것이었음이 드러났다. 이 취약점은 CVE-2025-55241로, 익스플로잇에 성공한 공격자는 임의의 사용자로 스스로를 위장할 수 있게 해 준다고 한다. 이 ‘임의의 사용자’ 안에는 전역 관리자(global administrator)도 포함돼 있다.

취약점 위치와 발견자
취약점의 정확한 위치는 애저의 엔트라ID(Entra ID)다. 원래는 애저 액티브 디렉토리(Azure Active Directory)로 불렸지만, 2023년 7월부터 엔트라ID로 바뀌었다. 클라우드 기술을 기반으로 ID와 접근 권한을 관리한다. 인증과 관련된 요소들에서 발견되는 취약점은 거의 언제나 고위험군으로 분류되는데, 이번 취약점 역시 CVSS 기준 9.8점을 받았을 정도로 위험하다. 9.8점은 초고위험도다.

보안 연구원인 더그얀 몰레마(Dirk-Jan Mollema)라는 인물이 처음 발견한 것으로, “행위자 토큰(Actor token)과 오래된 애저 AD 그래프 API(Azure AD Graph API)의 검증 실패 취약점이 결합했을 때 발동된다”고 한다. 여기서 말하는 ‘행위자 토큰’은 따로 문서화 되지 않은 것이라 잘 알려져 있지 않은데, “엔트라ID 내부 요소 간 통신을 위해 만들어진 특수 토큰”이라고 한다. “백엔드 서비스끼리 안전하게 연결시키기 위한, 일종의 기계 대 기계 인증 토큰이라고 할 수 있습니다.”

액티브 디렉터리에 해당되는 인증 시스템 내 중요 인증 토큰에서 문제가 발견됐으니 큰 문제가 아닐 수 없다. “공격자가 전역 관리자로 로그인해서 권한을 갖추게 된다면 애저 내 여러 테넌트를 오가며 각종 행위를 할 수 있게 됩니다. 데이터 조회만 해도 경고가 뜨지 않고 흔적도 남지 않습니다. 데이터를 조작해도 최소한만의 흔적이 남죠. 대단히 위험한 일이 발생할 수 있는 상황이었던 겁니다.” 몰레마의 설명이다.

행위자 토큰과 애저 AD 그래프 API의 설계 결함
취약점은 왜 거기에 있던 걸까? 몰레마는 설계 자체에 문제가 있다고 설명한다. “백엔드 서비스 간 통신을 위한 토큰이기 때문에, 일반적으로 설정돼 있는 접근 보호 기능들을 우회할 수 있게 되어 있습니다. 최대 24시간 이상 유효하기 때문에 탈취한 사람이 하루는 쓸 수 있습니다. 24시간 유효하다는 건, 그렇게 설정된 시간 안에는 토큰을 폐지시키지도 못한다는 뜻입니다. 즉 처음부터 하루를 쓸 수 있도록 되어 있으면 누가 어떻게 해도 하루는 유지된다는 겁니다.”

그렇다면 이 특성과 결합했을 때 더 큰 문제를 일으킬 수 있다는 애저 AD 그래프 API의 검증 실패 취약점은 무엇일까? 한 마디로 로그 기능을 제공하지 않는다는 것이다. 몰레마가 자신의 블로그에 설명한 바에 따르면 “로그 기능이 없기 때문에 관리자가 무엇을 열람하거나 변경하든 전혀 알 수 없다”고 한다. 즉 백엔드 인증 토큰을 탈취하기만 하면 기록이 남는다는 걱정 없이 악용할 수 있다는 의미가 된다. “게다가 애저 AD 그래프 API는 해당 토큰이 어느 테넌트에서 발급됐는지도 확인하지 않습니다. 그렇기에 애저 내 여러 테넌트를 한꺼번에 공격할 수 있게 되는 겁니다."

MS도 사안의 심각성 인정
몰레마가 이 내용을 처음 발견한 건 지난 여름에 열린 블랙햇 때다. 발표 자료를 준비하다가 취약점에 대해 알게 됐다고 한다. 그리고 MS에 보고서를 제출한 건 7월 14일이다. MS는 3일 후인 17일, 패치를 배포하기 시작했다. 또한 애저 AD 그래프 관련 애플리케이션이 행위자 토큰을 요청하지 못하도록 수정하기도 했다. 이런 기본 작업이 다 끝난 9월 4일, 취약점에 CVE-2025-55241이라는 공식 번호가 부여됐다.

클라우드 환경의 취약점이고 패치였기 때문에 특별히 사용자들이 할 일은 없다. MS가 애저 관련 모든 시스템을 자체적으로 패치하면, 사용자는 자연스럽게 패치된 버전을 사용하게 된다. 거의 모든 클라우드 관련 취약점이 이런 식으로 사용자의 개입을 요하지 않는다. 이는 클라우드의 사소한 장점 중 하나다. 개인에게 패치 적용을 맡기면 잘 되지 않는 경우가 많다.

그러나 사용자가 패치하지 않아도 된다는 건, 거꾸로 말해 사용자가 다 제어하지 못하는 것들이 존재한다는 의미이며, 따라서 단점도 될 수 있다. 즉 ‘편리’와 ‘제어권 박탈’로 구성된 양날의 검과 같다. 이번 CVE-2025-55241 사태에서 볼 수 있듯이, 사용자가 모르는 요소들이 클라우드 내에 얼마나 존재하는지 아무도 알 수 없다는 것이 클라우드의 특성이라는 걸 기억해야 한다는 것. 행위자 토큰이라는 게 문서로도 공개되지 않은 기능이었으며, 그 문서화 되지 않은 기능이 사실상 제약 없이 활동하고 있었다는 것을 두고 하는 말이다.

클라우드로의 종속?
내가 특정 기술로 구성된 환경을 이용하는데, 그 환경을 구성하는 요소들을 전부 알지도 못하고, 안다 해도 전부 제어할 수 없다는 건 어떤 의미일까? 좋게 말하면 클라우드 제공 업체가 사용자 편리를 위해 귀찮을 일들을 대신 해주는 거라고도 할 수 있다. 나쁘게 말하면 사용자가 클라우드 제공 업체가 만드는 환경에 종속된 거라고도 할 수 있다. “클라우드를 이용한다”는 말 안에는 이 두 가지 모두가 포함돼 있다.

클라우드 제공 업체들은 사용자가 자신의 환경에 종속되기를 바라며, 그 방향으로 사업을 꾸려간다. 그래서 자신의 플랫폼에서만 사용할 수 있는 독자적 기능을 개발해 사용자들을 묶어둔다. 거기에 한 번 맛을 들인 기업들은 빠져나가기 힘들다. 그런 기능 중 하나가 ‘인증 서비스’다. 예를 들어 구글 ID로 다양한 서비스에 접속하다 보면, 애플이나 MS 등의 환경으로 옮겨가는 걸 상상할 수 없을 정도가 된다.

클라우드가 값싼 서비스라고 하기는 힘들지만, 경우에 따라 온프레미스(즉 오프라인) 환경을 유지하는 것보다 저렴할 수도 있다. 덩치가 큰 조직에서 자체적으로 서버실을 만들어 운영하고, 그 서버실을 기반으로 독자적인 서비스들을 개발해 직원들에게 배포하여 사용하게 한다고 했을 때, 그러한 시설을 마련하는 것은 물론 전문 인력까지 다수 고용해야 하기 때문에 유지비가 천문학적으로 들 수 있다. 그래서 큰 기업부터 클라우드로 넘어가고 있는 게 현실이기도 하다.

하지만 특정 클라우드 서비스 혹은 서비스들에 종속됐을 때 부작용이 나타날 수 있다. CVE-2025-55241과 같은 클라우드 단의 문제가 발생했을 때 사용자가 할 수 있는 일이 아무 것도 없다는 게 가장 큰 문제다. 취약점이 해결될 때까지 넋 놓고 기다려야만 한다. 클라우드가 마비라도 된다면, 그 서비스에 의존했던 기업은 사업을 잠시 중단해야 한다.

데이터 사용 방법에 대해서도 점점 사용자 기업이 낼 수 있는 목소리가 작아진다. 사용자가 어떻게 로그인을 해서, 어떤 정책 하에 데이터를 이용해야 하는지, 클라우드가 정해준 대로 해야 한다는 것이다. 일반적인 데이터 활용에 있어서 이는 큰 문제가 아닐 수 있지만, 특수한 경우 크나큰 불편이 초래될 수 있다. 심지어 클라우드 내 데이터와 관련된 각 나라의 규정도 다르기 때문에 사업자가 자기도 모르게 타국가의 규정을 위반하게 될 수도 있다.

클라우드는 API 호출량이나 사용자에 비례해 비용을 청구하는 편이다. 그렇기 때문에 클라우드에만 의존했다가는 회사 규모가 커짐에 따라 클라우드 비용이 기하급수적으로 비대해질 수 있다. 그랬을 때 다른 클라우드로 옮긴다거나 온프레미스로 체제 전환을 시도하는 건 더 큰 문제로 이어질 수 있기 때문에 사용자는 울며 겨자먹기 식으로 그 비용을 전부 감당해야 한다.

이 때문에 클라우드로의 종속에 대해서 대부분 전문가들은 ‘어쩔 수 없는 변화의 흐름’이라고 인정하지만 동시에 ‘될 수 있으면 피해야 한다’고 조언하기도 한다. 종속되는 걸 최대한 늦추기 위해서 보안 업계에서는 일반적으로 다음과 같은 조언들을 제공한다.

1) 클라우드 업체의 것이 아니라 표준으로 인정받은 프로토콜을 우선 채택한다.
2) 멀티 클라우드나 하이브리드 전략을 유지한다. 여러 클라우드에 자원을 분산시켜만 둬도 위에서 언급된 리스크 대부분이 해결된다. 하이브리드 역시 클라우드 마비나 지나친 비용 부담 문제로부터의 탈출구가 될 수 있다.
3) 의도적으로 벤더 중립성을 지킨다. 특정 벤더에 모든 것을 통째로 맡기면 관리 면에서 유용할 수 있으나, 종속이라는 측면에서 위험할 수 있다. 여러 벤더사와 관계를 맺으면 관리 면에서 복잡해질 수 있으나, 여러 서비스나 기능을 교차 검증할 수 있어 장기적으로 유리할 수 있다.