Google quiere matar la URL para salvar Internet y aún no sabe cómo

lunes, 17 de septiembre de 2018

¿Cómo sabes que ahora mismo estás en el sitio web de ElevenPaths leyendo este artículo del blog? Posiblemente mirarás hacia la barra de dirección, donde aparece listada la URL: https://blog.elevenpaths.com/2018/09/informe-seguridad-navegadores-movil-ciberseguridad.htm. Sí pero, ¿estás totalmente seguro de que esa cadena alfanumérica corresponde al verdadero sitio web donde se aloja el blog de ElevenPaths y no una suplantación? Yo no estaría tan seguro.

ilustración ordenador perro imagen
Fuente: https://en.wikipedia.org/wiki/On_the_Internet,_nobody_knows_you%27re_a_dog

Este viejo chiste sigue estando de actualidad. Han pasado casi 30 años desde que Tim Berners-Lee creara la Web y aún seguimos sin un método sencillo e infalible para garantizar la identidad de un sitio web.

Internet sigue sumida en una crisis de identidad
Cuando visitamos nuestro banco, nuestro periódico favorito o nuestra red social principal no dedicamos una segunda mirada a la URL. La mayoría de los usuarios de navegadores estiman la identidad de un sitio por su contenido, ni siquiera por su URL, ni mucho menos por su certificado digital. Los usuarios más avanzados verifican la identidad echando un rápido vistazo a la URL. Aun así, muy pocos abren el certificado digital, verifican la ruta de certificación y demás detalles. ¿Qué tipo de validación tiene el certificado?, ¿Tiene validación de dominio (DV), de organización (OV) o extendida (EV)?, ¿Verificas estos aspectos tú mismo en cada sitio web HTTPS que te encuentras?

En definitiva, vivimos sumidos en una crisis de identidad en Internet, donde nadie está seguro de quién está al otro lado de la conexión. Crisis aprovechada por los cibercriminales para montar todo tipo de ataques. Tal vez los más extendidos en este contexto sean los de phishing:
  1. El atacante crea un sitio web que es una réplica fiel del sitio web objetivo.
  2. A continuación, el atacante necesita enviar el cebo: un mensaje que incitará a las víctimas a hacer clic sobre un hiperenlace que conduce al sitio falso en lugar de al original. El vector de ataque puede ser un mensaje de correo, un mensaje en cualquier red social, un comentario en una página web, en definitiva, cualquier soporte para una URL.
  3. La víctima muerde el anzuelo: hace clic en el enlace y es conducida al sitio web del atacante, que parece el original. La réplica es tan convincente que la víctima revela confiada su información confidencial.
  4. El atacante recopila las credenciales u otra información mientras dure el ataque.
En definitiva, ¿en qué se basan los ataques de phishing? En la debilidad del sistema actual de identidad, incapaz de informar con sencillez a cualquier usuario sobre qué página está visitando. Hoy la información recae sobre la URL, y es muy fácil manipularla.

Entendiendo los ataques de suplantación: anatomía de una URL
Estas URL son un vestigio de los primeros años heroicos de Internet. Fueron concebidas para personas acostumbradas a la línea de comando, no para el público en general, que apenas sabe distinguir entre Internet y un navegador. Las URL, como su nombre indica (Uniform Resource Locator o localizador de recursos uniforme), suponen una manera conveniente de acceder a recursos de información alojados en servidores web. Cualquier persona que conozca la URL completa de un recurso podrá acceder a ese recurso de forma inequívoca.

Toda URL se basa en la siguiente sintaxis:

esquema:[//[usuario[:contraseña]@]equipo[:puerto]][/ruta][?consulta][#fragmento]

Donde:
  • Esquema: Indica el protocolo de red usado para recuperar la información del recurso identificado. El nombre de esquema va seguido por dos puntos (:) y dos barras (//). Los esquemas más habituales hoy son http, https, mailto, file o ftp.
  • Usuario y contraseña: Contienen el nombre de usuario y la contraseña de una entidad autorizada para acceder al recurso. Están separados por dos puntos (:). Ambos datos son necesarios únicamente si el recurso exige autenticación básica. Si no se exige autenticación y están presentes, entonces se ignoran. Se utiliza el símbolo @ para separar el nombre de usuario y la contraseña del siguiente segmento.
  • Equipo: Señala un determinado servidor donde se aloja el recurso deseado. Como se explica más adelante, puede representarse simbólica o numéricamente.
  • Puerto: Normalmente se omite, ya que la mayoría de los esquemas ofrecen su servicio en un puerto estándar: 80 en HTTP, 443 en HTTPS o 21 en FTP. Cuando resulta necesario ofrecer el servicio en un puerto no estándar, se especifica el número de puerto, separado del host con dos puntos (:).
  • Ruta: Especifica la ruta de acceso de archivo para el recurso. Empieza con una barra inclinada (/) y reproduce la estructura de directorios donde está alojado el recurso.
  • Consulta: Algunos recursos web contienen elementos ejecutables y esperan, además de una ruta de archivo, una cadena de consulta. Esta consulta puede contener una o más parejas de parámetro/valor, anexadas a la URL y procesadas por las páginas dinámicas en el extremo del servidor. La cadena de consulta se inicia con un símbolo de interrogación (?) y las parejas de parámetros se separan por el símbolo &.
  • Fragmento: Permite hacer referencia a una posición específica dentro de un recurso. Se usa típicamente en las páginas HTML, junto con las etiquetas de ancla.
Para el usuario experto, la URL proporciona todo un tesoro de información acerca del recurso visitado, en especial gracias a la parametrización: tokens, enlaces de afiliados, publicidad, secuencias de navegación, etc. Por desgracia, estas largas y complicadas secuencias de letras y números resultan indescifrables para los no iniciados. Empeorando aún más las cosas, son casi imposibles de mostrar en las pequeñas pantallas de los dispositivos móviles. Esta complejidad fue rápidamente aprovechada por los ciberatacantes, en especial, para el phishing.

Por increíble que nos parezca, millones de personas navegan por Internet cada día sin ser conscientes de que existe una ventanita en su navegador donde aparece la dirección de la página que están visitando. Si (casi) nadie se fija en ella, ¡qué fácil esconder ahí ataques! Estos ataques, denominados de ofuscación de URL, modifican sutilmente la dirección de manera que el usuario desprevenido no perciba nada extraño si llega a echar un vistazo superficial. A continuación, daremos un repaso a los más conocidos.

Dirección del host expresada numéricamente
La dirección de un host en Internet puede codificarse simbólicamente, con letras y números, fáciles de leer y recordar por los humanos, o numéricamente, con un número de 32 bits (en IPv4).

Por ejemplo,
  • Dirección simbólica: blog.elevenpaths.com
  • Dirección numérica: 216.58.201.179

Lo que es menos conocido es que la dirección IP, expresada habitualmente como cuatro grupos de dígitos separados por punto (a.b.c.d), también puede escribirse como un único número entero, ya que:

n = a x 256^3 + b x 256^2 + c x 256 + d

Incluso pueden expresarse en hexadecimal y hasta en octal. De manera que:

blog.elevenpaths.com = 216.58.201.179 = 3627731379 = 0xD83AC9B3

Técnicamente, lo mismo dar usar una que otra. Obviamente, las simbólicas son las que utilizamos las personas para publicar e intercambiar direcciones de equipos en Internet, por su legibilidad y facilidad para recordar. Los servidores DNS son los encargados de hacer esta traducción, lo que los convierte en blanco de ataques. Quien controla los DNS, controla hasta cierto punto la identidad de los sitios web que no usen certificado digital. Pero esa es otra guerra y no la trataremos aquí.

Así pues, una ofuscación trivial consiste en dirigir a la víctima al sitio web del atacante, mostrando en la ventana de URL su dirección numérica en lugar de simbólica. Si la víctima es un usuario medio de Internet, ni se fijará en la URL, y el ataque triunfará fácilmente. Recordemos que la gente se fija en el contenido de la página para validar su identidad, no en la URL.

Dominios de alto nivel con nombres similares a los originales
A poco que un usuario esté atento a la barra de URL y vea una ristra de números en vez del nombre del servidor, sospechará que algo raro pasa y podría abortar la operación.Un refinamiento del ataque anterior consiste en registrar un nombre de dominio que sea muy similar al original, cambiando uno o dos caracteres. Por ejemplo cambiar carácter por número, el orden de letras, omitir una letra, una letra por otra o utilizar caracteres unicode.

Las grandes instituciones suelen registrar múltiples combinaciones de su nombre de dominio, precisamente para mitigar este tipo de ataques de suplantación, dirigidos contra los Dominios de Alto Nivel (TLD).

Subdominios con nombres maliciosos
Este tipo de ofuscación funciona especialmente bien en dispositivos móviles, donde el ancho de la barra de dirección es fijo. El atacante registra un dominio cualquiera, con un subdominio que se corresponde con el nombre de sitio objetivo. Por ejemplo:

www.elevenpaths.com.dominiodelchicomalo.com

Dado que las URL no caben en la ventanita de los navegadores es necesario procesarlas de manera inteligente para hacer visible al usuario sólo su parte más significativa (eliding). Mal hecho, la víctima verá solamente la parte correspondiente al dominio objetivo y no la del dominio del atacante. En el último estudio constatamos que solo el 15 % de los indicadores de seguridad recomendados por la W3C, se encuentran en los navegadores móviles. A los navegadores aún les queda mucho camino por recorrer para identificar con seguridad a los sitios web.

Comparación del sitio original de Steam Login HTTPS imagen
Comparación del sitio original de Steam Login HTTPS con certificado EV a la izquierda en ruso y sitio de phishing HTTPS ruso a la derecha, en el navegador web Opera para Android

Acortadores de direcciones
Desde la aparición de Twitter, se volvieron extremadamente populares y ahora se utilizan en cualquier contexto. Son en sí mismos ofuscadores de URL, ya que toman la URL original y la comprimen a un tamaño más manejable. Entre las más populares destacan bit.ly, tinyurl, goo.gl, o amzn.to, por citar solo algunas. Claro está, la mera observación de una URL acortada impide saber a dónde dirige. Sí que existen sitios web que informan de la URL sin acortar, pero ¿quién se toma las molestias de verificar una URL acortada antes de hacer clic sobre ella? ¿Lo haces tú rutinariamente? Lo cierto es que los usuarios están tan acostumbrados a toparse con este formato de URL que no suelen despertar sospechas.

Autenticación básica
Observa cuidadosamente esta URL. ¿A dónde te llevará?

https://mibanco.com/NASApp/Net2/Gestor?PORTAL_CON_DCT=SlI&PRESTACION=login&FUNCION=directoportal&ACCION=control&destino=@3627731379

Una mirada superficial podría hacer pensar en que conduce a una página dinámica en mibanco.com. En realidad, se está haciendo uso del segmento usuario de la URL para distraer la atención del verdadero servidor al que redirige, codificado tras la arroba (@): 3627731379. Es decir, en verdad está apuntando al servidor de ElevenPaths. Afortunadamente, las últimas versiones de los navegadores son capaces de contrarrestar estas ofuscaciones.

¿Qué ha hecho Google hasta ahora?
El protocolo TLS junto con los certificados digitales constituyen la mejor defensa presente contra esta crisis de identidad. En un movimiento audaz, en el Google I/O 2014 la compañía anunció su eslogan "HTTPS Everywhere", incluyendo el https como señal de ranking: penaliza con un peor posicionamiento SEO a los sitios web que carecen de certificado digital y que, por lo tanto, no soportan el esquema https://. Desde enero de 2017, además Google Chrome comenzó a indicar al navegante la seguridad de la conexión con un icono en la barra de dirección, restringiendo progresivamente sus criterios. A partir de julio de 2018, Chrome marca como "No es seguro" todos los sitios HTTP. En breve, se destacará este mismo texto, pero en color rojo parpadeante. El objetivo de Google es acostumbrar a los navegantes a una web "segura por defecto (safe by default)".

Como consecuencia, resulta difícil ya encontrar sitios web "serios" sin soporte para TLS. Y, con el tiempo, todo hace pensar que la postura de Google se radicalizará aún más. ¿Llegará a bloquear el acceso con Chrome a sitios sin HTTPS? Qué duda cabe que se está perfilando una gran oportunidad para los servicios de certificación.

Además, para "aligerar" las URLs, Chrome en sus últimas versiones ha decidido ocultar subdominios como "www." y "m" en su barra de navegador por considerarlos triviales, algo que no ha dejado de sembrar polémica.

Cuantos más HTTPS, ¿peor seguridad?
Y aquí viene la contrapartida de este movimiento de Google. Conseguir un certificado TLS es ahora más fácil (y barato) que nunca. Como consecuencia, los ciberatacantes usarán por supuesto HTTPS en sus sitios maliciosos copiados de los originales. Lo que significa que sus sitios web inseguros llevarán un flamante icono "Es seguro" de color verde, al menos hasta el momento en que caigan en las listas negras de Google.

imagen ilustrativa de https con diferentes páginas web

Ahora bien, cuando Chrome dice "Es seguro", ¿qué quiere decir? TLS garantiza la confidencialidad del canal. Es decir, el usuario puede tener la certeza de que sus datos no pueden ser interceptados en tránsito desde el navegador al servidor o desde el servidor al navegador. ¿Significa eso que el sitio es seguro? Obviamente no. Los datos podrían ser manipulados irresponsablemente en el servidor o caer en manos de un atacante que lo asaltase. En definitiva, "es seguro" significa canal seguro, para nada significa sitio web seguro. ¿Cuántos usuarios serán capaces de discernir estos finos detalles criptográficos? Ese indicador proporcionará una falsa sensación de seguridad: pensarán que mientras un sitio tenga el indicador verde es seguro proporcionarle los datos personales.

Así que vamos a recapitular:
  • Los usuarios de navegadores no son muy avezados en eso de leer URLs. Como declaró a la revista Wired hace poco Adrienne Porter Felt, directora de ingeniería de Chrome: "[Las URL] Son difíciles de leer, es difícil saber en qué parte de ellas se supone que debemos confiar, y en general no creo que las URL estén funcionando como una forma válida de transmitir la identidad del sitio".
  • Los usuarios buscan formas fáciles de saber si un sitio es de fiar o no. ¿Qué mejor lugar donde mirar que el icono de Google, que informa «Es seguro» en verde o «No es seguro» en rojo?
  • Los usuarios navegarán con mayor confianza que nunca por los sitios maliciosos, porque ahora Chrome les asegurará que «son seguros».
Ya tenemos servido el cóctel para un auge en los ataques de phishing.

Si no es la URL, entonces... ¿qué?
En estas circunstancias, no es de extrañar que Google quiera matar la URL. Declara Porter Felt en la misma entrevista que "queremos avanzar hacia una situación en la que la identidad web sea comprensible por todos: que puedan saber con quién están hablando cuando están visitando un sitio web y puedan razonar si se puede confiar en él. Pero harán falta grandes cambios en cómo y en cuándo Chrome muestra las URL. Queremos desafiar la manera como las URL deberían mostrarse y cuestionarla mientras damos con la forma correcta de comunicar la identidad». Ahí es nada. De momento, Google tiene claro que la URL debe morir, pero aún no han encontrado la forma. Sea cual sea el mecanismo que inventen, eso sí, despertará grandes polémicas. Mientras ese día llega, seguiremos mirando la URL y viendo los detalles de los certificados. Y tú, ¿cómo crees que deberían evolucionar las URL?

Gonzalo Álvarez de Marañón
Equipo de Innovación y Laboratorio de ElevenPaths

2 comentarios:

  1. Después de leer este estupendo post, se me ocurre que pudiéramos tener un servicio que además de validar el "canal seguro" sea capaz de validar el contenido seguro, planteo varias formas 1 validar todos los scripts que se importan en dicha web generando un hash de dichos scripts y verificandolos contra una bd de cdn seguros al estilo imphash.
    2 Generar capturas de pantalla para a través de Machine Learning, buscar posibles coincidencias de imágenes y así intentar evitar el phishing.
    3 Intentar mediante una extensión de Chrome indicarle al usuario que su canal y web es "seguro" y los criterios que se han tenido en cuenta.
    Un Saludo al equipo de Eleven Path, de vuestro lector Rafael Rivera Tablada

    ResponderEliminar
  2. ¡Gran post!

    Un pequeño detalle, hay una errata en la expresión:

    n = a x 2563 + b x 2562 + c x 256 + d

    Faltan los operadores de potencia:

    n = a x 256^3 + b x 256^2 + c x 256 + d

    ResponderEliminar