Evitar las entradas DNS pendientes y la adquisición de subdominios

Este artículo describe la amenaza de seguridad común de la toma de subdominio y los pasos que puedes tomar para mitigarla.

¿Qué es una adquisición de subdominios?

Las adquisiciones de subdominios son una amenaza común y de alta gravedad para organizaciones que crean y eliminan regularmente muchos recursos. Una adquisición de subdominios puede producirse cuando tiene un registro DNS que apunta a un recurso de Azure desaprovisionado. Estos registros DNS también se conocen como entradas "DNS pendientes". Los registros CNAME son especialmente vulnerables a esta amenaza. Las adquisiciones de subdominios permiten a los actores malintencionados redirigir el tráfico destinado al dominio de una organización a un sitio que realiza una actividad malintencionada.

El siguiente es un escenario común de adquisición de subdominio:

1. CREACIÓN:

   1. Configuras un recurso de Azure con un nombre de dominio completo (FQDN) de app-contogreat-dev-001.azurewebsites.net.

   2. Puede asignar un registro CNAME en la zona DNS con el subdominio greatapp.contoso.com que enruta el tráfico a su recurso de Azure.

2. DESAPROVISIONAMIENTO

   1. El recurso de Azure se desprovisiona o elimina cuando ya no se necesita.

      En este momento, el registro CNAME greatapp.contoso.comdebe quitarse de la zona DNS. Si no se quita el registro CNAME, se anuncia como un dominio activo pero no enruta el tráfico a un recurso activo de Azure. Ya tiene un registro DNS "pendiente".

   2. El subdominio pendiente, greatapp.contoso.com, ahora es vulnerable y se puede adquirir mediante su asignación a otro recurso de suscripción de Azure.

3. ADQUISICIÓN:

   1. Con métodos y herramientas comúnmente disponibles, un atacante descubre el subdominio abandonado.

   2. El actor de amenaza aprovisiona un recurso de Azure con el mismo FQDN del recurso que controlabas previamente. En este ejemplo, app-contogreat-dev-001.azurewebsites.net.

   3. El tráfico enviado al subdominio greatapp.contoso.com ahora se enruta al recurso del actor malicioso, donde controla el contenido.

Riesgos de la adquisición de subdominios

Cuando un registro DNS apunta a un recurso que no está disponible, el propio registro debería quitarse de la zona DNS. Si no se elimina, es un registro "DNS pendiente" y crea la posibilidad de que se produzca la adquisición de subdominios.

Las entradas DNS pendientes permiten a los actores de amenazas tomar el control del nombre DNS asociado para hospedar un servicio o un sitio web malintencionado. Las páginas y los servicios malintencionados del subdominio de una organización pueden dar lugar a:

• Pérdida de control sobre el contenido del subdominio: Prensa negativa sobre la incapacidad de tu organización para proteger su contenido, daño a la marca y pérdida de confianza.

• Recolección de cookies de visitantes desprevenidos: Es común que las aplicaciones web expongan las cookies de sesión a subdominios (*.contoso.com). Cualquier subdominio puede acceder a ellos. Los actores maliciosos pueden usar la toma de subdominios para crear una página de aspecto auténtico, engañar a usuarios desprevenidos para que la visiten y obtener sus cookies (incluso las seguras). Un error común es pensar que los certificados SSL protegen tu sitio y las cookies de tus usuarios frente a una toma de control. Sin embargo, un actor de amenaza puede usar el subdominio secuestrado para solicitar y recibir un certificado SSL válido. Los certificados SSL válidos les conceden acceso a las cookies seguras y pueden aumentar aún más la legitimidad aparente del sitio malintencionado.

• Campañas de phishing: Los actores maliciosos suelen explotar subdominios de aspecto auténtico en campañas de phishing. El riesgo se extiende tanto a sitios web maliciosos como a registros MX. Los registros MX podrían permitir que los actores malintencionados reciban correos electrónicos dirigidos a subdominios legítimos asociados a marcas de confianza.

• Riesgos adicionales: Los sitios maliciosos pueden escalar a otros ataques clásicos como XSS, CSRF, CORS BYPASS y más.

Identificación de las entradas DNS pendientes

Para identificar las entradas DNS de la organización que podrían estar pendientes, utilice las herramientas de PowerShell "Get-DanglingDnsRecords" hospedadas en GitHub de Microsoft.

Esta herramienta te ayuda a listar todos los dominios con un CNAME asociado a un recurso de Azure existente que hayas creado en tus suscripciones o tenants.

Si los CNAME están en otros servicios DNS y apuntan a recursos de Azure, proporcione los CNAME en un archivo de entrada a la herramienta.

La herramienta admite los recursos de Azure que se muestran en la tabla siguiente. La herramienta extrae, o toma como entradas, todo el CNAME del inquilino.

Requisitos previos

Ejecute la consulta como un usuario que tenga:

• Al menos el acceso de rol Reader a las suscripciones de Azure.
• Acceso de lectura a Azure Resource Graph.

Si eres Administrador Global del tenant de tu organización, sigue las indicaciones de Elevate Access para gestionar todas las suscripciones y grupos de gestión de Azure y así acceder a todas las suscripciones de tu organización.

Ejecute el script.

Para obtener más información sobre el script de PowerShell, consulte Get-DanglingDnsRecords.ps1.

Corrección de las entradas DNS pendientes

Revise las zonas DNS e identifique los registros CNAME que estén pendientes o que se hayan adquirido. Si encuentras subdominios colgantes o tomados, elimina los subdominios vulnerables y mitiga los riesgos utilizando los siguientes pasos:

1. En la zona DNS, quite todos los registros CNAME que señalen a los FQDN de los recursos que ya no se aprovisionan.

2. Para enrutar el tráfico a los recursos que controla, aprovisione más recursos con los FQDN especificados en los registros CNAME de los subdominios huérfanos.

3. Revise el código de aplicación para ver las referencias a subdominios específicos y actualice las referencias de subdominios incorrectas o no actualizadas.

4. Investiga si ha habido algún compromiso y actúa conforme a los procedimientos de respuesta a incidentes de tu organización. Para consejos y mejores prácticas para investigar:

   Si la lógica de tu aplicación da como resultado que secretos, como credenciales OAuth, se envíen a subdominios colgantes o si se transmite información sensible a la privacidad a esos subdominios, estos datos podrían estar expuestos a terceros.

5. Entiende por qué el registro CNAME no fue eliminado de tu zona DNS cuando desprovisionaste el recurso y toma medidas para asegurarte de que los registros DNS se actualicen adecuadamente cuando los recursos de Azure se desprovisionen en el futuro.

Evitación de los registros DNS pendientes

Haz que los procesos que eviten entradas DNS pendientes y las consiguientes adquisiciones de subdominios sean una parte crucial de tu programa de seguridad.

Las siguientes secciones describen las características del servicio de Azure que pueden ayudar a crear medidas preventivas. Establece otros métodos para prevenir este problema mediante las mejores prácticas o procedimientos operativos estándar de tu organización.

Habilitación de Microsoft Defender para App Service

La plataforma integrada de protección de cargas de trabajo en la nube (CWPP) de Microsoft Defender para la nube, ofrece una amplia variedad de planes para proteger sus cargas de trabajo y recursos híbridos, de varias nubes y de Azure.

El plan de Microsoft Defender para App Service incluye la detección de DNS pendiente. Cuando activas este plan, recibes alertas de seguridad si desmantelas un sitio web de servicio de aplicaciones pero no eliminas su dominio personalizado de tu registrador DNS.

La protección DNS colgante de Microsoft Defender para la nube está disponible tanto si gestionas tus dominios con Azure DNS como con un registrador de dominios externo, y se aplica a App Service tanto en Windows como en Linux.

Para más información sobre esta función y otros beneficios de estos planes Microsoft Defender, consulte Introducción a Microsoft Defender para Servicios de Aplicaciones.

Uso de registros de alias de Azure DNS

Los registros de alias de Azure DNS pueden evitar referencias colgantes al acoplar el ciclo de vida de un registro DNS con un recurso de Azure. Por ejemplo, considere un registro DNS que se califica como un registro de alias que apunte a una dirección IP pública o a un perfil de Traffic Manager. Si elimina los recursos subyacentes, el registro de alias de DNS se convierte en un conjunto de registros vacío. El registro de alias DNS ya no hace referencia al recurso eliminado. Los registros de alias tienen límites en lo que pueden proteger. La lista se limita actualmente a:

• Azure Front Door (portal de entrada de Azure)
• Perfiles de Traffic Manager
• Puntos de conexión de Azure Content Delivery Network (CDN)
• Direcciones IP públicas

A pesar de las ofertas de servicio limitadas hoy en día, utiliza registros de alias para defenderte contra la adquisición de subdominios siempre que sea posible.

Para más información, consulte capacidades de registros de alias de Azure DNS.

Utilice la verificación de dominio personalizado de Azure App Service

Cuando crees entradas DNS para Azure App Service, crea un asuid.{subdomain} registro TXT con el ID de verificación del dominio. Cuando existe un registro TXT de este tipo, ninguna otra suscripción de Azure puede validar el dominio personalizado ni tomarlo.

Estos registros no impiden que alguien cree una instancia de Azure App Service con el mismo nombre que aparece en tu entrada CNAME. Sin la capacidad de demostrar la propiedad del nombre de dominio, los actores malintencionados no pueden recibir tráfico ni controlar el contenido.

Para más información, consulta Mapear un nombre DNS personalizado existente a Azure App Service.

Compilación y automatización de procesos para mitigar la amenaza

Los desarrolladores y los equipos de operaciones deberían ejecutar procesos de limpieza para evitar amenazas DNS pendientes. Las siguientes prácticas ayudan a tu organización a evitar esta amenaza.

• Creación de procedimientos para la prevención:

  • Instruya a los desarrolladores de aplicaciones para que redirijan las direcciones siempre que eliminen recursos.

  • Incluya "Quitar entrada DNS" en la lista de comprobaciones necesarias al retirar un servicio.

    • Añade bloqueos de borrado a cualquier recurso que tenga una entrada DNS personalizada. Un bloqueo de eliminación sirve como indicador para quitar la asignación antes de desaprovisionar el recurso. Medidas como esta solo funcionan cuando se combinan con programas educativos internos.

• Creación de procedimientos para la detección:

  • Revise los registros DNS con regularidad para asegurarse de que todos los subdominios están asignados a recursos de Azure:

    • Existir: Consulta tus zonas DNS para encontrar recursos que apunten a Azure subdominios como *.azurewebsites.net o *.cloudapp.azure. com (véase la lista de referencias de dominios de Azure).
    • Eres propietario: Confirma que eres propietario de todos los recursos a los que apuntan tus subdominios DNS.

  • Mantenga un catálogo de servicios de los puntos de conexión de nombre de dominio completo (FQDN) de Azure y los propietarios de la aplicación. Utiliza Azure Resource Graph, el portal de Azure u otro proceso de inventario de activos para exportar regularmente la información del endpoint FQDN de los recursos a los que puedas acceder. Si tienes acceso a todas las suscripciones en tu tenant, incluye todas las suscripciones en el inventario. Si no lo haces, documenta qué suscripciones cubre el inventario.

• Creación de procedimientos para la corrección:

  • Cuando su equipo encuentre entradas DNS huérfanas, investigue si se ha producido alguna vulneración de la seguridad.
  • Investigue por qué la dirección no se reenrutó cuando se dio de baja el recurso.
  • Elimine el registro DNS si ya no está en uso o apunte al recurso de Azure (FQDN) correcto que pertenece a su organización.

Limpia los punteros DNS o recupera el DNS

Cuando eliminas un recurso clásico de servicio en la nube, Azure reserva el nombre DNS correspondiente según las políticas de Azure DNS. Durante el periodo de reserva, solo las suscripciones que pertenezcan al tenant de Microsoft Entra de la suscripción a la que pertenecía originalmente el nombre DNS pueden reutilizarlo. Tras expirar la reserva, cualquier suscripción de Azure puede reclamar el nombre DNS. Las reservas DNS te dan tiempo para limpiar asociaciones o punteros al nombre DNS, o para recuperar el nombre DNS en Azure. Elimina las entradas DNS no deseadas lo antes posible. Puedes derivar el nombre DNS reservado añadiendo el nombre del servicio en la nube a la zona DNS de esa nube.

• Público: cloudapp.net
• Pastel de luna: chinacloudapp.cn
• Fairfax: usgovcloudapp.net
• Selva Negra: azurecloudapp.de

Por ejemplo, un servicio alojado en Public llamado test tiene el nombre test.cloudapp.netDNS .

Ejemplo: Las suscripciones A y B son las únicas suscripciones que pertenecen al inquilino de Microsoft Entra AB. La suscripción A contiene un servicio en la nube clásico llamado test con el nombre test.cloudapp.netDNS . Cuando eliminas el servicio en la nube, Azure reserva el nombre test.cloudapp.netDNS . Durante el periodo de reserva, solo una suscripción A o suscripción B puede reclamar el nombre test.cloudapp.net DNS creando un servicio en la nube clásico llamado test. Ninguna otra suscripción puede reclamarlo. Transcurrido el período de reserva, cualquier suscripción de Azure puede reclamar test.cloudapp.net.

Pasos siguientes

Para obtener más información sobre los servicios relacionados y las características de Azure que puede usar para defenderse de la adquisición de subdominios, consulte las páginas siguientes.

• Activar Microsoft Defender para el servicio de aplicaciones - Recibe alertas cuando se detecten entradas DNS pendientes.

• Impedir que los registros DNS queden pendientes con Azure DNS

• Uso de un identificador de comprobación de dominio al agregar dominios personalizados en Azure App Service

• Inicio rápido: Ejecutar la primera consulta de Resource Graph con Azure PowerShell