Perché i keylogger sono un problema per i gestori di password?

Question

Perché i keylogger sono un problema per i gestori di password?

#1 da (2 voti)
#2 da (1 voti)
#3 da (1 voti)

0

Lettura della definizione API di SetWindowsHookEx , Vedo

Calling the CallNextHookEx function to chain to the next hook procedure is optional, but it is highly recommended; otherwise, other applications that have installed hooks will not receive hook notifications and may behave incorrectly as a result. You should call CallNextHookEx unless you absolutely need to prevent the notification from being seen by other applications.

Quindi un gestore di password potrebbe semplicemente registrare un hook, non chiamare CallNextHookEx , quindi digitare la password e annullare la registrazione del hook per ripristinare il comportamento originale.

Questa tecnica non è elencata nella risposta a Con che facilità i keylogger sventano? o Metodi di mitigazione delle minacce dai keylogger , quindi mi chiedo se Mi manca qualcosa di ovvio.

windows password-management keyloggers

posta Thomas Weller 08.01.2015 - 22:30

fonte

3 risposte

Leggi altre domande sui tag windows password-management keyloggers

Quale metodo di crittografia PHP è più incidentalmente sicuro? Iniziare un nuovo lavoro dopo aver lavorato a casa per anni. Come proteggere al meglio dati, segreti e privacy sul posto di lavoro?

score 2 · Answer 1

Non penso che ti manchi qualcosa di ovvio. Le domande e le risposte di altri articoli si concentrano in realtà sull'arresto del keylogger che invia messaggi dalla rete.

La tecnica di cui parli è come un'applicazione, che sa che potrebbe essere un obiettivo per un keylogger, potrebbe impedire al keylogger di ottenere le informazioni in primo luogo.

score 1 · Answer 2

Non sono sicuro al 100% di ciò che sto per dire, ma molto probabilmente è corretto.

I messaggi vengono inviati dalla fonte (S) e viaggiano verso la destinazione (D). I ganci (Hx) sono posizionati logicamente tra questi 2 punti. I ganci possono essere utilizzati per elaborare il messaggio in viaggio per qualsiasi scopo (ad esempio il filtraggio del traffico). Con questo in mente, possiamo visualizzare un sistema Windows funzionante come segue:

(S) - > (H1) - > (H2) - > ...- > (HN) - > (D)

Quando un gancio ha finito con l'elaborazione del messaggio, lo passa a quello successivo, usando CallNextHookEx, fino a quando non rimangono nessun hook. Non chiamando il prossimo hook, si assicura che il messaggio non raggiunga mai la destinazione (da qui l'avviso di Microsoft).

La soluzione che hai proposto non funzionerebbe, perché avrebbe semplicemente interrotto qualsiasi scambio di messaggi tra il gestore di password e l'applicazione utente. Puoi immaginare un hook che non inoltra il messaggio come regola di drop del firewall, tutti i messaggi vengono scartati.

Un altro problema è che non puoi sempre avere accesso allo spazio di memoria del processo in cui il messaggio sta andando. Essendo un programma di gestione autonomo di passwors, non è possibile impostare hook all'interno di altri processi, come ad esempio firefox, mentre un keylogger può. Per questo motivo non puoi nemmeno impostare un hook in primo luogo.

score 1 · Answer 3

La tecnica proposta non è molto utile contro i keylogger per due motivi:

Si basa sul fatto che l'hook appena installato viene eseguito prima di quello del keylogger, quindi non funzionerà sempre anche con i keylogger basati su hook.
Ciò che è più importante, solo il più semplice dei keylogger utilizza SetWindowsHookEx. Esistono oltre una dozzina di metodi diversi che vanno da GetAsyncKeyState alle patch delle funzioni in modalità kernel. Poiché l'acquisizione delle chiavi basata su hook può essere rilevata banalmente dal software antivirus, i keylogger di malware reali (al contrario degli strumenti di monitoraggio dei dipendenti, ecc.) Probabilmente utilizzeranno qualcos'altro.