RFC est l’un des mécanismes d’exécution les plus puissants des environnements SAP, mais aussi l’un des moins monitorés. Un utilisateur authentifié via une connexion RFC et disposant de l’autorisation S_RFC peut appeler des modules de fonction capables de lire pratiquement n’importe quelle table de base de données, créer ou modifier des comptes utilisateurs, changer la configuration du système ou encore exécuter des transactions. Autant d’actions qui n’apparaissent pas nécessairement dans les outils de monitoring des processus métier utilisés au quotidien par les équipes SAP.
Les contrôles d’autorisation intégrés à chaque module de fonction varient considérablement. Certains sont rigoureux. D’autres beaucoup moins. Et certains modules de fonction bien connus n’effectuent pratiquement aucun contrôle d’autorisation significatif lorsqu’ils sont appelés via RFC. C’est notamment pour cette raison que les attaques basées sur RFC constituent un vecteur d’attaque documenté, régulièrement utilisé lors de tests d’intrusion SAP et observé dans des compromissions réelles.
Cet article explique à quoi ressemble concrètement une activité RFC non autorisée, où trouver les signaux permettant de la détecter et ce qu’implique un véritable monitoring en temps réel.
Pourquoi la surface d’attaque RFC est plus large qu’on ne le pense
Ce qu’un appel de fonction à distance peut réellement faire
RFC_READ_TABLE est l’exemple le plus souvent cité, car il illustre clairement le problème. Ce module de fonction est compatible RFC, largement connu et conçu à l’origine pour des scénarios légitimes d’échange de données. Il reçoit un nom de table et des critères de sélection, puis renvoie le contenu correspondant.
Le contrôle d’autorisation utilisé repose sur S_TABU_DIS, qui gère l’accès aux tables par groupes d’autorisation. Dans la pratique, de nombreuses implémentations SAP disposent d’autorisations S_TABU_DIS trop larges, notamment parce que la maintenance de groupes d’autorisation de tables très granulaires est complexe et qu’elle a rarement été appliquée de manière stricte lors du déploiement initial.
Un attaquant qui s’authentifie via RFC avec un utilisateur technique disposant de S_RFC et d’un périmètre S_TABU_DIS suffisamment large peut ainsi extraire USR02 (hashs de mots de passe), UST04 (affectation des utilisateurs aux profils), AGR_USERS (affectation des rôles) ou RSECTAB (configuration de sécurité) au moyen d’une série d’appels RFC_READ_TABLE.
Cette extraction ne nécessite aucun accès à SAP GUI, laisse très peu de traces dans les logs standards si le Security Audit Log n’est pas correctement configuré et peut être automatisée en quelques minutes.
RFC ne permet pas seulement d’extraire des données : il permet également d’exécuter des actions. BAPI_USER_CREATE1 peut créer des utilisateurs SAP lorsque l’appelant dispose des autorisations nécessaires. SUSR_USER_CHANGE_PASSWORD_RFC permet de modifier des mots de passe. SXPG_COMMAND_EXECUTE peut lancer des commandes au niveau du système d’exploitation si l’utilisateur possède l’autorisation S_RZL_ADM.
Ces modules de fonction ont tous des usages parfaitement légitimes dans des scénarios d’intégration. Mais associés à un compte compromis ou disposant de privilèges excessifs, ils transforment RFC en véritable mécanisme d’exécution à distance.
Le manque de contrôle spécifique aux appels RFC
Le modèle d’autorisation SAP a été conçu avant tout pour des utilisateurs dialog naviguant dans des menus et des codes transaction. Lorsqu’un appel arrive via RFC, les contrôles exécutés dépendent entièrement de ce que le développeur du module de fonction a implémenté. Il n’existe pas de couche d’autorisation RFC qui appliquerait automatiquement les mêmes contrôles qu’une transaction équivalente.
L’objet d’autorisation S_RFC détermine les groupes de fonctions et modules de fonction qu’un utilisateur ou un rôle peut appeler à distance. Mais dans la pratique, S_RFC est généralement attribué au niveau du groupe de fonctions plutôt qu’au niveau de chaque module.
Accorder l’accès au groupe de fonctions SDTX pour permettre l’utilisation d’un seul module peut donc également ouvrir l’accès aux autres modules RFC de ce groupe. Dans de nombreux environnements SAP, les profils RFC sont par conséquent plus permissifs que nécessaire, car les restreindre précisément exige de connaître la composition exacte de chaque groupe de fonctions et de maintenir cette configuration dans le temps.
À surveiller : le profil d’autorisation SAP RFC_NO_AUTHORITY accorde un accès RFC illimité à tous les modules et groupes de fonctions. Il est parfois attribué à des comptes de service ou à des utilisateurs techniques RFC lors d’un projet afin de contourner des problèmes rencontrés pendant les tests de connexion. Sa présence doit être considérée comme un constat critique lors de tout audit d’autorisations. Un compte disposant de RFC_NO_AUTHORITY peut appeler n’importe quel module compatible RFC du système et contourne ainsi entièrement la couche d’autorisation S_RFC.
À quoi ressemble une activité RFC non autorisée
Reconnaissance : lectures de tables et tests d’autorisations
Un attaquant qui explore un système SAP via RFC suit généralement une séquence assez reconnaissable.
Les premiers appels servent à déterminer ce qui est accessible : RFC_READ_TABLE avec des noms de tables courants pour tester le périmètre d’autorisation, des modules de fonction issus des groupes SYST et SYSTEM afin d’obtenir des informations sur le système, puis des appels vers des fonctions d’administration des utilisateurs afin de déterminer quelles opérations sont disponibles.
Lorsque ces appels sont refusés, ils peuvent générer des messages d’échec d’autorisation RFC dans les logs système. Lorsqu’ils réussissent, ils peuvent au contraire ne laisser quasiment aucun signal visible.
Ce qui distingue une reconnaissance d’un usage légitime est principalement la combinaison de la diversité des appels et de leur fréquence.
Une intégration RFC légitime appelle généralement le même ensemble de modules de fonction de manière récurrente, selon un comportement prévisible. Une phase de reconnaissance appelle au contraire de nombreux modules différents sur une courte période, souvent depuis un système source ou une adresse IP qui ne correspond à aucune intégration connue.
La variété des modules de fonction appelés et l’absence de destination RFC correspondante dans SM59 sont deux des meilleurs indicateurs permettant de distinguer un comportement offensif d’un trafic d’intégration normal.
Élévation de privilèges et persistance via RFC
Une fois les modules accessibles identifiés, la voie vers l’élévation de privilèges peut être très directe.
Si BAPI_USER_CREATE1 est accessible, l’attaquant peut créer un nouvel utilisateur avec un mot de passe connu. Si SUSR_USER_CHANGE_PASSWORD_RFC est accessible sur un compte disposant de privilèges élevés, il peut réinitialiser son mot de passe. Et si les relations de confiance entre systèmes autorisent une connexion RFC de confiance depuis le système compromis, l’attaquant peut exploiter cette relation pour accéder aux systèmes connectés sans nouvelle authentification.
Les connexions RFC de confiance méritent une attention particulière.
Lorsqu’un système est défini comme système de confiance dans SM59 et que la relation correspondante est configurée, les utilisateurs du système source peuvent se connecter au système cible sans fournir de mot de passe, uniquement à partir de leur identifiant utilisateur.
Si un système source de confiance est compromis, l’attaquant peut donc se connecter au système cible avec l’identité de n’importe quel utilisateur existant, y compris un administrateur, sans connaître ses identifiants.
L’événement d’authentification paraît parfaitement légitime puisque le mécanisme de connexion l’est lui aussi. L’anomalie se situe alors dans l’utilisateur utilisé et dans le système à l’origine de l’appel.
Où se trouvent les données de monitoring
Security Audit Log : les événements à monitorer
Le SAP Security Audit Log, accessible via la transaction SM20 ou RSAU_READ_AUD_LOG sur les systèmes plus récents, enregistre les événements liés à la sécurité, notamment certaines activités RFC.
Pour le monitoring de la sécurité RFC, les classes d’événements les plus importantes sont AU5, qui couvre les appels de modules de fonction RFC pour les événements activés dans le journal d’audit, ainsi que les événements d’échec d’autorisation de la classe AUB.
Plus précisément, le type de message AUB avec le sous-type AUB0003 enregistre les contrôles d’autorisation RFC ayant échoué. Ces événements correspondent notamment aux appels refusés lorsqu’un attaquant cherche à identifier les modules de fonction auxquels il peut accéder.
Le Security Audit Log n’est pas nécessairement actif par défaut sur tous les systèmes. Il doit être configuré explicitement dans SM19, notamment en définissant les mandants audités, les classes d’événements à enregistrer et les utilisateurs concernés.
Dans de nombreux systèmes SAP de production, cette configuration est incomplète : les événements de connexion dialog sont enregistrés, mais pas les événements RFC, ou bien seuls certains utilisateurs RFC sont audités.
Avant même de mettre en place le monitoring, il est donc essentiel de vérifier que les classes d’événements RFC pertinentes sont activées pour l’ensemble des utilisateurs du mandant de production.
SM21 et les échecs d’autorisation RFC comme signaux précoces
Le journal système SM21 enregistre les échecs d’autorisation dans la classe de messages UC. Lorsqu’un appel RFC échoue parce que l’utilisateur ne dispose pas de l’autorisation S_RFC nécessaire, un message UC est généré avec le nom du module de fonction et l’utilisateur à l’origine de l’appel.
Ces messages UC constituent en quelque sorte le journal des tentatives : ils révèlent les modules qu’un attaquant ou qu’un système mal configuré a tenté d’appeler sans en avoir l’autorisation.
Une série d’échecs d’autorisation UC provenant du même utilisateur ou de la même destination RFC, et visant plusieurs modules de fonction différents dans une courte période, constitue l’un des signaux temps réel les plus clairs d’une phase active de reconnaissance RFC.
Dans un système de production fonctionnant normalement, les échecs d’autorisation RFC sont relativement rares. Un système générant des dizaines d’échecs S_RFC par minute depuis une même source doit donc être considéré comme potentiellement soumis à une tentative de reconnaissance active.
Le problème est que SM21 est avant tout un outil d’analyse historique, pas un mécanisme d’alerte.
Les données existent, mais pour les exploiter efficacement, il faut soit une plateforme de monitoring capable de lire SM21 et de générer des alertes quasiment en temps réel, soit un administrateur consultant le journal suffisamment souvent pour détecter l’attaque pendant qu’elle est encore en cours.
À noter : lorsque le SAP Security Audit Log est configuré pour écrire ses données dans une table de base de données plutôt que dans un fichier, les performances des requêtes peuvent se dégrader à mesure que la table grossit au fil des mois. Pour limiter cette croissance, certains administrateurs réduisent alors le périmètre d’audit, parfois au détriment des événements RFC. Il est important de vérifier dans SM19 que la configuration actuelle correspond bien au niveau de monitoring réellement attendu.
Ce qu’exige un monitoring de sécurité RFC en temps réel
Le Security Audit Log et SM21 contiennent tous deux les bonnes données. Leur principale limite est qu’ils sont généralement consultés après les faits.
Une plateforme de monitoring qui interroge ces sources toutes les quelques minutes peut réduire le délai de détection de plusieurs heures à quelques minutes. Mais les attaques RFC peuvent être bien plus rapides.
L’extraction de USR02 via RFC_READ_TABLE avec des outils automatisés peut prendre moins d’une minute. Un cycle de détection basé sur plusieurs minutes identifie donc l’incident lorsque l’extraction est potentiellement déjà terminée.
Une détection réellement temps réel nécessite une collecte continue des événements du Security Audit Log à des intervalles inférieurs à une minute, associée à des règles capables d’identifier des comportements révélateurs d’une activité non autorisée plutôt que de simplement réagir à chaque événement isolé.
Parmi les scénarios qui doivent entraîner une réaction immédiate :
- plus de trois échecs d’autorisation S_RFC en 60 secondes depuis un même utilisateur ou une même adresse IP ;
- tout appel réussi à un module de gestion des utilisateurs tel que BAPI_USER_CREATE1 ou SUSR_USER_CHANGE_PASSWORD_RFC depuis une source absente de la liste des systèmes d’intégration autorisés ;
- toute session RFC provenant d’une adresse IP qui ne correspond à aucune destination SM59 connue ;
- toute connexion RFC de confiance depuis un système source à des horaires où aucune activité d’intégration légitime n’est attendue.
La différence entre une alerte basée sur un comportement et une alerte basée uniquement sur un seuil est essentielle.
Une alerte de seuil peut, par exemple, se déclencher lorsque le nombre d’erreurs RFC dépasse 50 par heure. Elle ne détectera pas nécessairement une attaque ciblée composée de 12 appels parfaitement choisis vers des modules sensibles, tous réussis, effectués depuis un compte compromis.
Une alerte basée sur les comportements, qui monitore par exemple les appels vers des fonctions d’administration des utilisateurs depuis des sources inhabituelles, peut quant à elle se déclencher dès le deuxième appel, que les opérations précédentes aient réussi ou non.
La liste des destinations SM59 constitue ici la référence de base.
Toute source RFC apparaissant dans le Security Audit Log devrait correspondre à une destination RFC configurée et documentée. Un appel provenant d’une source extérieure à cette référence constitue par définition une anomalie et mérite une analyse immédiate, même si aucune erreur d’autorisation n’a été générée.
La sécurité RFC n’est pas un problème de configuration que l’on règle une fois pour toutes.
La surface d’attaque dépend de l’intersection entre les modules de fonction compatibles RFC, les utilisateurs disposant d’autorisations S_RFC et leur périmètre, ainsi que les systèmes externes disposant d’un accès réseau à la passerelle SAP.
Ces trois dimensions évoluent en permanence. De nouvelles intégrations ajoutent de nouvelles sources RFC. Les profils d’autorisation dérivent avec le temps. Des systèmes sont ajoutés à des relations de confiance sans que toutes les implications soient nécessairement documentées.
Un monitoring capable de collecter les événements RFC, d’identifier les comportements anormaux quasiment en temps réel et d’alerter sur les écarts par rapport au trafic d’intégration habituel permet de transformer la couche RFC : d’un mécanisme d’exécution opaque, elle devient un environnement monitoré et auditable.
Les données sont déjà disponibles. La vraie question est de savoir si quelqu’un les analyse à la vitesse qu’exige le niveau de risque.
Redpeaks monitore en temps réel les événements du SAP Security Audit Log et les échecs d’autorisation présents dans les logs système, avec des règles d’alerte spécifiques à RFC permettant notamment de détecter les phases de reconnaissance et les appels inattendus vers des modules de gestion des utilisateurs.
