Bagaimana saya harus men-debug kesalahan “Tidak dapat mengambil keyboard. Klien jahat mungkin menguping sesi Anda. "


14

Saya menjalankan instalasi Ubuntu 14.04 yang saya setup lebih dari 6 bulan. Sekitar seminggu yang lalu, saya mulai menerima pesan kesalahan:

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

Saya hanya pernah melihatnya ketika kembali ke komputer saya setelah pergi cukup lama (biasanya semalam). Beberapa kali itu mencegah layar untuk mengunci setelah batas waktu yang ditetapkan (saya sudah mulai secara aktif menguncinya sebelum pergi).

Saya menggunakan keyboard usb (Kinesis Advantage) yang terhubung langsung ke port usb pada motherboard. Saya menggunakan mouse ELECOM nirkabel .

Saya akan mencoba melepaskan dongle mouse sebelum pergi. Bagaimana lagi saya bisa mengidentifikasi jika ada klien jahat yang melacak penekanan tombol saya atau jika ini adalah masalah konektivitas?


1
JANGAN MASALAH SUDO PERINTAH JIKA ANDA BERPIKIR KUNCI KUNCI ANDA DILAKUKAN !!! sebaliknya, boot media live yang bersih, dan pergi dari sana.
j0h

Jawaban:


13

Inilah cara mengatasi misteri Anda. Tujuannya lebih untuk mengajari pengguna "cara memancing" dengan menggunakan utilitas standar Ubuntu untuk menggali rincian setiap proses pada sistem mereka.

Langkah # 1 (untuk rasa ingin tahu kebanyakan): mengidentifikasi program mana yang memberi Anda kesalahan ini:

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

Dalam env saya satu-satunya program yang berisi string peringatan ini dalam binernya adalah gnome-ssh-askpass. Saya dapat mencari jika ada bug yang diajukan pada program khusus ini, dan bahkan mengunduh sumbernya apt-get source ssh-askpass-gnome(perhatikan bahwa nama paket berbeda dari nama program) untuk pemeriksaan lebih lanjut.

Namun, saya menduga penyebab utama tidak menjadi masalah di gnome-ssh-askpass. Karena gnome-ssh-askpassmeminta frasa sandi Anda, pengembangnya hanya memilih untuk berhati-hati ketika gagal mengambil keyboard, menganggap skenario terburuk, dan membuat pesan tersebut terdengar uber-paranoid. Tetapi perhatikan bahwa mengetik frasa sandi atau kata sandi Anda ke dalam kotak dialog situs web acak secara kebetulan mungkin bukan ide yang baik, jadi dalam hal ini gnome-ssh-askpasspengembang telah melakukan panggilan yang benar.

Baru-baru ini semakin banyak situs web yang mulai terlibat dalam praktik menampilkan sembulan, memudar segala hal lain di luar dialog sembulan, dan secara agresif meraih fokus. Ini mungkin penyebab utama gnome-ssh-askpassgagal mengambil keyboard. Jika browser Anda terbuka di situs tersebut, menutup browser atau menavigasi dari situs web yang agresif dapat membantu. Jika ini penyebabnya, Anda mungkin tertarik pada pengaturan desktop yang mencegah proses individual dari meraih fokus (desktop penuh) lengkap. Dalam KDE misalnya, pengaturan ini dapat ditemukan di bawah ( Pengaturan Sistem -> Perilaku-jendela -> Fokus -> Fokus mencuri pencegahan ). Jika Anda merasa sangat paranoid, saya sarankan untuk mengatur Highatau Extreme. Tentu saja, ini juga dapat mencegahgnome-ssh-askpasssendiri dari menyambar keyboard, atau lebih tepatnya: meraih Xfokus.

Langkah # 2: Identifikasi proses mencurigakan:

Mengetahui bahwa di Unix, perangkat muncul seperti file uder /dev, pertanyaan berikutnya adalah perangkat apa yang mewakili "keyboard" dalam hierarki sistem file. Kita dapat menggunakan lsofutilitas (daftar file yang terbuka) untuk ini.

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

Perhatikan bahwa sebagian besar proses memegang perangkat terbuka di desktop khas sedang menahan /dev/pts/<N>( pseudo tty ) terbuka. Ini adalah "perangkat" yang menarik.

Beberapa latar belakang tentang apa yang terjadi di sini:

Pada desktop grafis khas Linux, proses tidak berbicara langsung dengan keyboard. Sebaliknya Xprogram (Xorg) mengontrol semua acara keyboard melalui perangkat /dev/input/event<N>. Xmenggunakan event handler (evdev) yang antara lain menangani acara keyboard. Anda juga dapat memverifikasi ini dengan melihat Xlog: di /var/log/Xorg.0.logmana keyboarddisebutkan.

Acara keyboard diteruskan dari Xpengendali acara ke proses yang memiliki fokus penunjuk tetikus kapan saja melalui input-standar proses yang terbuka /dev/pts/<N>. Tegasnya: suatu proses tidak benar-benar "ambil keyboard", keyboard dipegang oleh X, proses hanya memiliki (atau meraih) "fokus" atau perhatian Xsehingga Xdapat meneruskan acara keyboard ke sana melalui deskriptor file stdin terbuka di /dev/pts/<N>.

Diagram acara papan ketik digandakan melalui evdev X

Langkah # 3: proses mana yang memiliki fokus Xorg pada waktu tertentu?

Bagaimana mengetahui proses mana yang memiliki fokus pada waktu tertentu? Inilah pertanyaan askubuntu yang menjawab ini:

cari tahu aplikasi di bawah mouse

Ringkasan jawabannya adalah menjalankan skrip seperti yang berikut di terminal saat menavigasi berkeliling dengan mouse:

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

Langkah # 4: gali lebih dalam ke dalam aktivitas proses

Setelah Anda mengidentifikasi proses yang dicurigai, langkah terakhir adalah menyelidiki proses individu ini. Untuk itu Anda dapat beralih ke sistem /procfile Linux ( man 5 proc).

Hampir semua yang ingin Anda ketahui tentang suatu proses tersedia di bawah /proc. Bahkan, program-program seperti lsof(daftar file terbuka), debugger yang memeriksa keadaan proses, dan utilitas proses daftar suka psatau top, semua bergantung pada /procyang diisi oleh kernel, untuk data.

Menggunakan procAnda dapat menemukan di mana program proses yang dapat dijalankan pada disk (mis. Program apa pun di luar direktori sistem standar, terutama jika ia mencoba bersembunyi di bawah jenis nama "jangan perhatikan saya" , mungkin dicurigai) dan menggunakan debugger atau pelacak panggilan sistem Anda dapat memeriksa apa yang sebenarnya mereka lakukan pada tingkat panggilan sistem (bahkan jika Anda tidak memiliki kode sumbernya).

Langkah # 2 dan # 3 akan memberi Anda semua ID proses PIDyang berpotensi membaca papan ketik Anda. Untuk masing-masing PID ini (mari kita tunjukkan masing-masing sebagai $pid) Anda dapat:

Petakan $ pid ke baris perintah lengkapnya:

cat /proc/$pid/cmdline

Map $ pid ke disk yang dapat dieksekusi:

ls -l /proc/$pid/exe

Map $ pid ke direktori kerjanya saat ini:

ls -l /proc/$pid/cwd

Petakan $ pid ke lingkungan aslinya

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

Lacak aktivitas panggilan sistem $ pid (dan anak-anaknya) secara langsung:

strace -f -p $pid

(Masih ada lagi: lihat man 5 proc)

Jika Anda melihat proses asing yang bereaksi terhadap setiap penekanan tombol dengan menyimpannya ke dalam file (via write) atau mengirimkannya melalui jaringan sendto, Anda mungkin menemukan sniffer keyboard.

Anda juga dapat memeriksa proses mana yang memiliki titik akhir jaringan (tcp + udp) terbuka:

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

Intinya:

Penyebab kesalahan yang paling mungkin bukan malware, tetapi banyak proses yang mencoba untuk mendapatkan kontrol keyboard secara bersamaan. Salah satunya adalah gnome-ssh-askpass(yang mencetak kesalahan). Yang lain mungkin browser terbuka di situs dengan kotak dialog memperoleh fokus yang agresif.

Bahkan jika Anda memiliki beberapa malware yang terinstal, kabar baiknya adalah karena Anda menggunakan Linux, semua proses bersifat transparan untuk Anda teliti dan periksa. Akan sangat sulit bagi malware untuk benar-benar bersembunyi dari Anda, atau untuk mencegah Anda dengan mudah menemukan itu menggunakan teknik di atas, mematikan prosesnya, dan menghapus semua file-nya.


Selama langkah # 2, saya tidak melihat banyak proses memegang /dev/pts/7(hanya 3 nilai pid unik). Menggulir hasil, tampaknya perangkat yang paling membantu /dev/pts/15meskipun ada yang memegang 1, 3, 12, 16, 17, 21, 22, 23, 24, 25, 25, 26, 27, 28, 29, 30, 31, 32, 34. Apakah keyboard selalu 7? Bagaimana saya mengidentifikasi yang mana dari ini adalah keyboard saya?
Steven C. Howell

Itu bisa salah satu dari yang di atas. Perangkat keyboard fisik sebenarnya terbuka dengan Xorg ( /usr/bin/X) sebagai /dev/input/eventNmana Anda dapat menemukan Anda Ndengan melihat string evdevdi /var/log/Xorg.0.log. Xorg lalu "maju" setiap keyboard klik ke proses individu yang memiliki pointer mouse "fokus" pada saat itu juga. Ketika saya menjalankan, ssh-askpasssaya melihatnya /dev/pts/3terbuka tetapi dalam env apa pun itu bisa berupa perangkat pseudo tty. Jadi, salah satu dari Anda /dev/pts/Nmungkin relevan di sini.
arielf

@ stvn66 Saya menambahkan sedikit skrip yang memberi tahu Anda proses mana yang memiliki "fokus" berulang kali (merujuk ke pertanyaan terkait pada askubuntu). HTH.
arielf

setelah menjalankan skrip untuk mengidentifikasi proses mana yang menahan mouse, bagaimana saya mengidentifikasi yang dicurigai? Tampaknya aplikasi apa pun yang saya pilih, misalnya dimulai sebagai terminal tempat saya menjalankan skrip, beralih ke {firefox}saat saya mengklik firefox, beralih lagi ke {thunderbird}ketika saya memilih thunderbird. Tidak ada yang menonjol sebagai tak terduga. Mungkin ini masuk ke Intinya Anda : masalah tidak datang dari sesuatu yang meraih keyboard. Saya berharap pemberitahuan ini tidak ada artinya atau bisa menghilangkannya.
Steven C. Howell

@ stvn66 Saya mendengar Anda :) Anda tidak dapat kembali ke masa lalu dan mencari tahu proses yang awalnya berfokus. Proses itu mungkin telah keluar sejak saat itu. Untuk benar - benar yakin, Anda harus dapat mereproduksi. Tebakan terbaik saya adalah browser Anda ( firefox) saat mengunjungi situs web dengan pop-up yang fokus. Kecuali Anda secara teratur mengunduh dan menginstal perangkat lunak dari sumber yang meragukan (non-kanonik), saya sangat ragu Anda secara tidak sengaja menginstal sniffer keyboard di Ubuntu. Adalah baik untuk menjadi sedikit paranoid, tetapi tidak perlu terlalu banyak berkeringat.
arielf

1

Masalah saya adalah karena dua gnome-ssh-askpassjendela bersamaan . Saya memiliki dua pekerjaan rsync ke server yang sama melalui SSH, dan keduanya mencoba untuk meminta kata sandi sertifikat SSH. Pengelompokan (dan rantai) mereka bersama-sama diselesaikan untukku!

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.