Ultimamente si parla molto di problemi di DLL hijacking (letteralmente: dirottamento delle DLL), sebbene non sia certo un problema nuovo. La fama degli ultimi giorni è causata da uno strumento in grado di analizzare i programmi per scoprire se siano attaccabili attraverso il DLL hijacking. Ma andiamo con ordine per cercare di capire come funzioni il tutto.
Per prima cosa, una DLL (dynamic-link library, libreria a collegamento dinamico) è un file presente negli ambienti Windows che contiene delle funzioni utili a uno o più programmi che vengono caricate in maniera dinamica solamente quando servono al programma stesso. La gestione delle DLL negli ambienti Windows è sempre stata problematica, al punto tale che è stato anche coniato il termine DLL hell per indicare i problemi delle DLL delle prime versioni di Windows.
Da un punto di vista operativo, quando un programma ha bisogno delle funzioni contenute in una DLL, chiede a Windows di caricare la DLL attraverso la funzione LoadLibrary() in cui può specificare solamente il nome della DLL da caricare; in questo caso è compito di Windows andare a cercare la DLL ed è proprio qui che iniziano i problemi.
Windows cerca una DLL in un gruppo di directory ben precise con un ordine definito e interrompe la ricerca quando trova la DLL che sta cercando; le DLL vengono cercate storicamente in:
- la directory che contiene il file eseguibile (EXE) dell’applicativo;
- la directory corrente;
- la directory di sistema, tipicamente c:\windows\system32;
- la directory di sistema a 16 bit, tipicamente c:\windows\system;
- la directory di Windows, tipicamente c:\windows;
- le directory elencate nella variabile di ambiente PATH.
Immaginiamo di sapere che un’applicazione per ascoltare file MP3 è vulnerabile al DLL hijacking (in un altro post vedremo come fare per scoprirlo) e immaginiamo di volerla attaccare sfruttando questa vulnerabilità. Noi sappiamo che la procedura di installazione dell’applicazione copia PIPPO.DLL in c:\windows\system32 perché quella DLL è utilizzata da altri programmi della medesima software house. Tutto quello che dobbiamo fare è creare un file PIPPO.DLL con alcune funzioni modificate ad arte per ottenere i nostri scopi e mettere quel file nella stessa directory in cui metteremo die file MP3 (un disco di rete, una chiavetta USB, un CD-ROM…). A questo punto diciamo alla vittima che utilizza l’applicazione di aprire i file MP3 dalla directory che contiene anche PIPPO.DLL modificato ad arte. L’applicazione caricherà il nostro PIPPO.DLL prima di andarlo a prendere in c:\windows\system32 in quanto lo trova nella directory corrente. Il gioco è fatto.
Microsoft ha risolto questo problema introducendo la chiave di registro HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode; quando questa chiave assume il valore 1, l’ordine di ricerca diventa:
- la directory che contiene il file eseguibile (EXE) dell’applicativo;
- la directory di sistema, tipicamente c:\windows\system32;
- la directory di sistema a 16 bit, tipicamente c:\windows\system;
- la directory di Windows, tipicamente c:\windows;
- la directory corrente
- le directory elencate nella variabile di ambiente PATH.
SafeDllSearchMode è supportato a partire da Windows 2000 SP4 e Windows XP SP1 e viene messo per default a 1 a partire da Windows XP SP2. Ulteriori informazioni nell’articolo Dynamic-Link Library Search Order.
Dal momento che le funzioni di sistema per gestire le DLL sono molteplici, un’applicazione che non viene scritta secondo le linee guida e che ignora una nota di sicurezza specifica potrebbe essere ancora oggi suscettibile di DLL hijacking.
Aggiornamento del 10 settembre 2010: è disponibile un video in cui viene mostrata il DLL hijacking in azione, i dettagli in questo articolo.
Lascia un commento