Layer Seven Security

SAP Cybersecurity Framework 2.0: What’s New?

Layer Seven on January 14, 2015

Since the official release of the SAP Cybersecurity Framework in 2014, the standard has become the de facto benchmark for securing SAP systems from advanced cyber threats. Drawing upon guidance issued directly by SAP, as well as the real-world experience of front-line SAP security architects and forensic investigators, the framework delivers a single point of reference to harden SAP systems from cyber risks. It enables enterprises to counter weaknesses in perimeter controls such as network firewalls and intrusion detection systems by securing the technical infrastructure of SAP systems. Vulnerabilities in such infrastructure could be exploited to bypass perimeter controls and corrupt or leak sensitive business information or perform denial of service attacks in SAP systems.

The threat posed by attackers that seek out and exploit vulnerabilities has reached epidemic proportions. By all measures, attacks are growing in frequency and sophistication. The number of threat actors is also increasing, ranging from organized gangs of cyber criminals to hacktivist groups and state-sponsored agents. Finally, the impact of cyber attacks has reached new levels. The cost of a successful data breach is no longer measured in purely monetary terms. Recent experience has demonstrated that the impact can be strategic and long-lasting.

The SAP Cybersecurity Framework fills the void created by weaknesses in perimeter security and the limitations of GRC software that focus exclusively on the SAP authorization concept. It empowers organizations to better understand and respond to lesser known risks in the technical components of SAP systems to greatly reduce the likelihood of a system breach. It also enables enterprises to improve breach detection capabilities to respond more rapidly to attacks and contain the impact.

What’s more, the framework provides a clear path for securing SAP systems from cyber threats using only standard SAP-delivered software. It demonstrates that effective strategies are not necessarily tied to licensing third party solutions but leveraging the host of security tools made available by SAP to customers without any additional expense. This includes automated vulnerability detection and alerting tools available in Solution Manager. It therefore provides a powerful and cost-effective alternative to approaches that revolve around purchasing, installing and configuring solutions from independent software vendors.

The SAP Cybersecurity Framework 2.0 improves upon the original standard by incorporating new SAP guidance in areas such as trace functions to identify authorizations required for RFC users, enabling switchable authorization checks, whitelists for RFC callbacks, and approaches for identifying required security patches included in Notes and support packages.

Trace Functions
There are several limitations with analyzing log data in event logs configured in the Security Audit Log and transaction STAD for restricting permissions for RFC users. The former only record function groups accessed by users and the latter is resource-intensive. Therefore, SAP recommends using short and long-term trace functions through transactions STAUTHTRACE, STRFCTRACE or STUSOBTRACE. This approach will reveal the function modules accessed by users and consume fewer system resources than STAD.

Switchable Authorization Checks
Switchable authorization checks are intended to strengthen security for critical remote-enabled function modules that are used to access or modify sensitive data by requiring additional authorization checks above and beyond the standard S_RFC check. They are delivered via Notes and support packages but should only be enabled after relevant user profiles are updated to include the new authorizations. The DUO and DUQ event logs of the Security Audit Log should be activated and reviewed to identify the specific users requiring the authorizations during a non-disruptive logging phase.

RFC Callbacks
Positive whitelists for systems with later versions of SAP Basis have been introduced by SAP to control the dangers posed by RFC callbacks. Callbacks enable servers to open RFC connections in clients during synchronous calls using the privileges of the RFC user in the client system. A new profile parameter rfc_callback_security_method is used to enable the whitelists which are configured using SM59.

Security Notes and Support Packages
The framework no longer recommends the use of the EarlyWatch Alert and RSECNOTE for the identification of relevant Notes and support packages. Both components have severe drawbacks and are effectively deprecated by SAP. Security Notes and support packages should be identified using System Recommendations accessed through the Change Management Work Center in Solution Manager or via WDC_NOTE_CENTER through the Easy Access Menu.

The SAP Cybersecurity Framework is presented in the white paper Protecting SAP Systems from Cyber Attack.

SAP Security Architects at Layer Seven Security perform comprehensive gap assessments against the recommendations of the SAP Cybersecurity Framework and enable customers to implement defense in depth by hardening the entire SAP technology stack. The layered control strategy supported by the framework is based on best practices and SAP security recommendations and represents the most comprehensive, efficient and cost-effective approach to secure SAP systems from cyber attack. To learn more, contact Layer Seven Security.

Featured in SAPinsider: How to Build Security using SAP Solution Manager

Layer Seven on November 18, 2014

Data breaches occur all too often and organizations are frequently left blindsided. As a result, cybersecurity has become a board-level issue across all industries. According to a recent survey of global business leaders, cyber risk is regarded as one of the most significant threats faced by corporations today, and is consistently rated higher than legislation, regulation, and other risks.

Even SAP systems are not immune from the anxiety surrounding cybersecurity. The architecture and complexity of SAP landscapes, as well as the form and volume of data typically managed within SAP systems, makes them targets for attackers. This was illustrated by the discovery of a modified Trojan that was targeting SAP clients in 2013. The malware targeted SAP GUI configuration files and was capable of malicious activities such as logging keystrokes; capturing logon credentials; and identifying, copying, and exporting files.

Responding to such threats is a daunting challenge. However, SAP customers do not have to look far for the tools to secure their systems from cyber threats. In fact, SAP offers a variety of tools with standard license agreements that can be leveraged immediately at zero cost.

Read more at SAPinsider

How to Secure SAP Systems from Password Attacks

Layer Seven on November 4, 2014

Exploiting weak password hashes is one of the most common and successful attack scenarios used against SAP systems. The availability of open-source programs such as Hashcat and John the Ripper enables even novice hackers to perform attacks against SAP passwords. In fact, Hashcat is capable of breaking any SAP password encoded using the BCODE hash algorithm in a maximum of 20 hours, regardless of the length and complexity of the password.

SAP systems support a variety of cryptographic algorithms to convert passwords into hash values. These values are stored in table URS02. This is designed to prevent the storage of passwords in clear-text. During the logon procedure, passwords entered by users are converted to a hash value and compared to the value stored for the user in table USR02. The logon is successful if there is match between the two values.

Since hash algorithms are one-way, it is not possible to calculate passwords from hash values. However, it is possible to compare values generated by tools such as Hashcat to the values stored in SAP tables to break passwords providing both are encoded using the identical algorithm.

Therefore, it is critical to restrict the ability to read and extract password hash values in table USR02. This can be achieved by controlling direct access to database tables through SQL statements using firewall rules. The ability to read tables using generic table browsing tools accessible through transactions SE16, SE17 and SE11 should also be restricted and monitored.

Note that USR02 is not the only table containing password hash values. In some releases, hashes can also be found in tables USH02, USH02_ARC_TMP, VUSER001 and VUSR02_PWD. Such tables should be assigned to the authorization group SPWD (refer to Note 1484692). Access to table USRPWDHISTORY should also be restricted since attackers are often able to guess current passwords based on former passwords if users employ variations of the same password.

There should be similar restrictions on debugging and transport authorizations since these can also be used to access or export SAP tables containing password hashes.

Users with access to multiple systems or systems in different environments should be required to use different passwords for each system and environment. Passwords for productive systems should not be identical to those used to access development or test systems.

SAP password code versions A-E are based on the MD5 hashing algorithm. The hash values generated through this mechanism are stored in the table column BCODE. All MD5 hashes are susceptible to brute force and other password attacks. Code versions F and G use the SHA1 algorithm. SHA1 hashes are stored in the PASSCODE column. They are less vulnerable than MD5 hashes but can be broken if passwords are short and relatively non-complex. The most secure hashing algorithm supported by SAP systems is iterated salted SHA-1 in code version H. This mechanism uses random salts and a higher number of iterations to mitigate password attacks. Iterated salted SHA-1 hash values are stored in PWDSALTEDHASH.

SAP kernels should be upgraded to 7.02 or higher to support PWDSALTEDHASH hash values. For added security, default iterations and salt sizes can be increased using the login/password_hash_algorithm parameter.

Once this is performed, the profile parameter login/password_downwards_compatibility should be set to 0 to ensure only the strongest possible hash values are generated. CUA systems can be excluded from this requirement if they are connected to systems that do not support PWDSALTEDHASH.

The report CLEANUP_PASSWORD_HASH_VALUES should then be run to discover and remove redundant password hashes. There is a clear security risk if this is not performed. Attackers may be able to use passwords encoded in BCODE and PASSCODE hashes if users employ identical or similar passwords encoded in PWDSALTEDHASH.

Enforcing single sign-on (SSO) for all dialog users provides the optimal level of protection against password attacks by removing the need to store hashes altogether. However, once SSO is enabled, direct logons should be blocked through the parameter snc/accept_insecure_gui=U and by ensuring users are not exempted from SSO through settings in user records maintained in the SNC tab of SU01.

Taken together, these countermeasures should safeguard systems from dangerous password attacks aided by well-known and easily accessible tools that can be leveraged to take full control of SAP systems.

Update: A new version of Hashcat capable of cracking SAP code version H password hashes encoded using SHA-1 is currently in beta testing. You can learn more at http://hashcat.net/forum/thread-3804.html

A Five Step Guide to Securing SAP Systems from Cyber Attack Without Breaking the Bank

Layer Seven on September 30, 2014

With SAP solutions deployed by 85 percent of Forbes 500 companies, they are a prized target for cyber attackers. Watch our Webinar playback to discover how to secure your SAP systems against targeted cyber attacks that could lead to denial of service, financial fraud or intellectual property theft. The Webinar is hosted by John Corvin, a Senior SAP Security Architect at Layer Seven Security. The insights delivered during the Webinar are based on lessons learned from hundreds of front-line engagements, aligned with leading practices and SAP recommendations and delivered by experienced SAP security consultants. Learn how to:

Secure SAP networks and communications
Protect remote function calls
Control critical user authorizations
Build log forensics
Configure security-relevant parameters

The Webinar will also enable you to identify opportunities for your organization to continuously monitor the security of SAP systems using standard tools and components available in SAP Solution Manager without licensing costly third party software. This will empower your organization to unlock the potential of SAP software and maximize the ROI of SAP licensing, while minimizing software-related capex and opex.

 

Can’t access YouTube? Watch on Vimeo: https://vimeo.com/107386560

A Dangerous Flaw in the SAP User Information System (SUIM)

admin on August 13, 2013

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.

Exploring the SAP DIAG Protocol

admin on June 27, 2013

One of the most memorable events at last year’s BruCON in Belgium was Martin Gallo’s expose of the SAP DIAG protocol. The session can be viewed in its entirety below. DIAG (Dynamic Information and Action Gateway) is a proprietary protocol supporting client-server communication and links the presentation (SAP GUI) and application (NetWeaver) layer in SAP systems. During the conference, Gallo presented the findings of his ground-breaking research that led directly to the identification of several denial-of-service and code injection vulnerabilities arising from security flaws in the DIAG protocol, patched by SAP in 2012.

Most researchers have focused on identifying weaknesses in the compression algorithm that scrambles payloads and other data transmitted through DIAG. The most notable research in this area was performed by Secaron in 2009. Secaron demonstrated that it is possible to intercept and decompress DIAG client-server requests including usernames and passwords. Subsequent research performed by SensePost revealed that the LZC and LZH compression methods used by SAP for DIAG are variants of the Lempel-Ziv algorithm. Furthermore, since both methods are also used in the open-source SAP MaxDB, the compression and decompression code-base is publically available. SensePost created a custom protocol analysis tool in Java using MaxDB code capable of compressing and decompressing DIAG messages. The tool could be used to intercept, read and modify client-server traffic in SAP.

Gallo’s research provides an unprecedented insight into the inner workings of the DIAG protocol. The vulnerabilities revealed by the research can be exploited through both client and server-side attacks. Deep inspection of DIAG packets can be performed through the SAP Dissection plug-in developed by Gallo for Wireshark, a popular network protocol analyzer. The research underscores the importance of strong countermeasures in SAP systems. This includes restricting access to the Dispatcher service responsible for managing user requests, SNC encryption for client-server communication, disabling SAP GUI shortcuts used by attackers to execute commands in target systems, effective patch management, and periodic vulnerability assessment and penetration testing.

Securing Your SAP Systems: How to Counter Every Current and Emerging Threat

admin on May 31, 2013

One of the highlights of the Sapphire conference earlier this month was the insightful session on SAP security delivered by Gordon Muehl, Senior Vice President of Product Security at SAP. A recording of the session can be viewed below. The session highlighted the threat presented to Internet-enabled SAP systems by external agents and stressed the importance of protecting systems against Web-based attacks such as verb tampering. According to SAP, such measures should include secure software development procedures and training for developers, as well as independent code reviews performed by specialized security resources to validate programs before release. SAP also recommends a proactive patch management strategy that includes regular monitoring of SAP Security Notes and the rapid application of high priority patches.

Layer Seven Security leverage leading SAP-certified solutions to secure SAP systems against external threats, identify code-level vulnerabilities and detect critical missing Security Notes. To learn more, contact a representative now.

Securing Your SAP Systems: How to Counter Every Current and Emerging Threat

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.