Tag Archives: wordpress

Pingback Problem: 162K WordPress Sites Tricked into DDoS

It’s always annoying when someone figures out a way to exploit intentional behavior, especially when it’s a key part of the design.

Sucuri reports on a denial-of-service attack that used thousands of legit WordPress sites to distribute the attack by sending fake pingbacks “from” the target site to all of the reflectors. Those blogs would all contact the targeted site to confirm the pingback and retrieve a title and summary…all at once, overwhelming it and taking it offline.

The quick-and-dirty solution is to remove XML-RPC functionality, but that also breaks certain plugins (like Jetpack) and the ability to connect to your blog using the WordPress mobile apps.

A little background on why Pingbacks work this way:

Waaaay back in the early days of blogging, most bloggers would interact by way of comments. If you wrote a blog post, and I was inspired to write a response, I would then go over to your site and post a comment letting you know about my own post. Two systems were proposed in 2002 to automate this process: pingbacks and trackbacks.

  • Trackbacks sent a complete summary to the remote blog, including the title of your post, the link, and an excerpt (which you could manually craft, or let your software handle).
  • Pingbacks sent a notice — a “ping” — to the remote site with the URL of your post, and then the remote site would retrieve it and extract the title and a summary.

This was also around the time that blog comment spam and spammy blogs were getting to be a big problem. What would happen is a spamming site would send out trackbacks to as many sites as possible claiming that they’d responded to some post, thereby getting backlinks on a zillion blogs and increasing their page rank. Pingbacks had an advantage: Because you were calling back already, your server could check to see whether the other site really had linked to you. It took a long time, but eventually this escalated into spammy blogs creating a temporary post with real links to the pages they pinged, then replacing it with a spam page after a short amount of time.

The problem now is: How do you block abuse of an as-designed behavior? That’s happened before: Back in the early days of the internet, it was considered polite to run your mail server as an open relay and rude to lock it down, but after spammers started massively abusing them, an open relay became a sign of a sysadmin who didn’t know what he was doing.

The comments on the Sucuri article suggest that Akismet, as a collaborative comment-spam filter, might be able to mitigate this type of attack. Wordfence’s collaborative security filter seems like another system well-positioned to detect it. But if that approach fails, pingbacks might just go the way of open relays.

Update March 18: Akismet has released a new version of the anti-spam plugin that mitigates this problem in two ways:

  1. Spam checks on pingbacks are now done before the verification request is sent, so that once an attack is identified, Akismet will prevent blogs from participating.
  2. An X-Pingback-Forwarded-For header is added to the verification request identifying where the pingback actually came from, making WordPress+Akismet a less attractive choice as a reflector by removing the anonymity.

Item #2, IMO, belongs in WordPress itself, not in a plugin, but I imagine this was a way to roll out the feature more quickly, at least to those sites using Akismet.

Update April 8: The X-Pingback-Forwarded-For header has been added to WordPress 3.8.2 and the upcoming 3.9.

First Stab at WordPress/MySQL Tuning

My job sent me to a class on scaling, optimizing and troubleshooting MySQL this week. I’ve been digging around a bit on some test databases at work, but of course as someone running a self-hosted WordPress blog, I had another MySQL server to practice on right here — one with real-world data and (admittedly low) load, but where I was only accountable to myself if I messed anything up.

Unfortunately, DreamHost’s MySQL VPS doesn’t give you much control over the server, and of course when you’re working with a third-party application, there’s only so much you can change the database without breaking compatibility. But I found some interesting surprises:

1: Everything was using the older MyISAM engine, because DreamHost is running an older version of MySQL that uses it as the default. Switching to the newer InnoDB (and back) is simple and safe enough that I figured it was worth a try.

2: There was a lot of junk left over from old plugins that I haven’t used in years. Continue reading

WordPress Name+Number Login/Registration Attacks

I’ve been seeing brute-force login attacks on another of my WordPress sites, but instead of targeting typical usernames like admin or extracting post authors, they’re random name and number combinations like Emanuel95A. What use could that possibly be? You’re not likely to hit on an existing user that way.

It turns out it’s not a dictionary attack after all. It’s not really a login attack either, at least not deliberately. It’s actually a bot trying to register new usernames (maybe for spam, maybe in preparation for a privilege escalation attack, who knows?), which explains the name and number combination: they’re actually trying to get a username that’s not already in use.

The bot hasn’t figured out that registration is turned off, so when WordPress redirects it to the login form, it keeps trying to register…in the login form…over and over until it gets locked out. (On a related note, if you don’t have something like the Limit Login Attempts plugin on your site, install one now.)

Because registration was off and repeated logins were blocked, it wasn’t currently a threat, but the alerts for all the lockouts were getting a bit annoying. I decided instead of nicely sending the “user” to the login page, I’d kick back a 403 error instead. Rather than hack WP or write a plugin, I just added a mod_rewrite rule:

# Broken register bots are repeatedly trying to log into the site.
RewriteCond %{QUERY_STRING} (registration=disabled|action=register) [NC,OR]
RewriteCond %{HTTP_REFERER} registration=disabled [NC]
RewriteRule ^wp-login.php - [F,L]

That leaves the form active under most circumstances, but stops everything if it’s been redirected from the registration page.

End of the Blogroll

The first beta of WordPress 3.5 is out, and along with new and improved functionality, one feature is being removed: the blogroll. Well, technically it’s only being removed on new installations. If you have an existing WordPress site with links in the Link Manager, it’s not going away until a future release, and even then it’ll be moved into a plugin. (Lorelle writes about the history of blogrolls in WordPress and what to do if you want to keep yours.)

The move reflects changes in blogging trends, as well as the ongoing struggle between search engines and the SEO industry. In the old days, it was trendy to list sites you liked in a sidebar. Search engines took note, and then SEO practitioners started taking advantage, and so blogrolls lost their value.

One of the sessions I attended at WordCamp LA was a talk on optimizing WordPress. One of the measures I’ve been looking into is reexamining the plugins I use. (Sure, there’s no such thing as too many if you’re actually making use of them, but more code needs more resources.) I’m actually using two plugins to increase the value of my blogrolls here and at Speed Force:

  • Better Blogroll to show a small, randomized subset on the sidebar instead of the full list of links. (This keeps it from being clutter, and prevents the links from fading into the background by being the same on every page.)
  • WP Render Blogroll Links to list them all on a page.

I keep thinking, do I really need these? Well, I definitely don’t want a long blogroll in the sidebar. If all I want is a links page, I can just write one, and if I really want static short list in the sidebar, I can add them manually. It only really matters if I want to keep that random subset. Otherwise, I can pull two more plugins out of my installation.

But then, do I even need the links page at this point? My current links here mostly fall into one of three categories:

  • Well-enough known to not need the promotion.
  • No longer relevant to this site.
  • Other sites I maintain.

I might want to just drop the list entirely.

Speed Force’s links are both more extensive and more targeted to the site. It’s probably worth keeping that list around, but maybe just as a links page.

Does anyone actually look at those sidebar links anymore?

New Plugin: Nice Links for Twitter Tools

Lately I’ve been linkblogging via Twitter, and using Alex King’s Twitter Tools to build a weekly digest in WordPress. The problem is that since I’m pulling the posts from Twitter, I’m stuck with Twitter’s limitations: Short descriptions, cryptic URLs, and unreadable links.

So I wrote a plugin to process the links. When Twitter Tools builds a digest, the plugin calls out to the remote site, follows redirects, retrieves the final URL and (if possible) extracts the page title. Then it replaces the cryptic-looking link with a human-readable link, transforming this:

Check out this site: http://bit.ly/9MhKVv

into this:

Check out this site: Flash: Those Who Ride the Lightning

If it can’t retrieve a title, it uses the final hostname. If it can’t connect at all, it leaves the link unchanged.

The download is here, and that’s where I’ll put future versions:
» Plugin: Twitter Tools – Nice Links.

Future

One thing I’d like to add at some point is cleaning up the title a bit. They can get really long, even without people trying to stuff keywords and descriptions in for SEO purposes. All it takes is a page title plus a site title, like this one. That’s a much more complicated problem, though, since there isn’t any sort of standard for which part of a title is the most important. I suppose I could just clip it to the first few words.

I’d also like to clean up duplicate text. Often the link title and tweet content are going to be the same, or at least overlap, especially if it’s generated by a sharing button or extension. That should be easier to check.