Як слід налагоджувати помилку "Не вдалося схопити клавіатуру. Зловмисний клієнт може підслухати ваш сеанс. "

Я запускаю інсталяцію Ubuntu 14.04, яку налаштовую більше 6 місяців. Близько тижня тому я почав отримувати повідомлення про помилку:

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

Я це коли-небудь бачив, коли повертався до свого комп’ютера після відсутності на довгий час (як правило, протягом ночі). Кілька разів це заважало блокувати екран після встановленого тайм-ауту (я почав його активно блокувати перед виходом).

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

Я спробую відключити ключ миші перед відходом. Як інакше я міг би визначити, чи є зловмисний клієнт, який відстежує мої натискання клавіш або це проблема з підключенням?

Ось як розгадати свою таємницю. Мета полягає в тому, щоб навчити користувачів "ловити рибу", використовуючи стандартні утиліти 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

В моєму середовищі єдиною програмою, яка містить цей попереджувальний рядок у своїй бінарній формі, є 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>.

Крок №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: глибше заглиблюйтесь у процесну діяльність

Після виявлення підозрюваного процесу останнім кроком є ​​розслідування цього окремого процесу. Для цього ви можете звернутися до /procфайлової системи Linux ( man 5 proc).

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

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

Етапи №2 та №3 повинні дати вам усі ідентифікатори процесу, PIDякі потенційно можуть читати вашу клавіатуру. Для кожного з цих ПІДС (давайте позначимо кожного з них $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, всі процеси прозорі для вас, щоб досліджувати та перевіряти. Зловмисне програмне забезпечення було б дуже важко по-справжньому сховатися від вас або не дати вам легко знайти його, використовуючи вищезазначені методи, знищити його процеси та видалити всі його файли.

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