Как отладить ошибку & ldquo; Не удалось схватить клавиатуру. Вредоносный клиент может прослушивать ваш сеанс. & Rdquo;

У меня установлена ​​Ubuntu 14.04, которую я установил более 6 месяцев. Около недели назад я начал получать сообщение об ошибке:

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

Я видел его только когда возвращался на свой компьютер после долгого отсутствия (обычно в течение ночи). Несколько раз это препятствовало блокировке экрана после установленного времени ожидания (я начал активно блокировать его перед уходом).

Я использую USB-клавиатуру (Kinesis Advantage), напрямую подключенную к USB-порту на материнской плате. Я использую беспроводную мышь ELECOM .

Я собираюсь попробовать отключить ключ мыши перед уходом. Как еще я могу определить, есть ли вредоносный клиент, отслеживающий мои нажатия клавиш, или это проблема с подключением?

14
задан 1 April 2016 в 16:06

2 ответа

Вот то, как решить Вашу тайну. Цель больше для обучения пользователей, "как ловить рыбу" при помощи стандартных утилит Ubuntu для рытья в детали любого процесса в их системе.

Шаг № 1 (для любопытства главным образом): определите, какая программа дает Вам эту ошибку:

# -- 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

В моем ENV единственная программа, которая содержит эту строку предупреждения в ее двоичном файле, gnome-ssh-askpass. Я мог искать, если существует ошибка, зарегистрированная на этой конкретной программе, и даже загрузите ее источник apt-get source ssh-askpass-gnome (обратите внимание, что имя пакета отличается, чем название программы) для дальнейшего контроля.

Однако я подозреваю, что первопричиной не является проблема в gnome-ssh-askpass. С тех пор gnome-ssh-askpass просит Ваш пароль, его разработчики просто приняли решение допустить ошибку на стороне осторожности при отказе захватить клавиатуру, принять худший вариант и заставить сообщение звучать uber-параноидальным. Но обратите внимание, что ввод Вашего пароля или пароля в некоторое случайное диалоговое окно веб-сайта случайно является, вероятно, не хорошей идеей, так в этом смысле gnome-ssh-askpass разработчики выполнили правильный вызов.

Недавно все больше веб-сайтов начало участвовать в практике отображения всплывающего окна, исчезновения все остальное вне всплывающего диалогового окна и настойчиво захвата фокуса. Это могло бы быть первопричиной для gnome-ssh-askpass отказ захватить клавиатуру. Если, при этом Ваш браузер открыт на таком сайте, закрывая браузер или перейдя далеко от агрессивного веб-сайта, может помочь. Если это - причина, можно интересоваться настольной установкой, препятствующей тому, чтобы отдельные процессы захватили полное (полный рабочий стол) фокус. В KDE, например, эта установка может быть найдена под (Параметры настройки системы-> поведение Окна-> Фокус-> предотвращение кражи Фокуса). Если бы Вы чувствуете себя действительно параноиками, я рекомендовал бы установить его на High или Extreme. Конечно, это может также предотвратить gnome-ssh-askpass самостоятельно от захвата клавиатуры, или более точно: захват X фокус.

Шаг № 2: Определите подозрительные процессы:

Зная, что в Unix, устройства появляются как вымя файлов /dev, следующий вопрос - то, какое устройство представляет "клавиатуру" в иерархии файловой системы. Мы можем использовать lsof (перечислите открытые файлы), утилита для этого.

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

Заметьте, что большинство зажимных приспособлений процессов, открытых в типичном настольном ENV, содержит /dev/pts/<N> (псевдо tty) открытый. Это "устройства" интереса.

Некоторый фон на том, что продолжается здесь:

В типичном Linux графический рабочий стол процессы не говорят с клавиатурой непосредственно. Вместо этого X программа (Xorg) управляет всеми событиями клавиатуры через устройство /dev/input/event<N>. X использует обработчик событий (evdev) который среди прочего, события клавиатуры дескрипторов. Можно также проверить это путем взгляда на X журнал: /var/log/Xorg.0.log где keyboard упоминается.

События клавиатуры передаются от X обработчик событий к процессу, который имеет фокус указателя мыши в любое время через процесс, введенный стандартом, который открыт на /dev/pts/<N>. Строго говоря: процесс на самом деле "не захватывает клавиатуру", клавиатура сохранена X, процесс только имеет (или захваты) "фокус" или внимание X так X может передать события клавиатуры ему через открытый stdin дескриптор файла на /dev/pts/<N>.

Diagram of keyboard events multiplexed via X evdev

Шаг № 3: какой процесс имеет фокус Xorg в какое-либо конкретное время?

Как фигурировать, какой процесс имеет фокус в какое-либо конкретное время? Вот askubuntu вопрос, отвечая на это:

узнайте приложение под мышью

Сводка ответа должна запустить скрипт как следующее в терминале при навигации вокруг с мышью:

#!/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

Шаг № 4: выройте глубже в действие процесса

После того как Вам определили подозрительный процесс, последний шаг должен исследовать этот отдельный процесс. Для этого можно обратиться к Linux /proc файловая система (man 5 proc).

Почти что-либо, что можно хотеть знать о процессе, доступно под /proc. На самом деле, программы как lsof (перечислите открытые файлы), отладчики, которые исследуют состояние процесса и перечисляющие процесс утилиты как ps или top, все полагаются /proc который заполняется ядром для данных.

Используя proc можно найти, где исполняемая программа процесса находится на диске (например, любая программа вне стандартных системных каталогов, особенно если это пытается скрыться под, "не обращают внимание на меня" вид имени, может быть подозреваемый), и использование отладчика или трассировщика системного вызова, можно исследовать то, что точно является ими делающий на уровне системного вызова (даже если у Вас нет их исходного кода).

Шаги № 2 и № 3 должны дать Вам все идентификаторы процесса (PIDs) это может потенциально читать Вашу клавиатуру. Для каждого из этих PIDS (позволяют нам обозначить каждого как $pid) Вы можете:

$pid карты к его полной командной строке:

cat /proc/$pid/cmdline

$pid карты к на дисковом исполняемом файле:

ls -l /proc/$pid/exe

$pid карты к его текущему рабочему каталогу:

ls -l /proc/$pid/cwd

$pid карты к его исходной среде

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

$pid трассировки (и его дети-procs) действие системного вызова в режиме реального времени:

strace -f -p $pid

(Существует больше: посмотрите man 5 proc)

Если Вы видите незнакомый процесс, который реагирует на каждое нажатие клавиши путем хранения его в файл (через write) или отправка его по сети к через sendto, Вы, возможно, нашли сниффера клавиатуры.

Можно также проверить, какие процессы имеют (tcp+udp) открытые сетевые оконечные точки:

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

Нижняя строка:

Наиболее вероятной причиной для ошибки не является вредоносное программное обеспечение, но несколько процессов, пытающихся получить контроль клавиатурой одновременно. Один из этих двух gnome-ssh-askpass (тот, печатающий ошибку). Другой может быть открытый браузер на сайте с агрессивным получающим фокус диалоговым окном.

Даже в удаленном шансе, что у Вас на самом деле есть некоторое установленное вредоносное программное обеспечение, хорошие новости - то, что, так как Вы находитесь на Linux, все процессы прозрачны, чтобы Вы исследовали и осмотрели. Вредоносному программному обеспечению было бы очень трудно действительно скрыться от Вас или предотвратить Вас от легкого определения местоположения его с помощью вышеупомянутых методов, уничтожив его процессы, и удалив все его файлы.

13
ответ дан 2 April 2016 в 02:06

Моя проблема была должна два параллельных gnome-ssh-askpass окна. У меня было два rsync задания к тому же серверу через SSH, и оба пытались попросить пароль сертификата SSH. Группировка (и объединение в цепочку) их вместе решенный для меня!

1
ответ дан 23 November 2019 в 03:03

Другие вопросы по тегам:

Похожие вопросы: