Artículo intitulado How to Login from an Internet Café without Worrying about keyloggers por Cormac Herley y Dinei Florêncio, del Simposio sobre Privacidad y Seguridad Servibles (SOUPS) ' 06, y reproducido aquí con su consentimiento.
Usuarios errantes que utilizan máquinas poco fiables para acceder a cuentas protegidas por contraseña tienen pocas buenas opciones. Una máquina en un café internet puede fácilmente estar corriendo un keylogger. El usuario errante no tiene una forma confiable de determinar si es segura, y no tiene otra alternativa más que ingresar la contraseña. Describimos un truco muy simple que el usuario puede emplear y que es enteramente efectivo en ocultar la contraseña. Verificamos su eficacia contra los programas de keyloggers más populares.
keylogging es una de las amenazas más insidiosas para la información personal del usuario. Contraseñas, números de tarjetas de crédito, información de identificación personal [PII], etcétera, están potencialmente expuestos; y la incidencia de keyloggers en el dominio público está aparentemente creciendo rápidamente. Al contrario de phishing [cosecha y pesca de contraseñas, de password harvesting fishing], este no es un ataque que usuarios alertas y sofisticados puedan evitar. Escribir un keylogger es una tarea trivialmente fácil [6,4], hay numerosas ofertas de freeware, y muchas de ellas hacen esfuerzos para ocultar su presencia. Por ejemplo, no aparecerán en la lista de procesos en ejecución [Task Manager]. Hay incluso un sitio de comparación de características [1] para aquellos interesados en los keyloggers más difíciles de detectar.
Usuarios en casa y en la empresa pueden confiar en sus sistemas si mantienen un buen firewall, un antivirus y estrategias de actualización. Sin embargo, los usuarios errantes no tienen control sobre lo que se instala. Ciertos centros de internet restringen el acceso a la máquina para prevenir la instalación de software. Esto hace menos probable que otro usuario haya instalado un keylogger, siempre y cuando el administrador haya puesto en práctica buenas políticas. Pero esto requiere saber que el administrador es competente y confiable. Tal como están las cosas un usuario no tiene una forma confiable de determinar si una máquina está corriendo un keylogger o no. En este ambiente, ¿Hay algo que el usuario pueda hacer para protegerse de la catastrófica posibilidad de pérdida de información?
Asumimos que la máquina que utilizamos tiene un keylogger corriendo. También asumiremos que no puede ser descubierto por el usuario, y que primordialmente queremos proteger cualquier contraseña que el usuario teclee (no nos interesa tanto otro tipo de tecleo). Hay muchas formas de implemetar tal keylogger, y los detalles no nos conciernen; en Windows user32.dll provee manejadores de eventos que cualquier aplicación puede invocar para atrapar cualquier evento del teclado y mouse. Hay muchos otras formas, y es verdad para cualquiera de los principales sistemas operativos [6,4]. De tal forma el keylogger obtiene una cadena de caracteres que crece en longitud a medida que las teclas son oprimidas. Por conveniencia, algunos keyloggers generan diferentes cadenas para las teclas de diferentes aplicaciones. Esto solamente presupone el chequeo de qué ventana tiene la atención al momento del evento de tecleo. Ahora es es muy fácil para el keylogger cosechar contraseñas. La cadena de pulsos de teclado que se envía al navegador contendrá casi siempre nombres de dominio (en un café internet la gente tecleará los dominios ya que no los tienen en 'favoritos'), seguido de un nombre de usuario y contraseña. Por ejemplo el segmento
www.hotmail.comsarahj7@hotmail.comsnoopy2
dice al logger que sarahj7@hotmail.com tiene una contraseña "snoppy2" en hotmail. Al analizar la cadena para dominios comunes como hotmail, paypal, amazon, fidelity, la tarea es incluso más simple.
Al principio nuestra tarea parecía imposible: si el keylogger ve todo, ¿Cómo podemos ocultar la contraseña de él? En lugar de esconder la contraseña nuestra propuesta es encerrarlo dentro una cadena de caracteres aleatorios. De tal forma que buscamos una forma de ingresar pulsos aleatorios para que sean vistos por el keylogger, pero que no afecten el proceso de login. El truco consiste en el hecho de que los keyloggers emplean llamadas al sistema operativo de muy bajo nivel. El keylogger ve todo, pero no entiende lo que ve. El navegador también ve todo, pero no utiliza todo lo que ve: no sabe qué hacer con caracteres tecleados en cualquier otra parte salvo los campos de ingreso de texto, y los deja 'caer al suelo'. El keylogger no tiene forma de determinar cuáles pulsos son utilizados por el navegador y cuáles caen al suelo. Es muy fácil grabar todos los tecleos o eventos de mouse (esto es cierto para los sistemas basados en Windows y en Linux [4,7]). También es muy fácil determinar qué aplicación tiene la atención al momento del evento (por ejemplo, este evento fue para el navegador). Pero es muy difícil determinar lo que la aplicación hizo con esos eventos.
Entre los tecleos sucesivos de la contraseña ingresaremos pulsos aleatorios. En el espíritu de desmenuzar y separar [5], la cadena que el keylogger recive contendrá la contraseña, pero enterrada en tanta basura aleatoria que descubrirlo no resulte viable. Hay que notar que no estamos explotando ninguna característica particular de algún navegador en específico: este truco funciona en todas las versiones de Internet Explorer, Netscape Navigator y Mozilla Firefox. Estamos explotando la dificultad que tiene la capa del sistema operativo de determinar cómo la interfaz gráfica de una aplicación maneja los eventos. Entonces, aquí está el método:
Navega a la página de login deseada;
Teclea el usuario;
for (cada caracter de contraseña) {
dar la atención a cualquier punto menos el campo de ingreso de contraseña;
teclear algunos caracteres aleatoriamente;
darle la atención al campo de contraseña;
teclear el siguiente caracter de la contrseña }
enviar;
Esto involucra teclear caracteres aleatorios entre caracteres sucesivos de la contraseña, y cambiando el centro de atención para y del campo de contraseña usando el mouse. En lugar de la constraseña snoopy2 el keylogger ahora obtiene:
hotmail.comspqmlainsdgfsodgfdpuouuyhdg2
Aquí hay un total de 26 caracteres aleatorios que han sido insertados entre los 7 caracteres de la contraseña verdadera. En general, un total de n caracteres extra en una longitud k de contraseña tendría tantas contraseñas posibles que un ataque sería inviable (recordando la contraseña que podía probarse solamente intentando loguearse). Hay varios ataques a este método como explicamos más abajo. Sin embargo, ninguno de los keyloggers revisados en [1] parecen tener la funcionalidad para derrotar a este simple truco.
En lugar de hacer que los usuarios tecleen sus contraseñas, algunos sitios han experimentado con teclados de pantalla como un método para ingreso seguro de datos. Tal como nuestro truco, esto fuerza a los keyloggers a hacer capturas de pantalla en cada click del mouse o a cada evento. Una empresa de seguridad [2] está ofreciendo servicio de login basado en la pantalla a bancos. De nuevo, esto depende del hecho de que un incremento no trivial en los recursos consumidos habrá de ser requerido para capturar estas contrseñas. Lo mismo no es verdad para los teclados de pantalla ofrecidos por las herramientas de accesibilidad de Windows XP (en Programas, Accesorios, Herramientas de Accesibilidad, Teclado en Pantalla). Desafortunadamente esto emula los tecleos y los envía a la aplicación que tiene el centro de atención. Incluso el más simple de los keyloggers va a cachar todas las entradas del teclado en pantalla como si fueran tecleadas.
Probamos cinco keyloggers shareware o comerciales: Homekeylogger 1.70, Ghostkeylogger, KGBkeylogger, Spypector 1.2.8 y ProBot. Ninguno de ellos capturó contraseñas ingresadas usando la técnica que describimos.
Es importante recalcar que esta no es una técnica universal ni durable para el problema de keylogging. Hay muchos trucos en el espacio de la seguridad que funcionan bien cuando se usan por un pequeño grupo de personas, pero que no resistirán los ataques que un despliegue más amplio esperaría traer. La seguridad aquí viene del hecho de que saber lo que una aplicación hace con los pulsos no es trivial para una capa de código que está debajo de esa aplicación. Hacer una captura de pantalla en cada tecleo revelaría cuáles de las teclas usadas en este método pertenecen al contraseña (el campo de contraseña en el navegador indica cuántas teclas se han ingresado). Pero señalamos que capturar la pantalla en cada tecleo incrementa el consumo de recursos por parte del spyware (y por lo tanto, el riesgo de ser detectado) y cosechar contraseñas se hace más difícil de automatizar.
Sin embargo, el simple mecanismo de encerrar la contraseña en tecleos aleatorios para ser extraídos luego es valioso. Aquí hemos insertado las teclas manualmente, y "extraído" sabiendo qué es lo que el navegador deja caer al piso. Hemos señalado que esto puede ser atacado (aunque es suficiente para dar protección real a los usuarios hoy día). Un mecanismo completamente seguro sería extraer los pulsos de algún otro lugar que de la máquina no confiable. En [3] demostramos cómo puede hacerse esto usando un simple servidor proxy. El usuario de nuevo introduce su contraseña embebida en pulsos aleatorios, y el proxy extrae los pulsos usando un secreto compartido entre el usuario y el proxy. De esta forma podemos enteramente evitar que cualquier información acerca de la contraseña quede en la máquina no confiable. Spyware que guarda los tecleos, captura de pantalla y monitorea todo el tráfico de la red todavía no podría descubrir la contraseña sin el secreto compartido. Detalles y variantes en [3].
[1] http://www.keylogger.org
[2] http://www.bharosa.com
[3] D. Florêncio and C. Herley. Entering Passwords on a Spyware Infected Machine Using a Shared Secret proxy. MSR Tech. Report, 2006.
[4] S. McClure, J. Scambray, and G. Kurtz. Hacking Exposed. McAfee, fifth edition, 2005.
[5] R. Rivest. Chaffing and Winnowing: Confidentiality without Encryption. 1998.
http://theory.lcs.mit.edu/~rivest/chaffing.txt.
[6] M. E. Russinovich and D. A. Solomon. Microsoft Windows Internals. Microsoft Press, 2005.
[7] E. Skoudis and L. Zeltser. Malware: Fighting Malicious Code. Prentice Hall, 2004.
Autor(es): Cormac Herley y Dinei Florêncio
Traducción: Roberto Hoyos
En línea desde: 02.03.2007