El mercado y el mercadeo del typosquatting (4)

¿Cómo protegerse?

El typosquatting puede terminar derivando en phishing, usos de tu imagen fraudulentos o que pudieran atentar contra ella, envío de visitas a tu competencia,...  Pero... ¿Cómo te proteges de todo esto?

Todo depende de en qué momento decidas actuar y de lo que otros hayan hecho ya al respecto. Vamos por partes:

Mejor prevenir que curar

Si el dominio que pudiera ser usado contra tí está libre... lo mejor sería que lo adquirieras. Por lo general, el coste anual no tendrá más allá de dos cifras (decimales al margen, claro) y en muchos casos puede que sea sólo una.

El problema aquí es que hay que imaginar. Prever qué dominios pudieran causarte problemas. Y seguro que no son pocos. Por poner un ejemplo, para "blogspot.com", donde nos estamos viendo, habría cosas como "wwwblogspot.com", "www-blogspot.com", "blogpot.com", "blogsppt.com", etc.

Unos serán más probables que otros. Quizá prefieras registrar sólo estos. Pero entonces...

Vigila

Sí. Vigila aquellos nombres de dominios que, sin ser tuyos, podrían confundirse contigo. Porque aunque hoy no estén registrados o tengan contenidos inofensivos, mañana todo puede haber cambiado.

Quizá cambien de propietario. Quizá el propietario cambie de ideas o lo aparque o alquile. Sea como sea, entonces sí será problema tuyo.

Así que comprueba el contenido de sus páginas, si es posible desde distintas ubicaciones (quizá te interese utilizar herramientas del tipo Browserling o BrowserStack), y también los resultados que puedan aparecer en las páginas de buscadores. Y, dado que lo más probable es que se protejan de la indexación mediante ficheros "robots.txt", si puedes irles echando un vistazo de vez en cuando tampoco te hará daño.

Vigilancia 24 x 7. Algo que en otras áreas no es (o no debería ser) tan raro de encontrar.

Cuando ya no puedas prevenir...

Si llegas cuando ya hay una campaña de phishing utilizando un domino, actúa.

Actúa tanto si eres el responsable del servicio como si eres un usuario. Aparte de las denuncias policiales y/o judiciales que corresponda poner, todo irá mejor si les ponemos las cosas difíciles a los phishers.

Si el dominio malicioso es un ".es", se puede realizar una notificación enviando un correo al CERT de Seguridad e Industria, dependiente del INCIBE, tal y como se cuenta en la página de dominios.es. En pocas palabras: manda un correo electrónico a incidencias@certsi.es. Si quieres más información, haz clic aquí. Otros TLD podrían tener cosas parecidas.

Para los ".com" y otros dominios habituales gestionados por ICANN, es cuestión de mirar los datos de Whois. Los agentes registradores dan datos de contacto para la notificación de cualquier abuso que se pueda encontrar. Busca una etiqueta que ponga "Registrar abuse contact email" o algo parecido y al lado tendrás una dirección de correo electrónico. 

Una vez sepas a quién, envía ese mensaje. Que el texto sea clarito y que tenga capturas de pantalla del sitio legítimo y el del phishing si es posible. Pero no corras riesgos inútiles: cuando se trate de algo en lo que no confíes, usa un servicio de los que te dejan usar un navegador durante un rato o hacen capturas de cómo se mostraría el sitio.

¿Que si funciona? Cuando la cosa está clara, normalmente sí. En cuestión de horas.

Y si no sabes qué hacer... cuenta con Google, que tiene también una página para reportar phishing.

Recuperar lo que no tuviste

Si el dominio está registrado pero no lo usan para nada raro... aparte de vigilarlo puedes actuar.

Para apoderarte del dominio que te tiene con la mosca detrás de la oreja puedes irte a los juzgados. Pero posiblemente sea algo costoso y lento. También, dependiendo del TLD del que estemos hablando, puede existir un procedimiento extrajudicial denominado "recuperación". Y que lo de recuperar no te lleve a engaño: no hace falta haber sido antes propietario del dominio.

Si se trata de un dominio ".es", te propongo un poco de lectura. Y por si prefieres que te lo resuma, ahí voy:

• Tienes que tener un dominio ".es" registrado para poder iniciar un procedimiento de recuperación.
• Existen una serie de "proveedores de resolución extrajudicial de conflictos" ante los que puedes interponer la demanda. Actualmente son:
• (Adigital), Asociación Española de la Economía Digital
• (Autocontrol), Asociación para la Autorregulación de la Comunicación Comercial.
• Consejo Superior de Cámaras de Comercio, Industria y Navegación de España.
• Centro de Arbitraje y Mediación de la Organización Mundial de la Propiedad Intelectual.


• En la demanda debes justificar:
• Que el nombre del dominio se parece demasiado a tu marca o nombre de dominio legítimo.
• Que el propietario del dominio "raruno" no los tiene.
• Que el registro o el uso posterior del dominio denota mala fe. O sea, que se registró o utilizó pensando en tí.

Si tienes razón... te darán el dominio en litigio y una cosa menos de la que preocuparte.

Eso sí. Todo tiene un lado malo. El coste por procedimiento, que tendrás que pagar TÚ, es de 1.400 euros. Mil cuatrocientos, por si alguien se lía con eso de los puntos y las comas. Si no me equivoco, más el correspondiente IVA. Y, por supuesto, añádele lo que corresponda si contratas a alguien para que te lleve estos papeles.

Cuando hablamos de euros y de cuatro cifras...

Si te interesa, puedes consultar los procedimientos que se abrieron en el pasado y sus resoluciones aquí, visitando la pestaña "Resoluciones dictadas". Algunas cosas curiosas encontrarás, como el caso de "facebook.es" del 2009 o el de "viajescarrefour.es" en el 2010. Nombres que habrían confundido  incluso a un experto.

Para dominios dependientes del ICANN también tienes una referencia que consultar. En este caso los proveedores de resolución aparecen listados en esta página. Sólo comentarte que la "WIPO" es lo mismo que la "OMPI" (siglas en inglés las primeras y en español las segundas). Y que la principal diferencia con las normas para los dominios ".es" es que, en el caso de los dependientes de ICANN eso de "el registro O el posterior uso denote mala fe" se cambia por un más restrictivo "el registro Y posterior uso denoten mala fe". Deben darse ambas circunstancias.

Por lo demás, tampoco es barato. De modo que vuelvo a lo que decía al principio de este post. Mejor prevenir que curar.

El mercado y el mercadeo del typosquatting (3)

Los que no estaban

Esta gente tiene más peligro que un plugin sin firmar.

Y no se trata de una única persona o de una única personalidad en Internet, que a priori es difícil distinguir un caso del otro.

Vimos el otro día que el propietario del dominio que trataba de propagar el plugin lo tenía aparcado y que era dueño de otros que hacían cosas igual o más raras que aquel. Pero ¿habrá dominios de otros propietarios que también te inviten a instalarlo? La respuesta parece clara: sí. Pero vamos a comprobarlo. Por ejemplo, buscando en Google el título de la página:

327 resultados. Referencias a dominios en páginas que se dedican a ello. Sí, algunos son casos repetidos, pero siguen siendo un buen número. Y muchos de ellos en dominios ".es".

Como comentábamos, el que NIC.ES te haga resolver un CAPTCHA antes de ver los datos de un dominio ha servido, en cierta medida, para proporcionar un cierto nivel de privacidad a los registrantes. O, por lo menos, para que no aparezcan sus datos directamente en los buscadores y otros sistemas de agregación de datos. Eso ha hecho que algunos vieran innecesario el uso de sistemas de anonimización y protección de datos en el registro de Whois.

Pero WhoisEs ha cambiado las reglas al ofrecer los datos sin CAPTCHA alguno y ser indexado por buscadores y sistemas como Domain Big Data. Y parece que todo ha sucedido demasiado rápido para algunos. Para casi todos. Por lo que no debe extrañar encontrarse ahora con mucha información y muchas posibilidades de relacionarla.

Eso sí, como decía en el post anterior, comprueba siempre los datos en las fuentes originales, que no siempre están actualizados. Recuerda que esta gente trabaja con dominios a corto plazo y muchas veces los ponen a la venta. Y si piensas en comprarles alguno, piensa que te los llevas con todo el historial que han adquirido previamente. Que quizá figuren en listas negras por las prácticas en las que se han visto involucrados o están etiquetados como distribuidores de malware. Cuidado, en todo caso.

Lo que ahora interesa es que aparecen muchos datos  y que a partir de cada dominio tenemos hilo del que tirar.

Como este caso. En la imagen aparece una referencia a una noticia de un tema policial entre los resultados proporcionados por Google. Téngase en cuenta que podría tratarse de otra persona con el mismo nombre que el utilizado para registrar el dominio y que no tenga nada que ver con éste. Al fin y al cabo, nombres que en un país parecen extraños en otros son de lo más común. Y no siempre se da un nombre real al hacerse con un dominio:

O este otro, cuyos apellidos harían pensar en un hermano del propietario del dominio con el que empezamos esta serie:

Hermano y compañero de fatigas, por lo que parece.

Riesgos futuros

No quiero repetirme más y me remito a los posts anteriores (1 y 2). Pero tampoco que no se transmita la preocupación que ciertos dominios me inspiran. Dominios que podrían confundirse con los de organismos y administraciones públicas o sitios populares. A los que un sencillo error, como el de no escribir el punto que separa el típico "www" del nombre del dominio, podría llevar. Por citar algunos (entre los resultados, en negrita, aparece un "falso positivo":

Y sucede que si te equivocas en el nombre de un banco quizá termines en una página que simula parecer Facebook y que te intenta contar lo afortunado que eres:

O quizá dominios que parecen hechos a medida de un intento de phishing, en los que uno de esos puntos que separan las partes de un nombre de equipo fue sustituido por otro carácter:

Muchos de ellos son ofrecidos a precios más que económicos, como se puede apreciar en la imagen. Económicos para un phisher. Y económicos para las organizaciones que, a causa de ellos, podrían ser objeto del phishing. La cuestión es saber quién se va a adelantar o si alguno de ellos no está intersado en la carrera.

Para dejar buen sabor de boca, ahí os dejo una remesa de dominios que, si algún día caen en malas manos, podrían causar verdaderos quebraderos de cabeza a más de uno. Sólo una muestra, sacada de "nic.es":

Llegado el caso, posibles objetos de los ataques podrían ser el Boletín Oficial del Estado, la Agencia Tributaria, la RAE (a la que desde que se pusieron a definir lo que es un "hacker" sin saber del tema...), la Agencia Española de Meteorología, la Agencia de Protección de Datos, Amazon, la Junta de Andalucía, la Dirección General de Tráfico...

O el propio "dominios.es".

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

Cloud, software propio, software propietario, software libre... ¿Qué camino sigo?

La última vez dejamos una pregunta en el aire ¿Cómo elegir, o en su caso desarrollar, el software? Echémosle valor al toro.

Para empezar, como dice el título: Cloud, software propio, software propietario, software libre... ¿Qué camino sigo?

Cloud (?)

Sobre el uso de tecnologías Cloud se ha escrito mucho. Y en el mundillo de la seguridad abundan quienes que se declaran excépticos. Incluso yo comentaba hace poco algo del tipo: "la nube simplifica mucho las cosas... sobre todo si sabes taparte la nariz y mirar hacia otro lado cuando huele mal". Cosa de la que no me desdigo. Pero que tampoco quisiera llevar más allá de lo razonable. Me explico:

El problema principal que le veo al Cloud cuando de seguridad se trata es que las organizaciones pueden terminar perdiendo el control sobre su información. La dejan en manos de otro y confían en que hará bien las cosas. Pero siguen siendo responsables de ella, legal y moralmente hablando. Está muy bien eso de contratar un servicio y olvidarse de él, pero la seguridad no es algo de lo que te puedas desentender, porque se infiltra en cada matiz de tu organización. Y no puedes comprarla. Recuerda: "no es un producto sino un proceso". Si te la proporciona una empresa, debes implicarte y controlar lo que ésta hace porque, lo haga quien lo haga, no es algo que puedas contemplar de forma independiente del resto de tus actividades.

En ese aspecto, el Cloud no simplifica las cosas. Más bien todo lo contrario. Pero ¿significa eso que no se debe usar? Ni mucho menos.

Hace algún tiempo, en una charla que di sobre vulnerabilidades del tipo CSRF y XSS, alguien me preguntó por las Content Delivery Networks y lo que yo pensaba de utilizarlas como fuente de librerías JavaScript para tus páginas web. Creo que esperaba que me opusiera categóricamente a su uso y, de hecho, me pareció que mi respuesta no le satisfacía. Pero era la única que tengo para este tipo de cosas: depende.

Sí. Depende, principalmente, de si tú eres capaz de hacer las cosas mejor que ellos. O de si tienes los medios necesarios (técnicos, humanos, organizativos, ...) para garantizar el servicio. Por poner un ejemplo: si tu sitio web está alojado en un servidor gratuito que ni siquiera soporta HTTPS quizá sea más fiable descargar algo de un servicio prestado por Google que de él.

Volviendo al Cloud, piensa en el correo electrónico. ¿Tienes medios para instalar un sistema de control de acceso que utilice dos factores? ¿Eres capaz de atender la carga administrativa que supone la gestión (altas, bajas, modificaciones, desbloqueos, etc.) de todos tus usuarios? ¿Tienes un servidor apropiado y con suficiente capacidad? ¿Dispones de un software suficientemente seguro y eres capaz de mantenerlo actualizado para que siga siéndolo? ¿Tienes personal para operarlo sin problemas y dar respuesta rápida a los incidentes de seguridad? ¿Dispones de infraestructuras para garantizar el servicio en caso de que algo falle? ¿Eres capaz de ofrecerlo sobre varios clientes, incluyendo smartphones?

Si respondiste "no" a alguna de estas preguntas... plantéate usar la nube. Plantéate si Gmail.com o Outlook.com, por citar dos ejemplos, hacen mejor que tú estas cosas. Porque es verdad que con la nube pierdes un grado de control pero también lo es que estas grandes empresas, gracias a la economía de escalas, pueden permitirse cosas que tú no. Y están sujetas a un marco regulatorio y a un escrutinio público del que quizá tú escapes.

Eso sí: si te decides por la nube... que no te vendan humo. Elige bien tus compañeros de camino y antes de seleccionarlos piensa en (y asegúrate de que figuren en el contrato) cosas como:

• Cómo se almacenarán tus datos. 
• Qué cifrados se aplicará a tus datos, dónde se realizará la encriptación y quiénes tendrán las claves.
• Quiénes tendrán acceso a tus datos.
• Dónde se van a alojar tus datos y si tienes algún grado de decisión sobre ello.
• Qué normativas les serán aplicables a tus datos.
• Cuántas copias existirán de tus datos.
• Qué control te dejan sobre tus datos y la forma en que se gestionan.
• Qué procedimientos existen para llevarte tus datos a otro servicio y cómo y en qué condiciones puedes utilizarlos.
• Qué responsabilidades asume la empresa propietaria del servicio en la nube  y cuáles asumes tú.
• Cómo te compensará la empresa en caso de que existan problemas de seguridad.
• Cómo actuará la empresa propietaria del servicio en la nube y cómo interactuará contigo (y con tus clientes, si procede) en caso de que se produzcan incidentes de seguridad.
• Qué pasará con tus datos (y con sus copias de seguridad) cuando dejes de trabajar con ellos.

Y repito: "tus datos". Y tu responsabilidad. Si te dicen que esto de la nube es cuestión de confianza... no lo creas. No basta con confiar. Necesitas garantías. Muchas garantías.

Pero si decidiste alejarte de la nube y alojar tú mismo tu software... tampoco habrás acabado de elegir. Te quedan al menos dos cuestiones por responder

¿Software Libre o Propietario?

Buena pregunta... ¿no crees?

O no tan buena, si lo miras bien. Si me pongo a mirar lo que hay por ahí me doy cuenta de que la elección entre software libre o propietario no me parece tan relevante. Conozco aplicaciones de software propietario malas. Malísimas. Con más agujeros que un queso de gruyère. Pero igual de malas las hay de software libre.

Que el código fuente sea público es un arma de doble filo. Como cualquiera que se mueva en estos mares, en alguna ocasión he encontrado una vulnerabilidad en un producto al revisar su código. O he podido realizar con mayor facilidad ataques de SQL Injection al conocer la estructura de la base de datos. Y habrá quien diga: "claro, la gente puede analizar el código y encontrar los problemas y resolverlos -- eso lo hace más seguro".

Y otros replicarán: "pero... ¿quién le dedica el tiempo necesario a analizar la seguridad del código de las aplicaciones que utiliza". O: "pero si el código es cerrado nadie, ni siquiera los delincuentes, lo tendrán tan fácil para dar con las vulnerabilidades".

O: "¿y si los bugs son encontrados por gente que no los hace público y los explota durante mucho tiempo". Porque de esto también hay precedentes. Por poner uno, cuando la NSA reconoció saber de HeartBleed años antes de que fuera publicada.  Y estamos hablando de una vulnerabilidad introducida en 2012 y de la que todos (al menos, los que no estábamos en el ajo) nos enteramos en abril del 2014.

Ambos están en lo cierto y ambos se equivocan. Y yo también. El software es algo demasiado complejo como para que sea el carácter abierto o cerrado de las fuentes lo que determine su seguridad.

Estudia qué aplicación o sistema responde mejor a tus necesidades. Y trata de conocer cómo se desarrolla. Independientemente del tipo de producto, busca algo que no te vaya a dejar en la cuneta. Huye como del fuego de proyectos gestionados por una única persona o un grupo reducido. Aléjate de aquellos que no sean la principal dedicación de quienes los crean y mantienen.

Mira el historial del software, pero no te dejes engañar por la cifra de vulnerabilidades encontradas. Más vulnerabilidades detectadas no quiere necesariamente decir que el software es menos seguro. Quizá sea todo lo contrario y estemos hablando de "más problemas corregidos".

Porque vulnerabilidades, con el tiempo, seguro que aparecen y más aún en aquellos productos software que son utilizados por mucha gente. Entonces lo importante será ver cómo las corrigen. Qué protocolos y procedimientos tienen establecidos para el reporte y la gestión de bugs. Qué tiempos de respuestas manejan. Qué tipo de soluciones suelen darles. Qué recursos dedican a ello.

Lo del software libre tiene un pro y una contra que no quisiera dejar de citar. Por un lado, quizá tengas algún margen de maniobra. Si puedes, trata de participar y aportar recursos a aquellos proyectos de software libre que utilices. Al fin y al cabo, es algo que parece justo y que, visto desde el punto de vista egoísta, te permitirá tener alguna influencia en su evolución.

Y, por otro, ten cuidado con todo lo que parezca salir gratis, sea o no libre. No sólo porque podría no serlo (gastos de formación, consultoría, etc.) sino también porque podría serlo. Al ser gratis y no tener que pasar por los trámites necesarios para pagar una licencia, cualquiera puede pensar en instalárselo. O en tener muchas instancias corriendo. Y con ello podríamos estar perdiendo el control sobre el software instalado en nuestros equipos y sobre la forma en que lo gestionamos y tratamos de mantenerlo tan seguro como nos sea posible. Estaríamos acabando con nuestra útil "lista blanca".

¿Lo hago yo o lo encargo a una empresa?

Si no utilizas un software ya existente, ya sea libre o propietario, también tendrás que decidir si lo haces con tus medios o contratas a alguien.

Aquí te digo lo mismo que cuando hablábamos con la nube: ¿puedes hacerlo tú mejor que ellos?

Pregúntate: ¿con qué personal cuento? ¿se dedica a otras cosas que no les va a permitir centrarse en los desarrollos? ¿me puedo permitir después realizar el mantenimiento del producto? ¿tiene mi personal formación suficiente en programación? ¿la tiene en seguridad y hacking?

Si es que no... piensa en que lo haga otro. Eso sí, antes de encargárselo, hazte las mismas preguntas de antes pero referidas a éste: ¿con qué personal cuenta la empresa? ¿se dedica a otras cosas que no les va a permitir centrarse en MIS desarrollos? ¿se pueden permitir después realizar el mantenimiento del producto? ¿tiene SU personal formación suficiente en programación? ¿la tiene en seguridad y hacking?

Y ni te plantees contratar con nadie que no sea mucho mejor que tú en esto.

Cuando contrates el desarrollo, asegúrate de que aparezcan cláusulas que te garanticen, entre otras cosas:

• La adecuada formación en materia de seguridad de TODO el personal de la empresa involucrado en el proyecto.
• Los datos del personal que va a trabajar en él, con su formación y cualificación, tanto general como específica en materia de seguridad, la relación que tienen con la empresa, el puesto y el tiempo que lleva en ella. Y no estaría de más que les hicieras alguna entrevista antes de decidir.
• La metodología a utilizar, en general y en particular en lo referente a la gestión de seguridad durante todo el ciclo de vida y de mantenimiento.
• La garantía de resolución de las vulnerabilidades que pudiera tener el producto en un tiempo y unas condiciones adecuadas.
• Las responsabilidades que asume la empresa en materia de la seguridad del producto (y no me vale eso tan manido de "la empresa no se hace responsable...") así como de producirse cambios sustanciales en el personal encargado del proyecto.
• Las compensaciones que tendrá que hacerte la empresa en los casos anteriores.
• Y algo que nunca me cansaré de repetir: TRANSFERENCIA DE CONOCIMIENTO. Que la empresa proporcione formación e información que mejore tu organización. Entre otras cosas, en seguridad.

Seguro que me dejo muchas cosas en el tintero, pero en algún momento tengo que dejar de escribir. Dejemos para más adelante algunas notas sobre el ciclo de vida y otros aspectos más técnicos.

Lo importante es que, lo hagas como lo hagas, que no tengas nunca que decir (o volver a decir) eso que una vez oí de "esto es que lo hicieron unos becarios que tuvimos hace tiempo y ahora vaya usted a saber quién será capaz de entenderlo y mantenerlo". 

En aquel caso, si no me falla la memoria, la aplicación tenía vulnerabilidades de Local File Inclusion (no recuerdo si también remoto), SQL Injection y XSS. Que no es poco. 

Y les habían cascado publicidad de pastillitas azules y otros fármacos.

El mercado y el mercadeo del typosquatting (2)

Whois y dominios .es

Visto lo que hace el plugin del post anterior, posiblemente te interese saber quién es su propietario. Y para eso están las consultas a Whois. En el caso de los dominios ".es" podemos hacer la consulta a través de "http://www.dominios.es". Curioso que no me funcionen las consultas a través de HHTPS: "https://www.dominios.es". Curioso y preocupante.

En la parte derecha encontrarás un formulario que te permite consultar si un dominio está disponible. Si lo usas, la respuesta te llegará desde otro domino, "nic.es", y esta vez, sí, sobre HTTPS. Te mostrará diversas variaciones sobre el dominio consultado, indicándote si está libre o no y, en el primer caso, incluyendo un enlace para ver sus datos. Eso sí, antes tendrás que resolver un CAPTCHA.

Como todo esto es mucho rollo, te cuento como hacerlo un poco más fácil. Hace algún tiempo me encontré en una página que lamento no recordar (con lo que a mí me gusta citar mis fuentes...) una URL que, poniendo el nombre de dominio como parámetro GET, te lleva directamente a la página del CAPTCHA. Y me hice un pequeño fichero HTML con un formulario. Os lo copio:

=========

<form onsubmit="visita()">

Dominio: 

<input type="text" id="dominio" />.es<br />

<input type="submit" value="Consultar" />

</form>

<script>

function visita(){

window.open("https://www.nic.es/sgnd/dominio/publicValidacionDetalleWhois.action?volverWhoIs=1&TDominio.nombreDominio=" +

document.getElementById("dominio").value + ".es"

);

document.getElementById("dominio").value = "";

return false;

}

</script>

=========

Y no creo que sea necesario un manual para utilizarlo:

Si esto te parece demasiado difícil... estás de suerte. Hay un sitio web que ofrece datos sobre dominios ".es" sin necesidad de resolver ningún CAPTCHA. Y que además está siendo indexado por los buscadores y utilizado como fuente por sitios como Domain Big Data. Se trata de http://www.whoises.com. Dejemos que sea él mismo quien se presente y diga qué es capaz de hacer:

Eso sí, sin querer meterme donde no me llaman, creo que hoy no es mi día con eso del HTTPS. Porque si visito WhoisEs con ese protocolo, tras recibir avisos relativos al certificado...

Queden ahí estos "trucos y consejos". Que, por otro lado, no sé cuánto tiempo seguirán siendo útiles.

El dominio del plugin

En esta ocasión usé "nic.es" para ver los datos del dominio:

¿Que por qué tapé los datos del propietario? La verdad es que, ante la duda, preferí hacerlo. Por un lado, porque de las imágenes del post anterior parece desprenderse que se trata de un dominio aparcado. O sea, que el propietario no es quien lo está explotando. Por otro lado, no sería la primera vez que se usa un nombre falso para registrar un dominio y podríamos estar poniendo en evidencia a una persona que no tiene nada que ver con este negociete.

En todo caso, los Whois son públicos y si alguien tiene interés en el dato concreto no tendrá problema en saberlo. Ni tampoco le será difícil encontrar otros dominios del mismo dueño. Puede hacerlo con buscadores:

O, mejor aún con un servicio que agregue datos de whois como Domain Big Data, buscando por el nombre del propietario:

Si me dejas hacer un inciso te señalaré que tienes que tener cuidado siempre con los datos de dominios. Porque, salvo que los obtengas de las fuentes originales, pueden haber cambiado desde que el buscador o el sistema utilizado los obtuvo. Quizá el propietario consiguió venderlos. Quizá expiraron.

En todo caso, creo que está clara la estrategia que este registrante tiene a la hora de elegir sus nombres de dominios. Visité algunos de ellos. En algún caso se me volvió a invitar a instalar un plugin ("quien no te conozca... que te compre", que decía aquel cuento):

Otros no mostraban nada raro. El típico listado de enlaces que sueles encontrar en cualquier dominio aparcado. Pero hice más pruebas utilizando una página llamada BrowserStack que es muy útil cuando Browserling se te queda pequeño.

Lo bueno de BrowserStack es que no sólo te permite probar con distintos sistemas operativos y navegadores para PC o Mac. También soporta dispositivos móviles. Y lo que me encontré fue un montón de redirecciones, tanto mediante JavaScript como mediante HTTP, que terminaban en páginas del tipo "has ganado este gran premio, rellena esta encuesta" o "participa en este sorteo, que casi lo tienes ganado". Y si probabas varias veces te salían cosas distintas. Así ocurría con un HTC One M8:

O con un Chrome sobre Windows 8.1:

Pero, como veremos, en esto del plugin y este registrante de dominios ni son todos los que están ni están todos los que son. 

El mercado y el mercadeo del typosquatting (1)

Typosquatting

Últimamente hemos hablado aquí de la campaña de phishing a Carrefour y de como los phishers usaban typosquatting para utilizar nombres de dominio medianamente creíbles para sus sitios web fraudulentos.

Nada nuevo bajo el sol, pero éste es uno de esos temas que me preocupan. Algo parecido a cuando veo que se usan técnicas ilegítimas o ilegales para el posicionamiento en buscadores y que ciertos personajes ensucian el nombre de una actividad en la que hay otros que se ganan la vida de forma honesta.

Con el typosquatting nos encontramos con prácticas inapropiadas muy parecidas. En algunos casos, coincidentes. Para empezar, se toma un dominio popular. Uno que reciba muchas visitas. Después se buscan nombres que puedan confundirse con aquel. Quizá cambiando una "n" por una "m" o quitando alguna letra o poniendo tres "r" donde en el legítimo aparecen sólo dos. La idea es que cuando la gente cometa un error al escribir la dirección pueda terminar visitando tu sitio.

¿Y ahora qué?

Ganar dinero

Dudo que haya demasiada gente que se dedique al typosquatting por hobby. Más bien creo que será por dinero. Y hay varias formas en que un dominio como estos de los que hablamos puede ser aprovechado.

Por poner un ejemplo, se me ocurrió ver qué pasaba si cambiaba la "y" de PayPal.es por una "i". Ignoro si la pesona que registró el dominio resultante pensaba en esto, pero a mí fue lo primero que se me ocurrió. Y lo que me salió fue:

¡Uf! Que me instale un complemento en el navegador para que no se sepa dónde me he estado metiendo.

Confieso que, tras leerme los términos y condiciones, mi primer idea fue no hacerlo. Pero entonces alguien dijo: "no hay cohones". Y, ya sabes,...

Eso sí, alguna protección tomé.

Un plugin desfasado

La página de la imagen anterior me aparecía independientemente del navegador que utilizara. Eso sí, si utilizaba Internet Explorer me salía un mensaje indicando que mi navegador no era compatible y me redirigía a la página de descarga de Chrome.

Con Chrome, sin embargo, tuve el primer problema. El plugin, que se promocionaba como una forma de descargar anónimamente desde distintos sitios, parece haber sido eliminado de la Chrome Web Store:

Probé, pues, con Firefox. En particular, con su versión 43, lo que más adelante se revelará como relevante. La ventana de instrucciones era distinta pero la cosa tampoco iba a ser fácil:

Tras hacer clic en "Permitir" para decirle al navegador que instalara el plugin ne salió otro mensaje indicándome que éste no viene firmado y que por tanto Firefox se niega a instalarlo.Como yo iba ya en plan kamikaze, entré en "about:config" y (niños: no hagáis esto en casa) modifiqué el valor del parámetro "xpinstall.signatures.required", como se indica en la documentación de Mozilla.

Al final... ¡lo conseguí! Ahora puedo visitar el dominio que elegí y...

... Ahora resulta que el dominio está aparcado y en venta. O sea, que su propietario no lo usa y lo "alquila" para que otros le busquen rentabilidad. En este caso ponen enlaces a páginas de PayPal pero entre ellos salpican algunos a distintos dominios no tan conocidos. Lo de siempre: enlaces y visitas.

En todo caso, como podemos ver, se trata de un plugin desfasado. Parece que lo intentaron en la Chrome Web Store pero les dieron de baja. Y aún no se adaptaron a la forma en que funcionan las nuevas versiones de Firefox. Dudo que un usuario normal se meta en camisas de once varas, como yo hice, para instalarse este plugin.

Además, tras actualizar a la versión 48 de Firefox, ya no funciona eso del "xpinstall.signatures.required". Como dice la documentación: "

• Firefox 40-42: Firefox warns about signatures but doesn't enforce them.
• Firefox 43: Firefox enforces the use of signatures by default, but has a preference that allows signature enforcement to be disabled (xpinstall.signatures.required in about:config).
• Firefox 48: (Pushed from Firefox 46). Release and Beta versions of Firefox for Desktop will not allow unsigned extensions to be installed, with no override. Firefox for Android will enforce add-on signing, and will retain a preference — which will be removed in a future release — to allow the user to disable signing enforcement."

¿Adivinas? A mí se me actualizó mientras hacía las pruebas. Y tuve que "desactualizar" a mano.

Pero en su día sí era más fácil y posiblemente no fuera despreciable el número de usuarios afectados.

¿Con qué se encontraron?

La licencia

Cuando me fui a la página de Plugins de mi navegador me encontré a mi nuevo inquilino:

Con éste, ya iban tres nombres: "Anonsurf", "Safe" y "Navegación Oculta 3.0". La descripción: "Paquete de instalacion necesario para navegacion anonima en las webs que lo requieran. El plugin modifica el contenido del navegador y actualiza sus datos para que estos puedan ser visualizados de forma segura y anónima".

Lo de "webs que lo requieran" ya lo había comprobado, aunque al final se trataba de un dominio aparcado con poco interés para mí. Lo de "modifica el contenido del navegador y actualiza sus datos"... creo que debería dar un poquito de miedo. Así que creo que habría que revisar los términos y condiciones que aparecían en la página inicial.

Parecía una, no demasiado mala pero tampoco buena, traducción de un texto en inglés. Y en ella aparecían perlas como:

• "Este es un contrato legalmente vinculante entre usted y el creador del instalador". Aunque no vi ningún dato que permitiera identificar a este "creador del instalador".
• "AL ACCEDER A LOS SITIOS Y DESCARGA DEL CONTENIDO, USTED autoriza el mostrar información PROMOCIONAL , anuncios y ofertas de productos o servicios de terceros (conjuntamente " PUBLICIDAD ")". Eso me temía yo.
• "NO SOMOS RESPONSABLES ANTE USTED O CUALQUIER OTRA PERSONA POR CUALQUIER DAÑO INCIDENTAL , CONSECUENTE , INDIRECTO , PUNITIVO O EJEMPLARES , INCLUYENDO, SIN LIMITACIÓN , TIEMPO MUERTO DEL EQUIPO , PÉRDIDA DE DATOS, O DE GANANCIAS , INCLUSO SI SE NOS HA ADVERTIDO DE LA POSIBILIDAD DE TALES DAÑOS. AL INSTALAR O USAR EL CONTENIDO, USTED ACEPTA RESPONSABILIDAD EXCLUSIVA PARA TODAS LAS CONSECUENCIAS DERIVADAS DE LOS MISMOS Y reconoce que ninguna reclamación será realizada en contra de nosotros, nuestros licenciatarios , distribuidores, agentes , empleados o afiliados".
• "NO HACEMOS NINGUNA REPRESENTACIÓN O GARANTÍAS RELATIVAS DE TERCEROS O SOCIOS OFERTAS, USTED ACEPTA QUE NO SOMOS RESPONSABLES POR CUALQUIER PÉRDIDA O DAÑO DE CUALQUIER TIPO INCURRIDO , O COMO CONSECUENCIA DE LA PRESTACIÓN O EXHIBICIÓN DE LAS OFERTAS". O sea, que no te quejes si una oferta te cuela algo en tu equipo o es fraudulenta.
• "EN ALGUNAS OCASIONES , A COMPARTIR se puede cobrar por dichos servicios a EL USUARIO FINAL PARA EL MANTENIMIENTO DEL SITIO WEB O DICHO DE SERVICIOS".

Eso sí, para acabar aparecía un tranquilizante "Ningún dato personal será recogido por esta página web" que ahondaba aún más en un anterior "En un esfuerzo por cumplir con la Ley de Protección de datos, nosotros no recogemos información de identificación personal ni usamos cookies de identificacion o rastreo".

El sitio web

Cuando eché un vistazo al plugin en las opciones de Firefox aparecía una dirección. A ver si dan más información al respecto:

Pues... no. He tenido la mala suerte de pillarlos de mantenimiento. Un administrador cuidadoso debe tener esta web, pues eché un vistazo a "archive.org" por si tuviera copias anteriores y se ve que "mantiene mucho su web". Sólo encontré algo distinto cuando me remonté al año 2014:

Una palabra, "hola", que parece apuntar a alguien que habla español.

Los efectos

Estuve navegando un rato. ¿Que si noté algún cambio?

Bueno, el navegador se me quedó colgado varias veces mientras visitaba páginas de periódicos. También es verdad que la máquina virtual que estaba usando tenía poca RAM. Todo era aparentemente normal hasta que eché un vistazo al código JavaScript incluido en el fichero XPI de la extensión y utilicé las herramientas para desarrollador del navegador.

El código fuente del plugin tenía cosas "llamativas":

O sea: código para modificar las páginas visitadas y  añadirles un script. O, dicho en otras palabras, un XSS basado en complementos del navegador. Eso sí, consentido por el usuario al aceptar los términos y condiciones si lo que hace es añadir publicidad a las páginas. Pero, concediendo que así sea hoy... ¿quien nos garantiza que los scripts sigan haciendo mañana lo mismo que hacen hoy?. Incluso si la voluntad del desarrollador fuera otra... ¿no sería posible que alguien comprometiera su sitio web?

Eché un vistazo al fichero que se incluía en el nuevo script. Y básicamente encadenaba otra carga

El cual contenía nombres de variables y textos en español y sí que hacía otras cosas. Como insertar IFRAMES con páginas de terceros:

O modificar las direcciones de las páginas solicitadas:

Por cierto que ese "getCookie" y el otro "setCookie" me hacen revisar los términos y condiciones. Firefox avisaba de vez en cuando de la redirección:

Las nuevas direcciones terminaban redirigiendo a la solicitada. Parecía que se trataba más de rastreo que de intentos de phishing u otros tipos de engaño similares.

O también añadir IFRAMES a las páginas:

¿Cómo se traduce todo esto en la práctica? Valga como muestra un ejemplo. Si visito la página de Google, me encontraré con una sorpresa al comparar el código fuente de la página descargada con el de la mostrada (este último puede obtenerse seleccionando todo y usando la opción "ver código fuente seleccionado"). Ahí está el script añadido. En la línea 49 me sale a mí:

O al ver el IFRAME añadido al final del documento con el "Inspector" de las herramientas para desarrolladores (F12):

O al comprobar los accesos a páginas en dominios ajenos al solicitado:

Cloaking

Quizá quieras hacer tú mismo o tú misma las pruebas que hice yo y alguna más que se te haya podido ocurrir. Pues vete haciendo el cuerpo a que quizá no puedas. Porque cuando he intentado acceder al dominio objeto de este post desde otros sitios, incluyendo equipos de conocidos, me he encontrado con que la respuesta era distinta.

Para que te hagas una idea, ahí van varias capturas de pantalla. La primera realizada utilizando Browserling, una web que te "presta" un navegador por un ratito:

Y ahí va Browsershots:

Y lo que ve el traductor de Google:

O el motor de generación de thumbnails usado por Exalead Search para los iconos personalizables de su página de inicio:

Queda vintage eso de "Esto es el fin de internet". ¿verdad?

Resumiendo, que es gerundio

Que te inyecten un script en las páginas de Google (o de Amazon, o de Bing, o de PayPal, o de...) no es cosa baladí. Un script puede tomar control de una página web y hacerle hacer cuanto desee. Desde hacer peticiones arbitrarias, saltándose cualquier protección anti-CSRF que pudiera haber en juego, hasta exfiltrar a terceros los datos manejados y las transacciones realizadas. Pasando por robar credenciales o cookies de sesión o por realizar escaneos de red o realizar ataques de denegación de servicio contra terceros sitios.

Como indiqué anteriormente, no parece ser éste el caso en el ejemplo que nos ocupa. Todo parece tener más que ver con el rastreo que con otra cosa. Pero no existen garantías sobre qué pasará en el futuro, quizá incluso en contra de los deseos de quienes escribieron y explotan el plugin.

De si se trata de un caso aislado o existen redes dedicados a esto trataremos otro día...