Shellshock et SAP
Source :
http://scn.sap.com/community/security/blog/2014/09/29/shellshock-lessons-learned-for-sap-customers
Traduction : Google
Auteur : Posted by Gary Prewett in Security on Sep 29, 2014 9:46:03 PM
J'ai suivi les nouvelles sur la vulnérabilité Shellshock ces derniers jours (plus d'informations ici, ici, ici, et ici) - la vulnérabilité affecte des millions de systèmes et dispositifs. Et, beaucoup de clients SAP exécuter des systèmes UNIX / Linux et par conséquent ont des vulnérabilités non patchées Bash qui devraient être patchés. Mais quelle est la criticité pour les clients SAP? Serait un client de SAP être vulnérable aux attaques de niveau applicatif qui profitent de cette vulnérabilité? Serait un client de SAP avec les services exposés à l'extérieur être vulnérables à ce type d'exploit?
Au cours de la fin de semaine Rob Kelly, un de mes collègues, et moi avons passé un certain temps à réfléchir à des ramifications de sécurité pour nos clients; Rob a passé quelque temps à essayer d'exploiter cette vulnérabilité au niveau de l'application sur une passerelle et un NetWeaver ABAP AS avant du système terminé par Web Dispatcher. Les bonnes nouvelles sont, SAP a normalisé sur le C Shell pour beaucoup de leurs scripts * NIX, et les services externes ne sont pas à base de script. Développeurs PI / PO peuvent utiliser des scripts Bash mais ceux-ci ne peuvent normalement pas être invoquée directement.
La considération primordiale pour SAP client est une séparation d'émission des obligations. Un de la séparation technique critique de devoirs conflits, c'est que entre le développement et l'administration système. Avec cette vulnérabilité, un développeur peut libérer le code qui leur a permis d'exécuter des commandes arbitraires et l'accès de l'administrateur système ainsi un gain.
Toutefois, les clients SAP suivants les pratiques de sécurité de bon sens décrites ci-dessous seraient déjà trouver qu'ils ont des processus en place pour répondre à ce risque spécifique:
Suppression de l'accès pour les développeurs d'exécuter des commandes au niveau du système d'exploitation dans la production.
La commande env utilisé pour exploiter cette vulnérabilité est définie dans SM69 par défaut; les développeurs ne devraient pas avoir accès à apporter des modifications dans SM69.
Les développeurs ne devraient pas avoir la possibilité de définir des travaux de fond qui leur permettraient de passer des paramètres supplémentaires.
Ne pas oublier d'enlever la possibilité d'exécuter rapport RSBDCOS0 dans SA / SE38.
La sécurité des infrastructures d'adressage
Les connexions au niveau du système d'exploitation doivent être limitées aux administrateurs
Restreindre la capacité d'obtenir l'accès au niveau de la console via pare-feu - ce que vos utilisateurs doivent pouvoir SSH à votre application ou les serveurs de base de données?
Selon les pratiques de développement de logiciels sécurisés
Inspecteur de code Run ou un produit similaire à garantir la validation d'entrée pour les variables définies par l'utilisateur étant passés à OS commandes (via le module fonction SXPG_COMMAND_EXECUTE, son PI / PO, ou autre).
Avoir un autre code d'examen de développeur pour les demandes d'établi dans le cadre de votre processus de contrôle des changements.
Alors que le shell bash devrait certainement être patché, ayant ces contrôles en place devrait permettre d'atténuer ce risque de shellshock exploitée sur les systèmes SAP de manière significative. En pratique, la plupart des clients peuvent se permettre d'attendre pour appliquer ce patch au cours de leur cycle de maintenance de patch normal.
Qu'en pensez-vous? Quelqu'un at-il là-bas exploré les implications de la shellshock dans leurs paysages SAP?
Partager cet article
Partager cet article
Newsletter
Abonnez-vous pour être averti des nouveaux articles publiés.
À propos
Admin SAP BC
Administration SAP BC
Commenter cet article