콜드 하드 캐시 - 캐시 악용으로 RPC 인터페이스 보안 우회
핵심 요약
Akamai 연구원들이 Microsoft Windows RPC 서비스에서 각각 기본 점수 4.3과 8.8로 CVE-2022-38034 및 CVE-2022-38045 두 가지 중요한 취약점을 발견했습니다.
이 취약점은 캐싱을 통해 MS-RPC 보안 콜백을 우회할 수 있는 설계 취약점을 이용합니다.
패치되지 않은 Windows 10 및 Windows 11 머신에 취약점이 있는 것을 확인했습니다.
이들 취약점은 Microsoft에 보고되어 10월 패치 화요일(Patch Tuesday)에서 처리됐습니다.
취약점 발견 프로세스는 Akamai 연구자들이 개발한 자동화 툴 및 방법론에 의해 뒷받침됩니다.
이 연구에 사용된 취약점 및 툴에 대한 개념 증명은 RPC 툴킷 리포지토리에서 제공합니다.
서론
MS-RPC는 Windows 운영 체제의 초석 중 하나입니다. 1990년대에 릴리스된 이후 대부분의 시스템에서 사용되고 있습니다. 서비스 관리자? RPC를 사용합니다. LSASS? RPC를 사용합니다. COM? RPC를 사용합니다. 심지어 도메인 컨트롤러에 대한 일부 도메인 작업도 RPC를 사용합니다. MS-RPC가 얼마나 보편화되었는지 안다면 MS-RPC가 면밀하게 검토, 문서화, 연구되었을 것으로 예상할 것입니다.
실제는 그렇지 않습니다. RPC 사용에 관한 Microsoft 설명서는 상당히 훌륭하지만 이 주제에 대해 그렇게 많이 작성된 것은 아니며 RPC를 조사하는 연구자들이 특히 보안에 대해 작성한 문서는 더 적습니다. 이는 RPC가 매우 복잡하여(Microsoft가 분명히 더 복잡하게 만들었지만 MS-RPC만 그런 것은 아님) 연구 및 이해가 어렵다는 사실에 기인할 수도 있습니다.
그러나 우리는 항상 도전하므로 MS-RPC의 심해를 탐구하기로 결정했습니다. 흥미로운 연구 주제일 뿐 아니라 보안에 대한 영향 때문이기도 합니다. 심지어 지금도 일반적인 공격 기법은 RPC를 이용합니다(예를 들면T1021.003 는 MS-COM을 통해 발생하고, T1053.005 는 MS-TSCH을 통해 발생하며 T1543.003 는 MS-SCMR을 통해 발생함). MS-RPC에는 보안 메커니즘이 내장되어 있지만 이를 우회 또는 악용할 수 있는 취약점이 있거나 노출된 RPC 서비스가 남용되어 시스템에 원치 않는 영향을 미칠 수 있는 취약점이 있다면 어떻게 될까요?
사실, 캐싱을 통해 한 보안 메커니즘을 우회할 수 있는 방법을 찾을 수 있었습니다. 이를 통해 많은 필수 조건(나중에 자세히 설명) 없이 원격 서버에 대한 권한을 에스컬레이션하기 위해 악용할 수 있는 몇 가지 서비스를 발견했습니다. 현재, 잠재적인 악용의 두 가지 실제 사례 WksSvc 및 SrvSvc입니다. 발견한 다른 취약점에 대한 업데이트는 공개 프로세스가 완료되는대로 게시할 예정입니다.
이 블로그 게시물에서는 RPC 서버의 보안 콜백 메커니즘, 캐싱으로 이를 우회할 수 있는 방법, Windows 서비스를 잠재적으로 취약한 것으로 플래그를 지정하도록 이 연구를 자동화한 방법을 중점적으로 소개합니다. 또한 자동화 툴 및 해당 원시 아웃풋은 당사의 GitHub 리포지토리에서 공유되는 RPC 툴킷에서 찾을 수 있습니다. 이 리포지토리에는 다른 유용한 참고 자료 및 이 연구에서 참조한 다른 연구자들의 작업에 대한 링크가 포함되어 있습니다.
보안 콜백
취약점 자체에 대해 논의하기 전에 MS-RPC가 구현하는 가장 기본적인 보안 메커니즘 중 하나인 보안 콜백을 이해하는 것이 중요합니다. 보안 콜백을 사용하면 RPC 서버 개발자가 RPC 인터페이스에 대한 접속을 제한할 수 있습니다. 이를 통해 특정 사용자에 대한 접속을 허용하거나, 인증 또는 전송 유형을 적용하거나, 특정 Opnum(서버에서 노출되는 함수는 Opnum(작업 번호)을 사용하여 표시됨)에 대한 접속을 금지하는 자체 논리를 적용할 수 있습니다.
이 콜백은 클라이언트가 서버에서 노출된 함수를 호출할 때마다 RPC 런타임에 의해 발생합니다.
이 연구에서는 원격 클라이언트-서버 상호 작용에 초점을 맞추었습니다. RPC 런타임 서버 측 코드의 구현은 ALPC 엔드포인트와 원격 엔드포인트(예: 명명된 파이프) 간에 다르기 때문에 이 점을 언급하는 것입니다.
캐싱
RPC 런타임은 성능 및 사용률을 높이기 위해 보안 콜백 결과의 캐싱을 구현합니다. 즉, 런타임에서는 매번 보안 콜백을 호출하기 전에 캐싱된 항목을 사용하려고 합니다. 구현에 대해 알아보겠습니다.
RPC_INTERFACE::DoSyncSecurityCallback은 보안 콜백을 호출하기 전에 먼저 캐시 항목이 있는지 확인합니다. 이를 위해 OSF_SCALL::FindOrCreateCacheEntry를 호출합니다.
OSF_SCALL::FindOrCreateCacheEntry는 다음 작업을 수행합니다.
SCALL(클라이언트 호출을 나타내는 오브젝트)에서 클라이언트의 보안 컨텍스트를 가져옵니다.
클라이언트의 보안 컨텍스트에서 캐싱 사전을 가져옵니다.
인터페이스 포인터를 사전의 키로 사용합니다. 이 값은 캐시 항목입니다.
캐시 항목이 없으면 새로 생성합니다.
캐시 항목에는 인터페이스의 프로시저 수, 비트맵, 인터페이스 생성 등 세 가지 중요한 필드가 있습니다.
RPC 서버의 수명 동안 인터페이스가 변경될 수 있습니다. 예를 들어, 서버가 기존 인터페이스에서 RpcServerRegisterIf3을 호출하는 경우입니다. 그러면 RPC_INTERFACE::UpdateRpcInterfaceInformation이 호출되어 인터페이스가 업데이트되고 인터페이스 생성이 증가합니다. 이러한 방식으로 캐싱은 캐시 항목이 이전 인터페이스에서 온 것일 수 있으므로 '재설정'해야 한다는 것을 알 수 있습니다.
캐싱 메커니즘은 인터페이스 기반(기본 동작) 및 호출 기반의 두 가지 모드로 작동할 수 있습니다.
인터페이스 기반 캐싱
이 모드에서는 캐싱이 인터페이스 기반으로 작동합니다. 즉, 캐싱의 관점에서는 두 개의 함수에 대한 두 호출은 동일한 인터페이스에 있는 한 차이가 없습니다.
보안 콜백을 호출하는 대신 캐시 항목을 사용할 수 있는지 여부를 알기 위해 RPC 런타임은 캐시 항목에 저장된 인터페이스 생성을 실제 인터페이스 생성과 비교합니다. 캐시 항목 초기화는 인터페이스 생성을 0으로 설정하기 때문에 처음 비교가 수행되면 인터페이스 세대가 달라지므로 보안 콜백이 호출됩니다. 콜백이 성공적으로 반환되면 RPC 런타임은 캐시 항목의 인터페이스 생성을 업데이트합니다. 따라서 보안 콜백을 다시 호출하지 않고 인터페이스에 접속할 수 있는 성공적인 캐시 항목으로 '표시'됩니다. 다음에 클라이언트가 동일한 인터페이스에서 함수를 호출할 때 이 캐시 항목이 사용됩니다.
호출 기반 캐싱
이 모드는 RPC 인터페이스가 RPC_IF_SEC_CACHE_PER_PROC 플래그로 등록된 경우에 사용합니다. 이 모드에서 캐싱은 보안 콜백이 접속을 허용한 프로시저를 추적하는 비트맵을 기반으로 합니다. 따라서 클라이언트가 Foo 함수를 호출하고 보안 콜백이 성공적으로 반환된 경우 Foo에 대한 캐시 항목이 있습니다. 클라이언트가 Bar를 호출하는 경우 보안 콜백이 다시 호출됩니다.
캐싱 요구 사항
그렇다면 캐싱이 작동하려면 무엇이 필요할까요? 먼저 몇 가지 용어를 명확히 해야 합니다. MS-RPC는 바인딩 핸들을 사용하여 클라이언트와 서버 간의 논리적 연결을 나타냅니다. 클라이언트와 서버는 지정된 함수를 사용하여 바인딩 데이터를 조작할 수 있습니다.
바인딩은 인증할 수 있습니다. 인증은 서버가 RpcServerRegisterAuthInfo를 호출하여 인증 정보를 등록한 다음 클라이언트가 바인딩에 대한 인증 정보를 설정할 때 이루어집니다. 이렇게 하면 서버가 클라이언트의 ID에 대한 정보를 가져올 수 있습니다. 이 인증 프로세스의 아웃풋은 클라이언트에 대해 생성된 보안 컨텍스트 오브젝트입니다.
전체 캐싱 메커니즘은 이 보안 컨텍스트를 기반으로 합니다. 즉, 바인딩이 인증되지 않으면 클라이언트에 대한 보안 컨텍스트가 생성되지 않으며, 따라서 캐싱이 사용되지 않습니다. 캐싱이 작동하려면 서버와 클라이언트 모두 인증 정보를 등록하고 설정해야 합니다.
하지만 서버가 인증 정보를 등록하지 않은 경우에는 어떻게 될까요? 캐싱을 계속 사용할 수 있을까요? 소개: 멀티플렉싱.
멀티플렉싱
Windows 10, 1703 버전까지는 서비스가 다른 서비스와 동일한 svchost 프로세스를 공유할 수 있었습니다. RPC 런타임 오브젝트 중 일부가 모든 인터페이스 간에 공유되므로 이 동작은 MS-RPC 보안에 영향을 미칩니다. 예를 들어, 엔드포인트(예: TCP 포트 7777)를 등록할 때 이 엔드포인트를 사용하여 동일한 프로세스에서 실행 중인 모든 인터페이스에 접속할 수 있습니다. 따라서 로컬로 접속해야 하는 다른 서비스도 이제 원격으로 접속할 수 있습니다. 이 내용은 Microsoft에서 작성한 이 페이지에도 설명되어 있습니다.
엔드포인트가 멀티플렉싱된다는 사실은 이미 어느 정도 알려져 있고 문서화되어 있지만 여기서는 또 다른 유사한 동작인 SSPI 멀티플렉싱을 제시하고자 합니다. 인증 정보 등록의 일환으로 서버는 사용할 인증 서비스를 지정해야 합니다. 인증 서비스는 클라이언트로부터 받은 인증 정보를 처리하는 패키지인 보안 지원 공급자 (SSP)입니다. 대부분의 경우 NTLM SSP, Kerberos SSP 또는 Microsoft Negotiate SSP이고 Kerberos와 NTLM 중에서 가장 적합한 옵션을 선택합니다.
RPC 런타임은 인증 정보를 전역적으로 저장합니다. 즉, 두 개의 RPC 서버가 동일한 프로세스를 공유하고 이 중 하나가 인증 정보를 등록하면 다른 서버도 인증 정보가 있습니다. 이제 클라이언트는 각 서버에 접속할 때 바인딩을 인증할 수 있습니다. 보안 관점에서, 인증 정보를 등록하지 않았기 때문에 클라이언트가 바인딩을 인증하거나 캐싱이 발생할 것으로 예상하지 않은 서버에 강제로 인증 또는 캐싱이 적용될 수 있습니다.
CVE-2022-38045 — srvsvc
RPC 보안 콜백 및 캐싱에 대한 새로운 지식을 바탕으로 실제로 메커니즘을 악용할 수 있는지 알아보았습니다. 그래서 과거에 이미 Off-by-One 취약점이 발견된 srvsvc를 다시 조사했습니다.
Srvsvc는 MS-SRVS 인터페이스를 노출합니다. LanmanServer라고도 불리는 Server 서비스는 SMB 공유를 관리하는 Windows 서비스입니다. 공유는 파일, 프린터, 디렉터리 트리 같은 리소스며 Common Internet File System(CIFS) 서버를 통해 네트워크에서 접속할 수 있습니다. 사용자는 네트워크 공유를 통해 네트워크상의 다른 디바이스를 사용하고 다양한 일상 업무를 수행할 수 있습니다.
Srvsvc의 보안 콜백을 살펴보니 함수에 이미 발견된 것과 다른 취약점이 있을 수 있다는 것을 알게 되었습니다. 보안 콜백 논리를 살펴보겠습니다.
위에서 볼 수 있듯이 SRVSVC의 보안 콜백 논리는 다음과 같습니다.
원격 클라이언트가 64~73(포함) 범위의 함수에 접속하려는 경우 - 접속 거부
클러스터 계정이 아닌 원격 클라이언트가 58~63(포함) 범위의 함수에 접속하려는 경우 — 접속 거부
따라서 원격 클라이언트는 인터페이스의 이들 특정 기능에 접속할 수 없습니다. 이러한 범위 검사는 제한된 기능이 민감하고 예상된(로컬) 프로세스만 호출해야 한다는 힌트를 줍니다.
이 검사는 이러한 함수에 대한 원격 접속을 방지하지만 원격 공격자는 캐싱을 악용하여 이 검사를 우회할 수 있습니다. 첫째, 원격 공격자가 이 범위에 있지 않은 함수, 즉 원격으로 사용할 수 있는 함수를 호출합니다. 보안 콜백 함수가 RPC_S_OK를 반환하므로 RPC 런타임은 결과를 성공적으로 캐싱합니다. 인터페이스가 RPC_IF_SEC_CACHE_PER_PROC 플래그로 등록되지 않았기 때문에 캐싱은 인터페이스 기반으로 합니다. 따라서 다음 번에 공격자가 동일한 인터페이스에서 어떤 함수를 호출하더라도 캐시 항목이 사용되고 접속 권한이 부여됩니다. 즉, 이제 공격자가 접속 권한이 없는 로컬 함수를 호출할 수 있으며 보안 콜백이 전혀 호출되지 않습니다.
Srvsvc는 인증 정보를 등록하지 않습니다. 따라서 정상적인 상황에서는 클라이언트가 바인딩을 인증할 수 없으므로 캐싱이 사용되지 않습니다. Srvsvc는 서버 시스템의 RAM 용량이 3.5GB 미만인 경우 동일한 svchost 프로세스를 다른 서비스와 공유합니다. "AD Harvest Sites and Subnets Service” 및 “Remote Desktop Configuration Service" 서비스는 인증 정보를 등록하므로 srvsvc는 이제 캐시 공격에 취약합니다.
이 특정 시나리오에서 공격자는 Opnum 58~74의 제한된 함수에 접속할 수 있습니다. 이러한 함수로 공격자가 수행할 수 있는 작업 중 하나는 원격 컴퓨터를 강제하는 것입니다.
보물찾기
보안 콜백의 캐싱 메커니즘을 악용하면 실제 취약점이 발생할 수 있다는 사실을 파악한 후 캐싱 공격에 취약할 수 있는 다른 인터페이스를 찾기로 결정했습니다. 그러나 모든 인터페이스를 수동으로 찾는 것은 길고 힘든 작업이므로 이를 자동화하는 방법을 찾고 싶었습니다.
RPC 인터페이스를 찾을 때 현재 실행 중인 프로세스를 통하는 방법과 파일 시스템을 통하는 방법 두 가지를 사용할 수 있습니다.
실행 중인 프로세스를 사용하는 경우 원격 엔드포인트 매퍼를 쿼리하여 원격 서버에서(예를 들어 Impacket의 rpcmap 혹은 rpcdump를 사용) 또는 로컬로(RpcView 또는 RpcEnum같은 툴을 사용) 메모리에 이미 로딩된 RPC 서버를 볼 수 있습니다. 하지만 이 접근 방식에는 문제가 하나 있습니다. 현재 로딩되지 않은 인터페이스는 모두 누락되고, 등록되지 않았기 때문에 클라이언트 인터페이스를 볼 수 없게 됩니다.
또는 Windows 파일 시스템을 스크레이핑하고 그 안에서 컴파일된 RPC 인터페이스를 찾을 수도 있습니다. 각 인터페이스에 대해 RpcServerRegisterIf에 전달된 인수를 분석하여 해당 등록 정보를 구문 분석합니다. 이 방법은 RpcEnum에서 수행되는 것과 비슷하지만 메모리 대신 파일 시스템을 스크래핑합니다.
이번 연구에서는 반드시 메모리에 로딩되지는 않은 인터페이스를 포함하기 위해 파일 시스템 방법을 선택했습니다. 프로세스를 자동화하기 위해 다양한 스크립트 및 툴을 작성했습니다(당사의 RPC 툴킷 리포지토리에서 사용 가능).
캐싱을 사용하는 인터페이스를 찾기 위해 RPC 인터페이스 자체를 구문 분석할 필요가 없습니다. 필요한 모든 정보를 RPC 서버 등록 호출에서 추출할 수 있습니다. 등록 함수는 RPC 인터페이스 구조, 등록 플래그 및 보안 콜백 포인터를 허용합니다. 그러나 RPC 인터페이스 구조를 구문 분석하면 인터페이스에서 노출하는 함수, RPC 서버 또는 클라이언트에서 사용되는지 여부와 같은 유용한 정보를 얻을 수 있습니다. 대부분의 경우 취약점이 존재할 수 있는 RPC 서버에 관심이 있지만 RPC 클라이언트는 서버 호출에 대한 유용한 정보를 제공하며 이 정보를 악용에 참조할 수 있습니다.
RPC 서버 인터페이스 구조는 문서화되어 있으므로 해당 필드를 추측할 필요가 없습니다. 또한, 크기 필드와 전송 구문은 상수입니다. (실제로 두 가지 가능한 전송 구문(DCE NDR 및 NDR64)이 있지만 DCE NDR에서 우연히 발견한 적이 있을 뿐입니다.)
Yara 또는 정규식을 사용해 두 상수를 검색하여 모든 RPC 인터페이스 구조를 찾는 것은 매우 간단한 일입니다. 찾은 후에는 인터프리터 정보 필드 를 사용하여 서버에서 구현하는 기능을 확인할 수 있습니다.
그러나 인터페이스의 보안 콜백(있는 경우)과 캐싱 여부에 대한 정보는 아직 없습니다. 이를 위해 믿을 수 있는 친구인 디스어셈블러에 의지해야 합니다. 모든 디스어셈블러에는 Xref 기능이 있으므로 RPC 서버에서 모든 인터페이스 등록 함수 호출을 찾는 것은 매우 쉬운 일입니다. 이를 바탕으로 함수 호출 인수를 구문 분석하여 인터페이스 구조 주소(스크랩된 RPC 서버 데이터와 상호 참조할 수 있음), 보안 콜백 주소(있는 경우), RPC 인터페이스 플래그를 추출하면 됩니다.
정확히 이 프로세스를 수행하는 스크래핑 스크립트가 당사의 RPC 툴킷에 게시되어 있으며 Windows Server 2012 및 Server 2022에서의 아웃풋 도 함께 제공됩니다.
CVE 또는 발생하지 않음
이러한 방법론 및 이론은 훌륭한데, 실제로 결과를 산출합니까?
그 대답은 예입니다. 보안 콜백과 캐싱을 모두 갖춘 인터페이스는 120개 이상이며, 이 중 많은 수가 문서화되지 않았습니다. 이 자체로는 당황할 이유가 없습니다. 대부분의 경우 보안 콜백이 캐싱에 의해 큰 영향을 받지 않기 때문입니다. 일반적으로 보안 콜백에 의한 검사는 전송 프로토콜 시퀀스(예: TCP) 또는 인증 수준과 같이 캐싱할 수 없는 값에 대해 수행됩니다. 변경 사항이 있을 경우 새 연결을 설정해야 하고 이는 캐시를 재설정하고 가능한 캐싱 우회를 무효화하기 때문에 어쨌든 새로운 보안 컨텍스트가 필요합니다.
이 조사 접근 방식을 통해 몇 가지 취약점을 발견했습니다. 나머지 부분은 아직 공개 프로세스 도중에 있기 때문에 지금은 그 중 하나만 논의할 수 있습니다.
WksSvc
CVE-2022-38034 CVSS 점수: 4.3
WksSvc는 MS-WKST 인터페이스를 노출합니다. 이 서비스는 도메인 멤버 자격, 컴퓨터 이름, SMB 네트워크 리디렉터(예: SMB 프린터 서버)에 대한 연결을 관리합니다. 인터페이스의 보안 콜백을 살펴보면 일부 함수가 나머지와는 다르게 처리되는 것을 알 수 있습니다.
Opnum이 8~11인 함수는 로컬 클라이언트에 의해 호출되도록 검사되므로 원격으로 호출할 수 없습니다. 하지만 캐싱을 사용하고 있으므로 원격 호출이 허용되는 다른 함수를 먼저 호출한 다음 제한된 함수 중 하나를 호출하면 어떻게 될까요?
짐작한 그대로입니다. 첫 번째 호출 결과의 캐싱 때문에 로컬에서 제한된 함수를 원격으로 호출할 수 있습니다. 이제 질문은 다음과 같습니다. 이러한 함수가 로컬 클라이언트에만 제한적으로 사용된다는 것을 보증할 만큼 중요합니까?
노출된 함수는 NetrUseAdd, NetrUseGetInfo, NetrUseDel및 NetrUseEnum입니다. 이들 함수가 친숙해 보인다면 netapi32.dll을 통해 접속할 수 있기 때문입니다(예를 들어 NetUseAdd참조).
이것은 좋습니다. 이 공격으로 무엇을 할 수 있는지에 대한 단서를 제공하기 때문입니다. 즉, 네트워크 사용과 마찬가지로 원격 서버를 선택한 네트워크 공유 폴더에 연결할 수 있으며, 심지어 선택한 논리 드라이브 문자에 매핑할 수도 있습니다. (우연의 일치일까요? 아닐 것입니다.)
이는 두 가지 공격 시나리오를 제공합니다.
1. 공유 폴더에 대한 인증을 요구할 수 있습니다. 그런 다음 NTLM 릴레이 공격을 위해 다른 서버로 릴레이하거나 토큰을 저장하고 오프라인에서 암호를 해독할 수 있습니다.
2. 또는 기존 파일 서버를 흥미롭거나 유용한 파일로 가장하거나 새 파일 서버로 할 수도 있습니다. 이러한 파일은 우리가 제어하는 것이기 때문에 원하는 방식으로 무기화하여 아마도 표적 사용자를 감염시킬 수도 있을 것입니다.
이 두 가지 시나리오는 로컬로 제한된 함수를 원격으로 호출할 수 있기 때문에 Microsoft가 이 취약점을 4.3점의 EoP로 분류하기에 충분했습니다.
하지만, 이것이 이야기의 끝이 아닙니다. 아직 극복해야 할 몇 가지 주의 사항이 있습니다.
보안 컨텍스트
WksSvc의 RPC 서버는 자체적으로 인증 등록을 수행하지 않습니다. 서비스가 자체적으로 실행되는 경우 클라이언트 측 인증이 불가능합니다(오류 RPC_S_UNKNOWN_AUTHN_SERVICE가 발생). 따라서 SSPI 멀티플렉싱도 악용하기 위해 이 서비스를 다른 서비스와 함께 실행해야 합니다. 이 때문에 영향을 받는 Windows 버전이 RAM 용량이 3.5GB 미만인 Windows 10, 버전 1703이상으로 제한됩니다.
로그온 세션
네트워크 매핑된 폴더가 작동하는 방식에 내재된 또 다른 문제는 이들이 해당 폴더를 생성하는 사용자의 로그온 세션 으로 제한된다는 것입니다. 보안 바인딩 및 캐싱을 사용하려면 먼저 로그온해야 하므로 항상 대상 컴퓨터의 기존(대화형) 세션과 다른 로그온 세션을 만들어야 합니다. 모든 의도와 목적에서 이 취약점은 아무런 영향을 미치지 않음을 의미합니다. 생성하는 네트워크 매핑은 일반 사용자가 시스템에 로그인할 때 생성하는 세션이 아니라 단기간 로그온 세션에 있기 때문에 표시되지 않습니다.
이를 극복하기 위해 NetrUseAdd의 코드를 좀 더 깊이 파고들어야 했습니다. 결과적으로 모든 사용자에게 영향을 미치는 전역 네임스페이스에 매핑을 생성하도록 지시하는 NetrUseAdd 를 전달할 수 있는 플래그가 있습니다. 이러한 플래그는 사용 가능한 헤더 파일 LMUse.h에서도 찾을 수 있습니다.
이러한 플래그로 무장한 우리의 코드는 이제 글로벌 매핑을 성공적으로 생성하여 대화형 세션에 영향을 미치며 악용 시도를 마무리합니다.
요약
MS-RPC는 복잡한 대형 프로토콜입니다. 또한 Windows의 핵심 기능 중 일부를 제공합니다. 개발자가 RPC 서버의 보안을 유지하는 데 사용할 수 있는 보안 기능이 있지만 보안에 영향을 줄 수 있는 취약점이 포함되어 있기 때문에 보안 연구자들에게 흥미로운 주제입니다.
그럼에도 불구하고 이 주제에 대한 공공 연구가 그다지 많이 수행된 것은 아닙니다. 이 블로그 게시물에서는 MS-RPC의 대규모 보안 메커니즘인 보안 콜백을 파헤쳐 콜백 결과 캐싱의 형태로 우회하는 방법을 발견했습니다. 또한 취약한 RPC 서버를 찾기 위한 조사 방법에 대해 자세히 설명하고 취약점 기록과 함께 발견한 내용 중 일부를 제시했습니다.
이 게시물 및 동반된 RPC 툴킷 리포지토리가 RPC 서버 및 보안 메커니즘을 조사하는 데 도움이 되기를 바랍니다.