Importance de la passerelle SAP pour la sécurité

Les attaques possibles contre les systèmes SAP sont illustrées ci-après à l'aide de fichiers ACL Reginfo et Secinfo non sécurisés. Il ne s'agit pas d'un guide pour attaquer les systèmes SAP. Il s'agit simplement d'attirer l'attention sur l'importance de la sécurité de la passerelle RFC pour la sécurisation des systèmes.

Attaque sur des systèmes dont le fichier ACL Reginfo n'est pas sécurisé : Supposons que notre administrateur SAP Basis ait configuré le fichier ACL Reginfo de manière non sécurisée. Cela peut se faire par exemple par l'une des configurations suivantes : gw/acl_mode = 0 et le fichier Reginfo n'existe pas ; gw/sim_mode = 1 (ce qui supprime la ligne "Deny all" implicite).

Il existe un danger en cas d'attaques de systèmes pour lesquels une entrée Allow trop ouverte est enregistrée dans Reginfo. Dans ce cas, un attaquant peut enregistrer n'importe quel programme auprès de la passerelle. Il pourrait choisir la configuration suivante pour une attaque : ./programm -a IGS. -g -x sapgw.

Attaque par callback RFC

Le nom TP indiqué est IGS.. Le pirate se fait passer pour Internet Graphics Service (IGS). Le programme IGS. est appelé dès que l'IGS est utilisé par un utilisateur. 

Un attaquant pourrait profiter de ce comportement pour effectuer une attaque RFC callback. Si le serveur enregistré (et donc le bloc fonctionnel implémenté) est appelé, il existe automatiquement un handle de connexion. Avec ce handle de liaison, l'attaquant peut appeler n'importe quel autre bloc dans l'abap. Dans la pratique, un attaquant créerait par exemple un utilisateur et lui attribuerait SAP_ALL (ou des autorisations comparables). Cet exemple exploite donc deux points faibles d'un système SAP, qui sont tous deux fréquemment rencontrés dans la pratique. Une ACL Reginfo bien configurée empêcherait cette attaque, tout comme une sécurité de rappel RFC correctement configurée.

Attaque sur des systèmes avec une ACL Secinfo non sécurisée : les attaques sur une ACL Secinfo sont encore plus faciles à réaliser pour un attaquant en cas de configuration non sécurisée. Les exigences pour une attaque sont très similaires à celles de Reginfo. Les paramètres de profil gw/acl_mode = 0 (avec fichier secinfo manquant), gw/sim_mode = 1 ou une entrée Allow trop ouverte pour un système d'attaquant peuvent avoir pour conséquence qu'une attaque sur le système est possible.

Une preuve de concept a déjà été réalisée par Dmitry Chastuhin (https://github.com/chipik/SAP_GW_RCE_exploit). Dans ce cas, n'importe quelle commande du système d'exploitation peut être exécutée sur le système attaqué. L'attaquant peut également réaliser la même chose avec un système SAP normal (en tant que système attaquant). Dans ce cas, une connexion RFC de type T est établie avec le système attaqué à l'aide du programme sapxpg. Ensuite, une commande OS externe est créée dans SM49. Cette commande est exécutée avec la connexion RFC de type T sur le système attaqué. Comme ces réglages ou commandes ont lieu sur le système de l'attaquant, les contrôles d'autorisation ne sont pas pertinents. Outre une bonne segmentation du réseau, seule une bonne configuration de Secinfo offre une protection.

Configuration correcte de Reginfo et Secinfo : la question est de savoir comment configurer Reginfo et Secinfo de manière sûre, sans que cela n'entraîne de restriction du système SAP. La note SAP 1408081 fournit une bonne structure de base à cet effet. Ces paramètres de base peuvent ensuite être étendus par l'analyse des protocoles, le cas échéant en combinaison avec le mode simulation. On parvient ainsi à ce que Reginfo et Secinfo soient configurés correctement de manière relativement simple.

claranet.de