優れた RPC インターフェースとその検索方法

簡単に言うと、セキュリティコールバックは、RPC インターフェースを保護する方法の 1 つです。RPC サーバー開発者が実装するカスタムコールバックです。ロジックは開発者が決定します。開発者は、ユーザーベースのアクセス制御、認証、トランスポートタイプを適用したり、サーバーで公開されている特定の機能へのアクセスを禁止したりすることができます。 

最終的に、コールバックは RPC_S_OK を返してクライアントとサーバーとの通信を許可するか、 RPC エラーコード（RPC_S_ACCESS_DENIED など）で拒否します。

クライアント要求の受け入れ可否は、属性（複数の場合あり）に依存するのが一般的です。属性については、以下で説明します。

クライアントは、複数のトランスポートを介してサーバーと通信できます。これらには、TCP、名前付きパイプ、ALPC などがあります。セキュリティコールバックでは、属性を確認して、ローカル接続要求のみ、リモート要求のみ、TCP 通信などでフィルタリングすることができます。 

プロトコルシーケンスの値は文書化されていませんが、RpcCallAttributes 構造体のセキュリティコールバックに渡されるプロトコルシーケンスを次の値にマッピングしました。

#define ncacn_ip_tcp 1

#define ncacn_np 2

#define ncalrpc 3

#define ncacn_http 4

他のプロトコルシーケンス（ncacn_hvsocket など）は、 文字列バインディングの解析を通じてセキュリティコールバックによってテストできます。

セキュリティコールバックにおいて、クライアントの 認証レベル の確認は非常に一般的です。これにより、サーバーはクライアントに要求する最小認証レベルを定義できます。

認証レベルは次のように複数あります。それぞれは前のレベルを拡張するものになります。

認証サービス は、認証レベルによって提示される認証ポリシーの検証を担うサービスを規定しています。 

認証サービスの定数は次のとおりです。

#define RPC_C_AUTHN_NONE  0

#define RPC_C_AUTHN_DCE_PRIVATE  1

#define RPC_C_AUTHN_DCE_PUBLIC  2

#define RPC_C_AUTHN_DEC_PUBLIC  4

#define RPC_C_AUTHN_GSS_NEGOTIATE  9

#define RPC_C_AUTHN_WINNT  10

#define RPC_C_AUTHN_GSS_SCHANNEL  14

#define RPC_C_AUTHN_GSS_KERBEROS  16

#define RPC_C_AUTHN_DPA  17

#define RPC_C_AUTHN_MSN  18

#define RPC_C_AUTHN_DIGEST  21

#define RPC_C_AUTHN_NEGO_EXTENDER  30

#define RPC_C_NETLOGON   68 （文書化されていません）

#define RPC_C_AUTHN_MQ   100

#define RPC_C_AUTHN_DEFAULT  0xffffffff

RPC_C_AUTHN_NONEの場合、認証がオフになります。一方、 RPC_C_AUTHN_WINNT の場合、NTLM プロトコルが使用されます。

認証サービスと値の完全なリストについては、 GitHub ページをご覧ください。 

NULL セッションは匿名接続です。この場合、クライアントは認証なしでサーバーと通信します。ユーザー名やパスワードもありません。 

一般的に、セキュリティコールバックが登録されている場合は、サーバー登録時に「RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH」のフラグが指定されていない限り、デフォルトで NULL セッションはブロックされます（他のケースについては こちらを参照）。セキュリティコールバックでは NULLL セッションも確認できます。 

これらのセッションへのアクセスをブロックすることで、セキュリティコールバックは RPC インターフェースを非認証ユーザーから保護します。 

opnum は、クライアントが実行を要求するインターフェースの関数を表します。より正確に言うと、RPC サーバーの関数テーブルのインデックスです。

opnum の値を確認することで、サーバーはクライアントのアクセスを、リモートクライアントの機微な情報を処理する関数、カーネルメモリにアクセスする関数、ユーザーモードクライアントの関数など、特定の関数に制限したりブロックしたりすることができます

Akamai Security Research では、この確認に依存する セキュリティコールバックの興味深い例 をブログで紹介しています。 

他のセキュリティコールバック確認は次のとおりです。

• 呼び出し元 - 呼び出し元がユーザーモードかカーネルモードかを確認

• クライアント PID - 特定のプロセスのみを許可

• 文字列バインディング - プロトコルシーケンス、ネットワークアドレス、エンドポイント情報などの RPC 接続属性を検証

• なりすまし - サーバーがクライアントのセキュリティコンテキストでコードを実行できることを確認

複合的な確認もあります。たとえば、lsasrv.dll の LsaCapRpcIfCallbackFn コールバックで、認証サービスが netlogon の場合、認証レベルは RPC_C_AUTHN_LEVEL_PKT_INTEGRITY より小さくする必要があります。

RPC Interface Analyzer は、RPC インターフェースを調査するための自動化ツールです。これによって調査者は、2 つの異なるソース（インターフェース定義（IDL）ファイルまたは PE ファイル）から RPC インターフェースを検索したり分析したりできます。

IDL ファイル は、RPC インターフェースとその関数を定義するファイルです。一般利用可能な IDL ファイルを分析することで、RPC インターフェースに関する情報とそのサーバーが公開している関数を、パラメーターや戻り値の型と併せて取得できます。この情報を使用して、調査者は潜在的に脆弱な関数を探すことができます。たとえば、 PetitPotamなどでパス引数を受け取る関数が挙げられます。 

当社の IDL アナライザーを実行する場合は、以下のコマンドを実行します。

使用可能な RPC インターフェースをコンピューターですべてスキャンするとします。RPC PE Analyzer を実行し、 C:\Windows\System32 のコピーを scrape_path として提供し、出力を繰り返します。 

pe_rpc_scraper.py -d idapro “C:\Users\User\Documents\System32_Copy”

出力は JSON 形式のため、反復作業を行って特定の情報を検索するのは難しくありません。例：

• DLL ファイル内の RPC クライアント／サーバーをすべて検索

• コンピューター上の RPC クライアント／サーバーをすべて検索

• 特定の RPC インターフェースのクライアントを検索

• 特定の RPC サーバーの RPC セキュリティコールバックを検索

• インターフェースレベルでキャッシングする RPC インターフェースを検索（このタイプのキャッシングが問題になる理由について、詳細はこちらの ブログ記事 を参照してください）。

これらは一部にすぎず、出力の用途は数多くあります。当社では、さまざまな用途やアイデアに関する声をお待ちしています。

RPC_CALL_ATTRIBUTES は、クライアント要求に関するデータを保持する構造体です。サーバー側のインターフェース・セキュリティ・コールバックでは、 RpcServerInqCallAttributes 関数を呼び出して情報を取得することができます。 

typedef struct tagRPC_CALL_ATTRIBUTES_V3_W

{

    unsigned int Version;

    unsigned long Flags;

    unsigned long ServerPrincipalNameBufferLength;

    unsigned short *ServerPrincipalName;

    unsigned long ClientPrincipalNameBufferLength;

    unsigned short *ClientPrincipalName;

    unsigned long AuthenticationLevel;

    unsigned long AuthenticationService;

    BOOL NullSession;

    BOOL KernelModeCaller;

    unsigned long ProtocolSequence;

    RpcCallClientLocality IsClientLocal;

    HANDLE ClientPID; 

    unsigned long CallStatus;

    RpcCallType CallType;

    RPC_CALL_LOCAL_ADDRESS_V1 *CallLocalAddress;

    unsigned short OpNum;

    UUID InterfaceUuid;

    unsigned long          ClientIdentifierBufferLength;

    unsigned char          *ClientIdentifier;

} RPC_CALL_ATTRIBUTES_V3_W;

セキュリティコールバックが実行するテストについて解説しました。これにより、値を個別に照会したり（たとえば、 RpcStringBindingParseW ではプロトコルシーケンスを取得でき、 RpcBindingInqAuthClient では認証情報を取得できるなど）、構造体を使用したりすることができます。構造体にはあらゆるデータが保持されており、また必要な関数呼び出しは 1 つだけです。実際、解析したほとんどのセキュリティコールバックでは RpcServerInqCallAttributes が呼び出され、RPC_CALL_ATTRIBUTES の構造体を使用してすべての属性を同時に照会します。セキュリティコールバックのロジックを理解したい方にとって、この構造体は非常に興味深いものと言えます。

この構造体には現在「1」「2」「3」の 3 つのバージョンがあります。いずれも旧バージョンを拡張したものであり、それぞれ ANSI と Unicode のバージョンがあります。それぞれのバージョンとそのメンバについては、こちらの GitHub ページでご確認ください。 

RPC ツールキットに新たに追加されたのは セキュリティコールバック情報であり、これは RPC PE Analyzerに含まれています。クライアントの要求を承認／拒否する前に、セキュリティコールバックが実行する確認や検証をピークできます。 

RPC インターフェースのセキュリティコールバックや、特に RPC_CALL_ATTRIBUTES 構造体へのアクセスを解析すると、インターフェースに何らかの手掛かりが見つかる可能性があります。特定の認証プロトコルを使用する（または使用しない）RPC インターフェースをフィルタリングする場合は、このようにして 認証サービス の属性を確認するセキュリティコールバックを検索することができます。また、クライアント要求を許可したり、サーバー登録フラグで NULL セッションを許可したりする前に、 NULL セッション を確認しない RPC インターフェースを照会して、脆弱な可能性のある RPC インターフェースを検出することもできます。

各セキュリティコールバックに対して、アナライザーは次のように機能します。

• 使用されている RPC_CALL_ATTRIBUTES STRUCT のバージョンを検索し、IDA のローカルタイプに関連する構造体を定義

• RpcCallAttribute のローカル変数を見つけ、そのタイプとして RPC_CALL_ATTRIBUTES 構造体を適用

• この構造体を使用したセキュリティコールバックによる確認を解析して、テスト対象の要素、比較対象の値、使用する演算子（== / != / > / < / など）を出力します。

使用方法

使用方法は変わりません。RpcCallAttributes 構造体のメンバやテスト内容にアクセスする場合、IDA の逆アセンブラフラグを使用して RPC PE Analyzer を実行すると、各 RPC インターフェースの出力にセキュリティコールバック情報が毎回含まれるようになりました。

• 注：この情報の追加は、現在 IDA でのみ有効です。Radare のオプションを使用してアナライザーを実行しても、セキュリティコールバック情報は含まれません。

出力が得られたら、それを使用して脆弱性が存在している可能性のある RPC インターフェースを検索できます。必要に応じてフィルタリングすることもできます。以下に例を示します。

• RPC_C_AUTHN_LEVEL_PKT_PRIVACY の認証レベルのみを要求する RPC インターフェースを取得する

• ローカル接続を要求する RPC インターフェースを取得する

• カーネルモードの呼び出し元のみを要求する RPC インターフェースを取得する

• キャッシングの脆弱性の場合と同様に、opnum を確認する RPC インターフェースを取得する

まとめ