0-day-blog-image-1What do you do when a security researcher posts that your website is serving malware?

Many web administrators finding themselves on the wrong end of that sort of post would be rightly concerned. Some may even panic, pulling the site offline and their hair out. Not so security company Flashpoint who not only acted quickly but have now published their After Action report.

The incident started with a post from security researcher Dancho Danchev on his own blog page. In that blog Danchev said: “It appears that Flashpoint’s official Web site is currently embedded with malware-serving malicious script potentially exposing its visitors to a multitude of malicious software.” The blog lists the files containing malicious code on the Flashpoint website. It also lists a number of malicious domains and fraudulent IPs alleged to have been used by the malware.

If true, then this would be a significant embarrassment to Flashpoint and a big headline for Danchev.

What did Flashpoint say?

In a blog from Chris Camacho, Chief Strategy Officer, Flashpoint, he says: “Flashpoint’s public-facing website is not and was never serving malware. We’re happy to shed light on exactly what happened below.”

Chris Camacho, Chief Strategy Officer, Flashpoint
Chris Camacho, Chief Strategy Officer, Flashpoint

Camacho goes on to explain that the incident in question occurred on April 12-13. It seems that a 0-day exploit against a specific WordPress plugin. Camacho doesn’t explicitly name the plugin. Instead he links to a post on Wordfence and an article about 0-day exploits against the Yuzo Related Posts plugin. That post says that the plugin in question was removed from the WordPress directory on March 30, 2019.

Camacho continued by saying that this only affected visitors to the website who had JavaScript enabled. They were redirected to another site which then redirected them to the server with the malware. Importantly Camacho says that no PII was breached and the server is segregated from all of its other systems and production environments.

How did this happen?

This is where the story is a warning to all website administrators. According to Camacho: “The attack wasn’t targeted at Flashpoint specifically. It was an automated attack that picked up our site and injected the vulnerability.”

What this means is that any site with the Yuzo Related Posts plugin installed is similarly at risk from being targeted. What is not clear is just why this plugin was still active on the Flashpoint website. As a security company customers would expect Flashpoint to be on point when it comes to patching and removing unwanted code. It shows that this is the sort of attack that can catch out any company.

The Wordfence blog says that over 600,000 websites were using the plugin when it was withdrawn. It is highly likely that a percentage of those still have the plugin installed. All of these run the risk of being affected by the attack.

What actions did Flashpoint take?

Camacho outlined the five steps that Flashpoint took once it was aware of this vulnerable plugin. They are:

  1. Our security team immediately removed the malicious plugin.
  2. We have audited all of our plugins and removed any that are not critical to the functionality of our website.
  3. We increased the frequency of our thorough scanning and auditing procedures to decrease the time from detection to remediation.
  4. We have written (and tested) custom monitoring that emulates JavaScript and will detect this type of attack in the future.
  5. Sent a communication to our FPCollab community immediately after notification of the blog post, as well as a direct Flash report to all of our users.

The first three steps here are good practice for all website administrators and can be implemented quickly. Step four is more complicated and it will be interesting to see if Flashpoint offers that code to any of its customers.

Enterprise Times: What does this mean?

It is easy to take issue with both Danchev and Flashpoint. There is no evidence that Danchev warned Flashpoint in advance of his blog that he was going to publish. If that is the case then he is guilty of failing to observe responsible disclosure guidelines for security researchers. Ironically, it was just that type of behaviour where a researcher disclosed the 0-day attack on the plugin that left its users at risk in the first place. We have emailed Danchev to ask if he did talk to Flashpoint but so far, no response.

For its part Flashpoint also has to take some blame. The first three steps it has implemented seem pretty standard. Regular auditing of plugins and removal of any that have security warning or are no longer supported should be a given. A weekly check of the WordPress site would have alerted Flashpoint to this particular issue. In addition, the removal of any unused or unwanted plugins is about reducing attack surface.

At the end of the day, this attack shows the risk posed by plugins to organisations of all sizes. Unlike the vast majority of WordPress users, Flashpoint cannot claim to have limited cyber security staff. Many businesses will look at this and think: “If it happens to them, how am I supposed to prevent it?”

The answer lies in steps 1-3 above.


Please enter your comment!
Please enter your name here