Layer Seven Security

The Final Frontier: The Challenges in Developing Secure Custom ABAP Programs

admin on January 18, 2013

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.

SAP has responded by issuing a series of recommendations to customers to strengthen configuration settings in components of the NetWeaver AS. These can be found in the whitepaper Secure Configuration of the SAP NetWeaver Application Server Using ABAP.

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.

Download the Ultimate Guide to Auditing and Securing Procure-to-Pay Controls in SAP

admin on August 17, 2012

The third installment of Layer Seven Security’s SAP Audit Guide was released today and can be downloaded at http://layersevensecurity.com/SAP_audit_guides.html. The series has proven to be a popular resource for audit and security professionals with over 10,000 downloads to date. The latest Guide focuses upon expenditure-related controls in areas such as vendor master data, purchasing, invoice processing and payment processing.

Forthcoming volumes of the Guide will deal with areas related to inventory, human resource management and Basis. Although the Guide was originally intended to the cover ERP-related modules most commonly implemented by SAP clients, Layer Seven Security will develop and issue similar guides for components such as Customer Relationship Management (CRM), Supplier Relationship Management (SRM) and the Enterprise Portal (EP). Stay tuned for future releases and feel free to give us your feedback.

FTC Takes Action against Wyndham Worldwide after Data Breach

admin on July 13, 2012

Until recently, the fallout from the data breach at Wyndham Worldwide, owner of Ramada, Travelodge and a host of other hotel brands, followed an all too familiar path. Immediately after news of the breach reached customers in 2010, the company followed regular protocols by issuing an apology and committing itself to improving security procedures in an open letter to the public.

The tale took an expected turn last month when the Federal Trade Commission (FTC) filed a complaint against Wyndham, citing the company’s failure to protect customer information and comply with security measures outlined in its own privacy policy as the grounds for the complaint. It’s alleged that the data security measures outlined in the policy were misleading and deceptive and therefore, violated the FTC Act. In essence, the FTC claims Wyndham failed to live up to security standards implied in its privacy statements.

The FTC’s response seems to have caught everyone off guard, including Wyndham itself. In a statement issued shortly after the complaint was filed, the group stated, “We regret the FTC’s recent decision to pursue litigation, as we have fully cooperated in its investigation and believe its claims are without merit. We intend to defend against the FTC’s claims vigorously, and do not believe the outcome of this litigation will have a material adverse effect on our company… In a time when cyber attacks on private and public institutions are on the rise globally, safeguarding customer information remains a top priority at Wyndham Worldwide.”

Wyndham has good reason to be taken aback by the FTC’s decision. Organisations that fall victim to hackers are rarely sued by government agencies. In most cases, civil action through class action lawsuits is the extent of their worries. However, Wyndham’s case seems to have been too severe for the FTC to ignore. This may have little to do with the size of the breach. Even large data breaches can be overlooked if companies had established reasonable security measures prior to the compromise. Therefore, the $10M of fraudulent transactions attributed to the 600,000 records stolen through the three separate breaches that took place at Wyndham should not in itself have led the FTC to take action. The driving factor seems to be the nature of the vulnerabilities and the absence of basic security measures at the company. The FTC claims that Wyndham failed to establish perimeter firewalls, change default user IDs and passwords, maintain strong password policies and patch and update software to remedy security vulnerabilities. It also failed to establish internal-facing firewalls to segment local and corporate networks and encrypt payment card data in storage.

Wyndham Worldwide may take some solace from the fact that the FTC does not have the ability to levy financial penalties. If the complaint is successful, Wyndham will probably be required to upgrade its security and undergo regular third party audits. However, a Senate bill was recently introduced that would enable the FTC to impose fines in data security issues. The bill was promoted by the FTC itself which clearly is committed to a strong stance on such issues. The agency has sued or reached settlement with approximately 35 companies over the last ten years for misrepresenting data security measures. Prior to Wyndham, the most notable case was Twitter, which settled with the agency in 2010.

A Ten Step Guide to Implementing SAP’s New Security Recommendations

admin on April 19, 2012

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.

MasterCard confirms it will enforce the PCI DSS compliance deadline for Level 2 merchants

admin on March 1, 2012

As you probably recall, MasterCard issued a directive in 2009 that required all Level 2 merchants to comply with the PCI DSS through either a Self-Assessment Questionnaire (SAQ) prepared by a certified Internal Security Assessor or an assessment performed by a Qualified Security Assessor by June 30, 2010. Following an uproar from merchants, this was pushed back to June 30, 2012. The latest news is that MasterCard has every intention of sticking to this deadline. If you’re a Level 2 merchant with between 1 and 6 million MasterCard or VISA transactions per year, you should immediately contact your acquiring bank to confirm your SAQ or ROC reporting requirements.

PCI DSS Merchant Levels

PCI DSS Merchant Levels

Microsoft Hack Exposed Credit Card Details

admin on February 27, 2012

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.

The Hidden Danger of GRC

admin on February 4, 2012

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 whitepaper Perfect 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.

http://www.sap.com/solutions/sapbusinessobjects/large/governance-risk-compliance/index.epx

Approva

Alert Enterprise!

Security Weaver

Xpandion

CSI Tools