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

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)