Inwigilacja połączeń SSH za pomocą strace
Napisał: Patryk Krawaczyński
12/11/2016 w Bezpieczeństwo 1 komentarz. (artykuł nr 573, ilość słów: 1003)
T
o, że używamy SSH do połączeń z serwerami nie oznacza, że możemy czuć się bezpiecznie. Szczególnie musimy uważać na te maszyny, którymi zarządzają niezaufane osoby. Dlaczego? Ponieważ odczyt niezaszyfrowanych danych w systemie można wykonać na różnych poziomach dostępu. Za przykład weźmy wywołanie ptrace, które jest używane do monitoringu i kontroli innych procesów. Głównie jest używane do debugowania, a chyba najpopularniejszym programem wykorzystującym jego możliwości jest strace.
Klient i serwer SSH używają różnych wywołań systemowych do odczytu danych od użytkownika i przekazywaniu ich na ekran. Na przykład możemy przeczytać, co dokładnie użytkownik wpisuje do klienta SSH poprzez połączenie się strace
do procesu i szukaniu wywołań read(#, "[dane]", 16384)
. Natomiast od strony serwera SSH musimy się skupić na przefiltrowaniu write(#, "[dane]", 1)
. Wyobraźmy sobie, że właśnie nasz serwer został przejęty przez agresora. Bardzo rzadko wykorzystujemy na nim konto administratora, ale bardzo często łączymy się z niego do innych serwerów, które ufają tylko naszej maszynie. Przychodzi dzień, w którym ponownie musimy zalogować się z swojego serwera do innego. Jak taka sytuacja może wyglądać od strony atakującego, który właśnie przygląda się nam z ukrycia? Na początek identyfikuje, do którego procesu musi wpiąć się programem strace
:
root@darkstar:~# ps -fC sshd UID PID PPID C STIME TTY TIME CMD root 1014 1 0 Nov11 ? 00:00:00 /usr/sbin/sshd -D root 2384 1014 0 Nov11 ? 00:00:00 sshd: darkstar [priv] darkstar 2414 2384 0 Nov11 ? 00:00:08 sshd: darkstar@pts/0,pts/1
Wybiera numer procesu: 2414, aby podsłuchać naszą konsolę:
strace -p 2414 -e write 2>&1 | egrep "^write(.*1)$"
Jak tylko zaczniemy wpisywać polecenia w naszej powłoce na ekranie napastnika pojawią się pojedyncze znaki wychwycone z wywołań systemowych:
write(10, "s", 1) = 1 write(10, "s", 1) = 1 write(10, "h", 1) = 1 write(10, " ", 1) = 1 write(10, "s", 1) = 1 write(10, "t", 1) = 1 write(10, "a", 1) = 1 write(10, "r", 1) = 1 write(10, "g", 1) = 1 write(10, "a", 1) = 1 write(10, "t", 1) = 1 write(10, "e", 1) = 1 write(10, ".", 1) = 1 write(10, "n", 1) = 1 write(10, "f", 1) = 1 write(10, "s", 1) = 1 write(10, "e", 1) = 1 write(10, "c", 1) = 1 write(10, ".", 1) = 1 write(10, "p", 1) = 1 write(10, "l", 1) = 1
Później pozostaje już tylko przechwycenie hasła i innych wrażliwych danych. Atakujący nie musi nawet zapisywać tych danych do pliku na przechwyconym serwerze, aby pozostawić ślady. Wystarczy, że będzie, co jakiś czas wykonywał zrzuty ekranu lub logowanie sesji odbędzie się z poziomu programu uruchomionego na jego komputerze.
Jeśli jesteśmy administratorami serwerów ataki tego typu możemy złagodzić poprzez wyłączenie ptrace – nie tylko, aby wykluczyć padnięcie ofiarą własnej maszyny, ale aby również być fair wobec własnych użytkowników. Jako klienci możemy również sprawdzać ustawienia danego serwera pod względem polityki wykorzystania ptrace, ale przede wszystkim musimy być zawsze świadomi możliwości podsłuchu używając niezaufanego systemu.
Więcej informacji: Spying on ssh with strace, Poor man’s SSH keylogger, strace keylogger
Analogiczną funkcjonalność możemy również osiągnąć poprzez sysdig:
Tylko w tym przypadku ustawienie
kernel.yama.ptrace_scope
na wartość 3 nie ochroni systemu przed podsłuchem, ponieważ sysdig nie korzysta z ptrace.