▲

Azure Entra ID 로그인 로그 우회 취약점 세 번째와 네 번째 사례 공개

 (trustedsec.com)
1P by GN⁺ 9시간전 | ★ favorite | 댓글 1개
  • 2023년 이후 Azure Entra ID 로그인 로그 우회 취약점이 총 4건 발견되었으며, 최근 두 건은 정상 토큰 발급이 가능한 심각한 문제로 확인됨
  • GraphGoblin은 OAuth2 ROPC 흐름에서 scope 파라미터를 반복 입력해 로그 생성을 우회하며, Graph****는 5만 자 이상의 User-Agent 문자열로 로그를 완전히 누락시킴
  • 두 취약점 모두 SQL 컬럼 길이 초과로 인한 로깅 실패가 원인으로 지목되었고, Microsoft는 보고 후 수정 완료
  • Microsoft는 이번 문제를 ‘중간(Medium)’ 수준으로 분류해 보상이나 공식 인정 없이 조용히 수정, CVSS 기준으로는 High(7.5~8.7점) 수준으로 평가됨
  • 반복된 입력값 검증 실패로 인한 결함이 지속되고 있어, 로그 교차 검증 및 KQL 기반 탐지 규칙 강화가 보안 담당자에게 필수 과제로 지적됨

Azure Entra ID 로그인 로그 우회 취약점 공개

  • 2023년 이후 Azure Entra ID 로그인 로그 우회 취약점이 총 4건 발견됨
    • 초기 두 건은 비밀번호 유효성만 확인 가능했으나, 최근 두 건은 정상 토큰 발급까지 가능한 심각한 수준의 문제
    • 모든 취약점은 현재 Microsoft에 의해 수정 완료

  • GraphNinja 및 GraphGhost 요약

    • GraphNinja: 다른 테넌트의 엔드포인트를 지정해 로그인 시도 시, 비밀번호 유효 여부를 알 수 있으나 로그가 생성되지 않음
      • 공격자는 외부 테넌트로 인증 요청을 보내고 응답을 통해 비밀번호가 맞는지 확인 가능
      • Microsoft는 이후 이 문제를 해결하기 위해 추가 로깅을 도입
    • GraphGhost: 잘못된 Client ID를 사용하면 인증 흐름이 비밀번호 검증 이후 실패하며, 로그에는 실패로만 표시됨
      • 비밀번호가 맞았다는 정보는 관리자 로그에 남지 않음
      • Microsoft는 로그인 로그에 비밀번호 검증 여부를 추가하여 수정

  • GraphGoblin 취약점

    • GraphGoblin은 OAuth2 ROPC 흐름에서 scope 파라미터를 반복 입력해 로그 생성을 우회함
      • "openid openid openid ..." 형태로 수천 번 반복 입력 시 정상 토큰이 발급되지만 Entra ID 로그인 로그에는 아무 기록도 남지 않음
    • 원인은 SQL 컬럼 길이 초과로 인한 INSERT 실패로 지목됨
      • 반복된 스코프 문자열이 데이터베이스 필드 길이를 초과해 로그 저장이 실패한 것으로 추정
    • Microsoft는 문제 재현에 어려움을 겪었으나, 영상 증거 제공 후 수정 완료

  • Graph****** (User-Agent 기반 우회)

    • User-Agent 필드에 50,000자 이상의 긴 문자열을 입력하면 로그가 생성되지 않음
      • 인증 요청은 정상 처리되어 토큰이 발급되지만 로그는 완전히 누락
      • SQL 컬럼 길이 초과로 인한 로깅 실패로 추정
    • 2025년 9월 28일 발견되어 10월 8일 Microsoft가 보고 전 이미 수정 완료

  • 타임라인 요약

    • 2025-09-20: GraphGoblin 최초 발견
    • 2025-09-26: Microsoft에 GraphGoblin 보고
    • 2025-09-28: Graph****** 발견
    • 2025-10-08: Graph****** 수정 완료
    • 2025-11-21: Microsoft가 GraphGoblin 재현 성공 및 수정 시작

Microsoft의 대응 및 평가

  • Microsoft는 이번 취약점을 ‘중간(Medium)’ 수준으로 분류하고 보상이나 공개 인정을 하지 않음
    • 이전 두 건(2023~2024년)에는 보상 지급 및 인정이 있었음
    • 이번에는 정상 토큰이 발급되는 심각한 문제임에도 불구하고 중요하지 않다고 평가
  • CVSS v3.1 기준 7.5점(High), v4.0 기준 8.7점(High) 으로 평가됨
    • Integrity(무결성) 손상으로 인해 높은 점수 산출
    • 로그 누락은 보안 컴포넌트의 직접적 손상으로 간주됨
  • Microsoft는 문제 재현 후 2주 만에 수정 완료
    • 과거 GraphNinja 수정에는 7개월, GraphGhost는 5개월 소요

로그 우회 탐지 방법

  • KQL 쿼리를 통해 Graph Activity 로그와 Sign-In 로그의 Session ID 또는 UniqueTokenIdentifier를 비교
    • Graph Activity에는 존재하지만 Sign-In 로그에는 없는 세션은 우회된 로그인으로 판단 가능
    • 단, E5 라이선스가 있어야 Graph Activity 로그 수집 가능
  • 예시 KQL 쿼리: 
    MicrosoftGraphActivityLogs
| where TimeGenerated > ago(8d)
| join kind=leftanti (union isfuzzy=true
SigninLogs,
AADNonInteractiveUserSignInLogs,
AADServicePrincipalSignInLogs,
AADManagedIdentitySignInLogs,
MicrosoftServicePrincipalSignInLogs
| where TimeGenerated > ago(90d)
| summarize arg_max(TimeGenerated, *) by UniqueTokenIdentifier
)
on $left.SignInActivityId == $right.UniqueTokenIdentifier
    • 필요 시 SessionId 기준으로 비교 가능
    • 탐지 결과를 기반으로 Azure Log Search Alert Rule 설정 가능

네 가지 로그인 로그 우회 요약

발견 시점 방식 토큰 발급 여부 Microsoft 인정 여부
2023-08 / 2024-05 외부 테넌트 ID 지정으로 비밀번호 검증 로그 미생성 X X
2024-12 / 2025-04 잘못된 Client ID로 인증 실패 유도 X X
2025-09-20 스코프 반복 입력으로 SQL 컬럼 오버플로 O X
2025-09-28 긴 User-Agent 문자열로 SQL 컬럼 오버플로 O N/A

Microsoft 보안 프로세스에 대한 비판

  • Entra ID 로그인 로깅 기능의 다수 파라미터에서 결함 발견

    • tenant ID, client ID, scope, user-agent 등 핵심 필드에서 반복적 취약점 발생
    • 단순한 입력값 검증 실패로 인한 문제로, 복잡한 공격이 아님
    • Microsoft의 보안 검토 및 품질 관리 부재 지적
    • 수년간 동일 영역에서 유사한 결함이 반복
    • AI 코드 생성 도입 여부나 코드 관리 과정에서의 누락 가능성 제기

  • 공개 투명성 부족

    • 네 건 모두 CVE 미발급, 공식 공지 없음
    • Microsoft가 CNA로서 자사 취약점 공개 여부를 독점적으로 결정

결론

  • Azure Entra ID의 로그인 로그는 전 세계 조직의 침입 탐지 핵심 데이터
    • 로그 누락 시 공격 탐지 체계 전체가 무력화될 수 있음
  • 발견된 네 가지 취약점은 모두 간단한 입력값 퍼징(fuzzing) 으로 탐지 가능했던 수준
  • Microsoft는 이러한 반복적 결함에 대해 공개적 설명과 투명한 보안 검토 절차 강화가 필요함
  • 관리자와 보안 담당자는 로그 교차 검증 및 KQL 기반 탐지 규칙을 통해 방어 체계를 보완해야 함
▲
GN⁺ 9시간전  [-]
Hacker News 의견들

  • CISA가 발표한 Microsoft 침해 사건 보고서를 떠올리게 됨
    국가 지원 해커가 Microsoft를 뚫고 미 국무부 등 여러 기관에 침투한 사건이었음
    놀라운 점은 Microsoft가 아니라 국무부의 한 시스템 관리자가 메일 로그 이상을 발견해 침입을 찾아냈다는 것임
    CISA 보고서 링크

  • ProPublica와 ArsTechnica가 Azure를 정면 비판한 기사에서, 연방 사이버 전문가들이 Microsoft 클라우드를 “형편없다”고 표현했다고 함
    기사 링크

    • 실제로는 한 전문가가 문서 품질을 그렇게 표현했는데, ProPublica가 Azure 전체로 확대 해석한 것 같음
    • Ars는 단순히 라이선스 재게시한 것뿐임
    • 내가 아는 Azure 보안 엔지니어들은 거의 멘탈 붕괴 상태임. 약 12명 중 절반은 번아웃, 나머지는 역량이 너무 낮음
    • Bloomberg나 CNBC는 이 사건을 다루지 않았음. 누군가 언론 연결망으로 알려줬으면 함

  • 지금의 사이버보안 상태는 문명 전체가 의존하는 시스템치고는 너무 허술함
    마치 구멍 난 배를 덕트테이프로 막고 대양으로 나가는 꼴임

    • 더 심각한 건, 업계가 그 구멍을 막겠다며 기관총 탑을 더 세우자는 식으로 대응한다는 점임

  • SQL 로그 관련 논의에서, 공격자가 너무 긴 입력을 보내 컬럼 길이 초과로 INSERT가 실패한 상황으로 보임
    그 결과 로그인 시도 기록이 남지 않았다는 설명임

    • 두 서비스가 따로 동작하는 구조였음. 검증 서비스가 실패를 감지하고 로그 서비스에 기록을 요청했지만, 로그 서비스가 실패해도 검증 서비스는 그대로 응답을 보냈음
      인증 흐름이 너무 복잡하게 설계된 구조적 문제로 보임

  • Azure의 감사 로그가 실제 동작과 다르게 기록된 경험이 있음
    클라이언트 시크릿을 삭제했는데, UI는 B를 지운다고 했지만 API는 A만 남기는 식으로 동작함
    결국 로그에는 내가 한 것처럼 기록됐지만 실제로는 시스템 버그였음
    이런 경험 이후로 Azure 로그뿐 아니라 감사 로그 전반에 대한 신뢰가 흔들렸음
    법정에서 증거로 쓰기엔 위험하다고 생각함

    • 그래서 나는 변경 전 확인 단계를 반드시 거치는 UI를 선호함. ‘비디오게임식’ 자동 저장 인터페이스는 너무 위험함
    • Azure 포털(신버전, 구버전 포함)은 버그 투성이라 놀랍지도 않음. 버튼 하나 잘못 눌러 다른 객체가 바뀌는 경우도 있음
    • 이 사례는 동시 편집 환경에서 set 연산 vs delete 연산의 위험성을 보여주는 좋은 교육 예시임. 로그는 정확했지만 UI 설계가 문제였음
    • 결국 사용자는 단지 의도를 표현할 뿐, 실제 실행은 프런트엔드가 제어한다는 점이 무섭게 느껴짐

  • 최근 EntraID 취약점들에 비하면 로그 우회는 덜 중요해 보임

    • 하지만 핵심 인증 로그가 ‘best-effort’로만 작동한다면, 보안 감사의 근거로는 심각한 문제임
    • 결국 성공적이고 은밀한 공격은 여러 취약점의 협업으로 이루어지는 법임

  • Microsoft가 Notepad에도 치명적 취약점을 넣은 적이 있으니, 이런 일은 놀랍지 않음

  • 예전에 Azure VPN을 평가했을 때, 연결 성공/실패 로그가 전혀 남지 않았음
    문제를 제기하자 Microsoft는 “그걸 새 기능 요청으로 등록하라”고 했음
    그때 Azure에 대한 신뢰를 완전히 잃음. 시간이 지나도 나아지지 않고 오히려 악화되는 느낌임

  • IT 관리자들이 Microsoft를 계속 쓰는 이유는 선택지가 없기 때문임

    • 나처럼 .NET 기반 LOB 앱과 각종 SaaS를 관리해야 하는 환경에서는 Microsoft 솔루션이 가장 현실적인 선택임
      예산도 적고 인력도 부족하니, 그냥 급여 받고 퇴근할 수 있는 수준으로만 유지함
    • 젊은 관리자들은 Microsoft를 싫어하는 경향이 강함. 세대 차이일 수도 있음
    • “아무도 X를 사서 해고된 적은 없다”는 말처럼, Microsoft 선택은 커리어 리스크가 적음

  • Microsoft가 Azure 취약점 재현에 실패해 영상 증거를 요청했을 때, 단 한 줄의 curl 명령어로 보여줬다는 점이 인상적이었음
    정말 통쾌한 순간이었음

답변달기