방화벽이 스스로 흘린 정보 — FortiOS 정보노출 결함 CVE-2025-68686을 로그로 되짚기

이미지 출처: CISA KEV

보안 장비의 취약점 중에서 가장 과소평가되는 부류가 정보 노출(Exposure of Sensitive Information)임. 원격 코드 실행처럼 화려하지 않고, 장비가 멈추지도 않고, 관리자 화면에 경고 하나 뜨지 않음. 그런데 침해 사고를 역추적해 보면 시작점이 이런 결함인 경우가 생각보다 많음. FortiOS에 할당된 CVE-2025-68686도 같은 계열임. 인가되지 않은 주체에게 장비 내부의 민감한 정보가 흘러나가는 유형이고, 방화벽·SSL-VPN 게이트웨이처럼 경계에 서 있는 장비에서 이 결함이 나면 파급이 단순하지 않음.

핵심 요약

• CVE-2025-68686은 FortiOS에서 인가되지 않은 주체에게 민감 정보가 노출되는 결함으로, 경계 장비 특성상 정찰 단계의 발판이 되기 쉬움
• 정보 노출은 장비 장애나 알림을 남기지 않으므로, 탐지는 비정상 요청 패턴과 인증 전 접근 흔적을 로그에서 찾는 방식이어야 함
• 즉시 조치는 벤더 권고 펌웨어 적용, 관리 인터페이스의 인터넷 노출 차단, 노출 가능성이 있는 자격증명·설정값의 회전

1. 왜 '정보 노출'이 경계 장비에서 더 무서운가

일반 웹서버에서 정보가 새면 그 서버의 정보가 새는 것으로 끝나는 경우가 많음. 그런데 방화벽이나 VPN 게이트웨이는 성격이 다름. 이 장비 안에는 다음이 모여 있음.

• 내부 네트워크 세그먼트 구조와 라우팅 정보 — 공격자가 가장 먼저 알고 싶어 하는 지도
• VPN 사용자 계정 목록, 세션 식별자, 인증 서버(LDAP·RADIUS) 연동 설정
• 펌웨어 버전, 활성화된 기능, 정책 이름 등 후속 공격을 정밀 조준하게 해 주는 메타데이터

즉 정보 노출 결함 하나가 정찰(reconnaissance) 비용을 0에 가깝게 만들어 줌. 실제 침해 사례를 보면 이런 결함으로 얻은 계정 목록이나 세션 값이, 뒤이어 나오는 인증 우회·자격증명 스터핑과 결합되며 진짜 침투로 이어짐. 결함 하나만 놓고 CVSS 숫자를 보면 '중간 정도네' 싶다가도, 공격 체인 안에 놓고 보면 평가가 달라지는 이유임.

2. 개념 수준에서 본 결함의 구조

이 유형은 대체로 응답이 요청자의 권한보다 많은 것을 말해 주는 데서 출발함. 구체적인 재현 절차는 다루지 않되, 방어자가 알아야 할 패턴은 아래 세 가지임.

• 인증 전 응답의 차이 — 존재하는 계정과 없는 계정에 대해 응답 시간이나 메시지가 미묘하게 다르면 그 자체가 열거(enumeration) 채널이 됨
• 에러 메시지의 과잉 친절 — 내부 경로, 설정 파일명, 백엔드 서버 주소가 에러에 그대로 실려 나오는 경우
• 권한 검사 없이 노출되는 엔드포인트 — 진단·상태 확인 목적의 인터페이스가 인증 뒤에 있어야 하는데 그렇지 않은 경우

세 가지 모두 공격 트래픽이 정상 요청과 거의 구별되지 않는다는 공통점이 있음. 이게 탐지를 어렵게 만드는 핵심임. 페이로드가 특이한 게 아니라, 그냥 평범한 요청을 남들보다 조금 많이 보낼 뿐이니까.

3. 탐지: 무엇을 보아야 하나

개인적으로는 시그니처보다 행위 패턴에 무게를 두는 걸 추천함. 실무에서 확인할 만한 항목을 정리하면 이렇게 됨.

• 단일 출발지의 요청 밀도 — 인증 성공 없이 특정 엔드포인트에만 반복 접근하는 IP. 열거 시도는 성공률이 낮으므로 시도 횟수가 튀게 되어 있음
• 비정상 User-Agent와 요청 순서 — 정상 사용자는 로그인 페이지를 거쳐 들어옴. 중간 단계를 건너뛰고 특정 경로로 직행하는 흐름은 자동화 도구의 흔적일 확률이 높음
• 관리 인터페이스에 대한 외부 접근 기록 — 이건 취약점 여부와 무관하게 항상 확인해야 하는 항목임. 국외 IP, 클라우드 사업자 대역, VPS 대역에서의 접근은 특히 눈여겨봐야 함
• 응답 크기의 이상치 — 같은 엔드포인트인데 평소보다 응답 바이트가 큰 건들이 섞여 있으면 그건 무언가 더 뱉어 냈다는 뜻임

Fortinet 장비를 쓴다면 event 로그와 traffic 로그를 함께 봐야 그림이 나옴. 한쪽만 보면 인증 실패 기록은 있는데 그 앞뒤 트래픽이 안 보이거나, 트래픽은 있는데 무슨 결과였는지가 안 보임. SIEM으로 보낼 때 이 두 소스를 같은 세션 키로 묶어 두면 조사 속도가 확실히 달라짐.

4. 완화: 우선순위대로

• 펌웨어 업데이트 — 벤더 권고 버전으로 올리는 게 근본 조치임. 다만 경계 장비 재부팅은 서비스 영향이 있으니 점검 창구를 잡아 두고 진행하는 게 현실적임
• 관리 인터페이스의 인터넷 노출 제거 — HTTPS·SSH 관리 접근을 내부망이나 별도 관리 VLAN으로만 열어 두기. 이 하나만으로 상당수 결함의 실효 위험이 사라짐
• Trusted Host 설정 — 관리자 계정별로 접근 가능한 출발지 대역을 못 박아 두는 기능. 쓰고 있지 않다면 지금이 적기임
• 노출 가능성이 있는 값의 회전 — 이미 노출됐을 가능성을 배제할 수 없다면 패치 후에도 관리자 비밀번호, API 토큰, VPN 사전공유키를 바꿔 줘야 함. 패치는 구멍을 막는 것이지 이미 나간 정보를 회수해 주지는 않음
• MFA 적용 범위 점검 — 계정 정보가 새 나갔다는 가정하에, 그 계정만으로는 아무것도 못 하게 만드는 게 두 번째 방어선임

5. 사후 점검, 여기까지는 해 보자

패치를 올렸다고 상황이 종료되는 건 아님. 최소한 아래 세 가지는 확인해 봐야 마음이 놓임.

• 취약점 공개 시점 이전 몇 주치 로그까지 거슬러 올라가 이상 접근이 있었는지 확인
• 관리자 계정 목록과 API 사용자 목록에 모르는 항목이 추가되지 않았는지 대조
• VPN 세션 기록에서 평소와 다른 시간대·지역의 로그인이 있었는지 검토

경계 장비 보안은 결국 '이 장비가 인터넷을 향해 무엇을 말하고 있는가'를 계속 확인하는 일이라고 생각함. 취약점 하나하나를 쫓아다니는 것보다, 노출면 자체를 줄여 두면 다음 CVE가 나왔을 때 대응이 훨씬 편해짐. 이번 건도 그런 관점에서 자기 환경을 한 번 훑어보는 계기로 삼으면 좋겠음.

혹시 사내 Fortinet 장비 로그를 SIEM에 어떤 식으로 정규화해 두셨는지, 더 좋은 탐지 룰을 쓰고 계신 분이 있다면 댓글로 공유해 주시면 저도 배우겠음. 같이 다듬어 보아요!