The misuse of administrative privileges is a common method used by attackers to compromise applications and propagate attacks to connected systems. The elevated privileges granted to administrative accounts are a prized target for attackers and provide a fast path to accessing or modifying sensitive data, programs and system settings.
User privileges for Java applications are administered through the User Management Engine (UME) in the SAP NetWeaver Application Server for Java (AS Java). The UME is the default user store for AS Java and can be configured to use LDAP directories, AS ABAP, or the system database of AS Java as the data source for user-related data.
UME permissions granted to users can include administrative actions such as Manage_All, Manage_Roles, Manage_Users, Manage_User_Passwords, and other privileged functions. Administrative actions are bundled into roles and granted to users organized into user groups. Standard user groups include the Administrator group, as well as groups such as SAP_J2EE_ADMIN and SAP_SLD_ADMINISTRATOR. The latter includes users with administrative access to the System Landscape Directory. Standard roles include Super Admin and, for Enterprise Portals running on AS Java, Portal System Admin, Portal User Admin and Portal Content Admin.
Access to administrative roles and rights in AS Java should be granted to required users only, based on the principle of least privilege. Users with administrative privileges in AS Java systems can be detected using the Cybersecurity Extension for SAP Solution Manager. The results are displayed in security reports and dashboards. Alerts are also triggered by the extension for new users granted privileged roles and actions for possible privilege escalations. The extension also detects users with administrative rights in ABAP and HANA platforms, as well as SAP-compatible databases including IBM, Microsoft, Oracle and Sybase.
Customers that have yet to implement Security Note 1844202 released by SAP on June 10 should do so immediately. The Note deals with a vulnerability that could be exploited to bypass monitoring controls designed to detect users with privileged access, including the SAP_ALL profile. This profile can be used to provide users with almost all authorizations in SAP systems. The vulnerability arises from a flaw in the coding of the RSUSR002 report accessible through the SAP User Information System (SUIM) or transaction SA38. RSUSR002 is a standard built-in tool used by security administrators and auditors to analyse user authorizations. A side-effect of Note 694250 was the insertion of the following line into the algorithm for RSUSR002:
DELETE userlist WHERE bname = “”
As a result of the insertion, users assigned the name “” are excluded from the search results generated by RSUSR002. This could lead to a scenario in which users are assigned SAP_ALL or equivalent authorizations without detection through regular monitoring protocols. However, the user “” would remain visible in UST04 and other user tables. The implementation of Note 1844202 will close the vulnerability in RSUSR002. Customers can also prevent the assignment of the username “” using customizing lists. For detailed instructions, refer to Note 1731549.
According to the Privacy Rights Clearinghouse (PRC), there were 680 reported data breaches in 2012 covering all forms of commercial, governmental, educational, medical and non-profit organizations. The breaches are estimated to have compromised over 27M data records.
The most significant breach occurred at VeriSign. Although the extent of the breach has never been disclosed nor, for that matter, the cause, the breach could potentially have an enormous impact on the ability of companies to establish secure connections to intended servers and verify the identity of those servers. This is because VeriSign is one of the principal issuers of SSL certificates used for encryption and mutual authentication. VeriSign also manages 2 of the world’s 13 root DNS servers, which control the complete database of Internet domain names and corresponding IP addresses. Although the breaches occurred during 2010, they were not disclosed by VeriSign until late 2011 when the company reported the incidents in public filings to the SEC. Guidelines issued by the SEC in 2011 now require registrants to “disclose the risk of cyber incidents if these issues are among the most significant factors that make an investment in the company speculative or risky“. A similar breach at the Dutch certificate authority Diginotar led the authority to file for bankruptcy in September 2011.
The second most significant data breach in 2012 was experienced by Global Payments, a large credit and debit card payments processor. The breach appeared to have stemmed from the compromise of servers in the company’s North American network but quickly spread to other areas of the network. According to initial estimates, approximately 1.5M records including Track 2 credit card data (card expiration date and credit card number) were directly exposed by the breach. This was later revised to 7M. Details on the cause of the breach have never been released by Global Payments. However, the company has disclosed that it has invested almost $85M on measures to improve security following the incident.
In the third major breach of 2012, a targeted phishing attack against employees at the South Carolina Department of Revenue led to the theft of usernames and passwords which were used by foreign attackers to access internal systems and other resources through remote services. Shortly thereafter, the attackers extracted over 8GB of data from the company through compressed database backup files. The files contained an estimated 5M social security numbers, 3M bank accounts and almost 400,000 credit card numbers. The attack may have been prevented through two factor authentication on remote access points. Furthermore, the damage would have been far lower had all the targeted data been encrypted.
Personal and financial records were also breached at the University of Nebraska, the fourth incident in the list. Banking information, social security numbers, addresses, grades and transcripts belonging to current and former students may have been compromised during a targeted attack against some of the organization’s databases.
The fifth and sixth incidents in the list did not involve the breach of financial data. However, they did involve the loss of hundred of thousands of customer records including social security numbers, drivers license numbers, dates of birth and employer information. Both breaches were caused by improperly configured servers. In the case of the Utah Department of Health, a default password had not been changed on one of the compromised servers. In both cases, the effected data had not been encrypted.
In the seventh most important data breach of 2012, an undisclosed vulnerability is suspected to have enabled unauthorized read-level access to a subscriber database at Intel. The database stored sensitive customer-related information including passwords, social security and credit card numbers in plain-text. However, there is reason to believe that the vulnerability was relatively short-lived and did not lead to the leakage of mass amounts of data, explaining the relatively low ranking of the incident. The group suspected to be responsible for the breach is also linked to similar breaches at NASA and US Bank in the same year.
The remaining incidents in the list involved the breach of large volumes of customer-specific data including names, addresses, phone numbers and email addresses from well-known e-commerce companies. In some cases, credit card data and passwords were also effected but the difference between these incidents and those placed higher on the list lies in the fact that sensitive data was encrypted. LinkedIn, for example, used SHA-1 to encrypt passwords. The exception is Yahoo!: over 400,000 were extracted from the company’s servers in plain-text through a SQL injection attack. All three organizations, Zappos, LinkedIn and Yahoo!, are subject to lawsuits for allegedly failing to properly safeguard user data.
Defense-in-Depth for SAP Systems
The incidents reviewed in this article cover a broad spectrum of organizations and industries. Clearly, the risk of data breach is no longer the sole preserve of e-commerce companies running custom-developed programs accessible to the general public through Web application servers. In fact, the most significant breaches effected enterprise systems designed principally for internal use. This should come as no surprise. Most system landscapes are highly integrated with multiple access points. This presents a large attack surface and provides opportunities to vault from compromised systems to connected systems by exploiting trust relationships and communication pathways required to successfully integrate applications in such landscapes.
SAP landscapes are a prime example of highly integrated environments supporting a variety of services through ports and protocols that include HTTP (80), HTTPS (443) and SMTP (25), commonly used by Web application servers. Therefore, SAP systems must be protected against the identical attack vectors that led to many of the data breaches discussed above. This includes methods such as SQL injection, exploitation of default passwords and configurations, and insecure system interfaces.
Protection should be applied at four distinct levels. The first is the authorization level. SAP systems contain thousands of authorizations that control access to various functions and resources. The improper assignment of authorizations can lead to the accumulation of access rights that may provide users with privileges beyond role requirements. Such privileges may be abused to compromise the confidentiality and integrity of information in SAP systems. Therefore, the proper assignment of authorizations and the maintenance of an adequate segregation of duties is the first pillar of SAP security.
The second area is the platform level which is comprised of two components. Â The first component is the secure configuration of the SAP NetWeaver Application Server. This includes network filters that restrict access to SAP services accessible from end-user networks, configuring ACL files for SAP Gateways and Message Servers, enabling SNC and SSL to encrypt network communications, robust password policies, the use of the latest password hashing algorithms, disabling and/or changing passwords for default users, disabling dangerous Web services, securing RFC connections, and regularly patching SAP systems.
The second component of platform level security is the configuration of underlying databases and operating systems in accordance with vendor-specific recommendations or generally-accepted security benchmarks. For example, Oracle databases supporting SAP systems should be secured in accordance with the comprehensive security guides issued by Oracle for each database version. In some cases, vendor-specific recommendations may conflict with SAP requirements. Therefore, recommendations must be applied carefully and selectively, wherever appropriate.
The third area is the program level. SAP programs should be protected against unauthorized changes. Furthermore, custom programs should be developed, tested and deployed in a secure manner to ensure they are not susceptible to code-level vulnerabilities. This includes missing or broken authorization checks, backdoors and rootkits, injection flaws, cross-site scripting, buffer overflows and directory traversals. An effective software development process including requirements for code reviews by appropriately trained resources could meet part of this requirement. However, SAP programs are more effectively controlled through tools that act as a firewall to prevent the deployment of vulnerable code and tools that detect and auto-correct suspicious statements in ABAP code. Currently, the only solution capable of performing both functions is CodeProfiler, developed by Virtual Forge.
The final area of a complete SAP security framework is client-level protection. For SAP GUI, this should include disabling scripting and recording, enabling SNC encryption, and appropriate security module settings. For browser-based access, SAP applications should be located in a trusted zone with less restrictive security settings. This will enable active scripting of Java applets required for certain SAP components without lowering the general security profile of browsers for untrusted connections. Client-level security should also include malware protection, Web filtering and restrictions on the administrative privileges of end-users.
The appropriate management of risks at all four levels in contemporary SAP environments (authorization, platform, program and client) will provide the defense-in-depth required to withstand sophisticated and determined attacks against SAP systems and minimize the risk of a data breach.
In November, SAP released an unusually high number of Security Notes to patch various forms of injection vulnerabilities in it’s software. The trend continued in December with the release of several patches for code injection flaws in the Computer Center Management System (BC-CCM), Project System (PS-IS), Transport Organizer (BC-CTS-ORG) and work processes in Application Servers responsible for executing ABAP programs (BC-CST). Given this alarming trend, this article is focused on discussing the challenges of developing secure ABAP programs for SAP systems, free of common vulnerabilities including not only injection flaws, but cross-site scripting errors, buffer overflows, directory traversals and backdoors and rootkits.
There are three attack surfaces in SAP systems. The first is through improperly defined and controlled application-level access. This attack surface is the most commonly known and understood by SAP customers. Today, most SAP clients deploy any one of a variety of access management tools to control access to sensitive functions and maintain a strict segregation of duties in their ERP systems. This manages the risk of unauthorized access through inadequate authorization structures that grant excessive or conflicting privileges to users and administrators.
The second attack surface lies at the platform level. This generally refers to components of the NetWeaver Application Server, also referred to as the Basis area of SAP systems. The NetWeaver AS is the technical foundation of the entire SAP software stack. It provides the runtime environment for SAP applications and includes work processes for ABAP and Java programs, gateways and modules for managing RFC, Web-based and other forms of communication protocols, tools to manage user roles, profiles and authorizations, and utilities that control certain database and operating system functions. The secure configuration and management of the NetWeaver AS is a vital component of a comprehensive SAP security strategy. However, the results of our security assessments repeatedly reveal common vulnerabilities in basis settings in most SAP environments. This provides a lush attack surface to internal and external attackers looking for an avenue to manipulate or appropriate business data or deliberately disrupt the availability of SAP systems.
The third and final attack surface in SAP provides an even greater array of opportunities for attackers. This surface exists at the program level. ERP systems such as SAP are designed to perform thousands of distinct functions ranging from, for example, adding a vendor to a list of approved suppliers, performing a transport to implement a change in a specific system, or encrypting/ decrypting traffic between servers or clients. These functions are performed by programs stored in the database table known as REPOSRC that are called when requested by work processes in the NetWeaver AS.
SAP programs are developed using two distinct programming languages: Advanced Business Application Programming (ABAP) and Java. Both are vulnerable to coding errors that could expose SAP programs to exploits such as code, OS and SQL injection, cross-site scripting, cross-site request forgery, buffer overflow, directory traversal and denial of service. SAP programs are also susceptible to missing or broken authority-checks that could lead to unauthorized execution of programs. Finally, SAP programs can contain backdoors through hardcoded credentials that bypass regular authentication and authorization controls, as well as malware known as rootkits that provide attackers with remote, privileged access to system functions and resources.
SAP performs a rigorous code review for all standard or delivered programs prior to release. However, some of the vulnerabilities present in the code base are not detected and patched until after release. Security Notes are therefore an important mechanism used by SAP to patch vulnerabilities arising from programming errors.
Custom programs are rarely subject to the same level of scrutiny applied by SAP to standard programs. Programs developed by in-house or off-shore developers to meet the needs of customers not met by standard SAP functionality are often laden with vulnerabilities that, when exploited, undermine the integrity of entire SAP landscapes. Such landscapes are only as strong as their weakest point. A robust application layer fortified with GRC tools has led attackers to shift their focus to the platform and code level. Given the relative openness of most SAP systems at the technical level, the strategy is proving to be profitable.
However, understandably SAP is less vocal on development procedures for custom programs since this is generally the responsibility of each SAP customer. The challenge should not be underestimated. Although manual code reviews to detect common vulnerabilities are theoretically possible, the skill-set to effectively review custom code is not only rare but expensive. Furthermore, it often leads to an increase in development time. Customers should consider investing in code scanning tools that are tuned to detect suspicious statements in ABAP code and integrate directly into the SAP Transport Management System (TMS). Such tools should also be capable of auto-correcting ABAP statements to minimize resource requirements and the impact on existing development times. Presently, the only tool capable of detecting and auto-correcting vulnerabilities in custom ABAP programs, with direct integration with SAP TMS, is Virtual Forge CodeProfiler. To arrange a security scan of custom programs in your SAP environment using CodeProfiler, please contact a representative at Layer Seven Security.
Does anyone remember the world before GRC? I know it seems like decades ago but the fact is solutions such as SAP GRC are a relatively new phenomenon. Until recently, most of us were working with SU01 and SUIM. While such tools have undoubtedly made life easier for administrators and auditors alike, there’s a hidden danger associated with their use that I’ve observed over and over again when clients rely too heavily on them to secure their environments.
Before we get to that, here’s a brief survey of GRC platforms for readers looking to adopt or switch solutions:
Today’s GRC landscape is far more complex than a simple toss-up between Approva and SAP GRC (formerly Virsa). Although these platforms remain the most popular among large companies with thousands or even tens of thousands of users, the market includes a number of new upstarts that are worth considering if you’re looking to save some serious dollars without sacrificing functionality. This includes Alert Enterprise, Security Weaver, Xpandion and CSI Tools (the links are provided below). All of these vendors offer a suite of scalable applications designed to provision user access, monitor segregation of duties in real time and automate user access reviews.
The pros and cons of the different platforms depend upon what you’re looking for. However, one very important piece of advice is to define your requirements very clearly and stick to them throughout the selection process. This way, you won’t be swayed by clever marketing that offers you bells and whistles you’ll never use. I’ve lost count of the number of times I’ve seen security and audit groups buy vast GRC suites to monitor everything in sight when in fact all they really needed was a basic tool to check their authorizations once a year or, at best, every quarter. Truth be told, if this is what you’re looking for, you should consider sticking with SAP SUIM. It may be so slow and cumbersome, but it gets the job done for next to nothing.
There’s also another important benefit to persevering with standard SAP functions that’s often overlooked: working directly with SAP builds a familiarity and depth of understanding of your environment that’s hard to form when you’re dealing with SAP through GRC tools. It also requires more intellectual effort and therefore forces users to develop their investigative skills rather than rely upon canned queries and reports.
In the grand scheme of things, these are minor drawbacks. We could just as easily argue that the enormous time and effort freed up by GRC tools allows resources to be devoted to more value-added areas. True, but there is a far bigger concern that can’t be so easily dismissed.
In the minds of those that administer GRC tools, the very notion of what is and isn’t SAP security is closely associated with the scope of the software they use. In other words, these tools shape our conception of security. Time and again, we are lulled into a false sense of security because of the rosy picture painted by GRC software. Often, this turns out be a mirage when we are forced to widen our paradigm to include the security of technical components of SAP that are beyond the scope of these programs. SAP security is about more than authorizations. It’s even deeper than Basis. In fact, it reaches down into the very kernel of SAP. It includes areas that are new to the SAP landscape and others that are often simply overlooked or underestimated. Many of these areas are discussed in our whitepaperPerfect Storm: The Brave New World of SAP Security. The moral of the story is that the results of GRC tools should be taken with a pinch of salt. Locking down critical authorizations, users and configurables doesn’t mean that your SAP systems are secure or even compliant with SOX, PCI or other standards. It’s only a small part of a broader security strategy that should include managing the technical components of SAP Netweaver that can be highly vulnerable to internal and external attack.
