Compartir a través de

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

  • Artículo

En este artículo se describe la amenaza de seguridad común de la adquisición de subdominios y los pasos que puede seguir para mitigarla.

¿Qué es una adquisición de subdominios?

Las adquisiciones de subdominios son una amenaza común muy grave para las organizaciones que crean y eliminan muchos recursos con regularidad. 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. Permite aprovisionar 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 desaprovisiona o se elimina cuando ya no se necesita.

      En este momento, el registro CNAME greatapp.contoso.com debe 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 las herramientas y los métodos de disponibilidad general, un actor de amenaza detecta el subdominio pendiente.

    2. Este actor aprovisiona un recurso de Azure con el mismo FQDN del recurso que se ha controlado previamente. En este ejemplo, app-contogreat-dev-001.azurewebsites.net.

    3. El tráfico que se envía al subdominio greatapp.contoso.com ahora se enruta al recurso del actor malintencionado en el que se controla el contenido.

Adquisición de subdominios desde un sitio web desaprovisionado

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 la organización para proteger su contenido, perjuicios para la marca y pérdida de confianza.

  • Recopilación de cookies de visitantes confiados: es habitual que las aplicaciones web expongan cookies de sesión a subdominios (*.contoso.com). Cualquier subdominio puede acceder a ellos. Los actores de amenazas pueden usar la adquisición de subdominios para crear una página de aspecto auténtico, engañar a los usuarios confiados para que la visiten y recopilar sus cookies (incluso las cookies seguras). Una idea equivocada habitual es que el uso de certificados SSL protege su sitio y las cookies de los usuarios de una adquisición. 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 suplantación de identidad (phishing): los actores malintencionados suelen explotar los subdominios de aspecto auténtico en campañas de suplantación de identidad (phishing). El riesgo se extiende tanto a sitios web malintencionados como a registros MX, lo que podría permitir que los actores de amenazas reciban correos electrónicos dirigidos a subdominios legítimos asociados a marcas de confianza.

  • Más riesgos: los sitios malintencionados se pueden usar para escalar a otros ataques clásicos, como XSS, CSRF, omisión de CORS, etc.

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 ayuda a los clientes de Azure a mostrar todos los dominios con un CNAME asociado a un recurso de Azure existente creado en sus suscripciones o inquilinos.

Si los CNAME están en otros servicios DNS y apuntan a recursos de Azure, proporcione el 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.

Servicio Tipo FQDNproperty Ejemplo
Azure Front Door microsoft.network/frontdoors properties.cName abc.azurefd.net
Azure Blob Storage microsoft.storage/storageaccounts properties.primaryEndpoints.blob abc.blob.core.windows.net
Azure CDN microsoft.cdn/profiles/endpoints properties.hostName abc.azureedge.net
Direcciones IP públicas microsoft.network/publicipaddresses properties.dnsSettings.fqdn abc.EastUs.cloudapp.azure.com
Administrador de tráfico de Azure microsoft.network/trafficmanagerprofiles properties.dnsConfig.fqdn abc.trafficmanager.net
Azure Container Instances microsoft.containerinstance/containergroups properties.ipAddress.fqdn abc.EastUs.azurecontainer.io
Azure API Management microsoft.apimanagement/service properties.hostnameConfigurations.hostName abc.azure-api.net
Azure App Service microsoft.web/sites properties.defaultHostName abc.azurewebsites.net
Azure App Service - Slots microsoft.web/sites/slots properties.defaultHostName abc-def.azurewebsites.net

Requisitos previos

Ejecute la consulta como un usuario que tenga:

  • al menos acceso de nivel de lector a las suscripciones de Azure
  • acceso de lectura al gráfico de recursos de Azure

Si es administrador global del inquilino de su organización, siga las instrucciones de Elevar el acceso para administrar todas las suscripciones de Azure y los grupos de administración para obtener acceso a todas las suscripciones de la organización

Sugerencia

Azure Resource Graph tiene límites paginación y límites de ancho de banda que debe tener en cuenta si tiene un entorno de Azure de gran tamaño.

Más información sobre el trabajo con grandes conjuntos de datos de recursos de Azure.

La herramienta usa el procesamiento por lotes de suscripciones para evitar estas limitaciones.

Ejecute el script.

Obtenga más información sobre el script de PowerShell, Get-DanglingDnsRecords.ps1y descárguelo desde GitHub: https://aka.ms/Get-DanglingDnsRecords.

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 se detecta que los subdominios están pendientes o se han adquirido, quite los subdominios vulnerables y mitigue los riesgos con 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 permitir que el tráfico se enrute a los recursos del control, aprovisione más recursos con los FQDN especificados en los registros CNAME de los subdominios pendientes.

  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. Investigue si se produjo algún riesgo y tome medidas según los procedimientos de respuesta a incidentes de la organización. Sugerencias y procedimientos recomendados para la investigación:

    Si la lógica de aplicación diera como resultado secretos, como las credenciales de OAuth, se enviará a subdominios pendientes o, si se transmitiera información confidencial de privacidad a esos subdominios, existe la posibilidad de que estos datos se expongan a terceros.

  5. Comprenda por qué el registro CNAME no se quitó de la zona DNS cuando se canceló el aprovisionamiento del recurso y realice los pasos necesarios para asegurarse de que los registros DNS se actualicen correctamente cuando se desaprovisionan los recursos de Azure en el futuro.

Evitación de los registros DNS pendientes

Asegurarse de que su organización ha implementado procesos para evitar las entradas DNS pendientes y las adquisiciones de subdominios resultantes es una parte fundamental del programa de seguridad.

Algunos servicios de Azure ofrecen características que ayudan a crear medidas preventivas y se detallan a continuación. Otros métodos para evitar este problema se deben establecer a través de las prácticas recomendadas de la organización o de los procedimientos operativos estándar.

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 for Cloud, 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. Con este plan habilitado, recibirá alertas de seguridad si retira un sitio web de App Service pero no quita su dominio personalizado del registrador de DNS.

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

Obtenga más información sobre esta y otras ventajas de este plan de Microsoft Defender en Introducción a Microsoft Defender para App Service.

Uso de registros de alias de Azure DNS

Los registros de alias de Azure DNS pueden evitar referencias pendientes mediante un acoplamiento del 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. Ya no hace referencia al recurso eliminado. Es importante tener en cuenta que se aplican límites a lo que se puede proteger con los registros de alias. Actualmente, esta lista se limita a lo siguiente:

  • Azure Front Door
  • 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 actualmente, se recomienda usar registros de alias para defenderse de la adquisición de subdominios siempre que sea posible.

Obtenga más información sobre las funcionalidades de los registros de alias de Azure DNS.

Uso de la comprobación de dominio personalizado de Azure App Service

Al crear entradas DNS para Azure App Service, cree un registro TXT asuid.{subdominio} con el identificador de comprobación de dominio. Cuando existe un registro TXT de este tipo, ninguna otra suscripción a Azure puede validar el dominio personalizado es decir, adquirirlo.

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

Obtenga más información sobre cómo asignar un nombre DNS personalizado existente a Azure App Service.

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

A menudo, los desarrolladores y los equipos de operaciones deben ejecutar procesos de limpieza para evitar las amenazas de DNS pendientes. Los procedimientos siguientes le ayudarán a asegurarse de que su organización evita sufrir 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.

    • Incluya bloqueos de eliminación en los recursos que tengan 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 pueden funcionar si 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:

      • Existentes: consulte las zonas DNS para ver los recursos que apuntan a subdominios de Azure, como *.azurewebsites.net o *.cloudapp.azure.com (consulte la lista de referencia de los dominios de Azure).
      • De su propiedad: confirme que posee todos los recursos a los que se dirigen sus 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. Para compilar el catálogo de servicios, ejecute el siguiente script de consulta de Azure Resource Graph. Este script proyecta la información del punto de conexión de FQDN de los recursos a los que tiene acceso y los envía a un archivo CSV. Si tiene acceso a todas las suscripciones de su inquilino, el script tiene en cuenta todas estas suscripciones, tal y como se muestra en el siguiente script de ejemplo. Para limitar los resultados a un conjunto específico de suscripciones, edite el script como se muestra.

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

    • Cuando se encuentran entradas DNS pendientes, su equipo debe investigar si se ha producido algún riesgo.
    • Investigue por qué la dirección no se reenrutó al retirar 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.

Limpieza de punteros DNS o reclamación del DNS

Tras la eliminación del recurso del servicio en la nube clásico, el DNS correspondiente se reserva durante de acuerdo con las directivas de Azure DNS. Durante el período de reserva, se prohibirá la reutilización del DNS EXCEPTO para las suscripciones que pertenecen al inquilino de Microsoft Entra de la suscripción que posee originalmente el DNS. Una vez expirada la reserva, cualquier suscripción puede reclamar el DNS. Al tomar reservas de DNS, el cliente tiene tiempo para 1) limpiar cualquier asociación o puntero a dicho DNS o 2) reclamar el DNS en Azure. La recomendación sería eliminar las entradas DNS no deseadas al principio. El nombre DNS que se reserva se puede obtener anexando el nombre del servicio en la nube a la zona DNS de esa nube.

  • Public: cloudapp.net
  • Mooncake: chinacloudapp.cn
  • Fairfax: usgovcloudapp.net
  • BlackForest: azurecloudapp.de

Por ejemplo, un servicio hospedado en Public llamado "test" tendría el DNS "test.cloudapp.net".

Ejemplo: La suscripción "A" y la suscripción "B" son las únicas suscripciones que pertenecen al inquilino "AB" de Microsoft Entra. La suscripción "A" contiene un servicio en la nube clásico "test" con el nombre DNS "test.cloudapp.net". Tras la eliminación del servicio en la nube, se toma una reserva en el nombre DNS "test.cloudapp.net". Durante el período de reserva, solo la suscripción "A" o la suscripción "B" podrán reclamar el nombre DNS "test.cloudapp.net" mediante la creación de un servicio en la nube clásico denominado "test". No se permitirá que otras suscripciones lo reclamen. Una vez transcurrido el período de reserva, cualquier suscripción de Azure podrá 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.