인증과 인가는 다른 문제다 — UniFi OS 접근 제어 결함(CVE-2026-34908)이 들춰낸 인가의 빈틈

이미지 출처: CISA KEV

문 앞에서 신분증을 확인하는 일과, 그 사람이 금고실에 들어가도 되는지를 따지는 일은 전혀 다른 절차임. 그런데 현장에서 보안 사고를 들여다보다 보면 이 둘을 한 덩어리로 묶어 버린 설계가 의외로 많음. CVE-2026-34908로 정리된 Ubiquiti UniFi OS의 부적절한 접근 제어(Improper Access Control) 결함도 정확히 그 지점을 건드림. 로그인이라는 관문은 멀쩡히 작동했지만, 그 뒤에서 "이 요청을 이 사용자가 해도 되는가"를 다시 묻지 않았다는 이야기임.

핵심 요약

• CVE-2026-34908은 UniFi OS의 접근 제어(인가) 처리가 충분치 않아 권한 밖 자원·기능에 손이 닿을 수 있는 결함임.
• 핵심 위험은 비밀번호 탈취가 아니라, 정상 인증을 통과한 뒤 권한 경계를 넘는 '인가 우회'에 있음.
• 방어는 최신 펌웨어 적용 + 관리 인터페이스 노출 차단 + 요청 단위 권한 로그 점검의 3박자로 접근함.

무엇이 문제였나 — '누구냐'는 물었지만 '돼도 되냐'는 안 물음

접근 제어 결함을 한 줄로 줄이면 이렇게 됨. 인증(Authentication)은 통과시켰는데, 인가(Authorization) 검사가 빠지거나 느슨했다. UniFi OS는 게이트웨이·스위치·AP·NVR 같은 네트워크 장비를 한 화면에서 관리하는 운영체제 성격의 플랫폼임. 그만큼 하나의 콘솔 뒤에 여러 권한 등급(읽기 전용, 사이트 관리자, 슈퍼 관리자 등)과 여러 자원(설정, 로그, 영상, 사용자 계정)이 촘촘히 얽혀 있음.

이런 구조에서 접근 제어가 어긋나면 전형적으로 두 가지 모습으로 나타남. 하나는 수평 권한 이동으로, 같은 등급의 다른 사용자/사이트 자원에 식별자(ID)만 바꿔 접근하는 IDOR류임. 다른 하나는 수직 권한 상승으로, 낮은 등급 계정이 관리자 전용 엔드포인트를 그대로 호출해 버리는 경우임. 어느 쪽이든 공통점은 분명함 — 서버가 매 요청마다 "이 토큰의 주인이 이 객체에 권한이 있나"를 다시 확인하지 않았다는 것.

왜 골치 아픈가 — 정상 트래픽과 구분이 어려움

이 부류 결함이 방어자 입장에서 까다로운 이유는, 공격이 형식상 완벽히 정상적인 요청처럼 보인다는 데 있음. 비밀번호를 무차별 대입하지도 않고, 깨진 패킷을 던지지도 않음. 제대로 로그인한 세션이 평소와 똑같은 API를 호출하되, 다만 자기 권한 밖의 자원을 가리킬 뿐임. 그래서 단순 실패 카운트나 인증 실패 알람만 보고 있으면 그냥 지나치기 쉬움.

정확한 영향 범위나 점수는 벤더·NVD 고지를 기준으로 확인하는 게 맞음. 다만 접근 제어 계열 취약점의 본질은 버전 숫자보다 "권한 경계가 어디서 무너지는가"에 있으므로, 세부 수치를 떠나 대응의 방향성은 거의 동일하게 잡을 수 있음.

어떻게 탐지하나 — 권한을 기준으로 로그를 다시 봄

핵심은 로그를 '인증 성공/실패'가 아니라 '요청과 권한의 일치 여부' 관점에서 다시 읽는 것임. 개념 수준에서 점검 포인트는 다음과 같음.

• 한 계정이 평소 다루지 않던 사이트·장비·자원 식별자로 접근 범위를 갑자기 넓힌 흔적이 있는지 확인함.
• 읽기 전용·하위 등급 계정에서 설정 변경, 사용자 추가, 펌웨어·백업 관련 엔드포인트 호출이 나타났는지 살펴봄.
• 403(권한 거부)이 떠야 정상인 경로에서 200(성공)이 반환된 응답 코드 조합을 추적함 — 인가 우회의 가장 직접적인 신호임.
• 관리 API에 외부 IP·비정상 시간대·낯선 User-Agent에서의 접근이 섞여 있는지 본다.

UniFi OS 자체 활동 로그와 함께, 앞단의 리버스 프록시나 방화벽 로그를 교차로 맞춰 보면 "어떤 세션이 어떤 객체에 손댔는가"의 그림이 훨씬 선명해짐.

어떻게 완화하나 — 노출 줄이고, 경계 다시 세움

실행 가능한 공격 코드를 다룰 필요는 없음. 방어 조치만으로도 위험은 크게 깎임.

• 최신 펌웨어·UniFi OS 업데이트를 우선 적용함. 접근 제어 결함은 결국 서버 측 권한 검사 코드 수정으로 막히므로, 패치가 1순위임.
• 관리 인터페이스를 인터넷에 직접 노출하지 않음. VPN·전용 관리망 뒤에 두고, 가능하면 출발지 IP를 화이트리스트로 묶음.
• 계정을 최소 권한 원칙으로 재정비함. 굳이 슈퍼 관리자일 필요 없는 계정의 등급을 낮추고, 다중 인증(MFA)을 켬.
• 관리자 행위에 대한 알림을 설정함. 설정 변경·계정 생성·내보내기 같은 고위험 동작은 실시간으로 통지받도록 함.

개인적으로는 패치 적용을 미룰 수밖에 없는 환경이라면, 적어도 관리 포트의 외부 노출만이라도 먼저 끊어 두는 걸 추천함. 인가 결함은 '닿을 수 있어야' 악용되는데, 닿는 경로 자체를 줄이는 것만으로도 체감 위험이 확연히 떨어지기 때문임.

한 줄로 남기고 싶은 교훈

이번 사례가 다시 일깨워 주는 건 단순함. 로그인했다는 사실이 그 사람이 무엇이든 해도 된다는 뜻은 아니라는 것. 인증은 출입증이고, 인가는 방마다 다른 잠금장치임. UniFi처럼 한 콘솔이 네트워크 전체를 쥐고 있는 플랫폼일수록 이 둘을 분리해서 보는 습관이 그대로 방어력이 됨. 여러분의 장비도 오늘 한 번, "이 계정이 정말 이만큼의 권한이 필요한가"를 기준으로 점검해 보면 좋겠음. 점검하다 막히는 부분 있으면 댓글로 같이 풀어 봐요.