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,

Zeus, o cómo desarrollar un troyano indetectable para la mayoría de antivirus

Hola,

Que confiar toda la seguridad de nuestros equipos a un antivirus es absolutamente inútil es algo que todos sabemos (o deberíamos saber). Que los estudios sobre virus y antivirus propician que cada cual cuente la feria según le ha ido tampoco es una novedad. Que los antivirus, por desgracia, son cada día menos efectivos, es algo que se viene comprobando desde hace bastante tiempo, y buena culpa de ello la tiene la especialización de la industria del malware.

Considerando todo lo anterior, os enlazo un interesante documento que bien podría poner en jaque a la industria antivirus. Se llama Measuring the in-the-wild effectiveness of Antivirus against Zeus, y como su propio nombre indica, es un estudio en el que se trata de analizar la efectividad de los antivirus a la hora de proteger a los usuarios de Zeus.

La familia Zeus, también conocida como Zbot, WSNPOEM, NTOS y PRG, es una familia de troyanos financieros de alta especialización orientados al robo de credenciales. Como buen pack de crimeware, Zeus viene acompañado de un panel de control PHP y un ejecutable para construir el troyano a medida. Entre las poco honrosas habilidades de Zeus se encuentran la capacidad de interceptación de credenciales en cualquier puerto TCP, incluyendo HTTP y HTTPS, la posiiblidad de ser personalizado en el momento de la compilación, comunicación aunque la máquina infectada esté tras NAT mediante un proxy Socks 4/4a/5, o la generación de capturas de pantalla del escritorio de la máquina infectada, por citar algunos ejemplos.

Zeus incorpora una lista de direcciones que, una vez visitadas por la víctima, disparan el proceso de apropiación ilegítima de las credenciales, enviándolas en tiempo real al servidor de destino. También tiene capacidad para inyectar código HTML, superponiendo falsos formularios de autenticación a los legítimos. Zeus también es el nombre de una red de ordenadores infectados (botnet) que sólo en Estados Unidos cuenta con más de 3,5 millones de máquinas infectadas por esta virulenta familia de troyanos.

Pero lo peor de Zeus es que utiliza algunas técnicas rootkit para evadir la detección de los antivirus, y quizás ese sea el factor que hace que sea extremadamente difícil su tratamiento. En el estudio de Trusteer las cifras hablan por sí mismas: después de analizar 10,000 máquinas infectadas, la principal conclusión es que Zeus acaba infectando el 77% de las máquinas con antivirus actualizados, lo que reduce la tasa neta de efectividad a un 23%. Para más inri, la mayoría de las infecciones detectadas (un 55%) correspondía a equipos con antivirus actualizados.

Que sólo un 23% de los despliegues antivirus consiga frenar un troyano y sus variantes es una cifra que debe hacernos pensar y mucho. Yo, si os sirve de algo, os aliento a que dejéis de pensar en que el antivirus que tenéis instalado es el Santo Grial de la protección, y que empecéis a considerar seriamente realizar una navegación responsable, huyendo del software pirata que hay en las redes de pares, los cracks, los keygens y los ficheros ZIP y/o RAR de la mula con las últimas canciones del Bisbal y compañía.

Sí, ya sabemos que según la legislación y jurisprudencia española descargar música sin ánimo de lucro no es un delito, pero la cantidad de descargas que además de la canción del verano incluyen regalito sorpresa es bastante más elevada de la que podáis pensar. Os recomiendo también que evitéis la tentación de ver cuerpos femeninos/masculinos en poses provocativas en páginas de dudoso origen y contenidos, ya que también son fuente habitual de contaminación. Sé que a alguno le costará trabajo, pero le va en ello su salud financiera :)

Un saludo,