Skip to content

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

Publicado por Sergio Hernando el 26 septiembre 2010

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,

Be Sociable, Share!

Categoría/s → Seguridad

6 comentarios
  1. 26 septiembre 2010
    Luis permalink

    La mayoría de entidades financieras utilizan sistemas para bloquear las transferencias sospechosas, aunque es cierto que se llevan utilizando menos tiempo que en el control de transacciones de tarjetas de crédito.

  2. 26 septiembre 2010
    Iker permalink

    Habitualmente cuando se habla de fraude en Banca Online (lógicamente) hablamos de fraude en transferencias “online” y el cosecuente robo de dinero.

    Pero … (ya se que no está ligado al tema online) pero que hay del fraude físico ¿? es decir clonado de tarjetas y su posterior uso para realiazar pagos no autorizados ¿?

    Me parece un tema interesante … no tan extendido a nivel informativo (y concienciación) como el tema fraude online pero que lo identifico a la orden del día.

    Las preguntas que me hago en relación a este tipo de fraude son variadas:

    Que medidas han adoptado los bancos ¿? que medidas tenemos que adoptar nosotros ¿? Las que actualmente existen son suficientes ¿?

    (En el caso del fraude Online al estar todo centrado dentro del mundo digital entiendo que para las empresas de seguridad y FSE el hacer un seguimiento del robo es relativamente más facil que en el caso de clonado de tarjetas)

    Puede ser un tema a analizar en sucesivos post del blog :p

  3. 26 septiembre 2010

    Iker,

    El tema de las tarjetas tiene un trasfondo distinto, aunque últimamente también lo comparte con los fraudes exclusivamente digitales (robo de datos de tarjeta mediante troyanos)

    La mayoría de instituciones han hecho inversiones o planean hacer inversiones elevadas en mecanismos de prevención del fraude, y en paralelo, han puesto a disposición de los clientes medidas como las alertas al móvil y más recientemente, EMV y mejores autoservicios y terminales de pago para tratar de reducir el impacto del fraude.

    Yo creo que para el tema de tarjetas las medidas actuales son suficientes. Son mejorables en muchos casos, como por ejemplo, cuando se hacen compras por Internet, pero en el plano físico deberían bastar si el cliente pone de su parte (operando en el cajero tapando su PIN, evitando terminales sospechosos, gestionando bien su PIN,o inspeccionando el cajero antes de operar en él)

    Es un tema del que he hablado en muchas ocasiones en el blog, pero anoto la recomendación para volver a sacarlo :)

    Un saludo,

  4. 26 septiembre 2010

    Luis,

    Aunque se tengan sistemas vanguardistas, estos sólo sirven para ponerle en bandeja al SOC de turno los eventos más relevantes, los cuales necesitan intervención humana.

    Ojalá todo fuera cuestión de sistemas.

  5. 28 septiembre 2010
    Álvaro Del Hoyo permalink

    Buenas, Sergio

    Mobipay precisamente lo que hacía en el caso de pagos de comercio electrónico, un caso similar a la autorización de transferencias en la banca online, era ofrecerta la posibilidad de pagar con el servicio Mobipay, al hacer click se te presentaba en pantalla una referencia USSD asociada unívocamente a la transacción (comercio, producto o servicio, importe,…), el usuario abría una sesión USSD con esa referencia desde su teléfono, y a continuación Mobipay te identificaba en el diálogo USSD que estabas haciendo una transacción por importe X en el comercio Y solicitándote autorización para autorizar, firmar la operación, cosa que se hacía eligiendo un medio de pago en la cartera virtual Mobipay y enviando el PIN asociada a la misma.

    Lo que se podría haber hecho TAMBIÉN con Mobipay para autenticar transacciones con el móvil: exactamente lo mismo que propones en tu post.

    Desconozco en manos de quién fueron a parar las patentes sobre la solución Mobipay tanto en España como a nivel internacional, pero me parece una irresponsabilidad que no se emplee en nuestro país.

    Enhorabuena por el post.

    Un saludo

Trackbacks & Pingbacks

  1. de la red – 27/09/2010 « Tecnologías y su contexto

Escribir un comentario

Note: XHTML permitido. Tu email nunca será publicado.

Suscribirse a los comentarios via RSS