TL;DR: borrado de DNS del CMS no reportado con señal de alarma de transferencia de registrador en WHOIS
- "Problema menor de DNS" o toma de dominio: A los proveedores externos les encanta la frase "problema menor de DNS", pero un borrado total de DNS coincidiendo con una actualización de registrador en WHOIS es indistinguible, desde el client-side, de una toma de dominio al estilo Polyfill, y solo uno de esos dos escenarios termina con notificación al cliente.
- Lo retiramos y lo rastreamos: cside retiró ButterCMS de nuestro propio blog el 9 de septiembre a las 08:00 PT, cuando el DNS dejó de resolver junto a una actualización de WHOIS, y nuestro motor ya rastrea el historial de registros DNS, los metadatos de WHOIS y la deriva de comportamiento de cada dominio de terceros en aproximadamente 1.660 sitios potencialmente afectados y 5.800 dominios adicionales.
- Sin post-mortem, sin confianza: Si el proveedor de tu CMS no puede publicar una entrada en su página de estado, un número de caso o un post-mortem tras una caída que podría confundirse con un secuestro de dominio, la cuestión no es si confiar en la solución, sino si la verificación continua de cada tercero dinámico es un requisito básico o algo meramente deseable.
¿Poco tiempo? Consulta el bloqueo de Magecart y skimmers en el navegador de cside. Cubre todo lo de abajo en un solo despliegue.
ButterCMS es una herramienta popular utilizada para gestionar contenido de blogs. A principios de esta semana, notamos un incidente de seguridad potencialmente grave que llevó al equipo a retirar ButterCMS de nuestro sitio, e iniciamos una investigación exhaustiva sobre lo que había sucedido. Potencialmente se vieron afectados 1.660 sitios web y más de 5.800 dominios.
Nuestro objetivo es compartir los hallazgos de nuestra investigación para mostrar lo que puede pasar cuando confías en terceros dinámicos sin verificación continua.
El incidente de ButterCMS
Observamos que el incidente comenzó a las 08:00 (PT) del 9 de septiembre, cuando notamos un aumento significativo de errores porque el DNS no lograba resolver el nombre de host. Esto resultó en una interrupción del blog en nuestro sitio web.
Poco después, notamos que el sitio de ButterCMS estaba caído porque no se estaban sirviendo registros DNS.
Cuando profundizamos, notamos que el dominio de ButterCMS había tenido una actualización de WhoIs al mismo tiempo que empezaron nuestros problemas. Una razón lógica para esto podría haber sido una renovación o un cambio en la propiedad del dominio. Esto último sería muy preocupante.
Si el dominio hubiera sido "cazado" (sniped) y hubiera caído en manos maliciosas, podría haber supuesto un riesgo de seguridad grave, similar al incidente de Polyfill, donde un cambio de propiedad del dominio provocó un importante ataque a la cadena de suministro del navegador en casi 500.000 sitios web. Esto resultó en la inyección de código malicioso en los navegadores de millones de visitantes, provocando redirecciones maliciosas y posiblemente otros ataques sigilosos que no se detectaron debido a la escasa utilización de la monitorización de seguridad del lado del cliente.
Llegados a este punto, deshabilitamos por completo la integración de ButterCMS para evitar que se sirvieran datos desde el dominio potencialmente comprometido. Deshabilitar el CMS elimina el riesgo de que se inyecte código malicioso en nuestro sitio.
Nos pusimos en contacto vía X (Twitter) para avisar al equipo de ButterCMS:
Estamos teniendo problemas de DNS con
, parece que vuestro DNS se ha borrado por completo en varias redes distintas.
Como no puedo acceder al sitio web, no tengo otra forma de contactar con vuestro equipo de soporte.- cody (@devlooskie)
No respondieron a nuestro mensaje.
A las 08:30, observamos que los registros DNS de ButterCMS se estaban restaurando y, algo importante, apuntaban a las mismas IPs que antes de la caída. Esto sugiere que el problema probablemente se debió a una mala configuración o a una caída del proveedor de DNS utilizado para su dominio. Durante la interrupción, no vimos ningún registro presente. Ni para el sitio, ni para la API.
Una vez confirmamos que el servicio había vuelto a la normalidad, revertimos nuestros cambios.
Finalmente contactamos con el equipo de ButterCMS a través de su servicio de chat:
En el mensaje completo, la operadora de soporte afirmó que su equipo no estaba al tanto del problema, pero que habían comenzado a investigar. No podemos compartir el historial completo de mensajes porque, tras pedir un número de caso, respondieron que no tenían ninguno. Intercom debería asignarlos por defecto.
Revisamos la página de estado de ButterCMS, que hasta la fecha no muestra ninguna caída. Esto nos hizo pensar inicialmente que el problema era cosa nuestra, o mucho mayor de lo que terminó siendo.
La correspondencia fallida con ButterCMS
Después de todo esto, los contactamos por correo electrónico. Esta fue su respuesta:
Mencionan una adquisición reciente de ButterCMS por parte de Tiugo Technologies. Sin embargo, esto se reportó a finales de 2022, hace más de 1,5 años. Aunque esto ahora explica el motivo de la transferencia del dominio, no fuimos informados ni notificados antes de los cambios.
Insistimos y recibimos el siguiente mensaje:
Un problema de verificación podría haber sido la causa. Sabremos más en su declaración post-mortem, que publicarán próximamente.
En un último correo de seguimiento el 12 de septiembre, esta fue su respuesta:
Creemos que la comunicación sobre este tipo de cambios es fundamental. Cuando los cambios planificados salen mal, incluso ligeramente, ponen a los clientes en un riesgo considerable. Un correo rápido para avisar a los usuarios ayuda muchísimo en este tipo de escenarios.
Estos cambios podrían incluso interferir con los requisitos del RGPD, ahora que sabemos que la propiedad del dominio cambió tras una adquisición. El RGPD no menciona específicamente las transferencias de dominio, pero se centra en la transferencia del control sobre los datos personales. Si el cambio de propiedad implica un nuevo responsable del tratamiento de datos personales, habría que informar a los clientes (los interesados). Esto entra dentro de los principios de transparencia y lealtad del RGPD (artículos 13 y 14).
Hay que notificar a los clientes la identidad del nuevo responsable del tratamiento y cualquier cambio en la forma en que se procesarán sus datos. La notificación debe producirse en un plazo razonable.
Esperamos algún tiempo antes de publicar esto, por si llegaba alguna comunicación antes del webinar planeado. Hasta ahora no hemos visto ninguna.
ACTUALIZACIÓN: Incluso después del webinar, no hay grabación ni entrada de blog ni comunicado alguno.
Más tarde intentamos buscar si otras empresas habían comentado este problema, pero no encontramos ninguna. Aunque no podemos conocer su número exacto de clientes, potencialmente se vieron afectados 1.660 sitios web y más de 5.800 dominios adicionales:
El riesgo de los terceros dinámicos
Esto es más grave que un simple cambio de registros. Este patrón es exactamente lo que ocurre cuando el dominio cambia de propietario o se actualizan datos importantes de WhoIs.
Aunque el problema ya está resuelto, esta situación puso de manifiesto una posible vulnerabilidad de seguridad.
La lección más amplia de este incidente es el riesgo que se asume al depender de servicios de terceros que inyectan contenido de forma dinámica en los sitios web. Un problema que conocemos bien y frente al cual protegemos desde el client-side.
Los dominios utilizados en integraciones pueden ser comprados por actores maliciosos y explotados para llevar a cabo ataques. El contenido que inyectan es dinámico, lo que significa que puede cambiar en función de factores como la hora, la región y otros datos específicos del usuario, lo que facilita que los actores maliciosos eludan la detección.
En este caso, la renovación del dominio de ButterCMS y la falta de claridad en torno a la actualización de WhoIs levantaron una señal de alarma que nos recordó la importancia de vigilar las dependencias de terceros.
La forma en que se construye un sitio web afecta significativamente a su vulnerabilidad frente a este tipo de problema. Lo ideal es que cualquier entrada esté correctamente sanitizada. La entrada del usuario debe limpiarse para evitar que se inyecte código malicioso en el sitio.
Muchos desarrolladores no implementan una sanitización adecuada, sobre todo cuando la documentación no lo aborda de forma explícita.
Si buscas "dangerouslySetInnerHTML", no encontrarás una guía clara sobre cómo usar esta prop de forma segura. Sin una sanitización adecuada, se puede inyectar cualquier HTML válido, lo que crea una grave vulnerabilidad XSS (Cross-Site Scripting).
Cuando se inyecta HTML en el cliente, toda la página web puede quedar comprometida a través de inyecciones de scripts. Sin salvaguardas, el HTML inyectado podría ejecutar scripts dañinos o redirigir a los usuarios a sitios maliciosos, convirtiendo efectivamente la función en una puerta abierta a riesgos de seguridad.
Cómo se gestiona esto del lado del cliente
Por supuesto, el riesgo de cambio de dominio no es nada nuevo para nosotros. Es un vector de ataque habitual en el mundo de la seguridad del lado del cliente. cside ya comprueba el historial de registros DNS, la información de WhoIs y los metadatos.
Mientras el sitio web siga activo (y, en consecuencia, cside también) y se produzcan cambios o anomalías, nuestro motor lo detecta. Y, tras comprobar otras posibles actividades maliciosas, alertará y/o bloqueará el dominio, el script y, por tanto, un posible ataque.
Puedes proteger tu sitio de forma rápida y gratuita usando cside.
