DLL Hell come back: share di rete in salsa rossa, piccante!

A chi pensava che con le care vecchie DLL non ci fossero più problemi, diciamo subito che si sbagliava. L'inferno continua con un nuovo (che poi tanto nuovo non è...) vettore di attacco che rischia di creare non pochi problemi soprattutto alle realtà aziendali dove gli share di rete sono utilizzatissimi.

Partiamo dall'inizio. Il caricamento di una DLL da parte di un codice eseguibile richiede come prima cosa di trovare tale DLL. Le politiche adottate per localizzare la DLL sono di cercarla:

- nel path corrente dell'applicazione in esecuzione;

- nelle directory di sistema del Sistema Operativo;

- nelle directory elencate nella variabile PATH di Environment;

- nella directory corrente;

- ...

Questo nel caso in cui l'impostazione della chiave "HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode" sia impostata a true. Altrimenti il caricamento dalla directory corrente scala al secondo posto! E in alcune versione di Windows l'impostazione è false di default. Poi metteteci anche che le singole applicazioni possono variare l'ordine di ricerca a dispetto del registry e la frittata è fatta!

Il vettore d'attacco consiste quindi nel posizionare la DLL maliziosa, con lo stesso nome di quella originale richiesta dall'applicazione che chiameremo per esempio X, in una directory di uno share di rete. Poi insieme alla DLL si aggiunge un file che l'applicazione X può aprire. A questo punto quando l'utente richiederà l'apertura del file, X verrà eseguita, e la DLL maliziosa caricata al posto di quella trusted (presente magari nella directory di sistema).

A complicare il tutto ci si mette anche Metasploit che ha già bello e pronto un exploit basato su tale vettore d'attacco abbinabile a qualsiasi payload. Il vettore di attacco quindi è abbastanza semplice da utilizzare e l'impatto rischia di essere assai elevato.



KB: We can't fix this one - Microsoft DLL Hijacking Exploit from Offensive Security on Vimeo.


Il rischio infatti viene innalzato dalla probabilità che l'attacco si verifichi: alta, visto che basta mettere gli opportuni file su un share di rete ed attendere che il malcapitato di turno clicchi sul file; e l'impatto è anch'esso elevato, perché potenzialmente possono essere distribuiti payload di vario tipo: dal DoS degli host vittima fino al furto di dati.

Perché allarmarsi tanto direte voi, appena Microsoft rilascerà l'opportuna patch tutto sarà risolto! Eh no, purtroppo non c'è nessun patch risolutiva, bisogna solo applicare le best practice per il caricamento delle DLL all'interno delle applicazioni: caricare le DLL specificando sempre il path completo in buona sostanza. Per fortuna che almeno un primo workaround per evitare il caricamento delle DLL dagli share di rete viene fornito attraverso la solita chiave di registro da impostare.

Ma come è possibile scoprire quali siano le applicazioni vulnerabili a questo tipo di attacco?

Dato che non è possibile (sarebbe un lavoro enorme) fare la review del codice sorgente di OGNI applicazione e vedere se rispettano le best practice da tempo pubblicate su MSDN:

• Wherever possible, specify a fully qualified path when using the LoadLibrary, LoadLibraryEx, CreateProcess, or ShellExecutefunctions.
• Consider using DLL redirection or a manifest to ensure that your application uses the correct DLL.
• Make sure that safe DLL search mode is enabled. This places the user's current directory later in the search order, increasing the chances that Windows will find a legitimate copy of the DLL before a malicious copy. Safe DLL search mode is enabled by default starting with Windows XP with SP2 and is controlled by the HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode registry value. For more information, see Dynamic-Link Library Search Order.
• Consider removing the current directory from the DLL search path by calling SetDllDirectory with an empty string (""). This should be done once early in process initialization, not before and after calls to LoadLibrary. Be aware that SetDllDirectory affects the entire process and that multiple threads calling SetDllDirectory with different values can cause undefined behavior. If your application loads third-party DLLs, test carefully to identify any incompatibilities.
• Do not use the SearchPath function to retrieve a path to a DLL for a subsequent LoadLibrary call unless safe process search mode is enabled. When safe process search mode is not enabled, the SearchPath function uses a different search order than LoadLibrary and is likely to first search the user's current directory for the specified DLL. To enable safe process search mode for the SearchPathfunction, use the SetSearchPathMode function with BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE. This moves the current directory to the end of the SearchPath search list for the life of the process. Note that the current directory is not removed from the search path, so if the system does not find a legitimate copy of the DLL before it reaches the current directory, the application is still vulnerable. As with SetDllDirectory, calling SetSearchPathMode should be done early in process initialization and it affects the entire process. If your application loads third-party DLLs, test carefully to identify any incompatibilities.
• Do not make assumptions about the operating system version based on a LoadLibrary call that searches for a DLL. If the application is running in an environment where the DLL is legitimately not present but a malicious copy of the DLL is in the search path, the malicious copy of the DLL may be loaded. Instead, use the recommended techniques described in Getting the System Version.

Microsoft suggerisce di utilizzare la utility "ProcMon" per analizzare il flusso di caricamento delle DDL nelle nostre applicazioni:

1. Attempt to start your application with the current directory set to a specific directory. For example, double-click a file with an extension whose file handler is assigned to your application.
2. Start Process Monitor.
3. In Process Monitor, include the following filters:
   
   
   
   • Operation is CreateFile
   • Operation is LoadImage
   • Path contains .dll
   • Path contains .DLL
   • Path contains .sys
   • Path contains .SYS
4. Exclude the following filters:
   
   
   
   • Process Name is procmon.exe
   • Process Name is Procmon64.exe
   • Process Name is System
   • Operation begins with IRP_MJ_
   • Operation begins with FASTIO_
   • Result is SUCCESS
   • Path ends with pagefile.sys
5. Check Process Monitor output for paths that look suspicious, such as a call to the current directory to load a DLL. This kind of call might indicate a vulnerability in your application.

Pensare di passare a tappeto tutte le applicazioni che normalmente vengono eseguite su un PC sarebbe però un suicidio!

Fortunatamente quelli di Metasploit ci vengono in aiuto con un kit di audit (DLLHijackAuditKit v. 2) che permette di identificare le applicazioni vulnerabili, fornendo anche dei PoC da inviare al produttore del sw vulnerabile.

Per un'analisi puntuale su un solo software (il Kit di Metasploit è invece un'analisi totale di tutti i software presenti sul PC), GuelfoWeb ha invece sviluppato un suo Kit che vi segnalo qui.

E' anche disponibile una lista non ufficiale con tutte le applicazioni vulnerabili a cui, se volete potete contribuire (questo è l'indirizzo, ringrazio Guelfo per la segnalazione).

Quindi, dovendo decidere come muoversi, questa è la strategia che suggerisco:

1. assicurarsi che il "SafeDllSearch" sia abilitato su tutti gli host della rete;
2. utilizzare la KB2264107 Microsoft (e relativo aggiornamento) per disabilitare il caricamento delle DLL su share di rete;
3. identificare le applicazioni non Microsoft (riduce lo spazio di analisi; passo opzionale nel caso in cui si usi il kit metasploit) ;
4. identificare le applicazioni aziendalmente più utilizzate;
5. analizzare le applicazioni mediante "ProcessMonitor", Kit Metasploit o Kit Guelfo, o lista non ufficiale, e identificare quelle vulnerabili;
6. contattare gli sviluppatori di tali applicazioni per le eventuali patch;
7. attendere che siano disponibili anche gli aggiornamenti ufficiali dai diversi produttori (come Microsoft) con il corretto caricamento delle DLL.

Che dire: buona fortuna a tutti!