방화벽이 지워야 할 것을 안 지웠을 때 — Cisco ASA·FTD 힙 검사 결함 들여다보기

이미지 출처: CISA KEV

장비 리부팅 후 메모리 코어를 받아 열어보면, 거기엔 있어서는 안 될 것들이 심심찮게 섞여 있음. 세션 조각, 다른 사용자의 요청 일부, 심지어 인증 관련 문자열까지. 이번에 공개된 CVE-2026-20349는 바로 그 "안 지워진 힙 메모리"를 외부에서 들여다볼 여지가 생기는 문제로, 대상은 하필이면 조직의 경계에 서 있는 Cisco Secure Firewall ASA와 FTD임.

핵심 요약

• Cisco ASA/FTD의 힙 메모리 처리 결함으로, 해제되거나 초기화되지 않은 메모리 영역의 잔여 데이터가 응답에 섞여 나갈 수 있는 정보노출 계열 이슈임
• 코드 실행보다 "정보가 새는" 쪽에 가깝지만, 경계 장비의 메모리 조각은 세션·설정·인증 흔적을 담고 있어 후속 공격의 발판이 됨
• 방어는 세 단계 — 노출된 관리·VPN 인터페이스 축소, 비정상 응답 크기/패턴 탐지, 벤더 픽스 적용 후 세션·인증정보 재발급

힙 검사(Heap Inspection)라는 게 뭔가

이름이 좀 낯설게 들리는데, 개념 자체는 단순함. 프로그램이 메모리를 할당받아 쓰고 반납할 때, 그 안에 남아 있던 내용을 명시적으로 지우지 않으면 다음에 그 자리를 받아 쓰는 코드가 이전 데이터를 그대로 보게 됨. 여기에 더해 "쓸 만큼만 채우고 버퍼 전체를 응답으로 내보내는" 식의 구현이 겹치면, 남은 뒷부분에 이전 세션의 찌꺼기가 그대로 실려 나감.

웹 쪽에서 유명했던 Heartbleed가 딱 이 구조였음. 그때도 실행 흐름을 탈취당한 게 아니라 그냥 메모리 조각이 흘러나왔을 뿐인데, 그 조각 안에 개인키와 세션 쿠키가 들어 있어서 사태가 커졌음. 정보노출 결함을 "심각도 낮음"으로 분류하고 넘어가면 안 되는 이유가 여기 있음.

왜 하필 ASA·FTD인가

ASA와 FTD가 서 있는 자리를 생각해보면 답이 나옴. 이 장비들은 조직으로 들어오는 트래픽을 전부 처리하고, 원격근무자 VPN을 종단하고, 관리자 세션을 받아주고, 인증 서버와 대화함. 즉 메모리 안에 조직에서 가장 민감한 문자열들이 상시로 떠다니는 장비임.

• VPN 사용자 자격증명과 세션 토큰 — 인증 처리 과정에서 메모리를 거쳐 감
• WebVPN/관리 인터페이스의 세션 식별자 — 탈취되면 인증 우회와 다름없음
• 설정 조각과 내부 IP 대역 — 내부망 정찰 지도로 쓰이기 좋음
• 인증서·키 관련 데이터 — 최악의 경우 복호화나 위장으로 이어짐

공격 재현 자체는 개념적으로 단순함. 특정 요청을 반복적으로 던지고, 돌아오는 응답에서 요청한 적 없는 바이트가 섞여 나오는지를 계속 긁어모으는 방식임. 한 번에 대박이 터지는 게 아니라 수천, 수만 번을 반복해 조각을 모으는 성격이라, 역설적으로 탐지 관점에서는 흔적이 잘 남는 편임. 이게 우리가 파고들 지점임.

탐지 — 무엇을 봐야 하나

메모리를 훑어가는 공격은 반드시 "반복"이라는 형태로 나타남. 그래서 로그를 볼 때 한 건짜리 이상 요청을 찾기보다, 시간축 위에서 같은 요청이 비정상적으로 쌓이는지를 봐야 함.

• 동일 출발지의 고빈도 반복 요청 — 특히 VPN 포털이나 관리 인터페이스 경로로 초당 수십 건 이상이 들어온다면 정상 사용자 패턴이 아님
• 응답 크기의 이상 분포 — 같은 엔드포인트인데 응답 길이가 들쭉날쭉하다면 버퍼 잔여 데이터가 실려 나가는 신호일 수 있음
• 인증 실패는 없는데 세션이 늘어나는 상황 — 어디선가 유효한 세션 식별자를 주워왔다는 뜻일 수 있음
• syslog의 메모리·연결 관련 이상 메시지 — 장비 자체가 힘들어하는 신호는 대개 로그에 먼저 뜸
• 지리적으로 설명되지 않는 접속 — VPN 계정이 평소와 전혀 다른 지역에서 붙는지 확인

개인적으로는 이런 종류를 잡을 때 IDS 시그니처보다 NetFlow나 방화벽 자체 로그의 통계적 이상치를 먼저 보는 걸 추천함. 페이로드가 특별히 이상하게 생긴 게 아니라 "정상 요청을 너무 많이 보내는" 형태라서, 내용을 보는 탐지는 쉽게 놓침. 반면 볼륨과 빈도는 거짓말을 못 함.

완화 — 순서대로 해보면 좋을 것들

패치가 정답인 건 맞는데, 경계 장비는 아무 때나 재부팅할 수 있는 물건이 아니다 보니 현실적으로는 단계를 나눠 가는 게 낫다고 봄.

• 1단계 — 표면 줄이기. 관리 인터페이스가 인터넷에서 보이는지부터 확인. ASDM·SSH·HTTPS 관리 접근은 관리망 또는 점프호스트에서만 되도록 ACL로 묶어두기. VPN 포털처럼 반드시 열어야 하는 건 남기되, 그 외는 과감히 닫는 게 맞음
• 2단계 — 앞단에서 속도 제한. 공격이 반복 요청 형태라면 요청 빈도 제한만으로도 수집 효율을 크게 떨어뜨릴 수 있음. WAF나 앞단 로드밸런서에서 출발지별 레이트리밋을 거는 것도 방법임
• 3단계 — 버전 확인과 픽스 적용. 벤더 권고에 명시된 대상 버전인지 확인하고, 유지보수 창을 잡아 적용. 여기서 중요한 건 "우리가 어떤 기능을 켜놓고 있는지"임. 대개 이런 결함은 특정 기능이 활성화된 경우에만 성립함
• 4단계 — 패치 후 정리. 이게 자주 빠지는 부분인데, 정보노출 결함은 패치했다고 이미 새어나간 게 회수되지 않음. 관리자 비밀번호, VPN 사전공유키, 세션 토큰, 필요하다면 장비 인증서까지 새로 발급하는 걸 계획에 넣어야 함

사후 점검 — 이미 당했다면 어디를 보나

메모리 유출은 흔적이 옅어서, 장비 안쪽만 봐서는 판단이 어려움. 그래서 시선을 밖으로 돌려야 함. 유출된 자격증명이 실제로 쓰였다면 그건 내부망 로그에 남기 때문임.

• VPN 접속 이력에서 평소 안 쓰던 시간대·지역·단말 조합이 있는지
• AD 인증 로그에서 서비스 계정이 갑자기 대화형 로그인을 하는지
• 방화벽 설정 변경 이력 — 조용히 추가된 ACL 한 줄이 가장 위험함
• 내부에서 외부로 향하는 새로운 상시 연결(비콘 형태의 주기적 통신)

경계 장비 취약점을 몇 번 겪다 보면 결국 같은 결론에 닿게 되는 것 같음. "막아주는 장비"도 결국 소프트웨어라는 것. 방화벽을 신뢰의 종점으로 두지 말고, 그 뒤에도 세그먼트를 나누고 인증을 한 번 더 요구하는 구조를 만들어두면 이런 소식이 나올 때마다 마음이 훨씬 편해짐.

오늘 바로 해볼 수 있는 건 딱 하나임. 우리 조직 ASA/FTD의 관리 인터페이스가 인터넷에서 응답하는지 확인해보기. 생각보다 열려 있는 곳이 많음. 확인해보고 결과가 어땠는지 댓글로 공유해주면 좋겠음. 같이 점검해보아요!