PostgreSQL Database: A Black Hole for You, A Goldmine for Someone Else

Content:
1. Cryptojacking 101
2. Why cryptojacking will cost you
3. Understanding PostgreSQL
4. A PostgreSQL vulnerability that enables cryptojacking
5. And here’s another one…
6. Handling cryptojacking in the real world
7. Automated and live patching is key
8. TuxCare Live Patching for PostgreSQL
9. Don’t let your PostgreSQL become a black hole

Cryptojacking 101

First, let’s see take a look at what cryptojacking is and why attackers make use of cryptojacking techniques. There’s a simple answer really: money. Mining cryptocurrency can mean big money, but for cryptomining the facts on the ground have changed.

Not so long ago it was easy to mine large amounts of cryptocurrency just by using a standard computer with an internet connection – you could do it at home. However, that changed over the years because many popular cryptocurrency algorithms are designed in a way that means that mining coins become more difficult as time passes.

The result is that today, mining coins is computationally extremely demanding – miners need a lot of resources to mine cryptocurrency, and resources are not free. This hits profits and, in many cases, means that unless resources can be obtained for free – in other words, stolen – mining cannot be performed profitably.

And that is what cryptojacking is all about – stealing resources to use for the purpose of cryptomining. When a hacker crypto jacks servers the goal is to harness the resources that you paid for and to use it to mine cryptocurrency without your permission, and of course without giving you any of the cryptocurrency that’s mined using your equipment.

Cryptojackers are motivated to stay hidden as long as they can, and they will of course try and inject their cryptojacking code where you are least likely to find it – we will come to that later in this article.

Why cryptojacking will cost you

Next, we’ll take a look at the problems caused by cryptojacking and why your organization needs to pay attention to the risks. A hacker that installs cryptomining software on your systems does not do so to directly disrupt your operations nor to steal data – but the drain on your computing resources can be extremely expensive. There are other consequences too. We list some of the effects here:

•         Cost increases. We explained earlier that cryptomining is very resource-intensive. Most organizations plan technology resources carefully – never purchasing more than what’s needed and tapping maximum value out of every dollar spent. Cryptojacking upsets this balance, and it means that your workloads can suddenly fail – leading to unexpected outages. Where your billing is dependent on usage you can expect dramatically higher bills.

•         Physical damage. While your workloads are designed to run within the physical and environmental limits of your hardware, cryptojackers will show absolutely no concern when abusing your hardware via illicitly installed cryptomining software. It can lead to physical hardware failure as components such as CPUs are run beyond manufacturer and environmental limits.

•         Compliance and legal concerns. Where an organization handles personal or other confidential data on its servers the presence of unauthorized cryptomining software can breach compliance regulations as the cryptomining software can have access to this data. It can lead to significant legal problems.

•         Cryptominers can become a security problem. Cryptojacking may start off as just an abuse of resources, but hackers can repurpose the software to accomplish other goals. This could be disrupting your services, or stealing data. In other words, a resource drain can quickly morph into a critical cyberattack.

As you can see, there’s real day-to-day costs involved into cryptojacking due to increased use of resources, but also risks of large unexpected costs as cryptomining software truly turn your technology solutions into a black hole.

Understanding PostgreSQL

Cryptojackers must hide their software somewhere and it’s emerged that your PostgreSQL database is a great place to hide out, as we’ll explain in the next section. But what is PostgreSQL, and do you even use it in your workloads?

Today’s technology solutions are highly complex, layered and integrated – with the typical technology stack depending on many components, some of which you may not even be aware of. These components operate in the background to support your applications.

Most applications rely on a database of some sort – including, for example, MySQL and indeed PostgreSQL. These are database management systems (DBMS), and PostgreSQL is one more of the more powerful options, first released in 1997. PostgreSQL is very popular in part because it is cheap to run and easy to implement.

PostgreSQL also offers important capabilities that make it very fit for enterprise applications, which is possibly why a Stack Overflow survey found that PostgreSQL is the second most popular database solution, after MySQL.

It is reasonable to assume that millions of applications and solutions rely on PostgreSQL – and often does so in the background, simply because a developer picked PostgreSQL for a DBMS.

A PostgreSQL vulnerability that enables cryptojacking

We’ve explained why you need to be worried about a successful cryptojacking attempt – let’s now take a look at how hackers can get cryptomining software into your PostgreSQL database.

In December 2020, a research team found the first example of hackers injecting cryptomining code into PostgreSQL. The team called the software PGMiner, which of course refers to PostgreSQL and mining – in other words, it’s code installed into PostgreSQL and it’s used to mine cryptocurrency.

The code depends on a specific vulnerability in PostgreSQL, a remote code execution vulnerability that enables a hacker to use the PostgreSQL application that you’re running to inject cryptomining code into your system. You can read a deep analysis from the team at Unit 42, it explains the methodology used by PGMiner here.

Interestingly, it may be argued that the “vulnerability” associated with this method of cryptojacking is in fact a feature of PostgreSQL. The PostgreSQL Global Development Group says that the COPY TO/FROM PROGRAM feature involved in the vulnerability is in fact working as intended. Nonetheless, this feature is actively being exploited for cryptojacking.

And here’s another one…

There’s not just one way for hackers to get into your PostgreSQL database. Let’s take a look at another example, just to illustrate how insidious the cryptojacking risk really is.

In this article, security vendor Imperva explains how hackers are injecting cryptomining code into PostgreSQL instances by making use of an image of Scarlett Johannsson. It sounds odd, yes, but essentially by appending malicious code to an image file, attackers can insert their code into a PostgreSQL instance via remote code execution.

The image is hosted on a public image hosting service and it looks like an image of a popular actor, nothing else – but this innocent image hides a real danger as it contains a real payload. According to the authors of the article, many anti-virus applications will not catch the payload in the image file.

It goes to show that attackers have multiple avenues to inject cryptomining code just where they want it to be.

Worse, these exploits are currently out there in the wild – and attackers can use automated tools to find vulnerable PostgreSQL servers. Worse, in the case of CVE-2019-9193, there is currently no patch available.

Handling cryptojacking in the real world

We’ve outlined how cryptomining software can end up costing your organization dearly – both in direct running costs and in unpredictable, indirect costs.

The team that found PGMiner suggested that anyone that makes use of PostgreSQL should focus really hard on best practice. For example, minimizing or completely abolishing the use of superuser access in PostgreSQL and limiting what remote users can do.

Another key point around best practice is the ability to consistently patch vulnerabilities. While CVE-2019-9193 in itself does not currently have an associated patch, in the broad, patching closes the vulnerabilities that act as entry points for attackers – including those who try to install cryptomining code on your servers.

Notably, while many malware threats are restricted to a specific processor architecture, the PostgreSQL threats we discuss in this article are a threat across x86, ARM and MIPS processor architectures.

Automated and live patching is key

We pointed to patching in the previous section – but there are difficulties associated with patching. Patching consistently and effectively is particularly challenging. Tech teams sometimes do not prioritize patching, and rarely have the resources to roll out patches as fast as they can – nor to do so in a truly consistent manner.

As so often is the case in cybersecurity, automation is the first step in getting patching done right. Patching automation lightens the workload for busy technology teams, while boosting consistency by virtue of automation.

But automation alone is not enough as patching often also involves disruption, and it can happen that teams put patching on hold because they are concerned that patching will lead to service breaks. Live patching mitigates this issue by ensuring that patches can be applied without the need to restart servers.

TuxCare Live Patching for PostgreSQL

Live patching is not that widely available – and it is not always available for all the operating systems and services that your solutions depend on – such as PostgreSQL. We’re glad to say, however, that TuxCare is working actively on rolling out live patching for PostgreSQL servers.

We already deliver a live patching solution for important Linux OS distributions and indeed for key libraries in those distributions. Users of our live patching solutions for Linux server operating systems benefit because maintenance teams spend much less time applying patches – TuxCare applies patches automatically.

TuxCare also benefits server maintenance in that our automated, live patching solution applies patches on-the-fly. Live patching means that critical security updates are installed without the need to restart a server – and without disrupting operations.

This live, automated patching feature will soon be available for PostgreSQL databases and will mean that organizations that use TuxCare can significantly improve their PostgreSQL patching regime and therefore reduce many of the opportunities for malware injections – including cryptominers.

Don’t let your PostgreSQL become a black hole

To wrap up, you now know that profit-seeking hackers may be trying to hide cryptomining code in your servers – and indeed in your PostgreSQL database. And it is not a threat that you can ignore – cryptomining software does not peacefully cohabit with your software solutions: it will drain your resources and will put you at risk of very significant costs.

Awareness is a good start, but you must also take action. Tighten up your PostgreSQL instances by limiting permissions, users and by patching consistently. Struggling to patch consistently? Watch out for the coming TuxCare live patching service for DBMS, including PostgreSQL.