advanced-threat-research/cve-2020-16899CVE-2020-16899 - Microsoft Windows TCP/IP 취약점 탐지 로직 및 규칙
10월 13일, Microsoft는 최신 버전의 Windows 10 및 Windows Server 2019에서 공격자가 악의적으로 조작된 패킷을 전송하여 즉각적인 BSOD(Blue Screen of Death)를 유발할 수 있는 Windows IPv6 스택의 심각한 취약점을 발표했습니다. 이 취약점은 공격자에게 코드 실행 권한을 부여하지는 않는 것으로 보이지만, 취약한 Windows 버전을 대상으로 대규모 서비스 거부(denial-of-service) 공격에 악용될 수 있습니다. 더 큰 영향을 미치는 RCE 버전의 이 취약점에 대한 탐지 로직은 CVE-2020-16898: "Bad Neighbor"에서 확인할 수 있습니다.
이 문서는 McAfee Advanced Threat Research에서 작성했습니다. 이 취약점을 더 깊이 이해하고 악용으로부터 방어하려는 네트워크 관리자와 보안 담당자에게 유용한 통찰력을 제공하기 위한 것입니다. 여기에서 생성된 시그니처는 프로덕션 환경에서 사용하기 전에 스테이징 환경에서 충분히 검토되고 검증되어야 하며, 대상 배포 환경에 맞춰 특정 튜닝이 필요할 수 있습니다.
여기에 제공된 정보는 예고 없이 변경될 수 있으며, 특정 상황이나 환경에 대한 정보의 정확성 또는 적용 가능성에 대해 보증이나 보장 없이 "있는 그대로(AS IS)" 제공되며, 사용에 따른 책임은 사용자 본인에게 있습니다. 또한 당사는 어떤 시그니처에 대한 성능 또는 효율성 벤치마크를 보장할 수 없습니다.
이 취약점은 Windows IPv6 스택이 하나 이상의 DNSSL 옵션 레코드(옵션 유형 = 31)를 포함하는 ICMPv6 라우터 광고(Router Advertisement, 유형 = 134) 패킷을 처리할 때 발생할 수 있는 out-of-bounds(범위 밖) 읽기의 결과입니다. DNSSL 레코드의 목적은 마지막 필드에 포함된 DNS 이름 접미사의 검색 목록을 제공하는 것입니다. 이 검색 목록은 여러 개의 null로 종료된 DNS 이름을 연속으로 보유할 수 있으므로 필드(따라서 전체 레코드)의 크기가 크게 달라질 수 있습니다. 이를 수용하기 위해 DNSSL 옵션 레코드에는 자체 길이(Length) 필드가 포함되어 있습니다. 그러나 길이는 8바이트 단위로 계산되므로 검색 목록의 도메인 이름 중 최소 하나는 레코드의 8바이트 정렬을 유지하기 위해 추가 null 패딩이 있을 수 있습니다. 취약점은 바로 이 null 처리 과정에서 발견될 수 있습니다.
Windows IPv6 스택은 검색 목록의 각 도메인 이름에 대해 256바이트 버퍼를 할당합니다. RFC 1035는 도메인 이름을 255바이트로 제한하므로 일반적으로 도메인 이름과 null 종결자를 포함하기에 충분합니다. 그러나 각 도메인 이름 끝의 후행 null을 소비하는 코드에는 옵션에 남은 바이트 수와 동일한 상한이 있으며, 이는 256바이트를 초과할 수 있습니다. 그 결과 null 소비 코드가 버퍼에 할당된 것보다 더 많은 바이트를 잘못 소비하여 out-of-bounds 읽기가 발생할 수 있습니다. 버퍼가 메모리 페이지 끝에 있는 경우 이 OOB 읽기는 BSOD를 유발할 수 있습니다.
이 취약점에 대한 Suricata 시그니처는 cve-2020-16899.rules에 있으며 다음 로직을 포함합니다:
alert icmp any any -> any any (msg:"Potential CVE-2020-16899 Exploit"; lua:cve-2020-16899.lua; sid:202016899; rev:1;)
해당 Lua 스크립트는 cve-2020-16899.lua에서 찾을 수 있습니다. 스크립트에는 ICMPv6 레이어를 제대로 파싱하고 CVE-2020-16899의 잠재적 악용을 식별하는 데 필요한 로직이 다음과 같이 포함되어 있습니다:
ICMPv6 레이어의 시작을 찾으면 레이어의 첫 번째 바이트를 테스트하여 라우터 광고 ICMPv6 패킷인지 확인합니다. 만약 그렇지 않으면 종료합니다.
Suricata 프리미티브가 ICMPv6 옵션을 파싱하도록 업데이트되지 않았으므로 ICMPv6 레이어의 17번째 바이트로 점프합니다. 옵션이 있는 경우 옵션이 시작되는 위치이기 때문입니다(처음 16바이트는 RFC 4443에 따른 정적 길이 필드입니다). 그런 다음 패킷의 바이트가 소진될 때까지 모든 옵션을 반복합니다. 각 옵션에 대해 옵션 유형 필드에 해당하는 첫 번째 바이트를 검사합니다. DNSSL이 아닌 모든 옵션은 무시하지만, 옵션 유형 = 31(DNSSL)의 경우 옵션의 길이(두 번째 바이트)가 취약점을 트리거하는 데 필요한 최소 길이인 35 이상인지 확인합니다:
