Many don’t know who I am. My name is Tony Perez, I’m the CEO of Sucuri. I have the pleasure of calling this company my family and everyday I work for every person at this company. My partner is Daniel Cid. He is one of the foremost thought leaders in the website security domain, his influence extending far beyond the communities that make up some of the most popular CMS applications today.
Together we are building one of the fastest growing Website Security companies in the domain, we have one simple mission, to create a safer web. We are a technology company built by technologists with a special, quirky, idea that we can make a difference.
Many don’t realize that the bedrock of our business is Research, all facets of research. It’s how we stay ahead of the bad guys, or attackers. It’s a responsibility we have, not just to the general public, but one that we owe to our clients – in basic terms, it’s what they pay us for. It’s how we ensure our tools and technologies stay ahead of the rest and what makes us the ideal solution for every website owner, our commitment to the Website Security domain.
This has come to head recently from the huge debacle over the past few weeks in which we reported a very serious vulnerability in the WordPress MailPoet Plugin (WHYSIJA-NEWSLETTERS). In the coming days the attackers proceeded to identify, then begin to exploit the disclosed vulnerability.
Frankly put, the entire situation was very unfortunate.
Some Background on the Recent MailPoet Issue
Here is a more accurate timeline on the order of events:
- 2014, Jun 16: Notified MailPoet of the vulnerability, provided patching recommendations.
- 2014, Jun 16: MailPoet team replied and said they were working on a fix.
- 2014, Jun 18: Notified Sucuri that they had fixed the bug and would released a patch soon.
- 2014, Jul 01: The MailPoet team updated WP.org with the new release.
- 2014, Jul 07: MetaSploit Module released for the Vulnerability
The total order of events from took 15 days.
Upon release of the blog post the MailPoet team did contact us to express their discontent with our actions, and this was our response in the interest of transparency:
As far as disclosing the vulnerability, this is quite a common practice and the correct way to bring awareness to a security issue. A good example of a perfect security disclosure was done by the Automattic team with JetPack:
As soon as they released a patch, they notified all users and contacted multiple blogs to ask them to urge everyone to upgrade.
I imagine you are worried about brand impact, but every piece of software will have bugs and security issues at some point. It rarely has any brand impact and if you respond properly, it can have the opposite effect and be very good for you plugin and team reputation. The “We had an issue, we fixed and it won’t happen again” type of message that your users would prefer to hear from you than from some external blog.
As for us, we don’t do that for publicity. It is just part of our research and work that we do every day. Even before Sucuri started, we were auditing code and disclosing security issues. Our goal is to be ahead of the bad guys to protect our clients and help the web at a whole.
I leave it for you all, unedited.
Open Letter to MailPoet
As to be expected, the MailPoet team is pretty pissed off as it would be expected. So pissed in fact that they felt compelled to question our intent and whether we shared the same goals, so let’s talk about that for a minute.
Are we sure we are all aiming for an open, safe web in the WordPress community?
In an effort to provide some peace of mind and transparency in our thought process, please read this open letter to MailPoet:
Hi Mailpoet Team
First and foremost, I am sorry for the troubles you have been experiencing as of late.
Second, I did want to take a minute to clarify a few points to avoid speculation:
1 – Let’s start with reasonable time:
MailPoet Post: It’s common practice among software security circles to disclose bugs privately with software companies, then get a reward, credit and the possibility to write about it, given a reasonable amount of time to fix it.</p>
You see, it’s all about a reasonable amount of time.</strong>
Responsible disclosure is about time to patch. That is what we provided. We disclosed only after your organization patched and made it publicly available.
Responsible disclosure has nothing to do with providing reasonable time after the patch to wait before disclosing publicly. Especially when you look at how the issue was highlighted, or lack there of in the change log.
Nothing highlighted the seriousness of the issue, so we did. That’s what we feel is our responsibility. It’s buried and lacks any emphasis, it’s why so many in the security business subscribed to Full Disclosure (i.e., https://www.schneier.com/blog/archives/2007/01/debating_full_d.html)
This was a very serious vulnerability, one that deserved attention and we did so after it was patched, as is expected and is the norm.
2 – In regards to this:
MailPoet Post: effectively giving no time to users to upgrade their MailPoet version
It’s arguable that the only reason many updated their plugins when the patch was released was because of our public release and our ability to reach 100′s of thousands of WordPress Website owners. We were also able to make contact with hosts, managed host, and development shops.
3 – In regards to this:
MailPoet Post: before posting a detailed technical disclosure
We did not post a detailed technical post. We did not share a Proof of Concept which is actually very standard, we did reference elements that we felt had a greater impact than the ecosystem in which your plugin currently operates. Here is a snippet of the technical description you are alluding too:
Sucuri Post: Because of the nature of the vulnerability, specifically it’s severity, we will not be disclosing additional technical details. The basics of the vulnerability however is something all plugin developers should be mindful of: the vulnerability resides in the fact that the developers assumed that WordPress’s “admin_init” hooks were only called when an administrator user visited a page inside /wp-admin/.
As you know, we also did not disclose any Proof of Concepts. We directed all those requests to your team to handle at your discretion.
4 – I presume this is meant to be a direct attack at us:
MailPoet Post: Are we sure we are all aiming for an open, safe web in the WordPress community?
If I misinterpreted the intent here, please do let me know. You are right though, our ambitions are much larger than the WordPress community, we’re pursuing a safer web we as a whole regardless of platform.
Again, I personally apologize and empathize with the struggles you have endured over the past week or so. Your struggles were not our intent, and not our driving force. Before this incident we had no relationship and had no interest in the space you are in.
That being said, if it ever becomes an issue in the future, for you or any other developer, we will follow the same protocol that we used with MailPoet.
All the Best,
Tony and Daniel
One small note, you mentioned:
There’s a difference between warning users and disclosing a 0 day vulnerability to the entire world on the same day of the bugfix release.
Small point of clarification, Zero Day vulnerabilities are those that are released and have no patch. Your vulnerability was patched, hence not being a Zero Day anymore.</blockquote>
Creating a Safer Web
Yes, in case you’re wondering, this is but the tip of the iceberg for us.
We will be proactively researching security issues across the wide spectrum that is Website Security. From CMS applications like WordPress, Joomla, osCommerce, vBulletin, etc… to web servers like Apache, NGINX, Windows IIS, and more. As stated before, it’s what makes us who we are and the responsibility we have to our clients as well as the wider audience of the web as a whole.
The time to be more proactive in our research and overall contribution to the web is now, not tomorrow or the day after. We stand fast in our convictions and will continue to push forward. Remember our responsibility is not the developers and designers, but the millions of website owners, their websites and their businesses.
All the best,
Tony / Daniel