How One Dev Accidentally Brought Down Millions of WordPress Sites

Security researchers enjoy the honor and privilege of making the Internet a safer place for users. For most of the time, they’re the silent guardians of the web. But in a few cases, their work receives the acclaim it so rightfully deserves.

Sometimes it’s for unexpected reasons. Security is a process, after all, which means defending against vulnerabilities and digital attacks is an ever-evolving task. Such an endeavor is difficult to begin with, but given the growing complexity of today’s software and IT systems, it can prove to be next to impossible.

In that vein, fixing one issue or simply adding a new software feature can undermine the security of thousands if not millions of users, especially when most of those users don’t take their own security to heart.

Product developer Jeremy Boyd learned that the hard way when one of his software fixes inadvertently caused Google to flag millions of ordinary people’s WordPress sites as malicious.

“Well, There It Was. Millions of Sites Had Been Affected.”

Several years ago, Boyd was intent on becoming someone in the WordPress developer community. He, therefore, decided to partner with a designer named George Wiscombe to work on a WP theme called Handgloves. For that project, he widgetized the theme and added a couple of social media hooks to it. Wiscombe approved Boyd’s changes and decide to publicly release them.

Some time later, a client specializing in interior design asked Boyd’s company to create a Multi-User WordPress installation for them. It wanted an asset catalog to reside under the installation’s main root, and it specified that each of its designer’s sites function as a subdomain.

Easier said than done. The problem rested with something called TimThumb, a PHP script that takes a bunch of parameters and resizes an image.

Boyd elaborates further:

“[TimThumb] was hard-coded to use only the local uploads folder by prepending the website URL to the uploads directory, then appending the image name.

“I decided to do a quick fix for this…. I allowed you to pass either the image name or a full URL with schema. If a full URL was passed, it would download the image locally into your uploads folder.”

Boyd posted the fix on his personal blog with the warning: “I haven’t tested this, and there are probably gaping holes in it.” He then basically forgot about it.

“Well, There It Was. Millions of Sites Had Been Affected.”

Some of our decisions have a funny way of circling back on us months if not years after we make them. That’s exactly what happened to Boyd when he found a snippet of code exploiting his fix.

Basically, attackers were using the update to find a website using TimThumb. They would then make a request for that site to grab their remote PHP script. The TimThumb utility on the target site would download the attackers’ script locally in the uploads directory thanks to Boyd’s fix, which would enable the attackers to own the site when executed.

As put another way by the product developer:

“The bug originated from my need to pull images from the parent domain and use them in a custom field for the featured image. So the blog http://jeremy.example.com needed to have timthumb.php pull in an image from http://www.example.com/uploads/2010/10/, and that technically allowed non images to be downloaded and cached into the requesting sites uploads folder, and if your upload folder allowed execution, an attacker could very easily run the downloaded scripts.”

It wasn’t all cut and dry, however. Months had elapsed since Boyd had published the temporary fix to his blog. In that span of time, TimThumb’s developers had taken the opportunity to patch the utility for the cross-domain issue. Any sites that had implemented the fix or set up permission settings on the uploads folder were, therefore, unaffected.

But millions of sites had failed to implement those security measures, meaning they were vulnerable to attack. Such a widespread lapse in security brought Boyd’s warning to life:

“That gaping hole that I warned might be in my super shitty code… Well, there it was. Millions of sites had been affected.”

Picking Up the Pieces

News of the flaw (along with a fix) first emerged on August 1, 2011. By that time, attackers had already started abusing the zero-day vulnerability to take over vulnerable WordPress sites and infect them with malware. All that the bad actors needed to do was sit back and wait for unsuspecting users to visit the compromised websites.

In the meantime, Google had learned of the exploit and decided to take matters into its own hands. The tech giant started blocking all sites that were still using a vulnerable version of TimThumb installed. Consequently, those websites didn’t appear in Google’s search results, and when someone tried to access them in the Chrome browser, Google displayed a screen warning of malware.

No one could reach the affected sites. There was no way to find them using Google search, and they were completely inaccessible via one of the most popular web browsers.

By all accounts, millions of WordPress sites went effectively offline.

Conclusion

The story above clearly illustrates how poor website security practices can produce disastrous results for ordinary users. Boyd and developers like those at TimThumb can only do so much to release software fixes and security patches. It’s up to site owners to implement them in a timely manner and to protect their WordPress sites using a variety of tools and plugins.

Want to learn more about how to harden your WordPress sites? Please click here.