<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=645174729237247&amp;ev=PageView&amp;noscript=1">
We are updating the structure and design of KernelCare blog for your convenience. Today, you may experience some text formatting inconvenience which will be fixed shortly.

Cryptominers Could Be Right Inside Your PostgreSQL Database

Cryptominers Could Be Right Inside Your PostgreSQL DatabaseMalware takes different shapes and forms. Some malware is immediately damaging. Think about an all-encompassing ransomware attack that locks up all of your data, for example. Other types of malware sneaks in without being noticed. Sneaky, insidious malware can lead to long-term financial consequences and, even worse, reputational damage. It is arguably more dangerous than obvious malware that alerts you to its presence.

Cryptojacking is one of the more insidious types of malware. This December, it emerged that this incredibly insidious malware may be hiding where you expect it the least – your PostgreSQL database.

 

Contents:

  1. What Exactly Is Cryptojacking?

  2. What Are The Risks Of Cryptojacking?

  3. Brief Introduction To PostgreSQL

  4. The PostgreSQL Vulnerability That Opens The Door To Cryptojacking

  5. When a Vulnerability Is Actually a Feature

  6. What Does CVE-2019-9193 Mean In Practice?

  7. Why Vulnerability Awareness And Best Practice Is Critical

  8. The Answer Lies In Automated Live Patching

  9. KernelCare+ Live Patching for PostgreSQL Is Coming

  10. Conclusion

 

What Exactly Is Cryptojacking?

What Exactly Is Cryptojacking?

Before we move on to the PostgreSQL characteristic that enables the exploit, let’s first take a look at cryptojacking and the motivations behind it.

Cryptocurrency is big business – back in the day, an individual equipped with a simple personal computer could use their PC to “mine” cryptocurrency and make a handsome return. Today the costs of mining in terms of computing power and energy use are much more prohibitive, to the extent that it is often not profitable to mine cryptocurrency on account of the associated costs.

Cryptojacking occurs when a malevolent actor hijacks your computing equipment in order to use your resources to mine cryptocurrency without your permission. The hijacker uses your resources free of charge – but keeps all of the profits of mining cryptocurrency for themselves. They also have the motivation to stay hidden as long as possible – injecting their cryptomining code where you’re least likely to look.

 

What Are The Risks Of Cryptojacking?

What Are The Risks Of Cryptojacking?

Cryptojacking doesn’t appear as if it will cost your organization that much – not at first glance, anyway. After all, the motivation is not to steal your data or to hold your data ransom. Instead, the malevolent actor behind cryptomining is simply abusing your computing resources for their own gain.

Think that cryptojacking isn’t a big issue? Think again. An unknown, illicit actor making use of your computing resources without permission can lead to heavy costs. If your systems are subject to cryptojacking you can look at any or all of the following consequences:

  • Reduced resource availability.  Cryptominers will compete against your own application resource requirements when it comes to computing resources. Where you have meticulously planned sufficient resources for your application demands you may find that your applications unexpectedly fail, or underperform – leading to unhappy stakeholders. Finding the reasons for these performance problems can be extremely difficult.
  • Hardware damage. Your systems configurations will ensure that you never abuse your hardware by, for example, continuously running CPUs at maximum utilization. Cryptominers will be less careful. In the long run, illicit cryptomining can lead to costly and expensive hardware wear and even failure.
  • Unexpected costs. Hardware failure is not the only cost of cryptomining: equipment that is needlessly run at full capacity will consume more energy. Cryptomining is widely known to be very energy intensive. Expect your electricity bills to skyrocket if any of your servers are used for cryptomining.
  • Security and compliance concerns. If your business handles confidential data or data covered by regulation you can get into deep trouble if an unauthorized third party has access to your systems.  A cryptominer that’s installed on one of your servers could open the door to something worse.
  • Cryptominers can be repurposed. Though cryptomining on its own does not mean your confidential data will be leaked, you must be aware of the fact that an unauthorized party has intruded into your systems. This intrusion may evolve – for example, the cryptomining software may turn into ransomware.

That’s why Illicit cryptomining software, wherever it is on your system, must be treated as a serious cybersecurity breach. Unauthorized cryptomining software is malware, and nothing else. And, just like any other malware, it has a way of sneaking into places you least expect.

This year, it’s emerged that PostgreSQL is one of these places.

 

Brief Introduction To PostgreSQL

Brief Introduction To PostgreSQL

The technology stacks most applications depend on are highly layered and complex. Widely used tools can disappear into this tech stack – working in the background. PostgreSQL is one of these widely used components that supports countless applications. And it’s a great place to hide cryptomining software.

PostgreSQL is an open source database management system. It was first released early in 1997, and today supports vast numbers of applications. Over time PostgreSQL has become very popular in part due to its low costs – it is open-source and easy to implement.

But PostgreSQL is also known to be one of the more powerful relational DBMS available – consider its ability to support multitiered applications that logically separates application and operational layers, for example. Likewise, PostgreSQL is known to be one of the more scalable and more extensible DBMS available for enterprise applications.

Given that PostgreSQL is so affordable and capable it is no surprise that it is so popular: in fact, a Stack Overflow survey suggests that PostgreSQL is the second most popular DBMS, after MySQL. That implies that millions of applications are running on PostgreSQL.

Indeed, your application may depend on PostgreSQL – and you may not even know about it.

 

The PostgreSQL Vulnerability That Opens The Door To Cryptojacking
The PostgreSQL Vulnerability That Opens The Door To Cryptojacking

Cryptojacking is clearly something to be worried about. And, as we stated earlier, cryptomining malware can hide in the most unlikely of places – including in your PostgreSQL instances. Let’s take a look at what emerged last week.

A research time of five - Yue Chen, Jim Fitzgerald, Yang Ji, Claud Xiao and Xiao Zhang found the first example of cryptomining code injected into PostgreSQL and called it PGMiner. In short, PGMiner depends on the PostgreSQL vulnerability CVE-2019-9193 to inject cryptomining code into a database instance.

It is essentially a remote code execution vulnerability (RCE) that allows someone from outside of your organization to use your PostgreSQL instance as a platform for cryptocurrency mining. Unit 42 has a deep analysis of the exact methodology behind PGMiner, which is beyond the scope of this article.

However, in short, once PGMiner has breached the perimeter it looks at the systems architecture of the server and based on that downloads a mining payload to match. It reproduces itself by recursively downloading specific modules as it works it way towards broader infection.

Of course, the PGMiner exploit hiding in your PostgreSQL may seem relatively innocuous, after all it is just mining cryptocurrency. But you must stay alert to the fact that a PGMiner infection may lead to a far bigger breach. Though PGMiner was developed to facilitate illicit cryptomining, it may evolve into a much more nefarious tool. In other words, though PGMiner compromises your PostgreSQL database, it can lead to an attack on another major application or service.

 

When a Vulnerability Is Actually a Feature
When a Vulnerability Is Actually a Feature

One thing to note about this particular PostgreSQL exploit is that the vulnerability in question, CVE-2019-9193, is in fact disputed. (Remember: CVEs refer to the database of Common Vulnerabilities and Exposures, a public catalog of cybersecurity vulnerabilities). When a vulnerability is disputed it is entered into the database, but marked as under question.

According to the PostgreSQL Global Development Group, CVE-2019-9193 is not a vulnerability – the group says that it is functionality that is working as expected.

This particular function, “COPY TO/FROM PROGRAM”, allows both users and superusers in a specific group to execute code in the context of the DBMS’ operating system user. According to the original filing, the function can be abused by malicious actors to run commands in Linux, macOS and Windows environments.

Clearly, if what the PostgreSQL Global Development Group calls a “feature” didn’t exist, then there would be no opportunity for PGMiner to emerge. But PGMiner is with us, today.

 

What Does CVE-2019-9193 Mean In Practice?

What Does CVE-2019-9193 Mean In Practice?

Unfortunately, PGMiner is out in the wild – and infecting PostgreSQL instances as we speak, via CVE-2019-9193. Because PostgreSQL has not released a patch there is currently no automatic way to stop this exploit, other than very close surveillance of the PostgreSQL instance.

In other words, your PostgreSQL database server is vulnerable and could be used for cryptomining without your knowledge. Inevitably, PostgreSQL will need to address the issue – either via a patch, or indeed via a feature change.

As a side note, it is worth understanding that, as stated by Palo Alto Networks’ Unit 42, malicious actors are increasingly weaponizing not only confirmed CVEs – but also disputed CVEs.

So what can you do to protect your DBMS?

 

Why Vulnerability Awareness And Best Practice Is Critical

Why Vulnerability Awareness And Best Practice Is Critical

The team that discovered PGMiner stated that they suggest that, as always, PostgreSQL users apply best practice by ensuring that superuser access is never granted to remote users or users who are otherwise not trusted.

So best practice is the starting point – best practice when managing your applications and infrastructure, but also best practice when it comes to patching vulnerabilities. Though we’re not sure at what point the exploit in question here will be patched, we do know that exploits are regularly addressed via a patch.

However, while continuous and regular patching is best practice, it is unfortunately not always implemented. According to Trend Micro, unpatched vulnerabilities remain one of the biggest reasons why companies suffer from intrusions.

Part of the problem is that consistent patching is difficult. It takes a significant amount of time and many organizations simply do not have the resources to consistently patch every application, service and operating system right around the clock. There is also an issue in that patching often means that a system must be taken offline – which means disruption to other systems or indeed to your customers.

 

The Answer Lies In Automated Live Patching

The Answer Lies In Automated Live Patching

It’s a tough conundrum: patch at great expense – spending a large sum of money on staff and resources, while frustrating customers with downtime. Or, leave holes in your organization’s patching regime – and risk a malware intrusion.

But it doesn’t need to be that way. Automated patching is the first step – using a tool that consistently applies newly released patches. The next, and critical step, is live patching. Live patching is where your patching tool is able to install a new version of software – a new version of a kernel, for example – without requiring you to reboot your server.

However, live patching is somewhat of a novelty – it requires intelligent manipulation of running services to switch out code that is in active use, and to insert the latest, patched version of that code.

 

 

KernelCare+ Live Patching for PostgreSQL Is Coming

KernelCare+ Live Patching for PostgreSQL Is Coming

KernelCare+ is an established tool that is used by organizations around the globe to live patch Linux instances – including virtualized Linux servers that support complex cloud applications. It ensures that these Linux instances are always operating the latest, fully patched kernel – without the need to constantly and disruptively restart the servers.

Given the increasing cybersecurity risks around PostgreSQL we are glad to announce that KernelCare+ is working on a live patching solution for PostgreSQL instances. Just like our live patching for Linux servers, the PostgreSQL live patching solution we are due to roll out will enable organizations to ensure consistent PostgreSQL patching without requiring frequent downtime.

 

Conclusion

Attackers are getting more and more inventive – including exploiting disputed CVEs. It implies that security teams and sysadmins must always apply watertight good practice, including consistent, gapless patching. It also means that teams must respond faster than ever once a vulnerability does emerge.

A PGMiner attack can cause significant disruption to your services. To avoid the need for a full clean up or even the need to re-install or re-configure your database due to the PGMiner attack, stay in the lookout for live patches by KernelCare+. 

Cryptominers Could Be Right Inside Your PostgreSQL Database

Cryptominers Could Be Right Inside Your PostgreSQL DatabaseMalware takes different shapes and forms. Some malware is immediately damaging. Think about an all-encompassing ransomware attack that locks up all of your data, for example. Other types of malware sneaks in without being noticed. Sneaky, insidious malware can lead to long-term financial consequences and, even worse, reputational damage. It is arguably more dangerous than obvious malware that alerts you to its presence.

Cryptojacking is one of the more insidious types of malware. This December, it emerged that this incredibly insidious malware may be hiding where you expect it the least – your PostgreSQL database.

 

Contents:

  1. What Exactly Is Cryptojacking?

  2. What Are The Risks Of Cryptojacking?

  3. Brief Introduction To PostgreSQL

  4. The PostgreSQL Vulnerability That Opens The Door To Cryptojacking

  5. When a Vulnerability Is Actually a Feature

  6. What Does CVE-2019-9193 Mean In Practice?

  7. Why Vulnerability Awareness And Best Practice Is Critical

  8. The Answer Lies In Automated Live Patching

  9. KernelCare+ Live Patching for PostgreSQL Is Coming

  10. Conclusion

 

What Exactly Is Cryptojacking?

What Exactly Is Cryptojacking?

Before we move on to the PostgreSQL characteristic that enables the exploit, let’s first take a look at cryptojacking and the motivations behind it.

Cryptocurrency is big business – back in the day, an individual equipped with a simple personal computer could use their PC to “mine” cryptocurrency and make a handsome return. Today the costs of mining in terms of computing power and energy use are much more prohibitive, to the extent that it is often not profitable to mine cryptocurrency on account of the associated costs.

Cryptojacking occurs when a malevolent actor hijacks your computing equipment in order to use your resources to mine cryptocurrency without your permission. The hijacker uses your resources free of charge – but keeps all of the profits of mining cryptocurrency for themselves. They also have the motivation to stay hidden as long as possible – injecting their cryptomining code where you’re least likely to look.

 

What Are The Risks Of Cryptojacking?

What Are The Risks Of Cryptojacking?

Cryptojacking doesn’t appear as if it will cost your organization that much – not at first glance, anyway. After all, the motivation is not to steal your data or to hold your data ransom. Instead, the malevolent actor behind cryptomining is simply abusing your computing resources for their own gain.

Think that cryptojacking isn’t a big issue? Think again. An unknown, illicit actor making use of your computing resources without permission can lead to heavy costs. If your systems are subject to cryptojacking you can look at any or all of the following consequences:

  • Reduced resource availability.  Cryptominers will compete against your own application resource requirements when it comes to computing resources. Where you have meticulously planned sufficient resources for your application demands you may find that your applications unexpectedly fail, or underperform – leading to unhappy stakeholders. Finding the reasons for these performance problems can be extremely difficult.
  • Hardware damage. Your systems configurations will ensure that you never abuse your hardware by, for example, continuously running CPUs at maximum utilization. Cryptominers will be less careful. In the long run, illicit cryptomining can lead to costly and expensive hardware wear and even failure.
  • Unexpected costs. Hardware failure is not the only cost of cryptomining: equipment that is needlessly run at full capacity will consume more energy. Cryptomining is widely known to be very energy intensive. Expect your electricity bills to skyrocket if any of your servers are used for cryptomining.
  • Security and compliance concerns. If your business handles confidential data or data covered by regulation you can get into deep trouble if an unauthorized third party has access to your systems.  A cryptominer that’s installed on one of your servers could open the door to something worse.
  • Cryptominers can be repurposed. Though cryptomining on its own does not mean your confidential data will be leaked, you must be aware of the fact that an unauthorized party has intruded into your systems. This intrusion may evolve – for example, the cryptomining software may turn into ransomware.

That’s why Illicit cryptomining software, wherever it is on your system, must be treated as a serious cybersecurity breach. Unauthorized cryptomining software is malware, and nothing else. And, just like any other malware, it has a way of sneaking into places you least expect.

This year, it’s emerged that PostgreSQL is one of these places.

 

Brief Introduction To PostgreSQL

Brief Introduction To PostgreSQL

The technology stacks most applications depend on are highly layered and complex. Widely used tools can disappear into this tech stack – working in the background. PostgreSQL is one of these widely used components that supports countless applications. And it’s a great place to hide cryptomining software.

PostgreSQL is an open source database management system. It was first released early in 1997, and today supports vast numbers of applications. Over time PostgreSQL has become very popular in part due to its low costs – it is open-source and easy to implement.

But PostgreSQL is also known to be one of the more powerful relational DBMS available – consider its ability to support multitiered applications that logically separates application and operational layers, for example. Likewise, PostgreSQL is known to be one of the more scalable and more extensible DBMS available for enterprise applications.

Given that PostgreSQL is so affordable and capable it is no surprise that it is so popular: in fact, a Stack Overflow survey suggests that PostgreSQL is the second most popular DBMS, after MySQL. That implies that millions of applications are running on PostgreSQL.

Indeed, your application may depend on PostgreSQL – and you may not even know about it.

 

The PostgreSQL Vulnerability That Opens The Door To Cryptojacking
The PostgreSQL Vulnerability That Opens The Door To Cryptojacking

Cryptojacking is clearly something to be worried about. And, as we stated earlier, cryptomining malware can hide in the most unlikely of places – including in your PostgreSQL instances. Let’s take a look at what emerged last week.

A research time of five - Yue Chen, Jim Fitzgerald, Yang Ji, Claud Xiao and Xiao Zhang found the first example of cryptomining code injected into PostgreSQL and called it PGMiner. In short, PGMiner depends on the PostgreSQL vulnerability CVE-2019-9193 to inject cryptomining code into a database instance.

It is essentially a remote code execution vulnerability (RCE) that allows someone from outside of your organization to use your PostgreSQL instance as a platform for cryptocurrency mining. Unit 42 has a deep analysis of the exact methodology behind PGMiner, which is beyond the scope of this article.

However, in short, once PGMiner has breached the perimeter it looks at the systems architecture of the server and based on that downloads a mining payload to match. It reproduces itself by recursively downloading specific modules as it works it way towards broader infection.

Of course, the PGMiner exploit hiding in your PostgreSQL may seem relatively innocuous, after all it is just mining cryptocurrency. But you must stay alert to the fact that a PGMiner infection may lead to a far bigger breach. Though PGMiner was developed to facilitate illicit cryptomining, it may evolve into a much more nefarious tool. In other words, though PGMiner compromises your PostgreSQL database, it can lead to an attack on another major application or service.

 

When a Vulnerability Is Actually a Feature
When a Vulnerability Is Actually a Feature

One thing to note about this particular PostgreSQL exploit is that the vulnerability in question, CVE-2019-9193, is in fact disputed. (Remember: CVEs refer to the database of Common Vulnerabilities and Exposures, a public catalog of cybersecurity vulnerabilities). When a vulnerability is disputed it is entered into the database, but marked as under question.

According to the PostgreSQL Global Development Group, CVE-2019-9193 is not a vulnerability – the group says that it is functionality that is working as expected.

This particular function, “COPY TO/FROM PROGRAM”, allows both users and superusers in a specific group to execute code in the context of the DBMS’ operating system user. According to the original filing, the function can be abused by malicious actors to run commands in Linux, macOS and Windows environments.

Clearly, if what the PostgreSQL Global Development Group calls a “feature” didn’t exist, then there would be no opportunity for PGMiner to emerge. But PGMiner is with us, today.

 

What Does CVE-2019-9193 Mean In Practice?

What Does CVE-2019-9193 Mean In Practice?

Unfortunately, PGMiner is out in the wild – and infecting PostgreSQL instances as we speak, via CVE-2019-9193. Because PostgreSQL has not released a patch there is currently no automatic way to stop this exploit, other than very close surveillance of the PostgreSQL instance.

In other words, your PostgreSQL database server is vulnerable and could be used for cryptomining without your knowledge. Inevitably, PostgreSQL will need to address the issue – either via a patch, or indeed via a feature change.

As a side note, it is worth understanding that, as stated by Palo Alto Networks’ Unit 42, malicious actors are increasingly weaponizing not only confirmed CVEs – but also disputed CVEs.

So what can you do to protect your DBMS?

 

Why Vulnerability Awareness And Best Practice Is Critical

Why Vulnerability Awareness And Best Practice Is Critical

The team that discovered PGMiner stated that they suggest that, as always, PostgreSQL users apply best practice by ensuring that superuser access is never granted to remote users or users who are otherwise not trusted.

So best practice is the starting point – best practice when managing your applications and infrastructure, but also best practice when it comes to patching vulnerabilities. Though we’re not sure at what point the exploit in question here will be patched, we do know that exploits are regularly addressed via a patch.

However, while continuous and regular patching is best practice, it is unfortunately not always implemented. According to Trend Micro, unpatched vulnerabilities remain one of the biggest reasons why companies suffer from intrusions.

Part of the problem is that consistent patching is difficult. It takes a significant amount of time and many organizations simply do not have the resources to consistently patch every application, service and operating system right around the clock. There is also an issue in that patching often means that a system must be taken offline – which means disruption to other systems or indeed to your customers.

 

The Answer Lies In Automated Live Patching

The Answer Lies In Automated Live Patching

It’s a tough conundrum: patch at great expense – spending a large sum of money on staff and resources, while frustrating customers with downtime. Or, leave holes in your organization’s patching regime – and risk a malware intrusion.

But it doesn’t need to be that way. Automated patching is the first step – using a tool that consistently applies newly released patches. The next, and critical step, is live patching. Live patching is where your patching tool is able to install a new version of software – a new version of a kernel, for example – without requiring you to reboot your server.

However, live patching is somewhat of a novelty – it requires intelligent manipulation of running services to switch out code that is in active use, and to insert the latest, patched version of that code.

 

 

KernelCare+ Live Patching for PostgreSQL Is Coming

KernelCare+ Live Patching for PostgreSQL Is Coming

KernelCare+ is an established tool that is used by organizations around the globe to live patch Linux instances – including virtualized Linux servers that support complex cloud applications. It ensures that these Linux instances are always operating the latest, fully patched kernel – without the need to constantly and disruptively restart the servers.

Given the increasing cybersecurity risks around PostgreSQL we are glad to announce that KernelCare+ is working on a live patching solution for PostgreSQL instances. Just like our live patching for Linux servers, the PostgreSQL live patching solution we are due to roll out will enable organizations to ensure consistent PostgreSQL patching without requiring frequent downtime.

 

Conclusion

Attackers are getting more and more inventive – including exploiting disputed CVEs. It implies that security teams and sysadmins must always apply watertight good practice, including consistent, gapless patching. It also means that teams must respond faster than ever once a vulnerability does emerge.

A PGMiner attack can cause significant disruption to your services. To avoid the need for a full clean up or even the need to re-install or re-configure your database due to the PGMiner attack, stay in the lookout for live patches by KernelCare+.