Layer Seven Security

Is SAP ASE the Most Vulnerable Point in Your SAP Landscape?

Layer Seven on May 24, 2023

SAP Adaptive Server Enterprise (ASE) is a widely-used relational database server for SAP solutions. As part of the drive to HANA, SAP is expected to withdraw support for third party databases including Oracle, IBM and Microsoft. Standard support for Oracle 19c, for example, will end in April 2024. Oracle 19c is the highest release of Oracle certified for SAP.  In contrast, maintenance and support for ASE is expected to continue beyond 2030. This includes both on-premise and cloud deployments. ASE is used within the SAP Cloud Platform and SAP HANA Enterprise Cloud for persistence services.

The database layer in SAP landscapes will increasing comprise of SAP HANA and ASE database systems. However, unlike HANA, security for ASE is often overlooked by SAP customers. As a result, ASE can be a vulnerable target for threat actors in SAP landscapes. This article will discuss the key aspects of ASE security and methods for automating vulnerability management, security patching and threat detection for ASE.

SAP ASE supports both password-based authentication for database users and external authentication using Kerberos, LDAP, or PAM. For password authentication, strict password policies are recommended governing password complexity, failures, expiration, and reuse. The transmission of passwords over the network layer should be secured using SSL through the FIPS 140-2 validated cryptographic module. For external authentication, it is recommended to enable message confidentiality, integrity and origin-checks to secure procedures for remote authentication.

ASE includes several pre-defined roles for provisioning required privileges to database users. They are managed using the sso security officer role. Access to this role should be restricted to authorized users. Other critical roles include the sa security administration role, and roles for operations, replication, job scheduling, web services, and system administration.

ASE also includes multiple default accounts that should be locked if not in use. This includes the accounts probe, sybmail, jstask, and mon_user. The sa account has system-wide privileges. The password for the account is blank on install. The account should be locked after the initial database configuration. The use of the guest account is not recommended since it inherits the permissions of the public role.

Remote users can be authorized to execute remote procedure calls (RPC) in ASE. Remote user IDs are mapped to local IDs by ASE to authorize access to RPCs. The use of remote users should be avoided.

Vulnerable services in ASE should be disabled to reduce the attack surface. This includes the extended stored procedures xp_cmdshell and xp_sendmail. Other stored procedures should be enabled to support enhanced security checks. For example, sp_extrapwdchecks should be activated to check for password reuse.

Column and table-level encryption can be enabled to protect data at rest. Encrypted data is transparent to applications and therefore does not impact operations. ASE supports the Advanced Encryption Standard (AES) encryption algorithm and 256-bit key lengths.  AES is a NIST-approved cipher standard.

Auditing is disabled by default in ASE. Once enabled, audit options should be activated to log specific events to the audit log. This should include auditing of the sa account and critical roles such as sso, configuration changes, login failures, role and account changes including user passwords, and the execution of stored procedures. It is also recommended to enable auditing for data binds, changes to encryption keys, and the importing/ exporting of data to/from external files.

Audit events are written to system audit tables. The tables can be read using SQL commands. Only select and truncate commands are supported for the audit tables. The event details include a unique event ID, timestamp, the ID of the account that performed the audited event, and the details of objects that were accessed or modified.

The Cybersecurity Extension for SAP leverages the database connectivity of SAP Solution Manager (SolMan) and SAP Focused Run (FRUN) to automatically detect security vulnerabilities in ASE installations that could be exploited by threat actors. This includes vulnerabilities in the following areas:

Settings for external authentication
Policies for password authentication
Users with critical roles
Disabling of default accounts
Remote users
Deactivation of vulnerable database services
Transport layer security
Database encryption
Auditing and logging

The Extension provides detailed recommendations to remediate vulnerabilities and harden ASE installations against targeted exploits.

Security notes for ASE are reported by System Recommendations (SysRec) in SAP Solution Manager. SysRec connects directly to SAP Support to calculate required notes. The Cybersecurity Extension for SAP integrates with SysRec to automatically identify and remove potential false positive notes based on installed application components. You can filters notes in SysRec for the ASE components BC-SYB-*.

The Extension also monitors ASE audit logs in real-time to detect and alert for potential breaches such as the use of default users that should be locked, changes to roles and user permissions, failed logins, locked users, database configuration changes including audit settings, successful calls to sensitive stored procedures, the installation of Java programs, password resets, remote procedure calls to/from external servers, the deployment of web services, and commands that transfer table contents to/ from external files.  

Alerts can be investigated using built-in incident response procedures and workflows.

Audit records are replicated from ASE installations to the Cybersecurity Extension for SAP to support archiving and forensic analysis and to protect against log corruption.

To learn more, contact Layer Seven Security.

Securing Microsoft Platforms with the Cybersecurity Extension for SAP

Layer Seven on November 23, 2022

SAP systems consist of multiple integrated technological layers. SAP solutions comprise the application layer. The application layer is supported by database and operating system layers. The layers are closely integrated to form a software ecosystem linked through several connections including trust relationships that bond the layers to form an SAP system. The layers are more tightly integrated in SAP HANA installations where application, database and OS functions can share physical resources.

Since SAP systems are comprised of multiple layers, security must be applied across all layers within a system. Threat actors can bypass secure SAP applications by targeting weaknesses at the database or OS level to compromise SAP systems. Ransomware, for example, can lead to a denial-of-service for SAP services by exploiting vulnerable operating systems. Application-level data protection mechanisms can be bypassed by exfiltrating data in SAP solutions directly from the database.

The need to secure databases and operating systems in SAP systems is more pressing when SAP applications are coupled with Microsoft platforms that are widely targeted by threat actors and suffer from a host of known vulnerabilities and exploits. The Cybersecurity Extension for SAP is the only security solution that secures all layers within SAP systems including databases and operating systems.

Together with over 2000 vulnerability checks for SAP solutions, the Cybersecurity Extension for SAP performs automated vulnerability scans for Microsoft SQL Server and Microsoft Server to detect more than 300 known security weaknesses in the platforms. This includes active vulnerable services that widen the attack surface for databases and hosts, authentication settings including password policies, file and table encryption, users with administrative privileges including system and user administration, the availability of standard users, logging and auditing, open ports and services, and host firewall settings.

The Cybersecurity Extension for SAP also monitors database and operating logs to detect indicators of compromise in Microsoft platforms and trigger alerts and email/ SMS notifications for security incidents. This includes system, role and user changes, direct access to user tables, changes to database schemas, user groups, scheduled tasks, stored procedures, passwords and firewall settings, failed logons including attempted remote logons, packets blocked by host firewalls, remote procedure calls, service activation, device and program installation, and changes to system auditing.

Securing Oracle Databases for SAP

Layer Seven on August 17, 2022

According to Gartner research, 70 percent of SAP customers have yet to migrate to S/4HANA. Based on current rates of adoption, SAP is unlikely to achieve its goal of migrating ECC customers to S/4HANA by 2027. As a result, the majority of SAP solutions continue to be driven by conventional databases. One of the most common database platforms for SAP is Oracle.

Oracle databases including several important security features to protect data at rest and in transit. This includes network encryption for securing communications between application and database servers, transparent database encryption for encrypting database tables, columns or complete tablespaces, granular access control using Database Vault, and Unified Auditing to support advanced policy-based logging. However, poorly configured Oracle databases can provide a vulnerable target for attackers to access and compromise data in SAP systems, bypassing application-level security and detection.

This article details best practices for securing Oracle databases against common vulnerabilities and exploits to protect against SAP attacks targeted at the database layer.

One of the most important steps is disabling the OPS$ mechanism in Oracle. In earlier versions of Oracle, the password for the SAP database user was retrieved from Oracle tables via an operating system user. The user was able to logon to the database via a shell prompt using credentials maintained at the OS level. The OPS$ mechanism enables threat actors to logon remotely to Oracle using locally-created users with the same IDs as OS users that are authenticated externally. This was deprecated from Oracle 11g. The encrypted password for the SAP database user is now stored in the Secure Storage File System (SSFS). The OPS$ mechanism is disabled using the value FALSE for the database parameter REMOTE_OS_AUTHENT.

Other important parameters include 07_DICTIONARY_ACCESSIBILITY to limit access to objects in the system SYS schema, global_names for blocking database connections from unauthorized domains, remote_login_passwordfile for preventing the use of password files to authenticate users, and options for enforcing robust password policies for database users including password complexity and expiration.

There are several standard users that are enabled in Oracle databases when a new database is created. The default passwords for the users should be changed after the install. Refer to the Oracle Help Center for the full list of standard users.

Users in the PUBLIC group should not be able to execute sensitive packages such as UTL_ORAMTS, UTL_HTTP and HTTPURITYPE. These packages can be used to send data to external destinations. All database users are members of the PUBLIC group.

The WITH_ADMIN privilege should not be included in permissions and roles granted to users, except for Oracle-maintained users. Users with the privilege can grant the permissions and roles to other users.

Critical system and table privileges should be restricted to authorized users only. This includes ALTER SYSTEM, GRANT ANY PRIVILEGE and BECOME USER. The last privilege enables users to inherit the privileges of other users.

Auditing should be enabled for specific database events. Examples include role and user changes, profile changes, database links, granting object and system privileges, changes to stored procedures, and schema triggers. Logging of successful and unsuccessful attempts to alter the audit trail in the SYS.AUD$ table is also recommended.

The Cybersecurity Extension for SAP (CES) performs comprehensive vulnerability scans for Oracle databases supporting SAP applications. The SAP-certified add-on automatically detects Oracle vulnerabilities including insecure authentication mechanisms, database misconfigurations, standard users with default passwords, users with critical roles and privileges, and incomplete audit policies.

CES also monitors Oracle database logs to detect and alert for security incidents and potential data breaches. CES is the only solution that secures the entire SAP stack including application, database and host layers. For host monitoring, CES also supports vulnerability management and threat detection for Oracle Linux operating systems, as well as other Linux variants including Red Hat Enterprise Linux (RHEL) and SUSE Enterprise Linux Server (SLES). In next month’s blog, we will discuss security and monitoring for Microsoft platforms supporting SAP systems, including SQL Server and Windows Server. Coverage for both platforms is included in the Cybersecurity Extension for SAP.

SAP Discloses Critical Vulnerabilities in ASE Databases

Layer Seven on June 4, 2020

SAP customers are urged to apply a series of recent patches released by SAP for the Adaptive Server Enterprise (ASE).  SAP ASE, previously known as Sybase SQL Server and Sybase ASE, is a widely deployed database platform used for both SAP and non-SAP applications. According to SAP, ASE is used by over 30,000 customers worldwide, including 90 percent of the top 50 banks.

Four of the patches released by SAP are for critical or high-risk vulnerabilities in multiple components of ASE. The vulnerabilities impact ASE versions 15.7 and 16.0 and carry CVSS scores ranging between 7.2 and 9.1.

Note 2917275 patches the most severe of the vulnerabilities by applying input validation for DUMP and LOAD commands that could be exploited to overwrite critical configuration files during database backup operations. Attackers can run DUMP commands to overwrite database configuration files with corrupted versions that will replace the default configuration. This can be exploited to install backdoors to ASE using credentials stored in the corrupted configuration files. It can also be exploited to execute arbitrary commands and executables using local system privileges by modifying the sybmultbuf_binary Backup Server setting.

Note 2917090 impacts Windows installations of the SAP ASE 16. Credentials for SQL Anywhere packaged in ASE can be read by any Windows user. SQL Anywhere supports database creation and version management. The credentials can be used to perform code execution with local privileges.

Notes 2916927 and 2917273 deal with high-risk SQL injection vulnerabilities in global temporary tables and ASE Web Services. Both vulnerabilities can be exploited to escalate privileges in ASE.

Database security notes including patches for ASE should be regularly monitored and applied using System Recommendations in SAP Solution Manager. Solution Manager connects directly to SAP Support for patch updates and monitor the patch status of SAP applications and databases. SAP Solution Manager also supports comprehensive vulnerability management for SAP ASE. Automated, daily security scans for ASE should be configured using Solution Manager to check for vulnerabilities related to the database configuration, administrative privileges, stored procedures, and other areas. The ASE audit log can be monitored by the Monitoring and Alerting Infrastructure (MAI) in Solution Manager to detect and alert for suspected malicious commands. To learn more, contact Layer Seven Security.

Webinar: 10KBLAZE – Secure Your SAP Systems with CVA and SolMan

Layer Seven on May 9, 2019

According to a recent report, thousands of SAP installations may be vulnerable to 10KBLAZE exploits targeting SAP applications.

Join SAP and Layer Seven Security to learn how to secure your SAP systems against the exploits with SAP Code Vulnerability Analyzer (CVA) and SAP Solution Manager. CVA performs static code analysis to detect vulnerabilities in custom code. SAP Solution Manager detects vulnerabilities and threats in SAP systems including components such as the gateway server, message server and SAProuter, targeted by 10KBLAZE.

Together, CVA and Solution Manager provide an integrated platform to secure your business-critical SAP systems against 10KBLAZE and other exploits.

Thu, Jun 6, 2019
11:00 AM – 12:00 PM EDT

REGISTER

Securing Administrative Access in SAP AS Java

Layer Seven on April 25, 2019

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.

 

Database Security with the Cybersecurity Extension for SAP

Layer Seven on January 30, 2019

Protecting SAP systems against cyber threats requires integrated measures applied not just within the SAP layer but across the technology stack including network, operating system, and database components.  As repositories of business-critical and sensitive information, databases warrant specific attention for hardening and monitoring efforts. This includes identifying and addressing configuration weaknesses, excessive privileges, and weak audit policies, encrypting data in transit and at rest, removing vulnerable stored procedures, and detecting and responding to privilege abuse or escalations.

SAP Solution Manager is uniquely positioned to monitor the security of SAP databases given its deep connectivity into SAP platforms. This article outlines the architecture and data collection procedures for database monitoring with Solution Manager. Next month’s article will explore database-level security reporting and event monitoring with SolMan.

Establishing connectivity to databases supporting SAP systems is a standard step during the mandatory configuration procedures for Solution Manager. Connection information is entered into the DB Parameters section during the Enter System Parameters step of Managed System Configuration. This includes the database host, port, and user credentials.

The connection supports the DBA Cockpit for database administration and monitoring. It also supports database extractors used by the Extractor Framework. The Extractor Framework performs data collection and distribution for monitoring and alerting in Solution Manager. The framework operates regular extractors to snapshot configuration, user, system, change and event-related data from systems. The snapshots are stored in areas such as the SolMan Configuration and Change Database (CCDB) and queried by other applications in SolMan including Configuration Validation and the Monitoring and Alerting Infrastructure (MAI). The concept of running or scheduling security scans is foreign in Solution Manager. Periodic jobs run the extractors to refresh the data. Therefore, there is no need to schedule scans or connect directly to systems to compile data when reviewing security-related information. Job Monitoring in Solution Manager can be used to monitor the relevant jobs and alert for job errors or warnings.

Solution Manager automatically applies preconfigured templates for databases once they are successfully connected for monitoring. SolMan installations are packaged with templates for all platforms supported by SAP systems including SAP databases such as HANA, Sybase and MaxDB, and third-party databases from Oracle, IBM and Microsoft. Template contents can vary based on the specific version and release of databases.

Templates for HANA platforms including metrics and alerts for monitoring system availability, performance and security. They also include CCDB stores to extract current values for HANA parameters, and details of active users, audit policies and users with critical database and system privileges.

The extractor framework and SAP-delivered templates may not provide coverage for monitoring all the security-related areas for each database platform. Therefore, customers or partners can either define their own templates or create/ modify extractors, metrics, alerts and CCDB stores to extract additional data. In the example below, we’ve added several custom stores to extract and query data for Sybase ASE that is not available in a standard Solution Manager installation.  This includes runtime values for all Sybase parameters, active users, roles assigned to database users, enabled stored procedures, audit settings, and database event logs with event IDs, user IDs, and timestamps.

The stores are assigned to the custom /L7S/ namespace to avoid any conflict with SAP and other namespaces.

The extractor framework regularly refreshes the data through background jobs. Database security policies are then applied by Solution Manager against the CCDB to identify vulnerabilities and security-related events in the platform. The data is also monitored by the MAI which triggers alerts and notifications for critical risks. The results are replicated to an internal Business Warehouse (BW) in Solution Manager.

In next month’s article, we will discuss how you can use Service Level Reporting and BusinessObjects to create detailed and user-freindly reports to convey the results of database security monitoring with SAP Solution Manager.

Secure, Patch & Respond: Security Analytics with SAP Web Intelligence

Layer Seven on November 20, 2018

SAP Web Intelligence enables users to visualize and manage security risks in SAP systems using interactive reports delivered through an intuitive web interface. Powered by the BusinessObjects platform, Web Intelligence connects directly to data sources in SAP Solution Manager to convey system vulnerabilities, missing security notes and open alerts using dynamic charts and graphs and detailed tables.

Animated charts summarize risks by system, location, priority and other dimensions. Results can be filtered and sorted to focus on specific areas. Users can comment on report elements for collaboration, decision-making and tracking remediation efforts. Reports can be exported to Excel, HTML and PDF. Reports can also be accessed remotely using the mobile app for SAP BusinessObjects.

The security reports are comprised of five distinct sections. The first section includes a series of charts that summarize risks across three dimensions: vulnerabilities, security notes, and alerts. The results can be filtered to focus on single or multiple systems.

The second section includes trend charts, bar graphs, geo-maps and bubble charts that break down the results for each dimension.

The remaining sections convey detailed findings and empower users to secure SAP systems against cyber threats by discovering and removing vulnerabilities, applying patches, and responding to alerts for suspected security breaches.

To learn more, contact Layer Seven Security. You can also request a free trial for security reporting with SAP Web Intelligence using Layer Seven’s cloud platform.

 

Security in SAP HANA

Layer Seven on May 30, 2016

SAP HANA is now deployed by over 7,500 organizations worldwide. While this represents only a fraction of the 300,000 companies that use SAP software globally, adoption is growing rapidly, doubling in 2015 alone. As expected, the introduction of SAP Business Suite 4 SAP HANA (S/4HANA) has accelerated this growth by widening the use-case for SAP HANA from analytics to transactional processing for core business processes.

While the performance and administrative benefits of SAP HANA are clear-cut, the benefits for security are more questionable. Unlike conventional persistent databases, HANA does not provide any native capability for label-based access control, data discovery and classification, data redaction and masking, or database firewalls. HANA also presents an architectural challenge for security engineers since some implementation scenarios integrate application and database layers that are traditionally hosted in separate physical or virtual servers.

SAP has addressed some of these concerns in later releases of HANA. SPS 12 includes features to isolate databases in multi-tenant environments to prevent cross-database attacks. It also includes more advanced logging capabilities to support multiple log formats and fine-grained audit policies. This is discussed in the newly updated whitepaper Security in SAP HANA, available in the resources section. The whitepaper provides a framework for securing HANA systems including network security, authentication and authorization, encryption for data in transit and at rest, and OS-level security for SUSE Linux Enterprise (SLES) and Red Hat Enterprise Linux (RHEL).

HANA vulnerabilities such as potential misconfigurations in database parameters or users with special privileges should be monitored using SAP Solution Manager (SolMan). In common with other SAP systems, HANA is connected to and monitored by SolMan. Security-relevant data is extracted by agents from HANA and transmitted to SolMan for analysis. SolMan analyzes the data using rulesets to identify potential vulnerabilities that could be exploited by attackers. The results are accessible through BW or BI including Lumira and Crystal Reports.

Rulesets benchmarked against best practices and SAP recommendations can be licensed from Layer Seven Security and imported directly into your Solution Manager platforms. To learn more, contact us.

Are 95 percent of SAP systems really vulnerable to cyber attack?

Layer Seven on May 26, 2015

Earlier this month, SAP issued a strongly-worded response to claims made by the software vendor Onapsis in a press release that over 95 percent of SAP systems assessed by Onapsis were exposed to vulnerabilities that could lead to the compromise of SAP systems. According to SAP, “The press release published by Onapsis is aimed at alienating SAP customers while promoting Onapsis’ own products. The assertion that over 95% of SAP systems were exposed to vulnerabilities is false.” In spite of such protests, the claims led to a wave of concern over vulnerabilities in SAP systems. The concerns were deepened by the revelation that the data breach at the government contractor USIS reported in 2014 was caused by a vulnerability in an SAP ERP system. The forensic investigators engaged by USIS to review the breach concluded that attackers were able to gain access to the system by exploiting an undisclosed SAP-level vulnerability or series of vulnerabilities. This assertion was based on evidence contained within SAP application trace logs and other sources. The breach led directly to the leakage of highly sensitive information impacting an estimated 25,000 government employees.

Along with similar incidents experienced by the Greek Ministry of Finance and Nvidia, the breach at USIS has served to illustrate the devastating impact to organizations when SAP systems are not securely configured and monitored to guard against possible cyber attack. Since the news of the source of the breach became public, security researchers have put forward several theories of possible exploits that could have been employed by attackers to compromise SAP systems connected to USIS. The theories include the use of default passwords, vulnerabilities in RFC gateways, remote code execution, and even database-level exploits. The fact that the attackers were presented with such an array of possible vectors is disturbing to say the least and highlights the wide attack surface presented by SAP systems.

Unless the specific SAP vulnerability that was exploited to breach USIS was a zero-day exploit, its likely that the breach could have been prevented through the proper hardening of SAP systems, regular patching, and continuous monitoring using tools provided by SAP in Solution Manager. It should be noted that almost all the attack vectors presented by researchers to explain the attack at USIS can be blocked by either applying applicable SAP patches or by observing the relevant SAP security guidance. This also applies to the so-called ‘Top Three Common Cyber Attack Vectors for SAP Systems’ declared by organizations such as Onapsis. Furthermore, once hardened, SAP systems do not necessarily require third party tools to monitor for possible changes or configuration errors that may expose them to cyber threats. The simplest, quickest and most cost-effective strategy is to leverage tools available in Solution Manager. They include System Recommendations for patch management, Change Analysis for detecting and investigating configuration changes, Alerting for security incident and event management, Dashboards for compliance monitoring and finally, Configuration Validation for comprehensive, automated vulnerability management. In short, both the information and the tools you need to secure your SAP systems against the type of attack that breached USIS are available to you at this very moment.