Shellshock – Lessons Learned for SAP Customers

[gary_prewett]

I have been following the news on the Shellshock vulnerability the last few days (more information here, here, here, and here) - the vulnerability affects millions of systems and devices. And, a lot of SAP customers run UNIX/Linux systems and consequently have unpatched Bash vulnerabilities that should be patched. But what’s the criticality for SAP customers? Would an SAP customer be vulnerable to application-level attacks taking advantage of this vulnerability? Would an SAP customer with services exposed externally be vulnerable to this type of exploit?

Over the weekend Rob Kelly, a colleague of mine, and I spent some time thinking through security ramifications for our clients; Rob spent some time attempting to exploit this vulnerability at the application level on a NetWeaver Gateway and an ABAP AS system front ended by Web Dispatcher. The good news is, SAP has standardized on the C Shell for a lot of their *NIX scripts, and external services are not script-based. PI/PO developers might use Bash scripts but these normally can't be invoked directly.

The primary consideration for SAP customer is a separation of duties issue. One of the critical technical separation of duties conflicts is that between development and system administration. With this vulnerability, a developer could release code that allowed them to execute arbitrary commands and thus gain system administrator access.

However, SAP customers following the common sense security practices outlined below would already find they have processes in place to address to address this specific risk:

1. Removing access for Developers to execute OS level commands in production.
   1. The env command used to exploit this vulnerability is defined in SM69 by default; developers should not have access to make modifications in SM69.
   2. Developers shouldn’t have the ability to set up background jobs that would allow them to pass additional parameters.
   3. Don’t forget to remove the ability to run report RSBDCOS0 in SA/SE38.
2. Addressing infrastructure security
   1. OS-level logins should be restricted to administrators
   2. Restrict the ability to obtain console level access via firewall – do your users need the ability to SSH to your application or database servers?
3. Following secure software development practices
   1. Run Code Inspector or a like product to ensure input validation for user defined variables being passed to OS Commands (via function module SXPG_COMMAND_EXECUTE, PI/PO scripts, or otherwise).
   2. Have another developer peer review code for workbench requests as part of your change control process.

While the BASH shell should definitely be patched, having these controls in place should mitigate this risk of shellshock being exploited on SAP systems significantly. Practically speaking, most customers can afford to wait to apply this patch in their SAP landscapes during their normal patch maintenance cycle.

What about you? Has anyone else out there explored the implications of the shellshock in their SAP landscapes?

Note: As mentioned in the comments, SAP has released a note on Shellshock: 2072994 - "ShellShock“ vulnerability (CVE-2014-6271).