Riesgos de los certificados SSL gratuitos modernos y registros DNS obsoletos

Riesgos de los certificados SSL gratuitos modernos y registros DNS obsoletos

Los certificados SSL han sido adoptados por muchos sitios web, pero en los últimos cuatro años, la adopción de SSL ha crecido enormemente. Una de las principales razones de ese crecimiento gigante es el hecho de que Google y otras compañías como Let's Encrypt alientan a los usuarios a proteger sus sitios web encriptando la información mediante un certificado SSL.

A pesar de haber existido durante más de dos décadas, los certificados SSL (HTTPS) comenzaron a crecer en popularidad en el 2014 y en el año 2018 se terminó convirtiéndose en uno de los temas de la seguridad más populares de todo Internet.

En la actualidad casi todos los usuarios quieren implementar un certificado SSL debido a que están en un principio creando un entorno seguro para sus visitantes, pero muchos ignoran los riesgos que pueden suponer los registros dns obsoletos.

Los origines del uso de los certificados SSL

En los últimos años, no era tan importante si tu sitio no estaba usando un certificado SSL. Solo los sitios web que operaban con tarjetas de crédito o que realizaban un procesamiento de datos confidenciales eran los únicos que debían usar certificados SSL. De hecho, nunca obtendría una certificación PCI válida para su tienda en línea si no instaló un certificado SSL.

En ese momento, los certificados SSL gratuitos no eran una opción, y la mayoría de los usuarios tenían que confiar en los populares proveedores de SSL, como las soluciones de Symantec, Trustwave o Comodo.

Antes del 2014, tener un sitio web con HTTPS era una tarea bastante complicada, ya que seguramente incluiría un certificado SSL caro, así como características de alojamiento adicionales para tener una IP dedicada, o el pago de certificados CDN SSL.

Pero los problemas de mover un sitio web a HTTPS no se notaban solo por el gasto económico que requiere. Realizar la configuración de una dirección IP dedicada para una web requería tiempo de propagación para los DNS, para que el administrador del sitio web pueda comenzar a generar los códigos de CSR para enviarlos a su proveedor de SSL. Una vez que los proveedores aprueben el SSL, le responderían con un código de CRT; el que finalmente instalaría en su sitio para tener la configuración SSL activa.

Hoy en día las cosas han cambiado, el SSL gratuito está disponible para todos, las IP dedicadas ya no son necesarias, y el proceso de instalación se puede realizar con unos pocos clics por personas que no tengan conocimientos técnicos en tan solo unos segundos.

La historia detrás de la adopción masiva de SSL

Desde principios de los años 90 hasta 2014, la adopción de SSL fue bastante lenta y solo fue utilizada por sitios web que trabajaban con información sensible como con las tarjetas de crédito o banca en línea.

Una de las primeras compañías que comenzó a ofrecer certificados SSL gratuitos fue Cloudflare, que anunció su SSL gratuito universal en 2014. En marzo del 2016, Google anunció su objetivo de una Internet segura, mostrando sus planes para hacer de Internet un lugar más seguro.

Let's Encrypt nació más tarde por varias compañías que fundaron el Internet Security Research Group (ISRG). Este fue el primer paso para que los certificados SSL estén disponibles gratuitamente para todos.

Otras compañías como Comodo y cPanel se unieron para ofrecer certificados SSL gratuitos, haciendo que la configuración SSL sea aún más fácil y casi 100% automatizada.

Ahora que los certificados SSL gratuitos están disponibles para cualquier persona, la adopción se ha vuelto masiva para casi todos los propietarios de sitios web y proveedores de servicios basados en Internet.

Let's Encrypt stats muestra que en la actualidad tienen 70 millones de certificados activos emitidos para nombres de dominio completamente desde la fecha de fundación hasta marzo del 2018.

crecimiento-lets-encrypt

La mayoría de las grandes compañías de TI usan cifrados ssl ofreciendo una mejor seguridad para todos sus usuarios. Un buen ejemplo de esto es cómo Google comenzó a migrar casi todos sus servicios y plataforma (93~95% en este momento) para usar el cifrado SSL:

uso-del-cifrado-ssls

Además de ofrecer certificados SSL gratuitos, también ayudó a esta gran adopción de los certificados SSL fue la automatización de las validaciones de dominio en el proceso de instalación de SSL. La instalación de un SSL no es difícil en absoluto, pero requiere que el registrador/proveedor de SSL se asegure de ser el propietario del dominio antes de aprobar su certificado.

Los nuevos SSL gratuitos ofrecidos por empresas populares como Let's Encrypt o Comodo funcionan de forma automática, lo que evita el proceso de espera eterno hasta que el registrador le envíe el código CRT para que pueda instalarlo en su sitio web.

En lugar de eso, usan procesos de validación de dominio automatizados que aceleran mucho la propiedad del dominio. Sin embargo, las recientes investigaciones de seguridad descubrieron nuevos riesgos de este tipo de validación de dominio cuando se combina especialmente con registros obsoletos del DNS.

Validaciones SSL basadas en dominio y registros DNS obsoletos

Investigadores de seguridad de TU Delft, UT Dallas y UC Santa Barbara publicaron un documento que muestra los riesgos de utilizar dominios SSL basados en la confianza lo puede permitir sufrir ataques dominios de adquisición explotando la reutilización de direcciones IP en los dos proveedores públicos más grandes de la nube en el mundo (Microsoft Azure y Amazon AWS). Los registros DNS obsoletos también son uno de los puntos clave en esta investigación.

¿Qué es un registro DNS obsoleto?

Un registro DNS obsoleto es solo un registro que señaló a una IP específica hace tiempo y que ahora mismo ya no dispone de la misma.

Supongamos que compra un servicio en la nube para la base de conocimientos en línea de su empresa definida en el subdominio: kb.suempresa.com, y lo señala a una IP predefinida como 123.123.23.23.

Al final, usted termina en el servicio en la nube que compró originalmente. Pero no elimina el registro DNS que creó para cd.domain.com. Ese es un registro DNS obsoleto es registro que aún existe para un servicio en la nube descontinuado.

Los atacantes pueden usar registros DNS obsoletos para generar nuevos vectores de ataque

Al escanear los registros DNS a través del historial de DNS, un atacante podría notar fácilmente los registros DNS obsoletos presentes en su nombre de dominio. Un atacante podría asignar direcciones IP a las que apuntan los registros DNS obsoletos, suplantar el servicio y luego instalar un certificado SSL validado.

Imagine que se despierta una mañana y descubre que el subdominio que usa como base de conocimientos (recuerde el ejemplo de cd.domain.com) que usaron sus clientes en el pasado ahora está en línea, funciona con un certificado HTTPS completo y probablemente se usa para realizar ataques maliciosos de phishing, malware o spamming.

En sus pruebas, los investigadores de seguridad encontraron que este tipo de ataques podrían ejecutar el ataque en menos de 70 segundos (tiempo más lento que la mayoría de la configuración TTL en registros DNS), permitiendo a los atacantes incluso interrumpir los servicios normales sin registros DNS obsoletos durante el tiempo de migración de un servicio a otro.

¿Hay alguna manera de mitigar este tipo de ataques?

La mejor forma de evitar la validación de este dominio y los ataques basados en registros obsoletos de DNS es introducir un nuevo método de autenticación en el proceso de validación de dominio.

Básicamente, la mitigación propuesta incluye el nuevo llamado "Desafío de validación de identificador resistente a adquisición de dominio" en el protocolo ACME (actualmente utilizado por Let's Encrypt para automatizar el proceso de emisión de certificación SSL), específicamente al introducir la nueva fase de validación dentro de ACMEv2 RFC.

Una cosa buena de este nuevo método de mitigación es mantener el proceso de validación del dominio SSL lo más simple posible para el usuario final, que a menudo no es técnico.

En este caso, este cambio es 100% transparente, ya que no se necesita una solicitud de certificado adicional: la misma solicitud de certificado se utilizará en el proceso de emisión del certificado SSL.

¿Como funciona?

  1. El cliente envía una solicitud de certificado para el nombre de dominio, por ejemplo, domain.com a una autoridad de certificación que valida el dominio.
  2. La autoridad de certificación verifica si ya existe un certificado SSL para el dominio o no.
  3. Quién solicita el SSL debe superar la comprobación de los DNS o basado en whois si un certificado anterior ya existe.
  4. Una vez que la URL ha sido verificada, la CA autorizará que se emita el certificado SSL.

La fase de transición del modelo de validación actual al nuevo no debería ser difícil para los proveedores de SSL actuales, ya que hay muchas validaciones ya utilizadas en las configuraciones actuales.

Reanudar: agregar la nueva capa de autenticación y mitigación no causaría ningún problema adicional, sino que ayudaría a prevenir nuevos problemas de seguridad.

Para un análisis completo y profundo de cómo funciona esta solución técnica, puede encontrarla en la investigación original, "Cloud Strife: Mitigating the Security Risks of Domain-Validated Certificates", en el capítulo IV. MITIGATION (página 08).

Además de este nuevo desafío de autenticación, los autores sugieren recomendaciones generales de seguridad para propietarios de dominios y proveedores basados en la nube para reducir su exposición y la de sus clientes a problemas de DNS para evitar ataques de control de dominio como la asignación de direcciones IP y operaciones de liberación de direcciones IP, reforzando DNS seguridad, implementación de DNSSEC, entre otros.

Conclusión

Como puede ver, estos riesgos pueden reducirse adoptando nuevas tecnologías de mitigación por parte de los proveedores de SSL, pero también por la mayoría de los proveedores de Cloud necesitan seguir las mejores prácticas desde los servidores TCP/IP y DNS, así como cambiar los modelos de asignación de IP.