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-askpass
sta 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-askpass
non 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 High
o Extreme
. Naturalmente, questo può anche preveniregnome-ssh-askpass
stesso dall'afferrare la tastiera, o più precisamente: afferrare la X
messa 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' lsof
utility (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 X
programma (Xorg) controlla tutti gli eventi della tastiera tramite un dispositivo /dev/input/event<N>
. X
usa un gestore di eventi (evdev) che, tra le altre cose, gestisce gli eventi della tastiera. Puoi anche verificarlo guardando il X
registro: /var/log/Xorg.0.log
dovekeyboard
è menzionato.
Gli eventi della tastiera vengono inoltrati dal X
gestore 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 X
così X
può inoltrare gli eventi della tastiera ad esso tramite un descrittore di file stdin aperto su /dev/pts/<N>
.
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 /proc
filesystem 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 ps
o top
, si basano tutti su/proc
quali sono popolati dal kernel, per i dati.
Usando proc
puoi 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 PID
che 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.