CouchDB

L’attacco a couchDB, fra i tutti e 4 gli attacchi, è quello probabilmente più d’effetto perchè l’unica condizione necessaria per la vittima è quella di avere il couchDB webserver in ascolto al proprio indirizzo IP. Quest’ultima condizione ai giorni d’oggi è molto facile che si verifichi soprattutto in un contesto di servizi distribuiti; ad esempio si potrebbe aver acquistato uno spazio web presso un provider di servizi avendo quindi necessità di gestirlo da remoto. Ebbene, il caso di questo attacco è proprio quello di riuscire prendere il controllo della macchina su cui è ospitato il web server semplicemente inviando delle “particolari” richieste sfruttando l’API fornita dallo stesso couchDB.
L’attacco sfrutta due vulnerabilità, nella prima couchdb consente ad un amministratore delle configurazioni che permettono di eseguire dei binari nel file system, così attraverso delle chiamate http possono essere lanciate, in particolare di lanciare remote code execution. Nella seconda vulnerabilità a causa delle differenze nel parser JSON basato su Erlang di CouchDB e nel parser JSON basato su JavaScript, è possibile inviare un particolare JSON che consente all’attaccante di aggiungere se stesso come amministratore del DB.

Soluzione SELinux:
Analizzando le varie fasi dell’attacco è venuto fuori che il processo che permette di lanciare la shell è couchjs, un processo chiamato dal processo couchdb che usa per eseguire il JavaScript.
Negare quindi a tale processo l’esecuzione di /bin/sh.
La policy reference contiene già un modulo di policy relativo a couchdb con le regole minimali per la corretta assegnazione dei type a tutti i file relativi ad esso. E’ stato necessario quindi obbligare il dominio dell’utente utente_u a transitare in quello di couchdb_t. Quindi dopo un’attenta fase di debugging di tutti i permessi che esso andava a richiedere, ho consentito tutti tranne quelli che permettevano il lancio di una shell.

Soluzione AppArmor:
Nel tentativo di confinare questo attacco sono emersi alcuni limiti di AppArmor. Non esistono profili ufficiali per molti applicativi, couchDB è tra questi. Dunque per creare un profilo da zero possiamo usare le utility messe a disposizione da AppArmor come ad esempio “aa-genprof” il quale analizza i log di sistema e in seguito chiede conferma o diniego per ogni azione relativa all’applicativo che vogliamo limitare; questo approccio si è rivelato fallimentare in quanto, essendo un DBMS, probabilmente userà un suo file di log, rendendo inefficace lo scan dei log di sistema. Non riuscendo a creare un profilo personalizzato per CouchDB, non resta che beneficiare dell’hardenizzazione della funzione chmod, messa a punto per l’attacco 0, che anche in questo scenario proteggerà il sistema dall’attacco.

Soluzione Tomyo:
La difesa di questo attacco consiste, così come per l’attacco 0, nel proteggere l’esecuzione di chmod sulla cartella /tmp dalla shell aperta da couchDB togliendo i permessi di esecuzione.
Se volessimo limitare ulteriormente couchDB, una ulteriore soluzione sarebbe quella di negare al processo couchjs di eseguire la shell /bin/sh.

Soluzione GrSecurity:
Con le policy di default, in particolare quella di non fare eseguire su /tmp, l'attacco non funzionava.
Ma se per esigenze /tmp deve esser eseguibile, la soluzione migliore è quella di limitare la visibilità di couchdbjs, non permettendo di accedere a /bin/dash, aggiungendo il parametro h, in modo da bloccare la reverse shell.
La policy sarà granulare se questa regola varrà solo per determinati utenti, usando i ruoli.