Après le SSTIC, on enchaîne avec le HITB à Amsterdam et cette fois, je vais essayer de tenir le rythme pendant les quatre jours pour mettre à jour mon blog quotidiennement. Inscrit à la formation SAP Security, je vais en profiter pour vous donner un aperçu ces deux premiers jours. Plus tard, il me restera à vous donner un exemple pratique ;)
SAP, c'est un ERP utilisé par pas mal d'entreprise car en gros, ça permet de gérer sa production de bout en bout. Par contre, c'est lourd à mettre en place et la sécurité est rarement la priorité des intégrateurs. Rien de nouveau, c'est souvent comme ça. Mais ça veut juste dire aussi qu'il y a moyen de s'amuser ;
Alors plutôt que de vous faire un cours sur SAP (d'ailleurs, je ne suis pas expert !), je vous donne les éléments principaux à prendre en compte pour sa sécurité.
La sécurité de SAP (depuis l'externe généralement)
Comme promis, nous allons parler de deux composants clés qui permettent d'apporter la sécurité à l'architecture SAP. Ces composants sont utilisés pour les connexions venant de réseaux qui ne sont pas de confiance généralement (ex : Internet).
Le SAP Router
Pour commencer, le SAP Router. On le retrouvera généralement sur le port TCP/3219. Il permet notamment de filtrer les IPs autorisées à communiquer avec les clients SAP. 3 niveaux de permission sont possibles :
Pour chaque règle, nous pourrons associer à l'IP (ou plage d'adresse IP) autorisée un mot de passe (clé partagée). Pour être plus clair, voici un exemple de fichier de règles :
Autre lacune du SAP Router, ces mots de passe sont visibles en clair dans le fichier de configuration. Dans le cas où le SAP router est bien configuré, il faudrait prendre la main sur la machine d'un utilisateur ayant la bonne adresse IP. Ensuite, comment obtenir un compte ? C'est en clair dans les profiles de l'utilisateur ...
Le Webdispatcher
Cette fois, nous nous attaquons à la couche applicative. A l'instar du SAP Router, le Webdispatcher va fonctionner à partir d'une liste blanche mais concerne les URLs autorisées cette fois (et non plus les IPs / services).
Il existe un compte par défaut qu'il peut être intéressant de connaître : icmadm. Mais le mot de passe est généré aléatoirement. On peut toujours essayer de trouver le mot de passe : l'interface d'administration se trouve à l'adresse suivante :
Le Webdispatcher peut avoir d'autres fonctions comme la répartition de charge (load balancing) et le chiffrement des communications (de bout en bout ou non selon que l'on souhaite analyser les flux par exemple).
Pour terminer, voici un exemple de fichier de configuration (on retrouve les P et D pour respectivement Permit et Deny) :
La sécurité de SAP en général
Instances SAP
Pour attaquer les instances SAP, nous aurons besoin de deux éléments :
Concernant le premier élément, il est généralement le même que l'instance de la base de données. Si nous trouvions ce dernier, nous aurions de grandes chances d'avoir l'élément recherché.
Quant aux comptes, il en existe par défaut. En effet, à part les 3 clients SAP créés par défaut, les autres qui seront générés auront pour couple login / mot de passe :
Les autres composants
L'architecture SAP dispose d'une base de données et d'un système d'exploitation au moins sur lequel repose la base de données. Plusieurs solutions peuvent être mises en place : Oracle, Informix par exemple côté base de données. Linux et Windows côté OS. Ces éléments clés au sein de l'architecture devront eux aussi être sécurisés.
Il y aurait beaucoup à dire et il ne s'agit pas d'éléments spécifiques à proprement parlé. Nous ne détaillerons donc pas ces points mais il est important de noter qu'ils doivent être traités afin de ne pas constituer les maillons faibles de l'architecture mise en place.
Petite conclusion
Nous avons commencer à aborder la sécurité de SAP tout en voyant des pistes potentielles d'attaques durant nos explications.
Pour faciliter la tâche d'un auditeur (ou d'un attaquant ...), il existe des plateformes d'audit tels que BIZSPLOIT dont je ne manquerai pas de vous parler et SAPSPLOIT sur lequel je reviendrai aussi puisqu'une conf y sera dédiée.
Alors plutôt que de vous faire un cours sur SAP (d'ailleurs, je ne suis pas expert !), je vous donne les éléments principaux à prendre en compte pour sa sécurité.
- Le cœur est représenté par le système SAP contenant notamment la base de données (ex : Oracle) ;
- Dans cette base de données, se trouvent généralement des choses très intéressantes :p ;
- Pour se connecter à la plateforme SAP, on bind avec des clients, à considérer en tant que passerelle en fait. Concrètement, on peut utiliser comme interface de connexion SAPGUI et s'attaquer à ces clients. Vous allez chercher cette outil et vous allez vous rendre compte qu'il est payant. Et comme il ne vous viendrait pas à l'idée d'utiliser une version crackée, il existe en fait une version JAVA gratuite ici ;
- Il est possible de se connecter depuis l'extérieur au clients SAP. Dans ce cas, une ou deux couches s'interposent : le SAP Router et le Webdispather. Nous reparlerons de ces deux éléments plus loin ;
- SAP, c'est quand même bien complexe et quand ça marche, c'est déjà bien. C'est pour ça que la sécurité est souvent laissée de côté ...
La sécurité de SAP (depuis l'externe généralement)
Comme promis, nous allons parler de deux composants clés qui permettent d'apporter la sécurité à l'architecture SAP. Ces composants sont utilisés pour les connexions venant de réseaux qui ne sont pas de confiance généralement (ex : Internet).
Le SAP Router
Pour commencer, le SAP Router. On le retrouvera généralement sur le port TCP/3219. Il permet notamment de filtrer les IPs autorisées à communiquer avec les clients SAP. 3 niveaux de permission sont possibles :
- D pour deny ;
- P pour permit ;
- et S pour ne permettre que les flux SAP (ce qui est contournable ...) ;
Pour chaque règle, nous pourrons associer à l'IP (ou plage d'adresse IP) autorisée un mot de passe (clé partagée). Pour être plus clair, voici un exemple de fichier de règles :
S 192.168.1.* SAPROUTER * motdepasse
D * * * *
Autre lacune du SAP Router, ces mots de passe sont visibles en clair dans le fichier de configuration. Dans le cas où le SAP router est bien configuré, il faudrait prendre la main sur la machine d'un utilisateur ayant la bonne adresse IP. Ensuite, comment obtenir un compte ? C'est en clair dans les profiles de l'utilisateur ...
Le Webdispatcher
Cette fois, nous nous attaquons à la couche applicative. A l'instar du SAP Router, le Webdispatcher va fonctionner à partir d'une liste blanche mais concerne les URLs autorisées cette fois (et non plus les IPs / services).
Il existe un compte par défaut qu'il peut être intéressant de connaître : icmadm. Mais le mot de passe est généré aléatoirement. On peut toujours essayer de trouver le mot de passe : l'interface d'administration se trouve à l'adresse suivante :
http://host:port/sap/wdisp/admin/default.html
Le Webdispatcher peut avoir d'autres fonctions comme la répartition de charge (load balancing) et le chiffrement des communications (de bout en bout ou non selon que l'on souhaite analyser les flux par exemple).
Pour terminer, voici un exemple de fichier de configuration (on retrouve les P et D pour respectivement Permit et Deny) :
P /sap/authorized.cgi
D *.php
D *
La sécurité de SAP en général
Instances SAP
Pour attaquer les instances SAP, nous aurons besoin de deux éléments :
- l'ID de l'instance (SAPID) ;
- un compte (login / mot de passe).
Concernant le premier élément, il est généralement le même que l'instance de la base de données. Si nous trouvions ce dernier, nous aurions de grandes chances d'avoir l'élément recherché.
Quant aux comptes, il en existe par défaut. En effet, à part les 3 clients SAP créés par défaut, les autres qui seront générés auront pour couple login / mot de passe :
SAP* / PASS
Les autres composants
L'architecture SAP dispose d'une base de données et d'un système d'exploitation au moins sur lequel repose la base de données. Plusieurs solutions peuvent être mises en place : Oracle, Informix par exemple côté base de données. Linux et Windows côté OS. Ces éléments clés au sein de l'architecture devront eux aussi être sécurisés.
Il y aurait beaucoup à dire et il ne s'agit pas d'éléments spécifiques à proprement parlé. Nous ne détaillerons donc pas ces points mais il est important de noter qu'ils doivent être traités afin de ne pas constituer les maillons faibles de l'architecture mise en place.
Petite conclusion
Nous avons commencer à aborder la sécurité de SAP tout en voyant des pistes potentielles d'attaques durant nos explications.
Pour faciliter la tâche d'un auditeur (ou d'un attaquant ...), il existe des plateformes d'audit tels que BIZSPLOIT dont je ne manquerai pas de vous parler et SAPSPLOIT sur lequel je reviendrai aussi puisqu'une conf y sera dédiée.
1 commentaire:
De plus en plus les applications créée par sap sont soumis à des attaques de plus en plus techniques. Malheureusement la formation des développeurs ne prends pas toujours en compte des méthodes de développement sûre ce qui génère des failles de sécurité fréquente. Pour cela il vaut mieux mettre un firewall applicatif qui bloquera des actions illicites.
Enregistrer un commentaire