At Holm Security, we provide solutions for vulnerability assessment. In meetings with our customers, we sometimes discuss previous incidents that could've easily been avoided. This time, we've decided to publish one such story, to show you what it looks like from a different perspective – from the point of view of the company owner and how it happened. This story has been described with the approval and anonymization of our customers.
Some time ago, before using Holm Security's platform, the company led by our customer (who, for this article, we'll call John) had been hacked. We know a lot of similar stories, but this specific one is a great case study for anyone making a security-related decision – and it doesn't matter if you are a project manager at a big corporation or own a small online shop.
Let's start with a summary of our discussion with John.
This is exactly what John saw:
John decided to start a remediation plan but quickly realized that it wasn’t as easy as he first had thought. Feeling the need to act swiftly to remove the malware from the servers, John started by contacting different pentest teams.
John's system administrator called him back after 5 hours, providing him with all the necessary information over the phone and e-mail (stating that it was not enough time to do it the proper way) and the hired team was able to start the cleanup process.
We believe John should have tried to remain calm and not make emotional decisions. It’s always good to have an already predefined (and well-tested) code of conduct for such cases. If John had created a risk assessment before the incident, the situation where no one, except the system administrator, has access to the servers could've been quickly mitigated. Another option is to have an alternative secure communication channel.
While looking at application security, many different aspects need to be considered. Unfortunately, auto-update doesn’t guarantee full protection because it’s just one element in the security process. John forgot about the plugins updates, which need to be updated separately, as well as themes. Ask yourself; do you always remember to do this?
Even if it’s important to remember that such updates won’t give 100% protection. Servers, operating systems, and multiple services running (some of them accessible from the internet)– all those elements need to be regularly updated. While not all of the vulnerabilities are publicly known, there are still other risk factors; we also have to account for the human factor.
While reading this, you might get the impression that you need to hire a big team of experts (and have a big budget for that) to handle all these things - and you are right, but only partially. A lot of this critical work can be fully automated with the right tools. Holm Security is a vendor for such solutions. We provide products for continuous and automated vulnerability analysis. If you have any questions about our products, contact us directly.
We reproduced the whole attack step by step- based on information provided by John, especially for you. Below we’ll present, from the attackers’ perspective, what the attack looked like. First, we’ll reproduce the 1:1 lab environment – CentOS 7, MySQL database, WordPress (in the same version), and not the updated WordPress Grace Media Player plugin.
Right, while we got this information from John, the question is, how did the attacker do it? The answer is straightforward. Usually, it’s just enough to investigate the source code view to find out a few tips:
In practice, if you add this specific URL to your website, you will get the content of the passwd file as a proof of concept (and, you can try to read other data as well):
This gave him a very user-friendly graphical interface with the possibility to execute any actions directly on the hacked server (regarding assigned privileges, but still, there is something like Local Privilege Escalation if needed).
There was still one more problem - regarding a notice from Google. To fix this, the application owner must log in to the Google Webmasters Tool and confirm that the problem is already solved. Then, Google will make a verification process, and if everything is fine now, the red notice will be disabled. Such verification could take a few days – consider one thing, can your business afford this?
If you are wondering how to avoid situations like this one, here is what we recommend: