Verified by Visa y MasterCard Securecode: cuando se diseñan mal los mecanismos de autenticación

Hola,

Me gustaría enlazar un paper en el que se pone, de una manera ordenada y por escrito, lo que muchos piensan desde hace mucho tiempo: no siempre las implementaciones del protocolo 3-D Secure para tarjetas financieras están bien hechas.

Este protocolo, utilizado en los programas Verified by Visa y MasterCard Securecode, tiene como objetivo principal reducir el fraude con medio de pago no presente. La idea es generar, para cada plástico, un código que será requerido para autenticar una transacción de comercio electrónico. Este código ha de introducirse en una ventana generalmente independiente con el objetivo de que el legítimo titular de la tarjeta demuestre que es él y no otra persona el que está ejecutando la transacción. Este protocolo, tal y como hemos comentado, surgió con la idea de proteger a los usuarios de los fraudes con medio de pago no presente, es decir, de aquellas compras realizadas por los atacantes sin estar en posesión de la tarjeta, pero en las que se utilizan datos previamente adquiridos (generalmente por skimming o troyanización de estaciones), como el titular, el PAN o número de tarjeta, la fecha de caducidad y el código de verificación.

verified by visa

El documento se titula Veri fied by Visa and MasterCard SecureCode: or, How Not to Design Authentication y es una crítica a cómo algunas implementaciones de estos formularios de autenticación de transacciones obvian que al usuario se le lleva años educando para, entre otras cosas, tratar de discernir si el dominio donde introduce datos casa con el dominio habitual de un negocio o empresa, o para advertir la presencia de certificados HTTPS, entre otras cosas. Por otro lado, los navegadores han empujado en este sentido bastante, introduciendo mejoras como la coloración de la barra de herramientas, el resalte del nombre de dominio, la gestión de certificados, los controles antiphishing … todo con una única finalidad: intentar que los usuarios detecten por sí mismos sitios fraudulentos o sospechosos.

Y claro, si implementas 3-D Secure y te cepillas esas medidas, flaco favor le haces a la seguridad de tus clientes y en general, al esfuerzo que durante años muchísimas personas han invertido en tratar de que las cifras de fraude, en vez de aumentar constantemente, se estabilicen o reduzcan.

Un saludo,

Cutrephishing extremo: hágase phishing usted mismo

Buenas,

Aprovechando la migración a Thunderbird 3 he descargado el correo de uno de los pozos de spam con el que tengo la mala costumbre de leer correo basura de vez en cuando.

Me ha sorprendido que en esta época de industrialización de la actividad criminal tecnológica el cutrephishing siga estando vivo. He podido contar hasta 6 mensajes de finales de septiembre que ejemplifican perfectamente que no todo el mundo lleva por bandera la sofisticación. Lógicamente no se trata de un ataque fresco, y de hecho los sitios fraudulentos a los que eran remitidas las credenciales ya no funcionan, pero es un caso curioso que desde luego no suele ser el habitual cuando los amigos de lo ajeno se ponen manos a la obra.

Lo llamativo de este ataque es que es el propio usuario el que tiene que hacerse el phishing a sí mismo. Ni te invitan a seguir un enlace que simula ser la página de tu banco, ni contaminan un sitio legítimo para redirigirte a un sitio malicioso, ni te pretenden colar un troyano financiero con el objetivo de desplumarte. Cualquier cosa vale para tratar de robar datos sensibles, y si no, atentos al ejemplo. Los mensajes de correo fraudulentos que recibe el usuario son similares al siguiente:

phishing cam

El ataque invitaba al usuario a abrir el fichero adjunto y usar el formulario, en este caso, para realizar una hipotética reactivación de su tarjeta. Todo ello en texto plano, y sin look and feel corporativo alguno.

No os creáis que ese fichero es en realidad un downloader camuflado bajo la forma de un fichero HTML. Parte del código de ese fichero es el siguiente:

phishing cam

El adjunto es un triste fichero HTML que pretendía que el usuario introdujese número de tarjeta y PIN:

phishing cam

Lo triste de estos ejemplos es que por muy inverosímiles que parezcan, siempre hay usuarios que acaban picando. No os quepa duda.

Un saludo,