A principios de diciembre de 2022, Rackspace publicó este aviso para sus clientes:
El viernes 2 de diciembre de 2022, nos enteramos de un problema que afectaba a nuestro entorno de Hosted Exchange. Apagamos y desconectamos proactivamente el entorno de Hosted Exchange mientras evaluamos para comprender el alcance y la gravedad del impacto. Después de un análisis más detallado, hemos determinado que se trata de un incidente de seguridad.
Este aviso puede haberlo sorprendido por varias razones. Una es que es posible que no sepa que algunas empresas aún ofrecen servicios de Exchange alojados. Otra es que es posible que no conozca Rackspace, que ha crecido durante dos décadas hasta convertirse en una empresa de alojamiento que cotiza en la bolsa de US€3.000 millones al año. Una tercera es descubrir que los atacantes pueden comprometer una empresa tan grande. Sin embargo, por sorprendente que sea, todas estas cosas son ciertas, y ahora estamos lidiando con las consecuencias.
¿Qué sucedió?
Puede ser difícil desentrañar incidentes de seguridad como este, pero, para su crédito, Rackspace hizo prácticamente todo bien: hizo público el incidente, contrató a una empresa de seguridad muy conocida (CrowdStrike) para que los ayudara a limpiar y luego publicó una autopsia discutiendo lo sucedido. Esto es lo que sabemos según esa autopsia y los comentarios de CrowdStrike.
El análisis de CrowdStrike muestra que estos atacantes (parte de un grupo de ransomware conocido como Play) usaron un exploit de día cero previamente desconocido para penetrar el entorno de Exchange alojado en Rackspace. Este exploit está relacionado con el exploit ProxyNotShell, que Microsoft reconoció por primera vez en septiembre de 2022. Como mitigación inicial, Microsoft recomendó agregar una regla de reescritura para que IIS elimine las solicitudes de conexión que intentan usar el exploit. En la actualización de seguridad de Exchange del 8 de noviembre de 2022 (KB5019758), Microsoft corrigió las vulnerabilidades subyacentes. ¡Observe mi uso del plural! Se abordaron dos problemas en ese parche: CVE-2022-41040 es la capacidad de forzar una solicitud del lado del servidor contra el punto final de detección automática, y CVE-2022-41082 es una vulnerabilidad remota de PowerShell. Los ataques de ProxyNotShell requerían que el atacante tuviera éxito en la explotación de ambas vulnerabilidades. Agregar la regla de reescritura bloqueó el exploit 41040 y detuvo un ataque. O eso parecía.
Cuando lanzaron el parche, Microsoft actualizó su guía para decir lo siguiente:
Recomendamos que los clientes protejan sus organizaciones aplicando las actualizaciones de inmediato a los sistemas afectados. Ya no se recomiendan las opciones descritas en la sección Mitigaciones. Para obtener más información, consulte el blog del equipo de Exchange.
Sin embargo, en un desarrollo que probablemente no sorprenderá a muchos de ustedes dada la baja aceptación de los parches anteriores… Rackspace no instaló el parche. El análisis de CrowdStrike parece indicar que Rackspace no parchó porque Microsoft no dijo explícitamente que CVE-2022-41082 era remotamente explotable. Eso puede haberlos llevado a creer que la regla de mitigación, recomendada originalmente en septiembre, era lo suficientemente buena como para obviar la necesidad de aplicar el parche de noviembre. Esta resultó ser una muy mala decisión porque los atacantes también podrían explotar el problema remoto de PowerShell (CVE-2022-41082) al atacar OWA con una solicitud del lado del servidor falsificada. Eso es lo que hicieron los atacantes de Play.
Debido a que Rackspace no parcheó, fueron incendiados. Archiva ese hecho para más tarde.
El impacto en los clientes
El incidente se convirtió en un gran lío para todos los involucrados. El precio de las acciones de Rackspace recibió una gran paliza, los medios de comunicación locales que antes los apoyaban se volvieron contra ellos y los clientes los ridiculizaron. El impacto para la mayoría de los clientes, según la autopsia de Rackspace, fue que no tuvieron acceso a su correo electrónico desde aproximadamente el 2 de diciembre hasta finales de diciembre, dependiendo de cuándo se restauraron los datos de cada cliente. En el camino, Rackspace ayudó a algunos de sus clientes a cambiar sus buzones de correo a Microsoft 365, pero los resultados generales son bastante sombríos. “Más de la mitad de los clientes afectados tienen algunos o todos sus datos disponibles”, dijo Rackspace, pero esos datos se limitan a los correos electrónicos que llegaron antes del 2 de diciembre.
Junto con la interrupción, un total de 27 clientes (de aproximadamente 30 000 clientes de Exchange alojados) tenían archivos PST que contenían datos de correo robados por los atacantes. La razón por la que los atacantes persiguieron los archivos PST no está clara, pero es probable que se deba a que los archivos PST son portátiles y de fácil acceso con cualquier cliente de Outlook. El infame hackeo de correo electrónico de Sony Pictures (2014) también dio como resultado que los atacantes copiaran una gran cantidad de archivos PST que contenían información confidencial que luego llegó a la vista del público. Los PST son inseguros. Llano y simple.
Rackspace no ha dicho públicamente qué clientes específicos se vieron afectados, si pertenecen a categorías o verticales específicas, ni nada sobre ese aspecto del ataque. Esto probablemente sea inteligente, considerando la cantidad de demandas que actualmente se les presentan.
Avanzando
El impacto a largo plazo de este incidente es interesante. Primero, Rackspace gastó alrededor de €30 millones para limpiar. Eso es dinero real, incluso para una empresa de € 3 mil millones. En segundo lugar, están saliendo del negocio de Exchange hospedado. Eso deja a Intermedia y algunas empresas más pequeñas como los últimos proveedores de Exchange alojados que quedan en los EE. UU., con un puñado de hosters medianos que quedan en el resto del mundo. Sin embargo, es difícil ver cómo este fiasco es una buena noticia para ellos, ya que todo el lío subraya el punto de Microsoft de que sus inversiones en Exchange Online no pueden ser igualadas por organizaciones que alojan sus propios entornos.
En tercer lugar, Rackspace ofrece pagar a Microsoft para migrar a los clientes a Microsoft 365, un costo no insignificante para ellos. Puede que eso no sea suficiente para convencer a los clientes de que se queden con ellos, pero significa que esa línea de negocio y sus ingresos asociados se han ido. Es posible que recuperen algunos ingresos de la venta de licencias de Microsoft 365, pero una vez que los clientes están en Microsoft 365, es trivial para ellos cambiar a otro proveedor de servicios administrados, y espero que muchos de ellos lo hagan.
¿Lecciones aprendidas?
Rackspace obviamente tomó la decisión estratégica de evitar que se repitiera este problema y se deshizo del Exchange alojado. ¿Qué podemos aprender los demás? Bueno, podemos comenzar con una lección que demasiadas personas parecen no haber internalizado aún: aplique parches a sus servidores de Exchange. Tal vez gritarlo unas cuantas veces más resulte en algunas mejoras de seguridad incrementales. La lección más grande es probablemente también una de estrategia: si se ha resistido a cambiarse a Exchange Online por razones comerciales u operativas, debe estar preparado con una estrategia para asegurarse de que sus usuarios estén protegidos contra el ransomware y otras amenazas, y que tenga una solución viable. manera de recuperar datos si esa estrategia de protección falla. El costo de hacerlo es alto, pero el costo de no hacerlo es peor, y la comparación de esos costos puede llevarlo a reconsiderar si, después de todo, la nube es el lugar adecuado para su correo electrónico.