CVE-2026-20230 Cisco Unified Communications Manager SSRF 임의 파일 쓰기에서 RCE까지 PoC 도출 과정과 고찰

적용 범위: 로컬 실습 환경, 승인된 재현 환경, 취약점 검증 및 보호 규칙 분석에만 사용한다. 승인되지 않은 대상에는 사용하지 말 것. 본 문서는 CVE-2026-20230의 악용 체인, 검증 가능한 현상, 판단 로직 및 방어 관점을 주로 분석하며, 직접 복사하여 실행할 수 있는 공격 패킷, WebShell 내용 또는 명령 실행 페이로드는 제공하지 않는다.

1. 취약점 배경

CVE-2026-20230은 Cisco Unified Communications Manager(Unified CM / CUCM) 및 Cisco Unified Communications Manager Session Management Edition(Unified CM SME)에서 발생하는 서버 측 요청 위조(SSRF) 취약점이다. 이 취약점은 특정 HTTP 요청 처리 흐름에서 입력 검증이 충분하지 않아 발생하며, 공격자는 인증 없이 요청을 구성하여 영향받는 장비가 공격자를 대신해 내부 인터페이스나 로컬 리소스에 접근하도록 만들 수 있다.

이 취약점의 영향은 일반적인 SSRF 탐지 수준에 그치지 않는다. 공개된 기술 분석에 따르면 특정 버전과 서비스 활성화 조건에서 SSRF는 임의 파일 쓰기 능력으로 추가 연쇄될 수 있으며, 공격자는 통제 가능한 내용을 기본 운영체제 경로에 쓴 다음 Web 컨테이너 접근 가능 디렉터리 또는 서버 측 컴포넌트 로딩 메커니즘을 활용하여 파일 쓰기를 코드 실행으로 전환할 수 있다.

Cisco는 이 취약점에 대해 CVSS v3.1 점수 8.6을 부여했으며, 벡터는 다음과 같다:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N

CVSS 점수는 High로 표시되지만, Cisco는 이 취약점의 Security Impact Rating을 Critical로 표시했다. 그 이유는 성공적으로 악용할 경우 기본 운영체제 파일을 쓸 수 있고, 나아가 root 권한으로 승격될 가능성이 있기 때문이다.

특히 주의해야 할 점은 이 취약점의 핵심 선행 조건이 WebDialer 서비스가 반드시 활성화되어 있어야 한다는 것이다. WebDialer는 기본적으로 꺼져 있으므로, CUCM 자산을 확인했다고 해서 바로 취약점이 악용 가능하다고 판단해서는 안 된다. 실제 위험 판단은 제품 버전, 패치 상태, WebDialer 서비스 상태 및 관련 인터페이스 접근 가능 여부를 동시에 확인해야 한다.

2. 단순히 인터페이스 하나가 200을 반환한다고 판단할 수 없는 이유

이 취약점은 일반적인 "특정 고정 URL에 접근하여 200이 반환되면 존재한다"는 형태의 Web 취약점이 아니다. 그 악용 체인은 최소한 세 가지 계층을 포함한다:

1. 외부에서 접근 가능한 WebDialer 또는 cmplatform 관련 인터페이스.
2. SSRF의 영향을 받을 수 있는 내부 접근 로직.
3. 내부 요청에 의해 추가로 트리거될 수 있는 파일 쓰기 또는 서비스 배포 동작.

따라서 특정 인터페이스에 단독으로 접근하여 HTTP 200, 302, 401, 404 또는 500을 얻었다고 해서 취약점의 존재 여부를 직접 증명할 수는 없다.

예를 들어, WebDialer WSDL 인터페이스에 접근 가능하다는 것은 대상이 WebDialer 관련 기능을 노출했음을 보여줄 뿐, 이후 SSRF가 반드시 필터링을 통과할 수 있다는 것을 증명하지는 못한다. installClusterStatusExecute 인터페이스에 접근 가능한 것도 관련 진입점이 존재함을 보여줄 뿐, 임의 파일 쓰기가 성립되었음을 단독으로 증명하지는 못한다. 반대로 특정 단계에서 예외가 반환되더라도 이는 대상 버전, 패치, hostname 해석, 경로 권한, 프록시 장비 또는 서비스 상태 때문일 수 있으며, 반드시 전체 취약점 체인이 존재하지 않는다는 것을 의미하지는 않는다.

보다 안정적인 판단은 다단계 증거 조합을 사용해야 한다:

1. 대상이 Cisco Unified CM / Unified CM SME인지 확인.
2. WebDialer 서비스가 활성화 상태인지 확인.
3. 대상의 실제 hostname 또는 내부 서비스 식별자를 획득할 수 있는지 확인.
4. SSRF 진입점에 도달 가능하고, 서버 측에서 내부 요청을 시작하는 징후가 있는지 확인.
5. 승인된 실습 환경에서 통제된 파일 쓰기 증거가 발생하는지 확인.
6. 서버 측 로그, 파일 시스템 변경, Web 컨테이너 로그 및 알람 데이터를 결합하여 실제 트리거 여부 판단.

"WebDialer 활성화 + 영향받는 버전 + SSRF 동작 성립 + 통제된 파일 쓰기 성립"이 동시에 나타나야 비로소 신뢰도 높은 악용 가능으로 판단해야 한다.

3. PoC 구성思路

현재 공개된 악용 체인의 핵심은 단순한 SSRF가 아니라, SSRF와 Axis/Java Web 서비스 메커니즘, 로그 쓰기 또는 배포 설명 파일 처리 로직 간의 조합 악용이다.

전체적인思路는 다음과 같이 요약할 수 있다:

WebDialer 정보 획득
    ↓
대상 실제 hostname 획득
    ↓
cmplatform 관련 인터페이스를 통한 SSRF 트리거
    ↓
내부 WebDialer / Axis 관리 경로 접근
    ↓
통제 가능한 서비스 설명 내용 쓰기 또는 배포
    ↓
새로운 호출 가능 서비스 또는 파일 쓰기 능력 형성
    ↓
파일 쓰기 능력을 Web 접근 가능 스크립트로 전환
    ↓
특정 환경에서 명령 실행까지 도달

체인 설계 관점에서 hostname은 핵심 요소이다. 일부 필터링 로직은 127.0.0.1, localhost 등 일반적인 로컬 주소를 차단하지만, 대상의 실제 hostname은 이후 요청 흐름에 허용될 수 있다. 따라서 PoC는 먼저 WebDialer의 WSDL 정보에서 실제 호스트 이름을 추출한 다음, 이를 SSRF 체인의 내부 접근 접두어로 사용한다.

두 번째 핵심 요소는 Axis 서비스 관련 로직이다. PoC는 Web 디렉터리에 직접 파일을 업로드하는 것이 아니라, 내부 서비스 처리 체인을 통해 서버 측 컴포넌트가 공격자 통제 내용을 특정 경로에 쓰도록 만든다. 이 과정은 본질적으로 "서버 측 내부 요청 + 컴포넌트 구성/로그 쓰기 동작 + 경로 이동/경로 제어"의 조합이다.

세 번째 핵심 요소는 2단계 쓰기이다. 첫 번째 단계는 일반적으로 더 안정적인 파일 쓰기 진입점을 구축하는 데 사용되고, 두 번째 단계에서 명령 실행 스크립트를 Web 접근 가능 디렉터리에 쓴다. 이렇게 하는 이유는 SSRF를 통해 한 번에 완전한 명령 실행 로직을 쓰려고 하면 인코딩, 길이, XML 구조, 경로 권한 및 서버 측 파싱 동작의 영향을 받을 수 있기 때문이며, 2단계 방식은 복잡한 페이로드를 분리하기 easier 때문이다.

본 문서는 완전한 악용 패킷과 WebShell 내용을 제공하지 않는다. 방어와 검증 시 다음 핵심 특징만 이해하면 된다:

외부 요청 진입점: cmplatform 설치 상태 관련 인터페이스
정보 획득 진입점: WebDialer WSDL / services 관련 인터페이스
내부 전달 대상: WebDialer / Axis / AdminService 관련 경로
핵심 동작: SSRF, 서버 측 내부 요청, 통제 가능한 파일 쓰기, Web 접근 가능 파일 생성
최종 위험: 임의 파일 쓰기, WebShell 생성, 명령 실행, root 권한 승격 경로

4. hostname 획득 로직

PoC는 먼저 대상의 실제 hostname을 획득해야 하며, IP 주소나 외부 도메인만 사용해서는 안 된다.

그 이유는 SSRF 필터링 로직이 반드시 최종 연결 대상만 판단하는 것이 아니라, hostname 필드, URL 문자열, 로컬 주소 키워드 등을 함께 검증할 수 있기 때문이다. 일반적인 127.0.0.1, localhost 같은 로컬 주소는 차단될 수 있지만, 장비의 실제 hostname은 특정 시나리오에서 합법적인 노드 이름으로 간주될 수 있다.

판단에 도움이 될 수 있는 인터페이스는 일반적으로 WebDialer WSDL 정보와 관련이 있다. 해당 WSDL에 접근하면 응답에 서비스 주소, location 필드 또는 기타 파싱 가능한 호스트 식별자가 포함될 수 있다. PoC는 응답 텍스트에서 URL의 hostname을 추출하여 다음 단계 SSRF의 내부 접근 대상으로 사용한다.

이 단계의 판단 기준은 다음과 같아야 한다:

1. WSDL 인터페이스에 접근 가능한지.
2. 응답 내용이 WebDialer / Axis 서비스 특징과 일치하는지.
3. 응답에서 실제 hostname을 파싱할 수 있는지.
4. 파싱된 hostname이 외부 접근 IP 또는 도메인과 다른지.
5. 해당 hostname이 이후 SSRF 진입점에 수용될 수 있는지.

hostname 파싱에 실패하면 PoC는 대상 IP로 폴백할 수 있지만, 이는 성공률을 현저히 낮춘다. 실제 환경에서 hostname 파싱 실패의 일반적인 원인은 WebDialer 미활성화, 인터페이스 접근 제어 제한, 응답이 리버스 프록시에 의해 변조됨, 인증서 또는 서비스 구성 불완전 등이다.

5. SSRF 트리거 단계

SSRF 트리거 지점은 cmplatform 관련 설치 상태 조회 로직에 있다. 이 기능은 원래 클러스터 노드 설치 상태를 조회하는 데 사용되며, 서버는 사용자가 제출한 노드 식별자 또는 hostname을 기반으로 내부 요청을 구성한다.

취약점의 핵심 문제는 공격자가 통제할 수 있는 hostname 매개변수가 합법적인 노드 이름이나 신뢰된 호스트로 엄격히 제한되지 않아, 이 매개변수가 더 복잡한 내부 접근 경로로 구성될 수 있다는 점이다. 이후 서버는 공격자를 대신해 내부 인터페이스에 요청을 보낸다.

이 단계의 핵심은 "외부 URL에 접근할 수 있는가"가 아니라 "CUCM 장비 자체가 내부에서만 접근 가능한 WebDialer / Axis 관리 인터페이스에 접근하게 만드는가"이다. 따라서 SSRF의 가치는 두 가지 측면에서 나온다:

1. 외부 네트워크 접근 제한을 우회하여 본인 또는 내부 컴포넌트만 접근할 수 있는 서비스 경로에 도달.
2. 내부 서비스 신뢰 경계를 활용하여 일반 HTTP 매개변수를 내부 컴포넌트 동작으로 전환.

승인된 검증에서 HTTP 상태 코드만으로 SSRF 성공을 판단해서는 안 된다. 더 신뢰할 수 있는 증거는 다음과 같다:

1. 서버 측 로그에 내부 경로에 대한 접근 기록이 나타남.
2. 요청 응답 내용에 내부 인터페이스 특징이 나타남.
3. 이후 WebDialer services 페이지에 새로 추가되거나 비정상적인 서비스 흔적이 나타남.
4. 파일 시스템에 서버 측 프로세스가 생성한 비정상적인 파일이 나타남.
5. 보안 장비가 hostname 매개변수에 비정상적인 경로, 인코딩 내용 또는 내부 서비스 경로가 포함된 것을 기록함.

6. Axis 서비스 쓰기와 임의 파일 쓰기思路

공개 체인에서 SSRF는 Axis 관련 서비스 인터페이스에 접근하고 서비스 배포 설명 내용을 쓰는 데进一步 사용된다. 공격자는 특수한 XML/WSDD 구조를 구성하여 서버 측 컴포넌트가 처리 과정에서 통제 가능한 내용을 지정된 경로에 쓰도록 만든다.

이 단계의 본질은 전통적인 파일 업로드가 아니라 서버 측 컴포넌트의 처리 로직을 남용하는 것이다:

사용자 통제 매개변수
    ↓
SSRF 내부 요청
    ↓
Axis / Web 서비스 처리
    ↓
통제 가능한 배포 설명 또는 로그 쓰기
    ↓
지정 경로 파일 생성

보안 분석 관점에서 몇 가지 핵심 요소가 있다:

1. 쓰기 대상 경로는 일반적으로 Web 컨테이너 접근 가능 디렉터리로 이동해야 한다.
2. 쓰기 내용은 서버 측 컴포넌트 처리 형식을 충족해야 하며, 그렇지 않으면 유효하지 않은 파일만 생성될 수 있다.
3. 쓰기 파일의 소유자와 권한은 Tomcat / CUCM 서비스 프로세스에 따라 결정된다.
4. 쓰기 위치가 Web에서 접근 가능하면 파일 쓰기는 스크립트 실행으로进一步 전환될 수 있다.
5. 쓰기 위치가 실행 가능하지 않더라도 구성 오염, 지속성 또는 이후 권한 상승 조건을 초래할 수 있다.

따라서 CVE-2026-20230의 고위험 지점은 단순히 SSRF가 아니라, SSRF가 신뢰 경계를 넘어 내부 관리/서비스 배포 체인에 진입하고 최종적으로 통제 가능한 파일 쓰기를 트리거할 수 있다는 점이다.

7. 2단계 WebShell 쓰기 로직

PoC 설계에서는 일반적으로 한 번에 명령 실행을 완료하는 대신 2단계 쓰기를 채택한다.

첫 번째 단계는 간단한 파일 쓰기 능력을 생성하는 데 사용된다. 이 단계의 목표는 공격자가 Web 접근 가능 경로를 통해 서버의 지정된 위치에 내용을 쓸 수 있게 하는 것이다.

두 번째 단계에서는 첫 번째 단계의 쓰기 능력을 활용하여 명령 실행 스크립트를 Web 접근 가능 디렉터리에 쓴다. 이후 공격자는 HTTP 매개변수를 통해 시스템 명령 실행을 트리거할 수 있다.

2단계 설계의 장점은:

1. 단일 SSRF 요청에서 페이로드 복잡도를 낮춘다.
2. XML, URL 인코딩, 특수 문자 이스케이프로 인한 페이로드 손상을 방지한다.
3. "서비스 배포"와 "최종 실행 파일 쓰기"를 분리하여 디버깅이 용이하다.
4. 다양한 대상 경로에서 착점을 조정하기 쉽다.
5. 이후 명령 실행 단계를 SSRF 단계와 분리한다.

그러나 방어 관점에서 2단계 쓰기는 더 명확한 탐지 표면을 제공한다:

1. 첫 번째 비정상 요청은 일반적으로 새 서비스를 생성하거나 중간 JSP를 쓰려고 시도한다.
2. 두 번째 비정상 요청은 일반적으로 중간 JSP에 접근하며 파일 이름, 파일 내용 등의 매개변수를携带한다.
3. 세 번째 단계는 최종 명령 실행 JSP에 접근하며 인증 암호 또는 명령 매개변수를携带한다.
4. Web 접근 로그에는 짧은 시간 내에 WebDialer, services, axis2-web, platform-services 등의 경로를 연속적으로 접근하는 동작이 나타난다.
5. 파일 시스템에 비정상적인 JSP, 비정상적인 서비스 이름, 비정상적인 로그 파일 또는 새로 추가된 Web 리소스가 나타날 수 있다.

8. 현재 PoC의 전체 실행 흐름

현재 PoC의 흐름은 다음과 같이 요약할 수 있다:

1. 대상 주소를 파싱한다.
2. WebDialer WSDL에 접근하여 실제 hostname 추출을 시도한다.
3. 내부 WebDialer / Axis 관리 경로를 대상으로 SSRF 요청을 구성한다.
4. 내부 요청을 통해 Axis 서비스 관련 내용을 쓴다.
5. services 페이지에 접근하여 비정상 서비스 배포 성공 여부를 확인한다.
6. 새 서비스를 호출하여 첫 번째 단계 파일 쓰기 스크립트를 쓴다.
7. 첫 번째 단계 스크립트에 접근하여 두 번째 단계 명령 실행 스크립트를 쓴다.
8. 두 번째 단계 스크립트에 접근하여 테스트 명령을 실행한다.
9. HTTP 응답, 파일 생성 결과 및 명령 출력을 기반으로 악용 성공 여부를 판단한다.

악용 성공률 관점에서 가장 중요한 실패 지점은 일반적으로 다음에集中된다:

1. WebDialer가 활성화되지 않음.
2. hostname 파싱 실패 또는 필터링됨.
3. SSRF 요청이 실제로 내부 서비스에 진입하지 못함.
4. Axis 서비스 배포 실패.
5. 경로 이동 착점이 대상 버전에 맞지 않음.
6. Web 디렉터리를 쓸 수 없거나 스크립트가 실행되지 않음.
7. 대상이 이미 패치되었거나 Cisco 임시 수정 패키지를 적용함.
8. 프록시, WAF, EDR 또는 파일 무결성 모니터링이 중간 단계를 차단함.

따라서 이 PoC는 특정 영향받는 버전과 기본 경로가 일치할 때 악용 가능성이 높지만, 모든 CUCM 자산에 대해 안정적으로 통과되는 것은 아니다.

9. 성공 판단 로직

CVE-2026-20230의 성공 판단은 스크립트가 끝까지 실행되었는지만 볼 수 없다. 더 합리적인 판단은 4단계로 나누어야 한다.