The ChipWIN Blog Hack: The Postmortem

- Posted February 13th, 2017 by

Last week on the CWB — the world was in disarray as nasty Russian porn spam assaulted the brave viewers of the mobile version of the blog.  President Hoodie made the decision to limit the spread of the pixelated and badly size-ratioed X-Rated images by halting blog operations for the week while ViridianForge and Chaney teamed up to figure out just what the heck had gone wrong. If you decide to jump past the fold, you’ll find out just what they discovered. This article is heavy on the technical detail for us, so before you dive in, take a look at these adorable kittens.

So….what happened?

Cutting straight to the point, the culprit was a nasty piece of work that injected mobile redirects into the blog’s .htaccess file and potentially quite a few of the blog’s internal WordPress files. In the process, we learned a few things about this particular hack.  Specifically, that it operated by adding malicious redirects to the blog’s top-level .htaccess file and similar redirects scattered throughout the blog’s internal .php files using various methods of obfuscation.

An example was discovering a Base64 encoded file – /wp-includes/pomo/sys.php.  Renaming this file caused the redirect probability of a mobile visit to seemingly drop off dramatically, but it did not wholly eliminate it.

A second example was found in a few lines buried out of sight in /wp-load.php.

This was nowhere nearly as sophisticated as our last find, which meant it was incredibly easy for Chaney and I to understand.  This little block of code asks if the visitor loading the blog post is using a browser that matches any of the types listed in the first argument to preg_match. If they are, it sets a cookie, and then sets the HTML header to the reverse of the concatenation of all those tiny little strings listed.  (Protip: You probably shouldn’t visit the php file there. Nope. Definitely wouldn’t recommend it.)

So, how did it happen?

While the Chiptunes = WIN blog was itself not perfectly protected, we believe the issue was with an older, unmaintained blog elsewhere on the shared hosting solution that Chiptunes = WIN’s WordPress install currently lives on. We think this as there was severe vulnerability was found in the WordPress REST API which was addressed in January 26th’s 4.7.2 security release. The full extent of the severity of this vulnerability wasn’t disclosed until February 2nd. While Chiptunes = WIN’s WordPress install was upgraded immediately, one of those older blogs on the shared hosting may not have been. You can learn more about this situation at ArsTechnica.

What was done to rectify the situation?

  • We engaged maximum good communication.
    • VF and Chaney immediately got onto Discord when they got word of the problem from Brandon.
    • This was especially critical as VF is currently working 40-50 hours a week and Chaney is in the middle of moving apartments.
  • We got our learn on.
    • WordPress provides an excellent resource in their article “Hardening WordPress
    • We used find to hunt down files of interest. (‘find . -name .htaccess’ to find all the .htaccess files in the blog directory structure)
    • We used grep repeatedly to hunt down potentially compromised code. (‘grep -rnw ./ -e “<string of interest>”)
  • The blog was restored from a fresh, vanilla tarball of WordPress 4.7.2 and backups.
  • We installed WordFence to provide constant monitoring and protection to the blog.
    • Securi also provides a great solution in this field – and comes highly recommended by Dj CUTMAN.
  • Internal directory permissions were cleaned up throughout the blog’s directory structure. 755 for directories, 644 everywhere else.
    • Excepting a few cases where we could get away with 600 permissions.
  • Per “Hardening WordPress” recommendations, .htaccess files were added in sub-directories to tightly control access and alterations to internal WordPress structures.
  • The site was scanned with to verify that we were operating cleanly.
  • The site was given a thorough scan of all plugins, themes, timthumbs using wp-scan to check for any other outstanding vulnerabilities visible to the world.
    • During this process, we also tried to brute force all the logins for the blog to make sure all the writer’s passwords were secure.

What can other steps can be taken to keep this from happening to you?

  • We’re looking at eventually moving off of our shared hosting solution to one entirely for Chiptunes = WIN. We’d recommend this to anyone running their own own WordPress blogs, just to limit your site’s exposure to threats.
  • If you only have a one or two users logging into your WordPress site – we’d recommend following these instructions to add a server-side password to your WordPress Administration files.

That concludes this postmortem. If you want to learn more, we’re including a number of good reading links below that VF and Chaney dug out of their bookshelves when attacking this problem. We both sincerely thank everyone for their patience during this downtime, and hope you’ll all continue rocking out with Chiptunes = WIN for many, many years to come.

Hardening WordPress | | Locking Down WordPress | WordPress Security Fundamentals
Essential System Administration Pocket Reference | Linux Server Hacks

Dig this article? Then consider supporting us on Patreon!