Finie la libre circulation dans le système d'exploitation : détecter et contenir les attaques visant les environnements SAP

Les applications SAP n'existent pas de manière isolée, mais sont étroitement liées au système d'exploitation sous-jacent. Qu'il s'agisse d'écrire des fichiers journaux, de traiter des données saisies, d'exécuter des tâches en arrière-plan ou d'effectuer des contrôles d'intégrité, l'accès aux ressources du système d'exploitation est toujours nécessaire pour appeler des fonctions système ou effectuer des opérations sur le système de fichiers.

Tous les processus déclenchés par SAP au niveau du système d'exploitation sont lancés par un utilisateur dédié du système d'exploitation, qui, sur les systèmes Linux, porte le nom de l'identifiant système SAP et s'appelle, par exemple, « adm ». Le système d’exploitation ne connaît ni les processus métier du niveau SAP, ni les utilisateurs, rôles, transactions et autorisations qui y sont associés. À l’inverse, SAP ne sait pas quelles fonctions ont été exécutées dans le système d’exploitation ni quels accès ont eu lieu : les applications SAP se contentent d’envoyer une requête et de recevoir un résultat en retour. La visibilité entre les deux niveaux est donc relativement limitée ; l’échange repose sur une confiance mutuelle.

Entre le code ABAP des applications SAP et le système d'exploitation se trouve le noyau SAP, qui sert d'intermédiaire et se charge de la création des processus, de la gestion de la mémoire, des communications réseau, des accès au système de fichiers et de l'exécution des commandes du système d'exploitation. Il valide les requêtes des applications et utilise l'utilisateur du système d'exploitation de SAP pour exécuter des commandes ou des accès aux fichiers. Dans la plupart des cas, ces commandes et ces possibilités d'accès sont clairement définies. Les applications ABAP les appellent à l’aide de modules fonction standardisés : le noyau les résout, valide les autorisations, organise les paramètres et les exécute enfin.

Il existe toutefois, héritage du passé, la possibilité que des applications ABAP transmettent directement au noyau les commandes concrètes du système d’exploitation via des instructions telles que CALL ‘SYSTEM‘ ou CALL ‘CFUNC‘. Cette pratique est fortement déconseillée et, dans les environnements modernes, cette option est de plus en plus restreinte ; toutefois, on la retrouve encore fréquemment dans le code hérité. De plus, les composants du noyau peuvent bien sûr eux-mêmes initier des appels de commande, par exemple pour contrôler des instances, effectuer des vérifications de l'état du système ou surveiller les ressources. Cela ne change toutefois rien au principe fondamental selon lequel le noyau exécute les commandes via l’utilisateur du système d’exploitation de SAP.

Accès aux fichiers présentant un risque élevé

Si des attaquants parviennent à exploiter des vulnérabilités ou des erreurs de configuration au niveau SAP, ou à utiliser abusivement des identifiants volés, ils peuvent interagir avec le niveau du système d'exploitation via l'utilisateur de ce dernier. Les conséquences concrètes dépendent de l'environnement SAP concerné, de la configuration du système d'exploitation et de l'infrastructure environnante. Mais le simple fait d’accéder au système de fichiers leur offre déjà une grande marge de manœuvre : ils peuvent notamment consulter les fichiers de configuration, les paramètres de connexion, les définitions d’interface et les certificats, modifier des scripts, voire les remplacer.

Les pirates sont ainsi en mesure d'espionner le système, de le manipuler et de s'assurer un accès permanent – au cas où les mots de passe seraient modifiés ou les failles corrigées. Pour ce faire, il suffit parfois de modifier ou de remplacer des scripts de démarrage, des tâches cron et d’autres éléments qui s’exécutent automatiquement à des moments précis ou lors d’événements spécifiques. Souvent, les pirates mettent également en place des portes dérobées, des canaux de communication protégés et des outils de piratage pour leurs activités futures. Afin que celles-ci ne soient pas détectées, ils modifient les fichiers journaux, effacent les traces numériques ou perturbent les systèmes de surveillance.

Indépendamment de cela, le système SAP compromis peut également servir de tremplin vers d'autres systèmes au sein de l'environnement SAP, tels que des serveurs de bases de données et de fichiers, des systèmes de sauvegarde ou des plateformes de surveillance.

Scénarios d'attaque possibles dans la pratique

Divers scénarios d'attaque, que des experts de Fortinet, No Monkey, PwC et Red Hat ont pu démontrer dans le cadre d'un projet baptisé « Ironroot », reposent sur l'exploitation abusive de différentes transactions SAP. La transaction AL11, par exemple, permet aux administrateurs d’accéder à des répertoires prédéfinis via l’interface SAP. Si de nouvelles entrées sont ajoutées à la liste des répertoires, les fichiers qui s’y trouvent peuvent être ouverts directement depuis SAP, sans avoir besoin d’un accès shell au serveur. En fonction des autorisations dont dispose l’utilisateur SAP sur le système hôte, cela permet d’accéder à des informations sensibles telles que les configurations, les journaux, les identifiants et les données d’application, qui aident les attaquants à planifier et à mener d’autres activités.

Les fonctions natives d'ABAP pour la gestion des fichiers et la transaction SE38 permettent en outre de modifier et de créer des fichiers sur le système. Lors d'une démonstration, un rapport a ainsi été généré, qui a créé un fichier inoffensif dans le système de fichiers. Dans un tel scénario, des attaquants pourraient, par exemple, modifier ou recréer des configurations et des scripts. S’il s’agit d’éléments que le système d’exploitation lance lui-même à des moments ou à des occasions précis, ils n’ont même pas besoin des autorisations nécessaires pour exécuter des fichiers et du code afin de causer des dégâts importants.

Cependant, les pirates peuvent tout à fait s'approprier ces droits de manière frauduleuse. L'une des possibilités consiste à exploiter la transaction SM69 pour définir ses propres commandes, qui peuvent ensuite être appelées depuis l'interface SAP via la transaction SM49. SAP ouvre alors un shell qui exécute la commande – par exemple, le lancement d’un script – au niveau du système d’exploitation. Dans la démonstration réalisée par les experts, il s’agissait simplement d’un message inoffensif „ Hello from the OS “, qui a été renvoyé directement au niveau SAP. En cas d’attaque, il peut s’agir de fichiers binaires, de scripts ou d’outils système dangereux.

Outre SM49 et SM69, SAP propose également des fonctionnalités permettant une interaction directe avec le shell du système d'exploitation, notamment le programme ABAP RSBDCOS0, qui exécute des commandes du système d'exploitation et affiche les résultats obtenus au sein de l'interface SAP. Lors de leurs démonstrations, les experts ont utilisé ce rapport et, dans un premier temps, des commandes simples telles que « whoami » pour déterminer si les commandes étaient exécutées en tant qu’utilisateur du système d’exploitation SAP. Ils ont ensuite initié un shell inversé à l’aide de Netcat et établi une connexion sortante vers un système externe. Grâce à celle-ci, les attaquants pourraient s’assurer un accès continu au système d’exploitation, parcourir et créer des fichiers, exécuter n’importe quelle commande et s’implanter de manière permanente. En substance, ils disposent des mêmes possibilités qu’un utilisateur connecté localement, ce qui modifie considérablement la nature de la compromission par rapport aux scénarios d’attaque décrits précédemment via des transactions SAP. L’application SAP ne sert ici plus que de vecteur d’attaque initial.

La sécurité à plusieurs niveaux devient obligatoire

Pour prévenir les attaques et la compromission des systèmes, les entreprises prennent généralement toute une série de mesures : elles renforcent la sécurité des systèmes d'exploitation, installent des solutions de sécurité, corrigent les vulnérabilités, segmentent les réseaux, adoptent des pratiques sécurisées dans le développement logiciel et mettent en place une surveillance continue. Cependant, dans des environnements d'entreprise complexes et en constante évolution, qui sont de plus en plus souvent la cible d'attaques menées par des pirates s'appuyant sur l'IA, ces mesures préventives ne suffisent plus. Grâce à l’IA, les vulnérabilités, les erreurs de configuration et autres points d’attaque peuvent être détectés et exploités plus rapidement que jamais ; c’est pourquoi des stratégies de sécurité à plusieurs niveaux sont nécessaires pour réduire la surface d’attaque et limiter la marge de manœuvre des intrus.

Cette approche, également appelée « défense en profondeur », repose sur l'imbrication de plusieurs mécanismes de sécurité, de sorte que, si l'un d'entre eux est contourné, d'autres prennent le relais pour bloquer les attaquants ou, à tout le moins, les ralentir. Cela revêt une importance particulière dans les environnements SAP en raison de la relation de confiance entre le niveau SAP et celui du système d’exploitation : en effet, si un attaquant parvient à exécuter des commandes du système d’exploitation ou à effectuer des opérations sur le système de fichiers via la pile SAP, cela signifie que les mécanismes de protection préventifs ont déjà été contournés. À ce stade, l’attaque est en cours et ne peut plus être empêchée, mais seulement contenue.

Dans le cadre du projet Ironroot, les experts de Fortinet, No Monkey, PwC et Red Hat ont donc mis au point des mesures visant à limiter les possibilités des attaquants au niveau du système d'exploitation et à compliquer l'espionnage et l'infiltration d'autres systèmes. Les objectifs concrets sont les suivants :

• limiter l'accès au système de fichiers. Un compte SAP compromis ne doit autoriser l'accès qu'aux répertoires et fichiers nécessaires au fonctionnement normal de SAP. L'accès aux ressources du système d'exploitation non pertinentes à cet égard, aux identifiants sensibles et aux fichiers d'administration doit être empêché autant que possible.
• limiter l'exécution des processus. Étant donné que les attaquants exécutent souvent leurs propres outils, scripts et fichiers binaires après avoir obtenu l'accès à un système, il convient de restreindre ces possibilités afin de les empêcher d'exécuter du code malveillant, de s'implanter de manière permanente ou d'explorer d'autres systèmes.
• pour compliquer l'extension des privilèges et les mouvements latéraux. Si l'accès aux ressources partagées, aux outils d'administration et aux canaux de communication fiables est limité, les attaquants ne peuvent plus s'étendre aussi facilement au-delà du système initialement compromis.
• améliorer le confinement. Même si des pirates parviennent à compromettre le compte du système d'exploitation de SAP, les possibilités d'action qui en découlent doivent rester limitées à un périmètre strictement défini.

La combinaison du contrôle d'accès discrétionnaire (DAC), de l'extension SELinux du noyau Linux et du framework fapolicyd (File Access Policy Daemon) peut constituer une couche de sécurité supplémentaire au niveau du système d'exploitation et contribuer à atteindre ces objectifs.

Contrôle granulaire des accès

Si les contrôles d'accès discrétionnaires (Discretionary Access Controls) sont attribués avec soin selon le principe du moindre privilège, ils offrent une bonne protection de base, car les utilisateurs et les groupes ne peuvent accéder qu'aux répertoires et fichiers dont ils ont réellement besoin pour leur travail. Dans les environnements SAP, les administrateurs doivent accorder une attention particulière, lors de l’attribution des droits, aux systèmes de fichiers distribués, aux répertoires de transport, aux espaces de stockage de sauvegarde, aux scripts d’intégration et aux outils d’administration. Toutefois, si un attaquant agit dans le contexte de sécurité d’un compte de confiance, le système d’exploitation considère toutes ses actions comme légitimes. C’est là qu’interviennent SELinux et fapolicyd.

SELinux ajoute à Linux un contrôle d'accès obligatoire (MAC), dans lequel les accès sont autorisés ou refusés non pas en fonction de l'identité de l'utilisateur et de l'objet auquel il souhaite accéder, mais sur la base de politiques définies de manière centralisée. Cette approche permet un contrôle granulaire, car les règles permettent de définir précisément à quels fichiers un processus est autorisé à accéder, quelles connexions réseau il peut établir, quelles ressources il peut modifier et quelles interactions entre les composants du système il est autorisé à déclencher. Même si un attaquant prend le contrôle d’un processus SAP ou d’un compte du système d’exploitation, il n’obtient aucun droit d’accès aux ressources allant au-delà de celles définies dans les règles. Toute tentative est bloquée par le noyau et consignée sous la forme d’une entrée „ avc: denied “ dans /var/log/audit/audit.log ou /var/log/messages. Si nécessaire, ces journaux peuvent être intégrés à des systèmes SIEM et analysés de manière centralisée, ce qui permet de détecter de manière fiable les attaques en cours.

fapolicyd permet quant à lui de contrôler quels objets exécutables sont effectivement autorisés à s'exécuter – Linux lui-même impose relativement peu de restrictions à cet égard dès lors qu'un attaquant a pris le contrôle d'un compte disposant de droits suffisants. Au lieu d’une simple liste blanche, fapolicyd s’appuie sur des informations relatives à l’intégrité et à la fiabilité des fichiers, sur les métadonnées issues de la gestion des paquets et sur des règles définies par l’administrateur. Il est ainsi possible de spécifier que seuls les binaires provenant de dépôts approuvés, les logiciels SAP fiables et les applications explicitement autorisées peuvent être exécutés. En revanche, les fichiers exécutables provenant de sources inconnues ou douteuses sont bloqués, ce qui empêche les attaquants de lancer des scripts téléchargés, des outils de tunneling et d’autres outils de piratage.

Des ensembles de politiques prêtes à l'emploi pour une protection rapide

SELinux et fapolicyd font partie intégrante de nombreuses distributions Linux, dont Red Hat Enterprise Linux. D'autres distributions intègrent parfois des modules et des fonctionnalités similaires, comme AppArmor, ou peuvent être équipées de ces outils a posteriori.

Pour garantir une protection fiable dans les environnements SAP, SELinux et fapolicyd doivent être configurés. Dans le cadre du projet Ironroot, un ensemble de politiques a été développé pour Red Hat Enterprise Linux ; celui-ci peut être installé après la suppression des politiques existantes et des étiquettes de ressources. Ce pack définit alors de nouvelles étiquettes et améliore les règles d'accès à celles-ci, afin que, par exemple :

• l'administrateur ABAP ne peut plus accéder aux droits root via sudo, une faille dont les pirates tirent souvent parti pour se propager au sein de l'infrastructure.
• l'administrateur SAP ne peut plus utiliser de port réservé, ce dont les pirates profitent souvent pour exporter des données confidentielles.
• l'administrateur de la base de données HANA ne peut plus modifier les fichiers temporaires de l'administrateur ABAP, une faille dont les pirates tirent souvent parti pour injecter des commandes malveillantes.

Les entreprises peuvent bien sûr également définir leurs propres étiquettes et politiques pour SELinux et fapolicyd.

Il est important de considérer DAC, SELinux et fapolicyd comme une protection multicouche qui ne déploie pleinement son efficacité que grâce à l’interaction de ses différents composants, car les attaquants doivent contourner plusieurs mécanismes de sécurité pour accéder à des données sensibles, exécuter leur propre code ou infiltrer d’autres systèmes. Le DAC définit quels utilisateurs et groupes sont autorisés à accéder à certaines ressources. SELinux ajoute des règles qui restreignent le comportement des processus, même si les droits d’accès aux fichiers normaux autoriseraient ces activités. Enfin, fapolicyd régit de manière fondamentale quels logiciels sont autorisés à s’exécuter sur le système.

Vers l'inscription du partenaire :