Posible manera de extraer la contraseña de sudo del sistema en ejecución a través del portapapeles

6

Utilizo para copiar y pegar mi contraseña sudo de un archivo KeePass, por lo que supongo que la contraseña de usuario de texto sin formato se guardará en la RAM en algún momento cuando la use, por ejemplo, para aceptar una actualización. ¿Es eso correcto?

¿Sería teóricamente posible que un atacante extraiga esta cadena de contraseña o una parte de ella conectando la RAM a otra máquina (por ejemplo, Cold Boot Attack)? ¿Podría el atacante volver a conectar la memoria RAM a la primera máquina aún en ejecución e ingresar la contraseña de usuario para desbloquear la pantalla, por ejemplo?

¿Haría una diferencia si escribiera la contraseña sudo con mi teclado cada vez que la necesito? Creo que las pulsaciones simples no se guardan en la memoria RAM, ¿no?

Otra opción para evitar esto sería una contraseña de bloqueo de pantalla personalizada, supongo.

    
pregunta Junior J. Garland 29.04.2015 - 01:05
fuente

2 respuestas

7

Sí . De hecho, esta es una característica común de los keyloggers. A menudo tomarán capturas de pantalla cada X segundos, monitorearán el portapapeles y registrarán los movimientos de las teclas. Estas características prácticamente anulan su estrategia de escribir en lugar de copiar / pegar.

Sin embargo, usted menciona que está usando keepass. Así que puedes estar protegido. Eche un vistazo a esta información de sus preguntas frecuentes

  

Debido a que estamos usando mucho el portapapeles, es útil bloquear todos los monitores actuales del portapapeles. Esto significa que no se notificará a ninguna otra aplicación cuando KeePass cambie el portapapeles.

     

Para esto, se crea una ventana invisible y se agrega a la parte superior de la   Cadena de manejador de eventos del portapapeles. Esta ventana simplemente tira todo   El portapapeles cambia los mensajes que recibe, prácticamente bloqueando a todos los demás.   Las aplicaciones de recibir cualquier evento.

También detalla otra característica para derrotar a los keyloggers:

  

La función Auto-Type de KeePass es muy poderosa: envía pulsaciones de teclas simuladas a otras aplicaciones. Esto funciona con todas las aplicaciones de Windows y para las aplicaciones de destino no es posible distinguir entre las pulsaciones reales y las simuladas por Auto-Type. Esto, al mismo tiempo, es la principal desventaja de Auto-Type, porque los keyloggers pueden espiar las teclas simuladas. Aquí es donde entra en juego la ofuscación de tipo automático de dos canales (TCATO).

     

TCATO hace que los keyloggers estándar sean inútiles. Utiliza el portapapeles de Windows.   para transferir partes del texto auto-escrito a la aplicación de destino.   Los keyloggers pueden ver las pulsaciones de Ctrl-V, pero no registran el real   Contenidos pegados desde el portapapeles.

La conclusión es que, como pueden saber, es que a medida que surgen nuevos ataques también surgen nuevas defensas (y viceversa).

    
respondido por el KDEx 29.04.2015 - 01:27
fuente
3

Pruebas con LiME en CentOS. Primero, KeePassX se configuró para generar contraseñas de búsqueda simples, que se regeneran cada vez porque las búsquedas colocan las contraseñas en la memoria.

Todos estos estaban a salvo (no se revelaron, y a menos que se indique que realicé el paso antes de comenzar un volcado de LiME):

  • Genere la contraseña dentro de KeePassX, no termine de guardar.
  • Vuelva a generar la contraseña, guarde la contraseña y deje la ventana principal abierta.
  • Inicie la captura de memoria, vuelva a generar la contraseña, la captura finaliza antes de que caduque el tiempo de espera de la contraseña (sujeto a tiempo, pero es poco probable).
  • Regenerar contraseña, copiar al portapapeles con la función de copia de KeePassX, el tiempo de espera de la contraseña no caduca.
  • Regenerar contraseña, copiar al portapapeles con la copia de KeePassX, iniciar volcado; la contraseña caduca en 10 segundos (el volcado finaliza a los 30 segundos)
  • Regenerar contraseña, copiar al portapapeles a mano con Ctrl-C, iniciar volcado después de que expire el tiempo de espera.
  • Regenerar contraseña, copiar al portapapeles a mano (Ctrl-C), tiempo de espera no caducado.
  • Regenerar contraseña, guardar, luego dejar [Mostrar contraseña] activa durante el volcado.
  • Regenerar, copiar y pegar desde KeePassX a GNote.
  • Regenera, copia y pega desde el campo de entrada de la contraseña de KeePassX a Firefox + Gmail.
  • Regen, muestra la contraseña, escribe manualmente en el campo de entrada de la contraseña de Firefox + Gmail.

Tuve una detección de casualidad, probablemente un error. Una detección real fue un intento manual de poner en cola un comando de búsqueda mientras se esperaba que el volcado terminara: Esto inyectó la contraseña en la memoria.

A tus preguntas:

Hay mucho tiempo para usar la volatilidad con la memoria copiada + las claves de cifrado, pero el acceso físico suele ser más difícil. La mayoría de las personas (en mi opinión) no tienen que preocuparse demasiado por su hardware. Sí, hay E / S de bajo nivel, actualizaciones de BIOS, BadUSB, Thunderstrike, comunicación ultrasónica, incluso modificaciones al firmware del disco duro; todos son noticias, pero a menudo de un alcance limitado.

Los administradores de portapapeles o los programas de menor seguridad que KeePassX son más preocupantes y la interacción de shell en realidad se parece a la pistola humeante (especialmente cuando se completan las pestañas, las búsquedas y la cola de comandos).

Mi contraseña de texto claro de sudo persiste en la memoria si elevo, pero lo hago mucho. Para emular el uso bajo, aquí hay una prueba de una nueva cuenta, comenzando desde la raíz (menos oportunidades para sudo). No busqué entre volcados de memoria, confiando en KeePassX para proteger las contraseñas como se indica arriba:

Terminal 1:
========================
# adduser keepasstest
# su keepasstest            ' user is working
$ exit
# passwd keepasstest
Changing password for user keepasstest.
New password:               ' paste from KeePassX
Retype new password:        ' paste from KeePassX
passwd: all authentication tokens updated successfully.

# exit                      ' dump memory #1

Terminal 2:
=====================
$ sudo -s                        ' my account
# su keepasstest                  ' substitute user
$ sudo -s                        ' elevate
[sudo] password for keepasstest:  ' Paste from KeePassX
#                                ' dump memory #2

Resultados:

$ sudo grep Ifnavcogi... lime*.txt

lime1.txt:Ifnavcogi...
lime1.txt:Ifnavcogi...     ' 3 entries after passwd
lime1.txt:Ifnavcogi...

lime2.txt:Ifnavcogi...
lime2.txt:Ifnavcogi...
lime2.txt:Ifnavcogi...     ' 5 entries after sudo
lime2.txt:Ifnavcogi...
lime2.txt:Ifnavcogi...

15 minutos después, al menos una contraseña aún está presente en los volcados, incluso después de que el tiempo de espera en caché de sudo haya expirado; el resto viene de la memoria de mi navegador.

Otra preocupación, aunque KeePassX hace páginas de bloqueo para evitar que se cambien al disco (ps -axu mostrará "L" en sus banderas) que ya no importa si hibernar el sistema y no use un buen cifrado de disco completo.

Parece que la contraseña está en varios lugares fuera de KeePassX cuando uso sudo (independientemente de cómo llegue allí). Pero el volcado de memoria en vivo necesita permisos elevados ... como el nivel requerido para ubicar malware en su sistema, para reemplazar su hardware, o para obtener el acceso físico necesario para copiar su memoria. No me gustan las contraseñas de texto claro, pero el riesgo aún parece ser promedio.

    
respondido por el ǝɲǝɲbρɯͽ 29.04.2015 - 05:50
fuente

Lea otras preguntas en las etiquetas