음소거: Outlook에서 RCE를 달성하기 위한 취약점 연결: 1부
Executive Summary
Akamai의 연구원인 벤 바네아(Ben Barnea)는 Microsoft Windows에서 CVE-2023-35384 및 CVE-2023-36710의 두 가지 취약점을 발견했습니다.
인터넷상의 공격자는 이 취약점들을 서로 연결하여 Outlook 클라이언트에 대한 완전한 제로 클릭 원격 코드 실행(RCE) 악용을 만들 수 있습니다.
첫 번째 취약점은 MapUrlToZone 함수에 의한 경로 구문 분석에 있습니다. 이 취약점을 악용하려면 조작된 이메일을 Outlook 클라이언트로 보내야 하며, 그러면 공격자가 제어하는 서버에서 특수 사운드 파일이 다운로드됩니다.
두 번째 취약점은 ACM(Audio Compression Manager)에 있습니다. 이 취약점은 다운로드한 사운드 파일이 자동 재생될 때 악용되며, 피해 머신에서 코드 실행으로 이어질 수 있습니다. 이 취약점에 대한 자세한 내용은 이 블로그 게시물의 2부 에 설명되어 있습니다.
이 취약점은 Microsoft에 책임감 있게 공개되었으며, 2023년 8월 및 2023년 10월 패치 화요일(Patch Tuesday)에 해결되었습니다.
2023년 10월 소프트웨어 업데이트가 설치된 Windows 머신은 이러한 취약점으로부터 보호됩니다. 또한 2023년 3월 소프트웨어 업데이트로 패치된 Exchange 서버를 사용하는 Outlook 클라이언트는 악용되는 기능으로부터 보호됩니다.
개요
2023년 3월 패치 화요일에서 해결된 취약점 중에는 주요 Outlook 취약점 ( CVE-2023-23397으로 할당)이 있었으며 러시아 정부가 지원하는 공격자로 확인된 Forest Blizzard가 인터넷에서 악용한 것으로 드러났습니다. 2023년 12월, Microsoft가 폴란드 사이버 사령부(DKWOC)와 함께 발표한 자료 에 따르면 최근 동일한 공격자가 이 취약점을 악용하려는 시도가 발견되었다고 합니다. 공격자는 이 취약점을 통해 강제로 Outlook 클라이언트가 공격자의 서버에 연결하도록 할 수 있습니다. 이 연결의 일부로 클라이언트는 공격자에게 NTLM 인증정보를 전송하고, 공격자는 이를 오프라인에서 크래킹하거나 릴레이 공격에 사용할 수 있습니다. 이 취약점은 사용자 상호 작용 없이(제로 클릭) 인터넷에서 원격으로 악용될 수 있습니다.
이 취약점에 대한 패치가 릴리스된 후 이전 블로그 게시물에서 설명한 우회 방법을 발견했습니다. 이 우회 방법은 2023년 5월 패치 화요일에 수정되었습니다. 해당 게시물에서 당사는 악용된 기능이 방대하고 복잡한 공격표면을 제공하므로 Microsoft에서 이 기능을 제거할 것을 권장했습니다. 하지만 이 기능이 Outlook에 남아 있었기 때문에 Akamai는 추가 조사를 하기로 결정했습니다.
결국 Outlook에서 전체 RCE 취약점 체인을 확보할 수 있었습니다. 그리고 원래의 Outlook 취약점에 대한 또 다른 우회 방법을 발견했는데, 이 우회 방법을 통해 클라이언트가 공격자가 제어하는 서버에 강제로 연결해 악성 사운드 파일을 다운로드할 수 있었습니다. 그런 다음 일반적으로 모든 오디오 파일, 특히 Outlook의 알림음을 처리하고 재생하는 데 사용되는 Windows 미디어 구문 분석 라이브러리에서 취약점을 발견했습니다. 공격자는 이러한 취약점을 서로 연결하여 취약한 Outlook 클라이언트에서 제로 클릭 RCE를 달성할 수 있습니다.
2부로 구성된 이 블로그 게시물 시리즈에서는 두 가지 취약점을 찾기 위해 수행한 리서치를 소개합니다. 1부에서는 이전 우회 방법과 새로운 우회 방법을 중점적으로 다룹니다. 이제 2부에서는 Akamai가 발견한 미디어 구문 분석 취약점에 대해 설명하겠습니다.
원래 취약점
3월에 패치된 Outlook 취약점은 공격자가 맞춤형 알림음을 사용해 미리 알림을 포함한 메일을 보내면 트리거됩니다. 이 사용자 지정 알림음은 공격자가 확장된 MAPI 속성인 PidLidReminderFileParameter를 사용해 경로로 지정합니다. 공격자는 클라이언트가 SMB 서버에서 사운드 파일을 가져오도록 트리거하는 UNC 경로를 지정할 수 있습니다. Net-NTLMv2 해시는 원격 SMB 서버에 대한 연결의 일부로서 협상 메시지로 전송됩니다(그림 1).
그림 1: NTLM 인증정보 강제 적용
이 문제를 해결하기 위해 이제 코드에서 MapUrlToZone 을 호출해 경로를 인트라넷, 로컬 또는 인터넷으로 분류합니다. URL이 인터넷의 리소스를 가리키면 사용자 지정 알림 소리 대신 기본 알림 소리가 사용됩니다.
우회 경로 찾기
방어 조치가 시행된 후, 당사는 이를 우회할 수 있는지 자문해 보았습니다.
여기서 우회란 로컬리티 테스트를 통과하고 원격 위치에서 Outlook를 통해 사운드 파일을 다운로드하는 데 사용할 수 있는 경로를 의미합니다. 다시 말해 MapUrlToZone 은 인터넷이 아닌 것으로 간주하지만 CreateFile 은 인터넷 도메인으로 처리하는 경로를 찾아야 합니다.
이러한 우회 경로를 찾으려면 함수의 내부 작동 방식과 경로 구문 분석의 일부로 수행되는 작업을 완전히 이해해야 했습니다.
Windows 경로 및 URL
Windows에는 다양한 종류의 DOS 경로가 있으며, 이 경로와 NT 경로로의 변환에 대한 많은 리서치가 수행되었습니다. 여기서는 다양한 Windows 경로 종류에 대해 다루지 않을 것이며, 이 주제에 대한 자세한 내용은 제임스 포쇼(James Forshaw)의 블로그 게시물 에서 확인할 수 있습니다.
관심 있는 함수로 돌아가 보겠습니다. CreateFile은 Windows 경로를 받고 MapUrlToZone (이름에서 알 수 있듯이)은 URL 또는 경로를 전달할 수 있습니다. 우회 경로를 찾으려면 먼저 각 함수(또는 두 함수 모두)가 지원하는 경로 종류를 이해해야 합니다.
참고: CreateFile 및 MapUrlToZone은 경로를 직접 처리하지 않고 다른 WinAPI 함수를 사용합니다. 간결성을 위해 CreateFile 및 MapUrlToZone을 사용하여 해당 함수의 기본 경로 구문 분석 함수를 참조하겠습니다.
CreateFile |
MapUrlToZone |
|
|---|---|---|
RtlPathTypeUncAbsolute |
✔ |
✔ |
RtlPathTypeDriveAbsolute |
✔ |
✔ |
RtlPathTypeDriveRelative |
✔ |
✔ |
RtlPathTypeRooted |
✔ |
✘ |
RtlPathTypeRelative |
✔ |
✘ |
RtlPathTypeLocalDevice |
✔ |
✔ |
RtlPathTypeRootLocalDevice |
✔ |
✘ |
Schemes(file://, http://) |
✘ |
✔ |
표 1: 비교 차트 - CreateFile 및 MapUrlToZone 경로 기능
표 1에서 볼 수 있듯이 두 함수 모두 네 가지 경로, 즉 RtlPathTypeUncAbsolute, RtlPathTypeDriveAbsolute, RtlPathTypeDriveRelative , RtlPathTypeLocalDevice만 지원합니다.
첫 번째 시도
우회 경로를 찾기 위한 첫 번째 시도는 절대 UNC 경로(RtlPathTypeUncAbsolute)를 사용했습니다. 그림 2는 경로의 구조를 자세히 보여줍니다.
그림 2: 절대 UNC 경로 및 구성요소
Windows는 경로 구성요소가 시작되는 위치를 어떻게 알 수 있을까요? 표 2는 관련 코드(RtlGetFullPathName_Ustr)를 보여줍니다.
case RtlPathTypeUncAbsolute:
SeperatorsFound = 0;
for ( CurrentIndex = 2; CurrentIndex < InputPathLength; ++CurrentIndex )
{
CurrentChar = InputPathString->Buffer[CurrentIndex];
if ( CurrentChar == '\\' || CurrentChar == '/' )
{
SeperatorsFound++;
if ( SeperatorsFound == 2 )
break;
}
}
표 2: UNC 경로를 처리하는 RtlGetFullPathName_Ustr 코드 스니펫
코드에서 절대 UNC 접두사("\\")를 건너뛰고 경로 구성요소가 두 번째 경로 구분 기호('\' 또는 '/') 뒤 한 글자부터 시작한다고 가정하는 것을 볼 수 있습니다.
하지만 "\\\\localhost\..\Akamai.com\dir\file.txt"와 같은 경로를 제공하면 어떻게 될까요?
이 경로는 다음과 같이 처리됩니다.
"\\\\"는 UNC 접두사 및 루트 경로 구성요소로 해석됩니다
경로 구성요소는 "localhost\..\Akamai.com\dir\file.txt"입니다
일반적으로 루트 경로에 ".."가 오면 안 됩니다. 예를 들어, "\\localhost\directory\..\file.txt"는 "\\localhost\directory\file.txt"가 됩니다. 그러나 이 예제에서는 ".."가 루트 경로의 일부가 아니기 때문에 경로가 "\\\Akamai.com\dir\file.txt"로 변환됩니다.
즉, 경로의 일부를 삭제해 경로를 변조할 수 있는 방법을 찾았습니다.
이것이 CreateFile이 이 경로를 처리하는 방식입니다. MapUrlToZone은 어떻게 처리할까요(표 3)? 먼저 여분의 백슬래시를 제거하여 경로를 다른 방식으로 해석합니다.
\\localhost는 서버 이름입니다
서버 이름 위로는 갈 수 없으므로 \..\는 무시됩니다
경로 구성요소는 Akamai.com\dir\file.txt로 구성됩니다
인풋 경로: \\\\localhost\..\Akamai.com\dir\file.txt |
|
|---|---|
CreateFile |
MapUrlToZone |
\\\Akamai.com\dir\file.txt |
\\localhost\Akamai.com\dir\file.txt |
표 3: CreateFile 및 MapUrlToZone의 인풋 경로와 구문 분석 결과
MapUrlToZone은 위에 표시된 출력 경로에 대해 0(로컬)을 반환합니다.
우회 경로를 찾은 것처럼 보이지만, 안타깝게도 이 경로를 사용하여 UNC 요청을 트리거할 수는 없습니다. CreateFile이 처리하는 경로의 시작 부분에 슬래시가 하나 더 있는 것을 볼 수 있는데, 이는 서버 이름이 비어 있음을 나타냅니다. MUP(Multiple UNC Provider)가 여러 네트워크 공급업체에게 이 (비어 있는) 서버 이름을 처리할 수 있는지 여부를 쿼리하면 모두 거짓을 반환하므로 요청이 이루어지지 않습니다.
이 경로를 처리하는 MapUrlToZone및 CreateFile의 방식 차이를 악용하면 추가 백슬래시를 생략하는 방법을 찾거나 MUP 코드에서 구문 분석 불일치를 찾는 등 더 복잡한 솔루션이 필요할 수 있습니다. 이것은 향후 리서치를 위한 제안입니다.
두 번째 시도: 1번 우회 경로(CVE-2023-29324)
절대 UNC 경로로 재생하는 것이 실제로 작동하지 않았기 때문에, UNC를 지원하는 다음 경로 종류인 RtlPathTypeLocalDevice로계속 진행했습니다. “\\.\UNC\Akamai.com\test.wav”는 로컬 디바이스 경로의 예입니다. 구체적으로, 이는 MUP 드라이버로 리디렉션되는 UNC 디바이스 이름을 가리킵니다.
앞서 말했듯이 우회 경로를 찾으려면 경로 구문 분석의 일부로 수행되는 다양한 작업을 살펴봐야 합니다. 표 4는 그 차이를 보여줍니다.
CreateFile |
MapUrlToZone |
|---|---|
RtlPathTypeLocalDevice → 4자 전진인 경우 |
RtlPathTypeLocalDevice → 4자 전진인 경우 |
후행 공백 건너뛰기 |
|
'/'를 '\'로 변환 |
|
반복되는 '\' 접기 |
|
'.' 및 '...' 구성요소 제거 |
'.' 및 '...' 구성요소 제거 |
표 4: 경로 구문 분석의 일부로 완료되는 다양한 연산
여기서 CreateFile이 슬래시를 백슬래시로 변환하고 반복되는 백슬래시를 접는 등의 추가 연산을 수행한다는 것을 알 수 있습니다.
추가 경로 구분 기호를 사용하여 이러한 차이점 중 하나를 활용하는 경로를 살펴보겠습니다. 표 5는 코드에서 "UNC\" 접두사를 생략한 후의 결과 경로를 보여줍니다.
인풋 경로: \\.\UNC\\Akamai.com\test.wav |
|
|---|---|
CreateFile |
MapUrlToZone |
Akamai.com\test.wav |
\Akamai.com\test.wav |
표 5: UNC/ 접두사 생략 후 결과 경로
오른쪽 열의 경로를 확인하세요. 경로 구분 기호로 시작하고 그 뒤에 경로 구분 기호가 아닌 문자가 오는 경로를 루팅된 경로라고 합니다. MapUrlToZone은 루팅된 경로 구성요소가 로컬 경로인지 여부를 확인하기 위해 IsRootedPath 또는 IsDrivePath 함수를 사용합니다. 이 경우 경로가 루팅되었으므로 MapUrlToZone은 로컬을 반환합니다.
CreateFile은 UNC 접두사 뒤에 추가 경로 구분 기호가 없으므로 도메인 이름을 올바르게 추출할 수 있으며, 이제 Akamai.com SMB 서버에 접속해 test.wav 파일을 검색합니다. MapUrlToZone은 로컬로 간주하지만 CreateFile은 그렇지 않은 경로를 찾았습니다. 이 우회로 인해 Outlook 취약점 CVE-2023-23397악용이 다시 활성화되었습니다.
이 문제를 방어하기 위해 Microsoft는 두 흐름을 더 유사하게 만들려고 했습니다. 슬래시를 백슬래시로 변환하고 반복되는 경로 구분 기호를 축소하는 작업이 이제 MapUrlToZone 경로 구문 분석 흐름에 추가되었습니다.
생각…
이전 섹션에서 MapUrlToZone이 "\\.\UNC\" 뒤의 경로 구성요소가 드라이브인지 루팅된 경로인지 확인한다고 언급했습니다. 반복되는 경로 구분 기호가 축소되었기 때문에 수정 후에는 이 경로 구성요소를 루팅된 경로로 만들 수 없습니다. 그러나 드라이브 경로(예: "\\.\UNC\C:Akamai.com/test.wav")는 여전히 제공할 수 있습니다.
이렇게 하면 실제로 MapUrlToZone이 0을 반환합니다. 안타깝게도 콜론이 포함된 경로를 처리할 수 있는 네트워크 공급업체는 없으므로 이러한 혼동은 도움이 되지 않습니다. 첫 번째 (실패한) 시도와 마찬가지로, MUP 구문 분석 코드에서 혼동을 발견하면 새로운 취약점이 발생할 수 있습니다.
세 번째 시도: 2번 우회 경로(CVE-2023-35384)
수정 후 두 함수가 수행하는 작업은 거의 동일합니다(표 6).
CreateFile |
MapUrlToZone |
|---|---|
RtlPathTypeLocalDevice → 4자 전진인 경우 |
RtlPathTypeLocalDevice → 4자 전진인 경우 |
후행 공백 건너뛰기 |
|
'/'를 '\'로 변환 |
'/'를 '\'로 변환 |
반복되는 '\' 접기 |
반복되는 '\' 접기 |
'.' 및 '...' 구성요소 제거 |
'.' 및 '...' 구성요소 제거 |
표 6: CreateFile 및 MapUrlToZone 포스트픽스로 수행되는 작업
그러나 더 자세히 살펴보면 다음과 같이 자문해 볼 수 있습니다. 각 함수는 경로가 로컬 디바이스 경로인지 어떻게 결정할까요? 표 7은 경로 종류를 결정하는 데 도움이 되는 각 함수의 코드 스니펫을 보여줍니다.
CreateFile
if (IS_PATH_SEPARATOR(Path[0]) &&
IS_PATH_SEPARATOR(Path[1]) &&
(Path[2] == '.' || Path[2] == '?') &&
IS_PATH_SEPERATOR(Path[3])
return RtlPathTypeLocalDevice;
MapUrlToZone
!strncmp(path, "\\.\", 4) || !strncmp(path, "\\?\", 4)
표 7: 경로 종류를 결정하는 코드 스니펫
CreateFile을사용하면 경로 구분 기호는 슬래시나 백슬래시가 될 수 있습니다(예: "\\./"는 로컬 디바이스 경로로 간주됨). MapUrlToZone을사용하면 정확한 "\\.\" 또는 "\\?\" 경로만 로컬 디바이스 경로로 간주됩니다. 이는 경로 종류에 대한 혼동으로, CreateFile은 "\\./" 구성요소를 로컬 디바이스 경로로 인식하지만 MapUrlToZone은 인식하지 못하도록 할 수 있습니다. 이러한 혼동으로 인해 두 함수는 경로를 다르게 처리합니다.
이 점을 염두에 두고 "혼란스러운" 구성요소, \\./UNC/Akamai.com/file.wav가포함된 경로를 사용해 보겠습니다.
이 경로의 종류에 대한 의사결정을 분석할 때 MapUrlToZone의흐름은 다음과 같습니다.
경로가 로컬 드라이브입니까, 아니면 루팅된 경로입니까? 아니요
IsLocalDeviceUNC입니까? 아니요
PathisUNCW입니까? 예
PathisUNCW는 참을 반환하므로 함수는 이를 절대 UNC 경로로 표시하고 두 문자를 전진해 UNC 접두사 "\\"를 건너뜁니다. 각 함수의 출력은 표 8에 나와 있습니다.
인풋 경로: \\./UNC/Akamai.com/file.wav |
|
|---|---|
CreateFile |
MapUrlToZone |
UNC\Akamai.com\file.wav |
./UNC/Akamai.com/file.wav |
표 8: CreateFile 및 MapUrlToZone 함수에 대한 경로 출력
여기서 CreateFile은 출력이 UNC 경로이고 Akamai.com이 호스트 이름이라는 결론을 내립니다.
반면, MapUrlToZone은 다음 정보로 결론을 내립니다.
스킴: file://
호스트: . (도트)
경로: /UNC/Akamai.com/file.wav
절대 URI: file://./UNC/Akamai.com/file.wav
절대 URI가 "file://./"로 시작하는 경우(호스트가 "."인 경우) 코드는 공유 이름을 DOS 디바이스 네임스페이스의 일부로 해석합니다(그림 3). 따라서 "file://./UNC/"는 UNC 네임스페이스를 나타냅니다.
그림 3: 도트 호스트 이름이 있는 URL(https://en.wikipedia.org/wiki/File_URI_scheme)
명확히 하기 위해 두 함수 모두 인풋 경로를 UNC 경로로 간주하지만 종류는 다릅니다. CreateFile은 Windows 로컬 디바이스 경로로 취급하는 반면, MapUrlToZone은 URL로 간주합니다.
여기에서 두 함수 간에 혼동이 발생할 수 있습니다. 안타깝게도 아무런 트릭을 수행하지 않으면 MapUrlToZone은 여전히 Akamai.com을 호스트 이름으로 해석하고, 이 호스트 이름은 인터넷 도메인이므로 함수는 3을 반환하므로 우회가 아닙니다. 구문 분석 프로세스를 악용할 수 있는 다른 방법을 찾아야 합니다.
아래에서 MapUrlToZone은 내부 함수 SetPath를 사용해 경로 구성요소에서 작동합니다(표 9).
CreateFile |
SetPath |
|---|---|
RtlPathTypeLocalDevice → 4자 전진인 경우 |
|
후행 공백 건너뛰기 |
|
'/'를 '\'로 변환 |
|
반복되는 '\' 접기 |
|
'.' 및 '...' 구성요소 제거 |
'.' 및 '...' 구성요소 제거 |
표 9: CreateFile 및 SetPath 간에 완료된 작업 비교
다시 한 번 두 함수가 수행하는 작업의 차이를 활용할 수 있습니다. 이전 취약점을 통해 슬래시를 추가하면 우회할 수 있다는 것을 알았으므로 다시 시도해 보는 것이 좋습니다. CreateFile은 단순히 추가 슬래시를 제거합니다.
MapUrlToZone을 사용하면 CreateUri는 절대 URI "file://./UNC//Akamai.com/file.wav"를 반환합니다. 이 URI는 GetZoneFromUriInternal로전달되며 여기서 내부적으로 또 다른 CreateUri호출로 연결됩니다.
이것이 왜 문제일까요? CreateUri는 URL을 받았기 때문에PathCreateFromUrlW를사용해 이를 다시 Windows 경로로 변환합니다. 반환된 Windows 경로는 "\\.\UNC\\Akamai.com\test.wav"입니다. 이제 수정된 버전은 추가 슬래시를 제거하여 Akamai.com이 호스트 이름임을 올바르게 인식합니다.
즉, CreateFile 및 SetPath의차이를 좀 더 복잡하게 악용해야 합니다. 이번에는 두 가지 차이점을 악용하겠습니다.
CreateFile은 반복되는 경로 구분 기호를 축소합니다.
CreateFile은 반복되는 경로 구분자를 축소한 후 '.' 및 '...' 구성요소를 제거합니다.
이 두 가지 차이점을 악용하는 경로는 \\./UNC/C://../Akamai.com/file.wav입니다. 이 경로의 처리 과정은 그림 4의 순서도에 자세히 나와 있습니다.
그림 4: 두 함수에 의해 구문 분석되는 경로의 흐름도
당사는 CreateFile의최종 경로가 UNC 경로로 처리된다는 것을 이미 알고 있습니다. SetPath의출력의 경우 MapUrlToZone은 절대 URI 파일인 //./UNC/C:/Akamai.com/file.wav를 사용해 GetZoneFromUriInternal을 호출합니다. 이번에는 PathCreateFromUrlW가 이 URL을 Windows 경로인 "\\.\UNC\C:\Akamai.com\file.wav"로 변환합니다. 이 경로는 로컬 경로이므로 MapUrlToZone은 0(로컬)을 반환합니다. 다시 한 번 깔끔한 우회 방법을 찾았습니다!
이 문제를 해결하기 위해 이제 코드에서 NormalizeDosDevicePrefix를 호출해 슬래시를 백슬래시로 변환함으로써 로컬 디바이스 경로를 탐지할 때 혼동을 방지할 수 있습니다.
탐지 및 방어
Microsoft는 원래 Outlook 취약점의 탐지 및 방어를 위한 포괄적 가이드를 발표했습니다. 관측 결과, 지정된 모든 방법은 PidLidReminderFileParameter 프로퍼티에 지정된 URL에 의존하지 않기 때문에 새로운 취약점에 적용 가능합니다.
기업에서는 마이크로세그멘테이션을 활용해 원격 퍼블릭 IP 주소로 나가는 SMB 연결을 차단하는 것이 좋습니다. 또한, 사용 중인 환경에서 NTLM을 사용하지 않도록 설정하거나 보호되는 사용자 그룹에사용자를 추가하여 NTLM이 인증 메커니즘으로 사용되지 않도록 하는 것이 좋습니다.
발신 SMB 연결을 차단하고 NTLM을 비활성화하면 인증정보 도용을 방지하는 데 도움이 될 수 있습니다. 그러나 SMB 요청이 실패하면 Windows는 WebDAV가 활성화된 경우 이를 사용합니다. WebDAV를 통해 인증정보 도용을 악용할 수는 없지만 사운드 파일을 다운로드하는 것은 여전히 가능하며, 이는 RCE 체인의 두 번째 단계입니다.
이것만으로 괜찮을까요?
이 게시물에서는 두 가지 우회 경로를 발견하게 된 리서치 과정과 근본 원인 분석에 대해 자세히 설명했습니다. 앞서 살펴본 바와 같이, Windows 경로 구문 분석 코드는 복잡하고 종종 취약점으로 이어질 수 있습니다. 경로 처리 코드를 접하는 보안 연구원들에게 이 코드가 제공하는 공격표면에 대해 생각해 볼 것을 권장합니다.
Outlook의 맥락에서 MapUrlToZone을 우회하는 것 외에도 이러한 취약점이 웹의 MotW( Mark-of-the-Web ) 우회로 이어질 가능성도 배제할 수 없습니다.
NTLM 인증정보를 유출하는 기능 외에도 임의의 사운드 파일을 다운로드해 재생할 수 있는 기능도 있습니다. 이제 이 블로그 시리즈의 2부에서사운드 구문 분석 취약점에 대해 자세히 알아보실 수 있습니다.
