Se acabó el acceso sin restricciones al sistema operativo: cómo detectar y contener los ataques a entornos SAP

Las aplicaciones SAP no funcionan de forma aislada, sino que están estrechamente vinculadas al sistema operativo subyacente. Ya se trate de escribir archivos de registro, procesar datos introducidos, ejecutar tareas en segundo plano o realizar comprobaciones de estado, siempre se necesita acceso a los recursos del sistema operativo para invocar funciones del sistema o llevar a cabo operaciones en el sistema de archivos.

Todos los procesos iniciados por SAP a nivel del sistema operativo se ejecutan allí mediante un usuario dedicado del sistema operativo, cuyo nombre, en los sistemas Linux, se basa en el identificador del sistema SAP y que, por ejemplo, se llama «adm». El sistema operativo desconoce tanto los procesos de negocio del nivel de SAP como los usuarios, roles, transacciones y autorizaciones de dicho nivel. A la inversa, SAP desconoce qué funciones se han ejecutado en el sistema operativo o qué accesos se han producido: las aplicaciones de SAP se limitan a realizar una solicitud y reciben un resultado. La visibilidad entre ambos niveles es, por tanto, relativamente limitada; el intercambio se basa en la confianza mutua.

Entre el código ABAP de las aplicaciones SAP y el sistema operativo se encuentra, a modo de intermediario, el núcleo de SAP, que se encarga de la creación de procesos, la gestión de la memoria, la comunicación en red, el acceso al sistema de archivos y la ejecución de comandos del sistema operativo. Este valida las solicitudes de las aplicaciones y utiliza el usuario del sistema operativo de SAP para ejecutar comandos o acceder a archivos. En la mayoría de los casos, está definido con precisión cuáles son esos comandos y esas posibilidades de acceso. Las aplicaciones ABAP las invocan mediante módulos de función estandarizados; el núcleo las resuelve, valida las autorizaciones, organiza los parámetros y, finalmente, las ejecuta.

Sin embargo, debido a prácticas del pasado, sigue existiendo la posibilidad de que las aplicaciones ABAP transmitan directamente al núcleo los comandos concretos del sistema operativo mediante instrucciones como CALL ‘SYSTEM‘ o CALL ‘CFUNC‘. Se desaconseja encarecidamente esta práctica y, en entornos modernos, esta opción se restringe cada vez más; sin embargo, sigue siendo frecuente encontrarla en el código heredado. Además, por supuesto, los propios componentes del núcleo también pueden iniciar llamadas a comandos para, por ejemplo, controlar instancias, realizar comprobaciones del estado del sistema o supervisar recursos. Sin embargo, esto no altera el principio básico de que el núcleo ejecuta los comandos a través del usuario del sistema operativo de SAP.

Accesos a archivos con alto riesgo potencial

Si los atacantes logran aprovechar vulnerabilidades o configuraciones erróneas en el nivel de SAP, o hacer un uso indebido de datos de acceso sustraídos, pueden interactuar con el nivel del sistema operativo a través del usuario de dicho sistema. Las consecuencias concretas dependen del entorno SAP en cuestión, de la configuración del sistema operativo y de la infraestructura circundante. Sin embargo, el mero hecho de tener acceso al sistema de archivos ya les ofrece un amplio margen de maniobra: entre otras cosas, pueden leer archivos de configuración, parámetros de conexión, definiciones de interfaces y certificados, así como modificar o incluso sustituir scripts.

De este modo, los atacantes pueden espiar el sistema, manipularlo y asegurarse un acceso permanente, por si se cambian las contraseñas o se corrigen las vulnerabilidades. Para ello, basta con modificar o sustituir scripts de inicio, tareas programadas (cronjobs) y otros elementos que se ejecutan automáticamente en momentos determinados o ante determinados eventos. A menudo, los atacantes también instalan puertas traseras, canales de comunicación protegidos y herramientas de piratería para sus futuras actividades. Para que estas no llamen la atención, modifican los archivos de registro, borran las huellas forenses o interfieren en la supervisión.

Independientemente de ello, el sistema SAP comprometido también puede servir de puerta de entrada a otros sistemas dentro del entorno SAP, como servidores de bases de datos y de archivos, sistemas de copias de seguridad o plataformas de supervisión.

Posibles escenarios de ataque en la práctica

Los distintos escenarios de ataque que los expertos de Fortinet, No Monkey, PwC y Red Hat pudieron demostrar en el marco de un proyecto denominado Ironroot se basan en el uso indebido de diversas transacciones de SAP. AL11, por ejemplo, permite a los administradores acceder a directorios predefinidos a través de la interfaz de SAP. Si se añaden nuevas entradas a la lista de directorios, los archivos que se encuentran en ellos pueden abrirse directamente desde SAP, sin necesidad de acceso a la shell del servidor. Dependiendo de los permisos del usuario de SAP en el sistema host, esto permite acceder a información sensible, como configuraciones, registros, credenciales y datos de aplicaciones, que ayudan a los atacantes a planificar y llevar a cabo otras actividades.

Además, mediante las funciones nativas de ABAP para la gestión de archivos y la transacción SE38, es posible editar y crear archivos en el sistema. En una demostración se generó de esta forma un informe que creó un archivo inofensivo en el sistema de archivos. En un escenario de este tipo, los atacantes podrían, por ejemplo, modificar o crear nuevas configuraciones y scripts. Si se trata de elementos que el propio sistema operativo inicia en determinados momentos o circunstancias, ni siquiera necesitan permisos para ejecutar archivos y código a fin de causar daños graves.

Sin embargo, los atacantes pueden obtener estos derechos de forma fraudulenta. Una posibilidad es aprovechar la transacción SM69 para definir comandos propios que, posteriormente, se pueden ejecutar desde la interfaz de SAP mediante la transacción SM49. SAP abre un shell que ejecuta el comando —por ejemplo, el inicio de un script— a nivel del sistema operativo. En la demostración realizada por los expertos, se trataba únicamente de un mensaje inofensivo del tipo „Hello from the OS“, que se devolvía directamente al nivel de SAP. En caso de ataque, podrían ser binarios, scripts o herramientas del sistema peligrosos.

Además de SM49 y SM69, SAP también incluye funciones que permiten una interacción directa con el shell del sistema operativo, entre ellas el informe ABAP RSBDCOS0, que ejecuta comandos del sistema operativo y muestra los resultados dentro de la interfaz de SAP. En sus demostraciones, los expertos utilizaron el informe y, en un primer momento, comandos sencillos como «whoami» para determinar si los comandos se ejecutaban como usuario del sistema operativo de SAP. A continuación, se inició un shell inverso con Netcat y se estableció una conexión saliente con un sistema externo. A través de ella, los atacantes podrían asegurarse un acceso continuo al sistema operativo, buscar y crear archivos, ejecutar cualquier comando e instalarse de forma permanente. En esencia, disponen de las mismas posibilidades que un usuario que haya iniciado sesión localmente, lo que modifica significativamente la naturaleza del compromiso en comparación con los escenarios de ataque descritos anteriormente a través de transacciones SAP. La aplicación SAP solo sirve aquí como vector de ataque inicial.

La seguridad en varias etapas pasa a ser obligatoria

Para evitar ataques y la vulneración de los sistemas, las empresas suelen adoptar toda una serie de medidas: refuerzan la seguridad de los sistemas operativos, instalan soluciones de seguridad, corrigen vulnerabilidades, segmentan las redes, adoptan prácticas seguras en el desarrollo de software e implementan una supervisión continua. Sin embargo, en entornos empresariales complejos y en constante evolución, que los atacantes atacan cada vez más con el apoyo de la inteligencia artificial, estas medidas preventivas ya no son suficientes. Las vulnerabilidades, las configuraciones erróneas y otros puntos de ataque pueden detectarse y explotarse más rápido que nunca gracias a la IA, por lo que se necesitan conceptos de seguridad de varias capas para reducir la superficie de ataque y limitar el margen de maniobra de los intrusos.

Este enfoque, también conocido como «Defensa en profundidad», se basa en que varios mecanismos de seguridad se complementan entre sí, de modo que, si uno de ellos es superado, los demás están preparados para detener a los atacantes o, al menos, frenar su avance. Esto resulta especialmente importante en entornos SAP debido a la relación de confianza que existe entre el nivel de SAP y el del sistema operativo, ya que, si un atacante consigue ejecutar comandos del sistema operativo o realizar operaciones en el sistema de archivos a través de la pila de SAP, los mecanismos de protección preventivos ya han sido superados. En ese momento, el ataque ya está en marcha y ya no se puede impedir, sino solo contener.

Por ello, en el proyecto Ironroot, los expertos de Fortinet, No Monkey, PwC y Red Hat han desarrollado medidas destinadas a limitar las posibilidades de los atacantes a nivel del sistema operativo y a dificultar el espionaje y la infiltración en otros sistemas. Los objetivos concretos son:

• limitar el acceso al sistema de archivos. Una cuenta de SAP comprometida solo debe permitir el acceso a los directorios y archivos necesarios para el funcionamiento normal de SAP. Se debe impedir, en la medida de lo posible, el acceso a recursos del sistema operativo que no sean relevantes para ello, así como a credenciales sensibles y archivos administrativos.
• limitar la ejecución de procesos. Dado que los atacantes suelen ejecutar sus propias herramientas, scripts y archivos binarios tras haber conseguido acceso a un sistema, es necesario restringir estas posibilidades para impedir que ejecuten código malicioso, se instalen de forma permanente o exploren otros sistemas.
• Dificultar la ampliación de privilegios y los movimientos laterales. Si se limita el acceso a los recursos compartidos, las herramientas de administración y los canales de comunicación fiables, los atacantes ya no podrán avanzar tan fácilmente más allá del sistema comprometido inicialmente.
• mejorar la contención. Incluso si los atacantes logran comprometer la cuenta del sistema operativo de SAP, las posibilidades de actuación resultantes deben limitarse a un ámbito estrictamente definido.

Una combinación del control de acceso discrecional (DAC), la extensión del núcleo de Linux SELinux y el marco fapolicyd (File Access Policy Daemon) puede servir como una capa de seguridad adicional a nivel del sistema operativo y ayudar a alcanzar estos objetivos.

Control granular de los accesos

Si los controles de acceso discrecionales se asignan cuidadosamente siguiendo el principio del privilegio mínimo, ofrecen una buena protección básica, ya que los usuarios y grupos solo pueden acceder a los directorios y archivos que realmente necesitan para su trabajo. En entornos SAP, los administradores deben prestar especial atención, a la hora de asignar derechos, a los sistemas de archivos distribuidos, los directorios de transporte, los almacenes de copias de seguridad, los scripts de integración y las herramientas de administración. Sin embargo, si un atacante actúa en el contexto de seguridad de una cuenta de confianza, el sistema operativo considera legítimas todas sus acciones. Aquí es donde entran en juego SELinux y fapolicyd.

SELinux complementa Linux con un control de acceso obligatorio (MAC), en el que los accesos no se autorizan o deniegan en función de la identidad del usuario y del objeto al que desea acceder, sino sobre la base de políticas definidas de forma centralizada. Este enfoque permite un control granular, ya que las políticas permiten especificar con exactitud a qué archivos puede acceder un proceso, qué conexiones de red puede establecer, qué recursos puede modificar y qué interacciones entre componentes del sistema puede iniciar. Incluso si un atacante se hace con el control de un proceso SAP o de una cuenta del sistema operativo, no obtendrá permisos de acceso a recursos que vayan más allá de los definidos en las políticas. Cada intento es bloqueado por el núcleo y se registra en forma de entrada „avc: denied“ en /var/log/audit/audit.log o /var/log/messages. Si es necesario, estos registros pueden integrarse en sistemas SIEM y evaluarse de forma centralizada, lo que permite detectar de forma fiable los ataques en curso.

Por su parte, fapolicyd permite controlar qué objetos ejecutables pueden ejecutarse realmente; el propio Linux ofrece relativamente pocas restricciones en este sentido una vez que un atacante se ha hecho con el control de una cuenta con permisos suficientes. En lugar de una simple lista blanca, fapolicyd utiliza información sobre la integridad y la fiabilidad de los archivos, metadatos del gestor de paquetes y políticas definidas por el administrador. De este modo, se puede establecer que se puedan ejecutar binarios procedentes de repositorios autorizados, software SAP de confianza y aplicaciones autorizadas explícitamente. Por el contrario, se bloquean los archivos ejecutables procedentes de fuentes desconocidas o dudosas, de modo que los atacantes no puedan ejecutar scripts subidos, herramientas de tunelización ni otras herramientas de piratería informática.

Paquetes de políticas ya preparados para una protección rápida

SELinux y fapolicyd forman parte de muchas distribuciones de Linux, entre ellas Red Hat Enterprise Linux. Otras distribuciones incluyen en algunos casos módulos y funciones similares, como AppArmor, o pueden equiparse con ellos posteriormente.

Para garantizar una protección fiable en entornos SAP, es necesario ajustar SELinux y fapolicyd. En el marco de Ironroot se ha desarrollado un paquete de políticas para Red Hat Enterprise Linux que se puede instalar tras eliminar las políticas existentes y las etiquetas de recursos. A continuación, el paquete define nuevas etiquetas y mejora las políticas de acceso a las mismas, de modo que, por ejemplo:

• el administrador de ABAP ya no puede obtener privilegios de root mediante «sudo», algo que los atacantes suelen aprovechar para propagarse por la infraestructura.
• el administrador de SAP ya no puede utilizar un puerto reservado, algo que los atacantes suelen aprovechar para exportar datos confidenciales.
• el administrador de la base de datos HANA ya no puede modificar los archivos temporales del administrador de ABAP, algo que los atacantes suelen aprovechar para insertar comandos maliciosos.

Por supuesto, las empresas también pueden definir sus propias etiquetas y directrices para SELinux y fapolicyd.

Es importante entender DAC, SELinux y fapolicyd como una protección multicapa que solo despliega todo su potencial cuando sus componentes individuales actúan de forma conjunta, ya que los atacantes deben superar varios mecanismos de seguridad para acceder a datos sensibles, ejecutar su propio código o infiltrarse en otros sistemas. DAC determina qué usuarios y grupos pueden acceder a determinados recursos. SELinux añade reglas que restringen el comportamiento de los procesos, incluso cuando los permisos normales de acceso a los archivos permitirían dichas actividades. Y, por último, fapolicyd regula de forma fundamental qué software se puede ejecutar en el sistema.

Al directorio de socios: