miércoles, abril 29, 2015

Un Phishing bancario, un Spam en Unicode y la detección temprana

Ayer por la tarde me invitaron a ir a hablar en un programa de televisión sobre las tendencias en el cibercrimen y el fraude online. Una vez más, el tema que salió fue el de los ataques a cuentas bancarias y quiso el destino que me entrara un mensaje de phishing de una campaña de spam que había logrado saltarse el filtro antispam de nuestros servidores de coreo electrónico, así que aproveché dicho ejemplo para la intervención en el programa.

Figura 1: Un Phishing Bancario, un Spam en Unicode y la detección temprana

Este es el mensaje de correo electrónico que se saltó los filtros y hay varios detalles importantes que me gustaría contaros sobre él, ya que no es habitual que me entren este tipo de mensajes en mi inbox, así que os los paso a explicar.

Figura 2: Mensaje de spam con campaña de phishing recibido

Política AntiSpoofing

El equipo de seguridad responsable del dominio santander.com.mx tiene un registro el servidor DNS con una política antispoofing en el correo electrónico basada en SPF1 con valor -all. Esto quiere decir que todo servidor que reciba un correo electrónico de santander.com.mx, si no viene de una de las direcciones IP autorizadas por el registro DNS deberá marcarlo como spam y tirarlo a la carpeta de correo no deseado o directamente a la basura.

Figura 3: Política antispoofing de e-mail en santander.com.mx

En este caso, el correo electrónico ha sido enviado suplantado un subdominio de ese dominio, lo que hace que cuando se consulte la política SPF de ese subdominio el servidor de correo entrante no tiene información para discernir si esta autorizado o no. Esto lo ha aprovechado el atacante para saltarse la protección SPF.

Figura 4: Dirección de correo electrónico suplantada

Las alternativas para detectar esto sería aplicar en los servidores de correo entrantes medidas más exhaustivas en el análisis de correos de subdominios, o establecer políticas restrictivas SPF en todos los subdominios, pero a día de hoy no son eficientes ni 100 % efectivas, por lo que es una puerta que pueden utilizar los phishers. Eso sí, el dominio principal está protegido.

Codificación Unicode Extendida

Como se puede ver en el mensaje, se ha utilizado una codificación de UTF-8 extendida del asunto del mensaje. Esta codificación permite usar caracteres de alfabetos Unicode para lograr un efecto visual similar al que se obtiene con los caracteres con codificación Punycode

Figura 5: Asunto en codificación con caracteres del alfabeto Unicode

Si miramos el código fuente se puede ver que el asunto está codificado entre "=?utf-8?B?" y "?=", y si decodificamos con cualquier decoder para base 64 online se obtendrá el asunto que aparece.

Figura 6: Codificación Unicode UTF-8 del asunto

Este truco ayuda a evitar que los filtros basados en cadenas como "Banca" "Acceso a Banca" o "Bloqueado" detecten cualquier mensaje de correo que esté siendo procesado automáticamente.

Detección temprana

Una de las cosas que piensa la gente es que es fácil para los ladrones de estos sitios conseguir extraer dinero rápido con estos ataques de phishing, pero lo cierto es que cada vez lo tienen mucho más complicado. En este caso, la URL de la web tiene un phishing del Banco de Santander en México, y es bastante aparente.

Figura 7: Sitio web de Phishing

Yo notifiqué este phishing a nuestro equipo de Antifraude interno y me confirmaron que ya lo habían detectado y que tras comprobar que era un phishing activo, se había reportado automáticamente a las casas de antimalware, los servicios antifraude de navegadores y a las bases de datos de seguridad de nuestras alianzas. A los minutos ya estaba marcado en Google SafeBrowsing, como se puede ver.

Figura 8: Al los pocos minutos ya estaba detectado y bloqueado

Todos los que navegaran con Google SafeBrowsing activo ya recibirián una alerta de seguridad como la que puede verse a continuación, limitando el impacto de este phishing muchísimo.

Figura 9: Alerta de seguridad de phishing

Hoy ya está detectado, según Virus Total, también por un buen número de antivirus, lo que limita aún más su posible efectividad.

Figura 10: Detectado como Phishing por más escaners

Protecciones extras para evitar el uso de credenciales robados

Los equipos de seguridad de banca tienen además un buen número de controles para detectar que una credencial ha sido robada en el momento en que se quiere hacer una transacción. Muchos de ellos se basan en el análisis de hábitos de conexión de una determinada cuenta para saber si hay alguna anomalía. Para ello se hace un scoring de cada transacción y se comprueba que es un uso habitual desde una ubicación habitual por lo que si algo cambia, se bloquea la transacción.

Figura 11: Bloqueo de credenciales y transacciones en Caja Mar

Además, los sistemas tienen sistemas de firma de transacciones y protección de cuentas. Habitualmente han usado la famosa tarjeta de coordenadas, pero desde Europa ya se ha dado muerte a este sistema, por lo que muchos bancos pasan al uso de sistemas de firma de transacciones usando OTPs derivados de los datos de la transacción o plataformas como Latch. En el caso de todas las cajas del Grupo CajaMar, por ejemplo, además de proteger la cuenta se pueden restringir las transacciones, por lo que un acceso para consultar no podría realizar la transacción. 

Recomendaciones finales

Aun así, conviene recordar a todo el mundo que los ataques de phishing suelen llegar por e-mail así que no hay que pulsar en ningún enlace, y que el robo de credenciales bancarias más peligroso sigue siendo el de los troyanos bancarios que hacen Man in the Browser, por lo que lo mejor es que tengas un cuidado exquisito de tu equipo de trabajo y lo tengas fortificado al máximo para evitar cualquier sorpresa.

Saludos Malignos!

3 comentarios:

Anónimo dijo...

En este caso el subdominio no existe, y ése es otro chequeo que los servidores de correo hacen cuando reciben un correo entrante. Se podría haber rechazado porque el dominio del remitente no está en el DNS.

En todo caso, el usuario lo que ve cuando recibe un correo es el remitente que viene en la cabecera del mensaje (From). El mecanismo SPF protege al remitente a nivel de transporte (enveloped sender). Para proteger las cabeceras existe otro mecanismo de firma, DKIM.

Saludos.

Maligno dijo...

@Anónimo, la existencia del subdominio no es algo que hagan todos los servidores de correo. De hecho, los que he visto que hacen eso son soluciones antispam.

En el caso de DKIM su uso es para garantizar que el que lo envía es quién dice que lo envía. El Banco de Santader no tiene DKIM publicado y como decía en el artículo de DKIM al final solo se comprueba si viene la firma no si no viene.

DKIM, Domainkeys, Identified Internet Mail y el Spam

Saludos!

Miniyó (en la sombra del Dr. Maligno) dijo...

Chema, releyendo tu entrada en el blog veo que son ataques continuos y da igual usuarios particulares que grandes empresas. Hoy he leído la noticia del robo a Ryanair. Seguramente será que han dado con las claves de algún administrativo haciendo un phishing masivo. Lo he puesto en mi blog Por las noches leo a Chema - Robo a Rayanir

Han prometido dar información detallada del ataque una vez esté aclarado todo. Si puedes ampliar la parte técnica que seguramente no explicarán en ningún canal de tv más allá del morbo del robo de un "hacker".

Saludos.

Entrada destacada

Infraestructuras Críticas y Sistemas Industriales: Auditorías de Seguridad y Fortificación de @0xWord

Desde hoy está disponible a la venta un nuevo libro de 0xWord centrado en la seguridad de los Sistemas Industriales y las Infraestructuras...

Entradas populares