Nota: Este artículo ha sido publicado originalmente en el blog de Advantio en idioma inglés.

La norma de seguridad de datos de la industria de tarjetas de pago (Payment Card Industry Data Security Standard – PCI DSS) define una serie de controles físicos, lógicos y administrativos para la protección de datos de tarjetas de pago, con especial énfasis en el Número de Cuenta Primario (Primary Account Number – PAN).

En términos técnicos, PCI DSS incluye referencias explícitas a controles de seguridad como cortafuegos (firewalls), firewalls de aplicación web (Web Application Firewalls – WAF), antivirus, monitorización de integridad de ficheros (File Integrity Monitoring – FIM), sistemas de detección / prevención de intrusiones (IDS/IPS), servicios de sincronización de tiempo (NTP), registro de eventos (logs), uso de versiones seguras de protocolos (como TLS, por ejemplo), etc. No obstante, no se incluyen controles específicos para uno de los componentes críticos de una arquitectura de red: el sistema de nombres de dominio (Domain Name System – DNS). Y es precisamente en el servicio de DNS en donde se puede encontrar un “punto ciego” en el cumplimiento del estándar.

Para entrar en contexto, el DNS es una base de datos distribuida y jerárquica que usa el modelo cliente-servidor y que permite la asociación de un nombre de dominio (conocido como Fully Qualified Domain Name – FQDN) y otros datos asociados (conocidos como “registros”) con una dirección IP. La descripción técnica de los conceptos y criterios de implementación y especificación del sistema de resolución de nombres se encuentran descritos en las RFC1034 y RFC1035.

En términos generales, existen 5 elementos principales dentro de un sistema de resolución de nombres:

  • Cliente: Componente dentro de una máquina cliente que realiza solicitudes de resolución de nombres para su funcionamiento (navegadores, clientes de correo electrónico, etc.).
  • DNS resolver (también conocido como “recursor” o “iterator”): Servidor encargado de recibir las peticiones de clientes para resolución de nombres. Emplea almacenamiento temporal de registros ya resueltos (caching) para optimizar los tiempos de respuesta.
  • Root nameserver: Servidor encargado de proporcionar el nombre y la dirección IP del servidor autorizado de la zona de más alto nivel para el dominio buscado. Actualmente existen 13 servidores de este tipo en el mundo.
  • TLD (Top Level Domain) nameserver: Servidor que mantiene la información de todos los nombres de dominio que comparten una extensión de dominio común, como .com o .net. Existen varios tipos de servidores TLD, entre ellos los genéricos o gTLD (.com, .net, .edu, .org y .gov) y de país o ccTLD (.uk, .co, .jp, .es, etc.). La lista completa se puede consultar aquí.
  • Authoritative nameserver: Servidor que contiene la información específica del dominio que gestiona (por ejemplo yahoo.com) y retorna la dirección IP del nombre de host especificado al DNS resolver que realizó la petición inicial.

Al igual que muchos otros servicios que hicieron parte de los orígenes de internet, el DNS se desarrolló con el fin de ser operativo y escalable, pero la seguridad no fue parte de estos criterios iniciales: no había autenticación, la integridad de las respuestas no se validaba y los datos se transmitían en texto claro, deficiencias que empezaron a ser explotadas por atacantes a través de las siguientes técnicas:

  • DNS spoofing / cache poisoning: En este ataque se introducen datos de DNS falsificados en la caché del DNS resolver, lo que hace que el resolver devuelva una dirección incorrecta para un dominio, desviando el tráfico a una máquina maliciosa o cualquier otro lugar que el atacante desee, con el fin de distribuir malware o recolectar datos de inicio de sesión.
  • DNS Tunnelling: Esta técnica permite el encapsulamiento de otros protocolos (como SSH o HTTP) en peticiones de DNS con el fin de evitar las restricciones a nivel de filtrado de paquetes, empleado para exfiltración de datos o para comunicación con servidores de mando y control (Command and Control – C&C).
  • DNS hijacking: Mediante esta técnica el atacante redirige las consultas a un servidor de nombre de dominio diferente empleando malware o modificando el servidor DNS.
  • Ataques de reflexión/amplificación y denegación de servicio: En estos ataques se emplea la infraestructura de resolución de nombres para crear tráfico malicioso que se dirige hacia objetivos específicos o para saturar la operación del servicio. Algunos de estos ataques más conocidos dentro de esta categoría son NXDOMAIN, Phantom, Random subdomain, domain lock-up, botnet-based CPE, etc.

DNS y su relación con PCI DSS

Tal y como se indicaba anteriormente, el estándar PCI DSS no incluye ninguna referencia explícita al uso de controles de seguridad en la infraestructura de resolución de nombres, por lo que durante una implementación o una evaluación formal de cumplimiento pueden surgir las siguientes preguntas que pueden afectar la seguridad del entorno:

  • ¿Se puede considerar el protocolo DNS y su puerto estándar (53/UDP) como “seguros”?
  • ¿Es necesario implementar consideraciones adicionales de seguridad en una infraestructura de resolución de nombres tradicional?
  • ¿Se requiere la designación de un servidor específico de resolución de nombres dentro de una red que procesa, almacena y/o transmite datos de tarjetas de pago?
  • ¿Cómo se debe realizar la conexión entre un cliente y un servidor de DNS para efectuar una resolución de nombres en un entorno alineado con PCI DSS?
  • ¿Qué criterio se debe emplear al escoger un servidor de resolución de nombres autoritativo?
  • ¿Son confiables los servidores root y TLD que funcionan en la parte superior de la jerarquía de DNS?
  • ¿Los proveedores de servicios de registro de nombres deberían estar listados como proveedores de servicio de PCI DSS?

Actualmente, muchas de estas preguntas no tienen una respuesta oficial, por lo que es bastante probable que la gran mayoría de entornos que cumplen con PCI DSS tengan implementados controles mínimos o insuficientes para proteger de ataques su infraestructura de resolución de nombres.

En ese sentido, a continuación, se enumeran una serie de recomendaciones para proteger los servicios de DNS del entorno de tarjetas de pago, complementando los requisitos básicos de PCI DSS:

Recomendación Descripción
Arquitectura del servicio de resolución de nombres (DNS) Con el objetivo de implementar una arquitectura segura del servicio de DNS, se recomienda seguir los siguientes lineamientos:
• Instalar al menos un servidor interno dedicado que actúe como DNS resolver para el entorno PCI DSS. Dependiendo de la complejidad de la red, se pueden usar servidores DNS internos por zonas geográficas, delegaciones, etc.
• El servidor de DNS que realiza consultas a servidores DNS externos debe estar ubicado en la DMZ.
• El tráfico saliente de resolución de nombres debe estar restringido únicamente desde el servidor de DNS de la red interna hacia los servidores DNS de nivel superior en internet.
• Todos los sistemas dentro del entorno PCI DSS deben emplear el servidor DNS interno para su resolución de nombres.
• Solo se deben permitir las consultas al servidor DNS de las direcciones IP dentro del entorno. Proceder de igual manera con otras operaciones críticas (como transferencias de zonas).
• Las consultas al servidor DNS deben ser registradas (logs), para que puedan ser empleadas como elementos de análisis en una investigación si sucede un incidente de seguridad.
• Los cambios en los registros de resolución de nombres deberían ser monitorizados continuamente para detectar cambios no autorizados.
• Desplegar más de un servidor DNS interno para el balanceo de carga y la tolerancia a fallos. El DNS es particularmente vulnerable a los ataques de DoS. Evite conectar todos los servidores DNS al mismo segmento, switch o router, ya que esto crea un único punto de fallo innecesario.
• Cuando empleemos varios servidores DNS internos, deshabilitar las transferencias de zona o limitar las transferencias de zona a las direcciones IP de los servidores DNS internos.
Uso de funcionalidades seguras de resolución de nombres Con el fin de remplazar y/o complementar las funcionalidades tradicionales del protocolo de DNS, se recomienda emplear cualquiera de las siguientes alternativas y/o extensiones seguras:
Domain Name System Security Extensions (DNSSEC): DNSSEC es un conjunto de extensiones del servicio de DNS descritas en las RFC4033, RFC4034 y RFC4035, que proveen autenticación criptográfica y validación de integridad de los datos de DNS, incluyendo retrocompatibilidad con versiones anteriores. Mediante el uso de DNSSEC se puede minimizar el riesgo de DNS cache poisoning, ya que las respuestas de los servidores DNSSEC están firmadas digitalmente, con lo cual se puede detectar cualquier intento de manipulación de estos datos.
DNSCurve: DNSCurve emplea criptografía de curva elíptica para encriptar y autenticar los paquetes de DNS entre el recursor/resolver y el Authoritative Nameserver.
DNSCrypt: DNSCrypt permite la autenticación entre un cliente de DNS y un recursor/resolver empleando criptografía robusta.
Transaction SIGnature (TSIG): Descrita en la RFC2845, TSIG permite la autenticación de las actualizaciones de una base de datos de DNS.
Protección de tráfico DNS El tráfico de DNS tradicionalmente se envía en texto claro, sin ningún control para proteger su confidencialidad. Debido a esto, cualquier atacante podría tener acceso al tráfico de resolución de nombres, facilitando su captura y manipulación (man-in-the-middle).
Para evitar estos problemas, se recomienda hacer uso de las siguientes funcionalidades de seguridad para la protección del tráfico DNS:
DNS over TLS (DoT): DoT (RFC7858) agrega encriptación a los datagramas de UDP usados por DNS empleando Transport Layer Security (TLS). DoT usa el puerto 853.
DNS over DTLS (DoD): DoD (RFC8094) permite la encriptación de las consultas (queries) y las respuestas (responses) de DNS mediante el uso de Datagram Transport Layer Security (DTLS). DoD usa el puerto 853, al igual que DoT.
DNS over HTTPS (DoH): DoH (RFC8484) permite que las consultas y las respuestas de DNS se realicen empleando los protocolos HTTP y HTTP/2 en vez de hacerlo con UDP y encripta el tráfico usando TLS de la misma manera que se realiza con HTTPS. DoH usa el puerto 443.
Uso de software de DNS seguro Existen múltiples alternativas a nivel de software para implementar un servidor DNS, tanto comerciales como Open Source. No obstante, se recomienda que la solución elegida soporte las funcionalidades de seguridad descritas anteriormente.
Estos componentes deben tener asociado un estándar de configuración específico, de acuerdo con el requerimiento 2.2 de PCI DSS. Como referencia, se puede emplear el documento NIST Special Publication 800-81-2 - Secure Domain Name System (DNS) Deployment Guide.
Selección de un DNS de nivel superior aceptado por la industria Debido a que la arquitectura del servicio de DNS es jerárquica y recursiva, el servidor DNS de la red PCI DSS deberá conectarse con un servidor de nivel superior (generalmente a un servidor DNS resolver) en internet.
Al igual que con el servicio de sincronización de tiempo (NTP), los servidores externos que proporcionan el servicio deben ser reconocidos por la industria (industry-accepted) y soportar las funcionalidades de seguridad descritas anteriormente.
Algunos de estos servicios externos de resolución de nombres con prestaciones de seguridad y privacidad son:
• OpenNIC (https://www.opennic.org/)
• Cloudflare (https://www.cloudflare.com/dns/)
• OpenDNS (https://www.opendns.com/)
• DNSWatch (https://dns.watch/)
• Quad9 (https://www.quad9.net/)
Funcionalidades adicionales El uso de un servicio de DNS interno permite la implementación de controles adicionales tales como filtrado de contenido, bloqueando el tráfico a dominios no confiables.

Consideraciones para el registro de dominios vinculados a entornos PCI DSS

Otro de los grandes problemas no abordado por el estándar PCI DSS es la gestión de la seguridad de los registros de dominio vinculados con entornos PCI DSS realizados con proveedores de registro de nombres externos, sobre todo para servicios de comercio electrónico.

Como se ha descrito anteriormente, el DNS permite la vinculación de una dirección IP con un nombre de dominio (FQDN). Cuando un usuario (un individuo o una organización) quiere registrar un nombre de dominio bajo un TLD específico, debe contactar a una entidad autorizada denominada “registrador” (registrar). Este registrador recibe la petición de registro del usuario, valida que el dominio se encuentre disponible y, si está disponible, procede a adicionar este nuevo nombre a su base de datos de registros de DNS. A partir de ese momento, cualquier cambio que se requiera efectuar en el registro (renovación, transferencia o incluso edición de registros DNS y de zonas si estas tareas han sido delegadas en el registrador) deberá realizarse empleando las interfaces provistas por este proveedor.

Si se registra un nombre de dominio que apunta a una dirección IP de un activo dentro de un entorno de PCI DSS, automáticamente el registrador se convierte en un elemento crítico dentro de la infraestructura de la organización, ya que la responsabilidad de la operación y la administración de dicho nombre recae en esta entidad. Si un atacante compromete la red del registrador o accede de forma no autorizada a la interfaz de administración del dominio, el tráfico puede ser redireccionado hacia servidores maliciosos sin que el usuario final se percate de dicho cambio.

De acuerdo con el glosario del PCI SSC, un proveedor de servicios se define como “una entidad comercial que no es una marca de pago, directamente involucrada en el procesamiento, almacenamiento o transmisión de los datos del titular de la tarjeta en nombre de otra entidad. Esto también incluye a las empresas que prestan servicios que controlan o podrían afectar a la seguridad de los datos de los titulares de las tarjetas. Entre los ejemplos figuran los proveedores de servicios administrados que proporcionan cortafuegos administrados, IDS y otros servicios, así como los proveedores de hospedaje y otras entidades”.

Generalmente, una entidad registradora de dominios no se incluye dentro de los proveedores de servicio que afectan a un entorno PCI DSS – a pesar de que sus servicios pueden afectar la seguridad de los datos de los titulares de tarjetas – por lo que no existe ninguna obligación por parte de estas entidades para cumplir con el estándar o para agregar controles de seguridad adicionales para prevenir los riesgos asociados con la gestión de dominios.

En ese sentido, se recomienda seguir estas recomendaciones:

  • Usar una entidad registradora de dominios confiable.
  • Minimizar la información expuesta en la base de datos de Whois (información de los titulares de dominio) a través de servicios de registro privado.
  • Si está disponible, activar la autenticación multi-factor (MFA) en la interfaz de administración del dominio provista por la entidad registradora para minimizar accesos no autorizados.
  • Gestionar diferentes roles y permisos en los usuarios que pueden acceder a las interfaces de administración del DNS.
  • Activar el bloqueo de cambio de DNS (DNS change locking), que agrega controles adicionales si se realiza algún cambio en los nombres de dominio registrados. Por ejemplo, un empleado de la empresa de registro de dominios puede solicitar autorización por escrito o telefónica de una persona autorizada de la empresa para realizar cambios en el DNS, solicitar un número de identificación personal (PIN), un código OTP, etc.
  • Restringir el acceso a las interfaces de administración del dominio únicamente a direcciones IP autorizadas, ubicaciones físicas o dispositivos específicos.
  • Activar las notificaciones (por correo, SMS, etc.) cuando se realicen cambios en el DNS.
  • Configurar la renovación automática, para prevenir que un usuario malintencionado pueda adquirir el dominio cuando expire y redirigir el tráfico hacia servidores bajo su control.
  • Monitorizar periódicamente los registros de DNS (sobre todo CNAME) para detectar problemas de inactividad u obsolescencia que puedan dar paso a que un usuario malicioso pueda hacerse con el control de subdominios (subdomain takeover).

Conclusión

Una cadena es tan fuerte como el más débil de sus eslabones”. Esta frase la hemos escuchado múltiples veces aplicada al entorno de la ciberseguridad y aún no ha perdido su vigencia.

Un entorno que procesa, almacena y/o transmite datos de tarjetas de pago debe cumplir con los controles del estándar PCI DSS, que añade una capa de seguridad adicional para proteger dichos datos. No obstante, uno de los componentes de estos entornos que generalmente no se identifica ni se protege correctamente es el servicio de resolución de nombres o DNS. Debido a ello, la organización puede tener un “punto ciego” en su estrategia de seguridad y es indispensable proceder con el despliegue de acciones preventivas y correctivas para que esto no se convierta en un vector de riesgo.

El uso de una arquitectura segura, la implementación de funcionalidades adicionales de seguridad y la protección de los registros de DNS expuestos en internet, así como el uso de servicios de DNS provistos por entidades confiables hacen parte de esta estrategia de defensa de este “eslabón débil”. Todas estas recomendaciones deberían entrar a ser parte complementaria de los controles de PCI DSS en organizaciones afectadas por el cumplimiento con este estándar.

Autor: David Acosta

Asesor de Seguridad Calificado (QSA) para PCI DSS, P2PE, PIN, 3DS, TSP y PIN.
CISSP Instructor, CISA, CISM, CRISC, CHFI Trainer, CEH, OPST, BS25999 LA.