Keyloggers y protecciones de credenciales en banca online (y II)

miércoles, 24 de julio de 2013

Los keyloggers o registradores de teclas han supuesto un problema de seguridad desde el principio de los tiempos. Todavía son usados y su capacidad para capturar contraseñas sigue siendo muy considerada por atacantes. Más aún cuando los métodos de pago y la banca online son tan populares (y siguen protegidos fundamentalmente por contraseñas y sus variantes). A pesar de su veteranía y de los distintos métodos aplicados para combatir el malware que recoge lo escrito en el teclado, ¿siguen suponiendo un problema? ¿Los hemos superado?

Doble canal

Dando por hecho que el malware campando a sus anchas en un sistema infectado tiene toda la ventaja, las entidades de pago necesitaban un doble canal de autenticación. Los OTP son caros, pero el móvil es ubicuo. Este método se supone muy seguro por definición: habría que infectar los dos dispositivos para que el atacante pudiese realmente conseguir información valiosa. El problema es que Android en estos momentos permite la instalación de cualquier aplicación y, por tanto, resulta sencillo de infectar. El usuario, creyendo que necesita una aplicación para autenticarse, instala también un troyano en su teléfono Android. El atacante registra la información del sistema y la del móvil. Ya dispone de todo lo necesario para robar.

Troyano para Android que reenvía los SMS enviados por la banca online
¿Y por qué no la red?

Tras el breve (e incompleto) resumen descrito, podemos centrarnos en el tráfico de red, un punto interesante. Todo lo que ocurre en pantalla (las pulsaciones del teclado virtual, la introducción de la contraseña con el portapapeles...) al final acaba viajando por la red. Podríamos pensar que es un asunto ya superado, puesto que ¿qué banco no utiliza ya cifrado punto a punto con SSL/TLS que impide el acceso a la información? Pero cuando el malware controla en el sistema operativo y no al revés, tiene acceso a los datos de red a nivel de navegador, antes y después de que sean cifrados. Cualquier troyano medianamente avanzado hoy en día controla, almacena y envía al atacante el tráfico que viaja hacia el banco. Toda labor de ofuscación en la pantalla queda en nada si luego es enviado en texto claro por la red. ¿Cómo se combate esto?

Algunos programadores ofuscan la información. Suelen utilizar funciones JavaScript para "ocultar" la información antes de enviarla a la página que debe validarla. El atacante obtendrá los datos codificados si esnifa la red. Pero como toda seguridad por oscuridad, solo tiene que estudiar el JavaScript de la página y revertirlo para comprobar cómo se ha ofuscado. No es realmente una solución definitiva.

Otros cifran la información que viajará a su vez cifrada por SSL/TLS. Pero hay formas y formas de hacerlo. Cifrar la información con un valor fijo, aunque se utilicen de algoritmos estándar, sigue siendo seguridad por oscuridad, con lo que no es realmente eficaz. La clave de cifrado de la contraseña debe ser variable. Se debe implementar un "desafío-respuesta" entre la web que autentica y el cliente. Por ejemplo, el banco envía una contraseña variable en cada sesión con la que se cifrará (con AES, o DES...) la contraseña introducida por el usuario. Todo esto viajará por la red. Pero entramos en uno de los problemas más antiguos del juego del cifrado: ¿cómo envía el banco a través de un medio inseguro (y de forma cómoda para el usuario) la contraseña "primigenia" con la que cifrar las otras credenciales? Si el atacante está en la red y puede ver el tráfico en texto claro, también podría llegar a conocer la primera contraseña enviada, por muy variable o ofuscada que esté.

Tráfico POST hacia una banca online que envía la contraseña sin ofuscar ni cifrar
Actualmente muchas entidades optan por enviarla en texto claro en el hipotético caso de que implementen un sistema de este tipo. Pero por ahora (y solo por ahora) estas entidades están relativamente a salvo de los troyanos bancarios tradicionales... por una razón curiosa.

El malware tradicional espía la red, pero no puede espiarlo "todo". Ante la cantidad de información que recogen y el número de infectados, deben saber descartar lo que no les vaya a suponer un beneficio inmediato. Así que suelen activarse para recoger la información del tráfico de páginas cifradas (sea cual sea, si va por SSL, es que viaja información sensible) y de formularios en general que estén marcados como "password". Pero... incluso así no suelen recogerlo-robarlo todo. Deben descartar también el tráfico cifrado entrante. Al malware no le interesa robar el tráfico que viene hacia el sistema del usuario, solo el saliente, el que contiene los POSTS con los datos. Así que los ladrones no suelen cazar una hipotética clave "primigenia" con la que cifrar la información y que vendría definida por el banco con el tráfico entrante, por simple economización de recursos y por no incrementar el volumen de datos robados. El banco, por ahora, puede respirar un poco más tranquilo... a menos, eso sí, que los atacantes estudien específicamente estas características y decidan incluirlo en el código del malware.

En resumen, en un sistema infectado, toda medida puede ayudar a mitigar (y solo mitigar) el malware más genérico, y esto convierte a la guerra contra los keyloggers y "sniffers" en una huída hacia adelante en el que solo se está a salvo mientras la contramedida tomada no sea tan popular que los atacantes decidan incluir un ataque específico de serie en su arsenal. ¿Está perdida la guerra? Solo sabemos que se necesita un enfoque de autenticación muy diferente al actual para evitar que tenga éxito.

* Keyloggers y protecciones de credenciales en banca online (I)

Sergio de los Santos
ssantos@11paths.com
@ssantosv

No hay comentarios:

Publicar un comentario