As a security researcher and member of the CORE Security Consulting Services team, and close partner with CORE Labs here in Buenos Aires, I need to perform security analysis of complex enterprise IT environments with software installations from any number of vendors. These environments’ technologies are often both poorly documented and maintained. Our job here at CORE is to make sure our customers and other security professionals have a better understanding about hidden risks within their IT systems through vulnerability assessments and testing.
Evaluating the security levels of these systems is challenging, as was the case with SAP NetWeaver Applications Servers, a service that communicates with SAP’s GUI applications using the Diag (Dynamic Information and Action Gateway) network protocol. This SAP service’s complexity stems from the fact that the protocol is proprietary, documentation is not available to those who are not customers and there are no tools available to comprehensively evaluate an SAP installation.
Considering this, I focused on SAP’s protocol. I tested manually, performed remote fuzzing sessions, played around with its network packets and crashed the services in several ways. All of this enabled me to create an exploit toolset that led me to discover six vulnerabilities related to the SAP Diag network protocol that can:
- Establish a connection to the SAP Application Server’s Dispatcher service
- Query the application server
- Perform man-in-the-middle (MiTM) attacks
- Emulate a valid user by logging into SAP providing valid credentials
- Perform denial-of-service attacks
As a result of this work, I partnered with my fellow security researchers at CORE Labs where we shared details through our process of responsible disclosure to security professionals at SAP and today we issued a security advisory with technical details and a patch. This was timed with SAP’s issuance of an advisory covering these vulnerabilities. (to access the SAP advisory, visit their Community Network website and register)
Technical Details Regarding the Six Vulnerabilities within SAP Netweaver Application Servers
DiagTraceHex Denial of Service: Developer Traces are used within a SAP installation to diagnose problems. These can be configured at different levels of detail, from 0 (no traces) to 3 (full trace plus additional information). When Developer Traces are configured at levels 2 or 3 for the "Dialog processor" component, the SAP Netweaver Application Server's work processes makes a full hex dump of all Diag requests and responses. I found that a vulnerability is triggered by sending a Diag packet containing an item, e.g., the Diag XML Blob, with a wrong length field value. The application server will try to dump the packet's content and end up dumping the server's memory; this raises an exception, crashing the dialog work process.
DiagTraceAtoms and DiagTraceStreamI Denial of Service: These two vulnerabilities also require that the work process handling the request is configured to trace "Dialog processor" events at levels 2 or 3. In both cases, an unauthenticated user can cause a denial-of-service by sending specially-crafted packets of type DYNT ATOM and RCUI CONNECT_DATA.
Diaginput and DiagiEventSource Denial of Service: These are the other two denial-of-service vulnerabilities Diaginput and DiagiEventSource. An unauthenticated user can send malformed messages of type VARINFO MAINAREA_PIXELSIZE or UI_EVENT_SOURCE and the dialog work process will end up crashing and leaving the Diag service unavailable, thus provoking the denial-of-service.
DiagTraceR3Info Remote Code Execution: The sixth crash we performed with the DiagTraceR3Info looked more promising as this vulnerability could possibly allow an attacker to take over the server. By investigating the crash in more detail, I found that the problem was a stack-based overflow that was produced when the server handled messages containing ST_R3INFO CODEPAGE items. Exploitation of this bug was very straightforward using some well-known Unicode exploitation techniques. This bug also need work process' developer traces to be configured at levels 2 or 3 for the "Dialog processor" component.
What is the Business Risk?
It is worth noting that all of these vulnerabilities were accessable with no authentication required. The dispatcher service is commonly accessible only from internal networks, thus enabling an internal attacker to exploit the vulnerabilities. What this means is that any attacker with connectivity to a vulnerable SAP Dispatcher service could potentially compromise the entire SAP installation. The potential impact includes financial fraud, siphoning of critical business information and sabotage of every SAP Netweaver Dialog instance – rendering the service unavailable to legitimate users.
Even though some of the bugs require the Developer Traces to be set to levels higher than the standard (which isn't really common in production environments) it's worth mentioning that a regular user with permissions for executing Screen Traces (i.e., transaction ST20), work process management (i.e., transactions SM04/SM50) or profile management (i.e., transaction RZ10/RZ20) authorizations could enable traces on server's work processes and then launch the exploit for these vulnerabilities.
Access to turn on developer traces on production environments are mostly given only to BASIS administrators, but sometimes granted to regular users for troubleshooting or to developers in non-production environments. It’s also worth mentioning that SAP’s default users SAP* and DDIC has this capability. Therefore, it is suggested that SAP administrators follow standard guidance about default SAP users and passwords.
How you can Mitigate Risk
SAP has released fixes for these vulnerabilities. You can find the details in SAP Note 1687910 (requires authentication; to access the SAP advisory, visit their Community Network website and register). Apart from the remediation we outline in our advisory, we suggest you employ these countermeasures or workarounds that will help mitigate risk:
- Restrict network access to Dispatcher service's ports. Access to TCP ports 32NN (NN is SAP’s instance number) should be allowed only to required users.
- Disable Developer Traces for the Dialog Processing component. This can be performed using transaction SM50 and/or through "rdisp/TRACE*" profile parameters.
- Restrict access to transactions that can be used to enable Developer Traces. Some examples of these transactions are ST20 (screen traces) and SM04/SM50 (work processes management) through authorization object S_ADMI_FCD, and transactions RZ10/RZ20 (profile maintenance) using the authorization object S_RZL_ADM.
- Encourage the use of SAP GUI for HTML client instead of the SAP GUI application. Ensure that you also enable HTTPS/SSL.
- Martin Gallo, Security Researcher, CORE Security Consulting Services