Microsoft 내부 애플리케이션 접근을 위한 Entra OAuth 악용

• 연구진은 Entra OAuth의 동의 및 권한 위임 과정을 악용해 Microsoft 내부 애플리케이션에 접근 가능성 확인함
• 이 취약점은 내부 시스템 보호에 대한 새로운 위협으로, 외부 사용자가 내부 서비스로 접근 경로 확보 가능성 제시함
• 기본적인 동의 메커니즘과 권한 설정 미비가 핵심 원인임
• 연구 결과, 기존 보안 통제만으로는 OAuth 동의 요청 및 접근 통제에 취약점 존재함
• 기업 및 조직은 OAuth 동의 및 권한 관리 강화 필요성 확인함

---

연구 개요 및 배경

• Microsoft Entra OAuth는 사용자의 동의하에 여러 애플리케이션이 각기 다른 서비스에 대한 접근 권한을 얻는 인증/인가 체계임
• 연구진은 타깃 환경에서는 통상 내부에서만 접근 가능한 Microsoft 애플리케이션이, 특정 동의 및 권한 위임 시나리오를 악용할 때 외부에서도 접근 가능해짐을 발견함

원인 분석

• 취약점은 OAuth 동의 요청 과정을 악용해 발생함
• 애플리케이션이 올바르게 제한되지 않으면, 공격자가 사용자 동의를 유도해 내부 리소스 토큰을 취득 가능함
• 기본적으로 제공되는 동의 및 권한 부여 메커니즘이 충분히 세분화되어 있지 않아, 일부 내부 서비스가 외부 노출 위험을 가지게 됨

영향 및 위험

• 악성 사용자가 이 취약점을 이용해 Microsoft 내부 시스템 및 애플리케이션에 접근할 가능성이 있음
• 접근이 허용되면, 민감 데이터 유출 또는 내부 기능 오남용 위험 존재함

대응 및 권고

• 조직은 OAuth 관리 체계를 재검토하고, 모든 동의 및 권한 할당 과정을 엄격하게 통제해야 함
• 최소 권한 원칙에 기반해, 동의 받은 리소스와 권한 범위를 명확히 제한하는 접근 필요함
• 주기적으로 OAuth 애플리케이션 감사 및 동의 관리 프로세스를 수립해 관리 강화 필요함

[GN⁺]

Hacker News 의견

• Microsoft 문서가 정말 악몽임, 취약점이 있다는 것이 전혀 놀랍지 않음
  최근 Entra ID로 SSO 로그인을 구축했는데, (그나마 단일 테넌트여서 다행임) 엑세스 토큰에 올바른 스코프와 추가 필드 반환 설정을 맞출 때까지 거의 무작위로 시도하는 수밖에 없었음
  시작 가이드를 찾으려고 검색하면, 수많은 하위 페이지로 이어지고, 그 안에 담긴 마이크로소프트 특유의 난해한 용어들과 별 도움 안 되는 문서 링크만 계속 나옴

• 이런 결과가 전혀 놀랍지 않음
  Entra의 Oauth2 설정과 문서는 완전히 뒤죽박죽임
  너무 혼란스러워서 Microsoft 본인들도 제대로 동작시키지 못함이 분명함
  이 문제에 대한 그들의 해결책은 “더 많은 문서”를 추가하는 것인데, 이미 존재하는 스파게티 같은 문서도 다 읽기 어려움

  • 몇 주 전에 이 문제를 겪었음
    공식 문서에 따르면, 여러 리소스 서버를 대상으로 하는 스코프와 함께 authorization code flow를 수행할 수 없다고 되어 있음
    하지만 "openid $clientid/.default"를 요청하면 동작하긴 함
    플로우 마지막에 ID 토큰과 엑세스 토큰을 받게 되는데, ID 토큰은 OIDC 스코프가 적용된 것을 보여줌
    그런데 액세스 토큰을 보면 스코프에서 "openid"가 빠짐
    실제로 Microsoft Graph(UserInfo 엔드포인트 역할)를 호출할 수 없음
    왜 이런 동작을 하는지 제대로 설명해주는 자료를 찾지 못했음

• 멀티 테넌트 앱 인가가 계속해서 예기치 않은 문제를 만들어 냄
  나는 Microsoft에서 Wiz 리서치 결과로 적용된 패치를 작업했던 (퇴사한) PM임
  기사에 하나 수정 제안을 하면, 멀티테넌트 앱 인가 시 “iss” 또는 “tid” 클레임만 확인하라고 안내했다고 써 있었음
  실제 권고안은 이보다 조금 더 복잡함
  테넌트만 검증하면, 어떤 서비스 프린시플이라도 인가된 접근을 얻을 수 있게 될 가능성이 있음
  항상 토큰에 대해 테넌트 외에 subject도 검증해야 함
  예시로 tid+oid 조합으로 토큰을 검증하거나, 인가 전에 테넌트와 subject 모두 조건을 확인해야 함
  자세한 내용은 claims validation 공식문서에서 확인 가능함

  • 모든 토큰이 위조됐다고 가정하는 접근법을 강조함
    기본값으로 무조건 안전하게 설계해야 함
    CPU가 낭비된대도, 각 필드를 전부 다 검증해야 함
    시그니처는 꼭 유효성 검증해야만 의미 있음
    가능하다면 identity 데이터베이스와도 대조 검증을 권장함
    테넌트, 사용자, 그룹, 리소스 – 모든 것을 허용 전에 반드시 꼼꼼히 검증해야 함을 개발자들에게 가르쳐왔음

  • 100% 맞는 말임
    사실 엔지니어들은 공식 가이드를 꼭 읽어봐야 함
    관련 가이드는 여기에서 확인할 수 있음

  • “체크해야 할 항목에 대한 가이드”가 명확하게 되어 있는지도 궁금함
    원래 이런 건 Yes/No로 단순하게 정리되어야 한다고 생각함
    시스템에서 “이 그룹의 사용자는 모든 사람의 개인 노트를 읽을 수 있도록 해야 할까요?” 같은 체크박스가 있는 건 들어본 적 없음

• Entra의 복잡성을 무시하더라도, 특히 내부 Microsoft에서 지원해야 할 수많은 테넌트와 3P 고객용 테넌트가 구분 없이 혼재되어 있어서 실수를 인지 못하기 쉬움
  그보다 더 무서운 것은 “인증 토큰” 하나만으로 보안을 해결할 수 있다 믿는 것임
  이런 사이트는 원래 인터넷에 노출됐으면 안 되었음(이제는 공용 노출되어 있지 않음)
  네트워크 보안은 정말 뒷전으로 밀리지만, 가장 효과적인 방어 수단임

  • 네트워크 보안도 결국 방어 레이어 하나임
    방어는 여러 단계를 두는 것이 핵심임(defense-in-depth 개념)

• 클라우드로 옮기라고 했지, 내부망보다 더 안전하다고 했지, 자체 운영팀은 바보만 유지한다고 했지
  나는 너무 오래됐고 머리가 굳어서, 내부 Microsoft용 앱이 외부에서 접근되는 것 자체를 이해하지 못하겠음

  • 지난 10년간 구글에서 “Zero Trust”라 부르는 걸 시작으로 VPN을 완전히 버리는 추세임
    누구든 VPN에만 들어가면 중요한 데이터 접근 막기가 매우 힘들어졌기 때문임
    그래서 요즘은 “내부” 서비스도 외부에 노출하고, 각자 계층 권한(permissions) 관리가 필수임
    덕분에 한 번에 여러 서비스에 침투하는 식의 공격도 훨씬 어렵게 만들었음
    Zero Trust 개념 소개

  • 내 생각에는, 해당 앱이 공용 네트워크에 노출됐다는 것(즉, 인트라넷이 아니라는 것)이 진짜 문제가 아님
    진짜 문제는 이런 어플리케이션(Entra ID)이 멀티 테넌트라는 점임
    중요한 인증 정보가 여러 테넌트(악의적인 공격자 포함)와 동일 데이터베이스에 저장, 공유되고 있음
    그래서 멀티테넌시 위반이 흔하게 발생함
    Entra ID에 테넌시 체크 기능이 아무리 robust하게 있어도 취약점은 남음
    예를 들어, 블로그에서처럼 2개 이상 테넌트에 걸친 요청(멀티테넌트 요청)은 기본적으로 인가가 매우 어렵고, 작은 실수 하나가 전체 위험을 만들 수 있음
    단일 테넌트 앱과 비교하면, 공격자는 반드시 해당 테넌트 내 사용자가 되어야 하므로 사전 인증 공격이 훨씬 어려워짐

  • 이렇게 “클라우드로 가라, 내부망보다 더 안전하다, 직접 운영팀 둘 필요 없다”라는 주장이 많지만
    핵심은 블로그에서 보듯 리소스 서버 인가를 작업하는 개발자들이 토큰에서 issuer, audience, subject 같은 기본 claim조차 확인하지 않는다는 점임
    이런 실수가 반복된다면 인트라넷에 있어도 전혀 소용 없음
    결국 핵심 문제는 클라우드냐 자체 호스팅이냐가 아니라, 보안은 본질적으로 어렵고 실제 문제를 겪기 전까지 개선 순환이 잘 안 된다는 것임
    인트라넷이나 VPN망에 놔둔다고 해서 이런 보안 부실이 사라지지 않음

  • "Defence in depth"(다층 방어)라는 용어가 이제 유행을 지나간 것 같음?

  • 대부분의 회사에는 자체 서버 운영이 여전히 좋은 조언임
    3개 주에서 최고 지붕수리 업체라고 하더라도 직접 웹사이트, 이메일, 예약 시스템까지 전부 운영하게 맡기고 싶지는 않을 것임
    이 포럼에 있는 사람이라면 서버 직접 구축, 운영 가능하겠지만, 그게 “일반 사용자”는 아님

• Windows 빌드 서버에서 RCE 취약점 발견 후 보상금이 0$라는 것은 말도 안 됨
  실제 제로데이 취약점이 아니라 설정 이슈만 발견한 것이라고 해도, 만약 백도어 DLL로 빌드 환경 오염이 가능하다면 전 세계적으로 큰 재앙을 유발할 수 있음

  • 나는 Microsoft의 Windows 빌드 엔지니어였음
    이 빌드 도구 관리 UI에는 익숙하지 않지만(내가 퇴사 후 추가된 것일 수 있음) 정말로 원격 코드 실행(RCE)이 가능하도록 설계된 UI라고 생각하지 않음
    항상 NuGet에서 패키지를 가져와야 하며, 겉보기엔 아무 패키지와 소스를 지정할 수 있지만 실제로는 내부 Microsoft NuGet 피드로 제한하는 화이트리스트가 있었음
    NuGet 패키지 통제는 우리가 Windows 엔지니어링 팀에서 매우 중요하게 다뤘던 주제였음
    외부 공개 NuGet 패키지 사용은 전면 금지였고, 꼭 써야 하면 재패키징 후 내부 소스로 업로드한 것을 쓰도록 강제했었음

• Microsoft니까, 훌륭한 사람들이 많이 있음에도 최근 마스터키 유출, 엔지니어들이 PR에서 GPT에게 코딩 부탁한 일, 그리고 CEO가 백엔드 엔지니어는 사라진다고 말하는 것까지 봤을 때
  그 회사에 신뢰를 둘 수 없다고 생각함
  물론 대부분 사람들은 다른 선택지가 없음을 인정함
  그래도 머문다면 그건 좀 무책임함

  • "엔지니어들이 PR에서 GPT에게 기능 요청"한 것이 도대체 어떤 건지 궁금함
    혹시 dotnet/runtime 얘기임?

• 내 생각은 정말 간단함
  Entra*(혹은 Azure AD 등 이름이 바뀌어도 상관 없음)는 AuthZ(인가) 용도로는 쓰면 안 됨
  AuthN(인증) 용도로는 괜찮지만, 인가는 직접 구현해야 함
  AuthZ만 직접 수행하면 이런 문제는 쉽게 피해갈 수 있음
  *- 이름이 왜 바뀐 건지는 나도 모름. Microsoft 관리자 중에 "나는 이름을 바꾼다, 고로 존재한다"라는 좌우명을 가진 사람이 있는 듯함

  • "Azure AD"라는 이름은 그냥 Azure에 AD가 호스팅돼 있다는 오해를 불러 일으킴
    실제로는 이제 그 이상임

  • Entra로 AuthZ 구현 자체는 괜찮음
    “이 앱에 사용자를 반드시 할당해야 한다”라는 박스를 체크하고 직접 할당하면 됨[1]
    단, 이게 Entra에서 제공하는 유일한 AuthZ 기능임
    AuthZ를 사용 설정하지 않으면, Entra가 자동으로 인가 관리를 해줄 거라 기대하는 게 잘못임
    참고로, 간단한 “허용/거부” 인가는 모든 사용자가 같은 권한을 가지는 아주 단순한 앱에서만 의미가 있음
    보통 복잡한 애플리케이션에서는 사용자가 다양한 액세스 레벨을 가지니, 실제 인가(authorization)는 애플리케이션 내에서 구현해야 함
    [1] 관리 포털에서 앱 권한 할당 방법

• 이렇게 된 것, Entra ID 멀티테넌트 앱에서는 특정 테넌트만 블랙리스트/화이트리스트할 수 없는 점이 문제임
  거기다 MSAL은 브라우저 확장 같은 것에는 동작도 안 돼서, 결국 사용자들이 Entra ID와 통신하는 추가 보안 방안을 직접 구현해야 함
  이러니 각종 문제가 계속 나오는 게 당연함

  • Entra ID에서 멀티테넌트 앱에 대한 특정 테넌트 허용/차단 불가능한 점, 이거 정말 성가신 문제임
    “이 앱은 다음 테넌트만 접근 허용” 기능이 있었으면 좋겠는데, 지금은 “내 테넌트” 혹은 “Azure의 전체 테넌트”뿐임
    내가 쓰는 우회 방법은, “이 테넌트 전용”으로 앱을 설정하고 다른 테넌트 사용자를 내 테넌트에 초대하는 방식임
    아니면 “모든 테넌트 허용”으로 두고, 실제 사용자는 그룹으로 관리해 허용하는 식임
    이런 제한이 기술적 이유인지, 아니면 중요한 고객이 요청하지 않아서인지 전혀 모르겠음

• Azure는 정말 혼돈임
  Okta도 나름 문제는 있지만, 그래도 문서가 훨씬 잘 되어있고 가격이 비싼 대신 보안을 Azure 서비스와 섞지 않고 완전히 분리해서 관리할 수 있음
  그 값어치는 충분하다고 생각함