Cómo MuleSoft parchó una falla de seguridad crítica, evitó un desastre y... lo que se puede aprender

MuleSoft, una compañía ahora propiedad de Salesforce, fabrica middleware. El middleware es lo que los ingenieros llaman "pegamento de software". Puede encontrarlo en todas las grandes empresas de todo el mundo. Un middleware se puede usar para vincular aplicaciones en la nube distribuidas en decenas, cientos o miles de servidores, pero también se puede usar en redes más pequeñas, para traducir datos a medida que se mueven entre aplicaciones que funcionan en diferentes formatos. Todos usan middleware. ¡Todos!

El jueves 1 de agosto se la empresa encontró una vulnerabilidad de seguridad crítica en el motor MuleSoft y el API Gateway, dos de los productos más populares de la compañía.

Innumerables ingenieros de todo el mundo fueron convocados en reuniones o tuvieron llamadas telefónicas con el equipo de seguridad de MuleSoft.

Un día antes, MuleSoft había enviado un correo electrónico a una lista seleccionada de clientes. Instó a las compañías a instalar los últimos parches, lanzados el mismo día. El correo electrónico, obtenido por ZDNet e incrustado a continuación, también instó a las compañías a programar una llamada urgente con el personal de MuleSoft para que pudieran conocer detalles sobre una falla de seguridad que había sido reparada en secreto un día antes.

La compañía planeaba revelar detalles al público, pero en un mes, para que pudieran darles a las compañías una ventaja para parchar los sistemas locales.

Las compañías que ejecutan sistemas locales procesaban datos tan sensibles que simplemente no podían cargarse en una nube pública, por razones de seguridad, privacidad y cumplimiento. La página de inicio de MuleSoft enumera una variedad de bancos, procesadores de pagos y proveedores en la nube que probablemente estarían ejecutando sistemas locales, en lugar de depender de los motores Mule y las puertas de enlace API proporcionadas por Salesforce y los servicios en la nube de MuleSoft (que habían sido parcheados antes del correo electrónico incluso fue enviado).

Por el contenido del correo electrónico, se podía ver que MuleSoft se estaba tomando muy en serio el error de seguridad. En una acción poco frecuente, MuleSoft había pedido a los destinatarios de los correos electrónicos que no compartieran el contenido de la alerta de seguridad con nadie, ni siquiera verbalmente. La compañía describió la existencia de la vulnerabilidad como un problema de "need-to-know".

Obviamente, el correo electrónico se filtró. Se filtró en Twitter, en los canales de Slack y Discord, y en los grupos de Telegram. Es fácil ver por qué llamó la atención de todos. ¿Qué podría haber sido tan malo que MuleSoft describía como un problema de "necesidad de saber"?

La falla de directory traversal

Varias personas descargaron los parches y analizaron su contenido. Encontraron correcciones en el código de MuleSoft específico con un error Directory o Path Traversal. Este tipo de error puede permitir que un atacante malintencionado cargue y coloque archivos en un sistema en ubicaciones inesperadas del sistema. Si el atacante puede ajustar el ataque, puede controlar los lugares donde pueden terminar los archivos maliciosos.

Hay varios lugares en un sistema Windows o Linux donde los archivos cargados podrían ejecutarse automáticamente, lo que lleva a una situación en la que el atacante podría ejecutar código malicioso y apoderarse por completo de servidores vulnerables.

Dado que algunos middleware se ubican justo detrás de los servidores web, efectivamente se encuentran expuestos en Internet, con el servidor web pasando automáticamente la entrada externa al middleware, para ser transportados a API internas, bases de datos o sistemas de procesamiento de datos.

Era un error muy peligroso, y MuleSoft lo sabía.

Cuando ZDNet contactó a MuleSoft para obtener comentarios, casi de inmediato nos llevaron a una conferencia telefónica con el Director Técnico de MuleSoft, Uri Sarid, y el Director de Fideicomiso de Salesforce, Jim Alkove, en menos de una hora, un viernes por la noche, cuando la mayoría de la gente se había ido a casa.

Tenían una máquina bien engrasada funcionando en ese momento, y algún reportero entrometido estaba a punto de arruinarlo todo. Sarid y Alkove temían que un artículo de noticias atraería atención no deseada a la falla de seguridad de su compañía y pudiera conducir a ataques contra algunos de sus clientes.

Pero en lugar de negar que algo estaba mal, se tomaron el tiempo para explicar el complejo sistema que tenían para hacer frente a esta vulnerabilidad, y en ese punto, habría sido irresponsable por parte de ZDNet publicarlo.

Un nuevo enfoque para notificar a los clientes

MuleSoft había puesto el máximo esfuerzo tras este problema. La compañía había puesto su importante fuerza de atención al cliente en el tema y tenía la intención de notificar a todos y cada uno de sus clientes que ejecutaban sistemas locales, sin importar qué.

Se ordenó a los representantes que llamaran a cada compañía en parte. Todos los que ejecutaban un motor MuleSoft o un API Gateway localmente recibían una llamada para verificar si recibieron y leyeron el correo electrónico.

Además, Sarid dijo que MuleSoft había dado un paso sin precedentes al buscar y hablar con los departamentos de seguridad y DevOps de cada compañía, y no solo con secretarias o representantes de ventas.

Se estaban tomando muy en serio esta falla de seguridad. Querían que su mensaje llegara a la persona adecuada en cada organización, y querían asegurarse de que las empresas instalaran los parches.

Pero no se detuvieron aquí. MuleSoft también programó una segunda ola de llamadas después de que las compañías instalaron los parches, verificando que los clientes lo completaron, y transmitiendo consejos de mitigación adicionales.

Y los ejecutivos de MuleSoft y Salesforce no estaban exagerando. Lo que le dijeron a ZDNet en una primera llamada a principios de agosto es lo que vimos discutido en varios foros de discusión en línea, donde numerosos programadores describían llamadas telefónicas y reuniones de seguridad similares.

"Literalmente tuvimos miles de llamadas con estos clientes, y lo interesante es que los comentarios de los clientes que uno podría imaginar serían preocupantes, resultaron en realidad abrumadoramente positivos", dijo Sarid a ZDNet en una llamada telefónica de seguimiento este viernes.

"Numerosos clientes nos agradecieron por adoptar un enfoque inusualmente proactivo para llamarlos y hablarles sobre el problema. No habían visto a los proveedores hacer eso antes", dijo.

Otras empresas deben emplear enfoques similares

Un mes después de iniciar este proceso único de divulgación de vulnerabilidades, MuleSoft ahora lo ha hecho público. Los detalles sobre este problema de seguridad, como se prometió en su notificación de correo electrónico privado, se han publicado en el sitio de la compañía. MITRE también está en el proceso de asignar un CVE (identificador de error de seguridad) a esta vulnerabilidad.

Pero aunque los clientes de MuleSoft han parcheado, Sarid ahora espera que otras compañías aprendan de la experiencia de MuleSoft y adopten un enfoque proactivo similar para notificar a los clientes sobre problemas críticos, en lugar de diferir toda responsabilidad a sus clientes.

"No quieres manejar todo de la misma manera", dijo Sarid a ZDNet. "Las numerosas vulnerabilidades más pequeñas se pueden abordar de manera estándar. Pero los que requieren acciones urgentes que se divulgan antes de hacerse públicas, para esos no hay ningún procedimiento estándar que las empresas puedan seguir".

Sarid espera que otras compañías sigan el enfoque de MuleSoft cuando se enfrentan a una falla de seguridad importante, en lugar de descargar un aviso de seguridad en una página de soporte enterrada en algún lugar de sus sitios web, donde muy pocas personas saben mirar, sin molestarse en notificar a los clientes a través de algo tan básico como un correo electrónico, y mucho menos un teléfono.

Mulesoft vs el fiasco de divulgación de Fortinet y Pulse Secure

Lo que propone Sarid tiene mucho sentido, pero es algo que casi nunca se hace en realidad.

Sin embargo, el destino les ayudó a Sarid y MuleSoft, demostrando lo que sucede cuando las empresas adoptan un enfoque descuidado para notificar a los clientes sobre vulnerabilidades críticas.

A principios de este año, los investigadores de seguridad encontraron varias fallas de seguridad en muchos productos VPN empresariales. Los productos de Fortinet y Pulse Secure se vieron afectados por estos defectos. Las compañías hicieron su trabajo y resolvieron estos problemas y luego lanzaron avisos de seguridad en sus sitios.

El problema es que la mayoría de los clientes no estaban al tanto de estas actualizaciones y del hecho de que contenían soluciones para fallas de seguridad importantes. Cuando los atacantes comenzaron a explotar estas vulnerabilidades a mediados de agosto, la mayoría de las empresas que usaban estos productos VPN quedaron sin preparación.

There’s many vulns here but a key one with Pulse Secure is a path traversal bug which is *specifically allowed* in the code. We should not be reselling vendors who behave irresponsibly with disclosure and remediation. pic.twitter.com/R3tV1gnOsS

— Kevin Beaumont (@GossiTheDog) August 29, 2019

Ditto. It might have been nice for the account manager to mention they’ve shipped us software with a remote access backdoor which is being actively exploited in the wild, and that we might want to patch. https://t.co/ynyfBhEu1M

— Kevin Beaumont (@GossiTheDog) August 29, 2019

Ahora imagínese si estas compañías hubieran recibido una llamada telefónica de Fortinet o Pulse Secure, de manera similar a cómo MuleSoft se acercó a abordar su problema de seguridad.

El CTO de MuleSoft sabe exactamente cómo reaccionarían los clientes de Fortinet y Pulse Secure porque su compañía lo experimentó de primera mano.

"Cuando estás hablando con la persona de seguridad apropiada y le estás diciendo más información que solo la persona de seguridad entiende y maneja, se dan la vuelta y dicen '¡gracias!'", Dijo Sarid a ZDNet.

"Por lo tanto, convierte esta interacción potencialmente muy negativa en algo muy positivo, que con suerte es un incentivo para que otras compañías, para otros proveedores como nosotros, elijan este tipo de acción".

Traducción: Raúl Batista de la Redacción de Segu-Info
Autor: Catalin Cimpanu
Fuente: ZDNet - Zero Day

Suscríbete a nuestro Boletín