Zapobieganie wąchaniu hasła sudo przez złośliwe oprogramowanie

Często słyszę ludzi powołujących się sudona jedną z głównych barier przed złośliwym oprogramowaniem infekującym komputer z systemem Linux.

Najczęstszy argument wydaje się przebiegać w następujący sposób: Do zmodyfikowania konfiguracji systemu wymagane są uprawnienia rootowania, a do uzyskania uprawnień roota wymagane jest hasło, więc złośliwe oprogramowanie nie może modyfikować konfiguracji systemu bez pytania o hasło.

Wydaje mi się jednak, że domyślnie w większości systemów, gdy złośliwe oprogramowanie zainfekuje konto administratora, eskalacja uprawnień jest banalna - szkodliwe oprogramowanie musi tylko poczekać na uruchomienie użytkownika sudo.

Jakie metody istnieją, aby złośliwe oprogramowanie zdobywało uprawnienia root'a podczas uruchamiania użytkownika sudoi jak możemy się przed nim chronić?

Edycja: Jestem szczególnie zainteresowany ochroną przed zainfekowanym kontem administratora; to znaczy konto, które ma pełne uprawnienia roota sudo(np. konto użytkownika w typowym systemie komputerowym).

Gdy kawałek złośliwego oprogramowania uzyska dostęp do konta użytkownika, może:

1. Utwórz alias bash (w bieżącej powłoce i in ~/.bashrc) dla polecenia, które podszywa się pod [sudo] password for $USER:monit i kradnie hasło użytkownika.

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

2. Podobnie może umieścić plik wykonywalny o nazwie sudow ~/.bini zmodyfikować PATHzmienną, aby osiągnąć ten sam efekt:PATH="$HOME/.bin:$PATH"

3. Złap naciśnięcia klawiszy przez serwer X, wypatruj słowa sudo, a następnie wypróbuj tekst między kolejnymi dwoma Enternaciśnięciami klawiszy jako hasło.

4. Podobne działanie można wykonać w dowolnym środowisku (konsola, Wayland , X) przy użyciu np $LD_PRELOAD.

5. Jeśli złośliwe oprogramowanie zainfekuje powłokę, która używa sudoi sudobuforuje dane uwierzytelniające, złośliwe oprogramowanie może stale sprawdzać, czy jest możliwe sudobez hasła:

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

Zapobieganie:

1 i 2. Użyj \/bin/sudo. \Ignoruje aliasy i /bin/…ignoruje $PATH. Alternatywnie dodaj alias, taki jak: ssudo="\/bin/sudo"i zawsze używaj ssudozamiast sudo. Wydaje się mało prawdopodobne, aby wirus był wystarczająco sprytny, aby zmienić mapowanie tego aliasu.

3. Unikaj wpisywania hasła podczas korzystania z X11. Zamiast tego użyj wirtualnej konsoli lub Westona .

5. Ustaw timestamp_timeout=0w /etc/sudoers.

Wydaje się, że jedynym sposobem na całkowite wyeliminowanie szansy na sudowąchanie hasła jest całkowite uniknięcie go. Zamiast tego zaloguj się jako root do wirtualnej konsoli.

Według Aleksandra Peslyaka : „jedynym bezpiecznym zastosowaniem dla su [i sudo] jest przejście z konta uprzywilejowanego na konto mniej uprzywilejowane…”

Na marginesie, sudo ma pewne środki zaradcze:

• sudoczyta ttyzamiast stdin, więc alias sudo='tee -a /tmp/sudo-password | sudo'łamie się sudo(ale przechwytuje hasło).

Nie ma prawdziwej ochrony.

Chroniony hasłem dostęp do sudo powraca do epoki przed złożonymi środowiskami powłoki z poleceniami wykonywanymi przez podkładki. Po przesłaniu hasła pojawi się okno, w którym shim może wykonywać polecenia za pośrednictwem sudo, bez powiadomienia i przy pełnej kontroli systemu.

Gdybym chciał uzyskać dostęp, stworzyłbym użyteczny shim dla bash, zsh i fish itp. Monitorowałbym wykonywane polecenia. Wkrótce po powrocie sudo ze statusem zero zacznę wydawać „sudo chmod + s / bin / sh” lub inne nieprzyjemne rzeczy.

W momencie, gdy sudo otrzyma zadowalające hasło i masz powłoki, które uruchamiają polecenia w celu wyświetlenia monitu, możesz mieć kłopoty. Nie ma żadnej ochrony poza optymizmem.

Inne odpowiedzi dotyczyły ochrony hasła. Jako agresor nie martwiłbym się tym. Skoncentruję się na czasie po podaniu hasła, gdy hasło nie jest potrzebne. To najbardziej ryzykowny czas, kiedy atakujący musi zrobić wszystko, aby całkowicie skompromitować system.

Chronisz się przed tym? Musisz chronić swoje pliki RC. Sprawdź wszelkie podkładki dystansowe lub inne polecenia używane w wierszach polecenia. Poszukaj koprocesów połączonych z powłoką i narzędzi używanych do utrzymania środowiska powłoki. Główną obroną byłyby narzędzia intruzów hosta, ale to już po fakcie. Zapobieganie atakom? Używanie tylko prostych powłok bez skomplikowanej automatycznej konfiguracji i aktywnych monitów - to środowisko, dla którego opracowano sudo.

Kiedyś grałem w gry z innymi programistami (lata 80-te), w których próbowaliśmy pisać rzeczy, które otrzymywałyby terminal, którego używał inny programista, do wstawiania poleceń - to w zasadzie ten sam problem. Ułatwiliśmy też osadzanie narzędzi, które wstawiałyby polecenia bez widocznego śladu. :)

Nie wiesz, o wszelkich metod nieupoważnionych użytkowników do uprawnieniami roota zysk, ale wiem, że coś można zrobić, aby nieco mniej niebezpieczne , jeśli chcesz powiedzieć. umożliwia skonfigurowanie szczegółowych uprawnień w celu zdefiniowania grup użytkowników z określonymi uprawnieniami oraz określonych poleceń, które mogą być uruchamiane przez niektórych użytkowników.sudosudo

SUDO - KONTROLA GRANULARNA

• Sekcja użytkownika

  W tym miejscu możesz skonfigurować grupy dla użytkowników, dla których określisz polecenia. Pozwala skonfigurować grupę operacji;

  User_Alias  OPS = bob, jdoe 
  

  Tworzy to grupę OPS i umieszcza w niej użytkowników o nazwach bob i jdoe

• Cmnd_Alias

  Tutaj określamy określone zestawy poleceń. Musisz podać pełną ścieżkę i wszelkie opcje polecenia, które chcesz zastosować. Pozwala skonfigurować polecenia grupy Operacje;

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

  Spowoduje to dodanie trzech określonych poleceń do grupy poleceń OPSCMD.

• Specyfikacja uprawnień użytkownika

  Tutaj będziemy korzystać z grup, które do tej pory konfigurowaliśmy;

  OPS  ALL=(root)  OPSCMD 
  

  Najpierw określamy użytkowników, tutaj używamy grupy OPS, którą konfigurujemy. Wtedy WSZYSTKO oznacza, że ​​ma zastosowanie do wszystkich serwerów, jest to przydatne tylko wtedy, gdy korzystasz z sudo na wielu serwerach, z których każdy używa tego samego pliku konfiguracyjnego. Następnie określamy użytkownika, że ​​grupa Operacje uruchomi określone polecenia, ponieważ w tym przypadku chcemy, aby działały one jako root. Na koniec określamy polecenia, które chcemy, aby grupa OPS mogła być uruchomiona, w szczególności używamy skonfigurowanej grupy OPSCMD. Jeśli nie chcesz, aby wprowadzali hasło za każdym razem, gdy korzystali z sudo, wówczas specyfikacją polecenia będzie NOPASSWD: OPSCMD.

Po prostu zaostrz swoje sudozasady, tak jak nie ufasz użytkownikom :)

Jeśli jesteś zainteresowany systemem, który Twoim zdaniem może być zagrożony, uruchom „Rootkit” i użyj „Tripwire”, aby sprawdzić integralność systemu plików.

Radziłbym również zaostrzyć uprawnienia sudo, ponieważ nie wszyscy użytkownicy mają dostęp do wszystkich poleceń root, a raczej dają dostęp do określonych poleceń za pośrednictwem SUDO.

Przede wszystkim spójrz na /etc/sudoersplik.

Składnia będzie miała user MACHINE=COMMANDSformat.

Na przykład użytkownik root będzie miał root ALL=(ALL) ALL Oznacza to, że użytkownik root może uruchamiać dowolne (wszystkie) polecenia w dowolnym miejscu.

Jeśli twój wpis również, oznacza ALL=(ALL)to, że jesteś prawie równy użytkownikowi root. Jeśli tak nie jest i masz tylko pewne ograniczone uprawnienia, atakujący / złośliwe oprogramowanie może zrobić tylko tyle, ile może zrobić twoje uprawnienie sudo.

Wskazówki, które mogą Ci pomóc:

1. Sprawdź swój /etc/sudoersplik.
2. Uruchom skaner bezpieczeństwa, taki jak chkrootkit, rootkit hunter, Config server Scanner Exploit, snort itp.
3. Użyj visudopolecenia, aby edytować i modyfikować uprawnienia do pliku sudoers.
4. Uruchom skanery ponownie.

Referencje: strona man sudoers i Linux z sudo sudoers człowieka