Cisco Secure FMC 인증 우회·root 실행 취약점 (CVE-2026-20079)

NOW Briefing

Brief 1 Cisco FMC 인증 우회 취약점(CVE-2026-20079)이 실제 공격에 악용되고 있습니다.

Brief 2 공격자는 이 취약점으로 웹셸을 설치하고 FMC 계정 정보를 조회했습니다.

Brief 3 해당 브랜치의 핫픽스를 적용하고 관리 인터페이스의 외부 노출을 차단해야 합니다.

‍

Cisco Secure FMC 인증 우회·root 실행 취약점 (CVE-2026-20079)

‍

■ 개요

‍

FMC는 Cisco Secure Firewall 장비들의 정책을 배포하고 이벤트를 수집하는 온프레미스 관리 서버입니다. Cisco 권고 기준으로 이 취약점은 Cisco Secure FMC Software와 Cisco Security Cloud Control(SCC) Firewall Management에 영향을 주며, 장비 설정과 무관하게 적용됩니다. 반대로 Firewall Device Manager(FDM), Secure Firewall ASA Software, Secure Firewall Threat Defense(FTD) Software, 과거 Defense Orchestrator로 불리던 Security Cloud Control은 영향을 받지 않습니다. SaaS로 제공되는 SCC Firewall Management는 Cisco가 이미 수정본을 배포해 이용자 조치가 필요 없습니다. 국내에서는 Cisco Korea가 2016년 Firepower NGFW를 출시하면서 FMC를 통합 관리 콘솔로 소개한 바 있습니다.

공격에는 관리자가 발급한 계정이나 사용자 조작이 필요하지 않습니다. VulnCheck 재현에서는 부팅 때 만들어진 머신 세션과 장비에 내장된 다른 머신 계정의 고정 자격증명을 함께 사용해 웹 관리 세션을 만든 뒤, 스크립트 실행 경로로 root 권한을 얻었습니다. 이 경로는 FMC가 재부팅된 뒤 관리자가 웹 관리 인터페이스에 인증하지 않아 머신 세션이 데이터베이스에 남아 있을 때만 성립합니다. 관리 서버 한 대가 장악되면 그 아래 관리되는 방화벽들의 정책과 설정, FMC에 저장된 계정 정보까지 함께 위험에 놓입니다.

Cisco 권고는 2026년 3월 4일 처음 공개됐고, Cisco PSIRT는 2026년 8월 실제 악용을 인지했습니다. 9월 9일에는 Cisco가 권고를 갱신했고, 같은 날 Talos의 침해 분석과 CISA KEV 등재가 이어졌습니다. 이 취약점에는 임시 대응책이 없어 핫픽스나 수정 릴리스를 적용해야 합니다.

‍

■ 요약

‍

항목	내용
CVE ID	CVE-2026-20079
CVSS 점수	CVSS v3.1 10.0
취약점 유형	CWE-288, 대체 경로·채널을 이용한 인증 우회
영향/위험	• 미인증 원격 공격자가 조작된 HTTP 요청으로 인증 우회 가능 • 인증 우회 후 하부 운영체제에서 root 권한 스크립트 실행 가능 • 실제 공격에서 웹셸 설치와 FMC 사용자 계정 자격증명 조회 확인됨 • Sandworm과 사용 도구가 겹치는 클러스터가 Cyclops Blink를 배포한 사례 보고됨(해당 클러스터의 초기 접근은 이 취약점 또는 정적 자격증명 중 어느 쪽인지 특정되지 않음) • 성립 조건: 재부팅 이후 웹 관리 인터페이스 인증·대시보드 접근이 없어 머신 세션이 남아 있는 상태(VulnCheck 분석 기준)
영향 제품	• Cisco Secure FMC Software (장비 설정과 무관하게 영향) • Cisco Security Cloud Control Firewall Management (SaaS, Cisco가 수정본 배포 완료)
패치 버전	• 7.0 브랜치: Hotfix GB-7.0.9.1-3 • 7.2 브랜치: Hotfix HL-7.2.11.1-4 • 7.4 브랜치: Hotfix HG-7.4.7.1-3 • 7.6 브랜치: Hotfix CY-7.6.5.1-2 • 7.7 브랜치: Hotfix AM-7.7.12.1-2 • 10.0 브랜치: Hotfix P-10.0.1.1-2

‍

■ 기술 분석

‍

FMC는 부팅 과정에서 내부 프로세스용 세션을 데이터베이스의 세션 테이블에 미리 만들어 둡니다. VulnCheck 분석에 따르면 이 세션의 식별자는 무작위 값이 아니라 csm_processes라는 고정 문자열이고, 세션 레코드에는 일반 계정이 아닌 머신 계정을 뜻하는 usertype 값 2가 들어 있습니다. 공격자는 세션 쿠키에 이 값을 넣어 일부 페이지에 접근할 수 있지만, 해당 세션에는 권한과 sf_action_id가 없어 대부분의 웹 관리 기능은 사용할 수 없습니다.

대시보드나 위젯 상호작용, 클라우드 관리 세션의 웹 관리 인터페이스 접근, 계정 인증 과정에서 도는 주기적 정리 작업은 이 세션을 지웁니다. VulnCheck는 이 때문에 공격 가능한 시점이 대체로 부팅 직후이거나 웹 관리 인터페이스를 자주 사용하지 않는 장비로 한정된다고 설명합니다.

취약한 버전은 외부 웹 요청이 요구하는 사용자 유형과 기존 세션의 머신 사용자 유형을 대조하지 않았습니다. VulnCheck는 CGISESSID=csm_processes를 유지한 채 내장 report 머신 계정의 고정 자격증명으로 로그인해 같은 세션을 웹 관리 세션으로 갱신하고 sf_action_id를 발급받았습니다. 이 세션으로 라이선스 검증 기능을 호출하면 입력값이 /var/tmp/license.tmp에 기록되고, 업그레이드 준비 점검 기능은 같은 파일을 설치 스크립트로 처리하면서 root 권한으로 실행합니다. VulnCheck는 이 흐름으로 root 셸 획득까지 재현했지만, 익스플로잇 자체와 PCAP·YARA 규칙은 자사 인텔리전스 구독 고객에게만 제공합니다.

Cisco는 두 곳을 수정했습니다. 먼저 앞단 Apache 설정을 바꿔, 루프백 주소가 아닌 원격 요청에는 X-Auth-User-Type: 1(사람 사용자) 헤더를 강제로 붙입니다. 그리고 인증 처리 라이브러리에서 그 헤더값과 세션에 저장된 사용자 유형이 어긋나면 요청을 거부합니다. VulnCheck는 패치가 적용된 7.7.12-3 이미지에서 인증 처리 라이브러리 SF/Auth.pm의 로그인 검사 함수 CheckLogin에 추가된 아래 검증 코드를 확인했습니다. 여기서 AUTH_IS_USER는 사람 사용자를 뜻하는 상수 1로 머신 세션의 유형 값 2와는 일치하지 않습니다.

# verify user type
if ($session) {
    my $userTypeFromSession = $session->param('usertype');
    my $userTypeFromHeader;
    if (ref($q) eq 'Mojo::Message::Request') {
        $userTypeFromHeader = $q->headers->header('X-Auth-User-Type');
    } else {
        $userTypeFromHeader = $q->http('X-Auth-User-Type');
    }
    if (
        defined $userTypeFromHeader &&
        $userTypeFromHeader == AUTH_IS_USER &&
        defined $userTypeFromSession &&
        $userTypeFromSession != AUTH_IS_USER
    ) {
        my $username = $session->param('username');
        warn "CheckLogin: Incorrect user type: $userTypeFromHeader != $userTypeFromSession ($username)";
        return 0 if $hasReturnFlag;
        Unauthorized($q, $session);
    }
}

⚠️ WARN

2026년 3월 26일부터 상세한 기술 분석이 공개됐고 실제 악용까지 확인됐으므로, 핫픽스를 다른 유지보수 일정보다 먼저 적용해야 합니다.

■ 탐지 및 점검

‍

• 웹 서버 접근 로그가 쿠키 값을 기록하도록 설정돼 있다면, 외부 주소로부터 들어온 요청 중 세션 쿠키 값이 CGISESSID=csm_processes인 항목을 찾습니다. 정상 사용자 세션은 무작위 값이므로 우선 조사해야 할 신호입니다. 쿠키가 기록되지 않는 구성이라면 프록시 본문·헤더 로깅이나 패킷 캡처가 필요합니다.

• 웹 애플리케이션 서버인 CSM Tomcat의 웹루트 디렉터리에 배포 계획에 없는 JSP 파일이나 JAR 파일이 있는지 확인합니다. 실제 공격에서 확인된 home.jsp와 cmd.jar의 해시는 참고 자료의 Talos IoC 목록과 대조합니다.

• /var/tmp/license.tmp 파일의 존재와 수정 시각, package_info.pl 실행 이력을 정상 업그레이드 작업 기록과 대조합니다. 두 항목 모두 정상 운영 중에도 나타날 수 있으므로 시각 불일치나 예정에 없던 실행일 때만 침해 의심으로 분류합니다.

• FMC에서 나가는 아웃바운드 연결을 방화벽·NetFlow 기록으로 점검합니다. Talos가 공개한 C2·스캐너·공격자 주소와 대조하고, 관리 서버가 평소 통신하지 않는 대상으로 나가는 연결도 이상 신호로 다뤄야 합니다.

• 네트워크 침입 탐지 도구 Snort를 운영하는 탐지 장비에 탐지 규칙 번호(SID) 66075~66080이 활성화돼 있는지 확인합니다. CVE-2026-20316은 SID 66883, 연관 악성코드는 SID 66960·66961로 탐지됩니다.

✅ CHECK

전체 침해 지표 목록은 참고 자료의 Talos 분석 원문에서 확인할 수 있습니다.

‍

■ 대응 방안

‍

• 운영 중인 릴리스 브랜치에 해당하는 핫픽스를 즉시 적용합니다. 7.0은 GB-7.0.9.1-3, 7.2는 HL-7.2.11.1-4, 7.4는 HG-7.4.7.1-3, 7.6은 CY-7.6.5.1-2, 7.7은 AM-7.7.12.1-2, 10.0은 P-10.0.1.1-2입니다.

• 임시 대응책이 없으므로 패치 전까지는 FMC 웹 관리 인터페이스를 인터넷에서 분리하고 관리 전용 네트워크와 허용된 출발지 주소로만 접근을 제한해 노출을 줄여야 합니다.

• 패치는 이후의 악용만 차단하며 이미 남아 있는 침해 흔적을 제거하지 못하므로, 침해 지표나 비정상 실행 이력이 확인되면 침해 대응 절차로 전환해 FMC 사용자 계정 자격증명과 API 토큰, 관리 대상 장비 접근 자격증명을 재발급합니다.

• 침해가 의심되는 장비는 배포된 방화벽 정책과 접근 제어 규칙이 변조되지 않았는지 형상 기록과 대조해 검증합니다.

• Talos 권고에 따라 CVE-2026-20079와 CVE-2026-20316 핫픽스를 함께 적용했는지 확인합니다.

💡 TIP

핫픽스 적용 여부와 별개로, 3월 4일 이후 외부 노출 이력과 재부팅 후 웹 로그인 공백이 겹치는 장비는 점검 우선순위를 높여야 합니다.

‍