Czy jest jakiś sposób, aby powstrzymać użytkownika przed tworzeniem plików wykonywalnych i uruchamianiem ich?

Ataki ransomware mogą wykorzystywać exploity zero-day, ale często atakujący oszuka łatwowiernego użytkownika, aby uruchomił plik wykonywalny, pobierając i klikając.

Załóżmy, że mamy naiwnego użytkownika i chcemy ograniczyć go do normalnej ścieżki. Czy istnieje sposób, aby ograniczyć ich tworzenie pliku z uprawnieniami do wykonywania?

Lub, bardziej ogólnie, czy jest jakiś sposób na zbudowanie listy kontroli dostępu i zdefiniowanie, że ten użytkownik może wykonywać tylko pliki z tej listy?

Konkretny atak, na który wyraziłeś obawy, to:

często osoba atakująca oszuka po prostu łatwowiernego użytkownika, aby uruchomił plik wykonywalny, pobierając i klikając.

Przynajmniej w powszechnym przypadku, gdy plik jest pobierany w przeglądarce internetowej, powinno się temu już zapobiegać w Ubuntu przez przestrzeganie przez przeglądarkę zasad Wymaganego bitu wykonania. Najbardziej bezpośrednio odpowiednie części tej polityki to:

• Aplikacje, w tym komputery stacjonarne i powłoki, nie mogą uruchamiać kodu wykonywalnego z plików, gdy oba są:

  • brakuje bitu wykonywalnego
  • znajduje się w katalogu domowym użytkownika lub katalogu tymczasowym.

• Pliki pobrane z przeglądarki internetowej, klienta poczty itp. Nigdy nie mogą być zapisywane jako pliki wykonywalne.

Jeśli więc użytkownik zostanie poproszony o pobranie programu z przeglądarki internetowej, zrobi to i spróbuje uruchomić plik, klikając go dwukrotnie, nie uruchomi się. Odnosi się to nawet, jeśli pobrany plik jest skryptem powłoki, a nawet plikiem .desktop. (Jeśli kiedykolwiek zastanawiałeś się, dlaczego pliki .desktop w katalogu domowym muszą być oznaczone jako pliki wykonywalne, mimo że tak naprawdę nie są programami, właśnie dlatego).

Użytkownicy mogą zmienić to zachowanie poprzez zmiany konfiguracji. Większość tego nie zrobi i chociaż ci, którzy prawdopodobnie tego nie zrobią, nie powinniście się tak naprawdę martwić. Większy problem dotyczy bardziej złożonego ataku, o którym myślę, że już się martwisz, w którym złośliwa osoba (lub bot) instruuje użytkownika, aby pobrał określony plik, oznaczył go jako wykonywalny (przez przeglądarkę plików lub za pomocą chmod) i następnie uruchom to.

Niestety ograniczenie zdolności użytkownika do ustawienia bitu wykonania pliku lub wykonywania plików innych niż te z białej listy nie zmniejszy zauważalnie problemu. Niektóre ataki już działają, a te, których nie można w prosty sposób zmodyfikować, aby działały. Podstawową kwestią jest to, że efekt uruchomienia pliku można uzyskać, nawet jeśli plik nie ma uprawnień do wykonywania .

Najlepiej ilustruje to przykład. Załóżmy, że eviljest to plik w bieżącym katalogu, który, gdyby otrzymał uprawnienia do wykonywania ( chmod +x evil) i run ( ./evil), zrobiłby coś złego. W zależności od rodzaju programu ten sam efekt można osiągnąć, wykonując jedną z następujących czynności:

• . ./evillub source ./eviluruchamia polecenia w evil aktualnie uruchomionej powłoce .
• bash ./evilbiegnie evilw bash.
• python3 evilbiegnie evilw python3.
• perl evilbiegnie evilw perl.
• ... i ogólnie interpreter evildziała evilw tłumaczu interpreter .
• W większości systemów /lib64/ld-linux-x86-64.so.2 ./evil uruchamia binarny plik wykonywalny evil .

Żadna z nich, nawet ostatnia, nie wymaga, aby plik miał uprawnienia do wykonywania, ani nawet aby użytkownik mógł nadać temu plikowi uprawnienia.

Ale złośliwe instrukcje nie muszą nawet być tak skomplikowane. Rozważ to niezłośliwe polecenie, które jest jednym z oficjalnie zalecanych sposobów instalacji lub aktualizacji NVM :

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

Powodem, dla którego nie jest złośliwy, jest to, że NVM nie jest złośliwym oprogramowaniem, ale jeśli adres URL byłby zamiast skryptu, który wywołuje zło po uruchomieniu, polecenie to pobrałoby i uruchomiło skrypt. W żadnym momencie żaden plik nie musiałby mieć uprawnień do wykonywania. Pobieranie i uruchamianie kodu zawartego w złośliwym pliku za pomocą jednego polecenia tego typu jest, jak sądzę, dość częstym działaniem, które atakujący nakłaniają użytkowników do podjęcia.

Możesz pomyśleć o ograniczeniu dostępnych tłumaczy do uruchomienia przez użytkowników. Ale tak naprawdę nie ma sposobu, aby to zrobić, który nie wpływa znacząco na zwykłe zadania, które prawdopodobnie chcesz, aby użytkownicy mogli wykonywać. Jeśli konfigurujesz bardzo ograniczone środowisko, w którym prawie wszystko, co użytkownik chciałby zrobić na komputerze, jest niedozwolone, na przykład kiosk, w którym działa tylko kilka programów, może to zapewnić pewną ochronę. Ale to nie brzmi tak, jakby to był twój przypadek użycia.

Przybliżona odpowiedź na twoje pytanie brzmi: „Nie”. Pełniejsza odpowiedź jest taka, że prawdopodobnie uda Ci się uniemożliwić użytkownikom wykonywanie jakichkolwiek plików oprócz tych, które podajesz na białej liście. Ale to w ścisłym technicznym sensie słowa „wykonaj”, które nie jest potrzebne do osiągnięcia pełnego efektu działania większości programów lub skryptów. Aby zapobiec które , można spróbować zrobić whitelist bardzo mały, więc nie są wyświetlane żadne ustne z wyjątkiem tych, które mogą być bardzo ograniczone. Ale nawet jeśli ci się to udało, użytkownicy nie mogliby wiele zrobić, a jeśli uczynisz to tak małym, że nie mogliby się zranić, prawdopodobnie nie mogliby nic zrobić. (Zobacz komentarz Thomasa Warda ).

Jeśli twoi użytkownicy mogą się zranić, mogą zostać oszukiwani, by się zranić.

Możesz być w stanie ograniczyć używanie określonych programów lub w inny sposób zachowywać się w sposób, który może być szkodliwy, a jeśli patrzysz na określone wzorce, które ransomware zwykle stosuje, możesz być w stanie zapobiec niektórym konkretnym częstym przypadkom. (Zobacz AppArmor .) To może zapewnić pewną wartość. Ale nie da ci nic bliskiego kompleksowemu rozwiązaniu, na które liczysz.

Bez względu na to, jakie środki techniczne (jeśli w ogóle zastosujesz), najlepszym rozwiązaniem jest edukacja użytkowników. Obejmuje to nakazanie im, aby nie wykonywali poleceń, których nie rozumieją, i nie używali pobranych plików w sytuacjach, w których nie byliby w stanie wyjaśnić, dlaczego jest to wystarczająco bezpieczne. Ale obejmuje to również tworzenie kopii zapasowych, więc jeśli coś pójdzie nie tak (z powodu złośliwego oprogramowania lub w inny sposób), wyrządzone szkody będą tak małe, jak to możliwe.

TAK ^*

Nazywa się to ograniczoną powłoką.

Możesz użyć /bin/rbash, który jest już dostępny w Ubuntu i połączyć to z ograniczoną zmienną PATH . rbashZakaże wykonanie od wszystkiego, co nie jest $PATH.

Dodaj użytkownika z ograniczeniami:

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

Utwórz nowy katalog, w którym będziemy mogli łączyć pliki binarne, w których użytkownik będzie ograniczony do:

sudo mkdir /home/res-user/bin

Zmodyfikuj .profileplik:

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

Uczynić .profile, bashrci .bash_profileniezmienne:

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

Teraz dajemy użytkownikowi jedyną rzecz, na jaką będzie mógł zrobić, tj. Otwórz Firefox:

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

Teraz, jeśli się zalogujemy res-user, możemy otworzyć tylko Firefoksa:

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

Nie możemy łatwo uciec z naszej ograniczonej powłoki:

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

Użytkownik z ograniczonym dostępem nie może uruchomić plików ani uruchomić ich:

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

Użytkownik z ograniczonym dostępem nie może wykonywać złych skryptów z Internetu, ponieważ użytkownik nie może wykonać niezbędnych poleceń:

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

^* _{Istnieją sposoby na wyrwanie się z ograniczonych powłok , ale jeśli twój użytkownik jest w stanie to zrobić, może nie być tak łatwowierny, jak myślisz.}