Gibt es eine Möglichkeit, einen Benutzer daran zu hindern, ausführbare Dateien zu erstellen und auszuführen?

Ransomware-Angriffe könnten Zero-Day-Exploits verwenden, aber oft täuscht ein Angreifer einen leichtgläubigen Benutzer nur durch Herunterladen und Klicken zum Ausführen einer ausführbaren Datei.

Angenommen, wir haben einen naiven Benutzer und möchten ihn auf den normalen Pfad beschränken. Gibt es eine Möglichkeit, sie daran zu hindern, eine Datei mit ausführbaren Rechten zu erstellen?

Oder gibt es generell eine Möglichkeit, eine Zugriffssteuerungsliste zu erstellen und zu definieren, dass dieser Benutzer nur Dateien in dieser Liste ausführen darf?

Der spezifische Angriff, über den Sie Bedenken geäußert haben, ist:

Häufig täuscht ein Angreifer einen leichtgläubigen Benutzer lediglich durch Herunterladen und Klicken zum Ausführen einer ausführbaren Datei.

Zumindest in dem üblichen Fall, in dem die Datei in einem Webbrowser heruntergeladen wird, sollte dies in Ubuntu bereits verhindert werden, indem der Browser die Richtlinie Execute-Permission Bit Required einhält. Die direktesten relevanten Teile dieser Richtlinie sind:

• Anwendungen, einschließlich Desktops und Shells, dürfen keinen ausführbaren Code aus Dateien ausführen, wenn es sich um beides handelt:

  • Es fehlt das ausführbare Bit
  • befindet sich im Home-Verzeichnis eines Benutzers oder im temporären Verzeichnis.

• Dateien, die von einem Webbrowser, einem E-Mail-Client usw. heruntergeladen wurden, dürfen niemals als ausführbar gespeichert werden.

Wenn ein Benutzer also aufgefordert wird, ein Programm in einem Webbrowser herunterzuladen, und versucht, die Datei durch Doppelklicken auszuführen, wird sie nicht ausgeführt. Dies gilt auch dann, wenn die heruntergeladene Datei ein Shell-Skript oder sogar eine .desktop-Datei ist. (Wenn Sie sich jemals gefragt haben, warum .desktop-Dateien in Ihrem Home-Verzeichnis als ausführbar markiert werden müssen, obwohl es sich nicht wirklich um Programme handelt, ist dies der Grund.)

Benutzer können dieses Verhalten durch Konfigurationsänderungen ändern. Die meisten werden es nicht, und diejenigen, die es tun, sollten es wahrscheinlich auch nicht, aber darum müssen Sie sich nicht wirklich sorgen. Das größere Problem ist der komplexere Angriff, über den Sie sich Ihrer Meinung nach bereits Sorgen machen, bei dem eine böswillige Person (oder ein Bot) den Benutzer anweist, eine bestimmte Datei herunterzuladen, sie selbst als ausführbar zu markieren (über ihren Dateibrowser oder mit chmod) und dann starte es.

Leider würde die Einschränkung der Fähigkeit eines Benutzers, das Ausführungsbit für eine Datei zu setzen oder andere Dateien als die auf einer Whitelist auszuführen, das Problem nicht merklich mindern. Einige Angriffe werden bereits funktionieren, und diejenigen, die nicht einfach geändert werden können, tun dies. Das grundlegende Problem besteht darin, dass der Effekt des Ausführens einer Datei auch dann erzielt werden kann , wenn die Datei keine ausführbaren Berechtigungen besitzt .

Dies lässt sich am besten anhand eines Beispiels veranschaulichen. Angenommen, es evilhandelt sich um eine Datei im aktuellen Verzeichnis, die bei Angabe der ausführbaren Berechtigungen ( chmod +x evil) und von run ( ./evil) etwas Böses bewirken würde. Je nachdem, um welche Art von Programm es sich handelt, kann der gleiche Effekt durch eine der folgenden Methoden erzielt werden:

• . ./eviloder source ./evilführt die Befehle evil in der aktuell ausgeführten Shell aus .
• bash ./evilläuft evilein bash.
• python3 evilläuft evilein python3.
• perl evilläuft evilein perl.
• ... und interpreter evilläuft generell evilim Interpreter interpreter .
• Auf den meisten Systemen wird /lib64/ld-linux-x86-64.so.2 ./evil die ausführbare Binärdatei ausgeführt evil .

Keiner von denen, auch nicht die letzten, verlangt , dass die ausführbare Datei Berechtigungen oder sogar , dass der Benutzer sein kann der ausführbare Datei Berechtigungen geben.

Aber die böswilligen Anweisungen müssen nicht einmal so kompliziert sein. Betrachten Sie diesen nicht böswilligen Befehl, der eine der offiziell empfohlenen Methoden zum Installieren oder Aktualisieren von NVM ist :

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

Der Grund, der nicht böswillig ist, ist, dass NVM keine Malware ist. Wenn die URL jedoch zu einem Skript führt, das bei der Ausführung böse ist, wird das Skript mit diesem Befehl heruntergeladen und ausgeführt. Zu keinem Zeitpunkt müsste eine Datei ausführbare Berechtigungen erhalten. Das Herunterladen und Ausführen des in einer schädlichen Datei enthaltenen Codes mit einem einzigen Befehl wie diesem ist meines Erachtens eine ziemlich häufige Aktion, bei der Angreifer die Benutzer dazu verleiten.

Sie könnten versuchen, die verfügbaren Interpreter für die Benutzer einzuschränken. Es gibt jedoch keine Möglichkeit, dies zu tun, die sich nicht wesentlich auf die normalen Aufgaben auswirkt, zu denen Benutzer voraussichtlich in der Lage sein sollen. Wenn Sie eine extrem eingeschränkte Umgebung einrichten, in der fast alles, was ein Benutzer auf einem Computer tun möchte, unzulässig ist, z. B. ein Kiosk, auf dem nur einige Programme ausgeführt werden, bietet dies möglicherweise ein gewisses Maß an sinnvollem Schutz. Aber es hört sich nicht so an, als wäre es Ihr Anwendungsfall.

Die ungefähre Antwort auf Ihre Frage lautet "Nein". Die umfassendere Antwort lautet, dass Sie möglicherweise verhindern können, dass Benutzer Dateien ausführen, die nicht auf einer Whitelist aufgeführt sind. Dies ist jedoch im strengen technischen Sinne von "Ausführen" zu verstehen, der nicht erforderlich ist, um den vollen Effekt der Ausführung der meisten Programme oder Skripte zu erzielen. Um zu verhindern , dass , könnten Sie versuchen , die Whitelist sehr klein zu machen, so hat es keine Dolmetscher mit Ausnahme derjenigen , auflisten , die stark eingeschränkt werden könnte. Aber selbst wenn Sie das geschafft haben, konnten Benutzer nicht viel tun, und wenn Sie es so klein gemacht haben, dass sie sich nicht selbst verletzen konnten, konnten sie wahrscheinlich nichts tun. (Siehe Thomas Wards Kommentar .)

Wenn Ihre Benutzer sich selbst verletzen können, können sie dazu verleitet werden, sich selbst zu verletzen.

Möglicherweise können Sie verhindern, dass bestimmte Programme verwendet werden oder sich auf andere Weise schädlich verhalten. Wenn Sie sich bestimmte Muster ansehen, denen Ransomware tendenziell folgt, können Sie möglicherweise bestimmte häufige Fälle verhindern. (Siehe AppArmor .) Dies könnte einen gewissen Wert liefern. Aber es gibt Ihnen nichts, was der von Ihnen erhofften umfassenden Lösung nahe kommt.

Unabhängig von den technischen Maßnahmen (falls vorhanden), die Sie am Ende ergreifen, ist es am besten, die Benutzer zu schulen. Dazu gehört, dass sie keine Befehle ausführen, die sie nicht verstehen, und keine heruntergeladenen Dateien in Situationen verwenden, in denen sie nicht erklären können, warum dies einigermaßen sicher ist. Aber es beinhaltet auch Dinge wie das Erstellen von Backups, sodass der Schaden so gering wie möglich ist, wenn etwas schief geht (aufgrund von Malware oder auf andere Weise).

JA ^*

Es heißt eine eingeschränkte Shell.

Sie können verwenden /bin/rbash, was bereits in Ubuntu verfügbar ist, und dies mit einer eingeschränkten PATH-Variablen kombinieren . Das rbashwird die Ausführung von allem verbieten, was nicht drin ist $PATH.

Hinzufügen eines eingeschränkten Benutzers:

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

Erstellen Sie ein neues Verzeichnis, in das Binärdateien eingebunden werden können, auf die der Benutzer beschränkt ist:

sudo mkdir /home/res-user/bin

Ändern Sie die .profileDatei:

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

Machen Sie das .profile, bashrcund .bash_profileunveränderlich:

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

Jetzt geben wir dem Benutzer das Einzige, was er tun darf, nämlich Firefox öffnen:

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

Wenn wir res-useruns jetzt anmelden , können wir nur Firefox öffnen:

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

Wir können uns unserer eingeschränkten Hülle nicht leicht entziehen:

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

Der eingeschränkte Benutzer kann keine Dateien ausführbar machen oder starten:

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

Der eingeschränkte Benutzer kann keine bösen Skripte aus dem Internet ausführen, da der Benutzer die erforderlichen Befehle nicht ausführen kann:

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

^* _{Es gibt Möglichkeiten, aus eingeschränkten Shells auszubrechen , aber wenn Ihr Benutzer dazu in der Lage ist, sind sie möglicherweise nicht so leichtgläubig, wie Sie denken.}