Onapsis Publishes 15 Advisories for SAP HANA and Building Components
Today, Onapsis Research Labs released 15 advisories related to SAP HANA and some building components, as well as Internal Communication Channels (also known as TREXNet). This is the first launch of more than 40 advisories we will be publishing in the following month including several vulnerabilities we have discovered in business critical application such as SAP and Oracle. In this blogpost, we’ll analyze two different vulnerabilities affecting SAP HANA. These vulnerabilities have one thing in common: They affect how SAP HANA handles user authentication requests.
A remote unauthenticated attacker could use the first vulnerability “SAP HANA Information Disclose Relating User Existence” (CVE-2016-6145) to gain knowledge of the different database users created. The second, “SAP HANA SYSTEM user brute force attack” (CVE-2016-6144) could allow an attacker to gain access to the SAP HANA Platform most powerful user: SYSTEM.
Overview: Information Exposure Through an Error Message
It is generally underestimated how an error message could help an attacker. One of the advisories we published is based on this type of vulnerability, where too much information gives an attacker… too much information. In other words, showing some data in a response can help an attacker know things they shouldn’t, and in some cases (like the one we are presenting today), allows an attacker to reach conclusions that they shouldn’t. This kind of bug is identified under CVE-209 as Information Exposure Through an Error Message:
“The software generates an error message that includes sensitive information about its environment, users, or associated data.”
In a worst case scenario, the error messages could include information such as IP addresses, users or passwords. In some other cases, this information can be used as a beginning for some other attacks.
Technical details
The main component of the vulnerability “SAP HANA Information Disclosure Relating User Existence, pertains to information given to a user when performing a login to the SAP HANA Database through the SQL interface (TCP port 3XX15, where XX stands for the Instance number). If the user who performs the login is locked, this information will be displayed in the error message regardless of if the password used to perform the login was valid or not.
The below message is an example of what is displayed when the user does not exist or the password is incorrect:
On the other hand, the message is completely different when the user exists and is locked:
By receiving different messages, an attacker could easily create a script to discover valid users. We used the PyHDB Client to write a Python POC script that takes advantage of an unpatched system. As it shown in the next image, the proof-of-concept discovers two valid users: USER1 and USER2.
To fix this problem, SAP published SAP Security Note 2216869. Starting with SAP HANA Revision 102, a new parameter was added called detailed_error_on_connect” under the password policy configuration (section [password_policy] in the indexserver.ini file). This parameter determines what information is displayed in login error messages. If it is set to “False” the displayed message will be “authentication failed,” regardless the reason of the failed attempt (user doesn’t exist, incorrect password, locked user, and so on). In the SAP HANA Revision 97.03 the parameter was also included, but for compatibility reasons is set to “True”. This can be changed using the SAP HANA Database studio.
Another way an attacker could abuse this vulnerability is by knowing how many attempts are required to lock an user. This could allow the attacker to perform brute force attacks without locking the targeted user.
As mentioned, an attacker can exploit vulnerability mentioned in advisory HANA SYSTEM user brute force attack to gain access to the SYSTEM users, thus compromising the entire SAP HANA Platform: The problem resides in the way that SAP HANA Platform handles login attempts for the SYSTEM user.
Before Onapsis reported this vulnerability, the limit established for the maximum number of login attempts prior to locking the user did not apply for the SYSTEM user. This means that an attacker could perform an unlimited number of login attempts knowing that the SYSTEM user will not be blocked. We also developed a POC script for this vulnerability too, as can be seen in the next image:
The SAP Security Note mentioned earlier (2216869) also fixes this problem. A new profile parameter “password_lock_for_system_user” was implemented that enables locking the SYSTEM user after a certain threshold of invalid login attempt was reached. In the SAP HANA Revision 102, this parameter is enabled by default, and as the previous case, in SAP HANA Revision 97.03 it is disabled by default for compatibility reasons.
Conclusions
It is important to remember: always keep up to date your SAP HANA Platform with the latest security patches and properly configure the platform according to the SAP HANA Security guide. In a later blogpost we’ll analyze how additional SAP HANA vulnerabilities can be leveraged by attackers and what we can do to protect our SAP HANA platform against these attacks.
We are also in the process of preparing our SAP Security In Depth publication about SAP HANA (volume II). The previous version, SAP HANA System Security Review Part 1, is available for download here: https://onapsis.com/research/publications/volume-xii-sap-hana-system-security-review-part-1.