피해 측면에서 볼 때, 공격자는 일반 사용자 인증을 사용하여 관리자 권한으로 원격에서 임의 코드를 실행할 수 있습니다. 취약점 악용 난이도 측면에서 이 취약점은 매우 쉽게 악용될 수 있으므로 위험성이 큽니다.

취약점 특성 측면에서 34527 취약점은 CVE-2021-1675 취약점을 기반으로 합니다. 1675 취약점은 로컬 권한 상승 및 원격 코드 실행 취약점으로, 34527 취약점과 매우 유사한 부분이 있습니다.

취약점의 작동 원리를 이해하기 전에 Windows 인쇄 스풀러 아키텍처를 대략적으로 이해해야 하며, 이를 통해 취약점 관련 각 모듈 간의 관계를 명확히 할 수 있습니다.

== CVE-2021-1675 호출 흐름

=== Windows 인쇄 스풀러 아키텍처

스풀러 아키텍처는 <<spooler_arch>>로 나타낼 수 있습니다:

[[spooler_arch]] .Print Spooler 아키텍처 image::Print Spooler Architecture.png[]

구체적으로 스풀러는 인쇄 작업을 관리하며, 다음 구성 요소로 이루어져 있습니다:

winspool.drv:: 사용자에게 제공되는 동적 링크 라이브러리 파일입니다. 이 파일은 스풀러 관련 Win32 API를 정의하여 사용자가 호출할 수 있도록 합니다. 내부의 API는 모두 원격 프로시저 호출 형태로 서비스를 제공합니다.

spoolsv.exe:: spoolsv.exe는 시스템에서 서버 역할을 하며, API 호출을 최초로 처리하는 프로그램입니다. 이러한 설계는 인쇄 스풀러가 로컬 인쇄 작업뿐만 아니라 원격 인쇄 작업도 차이 없이 처리할 수 있도록 하기 위함입니다.

spoolsv.dll:: 라우팅 프로그램입니다. spoolsv.exe가 수신한 인쇄 요청을 각 인쇄 공급자에게 전달하고, 최종적으로 어떤 인쇄 공급자가 요청을 처리할지 결정합니다. 그 역할은 인쇄 작업이 원격 작업인지 로컬 작업인지 구분하는 것입니다. 원격 머신에서는 작업을 로컬 인쇄 공급자에게 고정적으로 할당합니다.

localspl.dll:: 로컬 인쇄 공급자입니다. 인쇄 공급자의 주요 작업은 인쇄 작업 관리 요구를 해결하는 것이며, 대부분의 API는 이 모듈 내에서 구현됩니다.

위 이론에 따라 계속 연구하면, 예를 들어 AddPrinterDriverEx 함수(CVE-2021-1675)를 호출할 때 다음 흐름을 거칩니다:

=== 함수 버전 선택

먼저 이 함수는 실제로 매크로로, 로컬 컴파일 환경에 따라 유니코드 버전(W) 또는 Ansi 버전(A)을 선택합니다(<> 참조):

[[AddPrinterDriverEx]] .AddPrinterDriverEx image::AddPrinterDriverEx.png[]

하지만 와이드 문자 버전이든 좁은 문자 버전이든 결과는 동일합니다. Windows 커널 문자열은 유니코드 인코딩을 사용하기 때문에, Ansi 버전의 호출은 결국 유니코드 버전으로 변환됩니다(<> 참조):

[[AnsiToUnicode]] .AnsiToUnicode image::AnsiToUnicode.png[]

Ansi 함수의 매개변수가 유니코드 버전으로 변환되면 함수가 호출됩니다(<>):

[[AnsiCallUnicode]] .AnsiCallUnicode image::AnsiCallUnicode.png[]

이 함수는 실제로 유니코드 버전의 AddPrinterDriverEx입니다(<>):

[[GetUnicodeProcAddress]] .GetUnicodeProcAddress image::GetUnicodeProcAddress.png[]

=== API 함수가 RPC 요청을 스풀러 서버로 전송

유니코드 버전의 함수 내부에 들어가면 먼저 Level 값에 따라 함수 매개변수 유형을 선택합니다:

image::pDriverInfo.png[]

이 취약점에서는 Level을 2로 설정하여 pDriverInfo 매개변수의 유형을 DRIVER_INFO_2 구조체로 선택합니다. 그런 다음 Windows는 함수 매개변수를 처리하고, 처리가 완료되면 원격 프로시저 호출을 통해 API를 계속 처리합니다:

image::set arguments.png[]

image::NdrClientCall3.png[]

=== MSRPC 메커니즘

Microsoft의 원격 프로시저 호출 메커니즘은 DCE 표준을 기반으로 구축되었습니다. 쉽게 설명하면, 원격 프로시저 호출은 원격 시스템에서 프로세스를 실행하는 것이며, 이러한 프로세스는 프로그래머 또는 시스템에 의해 미리 정의됩니다.

RPC의 구체적인 방법은 원격으로 호출하려는 함수를 직렬화하여 네트워크를 통해 원격 시스템으로 전송하고, 원격 시스템에서 이를 역직렬화하여 실행하는 것입니다. Microsoft가 구축한 시스템에서 TCP/IP와 SMB는 일반적으로 RPC 호출을 전송하는 데 선택되는 프로토콜입니다.

MSRPC를 사용하려면 먼저 호출할 함수의 IDL 인터페이스 설명을 정의하고, MIDL 도구를 사용하여 클라이언트와 서버에 해당하는 직렬화 프로그램 스텁을 생성해야 합니다. 일부 Win32 API의 경우 서버 스텁이 이미 정의되어 있으므로 클라이언트 스텁만 생성하여 사용하면 됩니다.

MSRPC는 UUID를 사용하여 특정 유형의 프로토콜을 식별합니다. 예를 들어 MS-RPRN은 원격 인쇄 프로토콜을 설명하는 데 사용되며, 원격 인쇄와 관련된 모든 함수는 이 프로토콜의 일부입니다. MSPRC는 UUID 12345678-1234-ABCD-EF00-0123456789AB를 사용하여 이 프로토콜을 식별합니다(<<rprn_uuid>>):

[[rprn_uuid]] .MS-RPRN UUID image::spoolss uuid.png[]

그런 다음 이 연결을 기반으로 연산자 번호를 사용하여 프로토콜 내 함수를 식별하여 원격으로 호출할 수 있습니다. 예를 들어 AddPrinterDriverEx는 89를 사용하여 자신을 식별합니다(<<addPrinterDriverEx_opnum>>):

[[addPrinterDriverEx_opnum]] .AddPrinterDriverEx Opnum image::AddPrinterDriverEx Opnum.png[]

MSRPC 사용 과정에서 두 가지 사항에 주의해야 합니다:

[IMPORTANT]

• TCP/IP 연결은 동적 포트를 사용하며, 135번 포트에서 수신 대기하는 엔드포인트 매퍼를 통해 포트 값을 가져와야 합니다.

"As you can see in your output, the scripts are trying to connect to port 135 (endpoint mapper) in order to get the TCP/IP port where the DCOM endpoint is listening (that is a dynamic port)." -- SecureAuthCorp/impacket issue #412

• 또한 일부 RPC 함수는 호출 시 인증이 필요하므로, 이 취약점은 일반 사용자 권한이 필요합니다. ====

=== spoolsv.exe가 API 요청 처리

[[call_flow]] .RpcAddPrinterDriverEx 호출 흐름 image::Function Calls.png[]

<<call_flow>>에서 볼 수 있듯이, spoolsv.exe는 이러한 함수들을 호출하며, 함수 내부 분석 결과 이 모듈은 초기화 외에는 완료하는 작업이 없습니다. 마지막으로, 이 모듈은 pLocalProvidor가 가리키는 함수, 즉 localspl.dll 모듈 내의 LocalAddPrinterDriverEx 함수를 호출합니다. localspl은 로컬 인쇄 공급자로서 실제로 API 기능을 구현하는 모듈입니다.

=== 로컬 인쇄 공급자의 함수 구현 로직

[[LocalAddPrinterDriverEx]] .LocalAddPrinterDriverEx image::LocalAddPrinterDriverEx.png[]

먼저 <>는 이 모듈이 스풀러가 정상 작동하는지 확인한 후 함수 SplAddPrinterDriverEx로 이동함을 보여줍니다.

[[SplAddPrinterDriverEx]] .SplAddPrinterDriverEx image::SplAddPrinterDriverEx.png[]

<> 함수 내부는 AddPrinterDriverEx 함수가 성공적으로 실행될 수 있는지 판단하는 중요한 위치입니다. 전반부는 볼 필요가 없습니다. WPP는 로그 관련 기술이므로 일단 건너뜁니다.

후반부에서 Microsoft는 변수 v12를 정의했으며, 이는 함수가 계속 실행될지 아니면 직접 종료될지를 판단하는 플래그입니다.

[[bittest]] .bittest dwFileCopyFlags image::bittest in spl.png[]

<>에서 볼 수 있듯이, 계속 실행 조건은 두 가지입니다: 하나는 v12가 0인 경우(bittest 성공), 다른 하나는 Validate 성공입니다. Validate는 권한 검증으로, 쉽게 우회할 수 없습니다. 내부에 OpenProcessToken API가 있어 다음 프로세스에서 권한을 상승시켜야 하며, 관리자 계정이 아니면 이를 수행할 수 없습니다.

따라서 계속 실행하려면 bittest 판단을 우회해야 하며, 판단 대상인 a4는 함수의 네 번째 매개변수로, 공식 문서에 설명된 매개변수 <>입니다: