Being wary of all things tracking by Google & Facebook, both of who’s products I love but data capturing practices I hate, for the last 4 years or so I always logged in into these in “Private browsing” sessions in Firefox (because why trust the worlds biggest advertising platform with your privacy, right?)
Now I just “discovered” that the Mozilla team have rendered that somewhat clumsy procedure -which required me to log in each time I restarted my computer or browser- redundant with their “Firefox Multi-Account Containers” add-on, allowing you to contain entire sessions to one (or more) tabs;
So now I have one browser window with a couple of tabs in the Google container, one tab in a Facebook container and all others in the “default” container where Google & Facebook can’t track me (fingerprinting aside, but there’s an option for that).
Infosec 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 ;-)