Come diventerà vulnerabile un server con chmod 777?

Ho letto spesso articoli che dicevano qualcosa sulla falsariga di “chmod 777 è cattivo!”

Mi stavo chiedendo:

Come posso diventare vulnerabile quando eseguo ‘chmod 777’ su un file?

Qual è un esempio di mondo reale di ciò che posso riprodurre?

    Consente al contenuto del file system di essere visualizzato e / o modificato da chiunque : presupponendo che l’utente malintenzionato abbia già un accesso di sistema generale molto comune sulle piattaforms di hosting condivise .. alcuni sono più “temprati” di altri fin dall’inizio. Ecco una piccola lista incompleta di possibili vettori di attacco:

    1. “il tuo codice sicuro” potrebbe essere sovrascritto con “il loro codice dannoso” che viene eseguito all’interno dello stesso contesto del server Web. potrebbe rubare password / trojan, esporre DB, eliminare contenuto, ecc. Cioè, il codice di qualcun altro può essere eseguito sotto la tua sicurezza contesto .
    2. Il contenuto (ad esempio “fonte di script”) può essere visualizzato al di fuori del contesto del server Web (o del proprietario). Hai una password “sicura” per connetterti al DB? Bene, non più …
    3. Se il contenuto era protetto da autorizzazioni (ad esempio, prima non era ansible accedere al server Web ), il server Web potrebbe essere in grado di accedere / elencare informazioni riservate … non valido se non si intendesse condividerlo. Diverse configurazioni di server Web tratteranno anche “elenchi” in modo diverso, il che può anche esporre più di quanto desiderato.

    In quanto sopra, suppongo anche che “gruppo” includa il principal del web server e che sia coinvolto un web server (e / o hosting condiviso) che possa essere utilizzato come vettore di attacco primario e / o vulnerabilità di sicurezza. Tuttavia, e lo ribadisco ancora: l’elenco sopra non è completo .

    Anche se non “sicurezza garantita”, l’utilizzo delle autorizzazioni più specifiche può mitigare alcune vulnerabilità / esposizione.

    Se l’utente malintenzionato ha accesso all’interfaccia Web (non ai file, ad esempio, tramite un altro account sullo stesso hosting condiviso), la modalità 777 non apre direttamente alcuna vulnerabilità. Quello che fa è rendere più facile per l’utente malintenzionato modificare le cose sul sito una volta che ottengono in qualche altro modo.

    Ad esempio, supponiamo che tu abbia un sito WordPress e che ci sia un bug da qualche parte che permetta all’utente malintenzionato di eseguire codice PHP arbitrario sotto le credenziali del daemon del server (questo è successo molte volte in passato e senza dubbio si ripeterà di nuovo in futuro). Il codice per WordPress stesso è memorizzato in file .php che il daemon del server può leggere. Se tali file sono in modalità 777, l’utente malintenzionato può scrivere su di essi, il che significa che possono modificare il codice, modificando il funzionamento del sito. Forse installano un kit “drive by exploit” e ora tutti quelli che visitano il tuo sito vengono violati dal browser. Forse installano un kit di spam SEO e ora Google pensa che tu stia vendendo Viagra (ma se visiti direttamente il sito è invisibile – sì, succede davvero).

    Se i file .php sono in modalità 755 e sono di proprietà di un utente che non è il daemon del server, l’autore dell’attacco non può modificare in modo definitivo il funzionamento del sito.

    Nota che ciò significa che la funzione di auto-aggiornamento da pannello di amministrazione di WordPress è rischiosa, dal momento che funziona solo se WordPress può modificarsi da solo – non puoi averlo e anche l’avversario non può modificare i file una volta che possono eseguire PHP arbitrario.

    Nota anche che sei al sicuro al 100% a questo riguardo se non ci sono file e nessuna directory che il daemon del server può modificare. Anche solo consentire il caricamento di file in una singola directory può essere ancora un problema, anche se l’unica cosa che consente a chiunque di inserirvi è quella dei file di immagine. (Se ciò sembra imansible, dai un’occhiata a http://lcamtuf.coredump.cx/squirrel/ .)

    Ogni cifra nel comando chmod rappresenta un numero ottale (3 bit). Con tre cifre, è 9 bit in totale. Ogni bit rappresenta un’authorization; 1 == ha permesso, 0 == non ha permesso.

    I tre bit di ciascuna cifra rappresentano read (binario 100 == decimale 4), write (binario 010 == decimal 2) ed esegui (binario 001 == decimale 1). Decimale 7 è permesso di lettura + scrittura + esecuzione.

    La prima cifra di un comando chmod rappresenta le autorizzazioni del proprietario di un file o di una directory. Il secondo è per il gruppo. Il terzo è per “l’universo” – cioè, tutti gli altri.

    Quindi chmod 777 rappresenta il permesso di lettura, scrittura ed esecuzione per te, il gruppo e tutti. Questo è solitamente un accesso molto più grande di quello richiesto.

    Per il tuo esempio del mondo reale, immagina se un file chiamato my_bank_account_credentials fosse stato modificato con chmod 777 . Non molto sicuro! Un utente malintenzionato potrebbe cambiare ciò che è lì dentro o semplicemente leggerlo e prendere felicemente i tuoi soldi.

    Per i server, il principale pericolo è che un bug sfruttato nel codice server possa consentire a un utente malintenzionato di accedere a qualsiasi cosa a cui il processo del server ha diritti – che includerebbe qualsiasi cosa abbia il set di autorizzazioni 777 .

    chmod è il comando CHange MODe. Il 777 indica le autorizzazioni. ci sono tre gruppi di persone che possono avere permessi (ognuno riceve la propria cifra), nell’ordine: Proprietario (del file o della directory, il primo 7), gruppo (tutti quelli che appartengono allo stesso gruppo del proprietario, secondo 7 ) e mondo (terzo 7).

    Il proprietario è l’utente del file – che saresti tu. Nel mondo * nix, gli utenti appartengono ai gruppi. Quindi potresti essere utente / proprietario Bob nel gruppo Marketing. Questo modello ti consente di fare cose come dire che Bob può leggere / scrivere il file, il resto del marketing può solo leggere il file e altri utenti possono leggere il file.

    Ogni cifra nel 777 è una rappresentazione binaria di: rwx (lettura / scrittura / esecuzione). Quindi un chmod di 755 significa: 111 (7) – Il proprietario può leggere write execute 101 (5) – altro nel gruppo può eseguire o leggere, no write 101 (5) – resto del mondo può leggere ed eseguire, no write.

    Questa impostazione significa che puoi leggere / scrivere ed eseguire i tuoi file, ma le persone che visitano il tuo sito possono solo leggere o eseguire il file. Quindi è necessario impostare i programmi nel cgi-bin su 755, in modo che le persone possano eseguire il file come programma.

    Se imposti i permessi a “chmod 644”, ottieni un file che può essere scritto da te, ma può essere letto solo dal resto del mondo. Questo è un bene per i file HTML dritti, in modo che nessun pandemonio possa andare avanti. Ma prova ed esegui un file con permessi di 644 e riceverai un errore.

    CHMOD 777 consentirà a tutti di apportare modifiche ai file del server, darà loro la condizione di scrittura e tutti sanno che è male.

    Se una voce dannosa raggiunge la tua app, il tuo sito web, ecc. Non importa cosa faccia al codice. Il punto critico è nel database e non esiste alcuna protezione contro la “scrittura” su di esso. Quindi i permessi di chmod 777 non sono affatto pericolosi.