June 12, 2024

Anatomy of an SAP vulnerability: Reducing the Risk of OS-access Vulnerabilities in SAP Code

PwC Germany and SecurityBridge are committed to strengthening the security of the SAP ecosystem by conducting thorough research and providing expert advice on SAP Security. This is the second and final article of the series dedicated to the CVE-2023-36922 vulnerability and stems from the combined effort of three SAP Security experts: Daniel Peisker (PwC Germany), Benedikt Schumacher (PwC Germany), and Joris Van De Vis (SecurityBridge).

In our first article, we provided a detailed analysis of the SAP vulnerability CVE-2023-36922, shedding light on its security risk. As vulnerabilities with potential access on the OS layer (either via commands or direct file access) are not an isolated case, we guide on reducing the overall risk going beyond mere patching. Let’s now focus on how you can practically and efficiently reduce the risk of all OS-access vulnerabilities in SAP code.

To reduce the risk, you should consider a combination of measures and controls:

Preventive – How can I prevent the vulnerability or security incident from occurring in the first place?
Detective – How can I detect a vulnerability or security incident if it does happen?
Compensating – What controls do I have in place to mitigate the potential impact of a vulnerability (or its exploitation)?

Preventive

Decreasing the probability of vulnerability occurrence can be done by strengthening processes around vulnerability and patch management for the SAP standard code base and ensuring the enacting of a DevSecOps approach with automated security checks and quality gates for your SAP custom code.

To maintain a robust security posture, organizations must manage their SAP Security Notes and Support Package Stacks (SPS) and apply patches promptly. The Security Patch Management process for SAP involves handling Security Notes and Support Package Stacks (SPS). Specifically, when Security Notes are released (often on Patch Tuesday), it’s crucial to swiftly assess their applicability and criticality. The criticality of the vulnerability addressed in these security notes determines the urgency for mitigation and patch application. Patch application and mitigation measures should always be tracked and monitored to ensure and track efficient handling.

To streamline this process, consider leveraging SecurityBridge. It provides valuable insights and can assist with automation related to patch implementation.

In SAP custom code development, however, integrating DevSecOps practices enhances security and mitigates code security risks. DevSecOps security practices across its stages of planning, development, testing, continuous integration / continuous deployment (CI/CD), enabling monitoring, maintenance, and developer training, organizations can proactively address security risks at every stage.

Specific measures to proactively prevent the mentioned vulnerabilities in SAP custom code from the DevSecOps process could be:

Provide SAP-specific secure coding guidelines containing best practices for writing secure code, covering areas such as input validation, authentication, authorization, and data handling. Regularly review and update this policy to align with evolving security standards.
Invest in training programs for your developers and educate them on secure coding practices, common vulnerabilities, and how to avoid them. Training should cover topics like secure input validation, secure database access, and secure API usage. Provide developers with access to used code scanning tools in advance (on a voluntary basis) to allow cross-checking of their coding practices.
Make code-scanning tools mandatory in your transport pipeline. A tool should automatically analyze code during the development process, identifying security flaws, potential vulnerabilities, and adherence to coding standards. By integrating and automating secure code checks into your pipeline, you ensure that security assessments occur consistently and early in the development lifecycle. Ensure that code vulnerabilities are fixed before they are transported into production.

By combining guidelines, developer knowledge, and an integrated tool you can significantly enhance the security posture of your custom code within the DevSecOps process.

Detective

Consider introducing monitoring and logging measures to detect unauthorized access attempts from SAP binaries in non-SAP directories on the host system layer. Monitor and alert if SAP binaries are accessing or executing non-whitelisted SAP directories/files or if unintentional activities are taking place (e.g., sudo from SAP users).

Compensating

To compensate for the impact in case OS-access vulnerabilities are exploited, at least the following measures should be conceived and aligned:

1. Ensure that authorizations for host system directories and files are properly configured. This includes adjusting the owners, group, and permissions (chmod) for all directories and files on the host system. Be especially careful with allowing the execution of binaries/scripts.
  
  Cross-check SAP security recommendations (e.g. SAP Security Baseline) for SAP installation directories. Provide security awareness training to system administrators and developers and use automation for directory and file authorizations.
2. Avoid using environment-wide shared directories that are mounted and writable without further restrictions for <sid>adm and sapsys, whether for transports or backups. It is important to limit the access and permissions of these directories to prevent widespread lateral movements within the SAP environment.
3. Implement File System Access Filtering: Consider using the mechanism of filtering file system access using table SPTH to restrict file access when users have unlimited S_DATASET permissions. This can help reduce the risk of unauthorized file access, even if directories and files cannot be restricted in their authorizations.
  
  Regularly check if the entries in table SPTH conform to the desired access restrictions. Incorrect or missing entries can render the filtering mechanism ineffective. Alternatively, activate table change logging for table SPTH and perform log evaluation to ensure the desired access restrictions are in place.
  
  Identify and address critical access possibilities resulting from unlimited S_DATASET permissions. These may include overwriting operating system files, SAP security audit log files, read access to PSE files, and read access to sensitive data. Mitigate these risks by configuring appropriate entries in table SPTH to prevent access to these file system locations.
  
  Include as many SAP directories as possible in the blacklist to protect the SAP installation. Consider including directories such as $DIR_BINARY, $DIR_EXE_ROOT, $DIR_TRANS, $DIR_PROFILE, $DIR_GLOBAL, $DIR_DATA, and $DIR_INSTALL. These directories may contain critical system files, configuration settings, and replicated executable files.
  
  Perform a check against the access log file to ensure that no valid access to any of the blacklisted directories will be blocked. If valid access is detected and validated, either remove the directory from the blacklist or explicitly grant access to specific subdirectories or files within the directory.
4. The most effective way to prevent OS command injection vulnerabilities is to avoid calling OS commands from application-layer code whenever possible. In most cases, there are alternative methods to achieve the required functionality.
  
  If it is necessary to call OS commands with user-supplied input, utilize logical commands with pre-defined parameters and avoid parameter wildcards (both in your code and in your system configuration). Use a unique naming concept based on the inherent risk of logical commands.
  
  For any parameter variables, strong input validation is crucial. Effective validation techniques include:
  – Validating against a whitelist of permitted values.
  – Validating that the input is a number.
  – Validating that the input contains only alphanumeric characters, without any additional syntax or whitespace.
  
  It is important to note that attempting to sanitize input by escaping shell metacharacters is not recommended, as it can be error-prone and easily bypassed by skilled attackers.
5. Review and clean up authorizations on the SAP application layer. Avoid using wildcards on S_DATASET and S_LOG_COM authorizations.

Thank you for reading this article, and please remember the importance of taking a comprehensive approach to SAP security. By addressing the risk strategically and not solely relying on patching isolated vulnerabilities, you can strive for a more robust and resilient security posture.