But whatever way you look at this, Google’s core business (as is Facebook’s) is displaying ads. Sure they try to do that in an intelligent manner. And sure, they have some cool technologies (App Engine, Android, Chrome, …). But at the end of the day they want us to see and click on ads. That makes Google a media company. But whereas traditional media have -at least the notion- of a wall between their editorial and advertising departments, editorial independence does not seem to exist over at Google.

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 ;-)

The title of the video (and the description, length, …) is now requested and cached server-side (the data is storedin the WordPress database, as post_meta, to be precise) and included in the HTML instead of getting that data client-side using JavaScript

Although by default WP YouTube Lyte only works with httpv or httpa links and hence does not act on normal YouTube links (which are instead auto-handled by oEmbed in WordPress core), you can easily change this behavior by adding the following code-snippet to your theme’s function.php or to a separate “helper”-plugin: