Rackspace: vulnerabilidad de Microsoft, donde se originó el ataque

Rackspace Technology confirmó que el ataque masivo de ransomware del que fue víctima en diciembre pasado se produjo a través de un exploit de día cero contra una vulnerabilidad de falsificación de solicitud del lado del servidor (SSRF) en Microsoft Exchange Server, también conocida como CVE-2022-41080.

La CSO de la compañía Karen O’Reilly-Smith dijo a Dark Reading que “ahora estamos muy seguros” que el origen del caso se relaciona con dicho exploit.

“Microsoft reveló CVE-2022-41080 como una vulnerabilidad de escalada de privilegios y no incluyó notas por ser parte de una cadena de ejecución remota de código que era explotable”, comentó.

La empresa de Redmond corrigió la vulnerabilidad en noviembre pasado.

Un asesor externo de Rackspace le dijo a Dark Reading que Rackspace se había demorado en aplicar el parche ProxyNotShell en medio de preocupaciones sobre los informes de que causaba “errores de autenticación” que la empresa temía que pudieran derribar sus servidores Exchange.

Rackspace había implementado previamente las mitigaciones recomendadas por Microsoft para las vulnerabilidades, que Microsoft había considerado una forma de frustrar los ataques.

FBI investiga el ataque de ransomware dirigido a Rackspace

Rackspace contrató a CrowdStrike para ayudar con la investigación. La firma de seguridad compartió sus hallazgos en una publicación de blog que detalla cómo el grupo de ransomware Play estaba empleando una nueva técnica para activar la falla ProxyNotShell RCE de próxima etapa conocida como CVE-2022-41082 usando CVE -2022-41080.

La publicación de CrowdStrike no nombró a Rackspace en ese momento, pero el asesor externo de la compañía le dice a Dark Reading que la investigación sobre el método de derivación de mitigación de Play fue el resultado de la investigación de CrowdStrike sobre el ataque al proveedor de servicios de alojamiento.

Microsoft le dijo a Dark Reading el mes pasado que, si bien el ataque pasa por alto las mitigaciones de ProxyNotShell emitidas anteriormente, no pasa por alto el parche real.

“El parche es la respuesta si puede hacerlo”, dice el asesor externo, señalando que la compañía había sopesado seriamente el riesgo de aplicar el parche en un momento en que se decía que las mitigaciones eran efectivas y el parche tenía el riesgo de derribar sus servidores. “Evaluaron, consideraron y sopesaron [el riesgo] que conocían” en ese momento, dice el asesor externo. La empresa aún no ha aplicado el parche ya que los servidores siguen caídos.

Un portavoz de Rackspace no comentó si Rackspace había pagado a los atacantes de ransomware.

Related posts

Deja un comentario