Un error tipográfico en el DNS de MasterCard pasó desapercibido durante casi 5 años

 (krebsonsecurity.com)
1 puntos por GN⁺ 2025-01-23 | 1 comentarios | Compartir por WhatsApp
  • MasterCard configuró mal uno de los nombres de servidor DNS de Akamai que dirigen parte del tráfico de mastercard.com, usando akam.ne en lugar de akam.net, y ese error tipográfico permaneció durante casi cinco años, del 30 de junio de 2020 al 14 de enero de 2025
  • El investigador de seguridad Philippe Caturegli vio que akam.ne, bajo el dominio de nivel superior de Níger, no estaba registrado, y lo aseguró por 300 dólares y cerca de 3 meses para bloquear un posible abuso
  • Al activar un servidor DNS en akam.ne, empezaron a llegar cientos de miles de solicitudes DNS al día desde todo el mundo, y entre las organizaciones con el mismo error tipográfico, MasterCard fue el caso más grande
  • Si este dominio se hubiera explotado, podría haber permitido recibir correos mal dirigidos, obtener certificados SSL/TLS para sitios web afectados y recibir manualmente algunas credenciales de Windows
  • MasterCard dijo que “no hubo riesgo para sus sistemas” y corrigió el error, pero después surgió una polémica sobre la forma de divulgación cuando se pidió eliminar una publicación de LinkedIn a través de Bugcrowd

Un error tipográfico en DNS que quedó sin atender casi 5 años

  • MasterCard usa cinco servidores DNS compartidos de Akamai para dirigir parte del tráfico de la red de mastercard.com
  • Desde el 30 de junio de 2020 hasta el 14 de enero de 2025, uno de ellos estuvo configurado con un nombre incorrecto
    • El nombre correcto del servidor debía terminar en akam.net
    • La configuración problemática apuntaba a akam.ne
  • akam.ne es un dominio dentro del ámbito de administración del dominio de nivel superior de país de Níger, en África occidental

Un investigador aseguró primero el dominio

  • Philippe Caturegli, fundador de la consultora de seguridad Seralys, descubrió este error tipográfico
  • Caturegli supuso que akam.ne todavía no estaba registrado y consiguió el dominio a través del registro de Níger
    • El costo fue de 300 dólares
    • El registro tardó casi 3 meses
  • Al activar el servidor DNS, empezaron a llegar cada día cientos de miles de solicitudes DNS desde todo el mundo
  • MasterCard no fue la única organización con el mismo error, pero por el volumen de solicitudes recibidas fue la más grande

Riesgos que podía generar el dominio con el error tipográfico

  • Si Caturegli hubiera activado un servidor de correo en akam.ne, podría haber recibido correos mal dirigidos hacia mastercard.com u otros dominios afectados
  • Si hubiera abusado del acceso, también podría haber obtenido certificados SSL/TLS para recibir y reenviar tráfico de los sitios web afectados
  • También existía la posibilidad de recibir manualmente credenciales de autenticación de Microsoft Windows desde computadoras de empleados
  • Caturegli no intentó realizar estas acciones y avisó a MasterCard que podía transferirle el dominio
    • En la notificación también incluyó como referencia al autor de Krebs on Security

La respuesta de MasterCard y Bugcrowd

  • Horas después, MasterCard reconoció el error, pero afirmó que no hubo un riesgo real para la seguridad operativa
    • “No hubo riesgo para los sistemas”
    • “Este error tipográfico fue corregido”
  • Después, Caturegli recibió un mensaje a través de Bugcrowd
    • El mensaje sostenía que haber publicado en LinkedIn la adquisición de akam.ne no se ajustaba a prácticas éticas de seguridad
    • También indicaba que MasterCard había pedido eliminar esa publicación
  • Caturegli respondió que nunca había reportado el caso a través del programa de Bugcrowd y que informó el problema directamente a MasterCard
  • También dijo que, antes de hacerlo público, registró el dominio afectado para impedir abusos y asumió él mismo ese costo

Cómo el caché DNS podía ampliar el impacto

  • En general, las organizaciones usan al menos 2 servidores DNS autoritativos, pero las que manejan mucho tráfico utilizan más dominios de servidores DNS para balancear la carga
  • Como MasterCard usa 5 servidores DNS, podría parecer que un atacante que controlara solo uno de ellos vería apenas alrededor de una quinta parte de todas las solicitudes DNS
  • En la práctica, los usuarios de internet dependen de resolvedores DNS públicos como Cloudflare o Google, por lo que el impacto podría ser mayor
    • Basta con que un resolvedor consulte al servidor de nombres equivocado y almacene el resultado en caché
    • Si se configura un TTL largo en los registros DNS, las instrucciones erróneas podrían propagarse a través de grandes proveedores de nube
  • Caturegli considera que, con TTL largos, el alcance del redireccionamiento de tráfico podría ser mucho mayor que simplemente una quinta parte

El subdominio afectado y rastros de registros anteriores

  • En las capturas publicadas por Caturegli, el servidor DNS mal configurado estaba relacionado con el subdominio az.mastercard.com de MasterCard
  • No está claro exactamente cómo se usaba este subdominio
  • Por su convención de nombres, parece un dominio relacionado con servidores de producción en la nube de Microsoft Azure, y Caturegli señaló que esos dominios se resuelven a direcciones de internet de Microsoft
  • akam.ne ya había sido registrado en el pasado
    • En diciembre de 2016 lo registró un usuario que usaba el correo um-i-delo@yandex.ru
    • Yandex muestra que esa cuenta pertenece a “Ivan I.” en Moscú
    • Según los registros DNS históricos pasivos de DomainTools.com, entre 2016 y 2018 estuvo conectado a un servidor de internet en Alemania y expiró en 2018
  • Un ex empleado de Cloudflare enlazó en los comentarios de la publicación de LinkedIn de Caturegli un reporte sobre un caso similar
    • Era un caso de dominio con error tipográfico en el que algunas organizaciones podrían haber escrito mal el servidor DNS de AWS awsdns-06.net como awsdns-06.ne
    • Según DomainTools, ese dominio con error también fue registrado por un usuario de Yandex y alojado en el mismo ISP alemán, Team Internet

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-01-23
Opiniones en Hacker News

  • Los nameservers que pueden registrarse públicamente, como en este caso, son solo un subtipo relativamente raro del problema de DNS colgante; lo más común es que un dominio esté mapeado directamente a una dirección IP de un proveedor de nube que un atacante puede obtener.
    Los servicios en la nube tienen un alcance amplio y muchas veces carecen de visibilidad global, así que es muy probable que las empresas que usan la nube tengan una vulnerabilidad de este tipo en algún subdominio.
    Los programas de bug bounty suelen excluir de forma general la “toma de control de subdominios”, pero cuando se descubre es fácil de explotar, y también hay datos internos y públicos en los que se filtró información sensible por este tipo de errores de configuración.
    El entorno actual de divulgación de vulnerabilidades hace demasiado fácil que las empresas eviten reconocer vulnerabilidades reales, y deja a los investigadores de buena fe en una posición en la que, por restricciones éticas y legales, les resulta difícil presentar el nivel de evidencia que exige el proveedor.
    También se subestima el riesgo de que con estas vulnerabilidades sea sencillo emitir certificados TLS.
    [1] https://dl.acm.org/doi/pdf/10.1145/2976749.2978387
    [2] https://escholarship.org/content/qt9r59r676/qt9r59r676.pdf
    [3] https://pauley.me/post/2022/cloud-squatting/
    [4] https://arxiv.org/pdf/2204.05122

    • Más allá de las IP, existe una enorme categoría de problemas con “registros DNS que apuntan a recursos compartidos en la nube que la organización ya no controla”, y cuanto más grande es la empresa, más extendido está.
      Por ejemplo, CNAME que apuntan a buckets de S3 liberados, instancias de Azure Website/WebApp, registros A que apuntan a IP no elásticas, nameservers de Route53 que ya no pertenecen a la cuenta AWS de la organización, cuentas de Heroku/Shopify/GitHub Pages eliminadas o desactivadas, o registros MX que apuntan a dominios de proveedores de email transaccional quebrados.
      La causa es que, con la descentralización de TI, gente que no sabe mucho crea infraestructura, luego al desmantelarla se olvida del DNS; además hay muchas subsidiarias, marcas y organizaciones regionales, lo que dificulta descubrir y hacer cumplir políticas; hay muchos sitios web y apps por país; y se acumula el uso de proveedores externos sin avisar al equipo de seguridad.
      Trabajo como Field CTO en una empresa israelí de ciberseguridad de este rubro, y ayer mismo hablé con una gran empresa de componentes de computadora sobre unas 12 páginas de apuestas de Indonesia que “operan” usando sus dominios, PageRank y enlaces; conversaciones así se repiten todas las semanas.
    • Que los bug bounty consideren inválidas todas las “tomas de control de subdominios” es una respuesta demasiado burda; deberían diferenciar según qué tan fácil es apropiarse del dominio.
      “Si de algún modo tomas control de google.com, puedes comprometer a los usuarios de Google” no es una vulnerabilidad de seguridad válida, pero si una toma de control de un dominio no registrado o vencido como aquí puede llevar a un compromiso, debería considerarse una vulnerabilidad válida.
    • La divulgación en bug bounty podría ser más efectiva si también se reportara automáticamente a organismos gubernamentales como la FCC y se pusiera en copia el correo de la empresa.
      Si la empresa quiere descartar el reporte, tendría que presentar evidencia clara, y si se demuestra un abuso derivado de ese reporte o si la empresa hace un cambio de modo que los pasos de reproducción del reporte ya no funcionen, eso podría dar lugar al pago de la recompensa o a una multa.
    • En un exchange de criptomonedas gestionaban una allowlist de direcciones IP que podían acceder a load balancers más rápidos, sin controles a nivel de aplicación.
      Asignaban una cantidad enorme de IP en la nube y repetían el proceso hasta encontrar IP antiguas, obteniendo mucha más capacidad que la original y enviando solicitudes con límites de velocidad más altos.
      Creo que hoy ya no funcionaría, y ahora es un método conocido por todos.

  • La parte de Bugcrowd en esta historia es inesperada.
    La captura del correo parece venir del “Platform Behavior Standards Team”; si es así, o Bugcrowd interpretó sus estándares de plataforma de forma demasiado amplia para intentar regular comportamientos fuera de la plataforma, o Mastercard se hizo pasar por un empleado oficial de Bugcrowd.
    Ninguna de las dos opciones resulta muy aceptable.
    [1] https://www.bugcrowd.com/resources/hacker-resources/platform...

    • Hay una interpretación de que las plataformas de bug bounty existen más para capturar y bloquear la divulgación responsable que para fomentarla.
      Alguien que suele hacer ese argumento probablemente podría explicarlo mejor.
    • La redacción también es pésima.
      Está escrita como si ya hubieran determinado que la persona hizo algo malo, y las únicas opciones son obedecer o pedir más explicación sobre por qué estuvo mal.
      No hay oportunidad de explicar que uno no hizo nada malo.
    • En mi experiencia, BugCrowd hace todo lo posible por retrasar y empantanar que los reportes lleguen a la empresa real.
      Desde el punto de vista de la empresa, eso reduce los pagos de recompensas y los costos de revisión interna, y además le da una negación plausible legalmente atractiva.
    • Seguramente hay empleados de Bugcrowd por aquí, así que quizá puedan explicar ese correo.

  • Una respuesta del tipo “no hubo una amenaza real” probablemente haga que la próxima vez los investigadores de seguridad intenten penetrar más profundamente para reunir más evidencia de impacto en esta u otras empresas.
    Si quieren que el vocero de la empresa pueda decir “no hay problema”, deberían compensar lo suficiente al investigador como para que acepte que se minimice el impacto.
    Aunque el investigador ya parece haber actuado correctamente, lo presionaron para acallar la noticia; me pregunto si la compañía de tarjetas de crédito tenía algún motivo para hacerlo, si fue una mala interpretación del trabajo por parte de relaciones públicas, o si la persona finalmente responsable por el error de seguridad de la información usó recursos de la empresa para evitar quedar en vergüenza durante su gestión.

    • Hay un motivo.
      Quieren hacer que los investigadores de seguridad tengan miedo de publicar sus hallazgos.

  • Hace algunos años, en Ucrania, todas o la mayoría de las transacciones en línea debían verificarse con un servicio llamado masterpass, y parecía algo como el 3DS de Mastercard.
    Pero, como suele pasar en sitios corporativos, el certificado SSL expiró, y todas o la mayoría de las transacciones en línea con ciertos tipos de tarjetas MasterCard quedaron completamente bloqueadas en ese momento.
    Mastercard no renovó el certificado durante más de un año, y por más que yo, como cliente, o el departamento de TI del banco intentáramos contactarlos, no sirvió de nada; más tarde cerraron el servicio discretamente.
    Al revisarlo, el servicio estaba escrito sobre tecnologías de Microsoft (IIS), la cadena de certificados era anormalmente larga, con certificados intermedios de los que nunca había oído hablar, y estaba alojado en un país del tercer mundo bastante lejos de Ucrania.

    • masterpass es la versión de Mastercard de 3DS y se usa globalmente cuando una transacción parece sospechosa.
      Desde la perspectiva de Mastercard, parece que las transacciones de ese país se consideraban sospechosas por defecto, aunque todas fueran entre entidades locales.
      En EE. UU. nunca lo vi vencido, y no sé cómo manejan el tráfico por país, pero suena a que el tráfico se enrutó a otro lugar y no a Mastercard.

  • Me inquieta que akam.ne haya sido registrado en 2016 a nombre de “Ivan I.”, en Moscú, usando correo de Yandex, y que entre 2016 y 2018 haya estado apuntando a servidores en Alemania antes de expirar.
    Es especialmente sospechoso que un dominio typo similar, aparentemente dirigido a organizaciones que escribían mal el servidor DNS de AWS awsdns-06.net como awsdns-06.ne, también estuviera registrado con una cuenta de Yandex y alojado en el mismo ISP alemán, Team Internet (AS61969).

    • “Ivan I” probablemente alude al nombre falso ruso común Ivan Ivanov, equivalente a “John Smith” en el mundo angloparlante.

  • “Si se hubiera abusado del acceso, se podrían haber obtenido certificados SSL/TLS capaces de recibir y retransmitir el tráfico de los sitios web afectados” y “nuestros sistemas no estuvieron en riesgo” son dos afirmaciones de las cuales una tiene que ser falsa.
    Ambas partes tienen incentivos para mentir o exagerar.

    • Una parte tiene incentivos de miles de millones de dólares para mentir o exagerar, y la otra se pasa el día pensando en los peores escenarios de atacantes sofisticados.
      Si habláramos de un servidor de CS:GO, el peor ataque de un atacante sofisticado quizá sería una exageración, pero cuando hablamos de una de las mayores procesadoras de pagos del mundo, no lo es.
    • Si sabes aunque sea un poco cómo se emiten los certificados, queda claro que el investigador tiene razón y que MasterCard está diciendo tonterías.
      Con investigar 10 minutos se llega a la misma conclusión.
    • Si no hubo impacto, bastaría con permitir que publique la lista completa de consultas DNS que capturó.
      La razón para no hacerlo es que esa lista daría pistas de infraestructura a actores maliciosos.
      MasterCard está mintiendo, o es ignorante e incompetente.
    • La cuestión central depende mucho de qué es realmente az.mastercard.com y qué hace.
      La idea de recibir correos dirigidos a x@mastercard.com no parece correcta; esto es solo un subdominio cuyo propósito no está claro.
      TLS probablemente sí sería posible, pero el riesgo depende de qué sea ese dominio y no parece que afecte directamente a los usuarios que visitan mastercard.com.
    • Si hablamos de certificados SSL/TLS, lo primero que se me viene a la mente son los proveedores de certificados basados en ACME.
      Basta con tener control del DNS del dominio, y se puede hacer mediante registros TXT o enviando solicitudes a un servidor HTTP bajo tu control.

  • Está claro que fue un gran error de Mastercard, pero también parece un error permitir que existan dominios que difieren en una sola letra de un dominio de nivel superior original.
    Por ejemplo, casos como .com y .co, o .net y .ne; es una estructura que se presta a problemas.
    Si esos dominios no existieran, no se podrían registrar y las solicitudes DNS mal escritas simplemente no irían a ninguna parte.

    • No necesariamente.
      Los errores tipográficos pueden ocurrir no solo en el dominio de nivel superior, sino en cualquier parte del nombre, y aun sin typos se puede obtener tráfico de distintos errores de computadora mediante bitsquatting, registrando dominios que difieren en 1 bit del nombre de sitios populares.
      Hay incluso papers con ejemplos.
      [1] https://en.wikipedia.org/wiki/Bitsquatting
      [2] https://www.securitee.org/files/bitsquatting_www2013.pdf
    • Esperaría que una gran empresa manejara este problema con Markmonitor.
      Básicamente consiste en registrar, en la medida de lo posible, dominios typo con distancia de edición 1.
      Según Wikipedia, Akamai es uno de los clientes de Markmonitor, así que sorprende que este dominio no ya estuviera registrado.
    • La cuestión es qué piensan hacer con los códigos ISO 3166-2 de Níger y Colombia.
    • No veo en qué se diferencia de que exista un número de teléfono que solo difiere en un dígito de un número telefónico sensible.
    • Los dominios de nivel superior ISO 3166-1 alpha-2 son claramente útiles, pero por las características del espacio de direcciones generan muchos typos de una sola letra.
      Los dominios que no son códigos de país también pueden coincidir con una versión de un dominio de nivel superior de código de país al que le falta una letra, así que no hay gran diferencia.
      Aun así, una buena herramienta de revisión de DNS debería detectar este tipo de mala configuración.
      Se manifiesta como que uno de los nameservers registrados no resuelve, o que los nameservers no devuelven el mismo número de serie de zona o la misma respuesta real.
      En .is, para registrar un dominio había que proporcionar 2 nameservers que funcionaran correctamente, pero .com ya no es tan estricto.

  • Ese nombre de dominio debió haberse transferido a akamai.
    También están llegando otras solicitudes a la misma dirección, y akamai debería manejarlo de forma responsable.

  • “Nos investigamos a nosotros mismos y no encontramos culpa” es la respuesta típica.
    Mastercard es una empresa pública de miles de millones de dólares, con al menos 3.400 millones de tarjetas de marca en todo el mundo, y procesó 44.300 millones de transacciones globales de crédito, débito y efectivo en el tercer trimestre de 2024.
    Admitir errores puede perjudicar en el corto plazo en el mercado, pero una cultura de negación arruina la cultura de la empresa.
    No es distinto de ClownStrike, y ya es hora de que llegue el caos a las redes depredadoras y parasitarias de crédito y débito.

  • Decir algo como “el error tipográfico ya fue corregido y no hubo riesgo para el sistema” siempre suena igual, y este tipo de comunicados de verdad enfurece

    • Su cálculo seguramente es este:
      si reconocen el problema, podrían perder millones de dólares en valor bursátil; si lo niegan, solo unos cuantos geeks van a seguir quejándose un poco más
      Sin evidencia de una intrusión, es difícil obligarlos a hacer algo; y si hay evidencia de una intrusión, terminan en la cárcel
    • Lo que en realidad significa se acerca más a: “hablamos con alguien de TI que no tenía idea de nada, que tenía un incentivo personal para no encontrar la exposición, y que no pudo imaginar una forma de explotarla en 15 segundos”
      Alguien que sabe del tema rara vez se siente lo suficientemente seguro como para afirmar tajantemente que algo no puede ser explotado