mercredi 30 juin 2010

[HITB Conference] SAP Hacking - Overview 2/2

Deuxième et dernier jour de training sur la sécurité de SAP. Beaucoup de choses mais ça reste tout à fait intéressant. On continue notre tour d'horizon !


La sécurité de l'authentification

Sur les systèmes SAP, il est possible de se connecter de plusieurs manières différentes. En particulier, il est possible de se connecter :
  • via un login/mot de passe (classique) ;
  • SNC (Secure Nework Communication) permet de se connecter à l'aide d'une librairie extérieure (ex : NTLM) ;
  • via un certificat ;
  • par ticket (dans le cadre d'une authent' par SSO notamment ;
  • PAS (Pluggable Authentication Service) : utilisation d'une autre base d'authent' (ex : LDAP) ;
Bon, on conviendra que ce n'est pas le choix qui manquent. Après, ils ne sont pas tous égaux en termes de fiabilité...


La sécurité des utilisateurs

Tout d'abord, il existe plusieurs types d'utilisateur. Le type attribué dépendra de la connexion et du niveau de sécurité attendu. Par exemple, le type Dialog permet un accès direct au système SAP. Ce qui n'est pas le cas pour le type system mais ce dernier impose un mot de passe qui n'expire pas.
Une fois n'est pas coutume, il existe pas mal de comptes par défaut sur un système SAP. Évidemment, il est recommandé de verrouiller les comptes en question ou du moins, d'en changer les mots de passe.
Le compte privilégié est SAP*. Tiens, il me semble qu'on avait vu que ce compte avait un mot de passe par défaut trivial ... De plus, ce compte ne peut pas être supprimé ! Il existe cependant des moyens de sécuriser de tels accès.


La politique de mots de passe

L'encodage des mots de passe a évolué au fur et à mesure des versions de SAP. Aujourd'hui, les plus complexes sont hashés avec SHA1 et bénéficient d'un sel aléatoire. Les précédents sont cassables avec john patché. Ensuite, tous les paramètres classiques et attendus existent (blocage du compte, historique des mots de passe, expiration, etc.).


Les autorisations

Un utilisateur loggé ne peut pas (toujours) faire tout ce qu'il veut. il est soumis à des autorisations. Des contrôles sont donc effectués avant qu'un utilisateur ne puissent réaliser une transaction (au sens SAP) par exemple. Un utilisateur ayant le profile SAP_ALL est le plus intéressant pour un attaquant ; en effet, il permet de réaliser toute action.


La sécurité des communications

Un attaquant peut s'amuser à interagir avec les protocoles utilisés par SAP pour obtenir des informations sur le système ou exploiter des vulnérabilités. il s'agit notamment de :
  • RFC : permet de lancer des fonctions sur les serveurs distants ;
  • Commandes externes : une transaction de SAP permet d'interpréter des commandes système (sur le système d'exploitation).

La sécurité des environnements

Dans SAP, nous retrouvons trois instances primaires :
  • environnement de développement (DEV) ;
  • environnement de qualification (QAS) ;
  • environnement de production (PRD).

Quand bien même il s'agit d'instances distinctes, elles sont reliées à une même base (common transport directory).
Il est possible de cloissoner les droits entre ces environnements et au sein de la base. Ainsi, un développeur ne pourra pas porter atteinte à l'intégrité des données de production par exemple. La configuration se fait via une transaction de SAP.


La sécurité du langage de programmation (ABAP)

Un module mal codé pourra permettre de lancer des attaques critiques. En l'occurrence, elles peuvent permettre de contourner les restrictions de droits appliqués à un utilisateur. Ce langage peut aussi permettre de lancer des commandes SQL et ainsi récupérer des données (contournement des contrôles d'autorisation (voir plus haut)).


Quelques portes cachées vers le graal

Il existe plusieurs points d'entrée qu'un attaquant se fera un plaisir d'utiliser pour atteindre sa cible. Il s'agit de service qui, une fois activé, offre une interface Web qui sera plus ou moins bien protégée ... (qui a dit que ça pourrait être accessible depuis Internet ??? ;)
Il pourra notamment compromettre l'application via les interfaces d'administration souvent mal protégée (d'après quelques recherches sur google ...).
  • http://serveur:port/chemin_vers_WGate/service/!?variable
  • http://serveur/scripts/wgate/webgui!?~client=000
  • http://serveur:port/chemin_vers_WGate/admin/!

Conclusion

Voilà, c'est terminé pour la formation. Je n'ai pas été exhaustif mais je pense avoir fourni un bon aperçu. Ici, nous avons surtout vu les différents points de sécurité à aborder pour la sécurisation d'un système SAP ... ou les vecteurs d'attaque pour un attaquant.
Nous ne serons pas sans reparler de SAP car deux confs sont prévus sur le sujet. Aussi, j'espère trouver l'occasion de vous faire un retour d'expérience sur un audit afin d'illustrer cette théorie par la pratique :)

1 commentaire:

Anonyme a dit…

Merci pour ce retour Jerem !

@+
Alex

Locations of visitors to this page