Skip to main content
SAP Pentest Playbook
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage
  2. /
  3. SAP Business Technology Platform
  4. /
  5. Known Attack Vectors
  6. /
  7. SAP HANA Cloud: Internet Exposure & HDI Container Self-Escalation
Edit page

SAP HANA Cloud: Internet Exposure & HDI Container Self-Escalation

Description

SAP HANA Cloud is the managed, BTP-provisioned database. It differs from on-prem HANA in two ways that matter to a tester: it is internet-facing by default, gated by a self-service IP allowlist rather than a network zone, and its default administrator is DBADMIN, not on-prem HANA’s SYSTEM. This page covers the HANA-Cloud-specific exposure and a developer privilege-escalation path in HDI containers that applies to HANA Cloud and on-prem alike. For on-prem HANA users, privileges, and backup exposure see Default Users & Privilege Escalation and Data & Backup Exposure; for how a BTP foothold reaches a HANA Cloud instance, see Service Key Abuse and Cloud Foundry.

Risk

A HANA Cloud instance with an open IP allowlist is an internet-exposed SQL endpoint fronted only by database authentication - a single leaked service-key or DBADMIN credential then yields a working SQL session from anywhere, with no VPN or Cloud Connector involved. The HDI container weakness lets a developer with deploy rights escalate their own privileges inside the database, because container “isolation” is a deployment boundary, not a security boundary. Impact is full read/write to the database’s data and, via privilege escalation, to objects and data beyond the developer’s intended scope.

Options

  • IP allowlist set to allow-all (0.0.0.0/0): HANA Cloud’s instance connection allowlist (“Allowed Connections” / “Configure IP Allowlist”) offers an “Allow all IP addresses” option - the equivalent of 0.0.0.0/0 - alongside “Allow only SAP BTP” and “Allow specific IP addresses.” Teams under delivery pressure select allow-all to unblock a demo, turning a managed DB into an internet-exposed SQL service. Test: with subaccount access, read the instance’s Allowed-connections setting directly; externally, an attacker holding DB credentials (leaked service binding, phishing) can connect from any source when allow-all is set.
  • DBADMIN default administrator: unlike on-prem HANA (SYSTEM), HANA Cloud’s initial admin user is DBADMIN. It is a known, high-value target for password attacks and, once obtained (or via a service key that maps to a privileged user), grants full administrative SQL. Test: check whether DBADMIN carries a strong, rotated password and whether named admins exist so DBADMIN can be locked down.
  • HANA Cloud service key → direct SQL (cross-reference): a BTP Space Developer can mint a HANA Cloud service key, which embeds a DB user/password (or certificate) usable directly with hdbsql/any SQL client over the public endpoint on port 443 - bypassing whatever authorization the application layer (CAP/UI5) implements. This is the most common path to the SQL session the allowlist is supposed to protect. See Service Key Abuse.
  • HDI container developer self-escalation: HANA Deployment Infrastructure (HDI) containers are isolated schemas with an object-owner (#OO) user and a deployment (#DI) API. There is no design-time control preventing a developer who has access to the design-time content and the ability to deploy it from manipulating HDI container roles - such a developer can elevate their access to HDI content, external objects, and data. The .hdbgrants + user-provided-service path is a concrete route: grant the #OO user access to an object, then update an HDI role to elevate one’s own privileges. Container isolation is a deployment boundary, not a security boundary. Test (HANA Cloud is HDI-default; also on-prem): with developer/deploy rights to a container, edit an .hdbrole/analytic privilege and redeploy to demonstrate self-escalation. Under-covered because it needs HANA-development knowledge.

Mitigation

  • Set the HANA Cloud allowlist to specific egress IPs, or use SAP HANA Cloud Private Link to reach the instance over the customer’s hyperscaler VPC; never use “Allow all IP addresses” in production.
  • Set a strong, rotated DBADMIN password; create named administrators and lock down / rename DBADMIN where supported; scope service-key DB users to least privilege (avoid cross-schema access).
  • Enforce TLS-only connections (hdbsql -e) and enable HANA audit policies for logons and privilege grants.
  • Enforce separation of duties between HDI design-time authoring and deploy authority; restrict who can bind user-provided grant services; avoid the .hdbgrants/user-provided-service escalation path in favor of stricter, reviewed grant controls.

Detection and Monitoring

  • Alert on IP allowlist changes, especially any move to “Allow all IP addresses.”
  • Enable and centrally ship HANA’s native SQL audit log (logons, privilege grants, DDL on HDI roles) - the BTP platform Audit Log does not capture data-plane SQL. See BTP Audit Blind Spots.
  • Watch for DBADMIN (or service-key user) logons with no prior interactive-logon history, and from unexpected source IPs.
  • Audit _SYS_DI grant-procedure execution and HDI role changes for signs of container self-escalation.

References