Plugin & Theme Developers: This Is What You Can Learn From Our SDK’s Security Vulnerability

This week was pretty intense for our team as we had to deal with a security vulnerability. Security is top priority for us and this is the first major vulnerability found in our SDK in four years. Unfortunately, like with any software – developers are humans too, so mistakes do happen, whether you are an indie developer, a theme shop of 20 people, or Google. The purpose of this article is first of all transparency, but also to give you insight into how we handled the incident and what you can learn from 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).

To mitigate the exposure and give everyone some “grace” period to update to the fixed version, we asked developers two things:
(a) If this security upgrade will be included in your changelog, please only use generic wording like “Security fix”.
(b) Even after updating and releasing the patched versions, please do not disclose this issue during the next 30 days, allowing enough time for all our partners and their users to update.

Just a day after, a website that covers plugins vulnerabilities (intentionally not linking to them or mentioning their name) published a post about the vulnerability, including information on how to exploit it while naming a few of the affected plugins. This took us by surprise as we just notified the plugin & theme developers about the issue less than 24 hours before. They didn’t contact us nor followed the Responsible Disclosure market practice, which we find quite irresponsible and unethical.

I reached out to them asking to temporarily unpublish the report to reduce the exposure and give our developers and their users a chance to update to the patched versions before it attracts unwanted attention from more hackers. But the person that I communicated with, which never exposed their name (I asked them), has their own righteous ideology and seems like common sense doesn’t really appeal to them. I did try to explain the problematic situation and the increased risk they are exposing to many developers and users, but my efforts fell on deaf ears, and I realized my email exchange was just a waste of time.

As our developers’ community was updating their plugins and themes to the newly patched SDK we released, we discovered two issues:

1. Several developers didn’t get our alert email because they registered to Freemius with an email address that they are not checking.
2. We intentionally didn’t flag the patched GitHub tag as an official release to avoid drawing attention. However, we learned that developers who were using Composer to update their libraries were not getting the latest update because packgist fetches only releases, unless specifying a tag explicitly.

To overcome those issues:

1. Because the vulnerability was already published publicly, two days ago we flagged the patched version as an official release so developers that rely on packgist will be able to update.
2. Earlier this morning we emailed another batch of messages to developers that have yet to update the SDK on all of their products. This time we sent the messages to their official support channels to increase the chances of everyone receiving the emails properly.

Even though we wanted to postpone the publication of this vulnerability by at least two weeks, we received a further inquiry from WP Tavern asking our input before they published their own article on the topic, which was the straw that broke the developer’s keyboard.

The Mistakes We Made And What You Can Learn From Them

Looking back at the incident, we made several mistakes that we could easily avoid and would have made everyone’s lives much easier.

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”.

Don’t waste your energy on “security trolls”

The second mistake was trying to interact with the company behind the site that published the vulnerability. It was a total waste of time and energy, and only triggered more antagonism which ended up with another post about the vulnerability. I would say that a good indicator to decide whether it’s worth your time to contact an author of a post that risks your plugin or theme users, is if there’s a name behind the post/website/company. If they are hiding behind proxies and acting irrationally, the chance that you can talk sense to them is practically zero.

So this is my advice – get into silent mode and only notify the people that must know about the vulnerability. In the case of a plugin/theme, that’s your users. This is also a good opportunity to emphasize the importance of collecting your users’ emails. If you don’t have a way to privately communicate with your users, you don’t have an effective way to privately notify them about security issues.

The Current Status Of The Incident

More than 60% of the developers who are using our SDK have already upgraded to the patched version. Additionally, the SDK comes with a special mechanism that allows multiple Freemius supported plugins or themes installed on the same WordPress website to use the newest version of the SDK if one of the products is already updated. So that’s good.

That said, there are still many sites that are vulnerable. That’s why I didn’t mention any technical details about the vulnerability itself, nor the affected products. We still want to offer our developers the chance to patch their products and allow their users to update to the secure versions.

How To Reduce Security Risks In Your WordPress Plugin/Theme?

If you don’t have any security background, Google “web security best practices” and you’ll find tons of articles and practices. Read a few of those to be aware of modern and typical potential risks and mistakes. Keep those in mind during the development and testing processes. Another good practice is to run periodic security audits by hiring a security researcher. It will cost a few hundred dollars, but if you are relying on your product as your main source of income, it’s a no brainer.

Unfortunately, as in our case, bad things can still happen. Even though we have a very strong security background, we conduct thorough code reviews and work with an experienced security researcher from the HackerOne community, yet this vulnerability still slipped through the cracks. 😔

I think that one of the reasons it happened is because the vulnerable code was actually added to debug edge cases and is not part of the SDK’s core functionality. So if there’s a lesson here, treat any piece of code in your product the same way, whether it is part of the actual business logic or anything else.

Recap

Security issues are inevitable in the software world. Whether we/you like it or not, one day your plugin or theme will have a security issue. The issue can be in your code, a library/framework you are using, a WordPress core method that provides unexpected results, and many more scenarios.

When it happens (I hope it won’t), don’t stress out (we definitely did) and act impulsively — it will only do more damage. Draft a methodological recovery plan, notify the affected parties, and be there to help your users to secure their sites. Everyone knows that security issues happen, what’s more important is how you deal with the situation.

With that said, on behalf of the whole Freemius team, we are truly sorry for the inconvenience and will be here throughout the whole weekend to offer support, advise, or any other help related to the issue. And for our new users, I know how important the first impression is, and this is definitely not a good one. I hope that you’ll give Freemius another chance, and with time, see the amazing features we offer for your WordPress plugins and themes.