A Story Of Unexpected Intrusion Testing Results

A Story Of Unexpected Intrusion Testing Results

Speakers: Yvan Genuer (Security Researcher, Onapsis)

Conference: HITB Phuket

YouTube: https://www.youtube.com/watch?v=jkSaP_KH-yY

Overview

In "A Story Of Unexpected Intrusion Testing Results," Yvan Genuer, a seasoned Security Researcher at Onapsis, unveils a critical journey into the often-overlooked security posture of SAP systems. The talk details the discovery of severe vulnerabilities, including memory corruption and OS command injection, within the ubiquitous SAP Host Agent – a mandatory component present on all SAP servers. These vulnerabilities, unearthed during a routine penetration test, were triggered by an obscure and undocumented configuration parameter, service/localConnection, which, when set to compatibility, exposed a wealth of privileged functions to remote, unauthenticated attackers.

Genuer's presentation is a compelling narrative that transitions from an initial, seemingly fruitless pentest to a deep technical dive culminating in remote code execution (RCE) as root. The research underscores the profound risks associated with undocumented features and the critical importance of scrutinizing core enterprise systems, even those managed in modern cloud environments. Given that SAP underpins the operations of approximately 90% of large corporations, managing everything from HR to finance, the compromise of such a system can lead to devastating business data breaches and operational disruption. The talk serves as a stark reminder that even fully updated and well-configured systems can harbor hidden dangers, particularly when obscure parameters enable unintended attack surfaces in high-privilege components.

This detailed exploration not only highlights the technical intricacies of the vulnerabilities but also emphasizes broader lessons in security research, vendor disclosure, and defensive strategies. It challenges the notion that outsourcing SAP to cloud providers or third-party teams absolves organizations of their security responsibilities, advocating for a "trust but verify" approach. The findings led to coordinated disclosure with SAP, resulting in critical security patches, reinforcing the collaborative effort required to secure complex enterprise landscapes against sophisticated threats.

Background

▶ Watch: Introduction to SAP vulnerability research (0:00)

SAP systems are the backbone of global commerce, with Yvan Genuer stating, "SAP runs the world," and estimating that around 90% of large companies utilize SAP for managing critical business functions such as HR, finance, and supply chain operations. This ubiquity makes SAP a prime target for attackers, as compromising an SAP system effectively means compromising an organization's most sensitive business data. SAP offers a diverse range of products, including SAP NetWeaver, SAP S/4HANA, and various other application platforms, all capable of running on different operating systems like Windows, Linux, and Unix, and supporting multiple database types.

A crucial, mandatory component across all these SAP server environments is the SAP Host Agent, also known interchangeably as SAP OS Control, SAP Host Control, or SAP Host Daemon. This agent is responsible for vital lifecycle tasks, enabling SAP administrators to stop and start systems, prepare for upgrades, and update kernels, among other functions. Due to its critical role, the SAP Host Agent operates with extremely high privileges, running as root on Linux/Unix systems and as NT AUTHORITY\SYSTEM on Windows. It exposes network services, listening on port 1128 for HTTP and 1129 for HTTPS. Remotely, these services are accessed via SOAP requests, leveraging three primary namespaces: sapcontrol, saposcol, and sap_wscall. Historically, SAP security professionals generally understood that only about 10 benign functions within these namespaces were accessible remotely without authentication, performing simple tasks like "ping" or basic status checks.

The story of this discovery began during a "very very little" three-day penetration test on an SAP S/4HANA system deployed in a cloud environment, specifically leveraging SAP's "Rise with SAP" offering. Genuer noted this was his first encounter with S/4HANA in the cloud. Initial reconnaissance involved scanning the system, revealing the typical array of open SAP services. Despite the system being described as "completely up to date, close, [and with] good configuration," an initial lack of findings on the first day prompted a deeper investigation beyond conventional SAP attack vectors. This persistence led to the unexpected revelations that form the core of his talk, highlighting that even seemingly robust and current SAP installations can harbor significant, hidden vulnerabilities.

Key Findings

▶ Watch: Discovering 'service_local_connection' parameter and its impact (11:00)

Yvan Genuer's research uncovered two critical vulnerabilities within the SAP Host Agent, both leading to Remote Code Execution (RCE) under specific, albeit previously undocumented, conditions. These findings underscore the danger of obscure configurations in highly privileged enterprise software.

The foundational discovery was an undocumented configuration parameter named service/localConnection. When this parameter was set to compatibility within the SAP Host Agent's configuration (saphostagent.ini), it drastically expanded the attack surface. Instead of the expected 10 remotely accessible, unauthenticated functions, 32 additional functions became remotely callable, with 12 of these requiring no authentication. This parameter was found embedded within the verbose output of the GetOSData function, which itself was unexpectedly accessible remotely.

Building upon this expanded access, Genuer identified two distinct RCE vulnerabilities:

1. Memory Corruption (CVE-XXXX-XXXX): This vulnerability was discovered in the sap_wscall namespace, specifically within the SendRequest web method. Through fuzzing the MValue parameter, Genuer was able to crash the saposcol binary, which runs with root privileges. The crash occurred at the end of a function during its return, allowing for the compromise of the ESP register. Critically, the saposcol binary exhibited surprisingly low protection mechanisms, with only stack execution protection enabled, making it susceptible to return-oriented programming (ROP) techniques. Further, the GetHardwareData function (also exposed by the undocumented parameter) leaked essential information like the libc version and its base address, enabling a Return-to-Libc (RTL) attack. While Genuer demonstrated this with a one_gadget payload in a lab environment, the nature of the HTTP SOAP request meant a direct shell was not returned. This particular vulnerability was found to affect only Linux systems.

1. OS Command Injection (CVE-XXXX-XXXX): This more practical RCE was found in the sapcontrol namespace, specifically within the ConfigureOutsideDiscovery web method. During analysis, Genuer observed that when the sapcontrol binary was executed locally by a standard user, it would internally craft an HTTP SOAP request to localhost:1128. This request was then processed by the saposcol listener, which, running as root, would execute commands. The critical insight was discovering that one of the undocumented parameters within this SOAP request was vulnerable to OS command injection. By crafting a malicious HTTP SOAP request and sending it directly to port 1128 or 1129 (if HTTPS), an attacker could inject arbitrary operating system commands, achieving a remote shell as root (Linux/Unix) or NT AUTHORITY\SYSTEM (Windows). This vulnerability proved to be a reliable and direct path to full system compromise.

Both vulnerabilities were responsibly disclosed to SAP, leading to the release of necessary security patches via SAP Security Notes, correcting the issues and addressing the undocumented parameter's dangerous behavior.

Technical Deep Dive

▶ Watch: Crashing a root-level binary (subway SC) on Linux (21:10)

The technical journey began during a three-day SAP penetration test where initial, conventional attacks yielded no results against an S/4HANA system noted to be "completely up to date, close, [and with] good configuration." This prompted Yvan Genuer to focus on the SAP OS Control services, specifically the HTTP and HTTPS listeners on ports 1128 and 1129. Although these services are well-known to SAP security professionals, and Genuer himself had previously found vulnerabilities in them, the expectation was that only a handful of benign functions would be remotely accessible without authentication.

However, during the pentest, Genuer discovered that two functions, GetOSData and GetVersionInfo, which typically require authentication or local access, were unexpectedly accessible remotely. The GetOSData function, in particular, returned a substantial 2 megabytes of plain text data. This data contained a wealth of OS-level information, including running processes, listener configurations, and even snippets from critical system files like /etc/os-release. Crucially, embedded within this voluminous output, specifically within the saphostagent.ini configuration, was an unfamiliar parameter: service/localConnection = compatibility.

This discovery was the linchpin. Genuer immediately paused work on the customer's system to replicate the environment in his lab, configuring the SAP OS Control with this specific parameter. The lab tests confirmed that enabling service/localConnection = compatibility exposed an additional 32 functions remotely, 12 of which did not require any authentication. This dramatically expanded the attack surface beyond what was publicly known or documented.

The first significant vulnerability uncovered was a memory corruption issue (CVE-XXXX-XXXX), affecting Linux systems. Genuer targeted the sap_wscall namespace and its SendRequest web method. By fuzzing the MValue parameter within the SOAP request, he observed a change in response length when the value reached 100. Further investigation, facilitated by interacting directly with the saposcol binary in dialog mode on a local system, revealed that sending MValue=102 through the SendRequest remotely was equivalent to executing saposcol calltime locally. This insight allowed him to use command-line fuzzing against the local saposcol binary. This fuzzing eventually led to a crash of saposcol, which, critically, runs as root. The crash occurred during the return instruction at the end of a function, and the ESP register was compromised, indicating a controllable overflow. Analysis of the binary revealed minimal protections, primarily only stack execution protection, making it vulnerable to Return-to-Libc (RTL) attacks. The GetHardwareData function, also exposed due to the service/localConnection parameter, conveniently leaked the libc version and its memory addresses, enabling the calculation of the libc base address. This information was crucial for crafting an RTL payload, which Genuer demonstrated by successfully pointing the RSP register to a one_gadget for potential shell execution in a GDB-attached environment. However, due to the nature of the HTTP request and the service crash, a direct remote shell was not received.

Recognizing the Linux-specific nature and the limitations of the memory corruption exploit for practical remote shell acquisition, Genuer continued his research. This led to the discovery of a more potent OS command injection vulnerability (CVE-XXXX-XXXX), this time within the sapcontrol namespace, specifically in the ConfigureOutsideDiscovery web method. While analyzing the function's behavior, he noticed that when a standard user executed the sapcontrol binary locally to call ConfigureOutsideDiscovery, the SAP Host Agent logs showed that root was attempting to execute commands, such as mv. This observation was puzzling until Genuer sniffed local network traffic on port 1128. He discovered that the sapcontrol binary, when invoked locally by a user, would internally craft an HTTP SOAP request and send it to localhost:1128. This local request was then processed by the saposcol listener, which, running as root, would execute the commands embedded within the SOAP payload. The key insight was that one of the parameters in this SOAP request, typically used for host, port, username, and password, was susceptible to OS command injection. By injecting standard shell metacharacters (e.g., $(command)), an attacker could execute arbitrary commands. This meant that a remote attacker, by sending a specially crafted HTTP SOAP request directly to port 1128 or 1129 (if HTTPS), could bypass local authentication and achieve remote code execution as root or NT AUTHORITY\SYSTEM. This method provided a reliable and direct path to a reverse shell, demonstrating a complete and practical compromise of the SAP system.

Demo / Proof of Concept

▶ Watch: Lessons: obscurity, trust, vendor relations, breaking vs. protecting (37:30)

Yvan Genuer provided clear demonstrations for both discovered vulnerabilities, illustrating the path to remote code execution.

For the memory corruption vulnerability (CVE-XXXX-XXXX), the proof of concept focused on showcasing control over program execution flow. In the demonstration, the attacker's perspective was shown on a bottom terminal, executing an exploit script. Simultaneously, a top terminal displayed a GDB debugger attached to the saposcol process, running as root on the target SAP system. The exploit script first requested the "Hardware Data" from the target, which, as previously discovered, contained crucial libc version and address information. This data was then parsed to calculate the libc base address. With this information, the exploit crafted a payload designed to target a one_gadget (a single instruction sequence within libc that can lead to a shell under specific conditions, often used in CTFs). When the crafted SOAP request was sent to the SendRequest function, GDB showed a breakpoint hit just before the crash. Critically, the RSP register was observed to point directly to the one_gadget address within libc. Continuing execution would attempt to execute a shell. Genuer explicitly noted that while this demonstrated control over execution flow, a direct shell was not received back to the attacker because the communication model involved sending an HTTP request that caused the service to crash, rather than persistent interactive communication.

The demonstration for the OS command injection vulnerability (CVE-XXXX-XXXX) presented a more practical and direct path to a remote shell. This proof of concept involved two terminals for the attacker. On the bottom terminal, a listener (e.g., netcat) was set up to catch an incoming reverse shell. On the top terminal, a custom exploit script was executed. This script took several parameters: the target hostname, the port (either 1128 for HTTP or 1129 for HTTPS), the operating system type (Unix/Linux or Windows, as the payload syntax differs), and the desired command to execute. For the demonstration, a standard reverse shell payload was provided as the command. The script then crafted a single, malicious HTTP SOAP request containing the injected command within one of the ConfigureOutsideDiscovery function's parameters. Upon execution of this single HTTP request, the listener on the bottom terminal immediately received a reverse shell. The prompt clearly indicated that the shell was running with root privileges, demonstrating complete and practical remote code execution on the target SAP system. This demo effectively showed a "game over" scenario for the attacker, achieving full system compromise through a single, unauthenticated remote request.

Defensive Implications

▶ Watch: Audience asks about the undocumented parameter's origin (41:10)

The findings presented by Yvan Genuer carry significant defensive implications for any organization operating SAP systems, particularly given the critical nature of the SAP Host Agent.

1. Patch SAP Host Agent Immediately: The most crucial defensive action is to apply the relevant SAP Security Notes. Genuer emphasized that these patches, identified by their SSN (SAP Security Note) numbers, address the underlying vulnerabilities by providing new, corrected binaries for the SAP Host Agent. He explicitly stated that patching the SAP Host Agent is "not an SAP upgrade" and involves "tiny application" binaries. This means the process is relatively low-risk and can be performed with minimal downtime, as the SAP system itself can continue running while the agent is updated. Organizations should prioritize these patches to mitigate the RCE risks. While specific CVE numbers were not provided in the talk, the SAP Security Notes would contain this information.

1. Verify service/localConnection Configuration: Defenders must audit their SAP Host Agent configurations to ensure the service/localConnection parameter is not set to compatibility. This parameter, which was previously undocumented and enabled remote access to privileged functions, is a direct indicator of vulnerability. The default setting for this parameter is to not use it, which means systems without this explicit configuration are not remotely vulnerable to these specific attacks (though they might still be vulnerable locally). Organizations should actively search for service/localConnection in their saphostagent.ini files and remove or disable it if found.

1. Upgrade SAP Host Agent to Deprecate Parameter: Genuer noted that from SAP Host Agent version 7.2 PL 61 (Patch Level 61) onwards, the service/localConnection parameter is completely deprecated and will no longer exist. Upgrading to this version or a newer one permanently removes the configuration option that enabled the remote attack vector, providing a more robust long-term defense against this specific class of vulnerability.

1. Strengthen Network Segmentation: The attack vectors rely on access to ports 1128 (HTTP) and 1129 (HTTPS). While these ports are typically not exposed directly to the internet, they are often accessible within internal enterprise networks. Defenders must implement strict network segmentation to ensure that only authorized and necessary systems can communicate with the SAP Host Agent on these ports. Genuer's pentest simulated an attacker already having internal network access, highlighting that even within a trusted network segment, these vulnerabilities can be exploited. Strong firewall rules, access control lists (ACLs), and potentially even host-based firewalls on SAP servers should restrict access to these ports to only essential administrative hosts.

1. "Trust But Verify" for Cloud and Managed Systems: A crucial takeaway is the importance of not taking security for granted, even when SAP systems are externalized to cloud providers (like "Rise with SAP") or managed by third-party teams. Genuer's initial pentest was on such a system, which was described as "up to date." Organizations must actively audit and verify the security configurations of their cloud-hosted or externally managed SAP environments, including checking for undocumented parameters and ensuring that default security postures are genuinely enforced. Delegating management does not delegate responsibility for security.

Key Takeaways

• Obscurity Is Not Security: The discovery of critical vulnerabilities stemming from an undocumented configuration parameter, service/localConnection, starkly illustrates that hiding features or their implications does not make them secure. Attackers will eventually uncover and exploit such hidden functionalities.
• "Trust But Verify" for Critical Systems: Even when SAP systems are hosted in the cloud or managed by external providers, and even if they are reported as "up to date" and "well-configured," organizations must maintain a proactive stance. Regular, independent audits and deep dives into configurations are essential to verify the true security posture.
• SAP Host Agent: A High-Privilege Target: The SAP Host Agent is a mandatory component running with root or NT AUTHORITY\SYSTEM privileges on all SAP servers. Its pervasive presence and elevated permissions make it an extremely high-value target for attackers, demanding the utmost scrutiny and robust security measures.
• Vendor Collaboration is Crucial: The successful coordinated disclosure with SAP, leading to the release of security patches, highlights the critical importance of a good relationship between security researchers and vendors. This collaboration ensures vulnerabilities are addressed effectively and promptly, benefiting the entire ecosystem.
• Offensive vs. Defensive Effort Imbalance: Genuer noted that finding these vulnerabilities took him approximately 10 days to two weeks. In contrast, correcting such issues for a large vendor like SAP can take "two to three months." This disparity underscores the significant effort required on the defensive side to secure complex systems against relatively quicker offensive discoveries.
• Network Segmentation Remains Key: While the vulnerabilities could be exploited remotely, they required access to specific ports (1128/1129). Strict network segmentation, limiting access to these ports from internal networks and absolutely blocking them from the internet, remains a fundamental defensive control.

About the Speaker(s)

Yvan Genuer is a highly experienced Security Researcher at Onapsis, a company dedicated to ERP security, with a strong focus on SAP systems. His career spans over two decades within the SAP ecosystem. Genuer began his journey as an SAP Basis Administrator, accumulating 10 years of hands-on experience in managing SAP systems. He then transitioned into SAP security, dedicating another 10 years to securing these critical enterprise platforms. For the last six years, he has served as a full-time security researcher specializing in SAP. Throughout his career, Yvan Genuer has made significant contributions to SAP security, having discovered and reported more than 100 vulnerabilities in SAP systems. His extensive background provides him with a unique and deep understanding of both the operational and security aspects of SAP, making his research particularly insightful and impactful.