lunes, 22 de agosto de 2016

Sigue el phishing a la Pass

No hace mucho me quejaba de no haber podido llegar lo suficientemente pronto para poner a la gente sobre aviso de un phishing a la tarjeta Carrefour Pass. Esta vez espero de poder ser de más ayuda.

Toda vez que los phishers han tenido ya problemas con su anterior infraestructura... se han montado una nueva y ¡a seguir con el negocio!

Hoy se han recibido dos mensajes que simulan proceder de dos direcciones de correo distintas del dominio "carrefour.es":


La imagen de logo de la cabecera, que no es mostrada por  Thunderbird al tratarse de contenido remoto, vuelve a ser aquella que sacaban de una web de un torneo de fútbol sala:


Los mensajes tienen el mismo texto, pero el destino del enlace "Confirmar ahora" es distinto. Eso sí, ambos pertenecen al mismo dominio. Y ¡oh sorpresa! las páginas de destino simulan ser formularios de acceso. Eso sí, con las mismas modificaciones que en la vez anterior. El mismo GET sobre HTTP:


Un dominio, typosquatting incluido (le falta una "r"), registrado hace una semana:


Esto hace que me vuelva a hacer las preguntas de ayer. Por más controles y medidas de protección que tengan tus sistemas, si no es difícil enviar correos fraudulentos cuyos remitentes parezcan pertenecer a tu organización y hay montones de dominios descontrolados que pueden ser utilizados en campañas de phishing contra ti... ¿es seguro tu servicio?

Y a todo esto, si pensabas que el dominio con las dos "r" era legítimo...


Los DNS de éste pertenecen a un dominio, "spam-and-abuse.com", propiedad del registrador de dominios GoDaddy. Creo que el nombre deja claro para qué lo usan. Buena cosa es ver que alguien hace algo.


domingo, 21 de agosto de 2016

¿Hasta dónde llegar?

El otro día, cuando veíamos lo del phishing a Carrefour Pass, dejaba caer una cosa que me había llamado la atención: Carrefour no era titular de un dominio que muchos habríamos dado por bueno si nos lo encontramos por ahí:


Estuve echando un rato, no demasiado largo, con la cabeza puesta en los nombres de dominio razonables y el typosquatting. Y nuestro ejemplo no era un caso aislado:

Quisiera poner en orden mis ideas y no centrar el tema en Carrefour, que ciertamente no es la única organización con este tipo de problemas, ni en los registradores de estos dominios, sobre cuyas intenciones no podría pronunciarme. Ni tampoco sólo en los dominios registrados, pues hay otros parecidos a los anteriores que aún no lo están. Quisiera tener respuestas y sólo me salen preguntas.

Con el paso del tiempo, veo como términos que antes sonaban muy bien se van quedando cortos. Muy cortos. Como "Seguridad Informática", que al centrarse más en las herramientas que en los objetivos, fue (o está siendo, según el caso) paulatinamente sustituido por "Seguridad de la Información".

Pero la información es escurridiza. Difícil de guardar. Y las formas de llegar a ella son, por otro lado, prácticamente ilimitadas. En esas condiciones... ¿Hasta qué punto se puede esperar que una organización registre todos los dominios que pudieran confundirse o asociarse con sus servicios, productos y marcas, incluyendo aquellos que consisten en un error ortográfico o de escritura? ¿Hasta dónde sería preciso llegar en ese frenesí registrador?

Y, por otro lado... ¿puede considerarse seguro un servicio si existen nombres de dominios que podrían ser utilizados de forma creíble para hacer phishing relacionado con él?

¿Podría regularse de alguna manera este tema? ¿Tendría cabida, por citar algún ejemplo, en la normativa sobre Protección de Datos o en el Esquema Nacional de Seguridad?

Lo que sí tengo claro es que se trata de algo que incide directamente sobre la seguridad. Y no hablo ya de "Seguridad de la Información", término al que creo que también le llegó ya su hora. Seguridad financiera. Seguridad patrimonial. Seguridad jurídica. Seguridad personal y de la privacidad y la intimidad. Seguridad de la imagen y la marca...

Seguridad. Sin matices añadidos. O se mira de forma global o se pierden de vista los detalles.

martes, 16 de agosto de 2016

Phishing a la Pass

Confieso que querría haber escrito antes este post. Habría sido mucho más útil. Pero a veces las cosas vienen como vienen y los datos llegan cuando llegan... Si no de aviso, al menos servirá para ver cómo los malos hicieron las cosas.

Hace unos días me llamó un conocido. Le habían llegado dos correos de Carrefour diciéndole que tenía bloqueada su tarjeta Pass y que tenía que desbloquearla. Pero él acababa de usarla sin problemas.

Tras pedirle que me reenviara los mensajes (como adjuntos) y que me hiciera alguna captura de pantalla, le di los consejos de rigor: que no hiciera nunca clic en los enlaces del mensaje; que, llegado el caso, pusiera él la dirección en la barra del navegador, etc.

Ahora que me llegó cuanto le solicitaba puedo compartirlo aquí. Tarde, sí, pero quizá mejor que nunca.

Se trataba de dos mensajes de correo. Uno del día 11:

 Y otro del 12:
Ni que decir tiene que cambié los datos del destinatario del mensaje.

La verdad es que, comparándolos, el primero parece más trabajado. Eso sí, el otro tiene un remitente más acojonante: "emergencias@carrefour.es". En todo caso, ambos indican provenir de direcciones de correo verosímiles.

El primero te alaba las bondades de la tarjeta para después decirte que la tuya está "desactivada por las nuevas normas de seguridad" (¡cachis!) y termina con "Este email es resultado de una investigación Carrefour S.A.". Supongo que por eso de asustar. Indican además los cuatro primeros dígitos del número de tarjeta y el resto va en asteriscos. Ciertamente, ocultar parte de la numeración es una práctica habitual en las comunicaciones. Por si acaso. Pero es que los primeros cuatro dígitos forman parte de la identificación del emisor de la tarjeta y, claro, son conocidos.

Eso sí, quizá llamen la atención esos caracteres raros que aparecen salpicados por el texto. Y es que, en lugar de las típicas entidades "á", "é", etc., en estos mensajes las vocales acentuadas se pusieron tal cual:

En la imagen anterior, aparece otra cosa sospechosa: La URL de la que sacan el logo de Carrefour. El sitio en cuestión parece de lo más legítimo. Dedicado a un torneo de fútbol sala o algo que se le parece mucho. Lo que pasa es que la empresa tiene un equipo inscrito en él...

Y... ¿para qué iban los phishers a buscar más si ahí está el logo?

La cosa se comienza a poner caliente cuando se llega al botón para restablecer tu tarjeta:

A fecha de hoy ninguna de las dos URL que aparecen en la imagen llevan a nada interesante pero, cuando se hicieron las pruebas, una de ellas redirigía a una página cuando menos curiosa:

Algo parecido se puede ver por algunas páginas de Internet que tomaron sus "fotografías" en el momento oportuno. Como ésta:

... o esta otra:


Bastante parecidas a la legítima página de inicio de sesión de los clientes de la tarjeta Pass ¿verdad? No es de extrañar, visto lo que aparece en su código HTML:


O sea, duplicada del original con HTTrack, un programa que hace copias de sitios web para su posterior consulta offline. Claro que, aunque la apariencia sea similar, los phishers introdujeron sus cambios. Y... ¿dónde mejor que en el formulario de inicio de sesión?


Bien comienza la cosa: método GET y uso de HTTP. Nada que ver con el POST sobre HTTPS de Carrefour. Y, por supuesto, a una página del dominio controlado por los phishers. Dominio cuyos datos de registro tampoco auguran nada bueno:

Un nombre de contacto raro con ganas y una cuenta de correo de Yahoo. Cabe aquí preguntarse: ¿qué comprobaciones se hacen sobre los datos proporcionados para registrar un dominio .es?

Y la respuesta es rotunda: DEPENDE. Porque cuando se quiere registrar un dominio .es, la autoridad "dominios.es" ofrece dos opciones: ellos mismos y un agente registrador:

Y, mientras "dominios.es" te pide muchos datos y "muy oficiales":


... hay otros que no exigen tanto. Como el usado por los phishers en esta ocasión (y, curiosamente, también por Carrefour): KEY-SYSTEMS. Esta empresa ofrece varias alternativas dependiendo del perfil del cliente

Y si nos vamos al registro de usuarios de la de "individuos y pequeñas y medianas empresas", los datos personales solicitados son más ligeritos...

Por no hablar de las formas de pago

A una empresa como ésta, verificar la autenticidad de la información introducida le puede resultar complicado y eso le viene bien a los phishers. Y también lo hace el uso de PayPal, que les ayuda a mantener el anonimato.

Que Carrefour no hubiera registrado este dominio de forma preventiva tampoco es tan raro. Son demasiadas las combinaciones posibles y nadie puede abarcarlo todo. Pero lo que sí me llamó la atención fue este otro, que podría llevar a error hasta a las personas más experimentadas, y que al parecer tampoco está bajo su control:

Espero que ni su actual propietario ni ninguno de los futuros se proponga utilizar este dominio para cosas malas. Miedo me daría, porque llevaría todas las papeletas para tener éxito en su empeño. Actualmente este dominio parece que no aloja contenidos. Lo único que pude encontrar en el poco tiempo que le dediqué fue unos cuantos nombres de domino y URLs proporcionadas por Google:


Sitio por defectos, sitios para móviles, página que parece destinada a la autenticación de usuarios o a información sobre seguridad... El futuro dirá lo que encontraremos ahí.

Y queda una cosa por señalar. Los phishers spoofearon cuentas de correo del dominio "carrefour.es". Ya sé que en estas cosas intervienen tanto los servidores de origen como los de destino pero... ¿utiliza este dominio cosas como SPF, DKIM o DMARC para tratar de evitarlo?

Utilizando la herramienta de MXTOOLBOX se puede hacer unas cuantas pruebas rápidas. Al parecer, "carrefour.es" no utiliza SPF, aunque otros dominios de él dependientes como "envios.carrefour.es" sí lo hacen:


No es de extrañar que se aceptara un mensaje que venía de una IP

... alojada, por lo que indica Robtex, en un hosting en Australia que no recuerda para nada a Carrefour.


Y, por otro lado, según MXTOOLBOX, "carrefour.es" tampoco ofrece registros MX:


Y si de DMARC se trata...

Saludos

lunes, 8 de agosto de 2016

Conseguir que tus aplicaciones sean seguras (o al menos, intentarlo) 2

Si limitar las aplicaciones que tus usuarios pueden utilizar te parece divertido, posiblemente no hayas pensado en lo que se te viene encima. Ahora tienes un conjunto de aplicaciones en las que centrarte y te toca hacerlo. Para empezar, tendrás que monitorizar los problemas de seguridad que pudieran afectar a cada instalación particular que tengas de cada software.

¿De dónde pueden venir los problemas? Poca cosa:
  • Vulnerabilidades del propio software.
  • Dependencias. Por ejemplo: que el software sólo funcione con una versión obsoleta de Java o de Flash. O que utilice una librería a la que se han encontrado fallos, como el reciente problema de Imagemagick.
  • Software mal configurado.
  • Fallos del software que obliguen a utilizar una configuración insegura. Como que no funcione correctamente el uso de contraseñas a la hora de acceder a carpetas compartidas y haya que establecer en éstas permisos del tipo "acceso total para todo el mundo".
  • Interrelaciones entre software que supongan merma para la seguridad. Por poner un caso: quizá nuestro software tenga que conectarse con un servicio web. Si éste no funciona sobre HTTPS, el uso de HTTP supondría el correspondiente riesgo de intercepción y/o modificación de peticiones y respuestas
  • etc.
Pero si conocer dónde puede estar el problema es importante, no lo es menos enterarse de que existe. Y aquí también tenemos distintas opciones. Ten en cuenta que no son excluyentes entre sí, de modo que tienes que ir preparando unos cuantos canales. Entre ellos:
  • Pruebas realizadas por tu organización: análisis de vulnerabilidades, tests de intrusión internos, etc.
  • Repaso de logs que pudieran encontrar ataques, ya fueran estos exitosos o no.
  • Información proporcionada por los distintos CERT.
  • Boletines de seguridad de los desarrolladores.
  • Repositorios de vulnerabilidades tipo CVE.
  • Otras organizaciones y fuentes de información (blogs, foros,...) relacionadas con la seguridad de la información.
  • Notificaciones por parte de profesionales de, y aficionados a, la seguridad que pudieran encontrar las vulnerabilidades. Dado que por este conducto puede llegarnos información muy cualificada (al menos, a veces) es muy importante cuidarlo y asegurarnos de que existan dos cosas y de que estén claras desde el principio:
    • Un cauce para que estas personas puedan realizar las comunicaciones.
    • Un marco en el que se deje claro qué se les permite y qué no hacer y cómo se va a tratar la información proporcionada.
A este respecto se me viene a la cabeza un antiguo artículo de Chema Alonso sobre la propuesta de un archivo "hackers.txt". Algo similar al "robots.txt", pero para gente de este mundillo.
 
Por no acabar este post sin poner otro par de listas, un elemento que puede complicarte la vida es lo variado de los tipos de software con los que puedes terminar trabajando. Una posible clasificación sería:
  • Software libre, en distribuciones originales o modifados por terceros.
  • Software libre modificado por tu organización. 
  • Software hecho a medida, bien por tu organización o por terceros.
  • Otro software propietario.
Dependiendo de en cuál puedas catalogar el sistema que presenta la vulnerabilidad, y de la naturaleza de ésta, tendrás una serie de opciones para corregir la situación:
  • Modificar la configuración del software. Posiblemente estés deseando que sea esto lo que haya que hacer.
  • Obtener una nueva versión del producto, o de las dependencias afectadas, y aplicarla. En este caso, la fuente de esta nueva versión podría ser:
    • El desarrollador del software afectado. Esta solución suele ser la mejor pues ofrece mayores garantías de continuidad en el futuro. Téngase en cuenta que el resto de opciones puede suponer tener que seguir manteniendo el software en el futuro sin el soporte de su desarrollador, quizá con medios propios. Y medios no siempre sobran...
    • Un tercero que ofrezca modificaciones del software (forks). En este caso, mejor que elijas algo fiable y con garantías de futuro.
    • Una modificación o desarrollo propio. O una modificación o desarrollo contratada a un tercero. Ya sabes que ésta te seguirá dando qué hacer durante mucho tiempo...
  • Plantearte la sustitución del producto afectado por otro que proporcione las mismas funcionalidades, pero que sea más seguro.
Tanto si obtienes una nueva versión y la aplicas como si cambias de software tendrás que actualizar la lista de software aprobado.

Eso, como se comentaba en el post anterior, tenía necesariamente su complejidad admistrativa. Pero no nos olvidemos de la parte técnica: ¿cómo elegir o, en su caso, desarrollar el software?

martes, 2 de agosto de 2016

¡Qué poco dura la alegría en la casa del pobre!

Quizá te haya pasado: Tienes un blog o un sitio web que apenas recibe visitas y un día, de pronto, cuando, de puro aburrido, compruebas si alguien ha visualizado alguna de sus páginas... ¡guau! ¡los contadores se han disparado y parece que comienzas a tener toda esa relevancia que siempre creíste merecer!

Bueno, sí, puede que sea eso. Pero es más probable que hayas sido víctima de un ataque de "SPAM de Rererer". Alguien ha puesto un programita a hacerte visitas incluyendo una cabecera "Referer" con una determinada URL. Una URL cuyo documento, por supuesto, no incluye ninguna referencia a tu sitio web.

¿Para qué?

Para empezar, si tu sitio tiene alguna página de estadísticas de acceso, en ella podría aparecer la URL que te enviaron como Referer. Y, si los bots de los buscadores la ven... ya sabes cómo interesa a cierta gente que haya enlaces a sus páginas y qué son capaces de hacer para conseguirlos.

Pero lo más probable es que se trate de una técnica de Ingeniería Social. Si, al revisar tus estadísticas, ves que recibes muchas visitas desde una URL, quizá te pique la curiosidad y quieras saber qué dicen de ti. Si te recomiendan o te critican. Si se trata de otra web con una temática similar a la tuya que podría interesarte. Si...

Y vas y visitas esa URL para comprobarlo.

A partir de ahí puede pasar cualquier cosa: que te intenten vender algo, que te traten de colar malware, que recopilen de ti toda la información que tu navegador proporciona (que no es poca) y la procesen para preparar un posterior ataque "más grave"... ¡cualquier cosa que pudiera ocurrírsete y alguna otra más!

Por supuesto, si tienes un sitio web popular posiblemente no repares en el Referer que te envían como SPAM. Quizá ni siquiera aparezca en las estadísticas de acceo. Quedará relegado a un puesto poco visible entre tantas visitas legítimas.

Pero si, como comenzaba planteando al principio, apenas tienes quien te lea... ¡entonces sí que aparecerá en lugar destacado en tus estadísticas, tentador e insinuante!

Lo dicho: ¡Qué poco dura la alegría en la casa del pobre!

lunes, 1 de agosto de 2016

Conseguir que tus aplicaciones sean seguras (o al menos, intentarlo) 1

La petición no presagiaba nada bueno:
- Tú que haces cosas de hacking y eso... ¿podrías decirnos cómo conseguir que nuestras aplicaciones sean completamente seguras?

Menos mal que esta vez tenía una respuesta:
-No podéis. Decir "completamente seguras" es como decir "perfecto". Y no existe nada perfecto.

- Vaya. Pero, al menos, podrías hacernos un listado de pruebas a realizar a los programas y cosas así.

Otra vez lo mismo. ¡empezar la casa por el tejado! Al final quedé en mandarles un documento con recomendaciones. No era la primera vez que me encontraba con esta situación ni que trataba el tema, de modo que tengo claro qué proponer. Y también que no es lo que esperan de mí, porque porque los consejos que suelo dar no tienen demasiado que ver con el hacking y sí con el sentido común y la gestión.

Eso sí, que nadie espere que vaya a ser fácil.

Para empezar, unas preguntas: ¿perteneces a una organización que te da recursos ilimitados para hacer tu trabajo? ¿todo el personal que le pidas? ¿todo el equipamiento que solicites? ¿todo el dinero que digas necesitar? ¿sin restricciones de tiempo ni de ningún otro tipo?

Si respondiste "no" a alguna de estas cuestiones (y, no sé por qué, creo que será el caso) entonces no puedes dedicar esfuerzos a gestionar y mantener todas las aplicaciones pasadas, presentes y futuras.

Haz, por tanto una lista blanca de aplicaciones, con indicación de las versiones, que tu organización puede utilizar y consigue que la alta dirección firme un documento en el que se prohíba el uso de todo programa o versión que no figure en la lista.

Por supuesto, habrá programas que todo el mundo podrá utilizar y otros restringidos a aquellas personas que desarrollan determinadas tareas.

Y, también por supuesto, tendrás que arbitrar procedimientos para actualizar la lista. Dar de baja aquellos programas que ya no se usan, han quedado obsoletos o han dejado de recibir soporte por su desarrollador, incluir nuevas aplicaciones que cubren necesidades no satisfechas con el software disponible y reemplazar elementos por otros que presten mejor servicio u ofrezcan un mayor grado de seguridad.

Mi siguiente consejo es que las modificaciones de la lista requieran también la firma de la alta dirección. Puedes tratar de embaucar a la misma persona que puso su rúbrica al documento que daba oficialidad a la creación de la lista blanca de software. Y que, en ningún caso, se añada una aplicación si existe otra u otras en la lista que cubra satisfactoriamente sus funcionalidades.

Ahora viene lo bueno: hacer que la lista no sea papel mojado. Utiliza herramientas que te digan qué software hay instalado en cada equipo de tu organización y comprueben que no hay nada que no figure en la lista.

Deja claro desde el principio, si es posible por escrito, que si encuentras algo raro lo reportarás al jefe de la unidad en que aparezca y a la alta dirección. Yo incluso lo incluiría en el documento que crea la lista blanca de aplicaciones, de modo que la firma de la alta dirección suponga una orden para tí.

Y cumple tu palabra. Amigos, lo que es amigos, no te va a ayudar a hacer, pero es lo que tiene esto de la seguridad.

Para acabar por hoy, una última recomendación. Piensa en qué harías tú si fueras ellos. En qué haces cuando el antivirus no te deja utilizar tranquilo uno de esos programas que hacen cosas "graciosas". ¿Creas, quizá, una máquina virtual?

Pues, llegado el caso, a alguien más se le ocurrirá. De modo que controla expresamente a quién se le permite utilizar software de virtualización y haz un listado de máquinas virtuales autorizadas. Si alguien se crea una "de estranjis", trátalo igual que si hubiera instalado un software no permitido. Y, por supuesto, controla lo que corre en los equipos virtualizados como si de máquinas físicas se tratara.

¿Te parece mucho lío? ¿Muchos quebraderos de cabeza? ¿Muchos posibles conflictos?

Pues la cosa no ha hecho más que comenzar.