Esiste un modo per impedire a un utente di creare file eseguibili e di eseguirli?

Gli attacchi ransomware potrebbero utilizzare exploit zero-day, ma spesso un utente malintenzionato ingannerà un utente credulone nell'eseguire un eseguibile scaricando e facendo clic.

Supponiamo di avere un utente ingenuo e di volerli limitare al percorso normale. Esiste un modo per impedire loro di creare un file con privilegio eseguibile?

O, più in generale, esiste un modo per creare un elenco di controllo di accesso e definire che questo utente può eseguire solo i file in questo elenco?

L'attacco specifico di cui hai espresso preoccupazione è:

spesso un utente malintenzionato ingannerà un utente credulone nell'eseguire un eseguibile scaricando e facendo clic.

Almeno nel caso comune in cui il file viene scaricato in un browser Web, ciò dovrebbe essere già impedito in Ubuntu dall'adesione del browser al criterio Bit di autorizzazione necessario . Le parti più direttamente rilevanti di tale politica sono:

• Le applicazioni, inclusi desktop e shell, non devono eseguire codice eseguibile dai file quando sono entrambi:

  • manca il bit eseguibile
  • situato nella home directory di un utente o nella directory temporanea.

• I file scaricati da un browser Web, client di posta, ecc. Non devono mai essere salvati come eseguibili.

Pertanto, se viene richiesto a un utente di scaricare un programma in un browser Web, lo fa e tenta di eseguire il file facendo doppio clic su di esso, non verrà eseguito. Questo vale anche se il file scaricato è uno script di shell o anche un file .desktop. (Se ti sei mai chiesto perché i file .desktop nella tua home directory devono essere contrassegnati come eseguibili anche se non sono realmente programmi, ecco perché.)

È possibile per gli utenti modificare questo comportamento attraverso modifiche alla configurazione. La maggior parte no, e mentre quelli che lo fanno probabilmente non dovrebbero, non è proprio quello di cui ti devi preoccupare. La preoccupazione maggiore è l'attacco più complesso di cui penso tu sia già preoccupato, in cui una persona malvagia (o bot) istruisce l'utente a scaricare un file specifico, contrassegnarlo da solo (tramite il browser dei file o con chmod) e quindi eseguirlo.

Sfortunatamente, limitare la capacità di un utente di impostare il bit di esecuzione su un file o di eseguire file diversi da quelli presenti su alcune whitelist non attenuerebbe notevolmente il problema. Alcuni attacchi funzioneranno già e quelli che non potrebbero essere banalmente modificati in modo da farlo. Il problema fondamentale è che l'effetto di esecuzione di un file può essere raggiunto anche se il file non dispone delle autorizzazioni eseguibili .

Questo è meglio illustrato dall'esempio. Supponiamo che evilsia un file nella directory corrente che, se avesse le autorizzazioni eseguibili ( chmod +x evil) e run ( ./evil), farebbe qualcosa di malvagio. A seconda del tipo di programma, lo stesso effetto può essere ottenuto da uno dei seguenti:

• . ./eviloppure source ./evilesegue i comandi nella evil shell attualmente in esecuzione .
• bash ./evilcorre evildentro bash.
• python3 evilcorre evildentro python3.
• perl evilcorre evildentro perl.
• ... e, in generale, interpreter evilviene eseguito evilnel interprete interpreter .
• Sulla maggior parte dei sistemi, /lib64/ld-linux-x86-64.so.2 ./evil esegue l'eseguibile binario evil .

Nessuno di questi, nemmeno l'ultimo, richiede che il file disponga delle autorizzazioni eseguibili o che l'utente sia in grado di concedere le autorizzazioni eseguibili al file.

Ma le istruzioni malevole non devono nemmeno essere così complicate. Considera questo comando non dannoso , che è uno dei modi ufficialmente raccomandati per installare o aggiornare NVM :

wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh | bash

Il motivo che non è dannoso è che NVM non è un malware, ma se l'URL fosse invece dello script di qualcuno che fa male quando viene eseguito, quel comando scaricherà ed eseguirà lo script. In nessun momento è necessario assegnare a file i permessi eseguibili. Scaricare ed eseguire il codice contenuto in un file dannoso con un singolo comando come questo è, credo, un'azione abbastanza comune che gli hacker ingannano gli utenti.

Potresti pensare di provare a limitare quali interpreti sono disponibili per l'esecuzione da parte degli utenti. Ma non c'è davvero un modo per farlo che non abbia un impatto sostanziale sulle attività ordinarie che presumibilmente si desidera che gli utenti possano svolgere. Se stai configurando un ambiente estremamente limitato in cui è vietato quasi tutto ciò che un utente potrebbe pensare di fare su un computer, come un chiosco che esegue solo un paio di programmi, questo potrebbe fornire una certa protezione significativa. Ma non sembra che sia il tuo caso d'uso.

Quindi la risposta approssimativa alla tua domanda è "No". La risposta più completa è che probabilmente potresti riuscire a impedire agli utenti di eseguire qualsiasi file tranne quelli forniti in una whitelist. Ma questo è nel senso rigorosamente tecnico di "eseguire", che non è necessario per ottenere il pieno effetto dell'esecuzione della maggior parte dei programmi o degli script. Per evitare che , si potrebbe provare a fare il whitelist molto piccolo, quindi non ha alcun lista interpreti ad eccezione di quelli che potrebbero essere fortemente limitato. Ma anche se ci riuscissi, gli utenti non potrebbero fare molto, e se lo rendessi così piccolo da non poter farsi male, probabilmente non potrebbero fare nulla. (Vedi il commento di Thomas Ward .)

Se i tuoi utenti possono farsi male, possono essere ingannati nel farsi male.

Potresti essere in grado di limitare l'utilizzo o il comportamento di programmi specifici in modi che potrebbero essere dannosi e se stai osservando modelli specifici che tende a seguire il ransomware, potresti essere in grado di prevenire alcuni casi comuni specifici. (Vedi AppArmor .) Potrebbe fornire un valore. Ma non ti darà nulla di simile alla soluzione completa che speri.

Qualunque misura tecnica (se presente) finisci per prendere, la soluzione migliore è educare gli utenti. Ciò include dire loro di non eseguire comandi che non comprendono e di non utilizzare i file scaricati in situazioni in cui non sarebbero in grado di spiegare perché è ragionevolmente sicuro farlo. Ma include anche cose come fare backup, in modo che se qualcosa va storto (a causa di malware o altro), il danno arrecato sarà il meno possibile.

SÌ ^*

Si chiama shell ristretta.

Puoi usarlo /bin/rbash, che è già disponibile in Ubuntu e combinarlo con una variabile PATH limitata . Il rbashvieterà esecuzione da tutto ciò che non è in $PATH.

Aggiungi un utente con restrizioni:

sudo adduser --shell /bin/rbash res-user

Crea una nuova directory, in cui possiamo collegare i binari, a cui l'utente sarà limitato:

sudo mkdir /home/res-user/bin

Modifica il .profilefile:

sudo vim /home/res-user/.profile

if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then
        . "$HOME/.bashrc"
    fi
fi

readonly PATH=/home/res-user/bin
export PATH

Rendere il .profile, bashrce .bash_profileimmutabili:

sudo chattr +i /home/res-user/.profile
sudo chattr +i /home/res-user/.bashrc
sudo chattr +i /home/res-user/.bash_profile

Ora diamo all'utente l'unica cosa che gli sarà permesso di fare, ovvero aprire Firefox:

sudo ln -s /usr/lib/firefox/firefox /home/res-user/bin/

Ora, se effettuiamo l'accesso poiché res-userpossiamo solo aprire Firefox:

res-user@localhost:~$ /home/res-user/bin/firefox --version
Mozilla Firefox 68.0.1

Non possiamo facilmente sfuggire al nostro guscio limitato:

res-user@localhost:~$ export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
-su: PATH: readonly variable

L'utente con restrizioni non può rendere eseguibili i file o avviarli:

res-user@localhost:~$ chmod +x script.sh 
Command 'chmod' is available in '/bin/chmod'
res-user@localhost:~$ bash script.sh 
Command 'bash' is available in '/bin/bash'
The command could not be located because '/bin' is not included in the PATH environment variable.
bash: command not found

L'utente con restrizioni non può eseguire script malevoli da Internet, poiché l'utente non può eseguire i comandi necessari:

res-user@localhost:~$ wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh | bash
Command 'wget' is available in '/usr/bin/wget'
The command could not be located because '/usr/bin' is not included in the PATH environment variable.
wget: command not found
Command 'bash' is available in '/bin/bash'
The command could not be located because '/bin' is not included in the PATH environment variable.
bash: command not found

^* _{Esistono modi per uscire da shell ristrette , ma se l'utente è in grado di farlo, potrebbero non essere creduloni come pensi.}