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 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 least.
At Onapsis we are very concerned about our client’s SAP system security and also the state of SAP security in general, so 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.
This month 17 Security Notes were published by SAP (taking into account 1 Support Package Note and 16 Patch Day Notes). There were four notes reported by external researchers, Onapsis Research Labs reported 1 of the four notes (2009696) a XSS vulnerability in SAP HANA by Will Vandevanter.
Hi! Today I was reviewing some events generated for the Security Audit Log and noticed an interesting behavior.
For those who are not familiar with it, the Security Audit Log (SAL) allows SAP security administrators to keep track (via a log) of the activities performed in their SAP systems. In a future post we will discuss how to enable and configure this logging.
By default the SAL facility logs the “Terminal Name” which is either the Terminal Name (defined by the computer which performed the logged action) or the IP address of the computer that is the source of events. The IP address is only logged if the source computer does not transmit a Terminal Name with its communications.
This behavior can be abused by an attacker since filling the terminal name value in an RFC call is a task performed by the caller (the user’s machine). Having the ability to manipulate the “Terminal Name” means the attacker could try different attacks such as bruteforce attempts but have each transaction appear to come from a different terminal. Taken even further; the attacker could set an IP address (or cycle through a set of IP addresses) as the Terminal Name; meaning each request would appear to have originated from these IP addresses (as in the logs it is not possible to distinguish between an IP address that has been logged because no Terminal Name value was transmitted vs an IP addressed that has been logged as the Terminal Name).
SAP is a complex and ever changing system, whether because of changes introduced to your SAP implementation to better suit your business or applying Security Notes (Patches) to ensure that newly disclosed vulnerabilities are mitigated.
In order to provide a predictable and scheduled flow of vulnerability mitigation and security patches, SAP releases their latest Security Notes information 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 is highly recommended to carry out periodic assessments on a monthly basis in the least.
At Onapsis we are very concerned about not only our client’s SAP system security but the state of SAP security in general, so to assist SAP’s 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.
This month 33 Security Notes were published by SAP. Of these 33 notes, Onapsis Research Labs reported 10 of the underlying issues that have been addressed by SAP:
- 1791081 by Sergio Abraham
- 1768049 by Sergio Abraham
- 1920323 by Sergio Abraham
- 1915873 by Sergio Abraham
- 1914777 by Sergio Abraham
- 1911174 by Sergio Abraham
- 1795463 by Sergio Abraham
- 1789569 by Sergio Abraham
- 1738965 by Sergio Abraham
- 1939334 by Juan Pablo Perez Etchegoyen, Jordan Santarsieri and Pablo Muller.
SAP is a complex and ever evolving implementation; whether that is through changes introduced to your SAP implementation to better serve the business or the newly disclosed vulnerabilities targeting SAP products. In order to provide a predictable and scheduled flow of security, vulnerability and mitigation information SAP releases their latest Notes and security information regarding their products on the second Tuesday of every month. Because of this regular disclosure of new issues that could potentially weaken an organizations security SAP security assessments should be carried out on a regular basis. In order to ensure our customers are testing for all the published vulnerabilities in their SAP implementations we perform a detailed analysis of the monthly SAP Security Notes as soon as they are published.
CVSS distribution for the Security Notes released in January 2014
In January SAP released a total of 34 Security Notes, of those Notes, six were the result of reports made to SAP by the Onapsis Research Labs.
Notes 1918333, 1917381 and 1894049 were reported by Nahuel D. Sánchez, 1922547 and 1910914 by Jordan Santarsieri and note 1931399 by Willis Vandevanter all from Onapsis Research Labs.
Hello! Today’s post can be considered as a appendix to our previous post. We will learn how to validate the strength of SAP passwords by trying to crack them. We’ll focus on the password hashes coming from the SAP JAVA Application Server.
The JAVA Application server stores the passwords in the form of hashes encoded in BASE64. The hash algorithm used is salted SHA-1, also known as SSHA1 .
SAP JAVA “stack” password hashes are stored in a database table called UME_STRINGS. The JAVA password hashes can be filtered by the “attr” field (attr = ‘j_password’). We can get the user name along with its corresponding hash by executing the following SQL query:
SELECT pid, val FROM UME_STRINGS WHERE attr = 'j_password'
There are reasons why you might want to check the security (strength) of an SAP implementation’s passwords. Maybe during an external SAP security assessment or during an internal review.
If it is an SAP security assessment and the successful exploitation of a vulnerability is able to provide OS command execution in the application server, the command shell might not be sufficient to prove the impact of the vulnerability. Sometimes the most effective way to do it is to retrieve valid credentials (SAP user credentials) in order to prove a real threat. This can evidence the ability to connect to the system, obtain business information and explain to our customer the real problem behind a given vulnerability. The impact is clearer, from the customer’s perspective, when there is a chance to access business data and it’s exposed with valid (SAP) user credentials rather than performing command execution and showing a command shell, although the latter could potentially cause more damage.
Other scenarios where password cracking could be necessary is on complex landscapes with several systems interconnected. If an attacker is able to obtain valid user credentials in low-criticity systems such as sandbox or development systems it is likely that the same user and password will be configured in productive systems as well, being able to “jump” from the initial system (probably much less secured) to the most critical systems.
In our previous post, we were able to understand the topology and configuration in place, useful whenever you want to analyze how secure a SAProuter implementation is. In this article, we’ll check if our SAProuter is secure or whether it would be possible for an attacker to retrieve information and connect to our internal network.
Using SAPRouter Agents
We have already retrieved useful information from the SAProuter, which is potentially connected to an untrusted network. But that’s not all of it. If the SAProuter is mis-configured, then it would be possible for a remote attacker to access the internal network and connect to arbitrary systems and services, even beyond standard SAP protocols.
The SAProuter has a special feature that enables it to route arbitrary protocols, which is called “native routing”. Refer to our SAProuter SAP Security In-Depth publication, specifically section 3.3, for further information on this topic.
Hello there, my name is Nahuel D. Sanchez and I work as a Security Researcher at the Onapsis Research Labs.
The idea behind this post is to uncover and understand the options we have while performing a security assessment of the company’s SAProuter implementation using the open source ERP Penetration Testing framework, Onapsis Bizploit.
For more information about vulnerabilities affecting the SAProuter, attacks and countermeasures, you should have a look at our SAP Security In Depth publication “Securing the Gate to the Kingdom: Auditing the SAProuter”.
Before we dig into the interesting stuff, it’s necessary to review some basic concepts. If you’re already familiar with the SAProuter, you can jump straight to the “Security Assessment Techniques” section.