SecureAuth uncovers SAML validation weakness in SAP HANA

Martin Gallo
Senior Director of Research at SecureAuth Innovation Labs
December 15, 2020

Get the latest from the SecureAuth Blog

This blog post details a specific vulnerability affecting SAP’s HANA implementation of the SAML standard. This vulnerability allows an attacker with authenticated access to trick a SAP HANA instance into authenticating as a different user.

We recommend SAP HANA customers check out SAP Security Note 2978768 (S-user required to access) published on December 8th 2020, review the recommended mitigation steps, and update their systems to version SAP HANA 2.0 SPS 05 revision 53, SAP HANA 2.0 SPS 04 revision 48.03 or SAP HANA 1.0 SPS 12 revision 122.33 whenever possible. You can find a more concrete technical explanation of the vulnerability and the details about the disclosure process in our security advisory SAUTH-2020-0001. This blog post serves as an in-depth explanation of the issue and a walkthrough for validating the vulnerability and going through the recommended mitigation steps.

SAML-based authentication in SAP HANA

For those not familiar with the technology, HANA is SAP’s in-memory database, and the core component of their business technology platform where ERP, CRM, SRM and other solutions run. Being an extensive platform targeted to the enterprise, the available support for federated identity protocols and technologies is varied. Among the supported federated authentication technologies is SAML.

We have covered the integration between SAP HANA and SAML environments in our blogpost series about HANA SQL Command Network Protocol, where we also briefed about the protocol basis, the password-based authentication mechanisms and its support for federated authentication methods. As mentioned at that time, in addition to the SQL interface, SAP HANA can leverage SAML for accessing Web-based applications, either the native ones provided by HANA (e.g. the Cockpit Administration portal) or custom developed ones (e.g. through XS classic model or XS advanced model).

In either way, the integration with a SAML-based environment looks like the following:

Diagram of a SAML-based integration with SAP HANA

Diagram of a SAML-based integration with SAP HANA

  1. The client, for example a user accessing an XS(A) application, or a business application that needs to connect to a HANA database instance, authenticates to an Identity Provider using a workflow defined by the IdP. For instance, the process can involve providing username and password, and depending on the adaptive access checks an additional authentication factor. The Identity Provider can be, for example, SecureAuth’s SaaS IAM.
  2. The Identity Provider will reply to the client with a SAML Response, that contains a signed SAML Assertion of the Bearer form. This assertion is a confirmation from the IdP that the identity of the user was properly validated.
  3. The client then forwards this response to the SAP HANA instance, which in this case acts as the Service Provider in SAML jargon. If the target is a Web application, the client will probably be a browser or other form of a Web agent. In case the target is the database itself, the client would be a database client (e.g. via ODBC or JDBC), and the SAML Assertion is included as part of the authentication handshake as demonstrated and explained in our previous blog post “Exploring the SAP HANA SQL command network protocol – Federated Authentication”.
  4. The SAP HANA instance, acting as the Service Provider, will validate the signature of the SAML Assertion received to see if it was issued by a trusted Identity Provider.
  5. In an additional step, the HANA service will also validate the content SAML Assertion, for example to determine the validity period of it, that the user is active, and any type of mapping that might have been done.
  6. If those validations succeeded, the user is authenticated, and a session is established with the client.

SAML Responses and Assertions 101

SAML is an XML-based standard, which defines the schemes and elements to use during the exchange of information. A SAML Assertion is, in a very simplified abstraction, comprised of the following elements:

<Assertion ID="XXX" Version="2.0" IssueInstant="2020-08-26T01:01:48Z"> 
     <CanonicalizationMethod Algorithm="[..]xml-exc-c14n#"/> 
     <SignatureMethod Algorithm="[..]xmldsig-more#rsa-sha256"/> 
     <Reference URI="#XXX"> 
       <DigestMethod Algorithm="[..]xmldsig-more#md5"/> 
       <DigestValue>[Base64-encoded digest]</DigestValue> 
   <SignatureValue>[Base64-encoded signature]</SignatureValue> 
     [Base64-encoded certificate or other key material] 
   <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">username</NameID> 
   <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/> 
<Conditions NotBefore="2020-08-26T01:01:48Z" NotOnOrAfter="2020-08-27T01:01:48Z"> 

SAML Assertion elements are signed according to the XML-DSig specifications. In a very simplified way, the signing process involves the following steps:

  1. The XML elements to be signed are transformed to a canonical representation.
  2. This canonical representation is hashed with a specified algorithm, and a digest is obtained and added in a Base64-encoded form.
  3. The digest is signed with the algorithm specified and added after also being Base64-encoded.

Through the rest of the article we will use this simplified SAML Assertion as an example to illustrate the vulnerability and attack vectors.

Canonicalization, XML Signatures and the Name ID Element

The vulnerability was assigned CVE-2020-26834, and it relates to the way signatures are evaluated by the SAML implementation in the vulnerable versions of SAP HANA 2.0 SPS 05 revision 52, SAP HANA 2.0 SPS 04 revision 48.02 or SAP HANA 1.0 SPS 12 revision 122.32. As previously mentioned, the SAML standard uses the XML-DSig specifications for generating the signature.

The vulnerability appears due to the way HANA obtains the value of the NameIDelement. This element is used as the name of the user who requested access. This is not a new vulnerability class. There’s plenty of examples of other Service Providers that suffered from the same problem, including Duo Security’s findings affecting multiple SAML libraries and some of their own products.

As we described in section 1, there are two occasions when SAP HANA evaluates a received SAML Assertion: to validate that its signature is correct and was emitted by a trusted IdP (step 4), and to validate the information about the user and the access itself (step 5). The problem appears because those two validations are performed using different methods to access the user’s identifier.

In the first case, and for SAP HANA to validate the signature of the SAML Assertion, the service seems to be respecting the canonicalization algorithm specified. When the canonicalization algorithm permitted the use of comments, those were respected and included in the signature. If the specified algorithm disallowed comment elements, those were correctly ignored.

However, the logic in charge of validating the content of the SAML Assertion for the vulnerable versions was different. Regardless of the canonicalization algorithm denoted in the XML structure, the service was effectively stripping out any element or content after a comment element.

Let us look at it through an example considering the following content for the NameID element of a SAML Assertion with the xml-exc-c14n canonicalization algorithm:

<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">username<!--->withsomecomments</saml:NameID>

The first validation logic will ignore comments and consider the true value of the NameID element as: “usernamewithsomecomments”, while the second validation logic will instead obtain “username”.

Why this is an issue? Well, an attacker who managed to get a valid SAML Assertion from a trusted Identity Provider should be able to tamper with it even in the presence of the signature. Adding a comment in some part of the NameID comment will result in the signature still being valid but allow for a change of the user being authenticated.

For example, a signed SAML Assertion emitted for the user “first.lastname” can be turned into “first”, “fist.last”, or any other sub-string of the original username without invalidating the signature. Depending on the user mapping method configured in HANA, and how users are defined, this might allow an attacker to bypass the authentication and access the database or an XS(A) application on behalf of another valid user.

We should mention that SAP HANA allows for automatic provision of users when they are not found in the database. If this is the case, it mostly sure will allow the attacker to abuse the vulnerability and get low-privileged access to the database or the applications hosted in the SAP HANA instance.

Is my organization affected?

If your organization operates SAP HANA integrated with a SAML-based Single-Sign On environment, chances are that you’re running a vulnerable version. However, that does not mean that your configuration scenario makes you vulnerable. There are a couple of steps that you can take to validate if you’re affected.

If you have administrative access to the SAP HANA configuration, you can perform the following checks:

  • First, obtain the version and Service Patch Level of your SAP HANA instances and check those against the list of patched versions. That information can be obtained, for example, by running the following commands as the adm user:
$ HDB version
HDB version info:
branch:              fa/hana2sp04
machine config:      linuxx86_64
git hash:            af3aabc5a5cdb94ecbc7c07d0997d0bd4ae0046b
git merge time:      2019-12-06 14:35:12
weekstone:           0000.00.0
cloud edition:       0000.00.00
compile date:        2019-12-06 15:29:38
compile host:        ld5144
compile type:        rel
  • Check if the SAML PROVIDER is configured to automatically provision users. This can be achieved also with SAP HANA Studio, SAP HANA Cockpit, or running the following SQL statement:
"XS_APPLICATIONUSER","CN=HXE, OU=SAML","CN=HXE, OU=SAML","xsa-85b9a273-f651-40fb-b6fd-beed1d111191","FALSE","TRUE"
2 rows selected (overall time 20.802 msec; server time 363 usec)

Last but not least, if you’re testing for CVE-2020-26834 from a black box perspective, for example as part of a Red Team or Penetration Testing exercise, there’re several tools you can use to validate their presence and determine its impact. For example, to test HTTP-based applications running on XS or XSA you can use an interception proxy after a successful authentication to the IdP and tamper with the XML elements, or reuse a SAML Assertion directed to another Service Provider. The same tests can be done on the SQL interface with the use of our Open Source pysap library. Refer to our previous blog post exploring Federated Authentication on the SAP HANA SQL Command Network Protocol for more details about the use of the library and the example scripts to perform the tests.

Is my organization under attack?

You can take a couple of steps to improve detection of potential exploitation if needed. Active exploitation might be detected by looking for XML comments inside the NameIDelement of SAML Assertions sent to the SAP HANA service.

Some of the places to look for these types of indicators might be the logs on your HANA server, and eventually live traffic going through. One way to observe detailed logs related to the SAML-based authentication in HANA would be to increase the trace level associated with authentication events. SAP Note 2091131 and SAP Note 2472944 (S-user required to access) contains detailed troubleshooting and diagnostics steps based on this trace. Enabling it can be done for example, by modifying the corresponding configuration parameter with the following SQL statement:

ALTER SYSTEM ALTER CONFIGURATION ('indexserver.ini', 'SYSTEM') set ('trace', 'authentication') = 'debug' with reconfigure;

A log event for a SAML-based authentication would look like the following:

[10295]{-1}[-1/-1] 2020-11-05 12:45:09.309182 d AuthenticationCo CodecSQL.cpp(00356) : validateInputData: param[1] length=2864 
[10295]{-1}[-1/-1] 2020-11-05 12:45:09.309184 d AuthenticationCo CodecSQL.cpp(00368) : param[1][0-19]=0x3c73616d6c3a417373657274696f6e20786d6c6e 
[10295]{-1}[-1/-1] 2020-11-05 12:45:09.309185 d AuthenticationCo CodecSQL.cpp(00377) : param[1][0-19]=<saml:Assertion xmln 
[10295]{-1}[-1/-1] 2020-11-05 12:45:09.309187 d AuthenticationCo CodecSQL.cpp(00492) : assign: m_Data=0x00007f624a6fcc00, data=0x00007f6235a33000, m_Length=2874 
[10295]{-1}[-1/-1] 2020-11-05 12:45:09.309194 d Authentication   SAMLAuthenticator.cpp(00469) : <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="XXX" Version="2.0" IssueInstant="2020-09-10T01:01:48Z"> 
  <ds:Signature xmlns:ds=""><SignedInfo xmlns=""><CanonicalizationMethod Algorithm=""/><SignatureMethod Algorithm=""/><Reference URI="#XXX"><Transforms><Transform Algorithm=""/><Transform Algorithm=""/></Transforms><DigestMethod Algorithm=""/><DigestValue>q4hz[..]PO2w=</DigestValue></Reference></SignedInfo><ds:SignatureValue>B3OK[..]/4EQ==</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIID[..]Ywg== 
    <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">USER<!-- Some comment added -->1</saml:NameID> 
    <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/> 
  <saml:Conditions NotBefore="2020-09-10T01:01:48Z" NotOnOrAfter="2020-09-11T01:01:48Z"> 
[10295]{-1}[-1/-1] 2020-11-05 12:45:09.309480 d Authentication   SAMLAuthenticator.cpp(01286) : Search SAML Provider with EntityId = 
[10295]{-1}[-1/-1] 2020-11-05 12:45:09.309778 d Authentication   SAMLAuthenticator.cpp(01354) : Search SAML provider for certificate with subject = '' and issuer = '' 
[10295]{-1}[-1/-1] 2020-11-05 12:45:09.309827 d Authentication   SAMLAuthenticator.cpp(01371) : Found SAML provider: IDP_SECUREAUTH 

You can observe that the SAML Assertion is included in the logs and might help to spot potential abuses of the vulnerability. Detection rules might be build on top of this logic.

With regards to observing traffic going to the HANA service, you should be able to inspect HTTP(S) requests and look for the noted indicators in the SAML Assertions that arrive to the service. Doing the same for SQL Command Network Protocol traffic can be a little bit more cumbersome, but possible with tools such as our own plugin for Wireshark.

Remediation Recommendations

The obvious recommendation is to patch your SAP HANA instances with the latest version that includes SAP Security Note 2978768 (S-user required to access). However, knowing that patching these kinds of software components might not be a straightforward task and might require some planning and due diligence, there are some actions that you can take to reduce the likelihood of the vulnerability being exploited or at a minimum to mitigate it.

On the SAP HANA administration side, the main recommendations are:

  • When possible, and until the patch can be applied, reduce the amount of users allowed to authenticate using SAML.
  • When possible, and until the patch can be applied, disable automatic creation of unknown users in all SAML PROVIDER configurations.
  • Enable the use of TLS to secure connections to the database, either via the SQL interface or HTTPS protocol.

From the IdP standpoint, you can check into a couple of items:

  • If the IdP allows it, specify canonicalization methods that are strict and include comments (for example,
  • Limit potential ways for a user to openly register their own accounts.


As part of our continued work innovating and researching security trends, we have coordinated the fix and disclosure of a vulnerability affecting SAP HANA’s SAML implementation. We hope that our customers integrating with SAP HANA servers, and the entire SAP customers community, can benefit from the detailed and in-depth analysis of the vulnerability, the available testing mechanisms and the recommended mitigations steps included in this article.

If you have questions, comments or feedback about this vulnerability or any of these topics, reach me on Twitter at @martingalloar or email our SecureAuth Innovation Labs via!


SecureAuth Innovation Labs blog posts

Nov 23, 2020: SecureAuth Innovation Labs – New Impacket Release Available Today!
Oct 21, 2020: Exploring the SAP HANA SQL Command Network Protocol – Federated Authentication
Aug 10, 2020: Exploring the SAP HANA SQL Command Network Protocol – Password-based Authentication and TLS

Related Stories

Pin It on Pinterest

Share This