Layer Seven, Author at Layer Seven Security

How to Block RFC Callback Attacks in Your SAP Systems

Layer Seven on March 23, 2016

Callback attacks exploit weaknesses in RFC security to execute function modules in calling systems. The impact of such attacks can be severe, ranging from the creation of dialog users with system-wide privileges to modifying or extracting sensitive data. This can occur if client systems execute malicious code within the function modules of connected systems. In the following example, the source code for the standard function module RFC_PING within a compromised system has been modified to create a new user with the SAP_ALL profile in any client system that connects to the system and calls the function module to perform a connection test.

The called system will exploit the callback functionality of RFC calls to firstly execute the BAPI_USER_CREATE1 function module to generate the dialog user in the calling system and secondly, run the BAPI_USER_PROFILES_ASSIGN function module to assign the SAP_ALL profile to the new user. Once this is complete, the attacker will be able to logon directly into the calling system with the new user. Since this is performed in the background, administrators that perform the connection test from the calling system would not be able to detect the exploit based on a review of the test results returned by the system (see below).

Callback attacks can be exploited to hop from development or test systems to productive systems by exploiting insecure RFC destinations between systems in different environments. Such attacks rely on the privileges of RFC users in client systems. Therefore, it’s important to restrict the authorizations of technical users to the minimal required for each scenario.

They also count on the ability to call any function module within client systems to run exploits. This should be controlled by enabling positive whitelists for RFC callbacks. Whitelists are controlled by the profile parameter rfc/callback_security_method. Empty whitelists should be enabled by default for all new RFC destinations. For existing destinations, rfc/callback_security_method should be set to 1 and the DUI event should be enabled in the Security Audit Log. This will log RFC callbacks executed within the system. The called function modules are displayed in the message text (see below).

The log results are available in RFC destination maintenance using transaction SM59. Administrators can use the log results to automatically generate whitelists for permitted callbacks to specific function modules for each destination. Once the whitelists are generated, rfc/callback_security_method should be set 2 to enable the whitelists in simulation mode. At this point, the DUJ event should be enabled in the Security Audit Log to record rejected RFC callbacks. The log results should be periodically reviewed to update the whitelists before finally activating all whitelists through rfc/callback_security_method=3. Once activated, callbacks to function modules outside the whitelists are rejected by client systems (see below).

Survey Reveals 65 percent of SAP Platforms Were Breached Between 2014-15

Layer Seven on February 26, 2016

Earlier this week, the Ponemon Institute released the results of the most comprehensive study performed to date on the state of SAP cybersecurity. The Institute is widely known for the annual Cost of Data Breach report that trends average data breach costs across major countries. However, it also performs a variety of other studies related to privacy, data protection and information security. It’s latest study Uncovering the Risks of SAP Cyber Breaches reviews the challenges and perceptions associated with securing SAP platforms. The study surveyed over 600 IT and security professionals between December 2015 – January 2016.

The key findings of the study include:

65% of SAP platforms suffered one or more security breach over the prior 24 months. 32% experienced between 1-2 breaches. 16% were breached 3-4 times and 12% between 5-6 times

75% of respondents believe it is likely their SAP platforms have one or more malware infection

The impact of an SAP breach is serious to catastrophic in 92% of organizations

The average cost of a breach that interrupts the availability of SAP systems is $4.5M

47% of respondents expect the volume of cyber attacks against SAP systems to increase over the next 24 months. 42% expect no change. Only 11% expect a decrease

75% express low levels of confidence in their company’s ability to immediately detect an SAP breach. 65% believe they would not be able to detect a breach within one week and 59% doubt they would be able to detect a breach within a month

59% expect trends such as the cloud, mobile, big data and IoT to increase the attack surface and the probability of a breach in SAP systems

The ability to assess and audit compliance levels of SAP systems against security policies and standards is considered important by 78% of respondents

81% believe it is important to continuously monitor the security of SAP platforms

54% of respondents supported the statement that it is the responsibility of SAP, not their organizations, to safeguard the security of SAP software. The reality is that the responsibility is shared. SAP is responsible for ensuring the integrity and security of software code. To this end, SAP works diligently to detect and remove programming errors before and after the release of applications. However, the responsibility for implementing patches for programming and other errors lays exclusively with the customer.

SAP is also accountable for providing guidance to securely configure its systems and counteract known vulnerabilities and attack vectors. Recommendations for dealing with RFC exploits, password attacks, standard users, vulnerable Java and ICF services, and numerous other areas can be found in online SAP security guides, as well as SAP advisories and papers such as the Secure Configuration of SAP NetWeaver Application Server using ABAP and Securing Remote Function Calls.

Finally, SAP is responsible for providing customers with the tools to secure their infrastructure. This includes tools for identifying and applying security patches, performing continuous and automated audits for vulnerabilities that may be exploited to breach systems, and supporting real-time threat detection and response. SAP’s product portfolio includes tools to meet all of these needs. Patch management can be performed using System Recommendations. Vulnerability management for over 500 vulnerabilities impacting ABAP, Java and HANA systems can be accomplished using Configuration Validation. Customers can leverage these tools within their Solution Manager platforms without resorting to third party software solutions. For real-time threat management, customers can deploy Enterprise Threat Detection. Alternatively, they can integrate their SIEM platforms directly with SAP systems using adaptors or indirectly using agents.

Cybersecurity Targets in China’s New Five Year Plan

Layer Seven on February 19, 2016

The details of China’s latest five year plan covering the period between 2016-2020 are expected to be released next month but early indications suggest it will focus upon reducing China’s reliance on foreign technology. Intelligence agencies and security researchers contend there is a strong correlation between industries targeted for growth by China and industries that suffer data breaches as a result of targeted attacks. For example, China’s last five year plan covering 2010-2015 focused upon sectors such as energy, healthcare and manufacturing. Over the same period, companies within these sectors experienced large-scale breaches that bore the hallmark of state-sponsored attacks. This includes organizations such as Anthem, US Steel, Medtronic and Westinghouse.

Since the new five year plan will launch during a period of unprecedented low growth in China, it is expected to lead to even more aggressive economic espionage in the form of cyber attacks against sectors targeted by China. This is likely to accelerate the shift from cyber attacks performed by criminal gangs for financial motives to state-sponsored cyber espionage driven by the strategic objectives of nation states.

According to the recently released Global Threat Report from CrowdStrike, the industry most at risk from China’s attention is energy. The new five year plan is expected to include objectives for building more nuclear power facilities, clean energy technology, and reducing China’s dependence on foreign oil. Next in line is transportation as China seeks to expand its airline and high speed rail industries, and domestic car production, including support for electric and hybrid transportation. Third is the public sector. China is expected to increases efforts to target foreign governments and think tanks in order to further its national interests. Fourth is the defense industry, particularly weapon systems, military personnel information, logistics, and technology related to aircraft carriers and drones. Fifth is the technology sector including the semiconductor industry, software source code, and social media applications that China is looking to replace with domestic versions. Other industries that are expected to feature heavily in the plan are healthcare, telecommunications, finance, manufacturing, media and agriculture. The Global Threat Report is available at crowdstrike.com.

Managing Security with SAP Solution Manager

Layer Seven on January 14, 2016

SAP Solution Manager is the second most widely deployed SAP product after ECC. In other words, there are more installations of SolMan in the world than there are for products such as BI, PI, CRM and SRM. This isn’t surprising when you take into account that SolMan is for IT what ECC is for business: it drives the entire system lifecycle including design, deployment and maintenance. It provides a centralized platform for monitoring system operations, managing changes, provisioning users, and a score of other core IT services. Yet, despite it’s versatility and widespread deployment, most organizations fall short of leveraging the full potential of SolMan. This is especially the case for system security.

Other than central user administration, earlywatch alerts, and system recommendations, most SAP customers are in the dark when it comes to other tools in SolMan that could be used to further security. This includes tools to manage and secure custom code (Clone Finder, Coverage Analyzer), identify security risks (SOS), and validate compliance using customer-specific security policies (Configuration Validation). The SAP paper Managing Security with SAP Solution Manager is intended to bridge this gap by informing customers how to realize the potential of SolMan for security. According to SAP, SolMan’s deep connectivity into systems, it’s central position in each landscape, and its link to the SAP extranet provides the ideal platform for defining, implementing and sustaining secure system landscapes. The paper can be downloaded directly from SAP using this link.

What’s New in the SAP Cybersecurity Framework 3.0

Layer Seven on January 14, 2016

Released earlier this month, the third version of the SAP Cybersecurity Framework includes important changes in the areas of transport layer security, logging and monitoring, and vulnerability management. It also discusses the most significant hack against SAP systems to date: the devastating data breach suffered by U.S Investigation Services (USIS). USIS performed background checks on prospective federal employees for the Office of Personnel Management (OPM) and other government agencies before it’s contracts were severed after the announcement of the breach in 2015.

The breach is estimated to have impacted the personal information of up to 20 million individuals. According to the findings of an internal forensic investigation, attackers were able to breach systems at USIS by exploiting an undisclosed vulnerability in a connected SAP ERP system sometime in 2013. The attack went unnoticed by intrusion detection and other network-level monitoring devices. The specific vulnerability exploited by the attackers has been the subject of widespread speculation by security researchers. Some have argued that the breach was caused by a brute-force password attack. Others have pointed towards RFC exploits or unapplied security patches. The source of the breach could have been any one of these or a combination of other vulnerabilities. The wide attack surface presented by SAP systems makes it impossible to pinpoint the root cause without access to the log data. Regardless, the breach demonstrated the destruction that can be wrought by successful attacks against vulnerable SAP systems. The contracts lost by USIS as a direct result of the attack were valued at $3 billion. The organization laid off 2500 workers and filed for bankruptcy shortly after the public announcement of the breach.

For transport layer security, the framework has been updated in line with RFC 7568 issued by the Internet Engineering Task Force (IETF) for deprecating Secure Sockets Layer Version 3 (SSL v3). SSL was the standard protocol for securing Web-based communication between clients and servers. Support for SSL has been gradually waning as a result of the growing awareness of weaknesses in its encryption scheme and key exchange mechanism. The POODLE vulnerability proved to be the final straw since it could be exploited to break encrypted SSL sessions and access sensitive data passed within such sessions including cookies, passwords and tokens.

The new version of the Framework includes an improved section on Read Access Logging (RAL). RAL should be configured to log access and changes by unauthorized users for sensitive data fields in SAP systems. This includes fields for banking, credit card and salary data. Exclusion lists can be maintained to rule out logging for authorized users. Together with the updated framework, you can also refer to an earlier Layer Seven article on protecting sensitive data in SAP systems using RAL for more information.

Lastly, much of the technical jargon related to Configuration Validation (ConVal) in earlier versions has been removed to focus on the core use-case for ConVal. ConVal is a powerful vulnerability management framework included in SAP Solution Manager that is recommended by SAP for managing vulnerabilities in SAP systems.

Since licensing for Solution Manager is included in SAP support and maintenance agreements, ConVal provides the most cost-effective alternative to third party tools.

You can download version 3 of the SAP Cybersecurity Framework in the whitepaper Protecting SAP Systems from Cyber attack from the Resources section.

Season’s Greetings

Layer Seven on December 15, 2015

As we near the end of the year, we would like to express our gratitude to the customers, partners and supporters that have contributed to another record year at Layer Seven Security. We look forward to relentlessly serving your cybersecurity needs in 2016 by securing your SAP assets and enabling you to maximize the value of your SAP licensing. Look out for our new white paper to discover how to integrate and monitor SAP log data with SIEM solutions and SAP ETD for real-time threat detection. Look out also for our new cloud-based Solution Manager as a Managed Service powered by SAP HANA.

We wish you a great 2016.

Layer Seven Security

Get Ready for SAP Solution Manager 7.2: What to Expect

Layer Seven on December 14, 2015

It’s well known that licenses for SAP Solution Manager are included in SAP maintenance and support agreements. However, with the release of version 7.2 next year, SAP will take this a step further by providing free licenses for SAP HANA for use with SolMan 7.2. Customer’s will still have to pay for hardware costs but HW costs have been falling and there is the option for cloud services to avoid hardware costs altogether.

Other improvements in SolMan 7.2 include a streamlined architecture requiring fewer integrations and system resources and delivering faster processing times. Depending upon the implementation scenario, customers will be able to lower SolMan running costs by up to 70 percent.

SolMan will also provide a vastly improved UI based on the Fiori Lauchpad and support access through Apple, Android and Windows mobile devices. Click on the images below to enlarge.

SolMan 7.2 will provide full support for HANA, S/4HANA, Cloud and Hybrid solutions, enabling customers to manage and monitor all SAP on-premise and cloud systems.

For security monitoring, we can expect improved reporting capabilities based on UI5 that do not require embedded BI or Flash, tighter integration between the SolMan frontend and BW Query Designer to support highly customizable reports, upgraded dashboards and alerts, and the ability to not only discover missing Security Notes for systems using SysRec but also identify the business processes impacted by the planned implementation of Notes. The latter will rely on solution documentation maintained directly in SolMan and a much improved Business Process Change Analyzer application that will integrate with Test Management to enable customers to develop, execute and review the results of test cases for planned changes.

SAP will remove maintenance for the current version of Solution Manager at the close 2017. Customers will have around 18 months to upgrade their Solution Manager platforms. The advanced performance and analytical capabilities offered by SAP HANA together with the major enhancements in Solution Manager 7.2 suggest that most customers will opt for early adoption. This will strengthen SolMan’s position as the premier solution for monitoring the security of SAP systems, providing the lowest total cost of ownership, unlimited flexibility and scalability, and unrivalled performance.

Are your System Users Vulnerable to SAP Hacks?

Layer Seven on November 24, 2015

One of the most telling statistics revealed at BlackHat USA earlier this year was the fact that 84 percent of InfoSec professionals regard unmanaged privileged credentials as the biggest cyber security vulnerability within their organizations. For SAP environments, the dangers posed by abusing user accounts with privileged access are well-known and can include shutting down SAP servers to interrupt the availability of services, reading or modifying sensitive information, and performing unauthorized changes to system configurations, programs, users, and other areas. For this reason, privileged access is carefully granted and vigilantly monitored in most systems, especially productive systems. This includes privileges assigned through powerful authorization profiles such as SAP_ALL, SAP_NEW, S_ABAP_ALL and S_A.SYSTEM.

However, countermeasures to prevent abuses of privileged credentials in SAP systems are usually focused upon dialog users since interactive logon is not possible with most other user types. This includes system users that are used for background processing. Therefore, it’s common to find system users with privileged access in productive systems, especially when such users support several cross-system connections and integration scenarios.

The risks posed by system users with privileged credentials should not be overlooked and can be as grave as those posed by dialog users. Attackers are able to modify user types from system to dialog in several ways. The most common method is through the Function Builder used to build, test and manage function modules.

Attackers can access the Function Builder through transaction SE37 in a connecting system to execute the BAPI_USER_CHANGE remote-enabled function module (RFM). This RFM can be used to implement user changes in destination systems. The changes are applied using a privileged system user in the destination system. The credentials for such users are often stored in RFC destinations configured in connecting systems. The relevant RFC destination is entered in the field RFC target sys of the Function Builder (see below). The username of the system user configured for the RFC connection is entered in the USERNAME import parameter. Finally, the values of the LOGONDATA and LOGONDATAX are maintained to specify the dialog user type.

Once executed from the connecting system, BAPI_USER_CHANGE will change the system user to a dialog user type in the destination system through a remote function call. This will enable the attacker to logon to the destination system through methods such as the Remote Logon option in the RFC destination maintained in the connecting system (see below).

Since attackers can bypass the restrictions placed on system users by abusing the privileged credentials provided to such users, it stands to reason that super user privileges should be managed for all user types, not just dialog users. This should include minimizing privileges for technical system and communication users to the minimum required for each scenario. Trace tools such as STAUTHTRACE, STRFCTRACE and STUSOBTRACE can be used to identify the authorization objects required for each user. This should be supported by enabling switchable authorization checks for sensitive function modules such as BAPI_USER_CHANGE, BAPI_USER_CREATE1 and BAPI_USER_PROFILES_ASSIGN, and, in NetWeaver releases 7.4X, enabling Unified Connectivity (UCON) to restrict external access to remote-enabled function modules.

RFC destinations with stored logon credentials can be identified using the config store RFCDES_TYPE_3 in Configuration Validation (ConVal). RFC users with critical profiles such as SAP_ALL can be identified using the store RFCDES_TYPE_3_CHECK. See below.

Monitoring SAP Security Metrics with SolMan Dashboards

Layer Seven on November 18, 2015

SAP Solution Manager (SolMan) includes a complete dashboard framework for visualizing data metrics and KPIs across a wide variety of areas. This includes areas such as availability, performance, service delivery, and crucially, system security. What’s more, the process for enabling and customizing dashboards is relatively quick and simple. This short guide walks through the steps to leverage the SAP-delivered dashboard apps in SolMan for security monitoring.

The first step is creating a link to the dashboard in the SAP Easy Access menu. Once you have logged into SolMan, right click on the Favorites folder and select Add Other Objects.

From the list in the Restrictions screen, choose Web-Dynpro Application.

Enter GENERIC_DASHBOARD_VIEWER in the Web Dynpro Applicat. field of the Web Dynpro Application screen.

Enter Security Dashboard in the description field.

Select HTTPS if applicable.

Within the Parameter table, enter ALIAS in the Name column and CIO_PERSONAL in the Value column. Click Save when complete.

The Security Dashboard link will now appear in your Favorites menu. Double click on the link to launch the dashboard in a browser. You will require the role SAP_SM_DASHBOARDS_DISP to access the dashboard, including the auth object SM_DBSINST.

The second step is configuring security apps in the dashboard. The welcome screen below is displayed the first time you access the dashboard. Select Configure in the top right of the screen and then Add new App.

Select the Cross-Application category. Click on the image below to enlarge.

Select and configure the following apps in sequence: Security Overview, Security Details, and Security List. You can learn more about these dashboard security apps at the SAP Help Portal.

Follow the steps below for each app.

Select one of the specified apps and click OK.

Enter a title for the app in the Header field. In the example below, we have configured the Security List app which displays the compliance status of systems by Software, Configuration, and User areas. The Software group includes checks for the release and support pack level of critical software components, kernel levels, and unapplied Security Notes. The Configuration group includes checks for security-relevant profile parameters, access control filters in operating system files such as sec_info and reg_info, client change settings, Security Audit Log filters, RFC destinations with stored logon credentials, trusted RFC connections, and active Web services. Finally, the Authorization group includes checks for users with critical authorization objects or combinations of auth objects, sensitive transactions, and powerful SAP-delivered profiles such as SAP_ALL. It also includes checks for standard users with default passwords.

The next step is to select the target system. This is the template that contains the baseline security policy used to check the compliance levels of systems in your landscape. You can select default templates such as 0SEC_NEW. However, best practice is to develop custom templates to perform checks for a wider array of vulnerabilities in SAP systems than covered by SAP-delivered defaults. Templates developed by Layer Seven Security, for example, perform over 500 vulnerability checks for ABAP, Java and HANA systems.

Once you have selected the target system, specify the comparison systems that should be monitored using the dashboard security app. In the example below, we’ve chosen to monitor the ABAP stack of the system SMP using the custom template in the virtual target system SEC_ABAP. This is a simplified example. In most cases, multiple systems should be selected for monitoring at the same time against a single target system.

Select Preview to sample the dashboard and then click Apply when done. Perform the configuration steps for the other security apps available in the SolMan dashboard. Save the Dashboard. Once complete, the dashboard should resemble the following:

The final step is to set the Auto Refresh frequency in the drop-down menu positioned in the top right of the dashboard. Once set, the dashboard will refresh as often as every 5 minutes for near real-time security monitoring.

How to Discover Missing Security Notes for Your SAP Systems using ConVal

Layer Seven on October 20, 2015

Earlier this month, the New York Stock Exchange released a definitive guide to cybersecurity targeted at directors and officers of public companies. Developed with Palo Alto Networks, the guide includes contributions from over thirty-five industry experts and contends with a wide range of questions including legal and regulatory issues, cyber insurance, supplier risks, and incident detection and response. It also discusses investor perspectives towards cybersecurity and cites a recent survey of 130 global institutional investors with an estimated $3 trillion under management that reveals 4 out of 5 institutions would blacklist the stocks of hacked organizations. The full report can be downloaded here.

According to the guide, cybersecurity risk management plans should include several critical countermeasures. One of the most important is effective patch management. In fact, the report points out that “system compromise and data breach are rarely the result of some sophisticated attack that no one has ever been seen before. The bulk of effective attacks use vulnerabilities that have been known for years…..Lack of patching and other standard security issues are normally the culprits” (p95).

This suggests that more active and rapid patching can significantly lower the risk of successful cyber attack. For SAP customers, this calls for the regular application of SAP-delivered security patches to address programming and other flaws. Security fixes are generally released by SAP on Security Patch Day, scheduled for the second Tuesday of every month. Corrections are packaged in Hot News, Security and Support Package Notes that are available through the SAP Support Portal.

There are several options for discovering relevant Security Notes for SAP systems. The first is directly through the SAP Support Portal using preconfigured filters for registered systems and products. Automatic email notifications can be setup through the Portal for newly released Notes.

The second is System Recommendations (SysRec). You can refer to our earlier post for guidance on how to Discover Security Patches for your SAP Systems using System Recommendations.

The third is a standard report available in Configuration Validation (ConVal). Although this approach draws upon SysRec, it consolidates missing SAP patches for all systems across landscapes. This is useful if you need to check the patch status of several systems at the same time. The instructions below provide a step-by-step guide for detecting unapplied SAP Security Notes using ConVal.

Step 1. Open Configuration Validation from the Root Cause Analysis or Change Management work center in SAP Solution Manager. Click on the image below to enlarge.

Step 2. Select the Reporting Templates option from the Report Execution tab.

Step 3. Select the report highlighted below and click ‘Start configuration reporting’.

Step 4. Maintain the filters for the report by selecting specific SAP System IDs (SIDs), system types, areas, and the date range. In the example below, we have selected Hot News and Security Notes released between Jan-Sep 2015 for all ABAP systems in the landscape. Click Execute when you are done.

Step 5. Analyze the results. In the report below, the table on the left provides a count of missing Notes by SID. The table on the right displays the unapplied Notes in each row against SIDs in each column.

The details of each unapplied Note are provided in the lower section of report. This includes version, description, priority level, and impacted application components. The results can be filtered by priority level to focus on Hot News and High Priority patches. Results can also be exported to .xls and other file formats for further analysis.