Responsible Disclosure – Sucuri Open Letter to MailPoet and Future Disclosures

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:

  1. 2014, Jun 16: Notified MailPoet of the vulnerability, provided patching recommendations.
  2. 2014, Jun 16: MailPoet team replied and said they were working on a fix.
  3. 2014, Jun 18: Notified Sucuri that they had fixed the bug and would released a patch soon.
  4. 2014, Jul 01: The MailPoet team updated WP.org with the new release.
  5. 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:

http://jetpack.me/2014/04/10/jetpack-security-update/

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.

You see, it’s all about a reasonable amount of time.

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.

Sucuri - MailPoet Security Disclosure

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.

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

Ask Sucuri: Who is logging into my WordPress site?

Today, we’re going to revisit our Q&A series. If you have any questions about malware, blacklisting, or security in general, send them to us at: info@sucuri.net. For all the “Ask Sucuri” answers, go here.


Question: How do I know who is logging into my WordPress site?

Answer: One of the most basic and important security aspects of any system is access control, specifically logging your access control point. It defines who can do what and where and under what circumstances. However, access control without the proper enforcement and auditing is like a law that is not enforced by the police; it loses its meaning.

WordPress has a very powerful access control tool, known as roles and capabilities, that allows you to specify what each user can do. However, it lacks good auditing capabilities. The purpose of auditing, i.e. logging, is to give administrators visibility into what is happening on the website at any given time.

Auditing is a very broad term. We could go in depth into the various elements that you, as an administrator, should audit. However, for this post we’re going to focus on your access control, specifically who is logging in.

Sucuri WordPress Security Plugin – Last Logins Feature

Out-of-the-box, the WordPress CMS does not provide auditing, nor does it include any type of authentication auditing for successful logins. For this reason, we have added both capabilities to our Free WordPress Security plugin.

The plugin allows administrators to see who is and has logged into your website. It includes attributes like location (i.e. where) and time. It’s known as the Last Logins feature (it’s based off the Linux “last” command).

This is what it looks like in your dashboard:

wordpress-lastlogins

It will list the users, IP addresses (hidden in the image) and the time of the login.

If you want to know who is logging in to your site (from when and from where), then leverage our Free WordPress Security plugin.

Note that it will only start logging the users, after you install it. So as soon you add the plugin, the last-logins table will be empty. But if you try to logout/log back in to WordPress, you should start to see it populating.

Importance of Auditing Your Access Control

For website administrators, we cannot stress the importance of logging activity, such as user log ins, enough. We handle various incidents on a daily basis where the website owner has no idea as to who is and isn’t logging into their environment.

Often, after a compromise, the forensics team will work with the website owner to understand what was going on. In many instances, basic auditing would have informed the client that something was not right. Here are some examples:

  1. Website owner works on the Pacific Coast, yet his user is logging in from China with his username and password
  2. Website owner is sleeping, yet somehow, the client’s user is still logging in
  3. A new user is logging into the environment every day and the website owner never created the user or it’s a single user website

Are you able to say, confidently, that this is not happening to you? If the answer is, “Yes,” then congratulations, you’re adhering to the auditing basics. If the answer is, “No,” then you should seriously consider downloading our free plugin.

Not Just Pills or Payday Loans, It’s Essay SEO SPAM!

Remember back in school or college when you had to write pages and pages of long essays, but had no time to write them? Or maybe you were just too lazy? Yeah, good times. Well, it seems like some companies are trying to end this problem. They are offering services where clients pay them to write these essays for you.

Essay SEO SPAM

The problem is that this is not only wrong, but it’s also becoming a competitive market where some companies are leveraging SEO SPAM to gain better rankings on search engines (i.e., Google, Bing). They are also using popular sites like bleacherreport.com and joomlacode.org to add their spam links.

Here are a couple example URL’s from sites that got hit (URL’s are still showing SPAM):

Read More

Friday the 13th – A Gallery of Webmaster Nightmares

This post is dedicated to all you geeky horror movie fans out there!

One morning you open your website and don’t recognize it. Something is devastatingly wrong. You wipe the sleep from your eyes, and instantly you know that you’re living your worst nightmare…

As you gain early morning focus from what you thought was a good night sleep, a scary face stares back at you, and declares that you’ve been hacked!

When you see it you know it’s, it’s…it’s…it’s Friday the 13th!!!

Hacked Website Defacement

It’s always Friday the 13th for webmasters of defaced sites, regardless of what their calendar tells. It becomes the most unlucky day in their webmaster life, the day when only bad things can happen.

Hacked Website Defacement 2

We, at Sucuri, come across such hacked sites every day. Every day we help website owners like you survive your Friday the 13th. We restore your sites and make sure this don’t happen again.

When your site is finally restored, and you calm down after the stressful fight for your site, it may eventually occur to you that the defaced page was a piece of some weird modern cyber art.

Hacked Website Defacement 3

OK, maybe you weren’t comparing your defacement to your favorite Van Gogh. We have seen defaced websites every day for the last few years, and after a while you start finding artistic value in some of the “hacked by..” pages you come across.

Sometimes they are disturbing and offensive, sometimes they are scary. Sometimes they are funny, and sometimes they even provide security advice.
In the end, they all reflect the sub-culture of h4x0r$.

Hacked Website Defacement 4

In this post, we’d like to share our collection of screenshots of defaced websites. Lean back and submerge into the world of cyber-chaos.
Once you emerge back from the craziness, think to yourself, and ask yourself the simple question, “Am I prepared to deal with such unfortunate events?”

Hacked Website Defacement 5

Hacked Website Defacement 6

Hacked Website Defacement 7

Hacked Website Defacement 8

Hacked Website Defacement 9

Hacked Website Defacement 10

Hacked Website Defacement 11

Hacked Website Defacement 12

Hacked Website Defacement 13

You can find 100 more screenshots and the whole collection on the Sucuri Facebook page.

——————

Have you encountered such defaced pages on the Internet? Share your own website nightmare, on this eery Friday the 13th!

How We Decoded Some Nasty Multi-Level Encoded Malware

From time to time, we come up with interesting bits of malware that are just calling us to decode and learn more about them. This is one of those cases.

Recently, I crossed pathes with this little gem:

dissecting-malware-step-1

That snippet is encoded malicious content. The full payload is is much bigger, 12816 characters, to be exact. Seems benign, right? At least it looks interesting. So interesting that I decided to dissect it, piece by piece.

Read More

Phishing Emails to Install Malicious WordPress Plugins

When all else fails, the bad guys can always rely on some basic social engineering tactics with a little hit of phishing!!

Over the weekend, a few of our clients received a very suspicious email telling them to download a new version of the popular “All in One SEO Pack” plugin for WordPress. What a win, right? It wasn’t just the plugin, but the Pro version too. To top it off, it was for Free!!! This is where the journey begins…

Happy Black Friday / Cyber Monday


Read More

Another Fake WordPress Plugin – And Yet Another SPAM Infection!

We clean hundreds and thousands of infected websites, a lot of the cleanups can be considered to be somewhat “routine”. If you follow our blog, you often hear us say we’ve seen “this” numerous times, we’ve cleaned “that” numerous times.

In most cases when dealing with infected websites, we know where to look and what to remove, generally with a quick look we can determine what’s going. Despite our experience and passion for cleaning up a hacked website, there are always surprises lurking and waiting for us, almost every day.

Some of the most interesting routine cases we deal with are often websites with SPAM. SPAM is in the database, or the whole block of SPAM code is stored in some obscure file. We also deal with cases where the SPAM is loaded within the theme or template header, footer, index, etc. Sometimes these SPAM infections are conditional (e.g. They only appear once per IP), sometimes not.

More often than not however, these infections is not too difficult to identify and remove. In the case we’re writing about in this post, we were able not only to remove malware, but also take a look at what’s going on behind the curtain.

Read More

Case Study: Analyzing a WordPress Attack – Dissecting the webr00t cgi shell – Part I

November 1st started like any other day on the web. Billions of requests were being shot virtually between servers in safe and not so safe attempts to access information. After months of waiting, finally one of those not so safe request hit one of our honeypots.

We won’t get into the location of the site because it really doesn’t matter, a fact that most critics don’t realize. As is often the case, the honeypot site was quiet without much traffic and the weakness was access control.

We intentionally left the password to the site to one of the top 10 passwords, with continuous attempts it took about 3 months before it was accessed.

This time though we were ready and this is how it went..

Read More

WordPress 3.6.1 Released – Includes Security Fixes

The WordPress team just pushed out a new version of WordPress. WordPress 3.6.1 is a maintenance release that includes some security bug fixes. Straight from their release post, these are the security changes:

  1. Block unsafe PHP unserialization that could occur in limited situations and setups, which can lead to remote code execution. Reported by Tom Van Goethem.
  2. Prevent a user with an Author role, using a specially crafted request, from being able to create a post “written by” another user. Reported by Anakorn Kyavatanakij.
  3. Fix insufficient input validation that could result in redirecting or leading a user to another website. Reported by Dave Cummo, a Northrup Grumman subcontractor for the U.S. Centers for Disease Control and Prevention.

We asked WordPress Lead Developer, Andrew Nacin for a bit of clarity around the author role issue that was fixed, here’s what Andrew said:

A user can reassign the authorship of a post to another user, even when they are not allowed to do so. (For example, the user is an Author and not an Editor.) The user must already be allowed to edit content — and specifically edit that post. They also then lose the ability to edit that post, but this “forging” could still cause a compromised account or malicious user to post as another user.

In closing the conversation with Andrew, he remarked that WordPress is not vulnerable to the remote code execution issue by default:

I’ll emphasize that WordPress is *NOT* exploitable to the RCE out of the box, despite it being a doozy. It requires a vulnerable object (which core does not have), as well as a vulnerable character set. It is a “perfect storm” vulnerability.


Read More

Over 10% of Alexa TOP Million Websites Found Not Safe – Infographic Report

We scan a lot of websites per day. Through our daily work we see all sizes and types of websites compromised, blacklisted, and filled with various security issues. But, we don’t often aggregate the results to provide a public report of what we are seeing.

So last month, we decided to do just that. We decided to scan the most popular websites on the internet to see how bad, or good, they are in terms of web security.

Our testing was very simple. We chose the top 1 million sites (according to Alexa), and checked the sites for those 4 issues:

  • Is the site Blacklisted? Sites were checked on Google, Norton, McAfee, ESET and Sucuri Labs.
  • Is the site infected with hidden SPAM?
  • Is the site infected with malware like drive-by-downloads, exploit kits, and similar issues?
  • Is the site running outdated software?

If the site passed those 4 tests, it would be considered safe for our testing purposes. Let’s see how the sites did.


Read More