Come devo eseguire il debug dell'errore “Impossibile afferrare la tastiera. Un client dannoso potrebbe intercettare la sessione. "


14

Sto eseguendo un'installazione di Ubuntu 14.04 che ho impostato per più di 6 mesi. Circa una settimana fa, ho iniziato a ricevere un messaggio di errore:

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

L'ho visto solo quando sono tornato al mio computer dopo essere stato via per un bel po '(di solito durante la notte). Diverse volte ha impedito il blocco dello schermo dopo il timeout impostato (ho iniziato a bloccarlo attivamente prima di partire).

Sto usando una tastiera USB (Kinesis Advantage) direttamente collegata a una porta USB sulla scheda madre. Sto usando un wireless mouse ELECOM .

Proverò a scollegare il dongle del mouse prima di partire. In quale altro modo è possibile identificare se è presente un client dannoso che tiene traccia delle sequenze di tasti o se si tratta di un problema di connettività?


1
NON EMIRARE I COMANDI SUDO SE PENSI CHE I TUOI TASTI SONO STATI REGISTRATI !!! invece, avvia un supporto live pulito e vai da lì.
j0h

Risposte:


13

Ecco come risolvere il tuo mistero. L'obiettivo è quello di insegnare agli utenti "come pescare" usando le utility Ubuntu standard per scavare nei dettagli di qualsiasi processo sul loro sistema.

Passaggio n. 1 (principalmente per curiosità): identifica quale programma ti sta dando questo errore:

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

Nel mio env l'unico programma che contiene questa stringa di avviso nel suo binario è gnome-ssh-askpass. Potrei cercare se c'è un bug archiviato in questo particolare programma e persino scaricare la sua fonteapt-get source ssh-askpass-gnome (si noti che il nome del pacchetto è diverso dal nome del programma) per un'ulteriore ispezione.

Tuttavia, sospetto che la causa principale non sia un problema gnome-ssh-askpass. Dato che ti gnome-ssh-askpasssta chiedendo la tua passphrase, i suoi sviluppatori hanno semplicemente scelto di sbagliare con cautela quando non riescono ad afferrare la tastiera, assumere lo scenario peggiore e rendere il messaggio super-paranoico. Ma nota che digitare la tua passphrase o la password in una finestra di dialogo casuale del sito per caso non è probabilmente una buona idea, quindi in questo senso ilgnome-ssh-askpass sviluppatori hanno fatto la scelta giusta.

Recentemente sempre più siti web hanno iniziato a impegnarsi nella visualizzazione di un popup, sbiadendo tutto il resto al di fuori della finestra di dialogo popup e catturando in modo aggressivo l'attenzione. Questa potrebbe essere la causa principale per gnome-ssh-askpassnon riuscire ad afferrare la tastiera. Se il tuo browser è aperto su tale sito, può essere utile chiudere il browser o allontanarti dal sito Web aggressivo. Se questa è la causa, potresti essere interessato a un'impostazione desktop che impedisce ai singoli processi di attirare l'attenzione completa (desktop completo). In KDE, ad esempio, questa impostazione è disponibile in ( Impostazioni di sistema -> Comportamento finestra -> Messa a fuoco -> Prevenzione furto messa a fuoco ). Se ti senti davvero paranoico, consiglierei di impostarlo su Higho Extreme. Naturalmente, questo può anche preveniregnome-ssh-askpassstesso dall'afferrare la tastiera, o più precisamente: afferrare la Xmessa a fuoco.

Passaggio 2: identificare i processi sospetti:

Sapendo che in Unix, i dispositivi appaiono come file uder /dev, la domanda successiva è quale dispositivo rappresenta "la tastiera" nella gerarchia del file system. Per questo possiamo usare l' lsofutility (list open files).

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

Si noti che la maggior parte dei processi che tengono aperti i dispositivi in ​​un tipico ambiente desktop sono aperti /dev/pts/<N>(una pseudo tty ). Questi sono i "dispositivi" di interesse.

Alcuni retroscena di ciò che sta succedendo qui:

In un tipico desktop grafico Linux, i processi non parlano direttamente con la tastiera. Invece il Xprogramma (Xorg) controlla tutti gli eventi della tastiera tramite un dispositivo /dev/input/event<N>. Xusa un gestore di eventi (evdev) che, tra le altre cose, gestisce gli eventi della tastiera. Puoi anche verificarlo guardando il Xregistro: /var/log/Xorg.0.logdovekeyboard è menzionato.

Gli eventi della tastiera vengono inoltrati dal Xgestore eventi al processo che ha il puntatore del mouse attivo in qualsiasi momento tramite l'input standard del processo che è aperto /dev/pts/<N>. A rigor di termini: un processo in realtà non "afferra la tastiera", la tastiera è trattenuta da X, il processo ha solo (o afferra) "focus" o l'attenzione di Xcosì Xpuò inoltrare gli eventi della tastiera ad esso tramite un descrittore di file stdin aperto su /dev/pts/<N>.

Diagramma degli eventi della tastiera moltiplicati tramite X evdev

Step # 3: quale processo ha il focus Xorg in un determinato momento?

Come capire quale processo ha il focus in un determinato momento? Ecco una domanda di askubuntu che risponde a questa:

scopri l'applicazione sotto il mouse

Il riassunto della risposta è eseguire uno script come il seguente in un terminale mentre si naviga con il 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

Passaggio n. 4: approfondire l'attività di processo

Una volta identificato un processo sospetto, l'ultimo passaggio è esaminare questo singolo processo. Per questo puoi passare al /procfilesystem Linux (man 5 proc ).

Quasi tutto ciò che potresti voler sapere su un processo è disponibile sotto /proc. In effetti, programmi come lsof(elencare i file aperti), debugger che esaminano lo stato del processo e programmi di utilità che elencano i processi come pso top, si basano tutti su/proc quali sono popolati dal kernel, per i dati.

Usando procpuoi trovare dove si trova il programma eseguibile del processo sul disco (ad es. Qualsiasi programma al di fuori delle directory di sistema standard, specialmente se sta cercando di nascondersi sotto un "non prestarmi attenzione" tipo di nome , può essere sospetto) e usare un debugger o un tracciatore di chiamate di sistema puoi esaminare cosa stanno facendo esattamente a livello di chiamata di sistema (anche se non hai il loro codice sorgente).

I passaggi n. 2 e n. 3 dovrebbero fornire tutti gli ID di processo PIDche possono potenzialmente leggere la tastiera. Per ciascuno di questi PIDS (denotiamo ciascuno come $pid) puoi:

Mappa $ pid alla sua riga di comando completa:

cat /proc/$pid/cmdline

Mappa $ pid sul suo eseguibile su disco:

ls -l /proc/$pid/exe

Mappa $ pid alla sua directory di lavoro corrente:

ls -l /proc/$pid/cwd

Mappa $ pid al suo ambiente originale

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

Traccia $ pid (e i suoi figli-procs) attività di chiamata di sistema in tempo reale:

strace -f -p $pid

(C'è di più: vedi man 5 proc)

Se vedi un processo sconosciuto che reagisce a ogni pressione di un tasto memorizzandolo in un file (via write) o inviandolo attraverso la rete a via sendto, potresti aver trovato uno sniffer da tastiera.

Puoi anche verificare quali processi hanno (tcp + udp) endpoint di rete aperti:

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

Linea di fondo:

La causa più probabile dell'errore non è il malware, ma più processi che cercano di ottenere il controllo della tastiera contemporaneamente. Uno dei due è gnome-ssh-askpass(quello che stampa l'errore). L'altro potrebbe essere un browser aperto su un sito con una finestra di dialogo aggressiva che acquisisce l'attenzione.

Anche nella remota possibilità che tu abbia effettivamente installato del malware, la buona notizia è che da quando sei su Linux, tutti i processi sono trasparenti per te da ricercare e ispezionare. Sarebbe molto difficile per il malware nasconderti davvero o impedirti di localizzarlo facilmente utilizzando le tecniche di cui sopra, uccidendo i suoi processi e rimuovendo tutti i suoi file.


Durante il passaggio n. 2, non vedo molti processi /dev/pts/7(solo 3 valori pid unici). Scorrendo i risultati, sembra che il dispositivo più helf sia in /dev/pts/15possesso di alcuni 1, 3, 12, 16, 17, 21, 22, 23, 24, 25, 25, 26, 27, 28, 29, 30, 31, 32, 34. La tastiera è sempre 7? Come identificare quale di queste è la mia tastiera?
Steven C. Howell,

Può essere uno dei precedenti. Il dispositivo a tastiera fisica è effettivamente aperto da Xorg ( /usr/bin/X) come /dev/input/eventNdove puoi trovarlo Nguardando la stringa evdevin /var/log/Xorg.0.log. Xorg quindi "inoltra" ogni clic della tastiera sul singolo processo che ha il puntatore del mouse "attivo" in quel particolare istante. Quando corro ssh-askpassvedo che è /dev/pts/3aperto ma in qualsiasi ambiente può essere qualsiasi dispositivo pseudo tty. Quindi uno qualsiasi dei tuoi /dev/pts/Npuò essere rilevante qui.
arielf

@ stvn66 Ho aggiunto un piccolo script che ti dice quale processo ha "il focus" ripetutamente (riferimento a una domanda correlata su askubuntu). HTH.
arielf

dopo aver eseguito lo script per identificare quali processi tengono il mouse, come dovrei identificarne uno sospetto? Sembra essere qualsiasi applicazione che seleziono, ad esempio, inizia come il terminale in cui ho eseguito lo script, passa a {firefox}quando faccio clic su Firefox, passa di nuovo a {thunderbird}quando seleziono Thunderbird. Niente è inaspettato. Forse questo è il risultato finale : il problema non deriva da qualcosa che afferra la tastiera. Vorrei che questo avviso non avesse senso o che potesse eliminarlo.
Steven C. Howell,

@ stvn66 Ti sento :) non puoi tornare indietro nel tempo e capire il processo che inizialmente era focalizzato. Tale processo potrebbe essere terminato da allora. Per essere veramente sicuri, devi essere in grado di riprodurre. La mia ipotesi migliore è che sia stato il tuo browser ( firefox) durante la visita di un sito Web con un pop-up che attira l'attenzione. A meno che non scarichi e installi regolarmente software da fonti dubbie (non canoniche), dubito fortemente che tu abbia installato accidentalmente uno sniffer da tastiera su Ubuntu. È bello essere un po 'paranoici, ma non c'è bisogno di sudare troppo.
Ari

1

Il mio problema era dovuto a due gnome-ssh-askpassfinestre simultanee . Ho avuto due lavori rsync sullo stesso server tramite SSH ed entrambi hanno provato a chiedere la password del certificato SSH. Raggruppandoli (e concatenandoli) risolti insieme per me!

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.