Keylogger do Linux sem root ou sudo! É real?

Alguém no Youtube afirma ter um keylogger no Ubuntu que não foi executado nem instalado como root. O link abaixo mostra uma demonstração do funcionamento.

http://www.youtube.com/watch?v=Y1fZAZTwyPQ

Apesar de afirmarem o contrário, essa pessoa poderia ter instalado o sistema como root antes de demonstrar o vídeo. Existe alguma outra evidência semi-credível de que isso é realmente possível sem raiz para instalação ou execução?

ATUALIZAÇÃO: O software mencionado na resposta de 24 de junho não seria instalado sem o sudo / root. Adicionei uma recompensa a quem fornecer um link para um software de keylogger para Linux que possa ser instalado e executado com privilégios regulares de usuário.

Sim, é real. Se você foi explorado através de um navegador e um invasor pode executar código com seus privilégios de usuário, ele pode registrar um programa através dos recursos de início automático do GNOME ou KDE que executam programas no login. Qualquer programa pode obter códigos de varredura de teclas pressionadas no X Window System. É facilmente demonstrado com o comando xinput. Consulte a postagem do blog sobre isolamento da GUI para obter detalhes.

O conceito nesse vídeo é 100% real e o código é muito simples.

Identifique o seu ID de teclado com: xinput --list

Registre as teclas digitadas com: xinput --test $id

Faça a correspondência entre números e teclas com: xmodmap -pke

Sim, é possível.
Você pode experimentá-lo em sua própria máquina com o software lkl semelhante .

Como não assisti ao vídeo, estou respondendo à impressão que obtive sobre o que ele afirma no tópico SU, em vez do vídeo que você cita.

Se um invasor puder executar o código em sua máquina como usuário, poderá registrar suas teclas pressionadas.

Bem, duh. Todos os aplicativos em execução têm acesso às teclas pressionadas. Se você estiver digitando itens no seu navegador, ele terá acesso às teclas pressionadas.

Ah, você diz, mas e as teclas de registro pressionadas em outro aplicativo? Enquanto o outro aplicativo estiver sendo executado no mesmo servidor X, eles ainda poderão ser registrados. O X11 não tenta isolar aplicativos - esse não é o seu trabalho. O X11 permite que os programas definam atalhos globais, que são úteis para métodos de entrada, para definir macros, etc.

Se o invasor puder executar o código como seu usuário, ele também poderá ler e modificar seus arquivos e causar todos os tipos de outros danos.

Isto não é uma ameaça. Faz parte das expectativas normais de um sistema em funcionamento. Se você permitir que um invasor execute o código em sua máquina, ela não estará mais segura. É como se você abrisse a porta da frente e permitisse a entrada de um matador de machados: se você se fechou em duas, não é porque a porta da frente é insegura.

O keylogger pode registrar apenas as teclas pressionadas pelo usuário infectado. (Pelo menos enquanto o usuário infectado não digitar a senha do sudo.)

É 100% possível. Para ttys / ptys (modo de texto), a maneira mais fácil é adicionar um calço a / bin / {ba, da, a} sh (por exemplo, um segundo segmento .code, RX) e alterar o ponto de entrada (como um ELF vírus faria). Exceto o acesso a isso, neste caso, pode-se modificar ~ / .profile ou ~ / .bashrc (etc.) para, como um modelo hipotético muito simples:

exec ~ / .malicious_programme

que pode carregar código de objeto compartilhado dinâmico para ocultar o programa malicioso em questão (exemplo: permitir leitura e modificação .profile, mas ocultar a linha. E / ou ocultar o programa).

Pode-se então usar o sistema UNIX98 pty (7) ou até simplesmente canalizar (2) para gravar todas as entradas em um shell bifurcado, assumindo que o fd não esteja marcado como FD_CLOEXEC e até mesmo alterar a entrada do usuário para o shell.

No X11, embora o kdm / gdm / xdm seja executado como root setuid (ou o equivalente em recursos [veja setcap (8)] ou qualquer modelo de segurança que você esteja usando, se não for o padrão), as coisas ficam mais complicadas, obviamente. Se alguém pode elevar privilégios? O iopl (2) ou o ioperm (2) facilita bastante a vida com acesso direto às portas do teclado 0x60 / 0x64 no x86. Como supomos que você não pode, devemos procurar uma rota alternativa. Conheço várias, mas não tenho certeza absoluta de que você queira uma dissertação sobre como isso é possível e as interfaces envolvidas.

Basta dizer que os trojans não superusuário do anel 3 são bastante possíveis no * nix, apesar do isolamento do processo, como resultado de vários problemas (principalmente no X) que adicionaram recursos para os daemons no modo de usuário fornecerem, por exemplo, texto - suporte de voz para todos os aplicativos sem comprometer a segurança do sistema. Eu já descrevi um que funciona de forma análoga a ttysnoops (que já passou da data de validade) e não requer raiz. Eu tenho um código de exemplo para este caso (que incluiria terminais internos no X), mas ainda não o publiquei. Se você quiser obter mais informações, entre em contato comigo.

Sim, é possível instalar o software sem privilégios su ou sudo; no entanto, isso geralmente é feito através de uma exploração de escalonamento de privilégios. Esse vídeo faz um bom trabalho dos recursos desse keylogger, mas deixa um pouco de detalhes na instalação do keylogger. Pode haver um pouco de truque aqui, mas é difícil dizer apenas a partir do vídeo.

Para fins de teste, criei um keylogger TTY que pode se conectar dinamicamente ao tty de um usuário e o programa não precisa ser instalado pela raiz e pode ser usado por qualquer conta. Uma vez conectado, ele registrará as entradas que correspondem ao padrão fornecido na linha de comando quando o programa é iniciado.

É possível com sistemas como o Crunchbang (distribuição baseada no Debian), apenas adicione permissões ao arquivo sudoers usando o nano visudo no terminal e adicione o keylogger para iniciar automaticamente como logkeys para Linux, por exemplo, logkeys --start --output /home/user/.secret /registro

Boa sorte