Even though SAP has more than 10,000 standard transactions, all companies create their own custom ones. There are different reasons for building custom transactions. For example, a user might need a specific report, a list, or a functionality that isn’t in the system. Sometimes there are even cases where custom transactions with identical functionality of an existing standard transaction are created.
Creating custom transactions isn’t a problem, it is a normal usage of the system. The problem however, is all the potential security issues related to these new transactions.
When building custom programs, the priority is focused on delivering the required functionality to the user, which usually results in security measures being left aside. It is common to find ABAP developers who aren’t concerned with the importance of security or are simply unaware of all the security mechanisms SAP offers to enforce security. They just ensure that the program is working properly based on what the user had requested. Once it’s created, someone else adds the tcode to the user role, and that is it.
So the question is how can we ensure that in our organization custom transactions are built in a secure way?
The answer is easy: Use ABAP security standards – BIZEC APP11 as a guide to create the transactions. Easy to say, but hard to do. The standard includes different types of possible misconfigurations:
- APP-01 ABAP Command Injection
- APP-02 OS Command Injection
- APP-03 Native SQL Injection
- APP-04 Improper Authorization
- APP-05 Directory Traversal
- APP-06 Direct Database Modifications
- APP-07 Cross-Client Database Access
- APP-08 Open SQL Injection
- APP-09 Generic Module Execution
- APP-10 Cross-Site Scripting
- APP-11 Obscure ABAP Code
SAP is a complex and ever changing system, whether because of changes introduced to your SAP implementation to better suit your business, or through the application of Security Notes (Patches) to ensure that newly disclosed vulnerabilities are mitigated.
In order to provide a predictable and scheduled flow of vulnerability mitigation information and security patches, SAP releases the major part of their latest Security Notes information on the second Tuesday of every month. Due to this regular disclosure of new security issues that could potentially weaken the security of SAP systems within an organization, it’s highly recommended to carry out periodic assessments on a monthly basis at minimum.
At Onapsis we are very concerned about our client’s SAP system security and also the state of SAP security in general. To assist our customers, we perform a detailed analysis of the monthly SAP Security Notes as soon as they are published. The goal of this is to provide SAP clients with detailed information about the newly released notes and vulnerabilities affecting their SAP systems and help guide their testing of these systems within their organization.
Since the last SAP Security Tuesday and today, there were 21 SAP Security notes published by SAP (taking into account 3 Support Packages and 18 Patch Day Notes). There were notes published by external security researchers from which, Onapsis Research Labs reported SAP Security Note 2122391 (by Sergio Abraham).
The plot graph illustrates the distribution of CVSS scores across released Security Notes. The only notes taken into account were the ones to which SAP set a CVSS (16 out of the 21 SAP Security Notes). As represented in the graph, the SAP Security Notes value ranges from 3.5 to 6.8 with a median of 5.0. Continue reading
A few days ago, an important set of bugs that affect the suites of protocols TLS/SSL were published in https://www.smacktls.com/. These protocols are mainly used as the security layer underlying the HTTP(s) protocol, but many other protocols may be affected. The described vulnerabilities have received specific names: SKIP-TLS and FREAK. These bugs affect different implementations of the TLS/SSL cryptographic algorithms, but they are not vulnerabilities in the protocols themselves.
SKIP-TLS can be described as an implementation error in how the client and server manage unexpected messages in the protocol state machine. Different cipher suites require different messages in particular orders. This bug leverages this complexity by sending messages in an specific order to skip all messages related to key exchange and authentication as described in the paper (https://www.smacktls.com/smack.pdf).
The FREAK attack to the TLS/SSL protocol implementation attempts to degrade the cipher quality, giving an attacker the possibility of downgrading the cipher suite strength of a TLS/SSL connection. This means that a resourceful attacker performing a man-in-the-middle attack could trick the client to select a weaker cipher suite that could then be broken in during a later stage of the attack (like those marked as EXPORT).
In this blog post we will focus on understanding the security impact of SKIP-TLS/FREAK for a group of SAP products.
As I said in a previous post, “Dealing with Authorization Gaps: Part 1,” the authorization groups aren’t limited to technical data as there are also many related to Business Master Data.
The concept of implementation is the same:
- Understand the reason for using an authorization group.
- Identify where to set the groups.
- Find the related authorization objects.
- Assign the values to the proper roles taking into account which users need each access.
Normally, there are more SAP business users than technical users, making the assignment to users much more complex.
Since there are many business authorization groups, I will focus on the ones I believe are the most critical:
- For FI Document Types.
- For Vendors.
- For Customers.
- For G/L Accounts.
Authorization Groups For FI Document Types
There are many transactions inside SAP which allow users to post financial documents. The best way to avoid having users posting document types that they shouldn’t is to assign authorization groups.
The document types can be updated using transaction OBA7. Since it’s a customizing transaction you will probably need to perform the change in Development and then transport it into Production.
In January, Oracle published a Critical Patch Update (CPU) with 19 vulnerabilities affecting JAVA SE (among other products): http://www.oracle.com/technetwork/topics/security/cpujan2015-1972971.html#AppendixJAVA
SAP has its own specific JAVA virtual machine implementation called SAPJVM, which according to SAP documentation: “…is derived from Sun’s HotSpot VM and JDK implementation … the SAP JVM is only targeting server-side applications. Certain features related to client environments are intentionally omitted or are not supported for general use.”.
This information could be important to identify whether or not the vulnerabilities are affecting the SAP JVM because only 4 out of the 19 are affecting the server-side functionality of the Oracle JVM: CVE-2015-0383, CVE-2015-0410, CVE-2014-3566 and CVE-2014-6593. However, that information is not conclusive.
Authorization groups are a difficult topic to tackle in SAP as they can be considered a double-edged sword. With proper implementation it’s possible to take security to the next level, however if not properly implemented, authorization groups can lead to usage issues and can create a false sense of security. These problems arise due to different reasons:
- Lack of understanding on the usage of an authorization group.
- Finding where to set the authorization groups for each function.
- Link with the proper authorization object. And finally,
- Assign the correct values to the right users.
In this post, we will go through some of the most critical and technical authorization groups:
- For RFC Destinations.
- For Tables.
- For Programs.
- For ICF services.
Authorization Groups For RFC Destinations
RFC destinations are very sensitive since they can be used to jump from one system to another. By using this type of authorization group, we can limit each user only to the destinations he requires.
The creation of authorization groups for RFC Destinations can be done using transaction SM59 by assigning a value in field “Authorization for Destination”.
There are two objectives for assigning an authorization to an RFC destination:
- Limit the users who can maintain the RFC Destination: which is related to the authorization object S_RFC_ADM – field ICF_VALUE
- Limit the users who can use the RFC destinations: which is related to the authorization object S_ICF – field ICF_VALUE
In this case, we need to check the systems in which users are responsible for maintaining the RFC destinations, and who those users are. Then, we must group the destinations in a way that is suitable for both, and assign the corresponding values to their roles.
SAP is a complex and ever changing system, whether because of changes introduced to SAP implementation to better suit the business, or through the application of Security Notes (Patches) to ensure that newly disclosed vulnerabilities are mitigated.
In order to provide a predictable and scheduled flow of vulnerability mitigation information and security patches, SAP releases the major part of their latest Security Notes information on the second Tuesday of every month. Due to this regular disclosure of new security issues that could potentially weaken the security of SAP systems within an organization, it’s highly recommended to carry out periodic assessments on a monthly basis at the very least.
At Onapsis, we are very concerned about our client’s SAP system security and the state of SAP security in general. To assist our customers, we perform a detailed analysis of the monthly SAP Security Notes as soon as they are published. The goal of this is to provide SAP clients with detailed information about the newly released notes and vulnerabilities affecting their SAP systems, and to help guide their testing of these systems within their organization.
On this Patch Day (second Tuesday of each month) SAP published 16 Security Notes (taking into account 2 Support Packages and 14 Patch Day Notes). There were notes published by external security researchers from which, Onapsis Research Labs reported SAP Security Note 2109818 discovered by security researchers Nahuel D. Sánchez and Fernando Russ.
The plot graph illustrates the distribution of CVSS scores across the Security Notes released. The only notes taken into account were the ones for which SAP set a CVSS (12 out of the 16 SAP Security Notes). As it’s represented in the graph, the SAP Security Notes range values go from 3.5 to 7.5 with a median of 5.25.
As a company, Onapsis is focused on the security of business-critical applications such as SAP and Oracle. While our focus has been on SAP applications, we have also been actively researching, identifying and reporting critical vulnerabilities facing Oracle business applications. In this sense, Oracle is different from SAP, specifically in the way and timing that security patches are released and available to end users.
In this post, I will go through an analysis of Oracle’s January 2015 Critical Patch Update (aka CPU). The goal is to provide Oracle customers with detailed information about the newly released vulnerabilities affecting their business critical applications, and to help them to better understand and prioritize the testing for vulnerabilities on these systems within their organization.
In January 2015, Oracle published 169 vulnerabilities affecting 48 different Oracle products. Oracle uses the Common Vulnerabilities and Exposures standard (CVE) to uniquely identify the vulnerability and Common Vulnerability Scoring System V2 (CVSS) to measure the risk implied by the vulnerability in terms of different aspects such as exploitability, complexity and impact, to name a few.
An important aspect of this month’s CPU is the fact that more than 59% of these vulnerabilities are affecting business-critical applications. This means that companies have to be aware of these vulnerabilities and take immediate actions to mitigate the risks implied by them.
It is important to note that all SAP HANA Appliances are shipped by default with Operating Systems containing vulnerable versions of the library, therefore the base OS of the appliances must
be updated. One example of this is the SAP HANA One hosted in Amazon AWS
, as this image is delivered with the vulnerable library.
Last week a new vulnerability was reported, affecting the GNU C library (glibc). This vulnerability affects a wide range of Linux distributions, among which are some supported by SAP products as stated in SAP Note 171356.
It’s important to understand that even though this vulnerability does not directly affect any SAP application, it affects a lower layer, the operating system, allowing any application to potentially use the vulnerable function.
The following list details the OS that were reported as vulnerable and are supported by SAP, therefore there could be SAP applications running on top of the following vulnerable operating systems
The world of profile parameters in SAP is vast and complicated as a user can change the entire behavior of the SAP by modifying some of these parameters.
But just when we thought that we knew everything about profile parameters, we recently discovered something very interesting.
SAP Security Note 1979454 is related to a vulnerability in transaction SHDB (a very sensitive transaction since it’s used to create recordings) which introduced a new profile parameter called “bdc/shdb/auth_check”.
The problem with SHDB is that it wasn’t checking any authorization object besides from the S_TCODE, and a user with access only to the transaction could see any recording made by any user. If the user recorded a user creation the password would be shown in plain text. To mitigate this risk an authority check was introduced inside the programs, which would check for the authorization object S_BDC_MONI. However to enable this check, the parameter bdc/shdb/auth_check needs to be set to TRUE.
While going through the correction instructions for this note, we noticed that there wasn’t an update for the SAP Kernel (whenever a new profile parameter is introduced, there should be an update to the Kernel), so we decided to test the correction instructions to see how this parameter worked.