Empecemos este artículo con una apuesta: les puedo asegurar que cerca del 70% de sus sistemas SAP es vulnerable a algún tipo de ataque. No me baso en estadísticas publicadas, sino en lo que vemos mis colegas y yo en cada proyecto que llevamos a cabo en nuestros clientes desde hace 25 años. ¿Se imaginan ustedes una proporción así en la seguridad de una línea aérea o un banco?

Se insiste poco en el valor del contenido de un SAP ERP o S/4: datos financieros, operativos y administrativos de importancia suprema para la organización. ¿Por qué no los protegemos suficientemente? Quizá por desconocimiento de la panoplia de vectores de ataque utilizables. Vamos a revisar algunos de ellos, aunque sin entrar en detalles técnicos (no es cuestión de dar ideas).

Por ejemplo, en el ámbito de la ingeniería social, aún hoy sorprende lo fácil que resulta obtener la contraseña de un usuario clave con una llamada de teléfono usando argumentos pseudotécnicos. Como ejemplo, transcribo una conversación real:

—Buenos días, ¿puedo hablar con XXXX?
—Soy yo.
—Te llamo de Sistemas, tu usuario está bloqueando varios jobs de SAP porque tiene la contraseña mal escrita.
—Pues no sé, no recuerdo haber lanzado jobs.
—Son jobs antiguos, pero llevan varios días bloqueándose y causando incidencias. ¿La contraseña es “password123”?
—No.
—Por eso está fallando. Pásame la correcta y probamos a ver si solucionamos esto de una vez, que nos están lloviendo las incidencias.
—OK, es…

Sí. Esta técnica tan burda a menudo funciona. Ahora imaginen la cantidad de variantes posibles, más aún si el atacante conoce la empresa desde dentro, y a la víctima. Se puede aderezar con phishing, incidencias reales provocadas para dar lugar a la llamada, etc. La urgencia, la presión técnica y la habilidad del llamante hacen el resto. Este vector es difícil de contrarrestar, porque el factor humano es imprevisible. La única solución es la formación adecuada de los usuarios.

Sistema de ficheros de SAP

Este vector también es uno de los grandes olvidados. Aunque la seguridad perimetral del servidor sea adecuada, y los roles y autorizaciones de SAP robustos, es necesario controlar y revisar periódicamente los accesos al sistema de ficheros, especialmente en los directorios de interfaz con otras aplicaciones:

• Subida y bajada de ficheros a y desde SAP al sistema operativo.
• Compartición NFS.
• Recursos compartidos de Windows.
• Transferencia de ficheros (SFTP).

Con el conocimiento adecuado, no solo es posible la obtención trivial de ficheros con información importante (listados de clientes, proveedores, etc.), sino también la extracción directa de la base de datos, la ejecución de comandos, etc. Todo ello sin dejar prácticamente huella, ya que toda la actividad se realizaría de manera anónima mediante suplantación de binarios legítimos.

Software obsoleto

SAP es un sistema que no ofrece facilidades para las actualizaciones. Una simple aplicación de support packages supone un miniproyecto que implica costes y un esfuerzo considerable. Pero hay que evaluar el precio de actualizar poco o nunca. Las vulnerabilidades en SAP se publican, e inmediatamente se diseñan herramientas específicas para usar los exploits. Aunque SAP también publique fixes o notas de seguridad con rapidez, si no se aplican estamos en una situación homóloga a tener rota la puerta de nuestra casa y que lo sepa todo el mundo. Algunos vectores conocidos son:

• Exploits de SAP. Fallos de seguridad o estabilidad de los binarios de SAP que pueden aprovecharse fácilmente sin conocimientos especiales. Normalmente, estos ataques son indetectables.
• Versiones antiguas con funciones peligrosas. A veces la propia funcionalidad estándar de SAP tiene agujeros de seguridad. Por ejemplo, algunas funciones de las versiones 3.0 y 3.1 de R/3 permitían —de forma estándar— hacerse con la sesión de otro usuario.
• Exploits de plataforma, sistema operativo o base de datos. Estos son aún más peligrosos porque son más conocidos y, por tanto, hay más atacantes potenciales y cuentan con más herramientas que los usan.

El remedio es obvio: hay que mantener el sistema actualizado y establecer una política de aplicación de parches de, al menos, una vez al año, aunque lo ideal sería cada seis meses.

Comandos externos

Este vector es interno de SAP y abre la posibilidad de que se ejecuten comandos a nivel de sistema operativo. Esta característica abre un amplio abanico de posibles ataques si se sabe utilizar, sobre todo teniendo en cuenta que, a menudo, el usuario con el que arrancan los servicios de SAP (<sid>adm) tiene acceso a cualquier fichero con el que trabaje de SAP, como es lógico. No es sencillo ejecutar un comando externo directamente desde SAP, salvo que se utilice la transacción adecuada o se conozca un poco de ABAP. Incluso desde ciertos módulos de función pueden cometerse tropelías innombrables.

La solución obvia pasa por diseñar buenas políticas de seguridad y, lo más importante, cumplirlas

La solución no pasa por ocultar estas posibilidades, puesto que son públicas y conocidas, sino por utilizar las autorizaciones de SAP de manera correcta y restringir muy detalladamente el uso no solo de transacciones, sino de código ABAP directo (programas y módulos de función). Por supuesto, hay que dejar de emplear indiscriminadamente roles y perfiles de administración, y se ha de auditar el sistema de manera continua.

Configuración deficiente

Por su extensión, este apartado merecería varios artículos. Algunos vectores clásicos son los siguientes:

• Desde hace años, un sniffer específico para SAP está al alcance de cualquiera. Recuérdese que el protocolo estándar CPIC por el que SAPGUI se comunica con el servidor no está cifrado. Ante la duda de estar paseando por la red datos confidenciales, usemos SNC u otro sistema para cifrar las comunicaciones.
• El uso de ciertas funciones accesibles por RFC es peligroso. Los sistemas de restricción basados en ACL son una buena herramienta para limitar desde qué máquinas pueden realizarse conexiones a los sistemas, especialmente por RFC.
• Parámetros de seguridad. Una parametrización laxa facilita otros ataques. A menudo, SAP tiene la política de contraseñas más pobre de la empresa, y no porque no se pueda regular, sino porque no se cambian los parámetros por defecto de caducidad y complejidad.
• Un clásico obvio es la “vida infinita” de los usuarios, sin un proceso automatizado que los deshabilite cuando llevan tiempo sin usarse. Un atacante puede servirse de estos usuarios como banco de pruebas sin riesgo de ser descubierto. He llegado incluso a ver sistemas en los que los usuarios se desbloquean automáticamente cada treinta minutos para evitar molestias a quienes los utilizan. Todo un chollo para hacer pruebas de fuerza bruta.

Solo queda recomendar la solución obvia: diseñar buenas políticas de seguridad y, lo más importante, cumplirlas.

Autorizaciones

La cuestión de las autorizaciones en SAP es especialmente compleja y encierra, además, riesgos para la seguridad. De forma resumida, estos serían los más importantes:

• Autorizaciones excesivas: se viola el principio básico de otorgar solo lo que se necesita.
• Pereza al asignar autorizaciones: se usa como plantilla otro usuario con funciones similares.
• Falta de auditorías periódicas y de auditorías automáticas realizadas con herramientas.
• Roles obsoletos que contienen autorizaciones críticas.

Los mismos vectores describen el remedio para limitarlos o eliminarlos. Solo hace falta implantar cierto orden y método en el uso de autorizaciones.

Si después de leer este breve y magro resumen de riesgos para su sistema ha sentido cierto desasosiego, el objetivo está conseguido. Desde luego, no busco asustar a nadie, sino recordar, una vez más, la importancia de tomarse la seguridad de SAP muy en serio.