|
Bonjour tout le monde !
Suite à une vague de psychose sur le Village, j'ai torturé mon ordinateur pour qu'il me réponde clairement si un keylogger pouvait vraiment (ou non) mettre en danger des identifiants. La réponse est oui, de toute évidence... Situation : Un script réalisé sous environnement AutoIt en suivant simplement quelques indications du manuel (en Anglais) lira les frappes clavier avec un déclencheur alternatif sur Ctrl+X/C/V, un bloc-notes ouvert où les informations seront à écrire (équivalent à Client de jeu, un navigateur Internet, et à toute application nécessitant un login quelconque), et un anti-virus Avast free-edition dans sa plus récente mise à jour. Environnements testés : Le clavier normal, le presse-papier, la reconnaissance vocale, le clavier visuel, la session "En tant que .." et le contrôle à distance (sous console DSM de Computer Associates). Évidemment, le keylogger étant vraiment fait à l'arrachée, il est bourré de "failles" sur lesquelles il n'observe pas ce qui se passe, mais disons que pour le sujet qui m'intéresse (et vu que sa finalité m'importe peu), il sera considéré comme faisant son travail (la lecture de toute information texte envoyée dans une application) sans faute. Petite capture d'écran pour donner de la profondeur à la situation : Code:
char:R;time:0'11"504;LWIN; <Windows+R ("Exécuter") char:N;time:0'13"419; char:O;time:0'13"549; char:T;time:0'13"785; char:E;time:0'13"862; char:P;time:0'14"128; char:A;time:0'14"506; char:D;time:0'14"547; char: ;time:0'15"577; <notepad [entrée] char:T;time:0'18"775;RSHIFT; char:E;time:0'19"87; char:S;time:0'19"437; char:T;time:0'19"557; char: ;time:0'20"468; char:D;time:0'21"2; char:E;time:0'21"120; char: ;time:0'29"572; char:K;time:0'29"947; char:E;time:0'30"95; char:Y;time:0'30"192; char:L;time:0'30"430; char:O;time:0'30"851; char:G;time:0'30"898; char:G;time:0'30"952; char:E;time:0'31"180; char:R;time:0'31"599; char:¾;time:0'31"957;RSHIFT; <Test de keylogger. char:%;time:0'44"486;LSHIFT;LCTRL; <Ctrl+Shift+gauche char:C;time:0'47"783;LCTRL; <Ctrl+C (copie) char:C;time:0'47"815;LCTRL; copie:keylogger. <Affichage du presse-papier copié char:(;time:0'52"482; <[bas] char:#;time:0'55"145; <[fin] char: ;time:0'56"177; <[entrée] char:V;time:1'2"390;LCTRL; <Ctrl+V (colle) colle:keylogger. <Affichage du presse-papier collé char:V;time:1'2"429;LCTRL; char:X;time:1'6"660;LCTRL; <Sélection à la souris d'une zone de texte, puis Ctrl+X (coupe) char:X;time:1'6"695;LCTRL; coupe:log <Affichage du presse-papier coupé char:$;time:1'8"47; <[origine] char:V;time:1'9"260;LCTRL; <Ctrl+V colle:log char:V;time:1'9"534; char:,;time:1'42"531; <[Impr. Ecr] Pour les situations étudiées : - La frappe au clavier normal est lisible en clair - La mise en buffer de type Presse-Papier est lisible en clair - La correction d'une faute de frappe volontaire est lisible en clair - L'utilisation du clavier virtuel (à la souris, donc) génère des frappes clavier lisibles en clair - La reconnaissance vocale génère des frappes clavier lisibles en clair - Le démarrage du keylog sous une session alternative (En tant que.. sur une session qui n'est pas celle en cours d'exécution) ne change rien - Les frappes clavier envoyées à une machine sous contrôle distant sont lisibles en clair (quand le script est sur la machine qui prend le contrôle à distance) - Les frappes clavier reçues par une machine sous contrôle distant sont lisibles en clair (quand le script est sur la machine prise en contrôle à distance, il ne peut pas lire ce qui est inscrit quand la fenêtre de prise de contrôle n'a pas le focus) - L'anti-virus n'a pas bronché d'un pouce Résumé : l'utilisation de la souris (clavier virtuel et mise en presse-papier par copie/colle) ne contourne qu'à-peine le problème, et le clavier est totalement transparent pour un keylogger. Questions : Quelles sont les sécurités qui pourraient être mises en place pour éviter que le clavier ne puisse être lu (sans changer de système d'exploitation) ? - Pensez-vous qu'une capture des frappes serait possible dans une fenêtre donnée, pour que tout ce qui transite ne soit pas lisible à l'extérieur de l'application ? (Il me semble que le jeu Cabal possède un système équivalent à celui-ci, une sorte de tunnel de capture du clavier.) - Serait-il intéressant de développer une sorte de brouillage hardware/logiciel, de sorte que la frappe lue par le script soit différente de celle interprétée par le logiciel ? (Quand j'appuie sur le "a" de mon clavier Azerty en mode Qwerty, j'obtiens un "q". Un mode similaire proposable par une application en interne ?) - Ou l'impact d'un éventuel keylogger ne doit avoir aucun importance, en utilisant par exemple une clef USB de chiffrement générant un code utilisable pendant une unique minute ? (WoW propose son Authenticator, un usage plus répandu de ce type de sécurité serait-il à encourager ?) - D'autres principes plus originaux "manuels" sont à explorer, par exemple de taper des bouts de login, des bouts de pass, ajouter des (fake) fautes, des (fake) corrections, des (fake) mises en buffer.. bref, générer des pièges dans tous les sens pour "perdre" le mouchard ? (Mais v'là le temps à passer pour s'authentifier alors.) En vous remerciant d'avance de votre participation à ces quelques questions, Bonne journée, Za. |
14/04/2011, 17h11 |
Aller à la page... |
Salut, j'ai fait un keylogger, comment le rendre impuissant ?
Suivre Répondre |
|
Partager | Rechercher |
Alpha & Oméga
|
.
Dernière modification par fjsorg ; 21/02/2013 à 20h27. |
15/04/2011, 13h47 |
|
|
Naviguer sur internet via des vm, utiliser une vm différente pour les sites à risques que tu jettes à chaque fois (via un retour sur image), avoir l'host sous linux.
|
15/04/2011, 17h56 |
|
Suivre Répondre |
Connectés sur ce fil1 connecté (0 membre et 1 invité)
Afficher la liste détaillée des connectés
|