Upgrade and Secure WordPress

No Comments

Matt Mullenweg reported the following:

Right now there is a worm making its way around old, unpatched versions of WordPress. This particular worm, like many before it, is clever: it registers a user, uses a security bug (fixed earlier in the year) to allow evaluated code to be executed through the permalink structure, makes itself an admin, then uses JavaScript to hide itself when you look at users page, attempts to clean up after itself, then goes quiet so you never notice while it inserts hidden spam and malware into your old posts.

Here are two quick steps to avoid unnecessary risks:

Turn off user registration

This one is simple. Just log in to your administrator screen and visit the “General Settings” screen (listed under Settings) and make sure the checkbox labeled “Anyone can register” is not checked.

Block access to your blog’s admin area

This can be accomplished with simple authentication.

If your site runs on Apache, you can create an .htaccess file in your /wp-admin/ directory to require authentication before the page is displayed. This post provides the necessary steps.

Force a URL to Use HTTPS

2 Comments

Today I came across some old ColdFusion & Mach-II (1.0) code where a plugin was used to force HTTPS. I assume the original developer decided to go with this solution because the target environment was Windows and Internet Information Server.

The task becomes a lot easier under Apache. So I threw away the plugin code and added the following rule to the Apache configuration:

<directory "/public_html/mysite.com">
RewriteEngine on
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*) https://%{HTTP_HOST}/$1	[R,L]
</directory>

The directive above can be placed inside a VirtualHost or Directory directives, but this usually requires access to the Apache server configuration, which is not typically possible in a shared hosting environment — in that case, the rule can be added to the .htaccess file.

Alternatively we could have used the SSLRequireSSL Apache (2.x) directive, but this would only block access to the non HTTPS address. In our case we want to automatically redirect the users instead of displaying an error message.

WPA Cracked, Sort Of

No Comments

Arstechnica has a great explanation of the issue.

Academic researchers have found an exploitable hole in a popular form of wireless networking encryption. The hole is in a part of 802.11i that forms the basis of WiFi Protected Access (WPA), so it could affect routers worldwide. German graduate student Erik Tews will present a paper at next week’s PacSec in Tokyo coauthored with fellow student and aircrack-ng team member Martin Beck that reveals how remnants of WPA’s predecessor allow them to slip a knife into a crack in the encryption scheme and send bogus data to an unsuspecting WiFi client.

In an interview from Germany, where he is a PhD candidate studying encryption at the Technical University of Darmstadt, Tews explained that an existing attack on Wired Equivalent Privacy (WEP) was modified to provide a slim vector for sending arbitrary data to networks that use the Temporal Key Integrity Protocol (TKIP). (Tews’ collaborator Beck is a student at the Technical University of Dresden; Tews credits Beck with the discovery, after which they jointly developed the paper that Tews will present at PacSec.)

With the Tews/Beck method, an attacker sniffs a packet, makes minor modifications to affect the checksum, and checks the results by sending the packet back to the access point. “It’s not a key recovery attack,” Tews said, “It just allows you to do the decryption of individual packets.” This approach works only with short packets, but could allow ARP (Address Resolution Protocol) poisoning and possibly DNS (Domain Name Service) spoofing or poisoning.

The paper, Practical Attacks against WEP and WPA, is now available for download.

So even though TKIP is not broken, the best way to protect your network is by switching from TKIP to AES with a relatively random password at least 20 characters long.