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


14

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

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

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

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

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


1
НЕ ВЫДАВАЙТЕ КОМАНДЫ SUDO, ЕСЛИ ВЫ ДУМАЕТЕ, ЧТО ВАШИ КЛАВИШИ ЗАПИСАНЫ !!! вместо этого загрузите чистую живую среду и идите оттуда.
июня

Ответы:


13

Вот как решить вашу тайну. Цель состоит в том, чтобы научить пользователей «ловить рыбу» с помощью стандартных утилит 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он запрашивает вашу фразу-пароль, ее разработчики просто предпочли ошибиться, когда не смогли схватить клавиатуру, принять наихудший сценарий и сделать сообщение сверхпараноидальным. Но обратите внимание, что ввод вашей парольной фразы или пароля в какое-то случайное диалоговое окно веб-сайта случайно не является хорошей идеей, поэтому в этом смысле gnome-ssh-askpassразработчики сделали правильный вызов.

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

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

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

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

Обратите внимание, что большинство процессов, удерживающих устройства открытыми в типичной среде рабочего стола, удерживают /dev/pts/<N>( псевдотермические ) открытыми. Это «устройства», представляющие интерес.

Немного предыстории того, что здесь происходит:

В типичном графическом рабочем столе 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>,

Диаграмма событий клавиатуры, мультиплексированных через X evdev

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

Как определить, какой процесс находится в центре внимания в конкретный момент времени? Вот вопрос аскубунту, отвечающий на это:

найти приложение под мышкой

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

#!/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: углубиться в процесс деятельности

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

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

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

Шаги № 2 и № 3 должны дать вам все идентификаторы процессов, PIDкоторые потенциально могут считывать вашу клавиатуру. Для каждого из этих 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 (и его дочерних процессов) в режиме реального времени:

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, все процессы прозрачны для вас, чтобы вы могли их исследовать и проверять. Вредоносному ПО будет очень трудно действительно скрыться от вас или помешать вам легко найти его с помощью описанных выше методов, убить его процессы и удалить все его файлы.


На шаге 2 я не вижу много процессов, удерживающих /dev/pts/7(только 3 уникальных значения pid). Прокручивая результаты, кажется, что самое полезное устройство, /dev/pts/15хотя некоторые держат 1, 3, 12, 16, 17, 21, 22, 23, 24, 25, 25, 26, 27, 28, 29, 30, 31, 32, 34. Клавиатура всегда 7? Как мне определить, какая из них моя клавиатура?
Стивен Хоуэлл

Это может быть любой из вышеперечисленных. Физическое клавиатурное устройство фактически открывается Xorg ( /usr/bin/X), /dev/input/eventNгде вы можете найти свое устройство N, посмотрев на строку evdevв /var/log/Xorg.0.log. Затем Xorg «перенаправляет» каждый щелчок клавиатуры на отдельный процесс, на котором указатель мыши «фокусируется» в данный момент. Когда я бегу, ssh-askpassя вижу, что он /dev/pts/3открыт, но в любом env это может быть любое псевдо-устройство. Так что любой из ваших /dev/pts/Nможет быть актуальным здесь.
arielf

@ stvn66 Я добавил небольшой скрипт, рассказывающий, какой процесс постоянно находится в «фокусе» (ссылка на соответствующий вопрос в askubuntu). НТН.
arielf

после запуска сценария, чтобы определить, какие процессы удерживают мышь, как определить подозрительный? Похоже, что любое приложение, которое я выбираю, запускается как терминал, в котором я запускал скрипт, переключается, {firefox}когда я нажимаю на firefox, снова переключается на, {thunderbird}когда я выбираю thunderbird. Ничто не выделяется как неожиданное. Возможно, это относится к вашей сути: проблема не в том, что что-то захватывает клавиатуру. Я хотел бы быть уверен, что это уведомление не имеет смысла или может устранить его.
Стивен Хоуэлл,

@ stvn66 Я вас слышу :) вы не можете вернуться назад во времени и выяснить процесс, который изначально был в центре внимания. Этот процесс мог завершиться с тех пор. Чтобы быть действительно уверенным, вы должны быть в состоянии воспроизвести. По-моему, это был ваш браузер ( firefox) при посещении веб-сайта с всплывающим контекстным меню. Если вы регулярно не загружаете и не устанавливаете программное обеспечение из сомнительных (неканонических) источников, я сильно сомневаюсь, что вы случайно установили анализатор клавиатуры в Ubuntu. Хорошо быть немного параноиком, но нет нужды чрезмерно потеть.
Ариэльф

1

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.