QUIC 종료: QUIC을 통해 SMB를 실행하는 Windows 서버의 DoS 취약점
Executive Summary
Akamai 연구원 벤 바네아(Ben Barnea)는 Microsoft Windows Server 2022에서 중요 취약점을 발견했으며, 이 취약점은 CVE-2023-24898로 지정됐고 기본 점수는 7.5입니다.
이 취약점은 srvnet.sys 드라이버의 버퍼 할당 검사 누락으로 인해 발생합니다.
이 취약점은 Windows Server 2022 머신에 대한 DoS(Denial-of-Service) 공격으로 이어질 수 있습니다. 이 취약점은 인터넷을 통해 인증되지 않은 공격자에 의해 트리거될 수 있습니다.
비교적 새로운 기능인 SMB over QUIC를 사용하는 서버만 취약합니다. 이 기능을 사용하려면 서버가 Windows Server 2022 Azure 버전이어야 합니다.
이 취약점은 Microsoft에 보고되어 2023년 5월 패치 화요일(Patch Tuesday)에서다루었습니다.
Akamai는 인사이트 쿼리를 Akamai Guardicore Segmentation 사용자에게 제공하여 네트워크에서 잠재적으로 취약할 수 있는 서버를 탐지할 수 있도록 합니다.
서론
QUIC는 비교적 새로운 전송 레이어 프로토콜로, 원래는 Google에서 설계했지만 여러 가지 버전이 있습니다. QUIC의 목적은 지연 시간과 패킷 손실 같은 일반적인 인터넷 문제를 극복하면서 보다 신뢰할 수 있고 안전한 연결을 제공하는 것입니다. 이는 UDP로 이어집니다.
Microsoft가 구축한 QUIC는 MsQuic이라고합니다. Windows는 또한 QUIC를 통합해 SMB 프로토콜의 전송 레이어로 사용하며( SMB over QUIC기능) IIS에서 HTTP/3과 함께 사용합니다. SMB over QUIC은 Windows Server 2022 Azure 에디션에서만사용할 수 있으며, HTTP/3은 Windows Server 2022에서 실행되는 모든 IIS 배포에서 사용할 수 있습니다.
이 블로그 게시물에서 설명하는 취약점은 SMB의 전송 레이어를 구축하는 드라이버인 srvnet.sys에있습니다.
취약점
QUIC은 연결 상태를 유지하기 위해 클라이언트와 서버 간의 연결을 고유하게 식별하는 연결 식별자를 사용합니다. 클라이언트는 여러 개의 동시 연결을 생성할 수 있습니다. QUIC 연결도 멀티플렉싱됩니다. 즉, 클라이언트와 서버는 동일한 연결에서 동시에 여러 스트림을 통해 데이터를 교환할 수 있습니다.
SMB over QUIC의 코드는 srvnet.sys에구축됩니다. 서버가 스트림에서 새 데이터를 수신하면 SrvNetQuicServerReceiveEvent 함수가 호출됩니다. 이 함수의 목적은 클라이언트가 보낸 전체 SMB 메시지를 읽는 것입니다. 성공적으로 메시지를 읽은 후에는 추가 처리를 위해 메시지를 SMB 메시지 목록으로 전송합니다.
SMB 메시지를 읽기 위해 코드는 먼저 4바이트 정수로 표시되는 SMB 메시지의 크기를 읽으려 합니다. 메시지를 성공적으로 읽으면 크기가 할당을 위한 최대 허용 크기보다 크지 않은지 확인합니다. 검사를 통과하면 코드는 이 크기의 버퍼를 할당하고 패킷의 나머지 바이트를 새로 할당된 버퍼로 읽으려 합니다. 전체 SMB 메시지 읽기를 완료하면 SMB 레이어에 새 SMB 메시지가 수신되었음을 알립니다.
SMB 메시지의 구조는 그림 1에 나와 있습니다.
그림 1: srvnet.sys의 SMB 메시지 구조
SMB 메시지 크기가 4바이트 미만이 수신되는 경우 취약점이 발생합니다 (그림 2). 이 경우 코드는 수신된 X 바이트를 저장하고 PendingMessageSize를 4에서 X를 뺀 값으로 설정합니다. 여기서 X는 수신된 메시지 크기의 바이트 수입니다. 이후 패킷을 수신할 때는 SMB 메시지 크기에 필요한 바이트(4에서 X를 뺀 나머지)를 읽습니다.
그림 2: 악성 패킷의 메시지 크기: 4바이트 미만
코드가 메시지 크기를 읽은 후에는 즉시 SMB 메시지를 할당하며, 최대 허용 크기를 기준으로 해당 크기를 확인하지 않습니다. 따라서 공격자는 SMB 메시지 크기를 한 패킷이 아닌 두 패킷으로 전송함으로써 최대 허용 크기 확인을 우회하고 예외적으로 큰 할당을 요청할 수 있습니다.
악용
이 버그를 DoS 취약점으로 전환하려면 설명한 문제를 트리거하는 패킷이 지속적으로 전송되어야 합니다.
그러나 최대 허용 크기를 우회하는 기능이 있더라도 여전히 두 가지 제한이 있습니다.
1. SrvNetAllocateBuffer는 16MB의 하드 할당 제한이 있습니다.
2. 서버의 사용 가능한 RAM에 따라 허용되는 인증되지 않은 동시 연결 수가 제한됩니다. 이 제한은 악용을 최대 32GB의 RAM이 있는 서버로 제한합니다. (다음 섹션에서는 이 제한을 우회하는 방법에 대해 이론적으로 설명하겠습니다.)
이 취약점을 악용하기 위해 먼저 여러 연결을 생성하고 매번 두 개의 패킷을 전송해 서버가 16MB를 할당하도록 했습니다. 이 작업을 반복하면 메모리가 고갈됩니다. 이 취약점은 드라이버에 있으며 커널 모드에서 실행되기 때문에 전체 시스템이 불안정해지고 응답하지 않게 됩니다.
최적화된 악용?
이 악용은 많은 패킷을 전송해야 합니다. Akamai는 QUIC의 기능을 악용하면 필요한 패킷 수를 줄일 수 있다고 생각합니다.
QUIC는 단일 연결을 통해 여러 스트림을 허용하지만, 이 수를 제한하기 위해 initial_max_streams_bidi 속성을 사용할 수 있습니다. SMB over QUIC은 연결의 동시 스트림 수를 1로 제한합니다.
여러 개의 동시 스트림을 사용해 악용을 개선할 수는 없지만, 다른 방법으로 취약점을 악용할 수는 있습니다. 여러 개의 동시 스트림을 생성하는 대신 여러 프레임이 포함된 하나의 QUIC 패킷을 생성해 다음과 같은 시퀀스가 연속적으로 반복적으로 발생하도록 합니다.
1. 스트림을 생성합니다.
2. 두 개의 데이터 프레임을 전송해 16MB 할당을 트리거합니다.
3. 스트림을 닫습니다.
이렇게 하면 인증되지 않은 연결 제한을 우회할 수도 있습니다. 이 방법은 독자들의 도전 과제로 남겨두겠습니다.
탐지 및 방어
실행 중인 SMB over QUIC 서버를 찾기 위해 Akamai Guardicore Segmentation 사용자는 다음과 같은 간단한 Insight 쿼리를 실행할 수 있습니다.
select * from registry where
path="HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\EnableSMBQUIC" and data=1
이 취약점에 대한 다른 방어 방법이나 해결 방법은 SMB over QUIC 기능을 끄는 것 외에는 없으므로 Windows Server 머신에 패치를 적용하는 것이 좋습니다.
요약
QUIC는 성능 향상과 지연 시간 감소를 보장하는 비교적 새로운 네트워크 프로토콜입니다. 이미 두 개의 매우 유명한 프로토콜인 IIS(HTTP/3용)와 SMB에 도입되어 통합 적용되어 있습니다.
Akamai는 QUIC가 Windows 전반에서, 그리고 일반적으로 흥미로운 새로운 공격표면이라고 될 것이라고 믿습니다. 여기에 설명된 문제 외에 다른 취약점인 CVE-2023-23392는HTTP/3에서 수정되었습니다.
다른 연구자들도 MsQuic을 사용하는 다양한 구성요소와 MsQuic 자체에 대해 조사해 보시기 바랍니다.
