De vulnerabilidades a exposiciones: cuando el riesgo se esconde en la integración
- Oscar Gómez
- 7 oct
- 4 Min. de lectura
Las brechas de estas semanas volvieron a recordarnos que el golpe más caro no siempre es el que atraviesa un firewall, sino el que se cuela por una puerta legítima mal vigilada.
Mientras Jaguar Land Rover prolongó un paro de producción por un ataque que inmovilizó plantas enteras y multiplicó pérdidas, Kering confirmó el robo de datos de clientes de Gucci, Balenciaga y McQueen, una muestra de cómo la interrupción industrial y la exposición masiva de información coexisten cuando la cadena digital se tensa por el eslabón equivocado.
No son anécdotas sueltas: son síntomas de ecosistemas hiperconectados donde un permiso de más o una integración mal entendida hacen de vector principal.
En ese telón de fondo, la brecha más pedagógica es la de Tenable porque no “rompieron” sus productos de seguridad, sino que explotaron una integración SaaS de soporte en Salesforce para leer datos que parecían inocuos —asuntos y descripciones de tickets, contactos— y que en la práctica suelen esconder secretos operativos copiados a última hora.
La cronología pública es consistente: entre el 8 y el 18 de agosto los atacantes abusaron de tokens OAuth ligados a la aplicación Drift de Salesloft para lanzar consultas SOQL y extraer información desde instancias de clientes en Salesforce.
La respuesta fue revocar credenciales, deshabilitar la app y notificar a los afectados. El matiz importante es el vector: no se vulneró el “core” de Salesforce, se abusó de una confianza ya oncedida a un conector autorizado. Esa es la diferencia entre estar comprometido y verse comprometido a través de lo que uno mismo permitió. En otras palabras, no fue Salesforce el problema: fue la puerta abierta que tú mismo habías permitido.
Contarlo como “una filtración de soporte” es perder la lección. El adversario no buscaba un listado de casos, buscaba llaves enterradas en campos de negocio, comentarios y descripciones: credenciales de nube, referencias de Snowflake, contraseñas reutilizadas, cualquier secreto que alguien pegó en un texto “temporal”.
Esa es, de hecho, la moraleja del giro del sector desde “gestión de vulnerabilidades” hacia “gestión de exposición”: dejar de acumular hallazgos sin peso y empezar a priorizar por criticidad de activos, contexto de amenaza y explotabilidad real, para atacar el uno por ciento que explica el noventa y nueve por ciento del riesgo.
La otra grieta, igual de pedagógica por lo doméstica, viene del escritorio: la aplicación de Google Drive para Windows y su carpeta de caché local DriveFS. Distintos análisis técnicos han mostrado que, en equipos compartidos, basta con copiar el contenido de DriveFS de un perfil y pegarlo en otro para que el cliente cargue el Drive ajeno sin pedir reautenticación.
El problema no es la nube, es la confianza casi ciega en el caché local y un aislamiento por usuario insuficiente, justo lo contrario de lo que promete un enfoque “zero trust” en el endpoint.
Algunos sitios atribuyen un CVE concreto a este fallo, pero conviene ser precisos: el identificador CVE-2025-5150 registrado oficialmente corresponde a otra vulnerabilidad (docarray) y no a Drive Desktop.
Hasta que exista correlación inequívoca, lo prudente es tratarlo como un defecto de aislamiento ampliamente documentado por la comunidad, con mitigaciones obvias: evitar Drive Desktop en PCs compartidos, limpiar caché al cerrar sesión y restringir su uso a endpoints gestionados. En otras palabras: si compartes tu equipo, cualquiera podría abrir tu nube sin contraseña.
El hecho técnico, con o sin etiqueta, es claro: si la sesión local vale más que la identidad, el eslabón débil es el equipo físico y la disciplina de sesiones. Todo esto se conecta con la idea de que un análisis o escaneo de vulnerabilidades es una fotografía, no un diagnóstico.
La seguridad llega cuando añadimos contexto: qué activo es crítico, qué integración puede leer campos libres donde alguien pegó una clave de API, qué token debería tener vida corta y origen restringido, qué alerta importa porque toca facturación y no un servidor de pruebas.
Esa lectura convierte herramientas en decisiones: tratar los tokens como credenciales de primera clase con rotación y scopes mínimos, revisar periódicamente “connected apps” y cortar permisos excesivos, inspeccionar nuestros SaaS para buscar secretos “enterrados” en tickets o comentarios, y, sobre todo, unir telemetría técnica con impacto de negocio para que la priorización sea real y no cosmética.
Y si hablamos de impacto, debemos hablar de datos sensibles. Mantener PII, credenciales o datos de pago sin cifrar o sin tokenizar ya no es imprudencia: es negligencia operativa. Tokenizar desactiva el valor explotable del dato cuando circula por múltiples sistemas y, de paso, puede reducir su alcance de cumplimiento.
Cifrar protege la confidencialidad de lo que no debe salir de la bóveda, idealmente con políticas de gestión de llaves serias y, cuando toca, cifrado de formato preservado para no romper lo legado. No es un debate religioso entre técnicas, es arquitectura aplicada al riesgo y al presupuesto.
Para una pyme en 2025, esto no va de replicar un SOC bancario, sino de visibilidad continua y disciplina: EDR/XDR bien administrado, correlación razonable en SIEM o un MDR cuando el equipo es corto, higiene extrema en integraciones de Salesforce, Google Workspace o el SaaS que corresponda, detección de secretos en repos y CRMs, acompañados de la convicción de que ninguna herramienta te salva si llenas el campo “descripción” de un ticket con contraseñas.
Soluciones como un Splunk/QRadar encajan en presupuestos contenidos si se prioriza por riesgo y no por catálogo. Lo que no cabe en ningún presupuesto es seguir concediendo permisos desbordados y tokens sin caducidad. La clave no es la herramienta, es la interpretación.
Si hubiera que condensarlo en una sola idea práctica sería esta: el problema no fue “un escaneo que no detectó algo”, fue una relación de confianza que nadie supo interpretar a tiempo. El antídoto es disciplina práctica: acotar y rotar tokens, limpiar y aislar cachés locales, inspeccionar los campos “libres” donde conviven texto y secretos, tokenizar lo que viaja por muchas manos, cifrar lo que no puede salir de la bóveda y exigir que cada alerta llegue con contexto de negocio.
Referencias
Si deseas tener siempre a la mano el artículo escrito por Oscar Gómez, te invitamos a descargarlo, compartirlo y comentarnos qué opinas al respecto.
Comentarios