Layer Seven Security
Missing authorization checks in the Archiving Workbench, default pass phrases on the J2EE secure store and SQL injection vulnerabilities in Java applications. Read the guide to July’s SAP Security Notes at http://layersevensecurity.com/SAP_security_advisories.html
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.
There are few terms more widely misunderstood in the world of information security than the word ‘hacking’. Although it’s used in a variety of contexts, it’s most commonly used to refer to all types of cyber crime including everything from fraud and industrial espionage to identity theft and spamming. If you take this view, cyber crimes are the deeds of ‘hackers’.
In reality, hackers do far more good than harm. Many are researchers that practice a form of ethical hacking driven by a desire to improve the state of information security. Ethical hackers are the ‘white hats’ of security. They use everything from port scanning to breaking and entering to simulate an attack against networks and systems, usually with the consent of their targets. Software companies such as SAP owe a huge debt to white hats. Many of the vulnerabilities patched by SAP Security Notes are discovered not by SAP, but independent researchers that are far more adept at finding vulnerabilities than SAP itself.
In the past, white hats would publish details about vulnerabilities as soon as they were discovered. Today, most follow SAP’s Disclosure Guidelines. As a result, very few vulnerabilities are publicized until they are patched by SAP. Whether or not this is in the interest of SAP customers is open to debate. It could be argued that this reduces the incentive for SAP to properly patch its software, A case in point is a session hijacking vulnerability in the Enterprise Portal which wasn’t patched until 18 months after it was reported to SAP.
White hats rule the roost of information security. One step below are the black hats who most closely resemble the stereotypical image of hackers portrayed in pop culture. Black hats use the same tactics as white hats but differ in their motives which are generally malicious. Most are driven by the need for notoriety or personal gain, although some are motivated by more noble goals such as social justice. The latter are often referred to as ‘hacktivits’. Its difficult to stall an attack by talented and determined black hats. The only approach that provides any glimmer of hope is the tried and tested defense-in-depth strategy which may buy enough time to detect a breach before any real damage is done or encourage attackers to direct their efforts towards other less well defended targets outside your network.
White hats look down upon black hats but the two groups have much in common. Firstly, they are both skilled in the art of finding and exploiting vulnerabilities. Secondly, they’re partial to challenges and venerate well-constructed code like a thing of beauty. Thirdly, both white hats and black hats frown upon script kiddies, or skiddies for short.
Skiddies are the hillbillies of the information security world. They don’t look down upon anyone since they’re at the rock bottom of the totem pole. Skiddies are considered social pariahs since they have no appreciation of the concepts and tools of information security. Their sole purpose is to exploit vulnerabilities discovered by black hats. Black hats take pride in their work. Targets are carefully selected and attacks are meticulously planned. They go to great lengths to cover up their tracks. Skiddies, on the other hand, blindly execute scripts developed by black hats hoping to catch victims that happen to be susceptible to whatever vulnerability they’re targeting at a moment in time. Despite this, skiddies should not be underestimated. They far out-number black hats. They also have an uncanny ability to learn about new exploits long before they’re patched. This is fuelled by IRC (Internet Relay Chat) and online trading for zero-day exploits.
The proliferation of easy to use security tools with point and click interfaces has dumbed down hacking and turned the tide in favor of skiddies. Many programming or configuration flaws in systems such as SAP don’t require any technical skill to exploit. Therefore, relying upon security through obscurity no longer works, especially when systems are public-facing.
Intense, focused attacks led by black hats are destructive but far less likely than a random strike performed by a skiddie. However, the latter will quickly reveal vulnerabilities in a poorly patched SAP environment.
April was another bumper month for SAP Security Notes. In all, SAP issued 33 patches, of which 5 were considered critical. Top of the list were Notes 1647225 and 1675432 which address missing authorization checks in components of Business Objects Data Services (EIM-DS) and the SAP Classification System (CA-CL).
EIM-DS is SAP’s flagship solution for data integration and quality. It’s used to consolidate, cleanse and migrate data from both SAP and external systems. CA-CL is used to manage classification properties and classes for various types of objects. An example could be an object such as a Ford F-350. This would fall into a Vehicle class and have properties such as length, weight, color, power, capacity, etc. assigned within the system. Both EIM-DS and CA-CL suffer from vulnerabilities that could enable users to escalate their privileges and perform administrative functions.
SAP also issued three other critical Security Notes. Two of these deal with programming errors in the SAP User Management Engine (BC-JAS-SEC) and other components of the NetWeaver Web AS Java. This manages Web-based access to SAP applications such as the Enterprise Portal. Note 1651004 is designed to protect the UME from cross-frame scripting (XFS) attacks that could be used to the steal the logon credentials of SAP users. You can learn more about XFS here. Note 1641208 deals with signature wrapping attacks that target XML messages transmitted through certain SAP Web services. This attack can be used to intercept and manipulate a message without breaking the digital signature designed to protect the integrity of the message and its content. It could enable attackers to modify the data within XML messages without detection.
The last vital patch released by SAP in April was Note 1652803 which fixes a Denial of Service (DoS) vulnerability in certain versions of Apache Tomcat bundled with Business Objects Enterprise. Tomcat is an open source web server that provides a runtime environment for Java code. Business Objects Enterprise is the platform that supports SAP reporting tools such as Crystal Reports, Web Intelligence and the Dashboard Builder.
SAP uses the Common Vulnerability Scoring System (CVSS) system to rate Security Notes. Three of the five critical vulnerabilities patched in April have a base score of 7.5. The highest possible score is 10.0. SAP did not provide CVSS information for the other two. This is fairly common. SAP doesn’t consistently provide CVSS scores for all Notes.
The Advisory below includes a complete listing of all of the Security Notes issued by SAP last month. Particular attention should be paid to 1657200, which is designed to patch a flaw in an SAP component responsible for managing payment cards, and the injection vulnerability patched by 1638596.
There are several myths in ERP security. One of the most common is that security is largely a matter of controlling access and segregation of duties. Another is that business applications are accessible only within internal networks. Yet another is that such applications are not a target for attack. All three are based on a simplistic and misguided take on today’s ERP systems.
The reality is that contemporary ERP systems have a highly complex structure. Complexity is the enemy of security. Vulnerabilities can be found not only in the business or application layer (which is the traditional area of focus for ERP security practitioners) but the technical layer that includes database, operating system and network components. A Fort Knox approach for the application level will provide a false sense of security if architectural, configuration and programming flaws are not addressed at the technical level.
This is compounded by the fact that most ERP instances have more than one attack surface. Almost all have direct or indirect connections to the Internet. The former includes connections to external offices, suppliers, vendors or other partners and to SAP services. The latter can include connections to user workstations with Web access. ERP resources are increasingly designed to be accessible by mobile users using Web-based protocols, ports and services. The isolated mainframes of yesteryear are a distant memory in our era of global communications.
Vectors for attack surfaces in ERP systems are generally well-known. What’s more, most can be performed with low-spec laptops and minimal technical knowledge. The idea that very few people have any motive to attack such information-rich systems is one of the most disturbing and perplexing myths in ERP security. I’m reminded of a comment that was made to me by a prominent partner in a well-known consulting firm. The partner was engaged as a security advisor by a large meat processing company during an otherwise successful SAP implementation. In his view, the client had a relatively low risk profile which justified a ‘vanilla’ security framework for its SAP systems. As a result, the company was urged to stick with SAP defaults, wherever possible.
The leads to the fourth and most damaging myth in ERP security: the notion that systems are securely configured by default and, where they are not, it’s the responsibility of the vendor to secure the system. ERP systems are designed to be flexible. They have to be capable of meeting the diverse needs of every imaginable business in all industries and sectors. As a result, there is no standard configuration that can meet the requirements of every business. Security has to be enabled. Default security settings are often highly dangerous and can leave organizations open to internal and external attacks. For this reason, SAP has issued numerous white papers, security guides and other publications to support the secure configuration of its software during and after implementation. This should be required reading for all security professionals specializing in SAP.
SAP does not take responsibility for security issues arising from architectural flaws, misconfigurations and inadequate patching. Customers are expected to design, manage and maintain their systems in a secure manner. This can prove to be a challenge in companies where there is no clear ownership over SAP resources or in cases where systems are owned by business departments that lack the technical skills to effectively manage ERP security. In these scenarios, business owners should take steps to share ownership with IT functions, especially technical resources within their organization that are more accustomed to dealing with infrastructure or platform-level security. There is often a strong relationship between the strength of SAP security in organizations and the degree of partnership between business and IT.
On January 16, SAP issued a revamped version of the whitepaper Secure Configuration of SAP Netweaver Application Server using ABAP, which is rapidly becoming the de-facto standard for securing the technical components of SAP. According to SAP, the guidance provided in the whitepaper is intended to help customers protect ABAP systems against unauthorized access within the corporate network. In fact, many of the recommendations can also be used to protect SAP systems against remote attacks originating outside such a network. These attacks are targeted at the technical components of SAP Netweaver that are responsible for managing user authentication, authorization, encryption, passwords and system interfaces, as well as underlying databases and operating systems. Breaches in these components can enable attackers to take complete control of an SAP environment.
The following is a quick guide to help you comply with SAP’s recommendations.
1. Disable unnecessary network ports and services. In most cases, this means blocking all connections between end user networks and ABAP systems other than those required by the Dispatcher (port 32NN), Gateway (33NN), Message Server (36NN) and HTTPS (443NN). NN is a placeholder for your SAP instance number. Administrative access should only be allowed through secure protocols such as SSH and restricted to dedicated subnets or workstations through properly configured firewall rules.
2. Install the latest version of SAP GUI. This should be 7.10 or 7.20 with activated security rules configured with the ‘Customized’ setting and the ‘Ask’ default action.
3. Implement strong password policies, restrict access to password hashes in tables and activate the latest hashing algorithms. SAP does not specify the exact settings for password policy parameters but you should use frameworks such as the PCI DSS as a proxy. Refer to section 8.5 of the standard. Default passwords should be changed for standard users and the password hashing mechanism should be upgraded to the latest version available for your system. Wherever possible, downward-compatible hashes should be removed from the database.
4. Enable SNC and SSL. SAP client and server communication traffic is not cryptographically authenticated or encrypted. Therefore, data transmitted within SAP networks can be intercepted and modified through Man-In-The-Middle attacks. Secure Network Communication (SNC) should be used for mutual authentication and strong encryption. This can be performed natively if both servers and clients run on Windows. You will need to use a third party product to secure connections between heterogeneous environments such as AIX to Windows.
SNC will secure network communication using the SAP DIAG and RFC protocols. For Web-based communication, you should switch to HTTPS/ SSL and restrict access to the relevant cryptographic keys.
5. Restrict ICF services. Many of the services enabled by default in the Internet Communication Framework (ICF) are open to abuse and could enable unauthorized and malicious access to SAP systems and resources. At a very minimum, you should deactivate the dozen or so services mentioned by SAP in the white paper. This can be performed through transaction SICF.
6. Secure Remote Function Calls (RFC). Wherever possible, remove trust relationships between systems with differing security classifications and hardcoded user credentials in RFC destinations. The belief that RFC connections using SAP_ALL privileges is fine as long as the user type is not set to dialog is a myth. This represents a serious risk to the integrity of information in SAP systems.
7. Secure the SAP Gateway. The Gateway is used to manage RFC communications which support SAP interfaces such as BAPI, ALE and IDoc. Access Control Lists (ACL) should be created to prevent the registration of rogue or malicious RFC servers which can lead to the interruption of SAP services and compromise data during transit. You should also enable Gateway logging and disable remote access.
8. Secure the SAP Message Server. The Message Server is primarily a load balancer for SAP network communications. Similar to the Gateway, it has no default ACL which means it is open to the same type of attacks. You should filter access to the Message Server port using a firewall and create an ACL for all required interfaces.
9. Regularly patch SAP systems. Implement missing SAP Security Notes and patch systems at least once a month. Security Notes can be downloaded from the SAP Service Market Place.
10. Regularly monitor the SAP security configuration. Standard SAP services such as EarlyWatch (EWA) and the Computing Center Management System (CCMS) can be used to monitor some security-relevant configurations. However, they do not provide the same coverage as professional-grade security tools such as those used by Layer Seven Security. You can learn more about SAP security monitoring through vulnerability assessment here. To discover why vulnerability assessments should be an integral component of your SAP security framework, click here.
The answer is when your Legal department is managing the fallout after a data breach. The case in point is the Utah Department of Health which announced this week that over 280,000 records belonging to Medicaid and CHIP recipients were compromised after a breach last week believed to be perpetrated by a group in Eastern Europe (http://www.health.utah.gov/databreach).
The group exported 25,000 files containing personal information including social security numbers, belonging to hundred of thousands of individuals. According to the Department, the breach was caused by “a configuration error at the authentication level of a server’s multilayer security system.” This seems like a rather euphemistic way of saying the server had a default password that the attackers were able to exploit. The Department states that it has implemented ‘corrective measures’ which presumably includes changing the password. It has also offered free credit monitoring for those effected by the breach.
To learn how to manage default users and passwords in SAP systems, download our free white paper at http://layersevensecurity.com/SAP_security_white_papers.html.
IBM released an advisory in February for a Denial of Service (DoS) vulnerability in AIX versions 5.3, 6.1, and 7.1. The warning seems to have flown under the radar since so far, many companies running the effected AIX OS platforms for their SAP environments have yet to deploy the patch. The vulnerability relates to a flaw in ICMP packet handling. An ICMP echo reply with ID=1 can lead to a DoS. ICMP is part of the Internet Protocol Suite and can be used to relay query messages. Echo reply is a ping utility that can be executed remotely with no authentication and very little complexity. The vulnerability has a CVSS base score of 7.8 and exploitability sub-score of 10 which means it is rated as extremely dangerous. The relevant security update can be downloaded directly from IBM through ftp://aix.software.ibm.com/aix/efixes/security/icmp_fix.tar. Technical information is available at http://www-01.ibm.com/support/docview.wss?uid=isg1IV08255.
Earlier today, Microsoft issued a statement that declared that the financial information belonging to customers of its online store in India may have been compromised by the recent attack perpetrated by a Chinese group called the “Evil Shadow Team.”
It is widely believed that this information was stored in clear text in databases raided by the group. The Evil Shadow Team may also have breached the supposedly secure gateway handling the payment process. In an original statement issued shortly after the attack, Microsoft had claimed the group had only compromised login IDs, passwords and possibly shipping addresses. However, after further investigation, it appears that the damage was far worse. Two weeks after the attack, the online store is still down, suggesting there are serious issues with the site.
To learn how to secure SAP systems against similar attacks, read our whitepaper.
SAP’s acquisition of SECUDE in 2011 is finally bearing fruit. Recently, SAP announced the launch of Netweaver Single Sign-On 1.0 which can be downloaded from the Service Marketplace. This is the latest addition to SAP’s identity and access management portfolio and is based on SECUDE’s Secure Login and Enterprise SSO solutions. It uses protocols such as Kerberos, X.509 and SAML to enable mutual authentication between not only SAP applications but between SAP and legacy systems. It also supports cross-company authentication between different domains. This is achieved through federated identity systems based on a choice of IDP or STS, which is used to issue and verify security tokens.
SSO aligns well with SAP’s ambition to ‘help companies run better’. It does so by seamlessly integrating people, processes and technology without the inconvenience of multiple logons. It also lowers the Total Cost of Ownership (TCO) by reducing the burden on Helpdesks that spend an inordinate amount of time helping locked-out users reset their passwords. According to research performed by the META Group (now owned by Gartner) 20-50% of all support calls are caused by forgotten or expired passwords. The cost to manually reset passwords ranges from $15-30 per call, and on average, users call help desks with a password problem 4 times a yearâ€. Forrester Research estimates the average cost is closer to $70. This should give SAP a leg up over the competition, not that it needs it, judging by the latest results.
For security folks, the case for SSO is less clear cut. While it enables companies to standardize and enforce stricter password policies to legacy systems, simplify administration and reduce the risk that users will write down credentials needed to logon to different systems, SSO has some serious drawbacks.
Firstly, implementing SSO is no picnic. Retrofitting legacy systems can be a nightmare. Secondly, since SSO only deals with authentication and not authorization, the administrative gains are minimal: somebody still has to setup privileges for every new user. Privileges are rarely synchronized between systems.
Thirdly, it creates a single point of attack. This is by far the most serious concern with SSO which delegates authentication to a single, central Identity and Access Management (IAM) system. IAMs are attractive targets for attackers, especially when they provide direct access to information-rich SAP systems. Attack vectors used to compromise SSO logins and passwords range from cross-site scripting, phishing to social engineering and have been successfully deployed against SSO schemes used by tech giants such as Google, Facebook and Twitter. A special mention should be given to Denial of Service (DoS) attacks. Note that SSO intensifies the damage caused by DoS against an IAM since it impacts every system relying upon the IAM for authentication.
Clearly, SSO is a double-edged sword. To realize the benefits, you have to manage the risks. This should include multi-factor authentication and hardening of all systems in the SSO environment. The latter should include regular patching, client-side security such as SNC encryption for SAP GUI traffic and host-level vulnerability assessments. You can learn more about SAP vulnerability management here.