MS-RPC와 그 보안 메커니즘에 관한 개요

서버와 클라이언트가 네트워크(또는 로컬) 관점에서 어떻게 통신하는지 궁금할 수 있습니다. 서버는 프로토콜 시퀀스와 엔드포인트의 조합을 등록해 들어오는 RPC 연결을 수신 대기합니다. 프로토콜 시퀀스의 예를 들면 다음과 같습니다. ncacn_ip_tcp (TCP), ncacn_np (명명된 파이프) 또는 ncalrpc (LPC). 명명된 파이프를 사용하는 경우, 엔드포인트는 TCP 5555 또는 \\pipe\\example과 같은 포트가 될 수 있습니다. 명명된 파이프는 숨겨진 IPC$ share를 사용해 TCP 포트 445를 통한 SMB 전송으로 전달됩니다. 프로토콜 시퀀스의 전체 목록은 Microsoft 웹사이트에 있습니다.

따라서 서버는 일부 엔드포인트에서 연결을 수신 대기합니다. 클라이언트는 어디에 연결해야 하는지 어떻게 알 수 있습니까? 이 질문에 대한 응답은 엔드포인트의 종류(동적 엔드포인트 또는 잘 알려진(정적) 엔드포인트)에 따라 다릅니다.

동적 엔드포인트는 서버 측의 엔드포인트 매퍼를 통해 등록된 엔드포인트입니다. 엔드포인트 매퍼(일명 'epmapper')는 서비스를 실제 엔드포인트에 매핑하는 RPC 서비스입니다. epmapper는 HTTP를 통한 RPC에 TCP 포트 135와 593을 사용합니다. 따라서 클라이언트는 epmapper를 사용해 원격 시스템에서 동적으로 등록된 모든 RPC 서버를 ( 지정된 API를 사용해) 열거할 수 있습니다.

잘 알려진(정적) 엔드포인트는 epmapper를 통해 등록되지 않은 엔드포인트입니다. 클라이언트는 서버가 미리 등록한 엔드포인트를 알고 있어야 합니다. 이 작업은 엔드포인트가 클라이언트와 서버의 코드에서 하드코딩되어 있거나 엔드포인트가 IDL 파일에 있는 경우에 수행할 수 있습니다. 인쇄 스풀러 서비스 IDL의 예를 들면 다음과 같습니다.

[

uuid(12345678-1234-ABCD-EF00-0123456789AB),

version(1.0),

ms_union,

endpoint("ncacn_np:[\\pipe\\spoolss]"),

pointer_default(unique)

]

RPC는 바인딩 핸들을 통해 클라이언트와 서버 간의 논리적 연결을 나타냅니다. 서버와 클라이언트 모두 인증 정보를 설정할 때와 같이 바인딩 데이터를 조작하는 함수를 사용합니다. 클라이언트가 바인딩에 인증을 설정하면 바인딩이 인증된 것으로 간주됩니다. 클라이언트 프로그램에서 RPC 함수를 호출하면 네트워크 바인딩이 진행됩니다. 네트워크 트래픽 측면에서 RPC 클라이언트는 패킷에 인증 정보가 포함된 바인드 요청을 전송해 RPC 상호 작용을 시작합니다. 서버는 bind_ack(확인됨) 또는 bind_nak(오류 발생)로 응답할 수 있습니다.

그림 2의 Wireshark 스니펫에서는 작업 스케줄러 인터페이스의 동적 엔드포인트 분해능을 볼 수 있습니다. 클라이언트가 작업 스케줄러에 대한 엔드포인트 정보를 갖고 있으면 새 연결이 생성됩니다. 그런 다음, 바인딩 인증의 일부로 AUTH3 패킷을 포함해 다른 바인딩 프로세스와의 새 연결을 볼 수 있습니다.

엔드포인트와 마찬가지로 바인딩은 세 가지 종류 즉, 자동 바인딩, 암시적 바인딩, 명시적 바인딩으로 구분됩니다(그림 3). 이 세 가지 바인딩은 바인딩 프로세스에 대한 애플리케이션의 제어량에서 차이가 있습니다. 

• 자동 바인딩(폐기) – 클라이언트와 서버 애플리케이션에서 바인딩 프로세스를 처리하지 않고 그 대신 RPC 런타임에서 이 프로세스를 완전히 제어하도록 합니다.
  
• 암시적 바인딩 – 바인딩이 발생하기 전에 클라이언트에서 바인딩 핸들을 설정할 수 있습니다. 클라이언트에서 바인딩을 설정하면 RPC 런타임 라이브러리가 나머지 부분을 처리합니다.
  
• 명시적 바인딩 –  클라이언트가 바인딩 핸들을 설정해야 합니다. 그런 다음 RPC 런타임은 이 값을 서버로 전달합니다.

이제 RPC의 작동 방식에 대한 기본 사항을 알았으므로 클라이언트가 하나의 함수에 접근하는 것을 차단할 수 있는 동작, 정책, 메커니즘에 대해 알아보고자 합니다. 이는 공격적인 관점과 방어적인 관점에서 모두 흥미롭습니다.

전송 인증

명명된 파이프 또는 HTTP와 같은 일부 전송에는 프로토콜의 일부에 속하는 인증이 있습니다. 예를 들어, 명명된 파이프는 인증이 있는 SMB를 통해 전달됩니다. 이는 기본적으로 서버가 명명된 파이프 엔드포인트를 등록할 때 유효한 사용자의 인증정보를 가진 클라이언트만 해당 엔드포인트에 연결할 수 있음을 의미합니다. 도메인 환경에서는 동일한 도메인에 도메인 사용자가 있으면 인증 검사를 충분히 통과할 수 있습니다. 시스템이 도메인에 속하지 않은 경우, 클라이언트는 원격 서버에 있는 로컬 사용자의 인증정보를 가지고 있어야 합니다(그림 4). 예외 사항은 이 게시물의 뒷부분에서 다루기로 하겠습니다.

인터페이스 플래그 사용

인터페이스를 보호하는 세 번째 방법은 RpcServerRegisterIf* 함수를 통해 인터페이스를 만들 때 설정되는 인터페이스 플래그를 사용하는 것입니다. 보안 측면에서 흥미로운 플래그를 열거하면 다음과 같습니다.

RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH – 사용된 전송 방법이나 인증 수준에 관계없이 각 호출에 대해 보안 콜백이 호출됩니다. 

RPC_IF_ALLOW_LOCAL_ONLY – 로컬 요청만 허용됩니다.

RPC_IF_ALLOW_SECURE_ONLY – 연결은 권한 수준이 RPC_C_AUTHN_LEVEL_NONE보다 높은 클라이언트에만 허용됩니다. 이 플래그를 지정하면 NULL 세션을 통과하는 클라이언트가 거부됩니다. 이 플래그는 호출하는 사용자의 권한 수준을 보장하지 않으며 클라이언트에 유효한 인증정보가 있다는 것만 보장합니다.

RPC_IF_SEC_NO_CACHE – 이 플래그는 인터페이스의 보안 콜백에 대한 캐싱을 완전히 비활성화합니다.

RPC_IF_SEC_CACHE_PER_PROC – 이 플래그는 전체 캐싱 메커니즘을 비활성화하는 대신, 기본 동작을 인터페이스 기반이 아닌 호출 기반으로 변경합니다.

서버 프로그래머는 인터페이스에 노출되는 함수의 일부로 보안 검사를 구현할 수 있으므로 호출되는 함수에 따라 해당 검사의 논리를 변경하거나 사용자 지정할 수 있습니다. 일반적인 보안 검사는 그림 6에 표시된 것과 같은 접속 검사입니다(srvsvc에서 가져옴).