This week the Onapsis Research Labs released an advisory for a server-side code injection vulnerability in SAP HANA integrated IDE. For more information about the SAP Note that fixes this issue, please refer to the Onapsis Research Labs advisory.
To define a reasonable exploitation scenario, we will assume the following conditions are met by our testing landscape:
- There’s a vulnerable application running in our HANA instance.
- The attacker has access to the vulnerable application.
- The application is using a standard database user (created by default)
With this kind of vulnerability an attacker would able to inject arbitrary XSJS code that will run with the same privileges of the user running the application in the HANA server, this attack vector brings two powerful post exploitation primitives:
- Run arbitrary XSJS code.
- Perform an arbitrary SQL query.
By leveraging this vulnerability an attacker could execute SQL statements. For example he could execute something similar to:
var conn = $.db.getConnection();
var st = prepareStatement("SELECT * FROM USERS");
This week you will have seen from our twitter account, (@Onapsis) or other security news feeds like PacketStorm regarding the publication of information about six advisories discovered by the Onapsis Research Labs effecting SAP. In a past blog, Securing Your SAP Through Research, I talked about the importance and value of the security research we do here at Onapsis. Additionally, I have discussed the fact that we have seen automated, widespread attempts to compromise SAP systems as well as very targeted attacks and the implications of those attacks.
If you look at the latest six advisories released by the Onapsis Research Labs which are listed on our advisory page you will see they impact across a variety of SAP technologies that have very different delivery methods. There are three vulnerabilities effecting SAP HANA, two targeting the Extended Application Services (XS); one of which is XSS in the Administration Tool for SAP HANA XS and the third is an authentication bypass. A highlight for me was the discovery of a hardcoded user in SAP FI Manager Self-Service, which effects every installation of FI Manager.
It is very important that you stay informed by reading about the advisories we publish and also the monthly Security Notes releases by SAP and that you evaluate their relevance to your critical systems and the risk they represent to those critical systems.
SAP takes their responsibility to help their customers be secure seriously. They have released the SAP HANA Security Guide to help their customers deploy HANA in a secure way. SAP Security Guides are nothing new, they help define a minimum benchmark of a securely deployed SAP system.
For those tasked with assessing a SAP HANA (or ABAP) system and determining the complete risk the system represents to the business, they know that just performing a SoD check is not enough (and for those that don’t the list of security guides from SAP and this blog should help explain why). SAP states that “[these] security guides provide information that is relevant for all lifecycle phases”. When auditing or assessing these SAP systems, and HANA in particular a logical place to start is to compare the system against SAP’s own security recommendations and benchmarks for HANA.
The SAP HANA Security Guide provides those minimum security recommendations. At 102 pages, the guide provides a lot of detailed information about the SAP HANA solution, common deployment scenarios and an overview of the communication paths used within a SAP HANA deployment and how they should be secured. This is further broken out into the following areas:
- SAP HANA User and Role Management
- SAP HANA Authentication and Single-Sign On
- SAP HANA Authorization
- SAP HANA Data Storage Security
- Auditing Activity in SAP HANA Systems
- Security Risks of Trace and Dump Files
- SAP HANA Additional Components
- Security for SAP HANA Data Provisioning Technologies
- Security Reference Information
Different software companies take different approaches to the security of their products after they have been sold to their customers. Some would prefer it if previously released software had no security research attention paid to it where as others take a more realistic and therefore positive (to their customers) attitude. This positive approach is not only to provide their customers with security guidance for each component but to also release vulnerability information to them along with patches or remediation information in a regular and predictable way that allows their customers to anticipate and plan for application of remediation.
SAP falls into the positive camp; as well as releasing vulnerability information for HANA and other SAP components on the second Tuesday of every month they also publish security guidance for best practices to securely install and maintain HANA deployments.
Now, you could try and argue that the ultimate best practice is for SAP to release completely perfect and secure code and products; and to not allow their customers to reconfigure it so it can run in an insecure manor. That and unicorn hamburgers would be fantastic; but I am not holding my breath for either to present itself to me any time soon…