Cuando la filtración de un proveedor también te afecta: lecciones del incidente de Klue

Hay una verdad incómoda que tarde o temprano enfrenta todo equipo de seguridad: la filtración que más te perjudique quizá no ocurra dentro de tu organización. Puedes aplicar parches a tu código, rotar tus secretos periódicamente y mantener un perímetro seguro; aun así, podrías despertar ante un incidente causado por un sistema que no es tuyo.

Así fue el incidente relacionado con Klue, una plataforma de inteligencia de mercado que muchas empresas usan para obtener información competitiva. Según lo que se ha hecho público, un actor de amenazas comprometió el backend de Klue y aprovechó ese acceso para llegar a los sistemas conectados de sus clientes, incluidos los entornos de Salesforce que habían integrado con la plataforma. Además, otros proveedores de seguridad, como Recorded Future, Tanium, Huntress y Jamf, también se vieron afectados y compartieron actualizaciones públicas. Vale la pena detenerse a analizar lo ocurrido, porque sus mecanismos ilustran claramente cómo pueden vulnerarse los ecosistemas modernos de software como servicio (SaaS).

Anatomía del incidente

Según la información divulgada hasta ahora, la secuencia fue, a grandes rasgos, la siguiente:

El punto de entrada inicial a Klue fue una credencial antigua que, según se informa, se creó en algún momento para un prototipo de integración que luego se abandonó, pero nunca se desactivó. El acceso siguió vigente después de que terminara el proyecto para el que se había creado. Un actor de amenazas la encontró y todavía funcionaba.

Desde allí, el atacante llegó a la parte de la infraestructura de Klue que conecta la plataforma con las herramientas de sus clientes. Esas conexiones funcionan con tokens de OAuth: credenciales persistentes que permiten a Klue leer y escribir en sistemas como Salesforce en nombre de sus clientes. El atacante introdujo código diseñado para recolectar esos tokens. Una vez que los obtuvo, ya no necesitaba vulnerar a cada cliente por separado. Podía autenticarse como la cuenta de servicio descubierta usando el secreto de la integración, consultar directamente los datos de gestión de relaciones con clientes (CRM) de cada cliente y luego exfiltrarlos. Después se produjeron intentos de extorsión.

Si dejamos de lado los detalles, queda un patrón conocido: un eslabón débil, un conjunto de llaves prestadas y un alcance del impacto que se extiende a todos los que están conectados más adelante. Una sola intrusión no quedó limitada a una empresa. Se propagó.

Una nota sobre Snyk

En aras de la transparencia que esperaríamos de cualquier proveedor, queremos hablar con claridad: Snyk fue una de las organizaciones afectadas por el incidente de Klue. Nuestra investigación indica que, hasta donde sabemos en este momento, el impacto se limitó principalmente a campos de datos empresariales en los entornos de Salesforce. Esto incluye información de contacto comercial de clientes y únicamente el título y la descripción de un subconjunto limitado de casos de soporte al cliente. No se incluyó el cuerpo ni el contenido de los casos de soporte, y los productos de Snyk tampoco se vieron afectados. Nuestra capacidad para atender a los clientes no sufrió ningún impacto.

Al recibir la notificación, desactivamos la integración de Klue en Salesforce, iniciamos nuestra propia revisión y nos pusimos en contacto con las partes correspondientes. Para consultar el estado actual y la información más reciente, visita status.snyk.io o el Snyk Trust Center. Mantendremos ambos actualizados a medida que avance nuestra revisión.

Si hay algo que te pedimos que tengas presente, más allá de nuestra propia situación, es que revises las llaves que has entregado y también aquellas que olvidaste haber creado.