Enregistreur de frappe Linux sans root ni sudo! Est-ce que c'est réel?

29

Quelqu'un sur Youtube prétend avoir un enregistreur de frappe sur Ubuntu qui n'a été ni exécuté ni installé en tant que root. Le lien ci-dessous montre une démonstration de son fonctionnement.

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

Malgré leurs affirmations contraires, cette personne aurait pu l'installer en tant que root avant de manifester pour la vidéo. Existe-t-il une autre preuve semi-crédible que cela est vraiment possible sans racine pour l'installation ou l'exécution?

MISE À JOUR: Le logiciel référencé dans la réponse du 24 juin ne s'installerait pas sans sudo / root. J'ai ajouté une prime à celui qui donne un lien vers un logiciel d'enregistreur de frappe Linux qui peut être installé et exécuté avec des privilèges d'utilisateur réguliers.

Mike Rowave
la source
Je pense que cela peut être fait facilement au niveau X. Pensez simplement aux programmes avec des raccourcis mondiaux.
Denis Nikolaenko
Pour empêcher les enregistreurs de frappe du système X Window, vous devez implémenter SELinux pour X. À ma connaissance, aucune distribution Linux répandue ne fait cela dès le départ. nsa.gov/research/_files/selinux/papers/x11/t1.shtml
Denis Nikolaenko
Connaissez-vous des exemples réels de travail? Sans le voir fonctionner de première main, je reste sceptique. Et sans savoir qu'il est vraiment possible pour un enregistreur de frappe d'être installé sans les privilèges sudo / root, cela ne vaut pas la peine de gérer la complexité de la configuration d'AppArmor ou de SELinux pour se défendre contre lui.
Mike Rowave
3
Veuillez résumer les points importants de la vidéo dans votre réponse. Il pourrait être supprimé ou le serveur pourrait devenir indisponible. (Oui, alors que je poste, Youtube est en panne.) Il est également assez impoli d'exiger que les visiteurs regardent une vidéo pour comprendre de quoi parle votre question.
Gilles 'SO- arrête d'être méchant'

Réponses:

29

Oui, c'est réel. Si vous avez été exploité via un navigateur et qu'un attaquant peut exécuter du code avec vos privilèges d'utilisateur, il peut enregistrer un programme via les installations de démarrage automatique GNOME ou KDE qui exécutent des programmes à la connexion. Tout programme peut obtenir les codes de numérisation des touches enfoncées dans le système X Window. Il est facilement démontré avec la commande xinput. Voir l'article de blog sur l'isolement de l'interface graphique pour plus de détails.

Denis Nikolaenko
la source
12

Le concept de cette vidéo est 100% réel et le code est très simple.

Identifiez votre identifiant de clavier avec: xinput --list

Enregistrez les frappes avec: xinput --test $id

Faites correspondre les numéros aux clés avec: xmodmap -pke

yardena
la source
11

Oui c'est possible.
Vous pouvez l'essayer sur votre propre machine avec un logiciel similaire lkl .

bbaja42
la source
C'est effrayant si c'est réel. Je vais mettre en place une machine virtuelle dans laquelle la tester. Mais le casse-tête suivant est de savoir comment le détecter immédiatement s'il s'installe d'une manière ou d'une autre via un exploit de navigateur ou quelque chose comme ça, ou au moins de manière proactive, l'empêcher de transmettre quoi que ce soit à Internet s'il s'exécute.
Mike Rowave
J'ai peu de connaissances dans le domaine, mais wiki.ubuntu.com/SELinux pourrait aider. N'hésitez pas à mettre à jour la question d'origine avec vos résultats. : D
bbaja42
1
Difficile de dire un canular, réel ou moins qu'il n'y paraît à partir d'une seule vidéo. Je peux déjà penser à des endroits où commencer si je voulais faire une vidéo supposant démontrer une énorme vulnérabilité (astuces suid, timeouts sudo, outils système falsifiés, etc. ad nauseum.) En aucun cas Linux n'est invulnérable pour attaquer, pour prétendre le contraire est stupide. Mais on ne peut pas tirer de conclusions basées sur des vidéos Youtube.
Andrew Lambert
@Amazed valid point, mais n'hésitez pas à installer lkl et à le tester sur votre propre machine.
bbaja42
1
Ça n'a pas marché. L'exécution a make installproduit l'erreur cannot create regular file '/usr/local/bin/lkl': Permission denied. L'exécution sudo make installn'a pas donné l'erreur, mais ensuite essayer d'exécuter réellement lkl a donné une autre erreur Have to be root to perform a iopl()!.
Mike Rowave
9

Je n'ai pas regardé la vidéo, donc je réponds à l'impression que j'ai sur ce qu'il prétend du fil SU plutôt que sur la vidéo que vous citez.

Si un attaquant peut exécuter du code sur votre machine en tant qu'utilisateur, il peut enregistrer vos pressions de touches.

Eh bien, duh. Toutes les applications que vous exécutez ont accès à vos touches. Si vous saisissez des éléments dans votre navigateur Web, votre navigateur Web a accès à vos touches.

Ah, dites-vous, mais qu'en est-il de l'enregistrement des pressions de touches dans une autre application? Tant que l'autre application s'exécute sur le même serveur X, elles peuvent toujours être enregistrées. X11 n'essaie pas d'isoler les applications - ce n'est pas son travail. X11 permet aux programmes de définir des raccourcis globaux, ce qui est utile pour les méthodes de saisie, pour définir des macros, etc.

Si l'attaquant peut exécuter du code en tant qu'utilisateur, il peut également lire et modifier vos fichiers et causer toutes sortes d'autres dommages.

Ce n'est pas une menace. Cela fait partie des attentes normales d'un système qui fonctionne. Si vous autorisez un attaquant à exécuter du code sur votre machine, votre machine n'est plus en sécurité. C'est comme si vous ouvriez votre porte d'entrée et permettiez à un meurtrier de hache d'entrer: si vous vous fendiez ensuite en deux, ce n'est pas parce que votre porte d'entrée n'est pas sécurisée.

L'enregistreur de frappe ne peut enregistrer que les touches enfoncées par l'utilisateur infecté. (Au moins tant que l'utilisateur infecté ne tape pas le mot de passe sudo.)

Gilles 'SO- arrête d'être méchant'
la source
Voir la loi n ° 1 .
Iszi
"Ne pas autoriser un attaquant à exécuter du code sur votre machine" est un excellent modèle de sécurité ... Je suppose que Windows devient alors parfaitement sécurisé lorsqu'il est utilisé par un utilisateur Linux (qui ne permettrait certainement pas "à un attaquant d'exécuter du code") ...
gbr
3

C'est 100% possible. Pour ttys / ptys (mode texte), le moyen le plus simple consiste à ajouter un shim à / bin / {ba, da, a} sh (par exemple, un deuxième segment .code, RX) et à modifier le point d'entrée (un peu comme un ELF virus). À moins d'y accéder dans ce cas, on peut modifier ~ / .profile ou ~ / .bashrc (etc.) pour, comme un modèle hypothétique très simple:

exec ~ / .malicious_programme

qui peut charger du code objet partagé dynamique pour masquer le programme malveillant en question (exemple: autoriser la lecture et la modification du .profile, mais masquer la ligne. Et / ou masquer le programme.)

On peut alors utiliser le système UNIX98 pty (7) ou même simplement pipe (2) pour enregistrer toutes les entrées dans un shell fourchu, en supposant que le fd n'est pas marqué FD_CLOEXEC, et même changer l'entrée utilisateur dans le shell.

Dans X11, bien que kdm / gdm / xdm s'exécute en tant que racine setuid (ou l'équivalent en capacités [voir setcap (8)] ou quel que soit le modèle de sécurité que vous utilisez s'il n'est pas par défaut), les choses deviennent évidemment plus compliquées. Si l'on peut élever des privilèges? iopl (2) ou ioperm (2) facilite la vie avec un accès direct aux ports clavier 0x60 / 0x64 sur x86. Puisque nous supposons que vous ne pouvez pas, nous devons chercher un itinéraire alternatif. J'en connais plusieurs, mais je ne suis pas tout à fait sûr que vous vouliez une dissertation sur la façon dont c'est possible et les interfaces impliquées.

Qu'il suffise de dire, anneau 3, les chevaux de Troie non super-utilisateur sont tout à fait possibles sur * nix, malgré l'isolement du processus, en raison de divers problèmes (en particulier avec X) qui ont ajouté des fonctionnalités pour les démons en mode utilisateur pour fournir, par exemple, du texte prise en charge vocale de toutes les applications sans compromettre la sécurité du système. J'en ai déjà décrit un qui fonctionne de manière analogue à ttysnoops (qui est bien après sa date d'expiration) et qui ne nécessite pas de root. J'ai un exemple de code pour ce cas (qui inclurait les terminaux internes en X), mais je ne l'ai pas encore publié. Si vous souhaitez plus d'informations, n'hésitez pas à me contacter.

David McIlwraith
la source
La question dit "sans root ni sudo". Comment un attaquant modifierait-il un programme /binsans privilège?
G-Man dit `` Réintègre Monica '' le
0

Oui, il est possible d'installer des logiciels sans privilèges su ou sudo; cependant, cela se fait généralement via un exploit d'élévation de privilèges. Cette vidéo fait un très bon travail sur les capacités de cet enregistreur de frappe, mais elle laisse un peu de détails sur l'installation de l'enregistreur de frappe. Il peut y avoir un peu de ruse ici, mais c'est difficile à dire à partir de la vidéo seule.

Xenoactive
la source
Vous tordez des mots. Il peut être possible d'installer un logiciel dans un répertoire système sans exécuter su ou sudo, mais un exploit par élévation de privilèges donnerait à l'attaquant le privilège root - alias "superutilisateur" ou "su".
G-Man dit `` Réintègre Monica '' le
0

À des fins de test, j'ai créé un enregistreur de frappe TTY qui peut être attaché dynamiquement au tty d'un utilisateur et le programme n'a pas besoin d'être installé par root et peut être utilisé par n'importe quel compte. Une fois connecté, il enregistrera les entrées qui correspondent au modèle donné sur la ligne de commande au démarrage du programme.

wzis
la source
-3

Est-il possible avec des systèmes comme Crunchbang (distribution basée sur Debian) d' ajouter simplement des autorisations au fichier sudoers en utilisant nano visudo dans le terminal et d' ajouter un enregistreur de frappe pour démarrer automatiquement comme logkeys pour Linux par exemple logkeys --start --output /home/user/.secret /bûche

Bonne chance

GodOfWarWebMew
la source
5
Le privilège root ou sudo est requis pour éditer le fichier sudoers.
Mike Rowave