Reflexiones sobre ZeuS Mitmo (Man-in-the-mobile)

Hola,

Tras pegarse 12 horitas analizando una aplicación Symbian S60, el amigo David de S21 ha publicado unas interesantes entradas (Parte I, Parte II, Parte III) sobre ZeuS Mitmo (Man-in-the-mobile).

Interesantes por varios motivos. El primero y más obvio es que los amigos de lo ajeno ratifican que le están metiendo mano a los esquemas de seguridad más recientes en entornos de banca a distancia. También interesante porque estos movimientos dejan entrever que el malware en dispositivos móviles es un campo que por desgracia tiene mucho recorrido para los criminales. Por último, también interesante, estos ataques dejan claro que no todo el mundo está implementando correctamente la autenticación de transacciones (eso dejando a un lado los que se empeñan erróneamente en autenticar a personas)

Cuando se emplea un teléfono móvil como canal alternativo para, repito, autenticar transacciones, no a personas, por obvio que parezca la relación entidad-cliente requiere que este último informe su teléfono móvil. Maneras de que el cliente informe su móvil hay muchas, y creedme, no es tan sencillo como pueda parecer. Cuando se tienen miles, cientos de miles o millones de clientes, los que desarrollan el negocio tienen dificultades muy elevadas para conseguir que el 100% de la masa de clientes informe de su móvil, especialmente en determinados perfiles de clientela más apegados a la bancarización tradicional.

Ante esta disyuntiva existen diferentes maneras de atajar el problema. Desde soportar transaccionalidad en modalidades distintas (los que han informado el móvil emplean el móvil y los que no, emplean medios tradicionales, como las tarjetas de coordenadas, las claves de operaciones, etc.) hasta forzar a la clientela al uso obligatorio de un teléfono si se quiere emplear la banca a distancia. Hay muchas maneras aceptables y seguras de obtener el móvil de un cliente para poder ofrecer autenticación en canal alternativo, como por ejemplo, tener gestores eficaces en la oficina, ofrecer premios o ventajas a quienes informen del teléfono, capturar el dato en la apertura de productos para nuevos clientes, etc. Lógicamente, obtener el teléfono a través de la propia aplicación de banca a distancia es lo más rápido y cómodo, pero lo que demuestra ZeuS Mitmo es que solicitar el teléfono empleando el mismo entorno de banca a distancia puede entrañar riesgos severos. ¿Por qué? Porque los amigos de lo ajeno pueden insertar ahí un troyano que capture los detalles y hacernos descargar una aplicación maliciosa en nuestro teléfono. Y si se contamina el canal alternativo, señoras y señores, a no ser que se disponga de una autenticación de transacciones bien fundamentada y con los debidos puntos de control, game over.

Y hago mención al servidor de aplicaciones porque el fundamento de la autenticación de transacciones no es otro que enviar al canal alternativo un número de autenticación (mTAN) que esté 100% vinculado a cada transacción que se quiera autenticar. Si el mTAN se genera teniendo en cuenta la cuenta origen, la cuenta destino, el importe y otra serie de parámetros, y este mTAN se valida en el lado del servidor, es posible montar un esquema en el que para transferir pasivo de la cuenta A a la cuenta B sólo exista un mTAN que haga que la operación culmine con éxito. ¿Es este esquema invencible? NO. Ni mucho menos, pero puede ser respaldado con medidas que mitiguen el riesgo.

Un troyano puede capturar la cuenta destino sobre la que queremos operar y hacer la transformación a la cuenta destino de los atacantes. Este paquete se envía al servidor de aplicación, se genera el mTAN, confirmamos la operación y otra vez, game over. Lógicamente, si el canal móvil no está contaminado, el cliente debe recibir un mensaje descriptivo que además del mTAN, incluya la cuenta destino y el importe, como último recurso para detectar anormalidad, pero esto no siempre es así. Sea como fuere, parece más que obvio que los atacantes tienen que, en algún momento, vulnerar el esquema para informar del número de cuenta destino malicioso y así poder extraer dinero de la cuenta origen. ¿Es esto una batalla perdida? NO. Si existe un riesgo de modificación de parámetros, ¿por qué no hacer hincapié en medidas como la utilización de libretas de contactos en la propia aplicación? Si en vez de pasar en la petición HTTP un parámetro cuenta destino pasamos un parámetro contacto 25, y el servidor resuelve que el contacto 25 es el código cuenta cliente cuya numeración es XXXX, ¿qué van a modificar los atacantes? Parece que lo tendrán más difícil, aunque siempre podrán intentarlo cuando demos de alta un contacto en la libreta.

Y como punto de defensa final, estando en pleno siglo XXI, yo al menos espero que mi entidad explote adecuadamente un sistema de prevención del fraude que sepa detectar operativa inusual, y si realizo por primera vez una transferencia a un CCC que nunca he utilizado, bien sea a una cuenta de Albacete o a un IBAN de Bielorrusia, yo quiero ver esa operación en rojo carmesí en el SIEM, e incluso prefiero que la operación sea bloqueada hasta que un operador me llame y me confirme si efectivamente quiero transferir 2000 euros a un tal Dimitri de Uzbekistán. Lamentablemente, este planteamiento choca de bruces con el desarrollo de negocio, cuyo único objetivo es que el cliente opere con comodidad y sin restricciones desde su iPad, su iPhone o su PC, con lo que finalmente, muchas de estas operativas se fraguan en fraude consumado.

La banca en línea es un entorno de alto riesgo que está siendo atacado continuamente. La lección más importante que podemos aprender de estos nuevos métodos de ataque es algo que ya sabemos: los amigos de lo ajeno innovan a pasos agigantados. Pero también podemos aprender otra lección, y esa no es otra que los fraudes en entornos complejos son igualmente complejos, y aunque no existe un método perfecto para solventar la papeleta, cuando se tiene un esquema adecuado cuesta muchísimo más atacar a la clientela que cuando se tiene un sistema elemental.

Un saludo,

Operar con más seguridad en banca a distancia empleando sistemas virtualizados

Hola,

Siempre que me preguntan por las mejores prácticas para operar con banca en línea tiendo a hacer el mismo comentario: además de aplicar el sentido común, la mejor manera de prevenir problemas desde el punto de vista técnico es hacer uso de la banca a distancia a través de máquinas que no corran sistemas Microsoft, y si no hay posibilidad o conocimientos, al menos operar en la banca en línea a través de sistemas virtualizados no Microsoft.

No es una recomendación que haga por tener nada en contra de Redmond. Los troyanos orientados a capturar credenciales están diseñados el 99,99% de las veces para funcionar en plataformas Windows, con lo que los agentes maliciosos, simple y llanamente, no funcionan en sistemas que no son Microsoft. Conviene comentar en este punto la excepción de Mac OS, un sistema no Microsoft para el cual sí existen amenazas cada vez más representativas, que aún siendo menos relevantes y abundantes que las diseñadas para plataformas Windows, no deben ser menospreciadas.

Los troyanos más usuales son aquellos orientados a modificar el sistema operativo y sus aplicaciones para, con la máxima transparencia para el usuario, provocar la captura de sus datos financieros, no sólo usuario y contraseña, sino las claves de operaciones y las coordenadas de sus tarjetas (cuando el servicio dispone de doble factor de autenticación/confirmación de operaciones). Así, es frecuente encontrar ejemplares que inyectan código HTML en navegadores, especialmente en Internet Explorer, no sólo para capturar login y pass, sino para inyectar después elaborados formularios HTML donde se insta a los usuarios a introducir la totalidad o parte de su tarjeta de coordenadas. Son frecuentes también los especímenes que capturan todo el tráfico GET/POST en determinados dominios pertenecientes a las bancas en línea, con la esperanza de poder comprometer así datos como la clave de operaciones.

También se han visto ejemplares, menos numerosos, orientados a explotar problemas en Firefox, aunque su número es muy inferior a los que están orientados a Internet Explorer. También los hay que pasan del navegador, ya que actúan sobre el sistema, como por ejemplo, los que modifican los DNS para transportar al usuario a páginas maliciosas, independientemente del producto de navegación que utilicen.

Sea como fuere, a día de hoy, los troyanos se diseñan para funcionar principalmente en Windows. Las razones son varias, siendo la principal que es la plataforma mayoritaria, y por tanto, atacándola, se maximizan la dispersión y rentabilidad de los ataques. Me juego una cena con quien quiera a que la mayoría de factorías de malware, especialmente las últimas en la cadena (las que compran y modifican malware, no las que desarrollan en sí los especímenes) no están capacitadas para programar agentes maliciosos en entornos UNIX, pero este tema no lo vamos a discutir ahora :)

Otra buena razón para que el malware mayoritario esté pensado para plataformas Microsoft y en menor medida, pero creciente, para Mac OS, es el modelo de software privativo con cobro por licencias, que hace que muchos usuarios descarguen software ilegal de redes de pares y servicios de filesharing en vez de adquirirlos de una manera legítima, pagando las correspondientes licencias. Una buena parte del malware reside y se dispersa mediante los cracks y keygens que acompañan descargas ilegales de software. Es frecuente ver también ejecutables acompañando a los ficheros ZIP o RAR que contienen álbumes musicales, o en las colecciones de fotos pornográficas. También abundan en las redes de pares ficheros maliciosos diversos que explotan vulnerabilidades de reproductores multimedia.

El objetivo de este texto es describir cómo podemos acceder a nuestra banca mediante un sistema virtualizado, lo que neutralizará la mayoría de probabilidades de sufrir un robo de credenciales. Y con la gran ventaja de emplear productos seguros y sin coste alguno para el usuario. Adicionalmente hablaremos de:

  • Los riesgos que no mitiga el uso de una máquina virtual no Microsoft.
  • Las características que debe tener un servicio de banca en línea para minimizar las probabilidades de sufrir fraude consumado.
  • Las actitudes que harán que la probabilidad de sufrir fraude sea la menor posible.

Cómo acceder a un servicio de banca en línea a través de una máquina virtual

1. Descargar e instalar Sun VirtualBox xVM

Este producto se puede descargar gratuitamente en http://www.virtualbox.org/wiki/Downloads. El artículo está orientado a usuarios Windows, con lo que hay que descargar e instalar la versión for Windows hosts . Lo normal es instalar la versión x86, a no ser que tengas un AMD 64 y un Windows 64 bits (lo que a día de hoy, no es lo habitual)

Una vez ejecutado, el aspecto que debe presentar el producto debe ser similar al siguiente:

virtualizacion

2. Descargar una distribución Linux para ejecutar en la máquina virtualizada

Opciones en este punto hay muchas, pero por tradición os aconsejo Slax. Se puede descargar en http://www.slax.org/get_slax.php?download=iso. Una vez descargado este fichero ISO (190 MB ocupa la versión 6.0.9) lo colocaremos en una ruta fácil de recordar, por ejemplo, C:\Virtualizacion

virtualizacion

3. Preparación de la máquina virtual

Los pasos a seguir son los siguientes:

  1. Pulsar «Nueva máquina virtual», lo que disparará un asistente para crear la máquina. Pulsamos «Next» (el producto tiene una curiosa mezcla entre inglés y español y hay algunas secciones no traducidas)
  2. En la pantalla, damos nombre a la máquina virtual y seleccionamos el tipo de sistema a virtualizar. No pasa nada si no lo especificamos, pero como sabemos que Slax es Linux, así lo hacemos constar. Una vez terminado, pulsamos «Next».

    virtualizacion

  3. Especificamos el tamaño de la memoria base que será asignada a la máquina virtual. Se recomiendan 256 MB, pero podemos ampliar tranquilamente a, por ejemplo, 1024 MB.
  4. Para asignar disco duro, nos encontramos con que de entrada, no hay disco duro asignado. Pulsamos «Nuevo» y se dispara un nuevo asistente para crear el disco duro a utilizar por la máquina virtual.
  5. Seleccionamos, dentro del asistente, «Imagen de expansión dinámica», lo que creará un espacio adaptativo para las necesidades de disco duro de la distribución a ejecutar.
  6. Damos tamaño al disco duro asignado, por defecto aparecen 8 GB, pero se puede reducir tranquilamente a una cantidad más razonable, por ejemplo, 1 GB. Pulsamos «Next» cuando hayamos terminado este paso.

    virtualizacion

  7. Pulsamos «Finish» para finalizar el proceso de creación del disco duro, lo que nos devolverá a la pantalla «Disco Duro Virtual» que habíamos encontrado antes, pero con la diferencia de que ahora ya tenemos un disco duro asignado. Pulsamos «Next» y luego «Finish» para terminar el asistente.
  8. Una vez hayamos completado los pasos anteriores, el aspecto que debe tener la aplicación debe ser similar al siguiente:

    virtualizacion

  9. Toca por último asignar la imagen ISO de Slax que hemos descargado como el sistema a ejecutar. Para ello pulsamos en «Configuración» y dentro de ese menú, en el submenú «CD/DVD ROM». Marcamos la casilla «Monta la Unidad de CD/DVD» y seleccionamos el tipo «Archivo de Imagen ISO». Pulsamos el icono a la derecha de la opción «Archivo de Imagen ISO» y agregamos la imagen ISO. Se dispara un nuevo asistente:

    virtualizacion

    Pulsamos «Agregar» y seleccionamos la imagen ISO que hemos descargado (la que hemos guardado en C:\Virtualizacion). Cuando hayamos localizado la imagen pulsamos «Seleccionar». Retornamos al menú anterior, el cual debería presentar un aspecto similar al siguiente:

    virtualizacion

  10. Pulsamos «Aceptar», y ya estamos en condiciones de ejecutar la máquina virtual.

4. Ejecución de la máquina virtual

Basta con pulsar el botón «Iniciar» en la pantalla principal de Sun VirtualBox xVM. Debería presentarse la siguiente ventana:

virtualizacion

La mejor opción es la ejecución con entorno gráfico KDE, que se disparará automáticamente. Suele ser normal que aparezca un mensaje de memoria baja, dependiendo de la reserva de memoria que hayamos hecho antes. Aunque este error no bloquea la máquina, hace recomendable aumentar la cantidad de RAM asignada a la máquina para que funcione adecuadamente. Esto se puede hacer en el menú «Configuración» de Sun VirtualBox xVM.

virtualizacion

Finalmente, tras la carga, el sistema se inicia. Ya tenemos un Linux Slax corriendo virtualizado, con el que podemos navegar a nuestra banca en línea tranquilamente. Con un doble click en la ventana, el teclado y el ratón funcionarán en la máquina virtual. Si queremos hacerlo en el sistema Windows, pulsamos el botón control derecho, y saldremos de la máquina.

virtualizacion

5. Navegar con la máquina virtual

Slax cuenta con un cuidado aspecto gráfico y contiene numerosas aplicaciones, entre las que está Konqueror. Como la máquina virtual toma la configuración de red de la máquina Windows subyacente, no hay que configurar nada. Estamos listos para navegar.

virtualizacion

El objetivo de todo lo que hemos hecho es poder acceder a nuestra banca en línea a través de un producto ajeno a los problemas de seguridad y condiciones de contorno que explotan habitualmente los troyanos. Al emplear una máquina virtual basada en UNIX, los troyanos mayoritarios no funcionarán, sencillamente, porque no pueden funcionar en un entorno Linux. Tampoco funcionarán las amenazas específicas orientadas a Internet Explorer, Firefox sobre Windows y en general, a cualquier amenaza que intente explotar problemas de seguridad en Windows y los productos que lo suelen acompañar (Java, Flash, etc). Pero no es oro todo lo que reluce …

¿De qué NO protege una máquina virtual?

Aunque la ganancia en seguridad en nuestras operaciones en línea es más que notoria, la virtualización no es la panacea, y existen algunas problemáticas que no se resuelven empleando estas soluciones:

  1. Phishing convencional y en general, cualquier ataque de ingeniería social. Si sigues un enlace falso que te lleva a una página modificada, e introduces tus datos, da igual que lo hagas en Linux o en Windows: tus datos estarán en manos de los atacantes.
  2. Sniffing o captura de tráfico. El tráfico provocado por nuestras acciones en la máquina virtual sale a Internet por el mismo adaptador que el sistema Windows, con lo que el tráfico generado puede ser capturado por agentes maliciosos. Desde el punto de vista del adaptador, si la banca opera en HTTPS (la amplia mayoría lo hace hace tiempo), el tráfico que podemos capturar estará cifrado y será inservible. Sin embargo, un proxy instalado entre el navegador y la salida a red podría capturar en claro nuestros datos, aunque esta posibilidad es descartable empleando una distribución como Slax, ya que requiere contaminación en origen, la cual, aún siendo factible, es de escasa probabilidad.
  3. Contaminación de nuestro enrutado. Si nuestro router está comprometido, es posible redirigir el tráfico a páginas maliciosas desde el hardware (routers, principalmente), aunque hayamos tecleado en el navegador de la máquina virtual una página legítima. Esta probabilidad, aunque existe, es de reducida probabilidad, pero debe ser tenida en cuenta.
  4. Contaminación de la distribución en origen. No es algo frecuente, pero ha sucedido. Este problema se puede solventar comprobando que las sumas de control del fichero ISO que descargamos coinciden con los anunciados por los autores de la distribución.
  5. Facilitar las claves y las tarjetas de coordenadas a otras personas. Da igual si usas Windows o Linux. Si le das las claves a alguien, esa persona puede ejecutar en tu nombre operaciones, con lo que conviene extremar las precauciones en este sentido.
  6. En general, gestionar mal la conservación confidencial de las claves, facilitando que en un evento de pérdida, despiste o sustracción alguien se haga con la totalidad de elementos necesarios para operar.

¿Qué características en un servicio de banca en línea dificultan la consumación del fraude?

  1. Tráfico HTTPS, por las razones que hemos comentado anteriormente.
  2. Empleo de doble factor. Los dobles factores pueden estar en la autenticación, en la confirmación de operaciones o en ambos sitios. La ventaja de disponer de doble factor de autenticación es impedir el acceso a nuestros datos financieros a los usuarios ilegítimos, que aunque no puedan operar en ausencia de claves de operación, pueden obtener un perfil para ejecutar acciones de extorsión.
  3. Alertas al móvil. Un sistema que nos envíe un mensaje cada vez que realizamos una operación o cambiamos una clave puede ayudarnos a identificar preventivamente un acceso ilegítimo.
  4. Servicio real 24×7 de atención telefónica y bloqueo, para poder requerir, ante la sospecha de compromiso, el bloqueo de nuestra cuenta en línea, así como de los productos financieros asociados (tarjetas, especialmente). Estos servicios deben además ser preventivos, ejecutando autónomamente bloqueos ante la sospecha de contaminación.
  5. Existencia de límites para operaciones. La existencia de límites permite mitigar para los distintos canales el importe de las cantidades que nos pueden sustraer, en caso de que finalmente seamos víctimas de un fraude.

¿Qué actitudes minimizan los riesgos de ser vícitmas del fraude?

  1. Navegación prudente y responsable. No visitar enlaces dudosos es una garantía de éxito. Extremar las precauciones en las redes P2P de intercambio, donde es frecuente encontrar malware.
  2. Mantenimiento adecuado del sistema operativo y sus aplicaciones. Tener al día los productos, instalando los parches recomendados, es siempre un factor mitigante.
  3. Aunque maniobremos en Internet con una máquina no Microsoft, conviene tener instalado y actualizado un producto antivirus, para minimizar los impactos restantes que procedan del correo, de la mensajería instantánea, de las redes P2P, etc.
  4. Sentido común. Recelar de lo sospechoso siempre conduce a la toma de decisiones adecuadas.

Un saludo para todos,