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,