Imagine this, one day you discover that your website is being used to propagate malware. Google adds a big red notice, alerting people that this website could be dangerous. You receive hate on social media, find it difficult getting a team able to fix the problem, all of this while your system administrator is on vacation.
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.
Your website contains malware
Let’s start with a summary of our discussion with John.
My company was hacked a few months ago. I usually use the “do not disturb” mode at night – unfortunately for me, because this morning, I woke up to a lot of notifications on my phone. One of the notifications included information that Google had put a big red alert for my online shop, resulting in one of the biggest financial consequences for my company. Other notifications included keywords like “attack,” “hacker,” “access denied,” etc. At that moment, I wasn’t aware of the scale of the attack but could sense the severity of it. I opened the URL for my online shop in the browser and the sight left me feeling terrified. (...)
This is exactly what John saw:
John probably wouldn't have been able to avoid the attack even if he had checked his phone through the night. This “red alert” was just a visible marker of something that had already happened.
(…) I found out that the attack had taken place. Somebody was using OUR website to attack OUR customers with malicious software. If you would like to know what the company owner feels in such a situation, I’ll help you imagine it – the support team was full of tickets from users, complaints about GDPR, customers worried about their data, and unable to access the website. The situation on our social media was similar, with a lot of hate in the comment section and tech sites were quick to write about our problem. My inbox was full, and our competitors had already pointed out our unfortunate situation. (...)
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.
(...) I finally found an available one that could help me with this emergency. The price was expensive, as usually in such cases, but I didn’t have time for negotiations. We signed the required documents like NDA, DPA, ETC – everything happened very fast, I didn’t even have time to read it carefully. The most important thing was to start working on problem remediation without any delay. Fortunately, the team was very organized and informed me that they could start work immediately – they just needed to contact the system administrator to get the required accesses for the servers. I thought that it would be easy – at least it should’ve been if the system administrator hadn’t been on vacation at the time. (…)
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.
In our opinion, 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.
(…) In the next hours the team found and removed the root cause of the problem. It was one of the plugins that we were using in our CMS. Before this, I was pretty sure that WordPress was well secured – everybody told me, that it's continuously tested, under security terms and all defined vulnerabilities are fixed very quickly. On the other hand, even auto-updates didn’t protect my website!
Security is a very complex topic
While looking at application security many different aspects need to be considered. Unfortunately, auto-update itself doesn’t guarantee full protection because it’s just one single element in the whole 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 regarding our products, feel free to contact us directly.
How the attack proceeded
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:
The biggest tip is a path to scripts and styles files (“wp-includes” and “wp-content”), which indicates the CMS type. If it’s still not enough for you, this specific CMS in the default configuration, disclosing the name + version under the “generator” meta tag.
We can call the screenshot above GAME OVER. Now it’s just enough for the attacker to open one of the provided links (for example https://www.exploit-db.com/exploits/46537) and read the instructions – especially this one:
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):
In this specific case, the team identified some malicious files on a server (one of them was the WSO web shell), which can be easily combined with LFI vulnerability to get full access over the server. How is it possible, that such a file was stored on the server? After the log analysis phase, the team identified that it was uploaded traditionally through a file upload mechanism on one of the subpages; the root cause - as usual - was a lack of input validation. When the attacker uploaded the web shell on the server, he was able to use LFI vulnerability to run it and all he had to do, was to identify the path to the uploads folder on the server – which was easy, because of the default WordPress configuration.
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).
One more thing to do
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?
Our recommendations
If you are wondering how to avoid situations like this one, here is what we recommend:
- Install updates immediately (CMS, themes, plugins, servers)
- Prepare code of conduct for such emergency cases – contacts, responsible peoples, backups, etc.
- Continuously scan your application and infrastructure under secure terms (remember, that not all of the vulnerabilities are publicly known) and set up SMS/e-mail notification.
- Validate every input from your users, on the application and server layer as well.
- Configure notifications in Google Search Console.
- Increase awareness among employees, for example by simulated phishing campaigns.
Cyber Security Starts Here! 👇
Vulnerability Management is a cornerstone in a modern cyber security defense.
Global
Sweden
Finland
Norway
Netherlands
India
Malaysia
Denmark
