Fantastiche interfacce RPC e come trovarle

In breve, un callback di sicurezza è uno dei diversi modi per proteggere un'interfaccia RPC. È un callback personalizzato implementato dallo sviluppatore del server. La sua logica viene decisa dallo sviluppatore e consente allo sviluppatore di applicare il controllo degli accessi basato sull'utente, l'autenticazione, i tipi di trasporto o impedire l'accesso a funzioni specifiche esposte dal server. 

Infine il callback restituisce RPC_S_OK per consentire la comunicazione del client con il server, o uno dei codici di errore RPC, come RPC_S_ACCESS_DENIED, per rifiutarla.

La decisione di accettare o rifiutare la richiesta di un cliente si baserà solitamente su un attributo (o più di uno) che descriveremo di seguito.

Il client può comunicare con il server tramite diversi trasporti: TCP, named pipe, ALPC e altri. Il callback di sicurezza può controllare questo attributo per filtrare solo le richieste di connessione locale, solo le richieste remote, la comunicazione TCP, ecc. 

Sebbene i valori della sequenza del protocollo non siano documentati, abbiamo mappato le sequenze del protocollo che vengono passate al callback di sicurezza all'interno della struttura RpcCallAttributes nei seguenti valori:

#define ncacn_ip_tcp 1

#define ncacn_np 2

#define ncalrpc 3

#define ncacn_http 4

Altre sequenze di protocollo (come ncacn_hvsocket) possono essere testate dal callback di sicurezza tramite un'analisi del binding di stringa.

Il controllo del livello di autenticazione Del cliente è abbastanza comune nei callback di sicurezza. In questo modo, il server può definire il livello minimo di autenticazione che si aspetta dai propri client.

Esistono più livelli di autenticazione, ognuno estende il suo livello precedente:

Il servizio di autenticazione specifica il servizio incaricato di convalidare la policy di autenticazione fornita dal livello di autenticazione. 

I valori delle costanti del servizio di autenticazione sono:

#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 (Undocumented)

#define RPC_C_AUTHN_MQ   100

#define RPC_C_AUTHN_DEFAULT  0xffffffff

RPC_C_AUTHN_NONE, ad esempio, disattiverebbe l'autenticazione, mentre RPC_C_AUTHN_WINNT utilizzerà il protocollo NTLM.

L'elenco completo dei servizi di autenticazione e dei relativi valori è disponibile in questa pagina GitHub. 

Una sessione NULL è una connessione anonima. In questo caso il client comunica con il server senza autenticazione; ovvero, nessun nome utente o password. 

Nella maggior parte dei casi, se viene registrato un callback di sicurezza, le sessioni NULL vengono bloccate per impostazione predefinita a meno che non venga fornito il flag RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH alla registrazione del server (leggi altri casi qui). I callback di sicurezza possono anche verificare la presenza di sessioni NULLI. 

Bloccando l'accesso a queste sessioni, il callback di sicurezza protegge l'interfaccia RPC da utenti non autenticati. 

Il numero di operazione rappresenta la funzione dell'interfaccia che il client richiede di eseguire. Più precisamente, il numero di operazione è l'indice nella tabella delle funzioni del server RPC.

Controllando il valore del numero di operazione, il server può limitare o bloccare l'accesso del client a funzioni specifiche, come funzioni che gestiscono dati sensibili per client remoti, funzioni che accedono alla memoria del kernel e/o funzionalità per client in modalità utente, ecc.

Akamai Security Research ha pubblicato un post sul blog di un esempio di un interessante callback di sicurezza che si basa su questo controllo. 

Altri controlli di callback di sicurezza possono essere:

• Origine del chiamante : per verificare se il chiamante proviene dalla modalità utente o dalla modalità kernel

• PID client : per consentire solo processi specifici

• Binding di stringa : per convalidare gli attributi di connessione RPC come la sequenza del protocollo, l'indirizzo di rete, le informazioni sull'endpoint, ecc.

• Impersonificazione : per assicurarsi che il server possa eseguire il codice nel contesto di sicurezza del client

Esistono anche controlli complessi. Ad esempio, nel callback LsaCapRpcIfCallbackFn su lsasrv.dll, se il servizio di autenticazione è netlogon, il livello di autenticazione deve essere inferiore a RPC_C_AUTHN_LEVEL_PKT_INTEGRITY.

RPC Interface Analyzer è uno strumento di automazione per la ricerca di interfacce RPC. Consente ai ricercatori di trovare e analizzare le interfacce RPC da due fonti diverse: file di definizione dell'interfaccia (IDL) o file PE.

I file IDL sono i file che definiscono un'interfaccia RPC e le sue funzioni. Analizzando i file IDL pubblicamente disponibili, possiamo ottenere informazioni su un'interfaccia RPC e le funzioni che il suo server espone, insieme ai relativi parametri e tipi di valori restituiti. Con queste informazioni, un ricercatore può cercare funzioni potenzialmente vulnerabili; ad esempio, funzioni che ricevono un argomento di percorso, come nel caso di PetitPotam. 

Per eseguire il nostro analizzatore IDL, eseguite i seguenti comandi:

Supponiamo di voler scansionare tutte le interfacce RPC disponibili sul nostro PC. Possiamo eseguire RPC PE Analyzer, fornire una copia di C:\Windows\System32 come nostro scrape_path ed esaminare l'output. 

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

Poiché l'output è in formato JSON, è facile scorrerlo e cercare informazioni specifiche. Ad esempio:

• Trovare tutti i client/server RPC in un file DLL

• Trovare tutti i client/server RPC su un PC

• Trovare i client di una specifica interfaccia RPC

• Trovare i callback di sicurezza RPC di un determinato server RPC

• Trovare quali interfacce RPC utilizzano la memorizzazione nella cache a livello di interfaccia (leggete questo post del blog per ulteriori informazioni sul motivo per cui questo tipo di memorizzazione nella cache è problematico)

Questi sono solo alcuni dei numerosi usi di questo output. Siamo lieti di conoscere altri usi e idee.

RPC_CALL_ATTRIBUTES è una struttura che contiene i dati relativi alla richiesta del cliente. Il callback di sicurezza dell'interfaccia sul lato server può ottenere queste informazioni chiamando la funzione RpcServerInqCallAttributes 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;

Abbiamo già menzionato i test eseguiti dai callback di sicurezza. Possono interrogare singolarmente alcuni di questi valori (ad esempio, RpcStringBindingParseW per ricevere la sequenza del protocollo, RpcBindingInqAuthClient per le informazioni di autenticazione e altro), oppure usare questa struttura che contiene tutto e richiede solo una chiamata di funzione. In effetti, nella maggior parte dei callback di sicurezza che abbiamo analizzato, chiamano RpcServerInqCallAttributes e utilizzano la struttura RPC_CALL_ATTRIBUTES per interrogare tutti gli attributi contemporaneamente. Ciò rende questa struttura molto interessante se si desidera comprendere la logica del callback di sicurezza.

La struttura ha attualmente tre diverse versioni - 1, 2 e 3 - e ognuna è un'estensione della rispettiva versione precedente e ha versioni ANSI e Unicode. Le diverse versioni e i relativi membri sono disponibili su questa pagina GitHub. 

La nuova aggiunta al nostro kit di strumenti RPC Toolkit sono le informazioni sul callback di sicurezza, che fanno parte di RPC PE Analyzer. Forniscono una panoramica dei controlli e delle verifiche che il callback di sicurezza esegue prima di approvare/rifiutare le richieste dei client. 

L'analisi del callback di sicurezza di un'interfaccia RPC, e in particolare il suo accesso alla struttura RPC_CALL_ATTRIBUTES, può far luce sull'interfaccia. In questo modo, potete cercare i callback di sicurezza che controllano l'attributo del servizio di autenticazione se desiderate filtrare le interfacce RPC che utilizzano (o non utilizzano) un protocollo di autenticazione specifico Potete anche interrogare le interfacce RPC che non controllano le sessioni NULL prima che consentano le richieste dei client e i relativi flag di registrazione del server consentano le sessioni NULL, per scoprire interfacce RPC potenzialmente vulnerabili.

Per ogni callback di sicurezza, l'analizzatore:

• Trova quale versione della struttura RPC_CALL_ATTRIBUTES viene utilizzata e definisce la struttura pertinente nei tipi locali di IDA

• Individua la variabile locale RpcCallAttribute e applica la struttura RPC_CALL_ATTRIBUTES come tipo

• Analizza i controlli che il callback di sicurezza esegue utilizzando questa struttura e mostra quale membro viene testato, il valore con cui viene confrontato e con quale operatore (== / != / / / ecc.).><

In che modo è possibile utilizzarlo?

L'uso non è cambiato: ogni volta che viene eseguito RPC PE Analyzer con il flag del disassemblatore IDA, l'output per ogni interfaccia RPC ora includerà le relative informazioni di callback di sicurezza, se accede ai membri della struttura RpcCallAttributes e ciò che verifica.

• Nota: questa aggiunta è attualmente disponibile solo per IDA, l'esecuzione dell'analizzatore con l'opzione Radare non includerà le informazioni di callback di sicurezza.

Una volta ottenuto l'output, è possibile utilizzarlo per trovare interfacce RPC potenzialmente vulnerabili e filtrarle in base alle proprie esigenze. Alcuni esempi includono

• Individuare un'interfaccia RPC che utilizza solo il livello di autenticazione di RPC_C_AUTHN_LEVEL_PKT_PRIVACY

• Individuare le interfacce RPC che prevedono connessioni locali

• Individuare le interfacce che prevedono solo chiamanti in modalità kernel

• Individuare le interfacce RPC che verificano la presenza di numeri di operazione, come nel caso di vulnerabilità della memorizzazione nella cache

Riepilogo