SOAP Opera: Securing SAP Web Services
The best run businesses may run SAP but very few run it exclusively. Most SAP systems operate in a complex, heterogeneous environment with information and processes spread across multiple systems including legacy applications. For SAP, this has always been a barrier to the rapid deployment of its software. Traditional solutions such IDocs, BAPIs and other interfaces were far from ideal, requiring extensive manual effort. Creating and managing the interactions between SAP and non-SAP systems was not only difficult and time-consuming, it hindered program development. Minor change requests would lead to long-term projects that would take months and, in some cases, years to implement.
Service-Orientated Architecture (SOA) offered a salvation for SAP. By embracing the principles and techniques of SOA, SAP was able to improve interoperability (which is essentially the ability to integrate diverse systems) and reduce development time and effort. This meant breaking down SAP functions into discrete objects that could be accessed or executed by other applications using open protocols and standards. These objects are known as Web services or, when subject to SAP business logic, Enterprise Services (ES). Examples include the ability to read customer data, create a sales agreement, cancel a shipment or update bank details.
Web services are constructed using standardized rules to support flexibility and ease of integration. The rules include Simple Object Access Protocol (SOAP). The name is misleading. SOAP is neither simple nor a protocol. In fact, it’s a schema for data exchange using Extensible Markup Language (XML). It provides a standardized way to exchange information between diverse systems. SOAP messages are XML documents that consist of an envelope, header and body.
Other Web service rules include Universal Description Discovery Integration (UDDI), which is used to register and catalog Web services, and Web Services Description Language (WSDL), which is equivalent to method signatures in programming language, used to describe how web services are called, the types of data that are transferred, as well as information related to network protocols, addresses and ports. We should also mention Web Services Business Process Execution Language (WS-BPEL), which is used to construct applications by binding together different Web services.
Service orientated environments are based on loosely coupled Web services that locate one another through UDDI registries and then dynamically bind together during runtime. When combined with WSDL, this happens through automated applications without human intervention. It can also be initiated by end users interacting with SOA environments through Portals. Portals, such as the SAP Enterprise Portal (EP), act as proxy agents, enabling users to interact with Web services in a SOA. We will discuss security concerns with the EP in a later article since this review is focused exclusively on Web services.
The SAP NetWeaver Application Server (NetWeaver AS) incorporates a Web Service Framework that includes ABAP and Java runtime environments for SOAP requests, tools that support UDDI registration and an Internet Communication Manager (ICM) to manage Web service calls usually through port 80NN (HTTP). Netweaver AS is the cornerstone of the SAP software stack. It integrates SAP and non-SAP applications and manages connections between the application layer and the underlying operating system and database.
Creating a Web service in SAP couldn’t be any easier. In most cases, it can be performed through simple wizards in both ABAP (Object Navigator) and Java (Developer Studio). You will need authorizations associated with the role SAP_BC_WEBSERVICE_ADMIN including S_ICF_ADMIN. Transaction WSADMIN is used to manage runtimes, generate WDSL documents and publish Web services in the UDDI.
Securing Web services is a formidable challenge. SOAP was designed for simplicity and extensibility, not security. Standard SOAP messages do not perform any authentication between endpoints or intermediaries, or provide mechanisms to protect the integrity or confidentiality of data at rest and in transit. For the most part, Web services share the same underlying architecture as Web applications. Consequently, they are vulnerable to similar exploits. This includes SQL injection attacks that target databases accessed by Web services, dictionary attacks against password protected Web services, directory traversal, buffer overflows, packet sniffing, man-in-the-middle exploits, schema poisoning, denial-of-service attacks, Trojan horses containing logic bombs, trapdoors and backdoors and XML injection attacks that target Web services directly which could lead to cross-site scripting. Since UDDI directories and WSDL mechanisms rarely require authentication and authorization, Web services are also vulnerable to remote reconnaissance attacks which are used to garner information on target systems to probe for potential vulnerabilities. Specialized search engines such as Shodan simplify the task of fingerprinting Web services that are exposed to the public, making reconnaissance very easy.
Firewall rules can be configured to ensure Web services are only accessed from legitimate networks and trusted systems. This could be supported by Intrusion Prevention Systems (IPS) that monitor for attacks against Web services. However, in reality, network perimeter controls offer scant protection against such attacks. Web services travel over HTTP. This is left open by most firewalls. Furthermore, the typical IPS does not support SOAP. Next-generation firewalls that have the ability to filter HTTP content including XML messages are expensive and offer poor throughput. Therefore, they are rarely adopted by organisations.
XML gateways provide the equivalent level of protection without the degradation in performance. Gateways are like application-level firewalls that act as intermediaries between external (untrusted) and internal Web services. Since they force SOAP messages to pass through hardened entry points that restrict access based on source, destination and other measures, gateways offer some measure of protection against Web service attacks. Enterprise level appliances such as the Cisco ACE XML Gateway can be integrated into SAP environments.
Gateways are attractive targets for attackers and, if subverted, can compromise internal Web services. Therefore, they should be regularly patched and supported by strong policies and rule-sets. Also, they should be reinforced by other components of an effective defense-in-depth strategy. This should include SSL/ TLS (HTTPS) to authenticate and encrypt SOAP messages when dealing with single endpoints (SSL doesn’t work with SOAP messages that traverse multiple destinations). It should also include adequate header extensions in SOAP messages that define security policies for message handling in accordance with the WS-Policy framework. The policies should include requirements for authentication, encryption and non-repudiation. Digital signatures should be used to protect against unauthorized modification of the policies. They should also be used to protect UDDI entries since compromised entries could lead requestors to bind to malicious Web service providers. Web services and underlying data should be replicated to improve availability and guard against denial of service attacks. Reconnaissance attacks can be blunted by disabling default error messages in the ICM and J2EE that disclose sensitive system information. They can also be thwarted by deactivating the info ICF service which can be abused by remote attackers to retrieve the same information. The presence of the info and dozens of other high-risk SAP services can be detected through vulnerability assessments performed by Layer Seven Security. The assessment leverage SAP-certified software to scan for over 400 security vulnerabilities in SAP systems. This includes services that can be accessed by attackers to perform critical functions and compromise such systems. Some of these services do not require any user authentication.