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 eliminar ButterCMS de nuestro sitio e iniciar una investigación exhaustiva sobre lo que sucedió. Potencialmente 1.660 sitios web y más de 5.800 dominios fueron impactados.
Nuestro objetivo es compartir los hallazgos de nuestra investigación para mostrar lo que puede suceder 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 en los 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 tuvo una actualización de WhoIs al mismo tiempo que comenzaron nuestros problemas. Una razón lógica para esto podría haber sido una renovación o un cambio en la propiedad del dominio. Lo último sería altamente preocupante.
Si el dominio fue "capturado" y había caído en manos maliciosas, podría haber representado un riesgo de seguridad grave, similar al incidente de Polyfill, donde un cambio de propiedad del dominio causó 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, causando redirecciones maliciosas y potencialmente otros ataques sigilosos que no fueron detectados debido a la subutilización del monitoreo de seguridad del lado del cliente.
Para este momento, deshabilitamos completamente la integración de ButterCMS para evitar que se sirvieran datos del dominio potencialmente comprometido. Deshabilitar el CMS elimina el riesgo de que se inyecte código malicioso en nuestro sitio.
Nos comunicamos a través de X (Twitter) para notificar al equipo de ButterCMS:
Estamos experimentando problemas de DNS con
, parece que su DNS fue completamente eliminado en varias redes diferentes.
Como no puedo acceder al sitio web, no tengo otra forma de contactar a su 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, lo que es importante, apuntaban a las mismas IPs que antes del tiempo de inactividad. Esto sugiere que el problema probablemente se debió a una configuración incorrecta o tiempo de inactividad con el proveedor de DNS utilizado para su dominio. Durante el tiempo de inactividad, no vimos registros presentes. Ni para el sitio ni para la API.
Una vez que confirmamos que el servicio había vuelto a la normalidad, revertimos nuestros cambios.
Finalmente nos comunicamos 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 comenzó a investigar. No podemos compartir el historial completo de mensajes, ya que después de solicitar un número de caso, respondieron que no tenían uno. Intercom debería tenerlos por defecto.
Revisamos la página de estado de ButterCMS, que hasta la fecha no muestra tiempo de inactividad. Esto inicialmente nos hizo creer que el problema estaba de nuestro lado o era más grande de lo que resultó ser.
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 fue reportado a finales de 2022, hace más de 1.5 años. Si bien esto ahora muestra la razón de la transferencia del dominio, no fuimos informados ni notificados antes de los cambios.
Hicimos un seguimiento y recibimos el siguiente mensaje:
Un problema de verificación podría haber sido el problema. Sabremos más en su declaración post-mortem que se publicará pronto.
En un correo electrónico de seguimiento final el 12 de septiembre, esta fue su respuesta:
Creemos que la comunicación sobre este tipo de cambios es vital. Cuando los cambios planificados salen mal, incluso ligeramente, pone a los clientes en un riesgo significativo. Un correo electrónico rápido para notificar a los usuarios es muy útil en este tipo de escenarios.
Estos cambios incluso podrían interferir con los requisitos del GDPR, ahora sabiendo que la propiedad del dominio cambió después de una adquisición. El GDPR no menciona específicamente las transferencias de dominio, pero se centra en la transferencia de control sobre los datos personales. Si el cambio de propiedad conduce a un nuevo controlador de datos que gestiona datos personales, los clientes (sujetos de datos) deberían ser informados. Esto cae bajo los principios de transparencia y equidad del GDPR (Artículos 13, 14).
Los clientes deben ser notificados sobre la identidad del nuevo controlador y cualquier cambio en cómo se procesarán sus datos. La notificación debe ocurrir dentro de un plazo razonable.
Esperamos para publicar esto durante algún tiempo para ver si podría llegar alguna comunicación antes del seminario web planificado. Hasta ahora, no hemos visto ninguna.
ACTUALIZACIÓN: Incluso después del seminario web, no hay grabación ni publicación de blog o declaración.
Más tarde intentamos buscar otras empresas comentando sobre este problema, pero no encontramos ninguna. Si bien no podemos conocer su número exacto de clientes, potencialmente 1.660 sitios web y más de 5.800 dominios adicionales fueron impactados:
El riesgo con terceros dinámicos
Esto es más serio que simplemente cambios de registros. Este patrón es exactamente lo que sucede cuando el dominio cambia de propiedad o se actualizan detalles importantes de WhoIs.
Aunque el problema ahora está resuelto, esta situación mostró una vulnerabilidad de seguridad potencial.
La lección más amplia de este incidente es el riesgo que tomas al depender de servicios de terceros que inyectan contenido dinámicamente en sitios web. Un problema que conocemos bien y contra el cual protegemos del lado del cliente.
Los dominios utilizados en integraciones pueden ser comprados por actores maliciosos y explotados para ataques. El contenido que inyectan es dinámico. Esto significa que el contenido puede cambiar según varios factores como el tiempo, 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 alerta para recordarnos monitorear las dependencias de terceros.
La forma en que se construye un sitio web afecta significativamente su vulnerabilidad a este tipo de problema. Idealmente, cualquier entrada debe ser debidamente 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, especialmente cuando no se aborda explícitamente en la documentación.
Si buscas "dangerouslySetInnerHTML", no hay una guía clara sobre cómo usar esta prop de manera segura. Sin una sanitización adecuada, se puede inyectar cualquier HTML válido, lo que crea una vulnerabilidad grave de XSS (Cross-Site Scripting).
Cuando se inyecta HTML en el cliente, toda la página web puede verse 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 un portal abierto para riesgos de seguridad.
Cómo se maneja esto del lado del cliente
Por supuesto, el riesgo de cambio de dominio no es nuevo para nosotros. Es un vector de ataque común en el mundo de la seguridad del lado del cliente. cside ya verifica el historial de registros DNS, información de WhoIs y metadatos.
Mientras el sitio web permanezca activo (y como resultado, nuestro proxy también) y ocurran cambios o anomalías, nuestro motor lo detecta. Y, después de verificar otras posibles actividades maliciosas, alertará y/o bloqueará el dominio, el script y, por lo tanto, un posible ataque.
Puedes proteger tu sitio rápidamente y de forma gratuita usando cside.
