Permisos de invitado mal configurados en Experience Cloud ponen en riesgo tus datos

Hace poco Salesforce alertó sobre un aumento de actividad maliciosa que tiene como objetivo sitios públicos construidos con Experience Cloud. La técnica descrita no explota un fallo del propio servicio, sino configuraciones demasiado permisivas en el perfil de usuario invitado que muchas organizaciones mantienen para publicar páginas públicas—y que, si no se ajustan correctamente, pueden permitir a atacantes obtener información que no debería estar abierta al público.

En el centro de la noticia está una versión modificada de una herramienta de código abierto llamada AuraInspector, desarrollada para auditar configuraciones dentro del marco Aura de Salesforce. La herramienta original, lanzada por Mandiant, sirve para identificar objetos y puntos expuestos por endpoints públicos como /s/sfsites/aura. Lo preocupante es que, según Salesforce, actores maliciosos adaptaron esa utilidad para automatizar barridos masivos y pasar de la mera detección a la extracción de datos cuando se encuentran configuraciones demasiado laxas.

Esto significa que no se trata de una “vulnerabilidad” en la plataforma per se, sino de configuraciones que permiten a usuarios no autenticados realizar consultas sobre objetos del CRM. Salesforce ha sido explícito en señalar que, hasta ahora, no han detectado un fallo inherente al sistema: los intentos se dirigen a ajustes de clientes que no siguen las recomendaciones de seguridad publicadas por la propia compañía. Puede leerse el comunicado y las indicaciones oficiales en el blog de Salesforce y en su aviso público sobre el asunto aquí y en su página de estado aquí.

Para entender la mecánica: los sitios públicos de Experience Cloud usan un perfil especial de “guest user” para mostrar contenido público como entradas de ayuda, FAQs o páginas de aterrizaje. Ese perfil debe tener permisos estrictamente limitados. Si por error se conceden permisos de lectura o acceso a APIs públicas a ese perfil, un escáner automatizado podría enumerar objetos e incluso extraer campos con datos sensibles sin necesidad de autenticación.

El riesgo práctico no es sólo la exfiltración inmediata de nombres o teléfonos; Salesforce advierte que esa información puede ser la materia prima de ataques posteriores. Datos aparentemente inocuos sirven para afinar campañas de ingeniería social y ataques por voz (vishing), que suelen ser más efectivos cuando el atacante ya dispone de detalles verificables sobre empleados o clientes. En ese sentido, la actividad reportada encaja en lo que la compañía califica como un patrón más amplio de ataques “basados en identidad”.

Salesforce ha recomendado varias medidas de mitigación que cualquier administrador debería revisar de inmediato: restringir el acceso del usuario invitado, establecer la visibilidad por defecto de los objetos en privado, desactivar accesos públicos a APIs desde perfiles guest y controlar la autoinscripción si no es estrictamente necesaria. La compañía ha publicado guías con pasos concretos para auditar y reforzar estas configuraciones en sus recursos.

La herramienta original sobre la que se basan estos ataques fue publicada por Mandiant; la existencia de una versión modificada por actores maliciosos muestra cómo las utilidades diseñadas para mejorar la seguridad también pueden ser reutilizadas con fines ofensivos si caen en manos equivocadas. Quienes quieran revisar la herramienta pública pueden consultar el repositorio oficial y las notas de la publicación por parte de Mandiant en GitHub y en la web de Mandiant aquí.

Salesforce atribuye la campaña a un grupo de amenazas conocido sin nombrarlo expresamente, lo que abre la posibilidad de relación con operativos que ya han dirigido anteriores ataques contra ecosistemas CRM a través de aplicaciones terceros. En cualquier caso, el mensaje para administradores y responsables de seguridad es claro: revisar las políticas de acceso, monitorizar consultas inusuales y aplicar el principio de mínimos privilegios en todos los perfiles expuestos públicamente.

Para equipos técnicos y de seguridad que necesiten priorizar acciones, no es necesario esperar a una intrusión para reaccionar. Una auditoría de permisos del perfil guest, la desactivación de APIs públicas para ese perfil y la revisión de logs de acceso suelen ser medidas técnicas de alto impacto. Además de seguir las recomendaciones de Salesforce, conviene integrar alertas específicas en los sistemas de detección para capturar patrones de escaneo masivo o consultas que intenten enumerar objetos del CRM.

En definitiva, este incidente es un recordatorio de que la seguridad no es sólo cuestión de parches y actualizaciones del proveedor: también depende de las políticas y configuraciones locales. Las herramientas automatizadas pueden ayudar a identificar debilidades, pero también pueden ser reutilizadas por adversarios», por lo que una configuración prudente y la vigilancia constante siguen siendo las mejores barreras ante este tipo de campañas.