Impedire al malware di annusare la password sudo

Sento spesso le persone che citano sudocome una delle principali barriere al malware che infetta un computer Linux.

L'argomento più comune sembra seguire: I privilegi di root sono richiesti per modificare la configurazione del sistema, e una password è richiesta per ottenere i privilegi di root, quindi il malware non può modificare la configurazione del sistema senza richiedere una password.

Ma mi sembra che per impostazione predefinita sulla maggior parte dei sistemi, una volta che il malware ha infettato un account amministratore, l'escalation dei privilegi è banale: il malware deve solo attendere l'esecuzione dell'utente sudo.

Quali metodi esistono per consentire ai malware di ottenere i privilegi di root quando l'utente esegue sudoe come possiamo proteggerli?

Modifica: sono specificamente interessato alla protezione da un account amministratore compromesso; vale a dire, un account con privilegi di root completi sudo(ad es. l'account dell'utente su un tipico sistema desktop).

Una volta che un malware ha ottenuto l'accesso all'account di un utente, può:

1. Creare un alias bash (nella shell corrente e in ~/.bashrc) a un comando che simula il [sudo] password for $USER:prompt e ruba la password dell'utente.

alias sudo='echo -n "[sudo] password for $USER: " && \
            read -r password && \
            echo "$password" >/tmp/sudo-password'

2. Analogamente, esso può generare un eseguibile denominato sudoin ~/.bin, e modificare la PATHvariabile per ottenere lo stesso effetto:PATH="$HOME/.bin:$PATH"

3. Il tasto Cattura preme attraverso il server X, cerca la parola sudo, quindi prova il testo tra i due Entertasti successivi che premono come password.

4. Una cosa simile può essere fatta in qualsiasi ambiente (console, Wayland , X) usando ad es $LD_PRELOAD.

5. Se il malware infetta una shell che utilizza sudoe sudomemorizza nella cache le credenziali, il malware può controllare in modo continuo se è possibile sudosenza una password:

while : ; do
    echo | sudo -S echo "test" &>/dev/null && break
    sleep 10
done
sudo echo "We now have root access"

Prevenzione:

1 e 2. Usa \/bin/sudo. Il \ignora alias e /bin/…ignora $PATH. In alternativa, aggiungi un alias come:, ssudo="\/bin/sudo"e usa sempre ssudoinvece di sudo. Sembra improbabile che un virus sia abbastanza intelligente da rimappare questo alias.

3. Evitare di digitare la password quando si utilizza X11. Utilizzare invece una console virtuale o Weston .

5. Impostare timestamp_timeout=0in /etc/sudoers.

L'unico modo per eliminare completamente la possibilità che la sudopassword venga sniffata sembra essere evitarla del tutto. Effettua invece il login come root su una console virtuale.

Secondo Alexander Peslyak : "l'unico uso sicuro di su [e sudo] è passare da un account più privilegiato a uno meno privilegiato ..."

In una nota a margine, sudo ha alcune contromisure:

• sudolegge ttyinvece di stdin, quindi si alias sudo='tee -a /tmp/sudo-password | sudo'interrompe sudo(ma cattura la password).

Non esiste una vera protezione.

L'accesso protetto da password a sudo risale a un'era precedente a complessi ambienti shell con comandi eseguiti da shim. Una volta che la password è stata inviata, c'è una finestra di opportunità in cui uno shim può eseguire comandi tramite sudo, senza alcuna notifica e con il pieno controllo del sistema.

Se fossi intenzionato all'accesso, creerei un utile shim per bash, zsh e fish, ecc. Monitorerei i comandi eseguiti. Poco dopo che un sudo è tornato con uno stato pari a zero, inizierei a pubblicare "sudo chmod + s / bin / sh" o altre cattiverie.

Nel momento in cui sudo ha ricevuto una password soddisfacente e si dispone di shell che eseguono comandi per ottenere un prompt, si è potenzialmente in difficoltà. Non c'è protezione, oltre all'ottimismo.

Altre risposte si sono concentrate sulla protezione della password. Come aggressore, non me ne preoccuperei. Mi concentrerei sulla durata dopo che è stata data la password, quando non è necessaria una password. Questo è il momento più rischioso, quando l'attaccante deve fare meno per compromettere completamente il sistema.

Ti stai proteggendo? Dovresti proteggere i tuoi file RC. Ispezionare eventuali spessori o altri comandi utilizzati nei prompt della riga di comando. Cercare i co-processi collegati alla shell e gli strumenti utilizzati per mantenere l'ambiente della shell. Le principali difese sarebbero gli strumenti di intrusione dell'host, ma questo è un dato di fatto. Prevenire gli attacchi? Usare solo semplici shell senza complesse configurazioni automatizzate e prompt attivi - questo è l'ambiente per cui è stato sviluppato sudo.

Giocavo con altri sviluppatori (anni '80) in cui provavamo a scrivere cose che avrebbero ottenuto il terminale utilizzato dall'altro sviluppatore, per inserire comandi - questo è essenzialmente lo stesso problema. E abbiamo reso molto più semplice incorporare strumenti che farebbero l'inserimento dei comandi senza traccia visibile. :)

Non sei sicuro di tutti i metodi per gli utenti non autorizzati a privilegi root guadagno, ma so che qualcosa che si può fare per rendere sudoun po 'meno pericoloso , se si vuole dire che. sudoconsente di configurare autorizzazioni granulari, al fine di definire gruppi di utenti con privilegi specifici e comandi specifici che determinati utenti possono eseguire.

SUDO - CONTROLLO GRANULARE

• Sezione utente

  Qui è possibile impostare gruppi per gli utenti per i quali verranno specificati i comandi. Consente di impostare un gruppo Operazioni;

  User_Alias  OPS = bob, jdoe 
  

  Questo crea il gruppo OPS e inserisce nel gruppo gli utenti di nome bob e jdoe

• Cmnd_Alias

  Qui specifichiamo specifici set di comandi. È necessario specificare il percorso completo e tutte le opzioni di comando che si desidera utilizzare. Consente di impostare i comandi del gruppo Operazioni;

  Cmnd_Alias OPSCMD = /admin/bin/srvbkup, /admin/bin/test 
  

  Ciò aggiunge i tre comandi specificati al gruppo di comandi OPSCMD.

• Specifica dei privilegi dell'utente

  Qui è dove utilizzeremo i gruppi che abbiamo impostato finora;

  OPS  ALL=(root)  OPSCMD 
  

  La prima cosa che specifichiamo sono gli utenti, qui usiamo il gruppo OPS che configuriamo. Quindi ALL indica che si applica a tutti i server, questo è utile solo se tu o esegui sudo su più server usando ciascuno lo stesso file di configurazione. Successivamente specifichiamo all'utente che il gruppo Operazioni eseguirà i comandi specificati poiché, in questo caso, vogliamo che vengano eseguiti come root. Infine, specificiamo i comandi che vogliamo che il gruppo OPS sia in grado di eseguire, in particolare stiamo usando il gruppo OPSCMD che impostiamo. Se non volevi che inserissero la password ogni volta che usavano sudo, la specifica del comando sarebbe piuttosto NOPASSWD: OPSCMD.

Indurisci le tue sudopolitiche tanto quanto non ti fidi dei tuoi utenti :)

Se sei interessato a un sistema che ritieni possa essere compromesso, esegui "Rootkit" e usa "Tripwire" per verificare l'integrità del filesystem.

Ti consiglierebbe anche di rafforzare i privilegi di sudo, come se non avessi bisogno che tutti gli utenti abbiano accesso a tutti i comandi di root piuttosto che dare accesso a comandi specifici tramite SUDO.

Prima di tutto dai un'occhiata al /etc/sudoersfile.

La sintassi sarà user MACHINE=COMMANDSformattata.

Ad esempio l'utente root avrà root ALL=(ALL) ALL Ciò significa che l'utente root può eseguire qualsiasi (tutti) comandi ovunque.

Se anche la tua voce ha, ALL=(ALL)allora sei quasi uguale a un utente root. Se questo non è il caso e hai solo alcuni privilegi limitati, l'attaccante / malware può fare solo quanto il tuo privilegio sudo può fare.

Suggerimenti che possono aiutarti:

1. Esamina il tuo /etc/sudoersfile.
2. Esegui uno scanner di sicurezza come chkrootkit, rootkit hunter, Config server Exploit scanner, snort ecc.
3. Utilizzare il visudocomando per modificare e modificare i privilegi del file sudoers.
4. Esegui di nuovo gli scanner.

Riferimento: pagina man Linux di sudoer e sudo man sudoer