Quando Apache o nginx servono file statici, seguono collegamenti simbolici anche se un collegamento punta a un file di proprietà di un altro utente del sistema (per esempio, uno corrispondente a un diverso abbonamento). Ciò consente a un autore di attacco con accesso a un abbonamento di leggere i file di un altro abbonamento, compresi i file contenenti password e impostazioni per WordPress e altri CMS.

Mitigazione della vulnerabilità

Autorizzazioni del file system

Se stai usando WP Toolkit, il modo più semplice per mitigare la vulnerabilità per le tue istanze di WordPress è quello di usare il Toolkit:

  1. Vai al WP Toolkit.
  2. Seleziona tutte le istanze di WordPress e fai clic su Controlla la sicurezza.
  3. Verifica che «Autorizzazioni per file e directory» sia contrassegnato come OK.
  4. Se non lo è, fai clic su Proteggi.

Se non stai usando WP Toolkit o se hai bisogno di proteggere qualche CMS diverso da WordPress, devi correggere manualmente i permessi su tutti i file che vuoi proteggere negando tutti i permessi al gruppo «Altro» eseguendo il seguente comando:

chmod o-rwx <file_name>

Nota: Non esiste un elenco di file da proteggere adatto a tutte le applicazioni web o CMS. I file esatti i cui permessi devono essere modificati per proteggere un’applicazione web variano a seconda dell’applicazione in questione.

Configurazione Apache

Questo modo di mitigare la vulnerabilità è adatto per gli abbonamenti che utilizzano Apache come server web (un abbonamento utilizza Apache se la “Modalità proxy” è attiva in Hosting e DNS > Impostazioni Apache & Nginx).

Nota: In Plesk Obsidian 18.0.30 e versioni successive, questa soluzione è applicata per impostazione predefinita. Nelle versioni precedenti di Plesk, segui le istruzioni riportate di seguito per mitigare la vulnerabilità.

Per mitigare la vulnerabilità, procedi come segue:

  1. Vai su Piani di servizio > il tuo piano > la scheda «Server Web» (o il tuo abbonamento > Siti web e Domini > Hosting e DNS > Impostazioni Apache e Nginx).
  2. Seleziona la casella di controllo “Limita la capacità di seguire link simbolici”.

Facendo ciò per un piano di servizio, si mitiga la vulnerabilità di tutti gli abbonamenti basati su quel piano di servizio (ossia, un autore di attacco che accede a un abbonamento non sarà in grado di effettuare attacchi contro altri abbonamenti). Facendo ciò per un abbonamento, si mitiga la vulnerabilità solo per quell’abbonamento.

Nota: Un sito web che utilizza collegamenti simbolici ai propri file continuerà a funzionare se non utilizza l’opzione «FollowSymLinks» nel file .htaccess, perché l’opzione «SymLinksIfOwnerMatch» è abilitata di default. Se un tale sito utilizza l’opzione «FollowSymLinks» nel file .htaccess, smetterà di funzionare.

Attenzione: L’applicazione di questa soluzione ti lascerà comunque vulnerabile a una condizione di race “time-of-check to time-of-use” relativa all’opzione «SymLinksIfOwnerMatch» dell’Apache. Per mitigare anche questa vulnerabilità, puoi applicare questa patch ad Apache (la patch non è stata testata da Plesk, applicala a tuo rischio e pericolo) o usa una delle opzioni di protezione di collegamenti simbolici basate sul kernel descritte più avanti in questo articolo.

Configurazione nginx

Questo modo di mitigare la vulnerabilità è adatto per gli abbonamenti che utilizzano nginx per servire direttamente i file statici (un abbonamento utilizza nginx se la “Modalità proxy” è disattiva o se la “Modalità proxy” è attiva e “Servire file statici direttamente da nginx” è attiva in Hosting e DNS > Impostazioni Apache & Nginx).

Per mitigare la vulnerabilità, procedi come segue:

  1. Vai su Piani di servizio > il tuo piano > Server Web (o il tuo abbonamento > Siti web e Domini > Hosting e DNS > Impostazioni Apache e Nginx).
  2. Seleziona la casella di controllo “Limita la capacità di seguire link simbolici”.

Facendo ciò per un piano di servizio, si mitiga la vulnerabilità di tutti gli abbonamenti basati su quel piano di servizio (ossia, un autore di attacco che accede a un abbonamento non sarà in grado di effettuare attacchi contro altri abbonamenti). Facendo ciò per un abbonamento, si mitiga la vulnerabilità solo per quell’abbonamento.

Nota: Questa opzione non è applicabile ai computer che eseguono il kernel Linux versione 2.6.39 o precedente. Per mitigare la vulnerabilità su tali macchine, si consiglia di aggiornare il sistema operativo all’ultima versione stabile o di utilizzare uno dei meccanismi di protezione dei collegamenti simbolici basati sul kernel elencati di seguito.

SecureLinks in mod_hostinglimits per CloudLinux

Sui computer che eseguono CloudLinux, puoi mitigare la vulnerabilità abilitando il meccanismo di protezione della corrispondenza del proprietario del collegamento simbolico disponibile come parte del modulo HostingLimits per Apache. Fai riferimento alla documentazione di CloudLinux per maggiori informazioni.

KernelCare Symlink Protection patchset per CentOS 7 (gratuito)

Sui computer che eseguono CentOS 7, puoi mitigare la vulnerabilità installando il Symlink Protection Patchset gratuito disponibile da CloudLinux. Fai riferimento alla documentazione di CloudLinux per maggiori informazioni.

Grsecurity (un set di patch per il kernel Linux che enfatizza i miglioramenti della sicurezza, è richiesto un abbonamento a pagamento)

Se nessuna delle opzioni per mitigare la vulnerabilità di cui sopra è applicabile alla tua situazione, puoi installare il set di patch per il miglioramento della sicurezza grsecurity per il kernel Linux e poi configurare la funzionalità GRKERNSEC_SYMLINKOWN. Si noti che l’utilizzo di grsecurity non è gratuito e richiede l’acquisto di un abbonamento annuale.