Jak powinienem debugować błąd „Nie można pobrać klawiatury. Złośliwy klient może podsłuchiwać sesję. ”

Korzystam z instalacji systemu Ubuntu 14.04, którą skonfigurowałem na ponad 6 miesięcy. Mniej więcej tydzień temu zacząłem otrzymywać komunikat o błędzie:

Could not grab keyboard. A malicious client may be eavesdropping on your session.

Widziałem to tylko po powrocie do komputera po dłuższej nieobecności (zwykle z dnia na dzień). Kilka razy zapobiegało to blokowaniu ekranu po upływie określonego czasu (zacząłem aktywnie blokować go przed wyjściem).

Używam klawiatury USB (Kinesis Advantage) bezpośrednio podłączonej do portu USB na płycie głównej. Używam bezprzewodowej myszy ELECOM .

Przed wyjściem spróbuję odłączyć klucz myszy. Jak inaczej mogę sprawdzić, czy złośliwy klient śledzi moje naciśnięcia klawiszy lub czy jest to problem z łącznością?

Oto jak rozwiązać swoją tajemnicę. Celem jest raczej nauczenie użytkowników „jak łowić ryby” za pomocą standardowych narzędzi Ubuntu do zagłębiania się w szczegóły dowolnego procesu w ich systemie.

Krok # 1 (głównie z ciekawości): określ, który program wyświetla ten błąd:

# -- You may need to search under more dirs, YMMV
#    List files (incl. binaries) which contain the warning string

$ sudo grep -ral 'malicious client may be eavesdropping' /usr /bin /lib
/usr/lib/openssh/gnome-ssh-askpass

W mojej env jedynym programem, który zawiera ten ciąg ostrzegawczy w swoim pliku binarnym, jest gnome-ssh-askpass. Mogę wyszukać, czy w tym konkretnym programie jest zgłoszony błąd, a nawet pobrać jego źródło apt-get source ssh-askpass-gnome(zauważ, że nazwa pakietu jest inna niż nazwa programu) w celu dalszej kontroli.

Podejrzewam jednak, że podstawowa przyczyna nie stanowi problemu gnome-ssh-askpass. Ponieważ gnome-ssh-askpassprosi o podanie hasła, jego twórcy po prostu wybrali ostrożność, jeśli nie złapali klawiatury, przyjęli najgorszy scenariusz i sprawili, że wiadomość brzmiała uber-paranoidalnie. Pamiętaj jednak, że wpisanie hasła lub hasła w przypadkowym oknie dialogowym strony internetowej prawdopodobnie nie jest dobrym pomysłem, więc w tym sensie gnome-ssh-askpassprogramiści wykonali prawidłowe połączenie.

Ostatnio coraz więcej stron internetowych zaczęło angażować się w wyświetlanie wyskakujących okienek, zanikanie wszystkiego poza oknem wyskakującym i agresywne przyciąganie uwagi. Może to być podstawowa przyczyna gnome-ssh-askpassniepowodzenia pobierania klawiatury. Jeśli przeglądarka jest otwarta na takiej stronie, pomocne może być jej zamknięcie lub odejście od agresywnej strony internetowej. Jeśli jest to przyczyną, możesz zainteresować się ustawieniem pulpitu, które uniemożliwi pojedynczym procesom przechwycenie całego (pełnego pulpitu) fokusa. Na przykład w KDE to ustawienie można znaleźć w ( Ustawienia systemu -> Zachowanie okna -> Ostrość -> Zapobieganie kradzieży ostrości ). Jeśli czujesz się naprawdę paranoikiem, polecam ustawienie go na Highlub Extreme. Oczywiście może to również zapobiecgnome-ssh-askpasssam z chwytania klawiatury, a ściślej: chwytanie Xostrości.

Krok # 2: Zidentyfikuj podejrzane procesy:

Wiedząc, że w systemie Unix urządzenia wyglądają jak pliki po użyciu /dev, następne pytanie brzmi, które urządzenie reprezentuje „klawiaturę” w hierarchii systemu plików. W tym celu możemy użyć narzędzia lsof(wyświetl listę otwartych plików).

# look for processes holding devices open, filter out some common ones:
$ sudo lsof | grep /dev | grep -vE '/(null|urandom|zero)'

Zauważ, że większość procesów utrzymujących urządzenia otwarte w typowym środowisku komputerowym trzyma /dev/pts/<N>( pseudo tty ) otwarte. Są to „urządzenia” będące przedmiotem zainteresowania.

Na typowym graficznym pulpicie systemu Linux procesy nie komunikują się bezpośrednio z klawiaturą. Zamiast tego Xprogram (Xorg) kontroluje wszystkie zdarzenia klawiatury za pomocą urządzenia /dev/input/event<N>. Xużywa modułu obsługi zdarzeń (evdev), który między innymi obsługuje zdarzenia klawiatury. Możesz to również sprawdzić, patrząc na Xdziennik: /var/log/Xorg.0.loggdzie keyboardjest wspomniany.

Zdarzenia na klawiaturze są przekazywane z Xprocedury obsługi zdarzeń do procesu, który skupia wskaźnik myszy w dowolnym momencie, poprzez standardowe wejście procesu, które jest otwarte /dev/pts/<N>. Ściśle mówiąc: proces tak naprawdę nie „chwyta klawiatury”, klawiatura jest utrzymywana X, proces ma tylko (lub chwyta) „skupienie” lub uwagę, Xdzięki czemu Xmoże przekazywać do niego zdarzenia klawiatury poprzez otwarty deskryptor pliku stdin na /dev/pts/<N>.

Krok # 3: na którym procesie Xorg koncentruje się w danym momencie?

Jak obliczyć, na którym procesie koncentruje się w danym momencie? Oto odpowiedź na pytanie askubuntu:

sprawdź aplikację pod myszą

Podsumowaniem odpowiedzi jest uruchomienie skryptu w terminalu podczas nawigacji za pomocą myszy:

#!/bin/bash
# Print the process tree of the window currently in focus.
# prereqs:
#   sudo apt-get install xdotool psmisc

while true; do
   pstree -spaul $(xdotool getwindowpid "$(xdotool getwindowfocus)")
   sleep 2
done

Krok # 4: zagłęb się w aktywność procesu

Po zidentyfikowaniu podejrzanego procesu ostatnim krokiem jest zbadanie tego indywidualnego procesu. W tym celu możesz przejść do systemu /procplików Linux ( man 5 proc).

Prawie wszystko, co możesz chcieć wiedzieć o procesie, jest dostępne pod /proc. W rzeczywistości programy takie jak lsof(wyświetlają listę otwartych plików), debugery, które badają stan procesu, oraz narzędzia do listowania procesów, takie jak pslub top, wszystkie oparte na /procjądrze, dla danych.

Za pomocą procmożna znaleźć, gdzie program wykonywalny procesu znajduje się na dysku (np. Dowolny program spoza standardowych katalogów systemowych, zwłaszcza jeśli próbuje się ukryć pod nazwą typu „nie zwracaj na mnie uwagi” , może być podejrzany) i użycie debugger lub moduł śledzenia wywołań systemowych możesz sprawdzić, co dokładnie robią na poziomie wywołań systemowych (nawet jeśli nie masz ich kodu źródłowego).

Kroki # 2 i # 3 powinny dać ci wszystkie identyfikatory procesów, PIDktóre potencjalnie mogą odczytywać twoją klawiaturę. Dla każdego z tych PIDS (oznaczmy każdy jako $pid) możesz:

Mapuj $ pid do pełnego wiersza poleceń:

cat /proc/$pid/cmdline

Zamapuj $ pid na jego wykonywalnym dysku:

ls -l /proc/$pid/exe

Zamapuj $ pid na bieżący katalog roboczy:

ls -l /proc/$pid/cwd

Odwzoruj $ pid na oryginalne środowisko

cat /proc/$pid/environ | tr '\000' '\012'

Śledź aktywność $ pid (i jej procesów potomnych) w czasie rzeczywistym:

strace -f -p $pid

(Jest więcej: patrz man 5 proc)

Jeśli zobaczysz nieznany proces, który reaguje na każde naciśnięcie klawisza, zapisując go w pliku (przez write) lub wysyłając go przez sieć do sendto, możesz znaleźć sniffer klawiatury.

Możesz także sprawdzić, które procesy mają otwarte punkty końcowe sieci (tcp + udp):

# See 'man netstat' for details on all options used below
$ sudo netstat -tunapee

Dolna linia:

Najbardziej prawdopodobną przyczyną błędu nie jest złośliwe oprogramowanie, ale wiele procesów próbujących jednocześnie uzyskać kontrolę nad klawiaturą. Jednym z dwóch jest gnome-ssh-askpass(ten, który drukuje błąd). Druga może być otwartą przeglądarką w witrynie z agresywnym oknem dialogowym skupiającym fokus.

Dobrą wiadomością jest to, że nawet jeśli zdalnie masz zainstalowane złośliwe oprogramowanie, ponieważ korzystasz z systemu Linux, wszystkie procesy są przejrzyste, dzięki czemu możesz je badać i sprawdzać. Bardzo trudno byłoby złośliwemu oprogramowaniu naprawdę się przed tobą ukryć lub uniemożliwić łatwe zlokalizowanie go przy użyciu powyższych technik, zabicie jego procesów i usunięcie wszystkich jego plików.

Mój problem był spowodowany dwoma równoległymi gnome-ssh-askpassoknami. Miałem dwa zadania rsync na tym samym serwerze za pośrednictwem SSH i oba próbowały poprosić o hasło do certyfikatu SSH. Grupowanie (i łączenie) ich razem rozwiązało dla mnie!