Un attacco di tipo symlink (collegamento simbolico n.d.t.) non è qualcosa di sicuramente nuovo in ambito unix-like. Curioso è invece vedere come online ed anche ultimamente ci siano sempre più forum dedicati che parlino di come arginare questa piaga : la gioia di tutti gli attacker odierni.
Se prendiamo questa due pagine ad esempio http://whmscripts.net/misc/2013/apache-symlink-security-issue-fixpatch/ , http://www.linuxkatta.com/cPanelFix/solutions-for-handling-symlink-attacks/ , vediamo come sia attualissimo il problema e che addirittura si millantano patch da parte di due colossi operanti nel settore hosting come Rack911 e cPanel.
Ciò ha del ridicolo, ed è praticamente assurdo in quanto già di default Apache prevede un elegante modo per risolvere il problema , ovvero disabilitare l’opzione FollowSymLinks e sostituirla con SymLinksIfOwnerMatch
La prima opzione permette di disabilitare completamente Apache dall’attraversare link simbolici, la seconda permette di sostituire la prima in maniera intelligente, ovvero “se e solo se” il proprietario del file target a cui punterà il link simbolico sia lo stesso del link.
Ciò permetterà di continuare ad usare quelle feature di Apache come l’url rewriting, (tramite mod_rewrite).
In questo modo e con una corretta separazione dei privilegi a livello di virtualhosting utilizzando Apache in modalità FastCGI o tramite PHP-FPM come abbiamo accennato in QUESTO PRECEDENTE ARTICOLO, si riuscirà a confinare forzatamente l’attaccante all’interno della propria home, ed evitare che scorrazzi indisturbato nel server o nelle home degli altri utenti.
Una delle preoccupazioni da adottare al momento di configurare Apache è anche quella di evitare che l’attaccante con un file .htaccess ad-hoc da lui caricato possa riabilitare l’opzione FollowSymLinks e che possa vanificare in pochi secondi i nostri sforzi.
Nel video alla fine di questo breve articolo troverete la dimostrazione pratica dell’attacco senza censura alcuna e una guida passo passo alla risoluzione del problema mostrandovi la configurazione corretta di alcuni file apache per un vhost che abbiamo usato per il nostro esperimento.
Buon proseguimento.
To all english readers :
Simply you can correctly configure Apache to limit this type of attack.
The steps you take are 3:
- Eliminate the option FollowSimLinks
- Add the option SymLinksIfOwnerMatch
- Remove the possibility of reactivating FollowSimLinks through a htaccess file.
Edit the configuration file for the vhost and set the following configuration:
Options-Indexes-FollowSymLinks + ExecCGI + SymLinksIfOwnerMatch
AllowOverride All Options = ExecCGI, SymLinksIfOwnerMatch, Indexes
In this way, no attacker will be able to do this kind of attack.