Vulnerabilidades más comunes en sistemas SAP: guía técnica
Por el equipo de QuantumSec
La mayoría de los compromisos de SAP no explotan un fallo exótico: explotan configuraciones conocidas desde hace años que nadie revisó a fondo. Esta guía repasa las vulnerabilidades más habituales que encontramos al auditar entornos SAP en producción, de la más sencilla de corregir a la que más impacto de negocio suele tener.
Cuentas por defecto y contraseñas débiles
SAP incluye cuentas estándar (SAP*, DDIC, SAPCPIC, EARLYWATCH) con contraseñas por defecto ampliamente documentadas. Es habitual encontrarlas sin cambiar en mandantes de desarrollo o pre-producción —y, con menos frecuencia de la deseable, también en producción—, algo especialmente peligroso en la cuenta SAP*, que en determinadas configuraciones conserva privilegios equivalentes a administrador del sistema.
Interfaz RFC y Gateway mal configurados
El Gateway de SAP gestiona las llamadas RFC (Remote Function Call) entre sistemas. Cuando las listas de control de acceso (los ficheros secinfo y reginfo) están mal configuradas o ausentes, un atacante en la red puede registrar programas RFC maliciosos o ejecutar funciones administrativas sin autenticarse. La vulnerabilidad RECON (CVE-2020-6287), que afectó a SAP NetWeaver AS Java y recibió la puntuación máxima de severidad (CVSS 10), es el ejemplo más conocido de hasta dónde puede llegar un fallo en esta capa: permitía crear un usuario con privilegios máximos sin autenticación previa.
Segregación de funciones (SoD) rota
Cuando un mismo usuario acumula transacciones que deberían estar separadas —por ejemplo, crear un proveedor y aprobar el pago a ese proveedor, o crear un pedido de compra y confirmar su recepción— el sistema de autorizaciones dificulta que un control interno detecte un fraude. Este tipo de conflicto suele acumularse con el tiempo, a medida que se conceden roles adicionales sin revisar el conjunto completo de permisos que ya tiene el usuario.
Notas de seguridad de SAP sin aplicar
SAP publica correcciones de seguridad mensualmente, el segundo martes de cada mes (SAP Security Patch Day), como SAP Security Notes. Un sistema que acumula notas de seguridad sin aplicar durante meses o años queda expuesto a vulnerabilidades públicamente conocidas —y, en muchos casos, con exploits también públicos— que un atacante puede identificar simplemente comprobando la versión y el nivel de parcheo del sistema.
Código ABAP personalizado vulnerable
Los desarrollos a medida en ABAP —informes, transacciones custom, extensiones Web Dynpro o BSP— no pasan automáticamente por los mismos controles de seguridad que el código estándar de SAP. Es habitual encontrar inyección SQL o de comandos del sistema operativo cuando el desarrollo concatena directamente la entrada del usuario, y cross-site scripting en interfaces web personalizadas que no sanean correctamente la salida.
Servicios Fiori, OData y Message Server expuestos
A medida que SAP expone más funcionalidad a través de Fiori y APIs OData, la superficie de ataque accesible desde fuera de la red interna crece. Un Message Server accesible sin restricciones, o un servicio OData con controles de autorización más laxos que la transacción SAP GUI equivalente, puede convertirse en una vía de entrada que nadie está monitorizando con el mismo nivel de atención que el acceso tradicional.
FAQ
¿Es lo mismo una revisión de SoD que un pentest SAP?
No. Una revisión de SoD confirma, sobre el papel, qué combinaciones de permisos tienen los usuarios. Un pentest SAP confirma si esas combinaciones —y otras vulnerabilidades técnicas como el Gateway, el código ABAP o el estado de parcheo— son explotables de verdad, y demuestra el impacto real de un compromiso.
¿Sigue siendo relevante la vulnerabilidad RECON (CVE-2020-6287)?
El propio fallo lleva parcheado desde 2020, pero sigue siendo relevante como caso de referencia: meses después de su publicación seguía habiendo sistemas sin parchear siendo escaneados activamente por atacantes, lo que ilustra el riesgo real de acumular SAP Security Notes sin aplicar.
¿Con qué frecuencia debería auditarse un sistema SAP?
Como mínimo una vez al año, y siempre tras cambios relevantes: una migración a S/4HANA, una ampliación significativa de módulos o roles, o un incidente que haga sospechar de un compromiso o fraude interno.