#MundoHacker: 7 formas de ofuscar URLs falsas en campañas de phishing

Si sigue esta página desde hace tiempo, sabrá de primera mano que con la proliferación de los dispositivos móviles y redes sociales, el phishing vive una segunda edad de oro, principalmente porque los enlaces son abiertos en navegadores o aplicaciones muy capadas, que impiden al usuario darse cuenta de que están ante un timo.

Typosquatting

Y algo que tienen en común la mayoría de ataques de phishing es que redirigen al usuario a una web clon y fraudulenta de un servicio, sea el que sea, con el fin de que inserte sus credenciales de acceso o realice una acción que les permita obtener información sensible de la víctima.

Puesto que la URL puede ser motivo más que suficiente para que el usuario desconfíe, en este capítulo de la serie #MundoHacker, veremos algunas de las técnicas más utilizadas para ofuscar URLs falsas en campañas de phishing. Y quien dice phishing, dice una broma a unos amigos o lo que se le ocurra.

1. Ingeniería social

La más clásica entre las clásicas. El siguiente enlace es un ejemplo: www.amazon.es (ES).

Seguramente si usted ve esto lo primero que piensa es que el enlace lleva a la página española de Amazon. Y de hecho, si está leyéndome desde el escritorio y pasa el ratón por encima, verá que efectivamente el enlace parece apuntar a esa dirección. Ahora bien ¿lo ha probado?

Aquí lo que estamos haciendo es modificar por HTML la dirección a la que apunta el enlace. Solo porque tengamos escrito www.amazon.es, no significa que el enlace apunte a este dominio.

Ahora imagine que en vez de apuntar a mi página, hubiera apuntado a un clon de la tienda oficial, y el enlace estuviera en un email que le alerta de que su pedido está parado en aduanas. Pues aunque no hubiera pedido algo, mucha gente entraría para ver de qué se trata, y al pedirle los datos de acceso, le redirigiría correctamente a la página de Amazon, donde vería, efectivamente, que no ha pedido nada…

Pero sus credenciales de Amazon ya estarían guardadas en una base de datos gestionada por una banda de cibercriminales, y sería víctima de una de las múltiples campañas de phishing.

Todo gracias a una ingeniería social que me ha llevado un par de segundos programar.

Otra posibilidad, aunque ya canta más, es el uso del operador @, que en Chrome y Firefox sirve para unir dos enlaces, haciendo caso al que está más a la derecha.

Por ejemplo, www.amazon.com@www.google.com dirigiría a google.

En IE, al menos en las versiones actuales, arroja un error.

2. Redirecciones

Aquí el tema se complica ligeramente, ya que tendremos que tener acceso a alguna de las páginas del dominio víctima. Básicamente con un script en PHP, python o javascript podemos forzar a que al visitar alguna de las páginas del dominio real, este redirija a otro. Esto es posible mediante inyecciones de código en alguno de los formularios o inputs de entrada de texto que tengamos por una web (y que no estén convenientemente protegidos, claro).

El usuario seguramente no se de cuenta (a fin de cuentas entiende que ya está en el dominio correcto), y podemos realizar las fechorías esperables.

El colmo de los colmos es si podemos modificar archivos tan críticos en un servidor como los de configuración o el .htaccess. Porque entonces podemos hacer lo que queramos (de hecho seguramente ni necesitemos redirigir a la víctima, ya que podremos aprovecharnos de ella desde el propio dominio original).

3. Open-Redirect en diversos servicios

Esta podría ser considerada una versión un poco más elaborada del anterior. Se basa en aprovechar vulnerabilidades (o no-vulnerabilidades, como dice Facebook) que permiten realizar redirecciones con las APIs de compartir que utilicen Open-Redirect, como es el caso de esta red social.

Para colmo, la posibilidad de cambiar el texto, descripción e imagen en las URLs compartidas en Facebook la hacen de facto muy interesante como vector de ataque (solo necesitamos que el dominio al que aparentemente está apuntado sea aquel que queremos que el usuario piense que va a ir).

Parece que poco a poco, aunque no lo considera vulnerabilidad, lo va solucionando, pero en todo caso, dejo enlace algunos ejemplos técnicos (I y II) de cómo se podría explotar, por si a alguno se le alumbra una bombilla.

4. Homógrafos o fallos de escritura

Según la tipografía que usemos, www.google.com y www.googIe.com podrían parecer exactamente iguales. Y en cambio, en el segundo caso estoy utilizando una “i” mayúscula en vez de la “l” minúscula.

A esto se denomina homografía, y se trata en buscar códigos Unicode que visualmente sean casi semejantes. Y los hay prácticamente indiferenciables, como en www.goοgle.com y www.google.com.

¿Ha encontrado la diferencia?

5. Typosquatting

Otra posibilidad es aprovechar los errores tipográficos que habitualmente tenemos por el idioma. Quizás le suene a guasa, pero para muchos hispanohablantes, Google se escribe Gugle o Gugel. Porque fonéticamente suena así.

El typosquatting está tan extendido que los propios buscadores aplican sus algoritmos de machine learning para corregírnoslo (el clásico “quizás quiso decir…“), e incluso no es raro que una compañía compre decenas de dominios con errores de typosquatting para protegerse, y facilitar el trabajo a los usuarios, que serán redirigidos al dominio correcto.

6. Acortadores de enlaces

Aquí empieza la chicha. Como comentábamos por arriba, el mundo móvil y las redes sociales (principalmente Twitter) vino acompañado de la necesidad de reducir las dimensiones de las URLs, y así surgieron los acortadores de enlaces. Servicios como bit.ly o karmacracy hacen de intermediarios, ofreciendo estadísticas de clicks al usuario que acorta el enlace y un enlace que ocupa menos para el resto de usuarios. Algo que se agradece cuando estás en una pantalla móvil, y que sobre todo, hace unos años, era necesario si no querías comerte buena parte de los 140 caracteres de un Tweet.

A día de hoy, esta restricción al menos en Twitter está controlada. Todos los enlaces ocupan 20 caracteres como máximo, por lo que necesario no es que sea. Y aún así, la mayoría de clientes de esta red social auto-acortan los enlaces igualmente.

Esto representa el caldo de cultivo perfecto para ataques de phishing, ya que el usuario a priori no sabe hacia donde apunta el enlace. Hay servicios como Uncover (EN) que permiten previsualizar el enlace, para saber si es el correcto o no antes de pinchar en él, pero en todo caso, la mayoría de usuarios pincharían antes que tener que ir a una página de estas y comprobarlo.

Unshorten (EN) hace lo mismo, pero además muestra un pequeño reporte con la confianza del sitio. Altamente recomendable.

7. Navegadores empotrados en las apps móviles

Dejo para lo último un tema que me apasiona, y del que ya hablé largo y tendido (y me quedé tan ancho) recientemente, con el fin de soporte de WebView (componente que gestiona esta característica) en Android para versiones inferiores a 4.3.

Básicamente aquí el ciberatacante no tiene que hacer nada, puesto que la mayoría de redes sociales, en su afán por mantener cautivo en sus aplicaciones al usuario, abren los enlaces externos en un navegador capado que carga dentro de la propia aplicación. Esto infla que no vea las estadísticas de tiempo de uso de las apps, y de paso, hace que el usuario sea incapaz de ver la URL a la que está accediendo.

Teniendo en cuenta que el 60% de tráfico de Facebook viene de las apps móviles, entenderá que este es un problema muy pero que muy grave.

Bonus: ¿Cómo evitar caer en el engaño?

Es tan sencillo como seguir estos tres puntos:

  • No abrir ningún enlace acortado sospechoso (aunque se lo envíe ese amigo del alma por Twitter) si no es con un desacortador de URLs.
  • Si tenemos que insertar datos sensibles, fijarse en que la conexión se esté haciendo mediante HTTPs y cuente con un certificado firmado original.

Google verificado

  • Y sobre todo, usar el sentido común: No me cansaré de repetirlo. Si algo huele mal, posiblemente es que está podrido.

 

P.D.: Ayer, día Mundial de la Privacidad, fue un día duro para muchos de los que tenemos páginas en internet. Y es que varios de los proveedores de servicio, por una u otra razón, nos dejaron buena parte del día sin acceso a las páginas. En mi caso, yo no podía acceder, pero gracias al sistema de caching y CDN que tengo implantado en este servidor y en la mayoría de los de mis clientes, los usuarios seguramente ni se dieron cuenta (a no ser que intentara enviar un comentario, la página era totalmente operativa). De ahí que ayer no pudiera escribir como viene siendo costumbre. Lamento las molestias.

 

________

Realizar este tipo de artículos me lleva varias horas, y en algunos casos, gastos extra que habitualmente suplo de mi bolsillo, o gracias a esa comunidad de patronos que me apoyan realizando donaciones puntuales o periódicas.

Si le gustaría ver más de estos tutoriales y análisis por aquí. Si el contenido que realizo le sirve en su día a día, piense si merece la pena invitarme a lo que vale un café, aunque sea digitalmente.

hazme patrono pabloyglesias