공장에서 나올 때부터 열려 있던 계정: Cisco FMC 하드코딩 패스워드 CVE-2026-20316 점검법

이미지 출처: CISA KEV

랙에 방화벽 관리 서버를 실장하고, 케이블 타이 정리까지 끝낸 뒤 초기 비밀번호를 바꾸는 순간을 떠올려 보면 됨. 우리가 "이제 이 장비는 우리 것"이라고 확신하는 지점이 대개 거기임. 그런데 하드코딩 자격증명 취약점은 바로 그 확신을 무너뜨리는 유형임. 내가 바꾼 비밀번호와 상관없이, 펌웨어 안에 처음부터 박혀 있던 또 하나의 열쇠가 조용히 살아 있는 상황이기 때문임. Cisco Secure Firewall Management Center(FMC)에서 보고된 CVE-2026-20316이 정확히 그 계열의 문제임.

핵심 요약

• FMC 제품에 정적으로 내장된 계정 정보가 존재해, 관리자가 설정한 자격증명과 무관하게 인증이 성립할 수 있는 구조적 결함임(CWE-798 계열).
• FMC는 다수의 FTD 장비 정책·VPN·로그를 총괄하는 오케스트레이터라, 한 대의 장악이 곧 경계 전체의 통제권 상실로 번짐.
• 당장 할 일은 패치 적용, 관리 인터페이스 노출면 차단, 그리고 인증·정책변경 감사로그의 외부 반출과 상시 탐지임.

1. 하드코딩 자격증명이 왜 유독 고약한가

일반적인 취약점은 "특정 요청을 특정 순서로 보내야" 성립함. 반면 정적 자격증명은 조건이 거의 없음. 인증 절차를 우회하는 게 아니라, 정상적인 인증 절차를 정상적으로 통과해 버림. 그래서 다음과 같은 성질이 따라옴.

• 공격 난이도가 낮음. 값을 아는 순간부터 재현이 반복 가능함.
• 인증 실패 폭주 같은 시끄러운 흔적이 남지 않음. 로그상으로는 "성공한 로그인" 한 줄임.
• 비밀번호 정책, 만료 주기, 복잡도 규칙이 아무 의미가 없음. 운영자가 통제할 수 있는 대상이 아니기 때문임.
• 값이 한 번 공개되면 동일 계열 장비 전체가 같은 열쇠를 공유하게 됨.

공격 재현은 개념 수준으로만 정리함. 노출된 관리 서비스에 내장 계정으로 접속을 시도하고, 성공하면 그 계정이 가진 권한 범위에서 명령이 수행되는 흐름임. 실제 값이나 동작하는 절차를 옮겨 적을 이유는 없음.

2. 하필 FMC라는 점

FMC는 그냥 서버 한 대가 아님. 방화벽 정책, NAT 규칙, VPN 프로파일, IPS 시그니처 배포, 이벤트 수집까지 한곳에 모이는 중앙 통제소임. 여기가 흔들리면 파급이 이렇게 감.

• 정책 변조: 특정 출발지·목적지에 대한 허용 규칙을 슬쩍 추가하면, 경계 방화벽 수십 대가 동시에 그 규칙을 받아감.
• 가시성 제거: 로깅 설정을 낮추거나 이벤트 전달을 끊으면 이후 공격이 관제 화면에서 사라짐.
• 신뢰 관계 악용: FMC는 관리 대상 장비들과 이미 신뢰된 채널을 갖고 있어, 내부로 뻗어 나가는 발판이 매우 좋음.

즉 이 취약점은 "방화벽 한 대가 뚫린 사건"이 아니라 "방화벽을 지휘하던 지휘소가 넘어간 사건"으로 읽어야 맞음.

3. 지금 바로 줄여야 할 노출면

• 패치가 1순위임. 정적 자격증명은 설정으로 무력화하기 어려운 유형이라, 벤더 권고문에 명시된 수정 릴리스로 올리는 것 외에 근본 해법이 없음. 우회 설정으로 버티는 선택은 임시 방편으로만 취급해야 함.
• 관리 평면 분리. FMC 관리 인터페이스가 업무망이나 인터넷에서 직접 닿는 구조라면 그 자체가 사고 대기 상태임. OOB 관리망 또는 별도 세그먼트로 분리하고, 접근은 점프호스트 한 경로로만 남기는 걸 개인적으로 추천함.
• 소스 IP 허용목록. SSH·HTTPS 관리 포트에 대해 운영자 대역과 점프호스트만 허용하도록 상위 ACL에서 잘라 둘 것. 내장 계정을 알아도 도달할 수 없으면 공격은 성립하지 않음.
• 외부 노출 여부 실측. 사내 자산목록만 믿지 말고, 외부 스캔으로 관리 포트가 실제로 열려 있는지 확인해야 함. 테스트용으로 잠깐 열어 둔 규칙이 몇 년째 살아 있는 경우가 정말 흔함.

4. 탐지 관점: 무엇을 어디서 보는가

정적 자격증명 악용은 "성공한 정상 로그인"처럼 보이기 때문에, 실패 로그 기반 탐지로는 잡히지 않음. 대신 맥락의 이상함을 봐야 함.

• 평소 로그인하지 않는 계정, 특히 서비스·점검용 성격의 계정에서 발생한 대화형 접속 성공 이벤트.
• 운영자 대역·점프호스트가 아닌 출발지 IP에서 성립한 관리 세션.
• 업무 시간 외 접속 뒤 곧바로 이어지는 정책 배포(deploy) 또는 규칙 변경 감사기록.
• 신규 사용자 계정 생성, 권한 상향, API 토큰 발급 이벤트. 침해 후 지속성 확보 단계에서 거의 항상 등장함.
• syslog 전달 대상 변경, 로깅 레벨 하향, 이벤트 전송 중단 같은 가시성 훼손 행위.
• 백업·설정 파일의 대량 조회나 반출로 볼 수 있는 트래픽 패턴.

핵심은 이 로그들이 장비 안에만 있으면 소용없다는 점임. 장비를 장악한 쪽이 로그도 함께 지울 수 있기 때문임. FMC의 감사로그와 인증 이벤트를 실시간으로 외부 SIEM에 밀어내고, 그 수집이 끊기는 것 자체를 알람으로 잡아야 의미가 생김. "로그가 안 들어온다"는 침묵이 종종 가장 큰 경보임.

5. 이미 노출됐다면 확인할 순서

• 패치 적용 전후로 관리 세션 기록 전수 검토. 특히 알 수 없는 출발지에서의 성공 세션을 우선 추림.
• 정책 형상 비교. 변경관리 기록에 없는 규칙·객체·VPN 프로파일이 있는지 형상 백업본과 대조함.
• 계정 전수 조사. 사용자 목록, 권한, API 토큰, 인증서를 모두 재확인하고 정체불명 항목은 폐기함.
• 자격증명 회전. 관리자 비밀번호, 연동 서비스 계정, 관리 대상 장비와의 등록 키까지 함께 갱신함.
• 인접 자산 확인. FMC가 신뢰 관계를 맺고 있던 관리 대상 장비와 인증 서버 쪽 흔적도 같은 기간으로 넓혀 봄.

6. 조금 더 멀리 보는 이야기

이런 취약점을 만날 때마다 드는 생각은, 결국 보안 장비도 그냥 소프트웨어가 돌아가는 서버라는 사실을 잊지 말자는 것임. "보안 제품이니까 안전하겠지"라는 가정이 관리 인터페이스를 아무렇지 않게 열어 두게 만들고, 그 가정 하나가 사고의 크기를 결정함. 조달·검수 단계에서 "정적 자격증명·개발용 계정이 제품에 포함되지 않음"을 문서로 요구하는 것도 생각보다 실효가 있음. 계약서에 한 줄 넣는 일이 사후 대응 몇 주보다 싸게 먹히는 경우가 많다 보니 말입니다.

오늘 저녁에 딱 두 가지만 확인해 보면 좋겠음. 첫째, 우리 FMC 관리 포트가 어디까지 보이는지. 둘째, 그 장비의 인증 로그가 지금 이 순간 외부로 잘 나가고 있는지. 이 두 개만 정리해 둬도 다음에 비슷한 유형이 또 나왔을 때 훨씬 편해짐. 각자 환경에서 확인해 보고, 막히는 부분 있으면 댓글로 남겨 주세요. 같이 정리해 보아요!