¿Por qué los keyloggers son un problema para los administradores de contraseñas?

0

Leyendo la definición de API de SetWindowsHookEx , Veo

  

Llamar a la función CallNextHookEx para encadenar al siguiente procedimiento de enlace es opcional, pero es altamente recomendable; de lo contrario, otras aplicaciones que tengan ganchos instalados no recibirán notificaciones de ganchos y, por lo tanto, podrían comportarse de manera incorrecta. Debe llamar a CallNextHookEx a menos que sea absolutamente necesario para evitar que otras aplicaciones vean la notificación.

Por lo tanto, un administrador de contraseñas podría simplemente registrar un enlace, no llamar a CallNextHookEx , luego escribir la contraseña y anular el registro del enlace para restaurar el comportamiento original.

Esta técnica no aparece en la respuesta a ¿Con qué facilidad se anulan los keyloggers? o Métodos para mitigar las amenazas de los keyloggers , por lo que me pregunto si Me falta algo obvio.

    
pregunta Thomas Weller 08.01.2015 - 22:30
fuente

3 respuestas

2

No creo que te estés perdiendo nada obvio. Las preguntas y respuestas del otro artículo realmente se enfocan en detener al registrador clave que envía mensajes fuera de la red.

La técnica de la que está hablando es cómo una aplicación, que sabe que puede ser un objetivo para un registrador de claves, puede impedir que el registrador de claves obtenga la información en primer lugar.

    
respondido por el JCx 08.01.2015 - 22:44
fuente
1

No estoy 100% seguro de lo que voy a decir, pero lo más probable es que sea correcto.

Los mensajes se envían desde la fuente (S) y viajan al destino (D). Los ganchos (Hx) están ubicados lógicamente entre esos 2 puntos. Los ganchos se pueden usar para procesar el mensaje de viaje para cualquier propósito (por ejemplo, filtrado de tráfico). Teniendo esto en cuenta, podemos visualizar un sistema Windows en funcionamiento de la siguiente manera:

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

Cuando se termina un enganche con el procesamiento del mensaje, se pasa al siguiente, usando CallNextHookEx, hasta que no quede ningún enganche. Al no llamar al siguiente enlace, se asegura de que el mensaje nunca llegue al destino (de ahí la advertencia de Microsoft).

La solución que propones no funcionará, porque simplemente interrumpiría cualquier intercambio de mensajes entre el administrador de contraseñas y la aplicación del usuario. Puedes imaginar un enlace que no reenvía el mensaje como una regla de caída del firewall, todos los mensajes se descartan.

Otro problema es que no siempre se puede tener acceso al espacio de memoria del proceso donde se envía el mensaje. Como un programa de administrador de contraseñas independiente, no puede establecer enlaces dentro de otros procesos, como Firefox, por ejemplo, mientras que un registrador de teclas puede. Debido a esto, ni siquiera se puede establecer un gancho en primer lugar.

    
respondido por el user4294507 08.01.2015 - 23:49
fuente
1

La técnica propuesta no es muy útil contra los keyloggers por dos razones:

  • Se basa en el hecho de que el gancho recién instalado se ejecuta antes que el keylogger, por lo que no siempre funcionará incluso con keyloggers basados en ganchos.
  • Lo que es más importante, solo los keyloggers más simples usan SetWindowsHookEx. Hay más de una docena de métodos diferentes que van desde GetAsyncKeyState hasta parchear las funciones del modo kernel. Dado que el software antivirus puede detectar de forma trivial la captura de clave basada en el gancho, es probable que los keyloggers de malware reales (a diferencia de las herramientas de monitoreo de empleados, etc.) utilicen otra cosa.
respondido por el DMWatson 10.01.2015 - 07:12
fuente

Lea otras preguntas en las etiquetas