[관점]
끄는 일이 우선순위에서 밀리는 이유는 위험이 작아서가 아니라 효과가 눈에 보이지 않기 때문이다. 변경 심의에 「정찰 정보가 덜 새어 나간다」를 들고 가면 통과하기 어렵다.
그래서 조치 순서를 나누어야 한다. 정보 유출에 그치는 것과 실제 트래픽 가로채기로 이어지는 것을 구분해 후자를 앞에 두면 심의에 올릴 논거가 달라진다. 같은 작업이라도 「정보가 덜 샌다」와 「중간자 공격 경로를 닫는다」는 다른 문장이다.
오래된 공격면의 재점검 필요성
기술이 빠르게 바뀌면서 새로운 공격 벡터와 공격면이 끊임없이 생겨난다. 그래서 새로 등장하는 변화를 따라가는 것만큼이나, 이미 오래된 기술과 과거에 한 번 식별해 둔 공격면을 다시 점검해 적절한 보안 조치가 실제로 적용되어 있는지 확인역할이 중요하다.
Pentera Labs 는 표준 보안 도구가 놓치기 쉬운 이런 취약 지점을 찾아내는 것을 연구 목표로 삼는다. 레드팀과 침투 테스터는 이를 활용할 수 있고, 방어자는 존재 자체를 인지할 수 있게 하기 위해서다.
원문은 MS-LLTD, mDNS, ICMPv6 세 가지 네트워크 프로토콜이 어떻게 공격에 쓰일 수 있는지를 설명한다. 이 셋을 고른 이유는 분명하다. 플랫폼과 내부망에서 흔히 쓰이지만, 발생시키는 트래픽 양이 워낙 적어서 쉽게 무시되기 때문이다.
낮은 위험으로 취급되는 프로토콜도 공격자에게 가치 있는 정찰 정보와 중간자 공격(MITM) 기회를 제공한다. 위험은 프로토콜 자체에만 있는 것이 아니라, 간과된 트래픽이 얼마나 손쉽게 디스커버리·스푸핑·내부 확산에 악용될 수 있는가에 있다.
1. MS-LLTD
LLTD(Link-Layer Topology Discovery)는 링크 계층 이벤트 알림을 전송하기 위한 표준 프로토콜이다. 목적은 장치가 네트워크의 링크 계층 토폴로지를 파악할 수 있게 하는 것이다. MS-LLTD 는 Microsoft 의 LLTD 구현이다.
동작 방식은 이렇다. “Quick Discovery” 과정에서 장치는 ethernet broadcast address 로 브로드캐스트 메시지를 보낸다. “LLTD capable” 한 장치는 여기에 “Hello” 메시지로 응답한다. 이 응답 메시지에는 응답 station 자신에 대한 정보 목록 — ipv4, ipv6, host id 등 — 이 TLV 라는 사전 정의된 구조에 담겨 실려 온다.
위험 — 이렇게 흘러나온 정보는 네트워크 디스커버리에 쓰일 수 있다.
네트워크 디스커버리란
네트워크 디스커버리는 장치들이 네트워크 상에서 서로를 찾아내고 연결하는 과정이다. 이 단계에서는 물리 장치 — 802.x 네트워크에서는 보통 ethernet address 로 정의된다 — 가 다른 종류의 논리 정보(대개 IPv4 및 IPv6 주소)에 매핑된다.
네트워크 디스커버리는 장치가 다른 장치와 통신하기 위해 가장 먼저 수행하는 동작이다. 그리고 같은 이유로 공격자가 공격에서 가장 먼저 취하는 행동 중 하나이기도 하다. 환경을 지도화할 수 있게 해 주기 때문이다.
2. mDNS
mDNS(Multicast Domain Name Service)는 직렬화된 unicast DNS 서버 없이도 호스트가 로컬 네트워크에서 DNS 와 유사한 동작을 수행할 수 있게 해 주는 프로토콜이다. 기존 DNS 프로토콜을 기반으로 한 제로 컨피규레이션(zero-configuration) 서비스다.
DNS 프로토콜에서와 마찬가지로, 호스트는 mDNS 를 사용해 IP 주소(A, AAAA records), 서비스 포인터(SRV records) 등을 조회할 수 있다. mDNS 서비스를 구현한 장치는 이런 질의에 응답하며, 심지어 자신의 IPv6 주소 같은 추가 데이터까지 함께 제공한다.
위험 — MS-LLTD 와 마찬가지로, 이 정보 역시 네트워크 디스커버리에 활용될 수 있다.
3. ICMPv6
ICMPv6 는 IPv6 프로토콜 위에서의 ICMP 구현이다. ICMP 와 유사하며 대부분의 메시지 타입 — Echo, Redirect, Destination Unreachable — 을 그대로 갖고 있다.
ICMPv6 는 IPv4 의 여러 문제를 해결하기 위한 새로운 기능을 도입했는데, 그중 하나가 NDP(Neighbor Discovery Protocol)라는 ICMPv6 확장이다.
그런데 이 기능은 공격자가 피해자의 네트워크 트래픽을 가로챌 수 있게 만들기도 한다. router advertisement 메시지를 스푸핑해 해당 링크에 연결된 노드들의 네트워크 구성에 영향을 주는 방식이다. 그 결과 피해자는 새 IPv6 DNS 를 자신의 DNS 목록에 추가하게 되고, 새로운 global IPv6 주소를 자동 구성(auto-configure)하게 된다.
위험 — 이 중간자 공격(MITM) 기법은 2011년 InfoSec Institute 가 처음 공개하였으며 “SLAAC Attack” 이라고 불린다.
마무리
조직에는 공격자보다 먼저 이런 사각지대를 찾아내기 위한 더 깊은 내부 가시성과 지속적인 검증(continuous validation) 이 필요하다.
참고 — 원문 블로그는 Pentera Labs 종합 연구 백서의 개요다. 프로토콜을 실제로 사용해 네트워크 디스커버리와 MITM 공격을 수행한 단계별 절차, 추가 관찰과 상세 설명은 백서 쪽에 담겨 있다. 블로그 본문에는 해당 절차와 비활성화 방법이 포함되어 있지 않다.
국내 적용 관점
첫째, Windows 도메인 기본 설정을 그대로 운영하는 관행이 이 문제의 출발점이다. 원문이 지적하는 세 프로토콜의 공통점은 「공격자가 무언가를 심어야 켜지는 것」이 아니라 처음부터 켜져 있다는 점이다. MS-LLTD 는 Microsoft 구현으로 Windows 환경에 내장되어 있고, mDNS 는 제로 컨피규레이션 서비스로서 설정 없이 동작하는 것이 설계 목적이며, ICMPv6/NDP 는 IPv6 스택의 필수 구성요소이다. 국내 다수 조직이 도메인 구축 시 벤더 기본 프로파일을 그대로 채택하고 이후 손대지 않는다는 점을 감안하면, 별도 조치가 없는 한 이 세 프로토콜은 지금도 사내망에서 응답하고 있다고 보는 편이 현실에 가깝다.
둘째, 그룹 정책 일괄 배포 구조에서는 「끄는 일」이 구조적으로 뒤로 밀린다. 원문이 강조하듯 이 프로토콜들이 방치되는 이유는 위험이 없어서가 아니라 트래픽 양이 적어 눈에 띄지 않기 때문이다. 국내 환경에는 운영 구조 요인이 하나 더 붙다. 그룹 정책은 전사 일괄 적용이 원칙이라 프로토콜 하나를 끄려 해도 전 단말 영향도 검토, 레거시 업무 시스템 호환성 확인, 변경관리 승인이 선행되어야 한다. 반면 얻는 효과는 「정찰 정보가 덜 새어 나간다」는 정성적 개선이라 변경 심의에서 우선순위를 얻기 어렵다. 조치 순서를 정할 때는 정보 유출에 그치는 MS-LLTD·mDNS 와, 실제 트래픽 가로채기로 이어지는 ICMPv6/NDP 를 구분해 후자를 앞에 두는 편이 합리적이다.
셋째, 사내망을 신뢰 구간으로 보는 전제가 이 공격들의 성립 조건이다. 원문의 세 기법은 모두 공격자가 이미 같은 링크(link) 위에 있다는 상황을 전제한다. 브로드캐스트 응답 수집도, 멀티캐스트 질의 응답도, router advertisement 스푸핑도 동일 브로드캐스트/링크 도메인 안에서 일어난다. 즉 경계 방화벽과 외부 차단으로는 아무것도 막히지 않다. 국내에서 흔한 「내부망은 통과한 사람만 있으니 안전하다」는 전제는, 단말 한 대만 침해되거나 협력사 장비 한 대만 물려도 곧바로 무너진다.
넷째, 망분리 환경이라고 해서 내부망 MITM 이 배제되지는 않다. 망분리는 업무망과 인터넷망 사이의 경계를 통제하는 방식이지, 같은 업무망 안에 있는 단말들 사이의 링크 계층 통신을 통제하지는 않다. SLAAC Attack 이 성립하는 조건은 인터넷 연결이 아니라 동일 링크상의 IPv6 노드 존재이다. 특히 IPv6 는 국내 다수 조직에서 「우리는 IPv4 만 쓴다」고 인식되지만 실제로는 OS 기본값으로 스택이 활성화되어 있고 IPv4 관제 체계에는 잡히지 않는 경우가 많다. 망분리 환경일수록 IPv6 트래픽이 관제 사각지대에 놓이기 쉬우므로, 분리 여부와 별개로 각 세그먼트 내부에서 이 프로토콜들이 실제로 응답하는지를 직접 확인해 보시기 바랍니다.
출처 · Pentera (Pentera Labs), Death by Default: Neglected Network Protocols You Should Know (2023-07-13, Pentera Team (개별 연구원명 미표기))