Solve WP Super Cache + Autoptimize Internal Server Errors

Yesterday I noticed my autoptimized JS-files were returning an internal server error (CSS worked as that is inlined). My Apache error-log had this entry:

[Tue Oct 13 17:23:42 2015] [alert] [client 178.xx.xx.xx] /var/public_html/blog.futtta.be/wp-content/cache/.htaccess: Option Indexes not allowed here

/var/public_html/blog.futtta.be/wp-content/cache/.htaccess is created by WP Super Cache, which got updated recently, a.o. to disable indexes being created of directories, and the .htaccess indeed read;

# BEGIN INDEX
Options -Indexes
# END INDEX

The solution? I could have edited WPSC’s .htaccess, but my changes could get overwritten there whenever Donncha would feel like it, so in the end I edited my site’s config in Apache;

<directory /var/public_html/blog.futtta.be>
AllowOverride All
</directory>

And all is well now.

On WordPress GET floods, plugin fingerprinting & keeping safe

flood sign, by alan in belfast from flickr under ccInfosec consultant and blogger Xavier Mertens suffered from a GET flood last week. The would-be DDOS originated from WordPress blogs that seemed non-related both geographically and content-wise, were using different versions of WordPress and seemed not to be compromised.
So what gives? WordPress blogs autonomously trying to DDOS other WordPress blogs? My best guess; a WordPress plugin gone rogue. The great WordPress HTTP API makes It easy enough to create a plugin that fetches targets from a control server and issues requests to those targets at a given time. It’s only a matter of hiding that behavior inside a plugin that seems useful and getting people to install that. The easiest way; finding an older plugin with an existing userbase and taking over development from the original developer (as i did with Autoptimize) is the easiest route to create your own little DDOS-ing botnet.

But all of this is pure speculation (although the UA matches the one used by WordPress HTTP API) off course. The only way to know for sure is to, for at least a sample of the flooding blogs, check what plugins they have in common. Doing so is frightfully easy using the NMAP HTTP WordPress Pugins script and if I am not mistaking Xavier is indeed looking into this.

But given the ease with which the NMAP-script can scan for WordPress plugins (there are similar scripts for e.g. Drupal modules), you might want to stop this from happening? I for one added this line in my WordPress .htaccess:

RedirectMatch 404 ^/wp-content/plugins/[^\/]*/$

Maybe you would even want to return a 404 for plugin readme.txt and index.html files as well, but I’ll consider that an assignment for you guys to chew over 😉

DDOS’ed by 80legs.com spider?

Just got some heavy traffic from a friggin’ spider with this useragent:

Mozilla/5.0 (compatible; 008/0.83; http://www.80legs.com/webcrawler.html) Gecko/2008032620

As changing robots.txt did not help immediately, more drastic measures were needed, so I added this tidbit to .htaccess to stop the fuckers:
SetEnvIfNoCase ^User-Agent$ .*(80legs) HTTP_SAFE_BADBOT
Deny from env=HTTP_SAFE_BADBOT

And now back to me just relaxing and having a bath! 😉