Como devo depurar o erro “Não foi possível pegar o teclado. Um cliente mal-intencionado pode estar espionando sua sessão. ”

Estou executando uma instalação do Ubuntu 14.04 que eu configuro há mais de 6 meses. Cerca de uma semana atrás, comecei a receber uma mensagem de erro:

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

Eu só o vi quando retornei ao meu computador depois de um tempo ausente (geralmente durante a noite). Várias vezes impediu que a tela bloqueie após o tempo limite definido (comecei a bloqueá-lo ativamente antes de sair).

Estou usando um teclado USB (Kinesis Advantage) diretamente conectado a uma porta USB na placa-mãe. Estou usando um mouse sem fio ELECOM .

Vou tentar desconectar o dongle do mouse antes de sair. De que outra forma eu poderia identificar se há um cliente mal-intencionado rastreando minhas teclas ou se este é um problema de conectividade?

Veja como resolver seu mistério. O objetivo é ensinar aos usuários "como pescar" usando os utilitários padrão do Ubuntu para investigar os detalhes de qualquer processo em seu sistema.

Etapa 1 (principalmente por curiosidade): identifique qual programa está causando esse erro:

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

No meu ambiente, o único programa que contém essa string de aviso no seu binário é gnome-ssh-askpass. Eu poderia procurar se há um bug registrado nesse programa em particular e até baixar sua fonte apt-get source ssh-askpass-gnome(observe que o nome do pacote é diferente do nome do programa) para uma inspeção mais aprofundada.

No entanto, suspeito que a causa raiz não seja um problema gnome-ssh-askpass. Como gnome-ssh-askpassestá solicitando sua senha, seus desenvolvedores simplesmente optaram por agir com cautela ao não agarrar o teclado, assumir o pior cenário possível e fazer a mensagem parecer super-paranóica. Mas observe que digitar sua senha ou senha em alguma caixa de diálogo aleatória do site por acidente provavelmente não é uma boa ideia; portanto, nesse sentido, os gnome-ssh-askpassdesenvolvedores fizeram a ligação certa.

Recentemente, mais e mais sites começaram a se engajar na prática de exibir um pop-up, esmaecendo tudo o resto fora da caixa de diálogo pop-up e agarrando agressivamente o foco. Essa pode ser a causa principal da gnome-ssh-askpassfalha ao agarrar o teclado. Se o seu navegador estiver aberto nesse site, fechar o navegador ou navegar para fora do site agressivo pode ajudar. Se essa for a causa, você pode estar interessado em uma configuração da área de trabalho, impedindo que processos individuais obtenham o foco completo (área de trabalho completa). No KDE, por exemplo, esta configuração pode ser encontrada em ( Configurações do sistema -> Comportamento da janela -> Foco -> Prevenção de roubo de foco ). Se você se sentir realmente paranóico, eu recomendaria configurá-lo para Highou Extreme. Obviamente, isso também pode impedirgnome-ssh-askpassagarrar o teclado ou, mais precisamente: agarrar o Xfoco.

Etapa 2: identificar processos suspeitos:

Sabendo que no Unix, os dispositivos aparecem como arquivos /dev, a próxima pergunta é qual dispositivo representa "o teclado" na hierarquia do sistema de arquivos. Podemos usar o lsofutilitário (listar arquivos abertos) para isso.

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

Observe que a maioria dos processos que mantêm os dispositivos abertos em um ambiente típico da área de trabalho está mantendo /dev/pts/<N>(uma pseudo-tty ) aberta. Estes são os "dispositivos" de interesse.

Em uma área de trabalho gráfica típica do Linux, os processos não falam diretamente com o teclado. Em vez disso, o Xprograma (Xorg) controla todos os eventos do teclado através de um dispositivo /dev/input/event<N>. Xusa um manipulador de eventos (evdev) que, entre outras coisas, manipula eventos do teclado. Você também pode verificar isso consultando o Xlog: /var/log/Xorg.0.logwhere keyboardé mencionado.

Os eventos do teclado são encaminhados do Xmanipulador de eventos para o processo que tem o foco do ponteiro do mouse a qualquer momento, através da entrada padrão do processo que está aberta /dev/pts/<N>. Estritamente falando: um processo realmente não "agarra o teclado", o teclado é mantido por X, o processo só tem (ou agarra) "foco" ou a atenção de Xmodo que Xpode encaminhar eventos do teclado para ele por meio de um descritor de arquivo stdin aberto em /dev/pts/<N>.

Etapa 3: qual processo o Xorg focaliza em um determinado momento?

Como descobrir qual processo tem o foco em um determinado momento? Aqui está uma pergunta do askubuntu, respondendo a isso:

descubra o aplicativo com o mouse

O resumo da resposta é executar um script como o seguinte em um terminal enquanto navega pelo 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

Etapa 4: aprofundar a atividade do processo

Depois de identificar um processo suspeito, a última etapa é investigar esse processo individual. Para isso, você pode recorrer ao sistema de /procarquivos Linux ( man 5 proc).

Quase tudo o que você pode querer saber sobre um processo está disponível em /proc. De fato, programas como lsof(listar arquivos abertos), depuradores que examinam o estado do processo e utilitários de listagem de processos como psou top, todos contam com o /procque é preenchido pelo kernel, para dados.

O uso de procvocê pode descobrir onde o programa executável do processo está no disco (por exemplo, qualquer programa fora dos diretórios padrão do sistema, especialmente se estiver tentando se esconder sob um tipo de nome "não preste atenção em mim" , pode ser suspeito) e usar um depurador ou rastreador de chamadas do sistema, você pode examinar o que exatamente eles estão fazendo no nível de chamada do sistema (mesmo se você não tiver o código fonte).

As etapas 2 e 3 devem fornecer todos os IDs de processo PIDque podem estar potencialmente lendo seu teclado. Para cada um desses PIDS (vamos denotar cada um como $pid), você pode:

Mapeie $ pid para sua linha de comando completa:

cat /proc/$pid/cmdline

Mapeie $ pid para o executável em disco:

ls -l /proc/$pid/exe

Mapeie $ pid para seu diretório de trabalho atual:

ls -l /proc/$pid/cwd

Mapeie $ pid para seu ambiente original

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

Rastreie a atividade de chamada do sistema $ pid (e seus filhos-procs) em tempo real:

strace -f -p $pid

(Há mais: veja man 5 proc)

Se você vir um processo desconhecido que reage a cada pressionamento de tecla, armazenando-o em um arquivo (via write) ou enviando-o pela rede para via sendto, você pode ter encontrado um sniffer de teclado.

Você também pode verificar quais processos têm pontos de extremidade de rede (tcp + udp) abertos:

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

Bottom line:

A causa mais provável do erro não é malware, mas vários processos que tentam obter o controle do teclado ao mesmo tempo. Um dos dois é gnome-ssh-askpass(aquele que imprime o erro). O outro pode ser um navegador aberto em um site com uma caixa de diálogo agressiva para aquisição de foco.

Mesmo com a chance remota de você realmente ter algum malware instalado, a boa notícia é que, como você está no Linux, todos os processos são transparentes para você pesquisar e inspecionar. Seria muito difícil para o malware realmente se esconder de você ou impedi-lo de localizá-lo facilmente usando as técnicas acima, matando seus processos e removendo todos os seus arquivos.

Meu problema ocorreu devido a duas gnome-ssh-askpassjanelas simultâneas . Eu tive dois trabalhos de rsync no mesmo servidor através do SSH e ambos tentaram solicitar a senha do certificado SSH. Agrupar (e encadear) eles resolvidos para mim!