Last week we had an odd interaction with the developer of the Freemius library where they wanted us take down a post about a fixed vulnerability in their library that seemed to us was already attempting to be exploited through WordPress plugins containing it. That seemed odd to us, since it was already being exploited, so pretty clearly we hadn’t disclosed the vulnerability as they were claiming was at issue with our having put out the post. We wondered if they missed the part about it looking like it was already being exploited (despite among other things it being the headline of our post) or did they assume we were wrong in thinking that? It turns out they already knew it was being attempted to be exploited before they even fixed it:

On Monday, Feb 25th, 2019, we received a support email from a helpful developer that stumbled across a GitHub issue on the WooCommerce repository. The issue was created by a representative of a small hosting company that noticed suspicious activity on their servers. The rep included the relevant activity logs that indicated two potential attacks, and one of them was targeting a plugin running the Freemius SDK.

As we take security very seriously, we immediately conducted a thorough investigation and confirmed the vulnerability was indeed in our SDK.

Due to the severity of the vulnerability, we started to work on a fix right away. After only a few hours we released a patched tag, and notified all the developers that were using a vulnerable SDK version to update the SDK across all of their products ASAP. We also updated the original GitHub issue to let the WooCommerce team know about it (the GH issue we removed after a few hours to reduce exposure).

Somehow that comes at the beginning of a post that goes on to trash us for not following responsible disclosure, despite them knowing that we didn’t discover the vulnerability or disclose it, considering it was already being exploited and fixed before we knew about it.

There are a number of things in that post that would probably be worth discussing, but one element of it stood out in relation to something that happened today.

Somehow one of their takeaways from this situation was to try to hide the situation even more:

Go into silent mode and only alert those who need to know

Since we were so eager to fix the issue asap, I personally made a “rookie” mistake that attracted unwanted attention too early. I went ahead and committed the fix to the GitHub repository we use to manage the SDK. Not only is the repository public, but I explained the fix and used the word “security” in it.

The better approach was to create a private/closed version of the repository, patch the security issue there, and only expose it to the relevant developers instead of making it public. This wouldn’t draw the attention from “vulnerability hunters”.

That doesn’t make a whole lot sense seeing as this was already attempted to be exploited before being fixed and we had already realized what was going on before running across their commit to fix it. Considering that it is highly unlikely that we have any expertise that hackers don’t have, they could have discovered what was going through the same path we did without that information in the commit as well.

Once the vulnerability was known to be being exploited what is most important is to get it fixed, since that will prevent hackers from exploiting, not trying to hide from them something they already know or could easily figure out. That involves making sure that plugins using the library have updated it, which we actually have focused on trying to do while the developer of the plugin is spending time trashing us.

That brings us to something that happened today. We had noticed that with one of the plugins impacted by this Post Snippets, which is one of the 1,000 most popular WordPress plugins and has 30,000+ installs according to wordpress.org, the vulnerability had been fixed after we had notified the developer, but no one was getting the updated version.

As of earlier today if you went to its page on the WordPress Plugin Directory you would have seen that the current version was 3.0.5 and it was last updated three months ago:

If you look at the development log though you would see an updated version, 3.0.6, to fix this was put out on February 27.

The discrepancy was caused by a simple enough mistake, the developer had left the stable tag listed in readme.txt file for the plugin at 3.0.5, so the Plugin Directory kept offering that version. Fixing that is easy and two hours after we notified the developer of the issue, it was resolved.

If we were not aware of the vulnerability and checking over plugins using it, who knows how long that situation might have remained unresolved. If the vulnerability was better hidden from us or anyone else that might be interested in getting plugins secured against this, it clearly wouldn’t have helped in resolving that.

This wasn’t even the first plugin where the developer had tried to fix this and failed that we had noticed, in the previous instance involved us getting a mild legal threat after letting them know that.