Pentest en environnement SAP

Magazine
Marque
MISC
Numéro
72
|
Mois de parution
mars 2014
|
Domaines


Résumé
SAP est la solution d'ERP la plus utilisée parmi les grandes sociétés. Sa popularité la rend néanmoins plus sujette aux malwares ou aux attaques plus ciblées. L'objectif de cet article est de détailler comment certaines fonctionnalités ou vulnérabilités peuvent être exploitées. Quelques pistes de protection seront également présentées.

Body

1. Introduction

1.1 Objectifs

Avant d'entrer dans le vif du sujet, il est important de noter que cet article n'a pas pour but de présenter une méthodologie complète et exhaustive d'un test d'intrusion d'une plateforme SAP. Les objectifs sont en effet de présenter de manière simplifiée le fonctionnement de SAP, les principaux composants, ainsi que de détailler les principales vulnérabilités pouvant être exploitées lors d'un test d'intrusion.

1.2 Quelques notions

1.2.1 SAP

SAP est un ERP (Entreprise Resource Planning) permettant de gérer les différents flux d'une société (ressources humaines, ventes, approvisionnement, etc.) au travers de différents modules. Outre l'objectif de gestion des données, l'un des principaux principes est de favoriser le développement d’outils de manière modulaire via une base de données unique (Oracle, MaxDB, MSSQL, etc.).

1.2.2 Clients et utilisateurs

Lorsqu’un système SAP est installé, des « clients » (mandants), identifiés par un nombre de 000 à 999, sont créés par défaut et permettent l’isolation de différents corps de métier. Par exemple, des utilisateurs se connecteront à un client « 123 », pour la gestion des finances, et d’autres accéderont au client « 456 » pour gérer l’inventaire des stocks. Ces clients garantissent en outre une bonne étanchéité des comptes : un client ne pourra pas consulter des informations d'un autre client.

Des utilisateurs sont également créés et associés à certains clients dès l’installation de SAP et peuvent s’avérer dangereux puisque certains disposent de privilèges élevés. Le tableau ci-dessous en liste quelques-uns.

CLIENTS

UTILISATEUR

MOTS DE PASSE

PRIVILÈGES

000, 001,066

SAP*

06071992

6071992

PASS

Administrateur

000, 001

SAPCPIC

admin

Lecture/écriture de fichiers

Appels distants à des programmes ABAP

000, 001

DDIC

19920706

Administrateur

066

EARLYWATCH

SUPPORT

Fonctions de monitoring

000

TMSADM

PASSWORD

$1Pawd2&

Apports de modifications entre environnements SAP

L'utilisateur SAP* est particulier : il s'agit en effet d'un super-utilisateur créé sur chaque nouveau client et par défaut régénéré automatiquement dans certaines versions avec un mot de passe connu (« PASS »).

À noter cependant que le processus d'installation de SAP a été modifié depuis les versions de 2009-2010 : les utilisateurs DDIC et SAP* des clients 000 et 001 disposent en effet du mot de passe maître saisi lors de l'installation.

SAPRouter est l'un des composants de SAP dont la sécurité sera étudiée dans cet article. Situé au niveau de la couche applicative du modèle OSI et dépendant du protocole propriétaire « NI » (non étudié ici), il fait office de proxy entre un réseau externe et un système SAP. Son but principal est donc de rediriger les connexions autorisées vers certains hôtes.

Attention, il ne peut en aucun cas remplacer un pare-feu ; il le complémente au contraire. S'il est possible d'indiquer au client que ses paquets doivent transiter via un SAPRouter, il n'existe en revanche aucun moyen de l'y forcer. Un attaquant pourrait ainsi modifier sa configuration pour communiquer directement avec l'équipement visé. La présence d'un pare-feu frontal est donc indispensable.

Sa configuration s'effectue dans un fichier nommé « saprouttab », ou « Route Permission Table », contenant l'équivalent d'ACLs (Access Control List).

Sa syntaxe est donnée ci-dessous. Les lettres P, S et D indiquent que la connexion est soit : autorisée pour tout protocole (P), autorisée uniquement avec des protocoles SAP (S), ou refusée (D). Le nombre qui suit indique le nombre de SAPRouters maximal autorisé. La source et la destination peuvent être une adresse IP, un alias, etc. Enfin, il est à noter que le mot de passe devra être saisi lors d'une connexion d'une entité (utilisateur, serveur, SAPRouter, etc.) au SAPRouter en question et sera ainsi envoyé compressé lors d'une connexion à une instance. Cette compression est détaillée dans

P|S|D[0-9]* <source> <destination> <service> [<mot de passe>]

La mise en place d'une mauvaise configuration ou d'une configuration trop permissive permettrait à un attaquant de rebondir sur le réseau interne.

1.2.4 Gateway

Des instances SAP ou des programmes externes peuvent communiquer entre eux grâce à l'interface RFC et via la « Gateway » de SAP. Cette application permet l'exécution des fonctions appelées, mais aussi de restreindre l'accès à certains hôtes.

RFC (Remote Function Call) est le terme qui désigne les appels à des fonctions ou programmes développés en ABAP, langage propriétaire. Initialement, les appels ne peuvent se faire qu'au sein d'un même environnement SAP. L'interface RFC permet en revanche à ces appels d'être transmis à des systèmes externes.

Pour pouvoir être contacté, un serveur doit être enregistré auprès de cette Gateway. SAP propose pour cela deux modes : « started » et « registered ». Avec le premier, la passerelle est configurée statiquement : toutes les informations nécessaires à l'exécution d'un programme sont fournies au démarrage. Lorsqu'un serveur demande son exécution, la Gateway s'y connectera, réalisera l'action puis clôturera la connexion. Avec le second mode, un serveur peut lui-même s'enregistrer auprès de la passerelle.

Ce deuxième mode est intéressant puisque si les permissions d'enregistrement sont trop permissives, il est possible de réaliser certaines attaques.

2. Outillage

Quelques outils gratuits permettent de réaliser un test d'intrusion de SAP :

- Wireshark : compilé avec un plugin de dissection [WIRESHARK], il facilite l'analyse des paquets transmis via les protocoles propriétaires de SAP ;

- Cain&Abel : cet outil est notamment utile pour obtenir des identifiants lorsque le protocole DIAG, présenté dans la suite de l'article, est utilisé.

- Bizploit [BIZPLOIT] : anciennement Sapyto, il s'agit dune panoplie d'outils permettant de réaliser de nombreux tests (collecte d'informations, découvertes de vulnérabilités et exploitation, recommandations associées) ;

- Metasploit : les modules de la partie « auxiliary/sap » permettent d'effectuer des tests similaires à ceux de Bizploit ;

- SAP Pentesting Tool [ERPSCAN] est un ensemble de scripts Perl permettant de conduire un test d'intrusion en mode boîte noire.

3. Mots de passe

3.1. Interception

SAPGUI est un client lourd pouvant être utilisé par un utilisateur afin de se connecter à une instance SAP. Ces deux interlocuteurs vont dialoguer entre eux via le protocole DIAG (Dynamic Information and Action Gateway), qui a été défini et implémenté par la société SAP AG.

Ce protocole possède une spécificité : les données sont compressées. Aucun chiffrement n'est donc effectué par défaut et la « sécurité » d'un tel protocole repose sur l'absence de documentation. Ces données transitent ainsi en clair sur le réseau et peuvent être interceptées et décompressées par des outils tels que Wireshark ou Cain&Abel. La figure 1 est un exemple d’identifiants obtenus avec Wireshark : l'utilisateur « EARLYWATCH » s'est connecté au client « 066 » avec le mot de passe « SUPPORT ».

wireshark

Fig. 1 : Exemple de capture d'identifiants.

Pour se prémunir d'une telle divulgation, la recommandation est classique : ajouter une couche de chiffrement. SAP propose en effet l'interface SNC (Secure Network Communications) offrant authentification, intégrité et confidentialité. Il repose sur un protocole propriétaire, mais son principe est similaire à SSL puisqu'elle repose sur l'utilisation de certificats.

Pour de plus amples informations sur SNC et sa configuration, le lecteur est invité à consulter [SNC].

3.2. Rétrocompatibilité

3.2.1. Introduction

Au fil de son développement, SAP a modifié son mécanisme de stockage des mots de passe. Plusieurs versions ont ainsi été développées, chacune utilisant des algorithmes différents. Le tableau ci-dessous recense l'ensemble des algorithmes utilisés par SAP.

Version

Description

A

Algorithme propriétaire, de nombreuses collisions

B

MD5, tronqué à 8 caractères, insensible à la casse, ASCII

D

MD5, tronqué à 8 caractères, insensible à la casse, UTF-8

E

Version améliorée de D

F

SHA-1, 40 caractères, sensible à la casse, UTF-8

G

Versions B (MD5) et F (SHA-1)

H

SHA-1, mot de passe salé aléatoirement

I

Versions B (MD5) , F (SHA-1) et H (SHA-1)

Certains modules SAP peuvent nécessiter une empreinte de mot de passe MD5 tandis que certains vont requérir une empreinte SHA-1. Pour garantir la maintenabilité de tels modules au sein d'un même environnement, SAP dispose d'un système de rétrocompatibilité des mots de passe. C'est pour cette raison que les versions G et I sont décrites comme correspondant à d'autres versions : plusieurs empreintes sont stockées. Ainsi, pour la version I, utilisée par défaut, les algorithmes MD5 et SHA-1 seront utilisés.

3.2.2. Exploitation

La divulgation des empreintes a principalement lieu lors d'un accès à la base de données. Dans ce contexte, la rétrocompatibilité pose un problème : le niveau de sécurité des empreintes - et par conséquent le risque de compromission du mot de passe lui-même - correspond à celui de l'algorithme le plus faible, ici MD5.

Comme l'indique le tableau précédent, le mot de passe est tronqué à huit caractères avec la version B. Si sa longueur initiale y est inférieure ou égale, il suffit de casser cette empreinte MD5 pour rendre caduc l'emploi de SHA-1. Sinon, si la chaîne dépasse cette limite, il est possible de retrouver plus facilement le mot de passe haché en SHA-1 : les huit premiers caractères obtenus après cassage du MD5 peuvent constituer le préfixe pour la génération d'un nouveau dictionnaire.

En réalité, les mots de passe utilisateur sont rarement beaucoup plus longs ; extraire cette première partie revient donc à obtenir la quasi-totalité du mot de passe recherché.

La société Onapsis a publié un article [ONAPSIS] détaillant la méthode à suivre pour ce cas. Sa lecture est recommandée.

3.2.3. Quelles protections ?

Si la société auditée n'a pas de contrainte de rétrocompatibilité à assurer, le mécanisme offert par SAP devrait simplement être désactivé en fixant la valeur du paramètre login/password_downwards_compatibility à 0, via la transaction RZ11.

Les transactions sont des programmes ABAP ayant une fonction bien précise. Par exemple, la transaction RZ11 a pour objectif de gérer des paramètres SAP et SE16 de consulter ou modifier des tables de la base de données.

Les recommandations habituelles applicables aux mots de passe et aux bases de données restent bien entendu applicables :

- Définition et application d'une politique de mot de passe complexe. SAP propose des paramètres, tels que login/min_password_lng, login/min_password_letters, login/min_password_specials ou login/min_password_diff [LOGIN].

- Restriction d'accès aux tables USR02, USH02 et USRPWDHISTORY de la base de données. Ces tables contiennent respectivement les identifiants, les notifications de changement d'état de compte et les précédents mots de passe utilisés. Cette contrainte peut se faire en créant un profil d'autorisation dédié : en l'attribuant à ces tables, seuls les utilisateurs la possédant seront en mesure de les consulter.

- Restriction d'accès au listener de la base de données.

4. Défauts de configuration

4.1. SAPRouter

Comme évoqué lors de l'introduction, un client peut être configuré afin de transiter par un SAPRouter. Il est à noter que le fichier de configuration peut contenir des wildcards ; la figure 2 donne un exemple de règle très permissive.

saprouttab

Fig. 2 : Exemple de configuration permissive.

Une telle configuration peut paraître irréaliste tant le risque est évident, mais elle n'en reste pas moins possible et est typique d'une plateforme de test.

4.1.1 Divulgation de données

Le risque de cette configuration est donc la connexion à l'infrastructure SAP depuis un réseau quelconque (scénarios de vol de portable, attaque externe, etc.). Un accès au SAPRouter lui-même serait ainsi possible, permettant l'extraction de données sensibles :

- informations système ;

- connexions actives (clients, adresses IP, etc.).

Bizploit (plugins/discovery/getSaprouterInfo) et Metasploit (auxiliary/scanner/sap/sap_router_info_request) disposent d'un module permettant l'exploitation d'une telle vulnérabilité. La capture ci-dessous est un exemple de données extractibles :

- le système sous-jacent est un Windows ;

- un client (192.168.56.1) est connecté à une instance SAP (192.168.56.101) via un client lourd (sapdp00 ou port 3200).

msf_router_info

Fig. 3 : Exemple d'exploitation

Ce dernier cas permet également de se faire une idée de l'adressage interne, et d'exploiter le SAPRouter comme proxy pour, par exemple, scanner le réseau. C'est ce que détaille la section suivante.

4.1.2 Redirections de trafic

Pour rappel, le rôle d'un SAPRouter est assimilable à celui d'un proxy : si la connexion est autorisée, le trafic est transmis au destinataire, quelle que soit sa nature. Plus généralement, si la redirection de services est autorisée, il devient possible d'utiliser le SAPRouter comme proxy pour attaquer le réseau : scan de ports, recherche de vulnérabilités, exploitation, etc.

Attention, ces attaques ne restent pas toujours aisément réalisables : une route peut être constituée d’une chaîne de SAPRouters et, dans les dernières versions, le dernier SAPRouter refuse toute connexion à un service non-SAP (ex. : SSH, Telnet) si un wildcard est utilisé. Ainsi, avec la configuration précédente (Fig. 2), seuls les accès à des services SAP seraient autorisés.

Avec Metasploit, ces attaques peuvent être mises en place simplement en spécifiant un proxy via la commande ci-dessous. À noter néanmoins que certains modules ne prennent pas en compte cette variable.

msf > set Proxies sapni:192.168.56.101:3299

4.2. Gateway

4.2.1 Register mode

Comme évoqué précédemment, la Gateway permet à des applications externes de communiquer avec une instance SAP par le biais de l'interface RFC. Pour cela, les serveurs ont la possibilité de s'enregistrer auprès de la Gateway en fournissant un identifiant de programme (ID ou tpname) ; lorsqu'un client demandera son exécution, le serveur sera automatiquement contacté.

Même si cette méthode peut paraître pratique (l'ajout de serveurs est dynamique), elle peut poser de graves problèmes si la configuration sous-jacente est trop permissive. Il est en effet possible de fournir un identifiant déjà existant lors de l'enregistrement. Dans un tel cas, la passerelle se comportera comme un loadbalancer.

4.2.2 Attaque Evil Twin

À partir de ces informations, il est légitime de s'imaginer mettre en place une attaque de type Evil Twin. Un attaquant pourrait effectivement s'enregistrer auprès de la passerelle, puis causer un déni de service sur le serveur usurpé. En réalité, l'attaque peut être plus subtile sur certains systèmes vulnérables.

Une fonction RFC (RFC_SET_REG_SERVER_PROPERTY) permet de modifier les caractéristiques d'un serveur. Sa fonctionnalité pourrait cependant être détournée pour forcer l'utilisation de connexions exclusives [VULN]. Tant qu'une action avec un client n'était pas terminée, le serveur n'acceptait pas d'autres requêtes.

Si tout serveur est autorisé à s'enregistrer et si le serveur à usurper est vulnérable à l'attaque précédente, il est possible d'intercepter l'ensemble des données qui lui sont initialement destinées. L'outil Bizploit permet de mettre en place une telle attaque via les modules exploits/eviltwin et exploit/stick : le premier s'enregistre auprès de la Gateway avec un ID à usurper, tandis que le second empêche l'établissement de nouvelles connexions vers le serveur légitime.

Au final, cette attaque peut conduire à la divulgation de nombreuses informations critiques : identifiants, fichiers confidentiels, etc.

4.2.3 Attaque par callback

De base, les appels RFC aux serveurs sont unidirectionnels : une requête est envoyée, puis une réponse reçue. Il existe néanmoins une extension : à la fin du traitement de la requête initiale, le serveur de destination a la possibilité de demander l'exécution d'une fonction sur le serveur émetteur, si les droits de l'utilisateur sur ce dernier le lui permettent.

L'attaque précédente peut ainsi être améliorée : outre la divulgation d'informations, il devient possible de se créer un accès (ex. shell) et d'exécuter des commandes sur le système émetteur.

4.2.4 Protections

Ces attaques peuvent être aisément évitées. Une première étape consiste à systématiquement appliquer les « Notes SAP » et à installer les correctifs de sécurité. Le détournement de la fonction RFC_SET_REG_SERVER_PROPERTY ne serait ainsi plus possible, limitant ainsi le risque de déni de service sur le serveur usurpé.

La configuration de la Gateway permet plus généralement d'éviter l'enregistrement de serveurs malveillants et de n'autoriser que quelques serveurs à exécuter les programmes enregistrés. Pour plus de détails techniques, le lecteur est invité à consulter [CONFGW].

5. Vulnérabilités SAP

L'objectif de cette partie est de souligner l'importance des mises à jour de sécurité. C'est pourquoi quelques vulnérabilités affectant un composant SAP vont être présentées : elles permettent d'obtenir des informations système et de compromettre une plateforme SAP. Les défauts de configuration ne sont ainsi pas les seuls vecteurs d'attaque.

La première vulnérabilité est due à un défaut d'autorisation sur le composant SAPHostControl, webservice permettant la gestion d'une instance SAP. Un appel SOAP peut en effet être spécialement forgé pour obtenir des informations systèmes : adresse IP, système d'exploitation, noms d'utilisateur, etc. Cette vulnérabilité peut être exploitée avec Metasploit (auxiliary/scanner/sap/sap_hostctrl_getcomputersystem).

msf_hostcontrol

Fig. 4 : msf_hostcontrol.png.

La seconde vulnérabilité est liée à un autre rôle de SAPHostControl : l'authentification d'utilisateurs auprès de la base de données. Lors de cette phase, différents paramètres lui sont transmis, mais aucune validation des entrées utilisateur n'est effectuée. Il devient alors possible d'injecter des données dans chacun de ces paramètres. Comme l'explique très bien l'article [HOSTCTRL], l'exécution anonyme de commandes système devient possible. Metasploit (exploit/windows/http/sap_host_control_cmd_exec) et l'outil « SAP Pentest tool » (module 32) permettent d'exploiter cette vulnérabilité.

Conclusion

Par le passé, de nombreuses vulnérabilités et configurations par défaut permettaient une compromission quasi-instantanée d'une plateforme SAP. Aujourd'hui, même si les protocoles sur lesquels repose SAP restent fermés, des efforts ont été réalisés en matière de sécurité : SAP AG fournit des guides de sécurité, peu de mots de passe par défaut sont disponibles post-installation, des patches de sécurité sont régulièrement publiés, etc.

Ces apports ne sont en revanche pas suffisants : il est encore fréquent de constater de mauvaises configurations (SAPRouter et Gateway notamment) et même si SAP propose des transactions permettant, par exemple, d'effectuer un état des lieux des mots de passe utilisateur (SA38/RSUSR003), encore faut-il les utiliser...

Il est également nécessaire de s'assurer de la bonne application des mises à jour de sécurité. La divulgation d'une ancienne vulnérabilité affectant NVIDIA, via son application NVCare, en est un parfait exemple [NVIDIA].

Remerciements

Je tiens à remercier Guillaume Lopes pour m'avoir guidé lors de la rédaction de cet article.

Les travaux d'Onapsis et d'ERPScan m'ont également été d'une grande aide, qu'il s'agisse de leurs outils, de leurs talks aux différentes conférences de sécurité ou de leurs whitepapers.

Merci également à Benjamin Caillat et Jean-Philippe Luiggi pour leur relecture attentive.

Références

[SNC] http://help.sap.com/saphelp_nw73ehp1/helpdata/en/5f/0f558b8a7841049139f0fb558ac62c/content.htm

[WIRESHARK] http://corelabs.coresecurity.com/index.php?module=Wiki&action=view&type=tool&name=SAP_Dissection_plu-gin_for_Wireshark

[BIZPLOIT] http://www.onapsis.com/research-free-solutions.php

[ERPSCAN] http://erpscan.com/products/erpscan-pentesting-tool/

[ONAPSIS] http://blog.onapsis.com/checking-sap-password-strength-abap/

[LOGIN] http://service.sap.com/sap/support/notes/2467

[VULN] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1918

[CONFGW] http://help.sap.com/saphelp_nw04/helpdata/en/bb/9f135a4b9b11d189750000e8322d00/content.htm

[HOSTCTRL] http://www.contextis.com/research/blog/sap-parameter-injection-no-space-arguments

[NVIDIA] http://en.wooyun.org/bugs/wooyun-2013-041


Sur le même sujet

Introduction à Zero Trust 

Magazine
Marque
MISC
Numéro
110
|
Mois de parution
juillet 2020
|
Domaines
Résumé

La sécurité informatique adore les modes. Le « Zero Trust » fait partie de ces concepts qui sont devenus populaires du jour au lendemain. Et comme le sexe chez les adolescents, « tout le monde en parle, personne ne sait réellement comment le faire, tout le monde pense que tous les autres le font, alors tout le monde prétend le faire* ».

Pré-authentification Kerberos : de la découverte à l’exploitation offensive

Magazine
Marque
MISC
Numéro
110
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Les opérations relatives à l’authentification Kerberos ne sont pas toujours remontées dans les journaux des contrôleurs de domaine, ce qui fait de ce protocole une arme de choix pour mener des attaques furtives en environnement Active Directory. Le mécanisme de pré-authentification de ce protocole offre par exemple des possibilités intéressantes pour attaquer les comptes d’un domaine.

Les enjeux de sécurité autour d’Ethernet

Magazine
Marque
MISC
HS n°
Numéro
21
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Quand nous parlons attaque, cela nous évoque souvent exploit, faille logicielle, ou même déni de service distribué. Nous allons revenir à des fondamentaux réseaux assez bas niveau, juste après le monde physique, pour se rendre compte qu’il existe bel et bien des vulnérabilités facilement exploitables par un attaquant. Nous verrons également qu’il existe des solutions pour s’en protéger.

Implémentation d’une architecture processeur non supportée sur IDA PRO et Ghidra

Magazine
Marque
MISC
HS n°
Numéro
21
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Malgré le nombre d’outils aidant au désassemblage voire à la décompilation de programmes, il arrive parfois que les mécanismes ou les processeurs étudiés ne soient pas nativement supportés. Pour cette raison, certains outils proposent des API permettant d’implémenter une nouvelle architecture. Cet article détaillera les grandes étapes de ce travail pour deux outils majoritairement utilisés, à savoir IDA PRO et Ghidra.

Contrôles de suivi de la conformité RGPD et d’atteinte d’objectifs définis dans la politique de protection de la vie privée

Magazine
Marque
MISC
Numéro
110
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Afin de mettre en application les exigences de contrôle de conformité (article 24 du RGPD), les directions générales, qu’elles aient désigné ou non un Délégué à Protection des Données (DPD), doivent mettre en œuvre des contrôles concernant les répartitions de responsabilités entre les acteurs impliqués par le traitement et l’application de règles opposables, l’effectivité des droits des personnes concernées, la sécurité des traitements et la mise à disposition des éléments de preuve pour démontrer la conformité des traitements de données à caractère personnel.

Par le même auteur

Pentest en environnement SAP

Magazine
Marque
MISC
Numéro
72
|
Mois de parution
mars 2014
|
Domaines
Résumé
SAP est la solution d'ERP la plus utilisée parmi les grandes sociétés. Sa popularité la rend néanmoins plus sujette aux malwares ou aux attaques plus ciblées. L'objectif de cet article est de détailler comment certaines fonctionnalités ou vulnérabilités peuvent être exploitées. Quelques pistes de protection seront également présentées.