Monthly Archives: March 2013

As found on the web (March 25th)

blog (feed #46)
generic (feed #49)
youtube (feed #51)
blog (feed #46)

Thanks for reminding me about AdBlock Plus Google!

So Google removed AdBlock Plus from the Google Play Android store. That is their prerogative, off course, but it does confirm they’re not the cool technology-centric search engine everyone once thought they were.┬áIt’s kind of ironic that in December 2011 AdBlock Plus by default enabled the display of “acceptable” ads, a move that seemed to be an attempt to appease (or please) Google.

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.

I don’t like particularly like ads, I don’t like widgets snooping on my web-whereabouts and I definitively don’t like Google’s advertising department dictating what applications the editorial team in charge of Google Play should remove. So today I installed AdBlock Plus on all my devices. Maybe you should too?

Introduction to Adblock Plus

Watch this video on YouTube.

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

How to have normal YouTube-links handled by WP YouTube Lyte

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:

/** force wp youtube lyte on http://www.youtube.com url's as well */
add_filter('the_content', 'force_lyte_parse', 1);

function force_lyte_parse($content) {
     $content=str_replace('http://www.youtube.com/watch?v=','httpv://www.youtube.com/watch?v=',$content);
     return $content;
}

Now that wasn’t too hard, now was it?