인증은 성공했는데 왜 그 앱까지 열렸을까 — ADFS 접근제어 구멍(CVE-2026-56155) 읽는 법

이미지 출처: CISA KEV

사내 계정 하나로 메일도 열고, 인사 시스템도 열고, 외부 SaaS도 여는 회사가 많음. 그 중심에 앉아 있는 게 ADFS(Active Directory Federation Services)임. 로그인 창을 대신 띄워 주고, "이 사람 맞습니다"라는 도장(토큰)을 찍어 각 서비스로 보내 주는 중개인 역할이라 보면 됨. 그런데 이번에 공개된 CVE-2026-56155는 그 도장 자체를 위조하는 이야기가 아님. 도장은 정상인데, 그 도장을 어디까지 쓸 수 있는지 구분이 충분히 촘촘하지 않았다는 이야기임. 분류상 'Insufficient Granularity of Access Control', 우리말로 옮기면 접근 통제의 결이 너무 굵었다는 뜻임.

핵심 요약

• ADFS의 접근 제어 판정이 충분히 세분화되지 않아, 인증에 성공한 주체가 원래 허용 범위를 넘는 리소스까지 닿을 수 있는 유형의 결함임
• 토큰 위조가 아니라 정상 인증 이후의 권한 경계 문제라, 로그상 '성공한 로그인'으로 보여 탐지가 늦어지기 쉬움
• 방어는 패치 적용 + 발급 규칙(Claims Rule)과 신뢰 관계 재점검 + 이벤트 ID 기반 접근 패턴 감시의 3단 구성으로 가는 게 현실적임

1. '인증'과 '인가'는 다른 문제다

보안 공부를 시작하면 제일 먼저 헷갈리는 게 이 둘인데, 이번 사안이야말로 그 차이를 몸으로 이해하기 좋은 사례임.

• 인증(Authentication): 너 누구냐 — 아이디/비번, MFA, 인증서로 신원을 확인하는 단계
• 인가(Authorization): 너 어디까지 되냐 — 확인된 신원이 어떤 앱·어떤 데이터에 닿을 수 있는지 정하는 단계

ADFS는 이 둘을 한 흐름 안에서 처리함. 사용자가 로그인하면 AD에서 신원을 확인하고, 그 결과를 클레임(Claim)이라는 조각들로 만들어 토큰에 담아 서비스(Relying Party)에 넘김. 서비스는 그 클레임을 보고 "아 이 사람은 재무팀이니 이 화면 열어 줘도 되겠다"를 판단함. 문제는 그 클레임을 만들고 거르는 규칙이 얼마나 촘촘하냐임. 굵게 만들어 두면 "인증된 사용자 = 전부 통과"에 가까워지고, 그 틈에서 원래 자기 몫이 아닌 리소스까지 손이 닿게 됨.

2. 이번 결함이 위험한 진짜 이유

토큰 위조 취약점은 오히려 티가 남. 서명이 안 맞거나, 발급자가 이상하거나, 만료가 어긋나거나 하니까 어디선가 걸림돌이 생김. 반면 접근 통제 세분화 부족은 다름. 모든 절차가 정상적으로 통과된 흔적만 남음. 사용자는 진짜 사용자고, 비밀번호도 맞았고, MFA도 통과했고, 토큰 서명도 정상임. 다만 그 토큰이 닿아선 안 될 곳까지 닿았을 뿐임.

그래서 이런 유형은 SIEM 알람이 안 울림. 실패 로그가 없으니까. 사고가 드러나는 시점은 대개 한참 뒤, "이 사람이 왜 저 시스템 데이터를 봤지?"라는 감사 과정에서임. 페더레이션 구조에서는 파급도 큼. ADFS 하나에 열 개, 스무 개 서비스가 물려 있으면 판정 로직의 결이 굵어진 만큼 그 아래 서비스 전부가 같은 결로 열리는 셈이라 그럼.

3. 개념 수준에서 그림 그려보기

실제 공격 절차를 재현할 생각은 없고, 어디서 어긋나는지 구조만 짚어 봄.

• 공격자는 정당한 계정 하나를 확보함(피싱이든 내부자든 협력사 계정이든). 여기까지는 흔한 시작점임
• 그 계정으로 ADFS에 정상 로그인함. 토큰이 정상 발급됨
• 여기서부터가 핵심 — 발급된 토큰이 담고 있는 신원·속성 정보가, 접근 판정을 하는 쪽에서 기대만큼 잘게 구분되지 않음. 원래는 "A부서 + B앱"까지 좁혀야 할 판정이 "인증됨"이라는 굵은 단위에서 멈춤
• 결과적으로 같은 신뢰 관계 아래 놓인 다른 리소스에 대해서도 통과 판정이 나올 여지가 생김

포인트는 새로운 마법이 없다는 것임. 대단한 익스플로잇 코드가 아니라, 원래 열려선 안 될 문 앞에 정당한 열쇠를 들고 서 있으니 문이 열려 버리는 상황에 가까움.

4. 방어자 체크리스트

순서대로 하는 걸 개인적으로 추천함.

• 패치가 1순위임. 이 유형은 설정 우회로 완전히 막기 어려움. 접근 판정 로직 자체가 대상이라 벤더 수정본이 근본 해법임. ADFS 서버는 도메인 컨트롤러급으로 취급해서 패치 창을 따로 잡아 두는 게 맞음
• Relying Party 목록을 눈으로 다시 봄. 몇 년 전에 붙였다가 지금은 안 쓰는 신뢰 관계가 살아 있는 경우가 정말 많음. 안 쓰는 신뢰는 지우는 게 제일 확실한 축소임
• Claims Rule을 리소스 단위로 좁힘. "인증된 사용자면 통과" 형태의 규칙이 남아 있는지 훑고, 그룹·부서·기기 상태 같은 조건을 판정에 실제로 반영하게 바꿈
• ADFS 감사 로그를 켜고 실제로 봄. ADFS 관리 이벤트 로그에서 토큰 발급 성공 기록을 사용자별·Relying Party별로 집계해 두면, 평소 안 쓰던 조합이 튀어나올 때 걸러낼 수 있음. 실패가 아니라 성공의 분포를 보는 감시임
• 조건부 접근 정책을 겹쳐 둠. ADFS 판정이 굵어도 그 뒤에서 위치·기기·위험도 기준으로 한 번 더 거르면 실제 피해 반경이 줄어듦
• ADFS 서명 인증서와 서비스 계정 권한을 점검함. 이번 건과 직결되진 않아도, 페더레이션 서버가 뚫렸을 때 피해 규모를 정하는 건 결국 이 둘임

5. 무엇을 로그에서 찾아야 하나

"뭘 봐야 하냐"가 결국 제일 실전적인 질문인 것 같음. 이런 것들을 권함.

• 평소와 다른 사용자–서비스 조합: 마케팅 계정이 갑자기 재무 앱 토큰을 받아 갔다면 그 자체가 신호임
• 토큰 발급 시각대: 새벽 3시에 몰린 정상 발급은 정상이 아닐 확률이 높음
• 같은 계정이 짧은 시간에 여러 Relying Party를 훑는 패턴 — 정찰의 전형적인 모양임
• Extranet(외부망) 경로에서의 인증 비중 변화 — 내부에서만 쓰이던 계정이 외부 경로로 넘어오면 의심 대상임

이 네 가지는 굳이 비싼 도구 없이도 로그 집계만으로 볼 수 있음. 오히려 이런 취약점 소식이 나왔을 때가 평소 미뤄 둔 로그 파이프라인을 손 볼 명분이 생기는 시점이라 봄.

6. 결국 남는 교훈

페더레이션은 편함. 계정 하나로 다 되니까. 그런데 편한 만큼 그 중심점이 판단을 얼마나 정교하게 하느냐에 조직 전체가 걸림. 이번 CVE는 "인증만 잘하면 된다"는 생각이 왜 위험한지를 다시 보여 준 사례임. 인증은 문 앞의 신분증 확인일 뿐이고, 그 안에서 어느 방까지 들어갈 수 있는지는 완전히 다른 설계 문제임.

ADFS 운영 중인 분들은 이번 기회에 Relying Party 목록 뽑아 보시고, Claims Rule 중에 "인증되면 통과"짜리가 몇 개나 남아 있는지 세어 보셨으면 함. 세다 보면 분명히 "이거 아직도 있었네" 싶은 게 하나쯤 나옴. 저도 예전에 테스트용으로 붙여 둔 신뢰 관계를 반년쯤 지나서 발견한 적이 있어서 남 이야기 같지가 않음. 같이 점검해 보아요! 혹시 자기 환경에서 이런 굵은 규칙 찾아내신 분 계시면 어떻게 정리하셨는지 댓글로 공유 부탁드림.