In the October patch release cycle, SAP released a set of security notes – two that apply to HANA, and one for TREX – to address twenty-one disclosed vulnerabilities originally found by Onapsis Research. Onapsis announced these advisories today (November 9th) - PC World followed this up with write-up this morning (“Dangerous bugs leave open doors to SAP HANA systems”).
Here are the notes in question:
Note | App. Area | Description | CVSS |
2203591 | BC-TRX | TREX/BWA installation can be attacked via RFC-Gateway | 7.6 |
2197459 | HAN-DB | Potential log injection vulnerability in SAP HANA audit log | 5 |
2197428 | HAN-DB | Potential remote code execution in HANA | 9.3 |
The highest vulnerability issue is a remotely exploitable buffer overflow that can be performed without authentication – addressed specifically in note 2197428 (which has a CVSS of 9.3 – about as high risk as it gets). This is a dangerous vulnerability that should be patched in all systems as soon as feasible. The TREX note (2203591) is also remotely exploitable by an attacker and does not require authentication, and is also considered high risk (note 2203591).
In looking through these notes, and thinking to the SAP customers I work with, the following questions often come up with respect to these types of vulnerabilities:
- Is our patch management strategy effective in staying current with new vulnerabilities?
- How can we proactively defend against these types of threats?
Answering each in turn:
Is our Patch Management Strategy Effective?
Currently, PCI is one of the more stringent security standards and is constantly re-evaluated in the light of current attack trends and the current threat environment, and is be considered a best or leading practice security standard. In version 3.1 of the DSS, section 6.2 states: “Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor supplied security patches. Install critical security patches within one month of release.” Organizations can use this as a benchmark to evaluate if their vulnerability management process is in line with leading practice.
Given that these were released on October 13th, if your organization doesn’t have these high risk notes deployed by November 13th, 2015 (a Friday! I know!) - then your organization is not following leading or best practice patch management.
How Can We Proactively Defend Against These Types of Threats?
That said, for organizations that have their TRAX RFC gateway(s) or HANA sqlserver ports exposed to untrusted networks, 30 days is far too long to live with this vulnerability. Consider that the worst vulnerability, the buffer overflow vulnerability in HANA, was disclosed to SAP on July 8th. This vulnerability has been known for a little over four months. That’s roughly 120 days an attacker might have to actively exploit this particular vulnerability - for some organizations, this might be an unacceptable level of risk.
Some options SAP customers have to address these vulnerabilities before they are disclosed or patched include:
- Implement Onapsis’ Advanced Threat Protection module in their OSP platform. The ATP engine is designed to prevent SAP-specific zero-day exploits, for those vulnerabilities identified by or known in advance by Onapsis. Note that Onapsis ATP may not be able to defend systems against zero-day exploits disclosed to SAP via other means.
- Implement a DAF (Database Application Firewall) for the HANA. This is also narrowly focused on the HANA sql port, and wouldn’t help address the TREX vulnerabilities disclosed.
- Best yet – when implementing HANA, architect for security! SAP customers should only allow connections to sensitive ports from trusted networks with a demonstrated need to have. The TREX note recommends restricting RFC access to only the Netweaver application servers and the TREX/BWA hosts via reginfo. Complementing this recommendation by implementing this same policy in your firewall rules is an additional layer of security – customers who only permitted access to HANA sqlserver and initiate RFC connections from trusted network in, say, September of 2015, would be have technical controls in place that would put the risk of exploitation of these vulnerabilities to a “Medium” or “Low” risk now - without applying notes.
But what about Hana XS? Can I allow Public Access to HANA XS Securely?
HANA XS (Extended Application Services) delivers a platform for natively executing (in memory, no less) applications – in HTML 5, if you so choose. Yet with great power comes great responsibility. Customers considering taking advantage of HANA XS should keep the following in mind: If you are allowing untrusted access to HANA XS applications, you are allowing these untrusted, unauthenticated connections to what, in theory, is a database platform containing the most important data in your organization. Plan your technical controls and security management program appropriately!
References:
http://www.pcworld.com/article/3003057/dangerous-bugs-leave-open-doors-to-sap-hana-systems.html#tk.r...
https://www.onapsis.com/research/security-advisories?title=&page=1
http://seclists.org/fulldisclosure/2015/Nov/40
