Cisco CUCM이 모르는 주소로 대신 요청을 보낸다, SSRF 취약점 CVE-2026-20230 알아보기

이미지 출처: CISA KEV

사무실 전화가 늘 그 자리에 있어서 그렇지, 그 전화를 묶어 관리하는 서버는 생각보다 내부망 한복판에 앉아 있음. Cisco Unified Communications Manager, 줄여서 CUCM이 딱 그런 물건임. 음성·영상 통화부터 단말 등록, 디렉터리 연동까지 도맡다 보니 데이터베이스, 인증 서버, 내부 API 같은 민감한 자원들과 평소에도 부지런히 대화를 주고받음. 이번 CVE-2026-20230은 바로 그 '대신 요청을 보내주는' 기능에 생긴 서버측 요청 위조(SSRF) 결함임. 공격자가 직접 손을 뻗을 수 없는 내부 자원을, CUCM의 손을 빌려 건드릴 수 있게 된다는 게 핵심임.

핵심 요약

• CUCM 내부의 요청 처리 로직이 사용자가 지정한 주소를 충분히 검증하지 않아, 서버가 공격자 의도대로 내부 자원에 요청을 보내는 SSRF로 이어짐.
• 위험의 본질은 '경계를 넘는 신뢰'임. 외부에서 막힌 내부망·메타데이터·관리 인터페이스가 CUCM을 경유해 노출될 수 있음.
• 방어는 패치 적용이 1순위지만, 송신(egress) 통제·네트워크 분리·요청 로그 모니터링을 함께 깔아야 실제로 막힘.

SSRF, 한 줄로 말하면 '서버를 심부름꾼으로 부리는 것'

SSRF(Server-Side Request Forgery)는 글자 그대로 서버가 대신 요청을 보내게 만드는 공격임. 보통 웹 애플리케이션에는 사용자가 준 URL을 서버가 받아 그 주소로 요청을 날리는 기능이 있음. 이미지 미리보기, 외부 연동, 웹훅 검증 같은 게 대표적임. 문제는 이 URL을 서버가 의심 없이 받아들일 때 생김. 공격자가 외부 주소 대신 내부 IP나 내부 서비스 주소를 슬쩍 넣으면, 서버는 '내가 신뢰하는 위치에서의 요청'이라는 모양새로 그 내부 자원을 두드림. 외부 방화벽이 아무리 단단해도, 요청이 신뢰받는 서버 안쪽에서 출발하면 경계가 무력해지는 구조임.

왜 하필 통신 관리 서버가 표적이 되나

CUCM 같은 통합 통신 서버는 SSRF의 가치를 유난히 키우는 환경에 놓여 있음. 첫째, 위치가 좋음. 운영을 위해 내부 데이터베이스, 인증·디렉터리 시스템, 다른 관리 콘솔과 폭넓게 통신하므로, 이 서버를 경유하면 평소 외부에서 닿을 수 없던 자원에 발을 들일 수 있음. 둘째, 권한이 큼. 통신 인프라의 중추라 네트워크 안에서 상대적으로 폭넓은 접근을 허용받는 경우가 많음. 셋째, 노출되어 있음. 단말 등록과 운영 편의 때문에 관리 인터페이스가 생각보다 넓은 대역에서 접근 가능하게 열려 있는 현장이 흔함. 즉 '경유지로 삼기 좋은 서버'라는 조건을 두루 갖춘 셈임.

공격자가 노리는 것 — 개념 수준에서만

구체적 페이로드를 늘어놓을 일은 아니고, 무엇을 노리는지 그림만 그려보면 이러함. SSRF로 가장 먼저 시도하는 건 내부 정찰임. CUCM을 통해 내부 IP 대역을 한 칸씩 두드려, 어떤 호스트와 포트가 살아 있는지 응답 차이로 지도를 그려나감. 그다음은 보통 닫혀 있어야 할 관리 인터페이스나 내부 API를 서버 권한으로 호출해보는 단계임. 클라우드형 배포라면 인스턴스 메타데이터처럼 내부에서만 접근 가능한 자원이 표적이 되기도 함. 어느 경로든 공통점은 분명함. 직접 공격은 막혀 있지만, 신뢰받는 서버의 이름으로 우회한다는 점임. 그래서 SSRF는 단독 결함보다 다른 공격으로 가는 발판으로 평가하는 게 맞음.

방어자 눈으로 — 무엇을 보면 보이나

탐지의 출발점은 'CUCM이 평소와 다른 곳으로 말을 거는가'임. 정상 운영이라면 이 서버가 통신하는 상대는 대체로 정해져 있음. 그 기준선을 알아야 이탈이 보임. 구체적으로는 다음을 살핌.

• 서버에서 나가는 송신 트래픽 중, 평소 대화하지 않던 내부 IP·대역으로 향하는 요청이 갑자기 늘어나는지 확인함.
• 짧은 시간에 여러 호스트·포트로 향하는 순차적 연결 시도는 내부 스캔의 전형적 흔적이므로 경보 대상으로 둠.
• 요청 처리 기능에 들어온 입력값(특히 주소·URL 형태) 로그를 남기고, 내부 대역이나 메타데이터 주소가 입력에 섞여 있는지 점검함.
• 응답 크기·지연 시간의 비정상 패턴을 함께 봄. SSRF는 응답 차이로 내부 상태를 추론하는 경우가 많기 때문임.

로그가 흩어져 있으면 이런 상관관계가 안 보이므로, CUCM의 접근·요청 로그를 중앙 수집해 두는 사전 준비가 사실상 탐지의 절반임.

완화 — 패치 한 줄로 끝나지 않는 이유

가장 확실한 조치는 벤더가 배포한 보안 업데이트를 적용하는 것임. 다만 통신 인프라는 점검 창구를 잡기가 까다로워 패치가 늦어지기 쉬움. 그 공백을 메우는 게 구조적 방어임. 개인적으로는 다음 순서를 추천함.

• 네트워크 분리: CUCM이 닿을 수 있는 내부 자원 범위 자체를 좁힘. 운영에 필요한 대상만 허용하는 분리는 SSRF가 성공해도 갈 곳을 잃게 만듦.
• 송신 통제: 서버에서 나가는 연결을 기본 차단하고, 꼭 필요한 목적지만 허용하는 출구 정책을 둠. 내부 정찰의 칼날을 직접 무디게 함.
• 관리 인터페이스 노출 축소: 운영 콘솔이 넓은 대역에서 접근되지 않도록 접근 출발지를 좁히고, 불필요한 기능·서비스는 꺼 둠.
• 변경 감시: 위 통제가 시간이 지나며 슬그머니 느슨해지지 않는지 주기적으로 재점검함. 분리 정책은 만들 때보다 유지할 때 무너지는 경우가 많음.

정리하면 이번 결함이 주는 교훈은 'SSRF 하나'가 아니라, 내부에 앉은 서버에 우리가 얼마나 큰 신뢰를 무심코 쥐여주고 있었는가에 대한 질문임. 통신 서버처럼 조용히 중심에 있는 자산일수록, 그 서버가 누구에게 말을 걸 수 있는지 한 번쯤 직접 그려볼 필요가 있음. 각자 환경의 CUCM이 어디로 요청을 보낼 수 있는지 오늘 한 줄이라도 점검표를 적어 보면 좋겠음. 같이 기준선부터 잡아 보아요. 막히는 지점이나 현장에서 본 패턴이 있으면 댓글로 나눠 주세요.